With increased software size and complexity, there is an increased risk in terms of software failures that could lead to unacceptable hazards. Part 6 of ISO26262 standard (International Standard for safety of automotive electronics) provides appropriate requirements and processes to develop automotive software acceptably safe. Following ISO26262 standard is almost mandatory in every leading company.
The topic of the meetup is to introduce the ISO26262 standard and briefly address the following questions:
1. How to develop automotive software according to ISO26262?
2. What is safety analysis and how to use it in software?
3. How to manage software according to requirements from standard?
4. What are the other constraints from ISO26262 towards software development and testing?
Speaker:
Chaitanya Raju is currently consulting across safety critical automotive systems and software. He has a master's in automotive embedded systems and experience of around 10 years in the automotive domain. As a safety practitioner he worked at Volvo Trucks (GTT), NEVS, CEVT, Hyundai Mobis and currently working in Volvo Cars. Chaitanya trained function owners, software developers and project managers in ISO26262.
5. Automotive Design &
Engineering
— AFRY has more than 40 different automotive
clients, mainly in Sweden, Brazil, UK, and
China
— AFRY is today running more than 20
automotive client satellites
— EE & Embedded Systems
5 AUTOMOTIVE SOFTWARE SAFETY & ISO26262
2021-04-21 |
6. AFRY Embedded Systems
Agile teams
Component and system in-house development
Modeling of systems and functions
Functional development, algorithm and calibration
Test methods development
HIL/MIL/SIL
AI / Machine learning
System Safety / ISO26262 / Cyber Security
EMC and Environmental
Data Analytics
6 AUTOMOTIVE SOFTWARE SAFETY & ISO26262
2021-04-21 |
7. Today’s speaker –
Chaitanya Raju
— 10+ years of experience
— Software & System Safety Engineer
— Education: MSc Intelligent Transportation Systems
— Has been training customer POs/SW-
developers/SM/PM in SW safety
— Likes MTB Trips and playing with his son ☺
7 AUTOMOTIVE SOFTWARE SAFETY & ISO26262
2021-04-21 |
8. 8
AGENDA
• Introduction & Importance of Software Safety
• Introduction to ISO26262, Safety Lifecycle, ASIL
Questions – 5 minutes
• How to develop automotive software according to ISO26262?
• What is safety analysis and how to use it in software?
• How to manage software according to requirements from standard?
• What are the other constraints from ISO26262 towards software
development and testing?
Questions & Discussion
8 2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
9. 9
Introduction to Software Safety
• Ensure sate of art approach for development of safety critical
software
• How do we categorize Safety critical software from normal?
• Safety-critical software includes hazardous software (which
can directly contribute to, or control a hazard).
• Controls or monitors hazardous or safety-critical
hardware or software
• Provide information to safety critical software
• Software that resides with safety critical SW in same SOC
or Physical Platform
• ISO26262, Part 6 have clauses for developing safety critical
software
• Main Objectives:
• To ensure a suitable and consistent software
development process; and
• To ensure a suitable software development
environment.
9 2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
13. 13
Number of Software based Recalls Source: NHTSA
Database
https://sibros.medium.com/the-current-state-of-automotive-software-related-recalls-ef5ca95a88e2
2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
14. 14
Number of vehicles affected due to SW: NHTSA Database
https://sibros.medium.com/the-current-state-of-automotive-software-related-recalls-ef5ca95a88e2
2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
15. 15
ISO26262 Scope
• ISO 26262 is the adaptation of IEC 61508 to comply
with needs specific to the application sector of E/E
systems within road vehicles
• ISO 26262 states requirements on
• Management, culture, processes
• Product development, verification and validation
• Supplier relationship
• Documentation, change management,
configuration management
• Production, service, field monitoring, tools, etc.
• ISO 26262 applies to:
• Systems with safety related functions
• Realized in E/E systems (partly or completely)
• Series production vehicles
• Passenger cars
• Trucks, Buses etc.
• Motorcycles
• Not Applicable for heavy machinery
15 2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
20. 20
How to develop Software according to ISO26262?
• Comply to Clauses in ISO26262 and Show evidence, build
Safety case
• Clauses?
• Requirements to satisfy for SW development & testing
• Actions:
• Plan to Satisfy Clauses from ISO26262 standard
• Develop Software Design
• Perform Safety Analysis
• Develop Software
• Verify Software Design & SW
• Use qualified tools for all actions
• Right Competence and safety mindset for reliable software
• Traceability is Key for success
20
SOC [QM]
App. SW
Basic SW[QM]
Comp A QM Comp B QM
SOC [ASIL B]
App. SW
Basic SW
Comp A
[ASIL B]
Comp B
[ASIL B]
WDG
[ASIL B]
PFM
2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
21. Example of clause:
21
21 2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
— “++” indicates that the method is highly recommended for the identified ASIL;
— “+” indicates that the method is recommended for the identified ASIL; and
— “o” indicates that the method has no recommendation for or against its usage for the
identified ASIL.
22. Example of clause:
22
22 2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
— “++” indicates that the method is highly recommended for the identified ASIL;
— “+” indicates that the method is recommended for the identified ASIL; and
— “o” indicates that the method has no recommendation for or against its usage for the
identified ASIL.
23. Example of clause:
23
23 2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
— “++” indicates that the method is highly recommended for the identified ASIL;
— “+” indicates that the method is recommended for the identified ASIL; and
— “o” indicates that the method has no recommendation for or against its usage for the
identified ASIL.
24. Error Detection Techniques:
• Range check: Out of Range data fault
• Monitoring if input/output is in range or out of range
• Plausibility Check: Not Valid Decision Faults
• Monitoring important signals
• Ex: vehicle speed 0 to 100kmph in 2 seconds
• Detection of Data error:Data error in Variable
• Individual data error monitoring with static values
• External monitoring mechanism: Execution Faults
• Watch dog reset for a program
• Control Flow Monitoring: Out of sequence fault
• Task monitoring, Inserting check points for sequence
• Redundancy with or with out voting
How to select type of SM in Software during Design?
Error Handling Techniques:
• Static Recovery Mechanism
• Reset HW or Re- execute SW
• Deactivation and reach safe state
• Gracefull Degradation
• Degrade to limit important functionalities instead of all
functionalities
• Independent parallel redundancy
• Redundancy of SW components
• Correcting codes of data
• Including error correcting codes, Masking error with default
values etc
Techniques in software for safety – Safety Mechanisms
24
24 2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
25. Safety Analysis
• Identify Component Failures and Effects on system
• Common Techniques:
• FTA
• FMEA
• For Software:
• Choose right level for software to not repeat for every
small change(in agile context)
• Static Analysis (MISRA C Guidelines or MAAB for models)
• Software Error Analysis
• Interfaces Analysis
• Faults of interfaces
• Mitigation of Faults(Detection and Handling)
• End to End Protection (ASIL A – D)
• Combine FMEA(Extend from system) and SWEA
25
25 2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
FTA
FMEA
26. Configuration Management
• Impact Analysis during change management
• List of affected ASIL SW components
• Traceability for every safety requirement
• Document Management for released version of software
• Requirements, Design
• Peer Review Reports
• Verification Reports
• Follow ASPICE for Software configuration management
26
26 2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
27. ISO26262 Vs ASPICE
ASPICE: Automotive Software Process Improvement and Capability determination
27
27 2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262
28. Other Constraints
• Software Component Qualification
• Software Tool Qualification
• Agile Vs ASPICE
• HIL Testing and Vehicle Test Logs – ASIL C & D
• Build Safety Case
• to provide the argument for the achievement
of functional safety
• Dynamic Safety Case is suggested
• Handling Software for different vehicle variants
• Create Base version with Proper management
• Verify Software functionality with FSR’s
• Store Reports
Safety Case Impact Assessment in Automotive Software Systems: An Improved Model -Based Approach
28
28 2021-04-21 | AUTOMOTIVE SOFTWARE SAFETY & ISO26262