Product development on HW level (part 5 of ISO 26262)
Looking for a basic understanding of what you need to address safety requirements when developing hardware components? Here you can find a corresponding video along with a whitepaper for download.
Back to Functional safety
A quick summary of product development at the hardware level? Our free whitepaper contains all the important information, including helpful illustrations, on the fifth part of ISO 26262 - ideal for anyone new to the topic of process improvements for safety-critical systems.
When we talk about hardware, we mean the hardware of electrical and electronic systems. This ranges from individual parts, such as resistors, to AD converters, sensors, microcontrollers, and ASICs used in vehicles. Hardware can be non-programmable and programmable elements.
If you have already developed such hardware elements – maybe for IT applications or household appliances – but now want to supply the automotive industry, then you’ll have to take into account that this hardware might now become safety-relevant. You are entering a domain with strict safety requirements and high product liability risks. Therefore, it’s essential that you adapt your hardware development processes.
Part 5 of ISO 26262 contains the requirements which are specific for the automotive market.
In six lessons, you will learn what you have to do additionally or differently in the individual phases of hardware development.
Image
Structure of ISO 26262:2018
Hardware development is part of system development in the safety lifecycle and runs parallel to software development.
A prerequisite for hardware development is a “technical safety concept” on the system level, shown above in the top left corner. Bottom right you see that the developed hardware goes into system integration. If safety-related factors have to be taken into account for the hardware in production or in later operation, these are passed on to the corresponding planning as so-called special characteristics, shown in the bottom left corner. Hardware may already exist and be fully developed, independently of ISO 26262. If you want to use such hardware in a safety-related vehicle project, there are conditions under which this is possible, shown above as a box outside the hardware phase model (“Evaluation of hardware elements”). But let us now concentrate on the phase model.
ISO 26262 first introduces this phase model with special clauses for the automotive field. Hardware development is affected by functional safety and this requires your attention and action.
Functional safety requires the hardware development process to be adapted to the requirements of ISO 26262.
The first step is to take technical safety requirements affecting hardware and refine and specify these as hardware safety requirements.
- This affects the specifications of safety mechanisms that the hardware must implement. For example, the detection of excessive voltage fluctuations in the power supply for individual components and microcontrollers. Or switches that no longer close.
- Your safety requirements must specify how detection, indication and control of faults in your hardware should be carried out.
- In some cases, safety requirements will also affect the monitoring of and reaction to errors in connected hardware.
- Tolerance times have to be specified.
- And this point is very special for ISO 26262: there are hardware metrics and certain definitions for failure rates. The target values that have to be achieved must be defined for this.
Furthermore, as a hardware engineer, you have to help refine the specifications of interfaces with software (the Hardware-Software-Interface).
And finally, hardware safety requirements have to undergo reviews and must be released.
Technical safety requirements must be detailed down to quality hardware safety requirements in order to be implemented in the hardware design.
Need support with a key project? We’re your first port of call when it comes to management consulting and improvement programmes in electronics development.
Steffen Herrmann and the sales team
In the next phase requirements are implemented in a concrete hardware design. This begins with the level of hardware architectural design.
From a safety perspective, hardware should be designed so that it implements the required safety requirements placed on hardware. This design is not just to deliver functional safety, but of course it also has to safeguard the actual function of hardware. Safety mechanisms thus become an integral part of the design. Since we may have to deal with requirements of different ASILs, there may be parts of the hardware with these different ASILs. To avoid “unsafe” parts endangering “safe” parts, ISO 26262 specifies criteria that you must take into account.
Finally, you have to prove that hardware safety requirements have been systematically implemented in the form of traces.
You can develop the hardware detailed design according to usual industry standards, but you must take the required robustness into account for your automotive application.
Functional safety requires that you conduct so-called “safety analyses”.
Graded by ASIL, you have to classify hardware faults with regard to violations of given safety goals. I cannot explain these terms in detail here, but there are certain faults that don’t endanger safety goals, those that directly endanger them, and those that only endanger them in combination with other factors.
With respect to the safety of automotive applications, you must provide credible evidence of how you can prevent faults violating safety goals and how you can prevent latent faults remaining permanently present in the vehicle.
In this phase you also have to think about the special characteristics needed for the production and maintenance phase, and ensure they are then implemented.
Hardware faults must be classified according to whether and how directly they violate safety goals.
Evidence must be provided that hardware faults that occur do not violate safety goals and are not permanently present in vehicles without being detected.
The next two clauses of ISO 26262 require analysis from you to ensure your hardware is suitable for the corresponding ASIL.
First of all, you must demonstrate that the hardware has sufficient mechanisms for detecting and controlling random hardware failures. Safety mechanisms must be effective at certain percentages.
Then you have to demonstrate that the probability of failure is low enough. Evidence must be provided of low enough safety goal violation rates due to random hardware failures.
Both clauses contain automotive-specific metrics and methods that you have to implement, but I will explain them in a separate video/white paper.
We’re proud that we have been one of the pioneers of functional safety since 2008 and that this has given us the opportunity to leverage our experience in developing the ISO 26262 safety standard.
Functional safety in automotive electronics? We’re the experts!
We have a wealth of experience in functional safety according to ISO 26262, having conducted over 700 projects with more than 100 clients worldwide.
Functional safety in automotive electronics? We’re the experts!
To date, we have trained more than 100 specialists under the TÜV Rheinland Functional Safety (Automotive) certification scheme.
Functional safety in automotive electronics? We’re the experts!
We already have 18 experts certified under the TÜV Rheinland Functional Safety (Automotive) scheme, or privately approved as official trainers.
Functional safety in automotive electronics? We’re the experts!
If we add up the experience of our experts in the field of functional safety, it comes to no less than 250 years.
Functional safety in automotive electronics? We’re the experts!
Who wrote the classic manual on Functional Safety in Practice, or Functional Safety Essentials? We did.
Functional safety in automotive electronics? We’re the experts!
Metrics on the effectiveness of safety mechanisms have to be created and the average probability of failure per hour has to be calculated. Compliance with ASIL-specific limits is an argument for the suitability of the hardware.
As usual, hardware is developed iteratively based on several samples and can be released for mass production after successful integration and testing.
ISO 26262 requires that this phase is planned and that tests are specified and carried out successfully.
You have to show that methodical procedures have been applied for specifying test cases.
You must demonstrate that hardware safety requirements have been implemented successfully and that the hardware is robust.
You must carry out tests according to industry standards. This includes, for example, function testing, electrical testing, and EMC tests.
Methods have to be used for the specification of hardware tests. Hardware tests must be performed successfully according to industry standards.
This tutorial was an introduction to special requirements affecting the development of hardware for automotive applications.
Please keep these key lessons in mind.
- Functional safety requires the hardware development process to be adapted to the requirements of ISO 26262.
- Technical safety requirements must be detailed down to quality hardware safety requirements in order to be implemented in the hardware design.
- Hardware faults must be classified according to whether and how directly they violate safety goals.
- Evidence must be provided that hardware faults that occur do not violate safety goals and are not permanently present in vehicles without being detected.
- For this purpose, metrics on the effectiveness of safety mechanisms have to be created and the average probability of failure per hour has to be calculated. Compliance with ASIL-specific limits is an argument for the suitability of the hardware.
- Methods have to be used for the specification of hardware tests. And hardware tests must be performed successfully according to industry standards.
- Improving your processes to keep them up to date with the latest safety standards – also so you can develop and sell reliable, available, maintainable and functional products
- Designing and rolling out safety management systems
- Conducting safety audits to confirm that your safety management fulfils relevant requirements
- Knowing for certain if a supplier really can provide you with the right components
- Building the capability to assess the functional safety of electronic systems and components
- Building the capability to provide staff training on all aspects of functional safety
