Software is the most critical part of any mechatronic automotive systems. We can’t talk about any product safety without ensuring software safety and software safety analysis is the only way to ensure safety on software level which is executed according to ISO26262-6:2018 Figure E.1 and a checklist is vital for ensuring the quality of analysis.
But why do we need it?
The Reason Behind
It is obvious that all software errors are systematic and many of them can violate safety goals of any safety critical systems and we want to identify unreasonable risks in the software. Is software well designed and implemented in order to cover all functional safety requirements? Does software consider all mechanisms, which are specified in the technical safety concept? Questions can be derived limitless. For sure, every company, that has a vision to develop and manufacture safety critical automotive systems, should have a safety culture and safety culture is obtained by functional safety process in the company. Checklists are required for ensuring any safety activities that’s why I would like to share you some very helpful criteria, that can be used in the checklist of software safety analysis.
Checklist
- Is there any missing feature in the Technical Safety Concept document?
- Was safety plan updated according to the updates from safety analysis?
- Was freedom of interference analyzed? Which mechanisms are implemented for providing it?
- Was software design with its all software components, functions, interfaces, parameters and partitions reviewed for weaknesses and critical functionalities?
- Which ISO26262 methods were selected? Were rationals documented?
- Are software requirements covering all safety mechanisms? Are there any missing errors or failures or safety mechanisms for software?
- Were all safety mechanisms reviewed and documented well?
- Was a confirmation review executed?
- Are there any unresolved review findings?
- Are all possible errors and all related detailed information such as error results, system reaction, and etc. analyzed and defined?
- Was FMEA conducted?
- Was FTA conducted?
- Were all possible risks checked and documented?
- Were static and dynamic software architecture documents prepared? Were requirements allocated to the design elements?
- Is it needed to implement SW partioning? If yes, how?
Result
Questions of checklist for software safety analysis can be reproduced. Goal is clear: Eliminate or mitigate all unreasonable risks on the software level and provide safety culture in your organisation.
As Mechatnom, we are the most experienced company on functional safety according to ISO26262 in Turkey. For your queries, contact with our experts now!
