Product development at system level (part 4 of ISO 26262)

As a vehicle supplier, are you looking for a basic understanding of what you face in product development at the system level? With a video and free whitepaper, learn here what you need to consider from a Functional Safety perspective according to Part 4 of ISO 26262.

Back to functional safety

The level, on which individual technologies are integrated into a product, can be roughly referred to as the “system level”. The technologies involved in a system are software, hardware, optics, hydraulics and so on. Specifically, within our context, we will focus on hardware and software.

Traditionally, suppliers in the automotive industry have hardware development departments and software development departments. Cooperation between the two specialist areas is often poorly organised. Employees work together selectively, only when they recognise that it has become necessary. It is the project manager who often also takes on coordination of activities. One serious disadvantage with this approach is that the system level is only looked at implicitly, or “in passing”, instead of being seen and developed as a separate discipline. But to make an overall automotive system safe, this is a discipline that is absolutely crucial. It is the system level that should define the requirements for each individual technology and systematically integrate them.

Part 4 of ISO 26262 contains the corresponding requirements.

Image   Structure of ISO 26262:2018
Play
Your free whitepaper

Ready for a quick summary on the system level in functional safety? Our free whitepaper provides you with a digest of all the important information, including illustrations that show what has been said about Part 4 of ISO 26262 – the ideal read for anyone new to the topic of process improvements of safety-critical systems.

Now, you'll learn how the system level is embedded in the safety lifecycle. You will learn about the system level reference phase model. And you will learn the key activities related to functional safety at this level.

The system – an engineering task in its own right

The system level follows the concept phase in the lifecycle. 1st-tier suppliers are usually responsible for the system level, while the carmaker is usually responsible for the concept phase. The supplier delivers a system to the carmaker's production line. If necessary, there are several nested systems and various sub-suppliers.

The first aspect is that the system level must be seen as something that needs explicit attention. I have already explained the first insight, namely that the system level must be seen as such and institutionalized. You must have a system engineer to design this level, including error detection and handling mechanisms.

Key lesson number 1 is therefore: Safety activities need to be coordinated at a system level.

Reference phase model of the system level

In the video and the whitepaper, you can see the system level reference phase model. ISO 26262 assigns security activities to three clauses.

  • The technical safety concept includes the prerequisites for hardware and software development.

  • System and item integration and testing integrates and checks the results of the disciplines over several integration levels, up to the complete system.

  • Finally, safety validation must provide evidence that the safety goals have actually been achieved in the vehicle, and that the result of the development can be released, produced and installed in vehicles.

Note: This reference phase model groups development topics logically. Of course, I can only integrate what I have already developed. However, the reference phase model should not be understood in such a way that the finished result of hardware and software development has to be completely available before I can start with integration. In practice, it is always the case that several hardware samples and numerous software releases are built and integrated. This means that the reference phase model has to be used iteratively, several times, and it’s only during the very last iteration that all requirements of ISO 26262 have to be met.

I would now like to explain the clauses of the reference phase model individually. Let's start with the technical safety concept.

WE’RE HERE TO HELP YOU

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

Technical safety concept (Clause 4.6)

Technical safety requirements (TSRs) are mainly derived from the functional safety requirements defined by the carmaker, and these must be made available to the Tier 1. The TSRs are safety requirements asking for the implementation of safety mechanisms. Safety mechanisms are used to detect, indicate and control faults. It must be specified which safe state the system has to change to if an error is detected. You also have to think about tolerance times, which depend very much on the specific application and other safety mechanisms. Requirements must be defined to avoid that errors that do not immediately lead to a violation of the safety goals remain permanently in the vehicle, thus posing a future danger. Finally, it may be necessary to define safety requirements for production, operation and service, and decommissioning.

We are looking at the system level here, for which a system architecture must be developed for implementing the functional (in the sense of the actual desired functionality) and the functional safety requirements.

Functional safety requires that safety analyses are carried out. Examples of analysis methods are failure mode and effects analyses, FMEAs, and fault tree analyses, or FTAs. Their aim is to think systematically, based on methods, about the causes of faults and their effects on the violation of safety requirements. Systematic errors must be taken into account – for example errors caused by incorrect software programming – as well as random hardware faults.

Safety requirements must be detailed enough to be specifically assigned to the hardware and software disciplines for implementation.

The system engineer mentioned earlier has the task of ensuring that there is an explicit specification for the interface between hardware and software (the “Hardware-Software-Interface”).

Finally, the quality of safety requirements and the system architecture must be verified.

Functional safety requirements are detailed into technical safety requirements so that they can be implemented with the system architecture to be developed in parallel.

Systematic failures and random hardware failures need to be addressed.

Safety analyses should be carried out in order to systematically identify the causes of failures and the effects of faults. This is done with the goal of securing the specification of safety requirements, safety mechanisms and design.

System integration and Test (Clause 4.7)

We now come to integration and testing, based on the results of hardware and software development.

What follows now is closely related to Automotive SPICE, but from the perspective of ISO 26262, so it refers specifically to functional safety.

During integration and testing, it’s easy to miss relevant test goals, despite much effort and high costs. Often, some aspects are tested multiple times by different test groups, while on the other hand, without proper coordination, important constellations are not even tested at all. This is why functional safety has to be approached systematically. A strategy must be specified for coordinating test objectives and how tests are organised.

Test cases have to be developed systematically according to certain methods. ISO 26262 describes what is necessary for integrating and testing systems on three levels. First, on the hardware-software integration level, second on the system level, and third on the vehicle level. The safety standard specifies that performance, effectiveness and robustness must be demonstrated. Overall, evidence must be provided that safety requirements are being met on each respective level.

Safety validation (Clause 4.8)

The safety validation focuses on the question of whether implemented safety measures are adequate for the intended use of the vehicles. For this purpose, the installed systems are subjected to long-term tests under real-life conditions, for example. Do the systems behave as expected? Can drivers cope with how the system reacts to errors? Do the different vehicle configurations work? Summer and winter tests are used here. Overall, evidence must be provided here that the safety goals have been reached and that the item is functionally safe.

Development results must be systematically integrated and tested on several levels, from hardware-software integration to the entire vehicle, in order to demonstrate the fulfilment of safety requirements and safety goals.

SINCE 2008

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!

700+ PROJECTS

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!

+100 SPECIALISTS

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!

18 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!

+250 YEARS

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!

Classic manual

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!

Summary

The section above was a walk-through system-level development from a functional safety perspective according to ISO 26262.

Let me summarise the 5 key lessons.

  • Safety activities need to be coordinated at a system level.
  • Functional safety requirements are detailed into technical safety requirements so that they can be implemented with the system architecture to be developed in parallel.
  • Systematic failures and random hardware failures need to be addressed.
  • Safety analyses should be carried out in order to systematically identify the causes of failures and the effects of faults. This is done with the aim of securing the specification of safety requirements, safety mechanisms and design.
  • Development results must be systematically integrated and tested on several levels, from hardware-software integration to the entire vehicle, in order to demonstrate the fulfilment of safety requirements and safety goals.
WE CAN SUPPORT YOU WITH…
  • 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

Download Whitepaper