Safety first and second

The automotive industry is only just starting to come to terms with the ISO26262 functional safety standard, and many car makers and their suppliers are still unsure of how to ensure compliance. Nevertheless, work has already started on the second edition of the standard and at the recent Fifth International ISO26262 Conference in Berlin delegates were almost queuing up to say what they wanted included or at least just gripe about what they saw wrong with the current standard.

The areas in which there are likely to be changes were laid out by Delphi’s Head of Functional Safety, and a member of the ISO26262 International Committee, Dave Higham. But first he reminded everyone of why the standard was so important: “There were 1.3 million deaths on the road in 2010 and that will rise to 1.9 million by 2020 if no action is taken,” he said. “But the number of fatalities is dropping and the drops match the introduction of technologies, so technology is playing its part.” He pointed out that Volvo had already set itself a target of zero fatalities in its new vehicles by 2020. “To realise that goal, we are going to have to rely on technology,” he said, “especially as in the next ten years there will be fifty per cent more vehicles on the road.”

The first edition of ISO26262 was published in 2011 and has prompted the whole supply chain to address functional safety. “The first edition was a catalyst to address safety,” said Higham. “But then we could focus on particular systems. Now we rely on systems of systems and that will increase as we move towards autonomous driving.” And whereas the first edition covered just cars, the new edition will extend that scope to other road vehicles such as motorcycles, lorries and buses.

Second Edition

The three-year project to develop the new edition began in January this year, with the plan for the standard to be published during 2018. There are three subgroups; one for lorries and buses, one for motorcycles and one for semiconductors. More may be added to that before the end of this year.

The motorcycle group has already submitted its Public Available Specification (PAS) and that will go to ballot with the aim for it to be integrated as a separate part of the standard. But there may also be a specific risk categorisation for motorcycles added later. The committee feels there is no need for a separate PAS for lorries and buses but one for semiconductors is under development and this will cover dependent failure analysis, base failure rate, analogue, programmable logic devices, IP and multicore. “The semiconductor group is very active,” said Higham, “with more than 100 participants.”

Another key element of the new edition will be cyber security, especially in the light of autonomous vehicles. The committee will also be working on forming tighter definitions between the different hierarchies in a vehicle from the sensor inputs through to the interface with the driver. The idea is to increase the number of architectural elements that can be reused.

Out of context

However, Higham addressed what has become a general criticism of the idea within the standard, of a “Safety Element out of Context (SEooC)”. This is a device, such as an electronic component, that cannot be qualified to ISO26262 on its own but only as part of a larger system. Many electronic component makers say that this leaves them flapping in the dark when it comes to development, as they do not know what they need to do to make sure their devices are acceptable.

Higham explained that microcontrollers often have many potential applications and configurations: “You can’t put everything on the designers of the microcontrollers,” he said. “The people who use them have to take some responsibility. They have to focus on what it offers their particular application.” Fulvio Tagliabò, Global Functional Safety Manager at Magneti Marelli, went further by saying that SEooCs were necessary because production often has to start before all functional safety aspects have been defined: “Functional safety requirements may change,” he said. “Suppliers define their own external safety requirements that are loosely related to high level functions.”

Other proposals

But that is just one criticism, there are many others, such as a definition of an item within the standard, which some found either confusing or not adequate. One of those is Johannes Schild, Senior Expert for Functional Safety at Bosch Engineering. Currently, an item is defined as a system or array of systems to implement a function at the vehicle level to which ISO26262 is applied. All a little vague. Plus the complete vehicle is not considered an item, therefore there is a need for an item to have interfaces and boundaries with other items in the vehicle, and that, believes Schild, is where the problems lie.

“ISO26262 does not give precise rules regarding the content of an item,” he said. “Currently, there is no common understanding about the item definition.” The consequence of this, he said, was the lack of a common procedure for subsequent development activities. And target failure rates cannot be defined if the item size is not considered.

There also needs to be, he said, definitions of the item boundaries, the lower boundary for input signals and the upper boundary into the system environment. In the past, items were introduced into the system step by step, whether this was an airbag, an engine management system, adaptive cruise control or so on. But increasing vehicle complexity has meant that these all need to interact with other systems. For example, forcing the vehicle to decelerate after an airbag deployment to avoid secondary collisions.

“Item interfaces have to be specified,” said Schild. “We propose the boundaries of classic system products be used as the upper item boundaries.” The advantages of this, he said, were that such systems and products were already well established and that items could be developed more independently of each other. This could also allow ISO26262 compliant items. As to the lower boundary, inputs in sensors can be divided into two groups – private or public. A private input would be used by one controller for one use case, whereas a public one could be used by multiple systems. A typical public signal would be the vehicle velocity, which can be accessed by various systems over the Can bus or Flexray. Schild would like the standard to specify that a private signal should be considered as part of the item to which it is providing information: “More detailed specification of item definition is needed in the second edition to reach a common understanding and consistent safety concepts,” he said.

Jens Christian Lisner, Functional Safety Expert at TÜV Nord, wants dependent failure analysis included in the standard because there was no clear definition of cascade failures, where one failure causes failure in another item which causes failure in a third and so on, compared with common cause failures where a failure will cause multiple failures at the same time.

“The definition is not particularly helpful in the standard,” he said. “Dependent failures are not mentioned directly but evidence for sufficient independence should be made. An analysis of dependent failures could detect between common cause and cascade failures.”

Another attack came from Adam Schnellbach, Functional Safety Expert at Magna Powertrain, who said the standard did not clearly define the requirements for the definition, derivation and validation of the Fault Tolerant Time Interval (FTTI). This is the interval between when a fault occurs before it leads to a hazard, in other words the time the system has to correct a fault before it becomes a problem: “The FTTI has to be longer than the diagnostic test interval plus the fault reaction time,” he said. “The problem is this is different for each fault.”

A good example would be in adaptive cruise control when the radar develops a fault that says the distance to the car in front is longer than it actually is, which could then lead to unwanted and potentially dangerous acceleration. “The time between the fault and the acceleration is the FTTI,” said Schnellbach. “The goal is to stop the fault causing the acceleration. In this, ISO26262 defines the terms fault, error and failure and this can be confusing. Detailed temporal requirements are necessary. We have to face the problem that there is something missing from the standard.”

Adela Béres, System Safety Manager at ThyssenKrupp Presta, was also not happy about the standard’s definition, especially when there could be two independent hardware failures during the time the driver was not in control. “The probability for independent hardware failures are not defined,” she said. “How long before the driver takes back control versus the probability of a second hardware failure within that time.”

And so the debate goes on, and probably will for some time. But in such a fast moving world as automotive, the standards – especially the safety standards – cannot afford to stand still. Autonomous vehicles are here, if only in controlled tests, but that will change and if they are to be accepted than safety standards have to be tight. ISO26262 looks like playing a key role in that, providing it can keep up with the pace.