Through its experience, éolane can support its customers in an RAMS (Reliability, Availability, Maintainability and Safety) approach, during the development of products whose failures can lead to serious events, jeopardizing people or resources safety.
For a complete system or subsystem, the 120 éolane R&D engineers:
- identify all products possible risks
- define the safety level associated with each risk
- design the corresponding solution
- take into account maintainability and repair operations
- carry out the certification or provide the necessary evidence
Standards and markets
- EN 61508 is the "hat" standard for the industrial world dealing with the functional safety of electronic systems
- The standards opposite are variations adapted to each market
For more than 10 years, éolane’s R&D teams have been able to prove successful design experiences in connection with these standards and these markets.
Depending on the level of safety required by the product, éolane is capable of being completely autonomous or can call on identified partners.
3 Steps
1. Risks identification and processes
- Two possibilities :
- A risk analysis has already been carried out by the client and will serve as a basis for the rest of the project
- Or, éolane supports its customers to achieve it
- The risk analysis makes it possible to define the safety level to be associated with each risk, according to the reference standard. Examples:
- automotive market (ISO 26262): from ASIL A (least secure) to ASIL D (most secure)
- rail market (EN 50126): from SIL 0 (least secure) to SIL 4 (most secure)
- At the end of this analysis, éolane
- adapts its development cycles according to the required safety level (s)
- constitutes a seasoned project team, taking into account the necessary independence constraints
2. Adapted architecture
Thanks to an iterative approach making it possible to define a functional architecture and to make it safe with regard to its potential failures, each function is:
- allocated to one or more trades: electronics, software, mechanics.
- made "robust" via:
- adding diagnostics
- sub-functions redundancy
- intrinsically safe design
3. Evidence
The normative constraints make it necessary to justify the design and verification method. The safer the product, the greater the depth of justification.
Evidence may consist of the following elements:
- the development plan
- the metrics required by the standards and based on calculations involving the complete system (electronics and software)
- FMEA
- Fault trees
Differentiation criteria
- Taking into account customer needs at the center of solutions for optimal performance
- A very wide variety of security products already developed in many business sectors
- Multidisciplinary teams in permanent contact (R&D, Industrial, Purchasing, etc.) and a proven network of partners
- Consistency of all businesses and their development cycles
- An average experience of teams of more than 15 years