The first step in any journey is often the most difficult to take. Not only does it require the will and energy to take the step, but the direction in which that step is taken has first to be decided upon.
It is no different with the systems engineering necessary behind any ADAS feature. You may have done the white boarding and decided which feature(s) to implement, and you may even understand the meaning and implications lying behind the “V Model”, but do you know how to approach the engineering task at hand in a robust and functionally safe manner, and even more importantly, do you know what it means for your design to be functionally safe?
Starting with the “Item Definition”, the ISO 26262 standard seeks to describe Functional Safety, whilst providing the glue by which the design components of the “Item” are bound together. Inherently, as per the intention of the ISO 26262 standard, the “Item Definition” in turn gives the system designer the framework in which the Functional Safety or System Safety of the “Item” can be understood and subsequently implemented to the required standard.
Over the last 40 years, the complexity of technology has increased at an astonishing rate. It seems only recently that music was recorded on black plastic plates called vinyl and purchased in buildings called record shops, VT220 terminals adorned the desks of most university labs and mobile phones the size and weight of house bricks.
The impact of this technological bloom can be seen first-hand in the automotive industry and in the “System of Systems” that the automobile has become. As a result, it is no longer possible to view automotive system safety from the holistic approach of IEC 61508 and the perspective of “Equipment Under Control” (EUC). It is simply not enough to build a car and then give the driver a crash helmet and hope for the best.
Over the last 40 years, the complexity of technology has increased at an astonishing rate. It seems only recently that music was recorded on black plastic plates called vinyl and purchased in buildings called record shops, VT220 terminals adorned the desks of most university labs and mobile phones the size and weight of house bricks.
The impact of this technological bloom can be seen first-hand in the automotive industry and in the “System of Systems” that the automobile has become. As a result, it is no longer possible to view automotive system safety from the holistic approach of IEC 61508 and the perspective of “Equipment Under Control” (EUC). It is simply not enough to build a car and then give the driver a crash helmet and hope for the best.
The ISO 26262 standard attempts to bridge the gap between the limitations of and the needs of the automotive industry, and aims to aid the automotive system designer to explore and develop the following for “safety-related systems that include one or more electrical and/or electronic systems and that are installed in series production passengers cars with a maximum gross vehicle mass up to 3,500kg”.
To achieve this bridging, ISO 26262:2011 comprises 10 parts
Vocabulary
Covers the definitions of all used terminology and acronyms.
Management of functional safety
Covers the organisational level safety management before and after production.
Concept phase
Covers the kick off phase of ISO 26262, covering the Item Definition, Initiation of the safety life cycle, Hazard analysis subsequent risk assessment and the functional safety concept.
Product development at the system level
Covers the initiation of the system level product development, the introduction of the safety requirements, their subsequent design, associated systems integration, validation and guidelines for management of the “Item’s” ultimate release.
Product development at the hardware level
Covers the initiation of the hardware development, introduction of the safety requirements and how to implement accordingly, how to evaluate the hardware architecture against the requirements for fault handling hardware metrics, evaluation of random hardware failures and hardware integration.
Product development at the software level
Covers the initiation of the software development, introducing the safety requirements and how to implement accordingly, test and configure the resultant software.
Production and operation
Covers the need for processes and the monitoring of those processes during production and aftermarket, for safety related “Items”.
Supporting processes
Covers key management techniques including tool usage, RASIC management, configuration management and system re-use.
ASIL-orientated and safety-orientated analysis
Covers the mechanisms of ASIL decomposition, coexistence of elements, dependent failures and final safety analysis.
Guidelines on ISO 26262
Covers all that has gone before with reasoning behind the core concepts.
The ISO 26262 standard should be considered, not as a necessary evil, but as an essential guide through a veritable jungle of development pitfalls, and when understood should take its place as a major weapon in your systems engineering capabilities arsenal.