File preview
Systems and Software Engineering Standards for the Automotive Domain
Joseph D’Ambrosio
Lab Group Manager GM Research Laboratories
ISO 26262 Technical Expert
Outline
ISO 26262
● Certification & Initial Feedback
MISRA C Mathworks Automotive Advisory Board Guidelines OMG Request for Information
What is ISO 26262?
Adaptation of IEC 61508 to comply with the specific needs of E/E systems within road vehicles
Specifies a functional safety life-cycle for automotive products Significant modifications vs. IEC 61508
ISO 26262 Road Vehicles Functional Safety
Applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic, and software components Is a standard, not a regulation
Broad industry participation in its development Publication Date: Nov. 2011
Key concept: Automotive Safety Integrity Level (ASIL)
Specify risk associated with a potential hazard Dictate development requirements to achieve required integrity with respect to systematic and random hardware failures
ISO 26262 Overview
1. Vocabulary 2. Management of functional safety
2-5 Overall safety management 2-6 Safety management during item development 2-7 Safety management after release for production
3. Concept phase
3-5 Item definition
3-6 Initiation of the safety lifecycle 3-7 Hazard analysis and risk assessment
4. Product development: system level
4-5 Initiation of product development at the system level 4-6 Specification of the technical safety requirements 4-7 System design 4-11 Release for production 4-10 Functional safety assessment 4-9 Safety validation 4-8 Item integration and testing
7. Production & Operation
7-5 Production 7-6 Operation, service and decommissioning
3-8 Functional safety concept
5. Product development:
hardware level
5-5 Initiation of product development at the hardware level 5-6 Specification of hardware safety requirements 5-7 Hardware design 5-8 Hardware architectural metrics 5-9 Evaluation of violation of the safety goal due to random HW failures 5-10 Hardware integration and testing
6. Product development:
software level
6-5 Initiation of product development at the software level 6-6 Specification of software safety requirements 6-7 Software architectural design 6-8 Software unit design and implementation 6-9 Software unit testing
6-10 Software integration and testing
6-11 Software verification
8. Supporting processes
8-5 8-6 8-7 8-8 8-9 Interfaces within distributed developments Overall management of safety requirements Configuration management Change management Verification 8-10 8-11 8-12 8-13 8-14 Documentation Qualification of software tools Qualification of software components Qualification of hardware components Proven in use argument
9. ASIL-oriented and safety-oriented analyses
9-5 Requirements decomposition with respect to ASIL tailoring 9-6 Criteria for coexistence of 9-7 Analysis of dependent failures 9-8 Safety analyses
10. (Informative) Guidelines on ISO 26262
Source ISO/FDIS 26262
Core processes
“Certification” Observations
“Certification” is not required by standard, however …
● Confirmation measures, including level of independence
Two certification/confirmation perspectives
● Integrated vehicle systems sold by automotive manufacturer
– No current government regulations requiring the standard – Self confirmation: internal or external
● Systems delivered by suppliers to manufacturer
– Manufacturer must obtain confirmation of supplier systems
– Approaches: manufacture internal, external; supplier internal, external
– ISO 26262 distributed interface agreement applies
Certification of products vs. process
ISO 26262 Certification Support
Large ecosystem developing around ISO 26262
● Certification, consulting, tools …
Volpe ISO 26262 Report: Industry’s Views— Pro’s
ISO 26262 is well regarded by industry and is seen as necessary. Many companies have at least tried it on pilot projects. GM has used it to ensure Volt’s battery functional safety. Industry recognizes it is valuable to have safety standard to address the growing complexity of Cyber-Physical Systems. No discrepancy with mature product development process, and it is easy to implement. Aligns well with the model-based development process.
Source : Qi Van Eikema Hommes, “Assessment of the ISO 26262 Draft Road Vehicles - Functional Safety”, http://www.sae.org/events/gim/presentations/2012/qi_volpe.pdf 7
Volpe ISO 26262 Report: Industry’s Views-Cons
Amount of documentation efforts Not convinced that the software development methods are sufficient to guarantee safety Since the standard is about the entire product life cycle, the effect of the standard will take some time to show. The concept phase is easy to implement, but there is difficulty to integrate a pilot project into the rest of the system that was not developed based on the standard. ASIL classification harmonization “Proven in use” argument is not useful
● ● Takes too long to collect sufficient data The definition in the standard makes it a step that will never be visited The large number of software tools used in development Comment: software tools are software. How will one quantify the probability of software making mistakes?
Qualification of software tools
● ●
Source : Qi Van Eikema Hommes, “Assessment of the ISO 26262 Draft Road Vehicles - Functional Safety”, http://www.sae.org/events/gim/presentations/2012/qi_volpe.pdf 8
1. 2.
Consider only using severity for ASIL assessment Government may want to consider playing a role in ASIL standardization
●
Volpe Report: Summary of Recommendations
However, the ASIL assessment must depend on the context and the design configuration of the system.
3. 4.
The standard may want to add a section to emphasize hazard elimination before detection and control Research activities may want to investigate the effectiveness of system theory based hazard causal analysis in automotive complex cyber-physical systems
● E.g. STAMP model and STPA.
5.
Fundamental research is needed for the safety of complex software-intensive systems today, including those in the current automobiles:
● ● The effect of complexity on safety is not well quantified The effects of software engineering best practices on safety may be insufficient to ensure safety. New and different approaches may need to be developed.
6. 7.
Government may want to play a role in certifying software tools used for the development of safety critical systems Government may want to consider regulating the safety of E/E systems after the vehicle is sold.
Source : Qi Van Eikema Hommes, “Assessment of the ISO 26262 Draft Road Vehicles - Functional Safety”, http://www.sae.org/events/gim/presentations/2012/qi_volpe.pdf 9
Outline
ISO 26262
● Certification & Initial Feedback
MISRA C Mathworks Automotive Advisory Board Guidelines OMG Request for Information
MISRA
MISRA C EXAMPLE
MISRA C:2004 (MISRA C2)
● “Guidelines for the use of the C language in critical systems” ● Restricted subset of C
•Rule 34 (required) •The operands of a logical && or || shall be primary expressions Invalid if ( x= = 0 && ishigh ) Valid if ( ( x == 0 ) && ishigh ) Primary expressions are constants, a single identifier such as ishigh, or a parenthesized expression. Parentheses are important for readability and ensuring that the behavior is what the programmer intends.
MISRA AC GMG / SLSF
● Modeling design and style guidelines
Source: Electronic Design http://electronicdesign.com/article/embedded-software/misra-c-safer-is-better2824 http://www.misra.org.uk/misra-c/Activities/MISRAC/tabid/160/Default.aspx
Checking MISRA C:2004
Static Code Analysis
Outline
ISO 26262
● Certification & Initial Feedback
MISRA C Mathworks Automotive Advisory Board Guidelines OMG Request for Information
Mathworks Modeling Guidelines
Mathworks tools broadly used in automotive industry MAAB – Mathworks Automotive Association Board
● Coordinate tool request and usage
“Control Algorithm Modeling Guidelines Using Matlab, Simulink & Stateflow” Mathworks verification tools can check compliance
Source: http://www.mathworks.com/automotive/standards/maab.html
Outline
ISO 26262
● Certification & Initial Feedback
MISRA C Mathworks Automotive Advisory Board Guidelines OMG Request for Information
OMG Dependability Request for Information
OMG request for information for dependability standard
● Due 5/20/2012
References ISO 26262 Key elements to address
● Rapid development
– Motivated by “unknown factors”
● Model-based development
– Controls & SW
● Assurance cases Planning on 18 month development cycle
Source: Yutaka Matsuno et. al., “Assuring Dependability of Consumer Devices: GM CONFIDENTIAL -Automobiles, Consumer Robots, Smart Houses, Avionics, etc-” White Paper, 12/15/2011.
GM Consumer Devices: Source: Yutaka Matsuno et. al., “Assuring Dependability ofCONFIDENTIAL -Automobiles, Consumer Robots, Smart Houses, Avionics, etc-” White Paper, 12/15/2011.
Summary
Broadly applied automotive standards
● ISO 26262, MISRA C coding guidelines
ISO 26262 Road Vehicles Functional Safety
Emerging automotive model-based standards & guidelines
● MISRA GMG / SLSF, MAAB ● OMG request for infomation
Joseph D’Ambrosio
Lab Group Manager GM Research Laboratories
ISO 26262 Technical Expert
Outline
ISO 26262
● Certification & Initial Feedback
MISRA C Mathworks Automotive Advisory Board Guidelines OMG Request for Information
What is ISO 26262?
Adaptation of IEC 61508 to comply with the specific needs of E/E systems within road vehicles
Specifies a functional safety life-cycle for automotive products Significant modifications vs. IEC 61508
ISO 26262 Road Vehicles Functional Safety
Applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic, and software components Is a standard, not a regulation
Broad industry participation in its development Publication Date: Nov. 2011
Key concept: Automotive Safety Integrity Level (ASIL)
Specify risk associated with a potential hazard Dictate development requirements to achieve required integrity with respect to systematic and random hardware failures
ISO 26262 Overview
1. Vocabulary 2. Management of functional safety
2-5 Overall safety management 2-6 Safety management during item development 2-7 Safety management after release for production
3. Concept phase
3-5 Item definition
3-6 Initiation of the safety lifecycle 3-7 Hazard analysis and risk assessment
4. Product development: system level
4-5 Initiation of product development at the system level 4-6 Specification of the technical safety requirements 4-7 System design 4-11 Release for production 4-10 Functional safety assessment 4-9 Safety validation 4-8 Item integration and testing
7. Production & Operation
7-5 Production 7-6 Operation, service and decommissioning
3-8 Functional safety concept
5. Product development:
hardware level
5-5 Initiation of product development at the hardware level 5-6 Specification of hardware safety requirements 5-7 Hardware design 5-8 Hardware architectural metrics 5-9 Evaluation of violation of the safety goal due to random HW failures 5-10 Hardware integration and testing
6. Product development:
software level
6-5 Initiation of product development at the software level 6-6 Specification of software safety requirements 6-7 Software architectural design 6-8 Software unit design and implementation 6-9 Software unit testing
6-10 Software integration and testing
6-11 Software verification
8. Supporting processes
8-5 8-6 8-7 8-8 8-9 Interfaces within distributed developments Overall management of safety requirements Configuration management Change management Verification 8-10 8-11 8-12 8-13 8-14 Documentation Qualification of software tools Qualification of software components Qualification of hardware components Proven in use argument
9. ASIL-oriented and safety-oriented analyses
9-5 Requirements decomposition with respect to ASIL tailoring 9-6 Criteria for coexistence of 9-7 Analysis of dependent failures 9-8 Safety analyses
10. (Informative) Guidelines on ISO 26262
Source ISO/FDIS 26262
Core processes
“Certification” Observations
“Certification” is not required by standard, however …
● Confirmation measures, including level of independence
Two certification/confirmation perspectives
● Integrated vehicle systems sold by automotive manufacturer
– No current government regulations requiring the standard – Self confirmation: internal or external
● Systems delivered by suppliers to manufacturer
– Manufacturer must obtain confirmation of supplier systems
– Approaches: manufacture internal, external; supplier internal, external
– ISO 26262 distributed interface agreement applies
Certification of products vs. process
ISO 26262 Certification Support
Large ecosystem developing around ISO 26262
● Certification, consulting, tools …
Volpe ISO 26262 Report: Industry’s Views— Pro’s
ISO 26262 is well regarded by industry and is seen as necessary. Many companies have at least tried it on pilot projects. GM has used it to ensure Volt’s battery functional safety. Industry recognizes it is valuable to have safety standard to address the growing complexity of Cyber-Physical Systems. No discrepancy with mature product development process, and it is easy to implement. Aligns well with the model-based development process.
Source : Qi Van Eikema Hommes, “Assessment of the ISO 26262 Draft Road Vehicles - Functional Safety”, http://www.sae.org/events/gim/presentations/2012/qi_volpe.pdf 7
Volpe ISO 26262 Report: Industry’s Views-Cons
Amount of documentation efforts Not convinced that the software development methods are sufficient to guarantee safety Since the standard is about the entire product life cycle, the effect of the standard will take some time to show. The concept phase is easy to implement, but there is difficulty to integrate a pilot project into the rest of the system that was not developed based on the standard. ASIL classification harmonization “Proven in use” argument is not useful
● ● Takes too long to collect sufficient data The definition in the standard makes it a step that will never be visited The large number of software tools used in development Comment: software tools are software. How will one quantify the probability of software making mistakes?
Qualification of software tools
● ●
Source : Qi Van Eikema Hommes, “Assessment of the ISO 26262 Draft Road Vehicles - Functional Safety”, http://www.sae.org/events/gim/presentations/2012/qi_volpe.pdf 8
1. 2.
Consider only using severity for ASIL assessment Government may want to consider playing a role in ASIL standardization
●
Volpe Report: Summary of Recommendations
However, the ASIL assessment must depend on the context and the design configuration of the system.
3. 4.
The standard may want to add a section to emphasize hazard elimination before detection and control Research activities may want to investigate the effectiveness of system theory based hazard causal analysis in automotive complex cyber-physical systems
● E.g. STAMP model and STPA.
5.
Fundamental research is needed for the safety of complex software-intensive systems today, including those in the current automobiles:
● ● The effect of complexity on safety is not well quantified The effects of software engineering best practices on safety may be insufficient to ensure safety. New and different approaches may need to be developed.
6. 7.
Government may want to play a role in certifying software tools used for the development of safety critical systems Government may want to consider regulating the safety of E/E systems after the vehicle is sold.
Source : Qi Van Eikema Hommes, “Assessment of the ISO 26262 Draft Road Vehicles - Functional Safety”, http://www.sae.org/events/gim/presentations/2012/qi_volpe.pdf 9
Outline
ISO 26262
● Certification & Initial Feedback
MISRA C Mathworks Automotive Advisory Board Guidelines OMG Request for Information
MISRA
MISRA C EXAMPLE
MISRA C:2004 (MISRA C2)
● “Guidelines for the use of the C language in critical systems” ● Restricted subset of C
•Rule 34 (required) •The operands of a logical && or || shall be primary expressions Invalid if ( x= = 0 && ishigh ) Valid if ( ( x == 0 ) && ishigh ) Primary expressions are constants, a single identifier such as ishigh, or a parenthesized expression. Parentheses are important for readability and ensuring that the behavior is what the programmer intends.
MISRA AC GMG / SLSF
● Modeling design and style guidelines
Source: Electronic Design http://electronicdesign.com/article/embedded-software/misra-c-safer-is-better2824 http://www.misra.org.uk/misra-c/Activities/MISRAC/tabid/160/Default.aspx
Checking MISRA C:2004
Static Code Analysis
Outline
ISO 26262
● Certification & Initial Feedback
MISRA C Mathworks Automotive Advisory Board Guidelines OMG Request for Information
Mathworks Modeling Guidelines
Mathworks tools broadly used in automotive industry MAAB – Mathworks Automotive Association Board
● Coordinate tool request and usage
“Control Algorithm Modeling Guidelines Using Matlab, Simulink & Stateflow” Mathworks verification tools can check compliance
Source: http://www.mathworks.com/automotive/standards/maab.html
Outline
ISO 26262
● Certification & Initial Feedback
MISRA C Mathworks Automotive Advisory Board Guidelines OMG Request for Information
OMG Dependability Request for Information
OMG request for information for dependability standard
● Due 5/20/2012
References ISO 26262 Key elements to address
● Rapid development
– Motivated by “unknown factors”
● Model-based development
– Controls & SW
● Assurance cases Planning on 18 month development cycle
Source: Yutaka Matsuno et. al., “Assuring Dependability of Consumer Devices: GM CONFIDENTIAL -Automobiles, Consumer Robots, Smart Houses, Avionics, etc-” White Paper, 12/15/2011.
GM Consumer Devices: Source: Yutaka Matsuno et. al., “Assuring Dependability ofCONFIDENTIAL -Automobiles, Consumer Robots, Smart Houses, Avionics, etc-” White Paper, 12/15/2011.
Summary
Broadly applied automotive standards
● ISO 26262, MISRA C coding guidelines
ISO 26262 Road Vehicles Functional Safety
Emerging automotive model-based standards & guidelines
● MISRA GMG / SLSF, MAAB ● OMG request for infomation