Myth 1: No Safety was implemented before ISO 26262
Fact: Automotive Systems have always had Safety measures and mechanisms in place
Cars have been around for a century and ISO26262 for not even a decade!
Cars have always had several safety features such as brakes, airbag, seat belts, tire pressure monitoring etc. But its not that just these features were implemented and nothing additional was done for Safety before the standard was published. Way back in the 1960s, Federal Motor Vehicle Safety and Regulatory standards such as FMVSS were introduced. This standard and its equivalents specified rules to avoid crashes, and contain impact during a crash. Additionally, Independent organizations like IIHS in the US evaluated several aspects of safety such as crashworthiness and crash avoidance and gave ratings to promote safety considerations in cars. These led to specifying requirements for Safety for components, System and design features.
Automakers have always been interested in the topic of Safety. If a Safety related defect reached the road, the traffic safety administration bodies could compel the automaker to recall the cars, and this could cause losses of several millions of dollars to them. As important as Safety is the Availability and Reliability of the System. The System not only needs to be safe, but it also has to respond correctly and in a timely manner.
Let's take few examples of Safety measures that have existed for a long long time now.
Most Automakers and Tier 1/2 Companies have defined and followed Internal quality processes that also include several safety measures.
Many of the Japanese and European OEMs have implemented self checks for specific features or Hardware of the ECU. For e.g., In Instrument clusters, a self test to turn on all telltales at Ignition ON was implemented to ensure that all the telltales are functioning correctly.
Critical Warning Telltales indicated on Instrument Clusters were HW monitored (to detect the actual status of the telltale) and failure of the telltale was reported on CAN or via Diagnostic error codes. Similarly, in some systems, audio output via loud speakers were also verified.
Self tests for Memory were implemented to detect random Hardware faults so as to ensure that the Memory contents are retained correctly during the life cycle of the product. For e.g., CRC mechanisms were implemented for Read-only Memory and ECC Mechanisms provided by the Microcontrollers was used.
Timeout Monitoring was implemented for Vehicle communication. CAN Messages were timeout monitored to ensure that the data exchange between ECUs worked correctly, and a failure of the ECU could be detected and fixed immediately.
Watchdog mechanisms using an Internal or External Watchdog were used to recover from a Stuck-at SW, Stuck-at-HW peripheral or an incorrectly functioning CPU.
State-of-the-Art Software Architectures have implemented Cyclic tasks in order to refresh/recover output through repetition.
And there are so many more such examples to quote.
So, what has changed due to ISO26262 ?
1. The Standard has now given everyone (OEMs, Tier1/2/3, Microcontroller vendors) a (uniform) language to speak.
Image credits: https://www.pixabay.com
By language, we refer to the standard terms used in the functional safety context. Part 1 contains a glossary of these terms.
Lets take some examples.
a. What may have existed as a Safety related feature before, shall now be called as a "Safety Goal", if the "Hazard and Risk Analysis" also arrives at the same conclusion.
b. Requirements of the safety-relevant feature shall now be called "Functional Safety Requirements".
c. "What" should be done to prevent/detect a misbehavior or the Safety feature shall now be called "Safety Measures"
In addition, the Standard may also have led to the result that the OEM identifies new Safety goals which it did not think of as Safety relevant before.
2. The Standard has given a baseline against which we could evaluate whether the mechanisms/measures that we are taking are sufficient/too less/much more than required.
Image credits: https://www.pixabay.com
The Standard tells us what methods are mandatory, optional, or not required for a specific ASIL level and what is the extent of diagnostic coverage provided by different mechanisms. With this as a basis, it can be ensured that all the needed aspects for the required ASIL level are implemented while simultaneously ensuring that the system is not over-engineered.