In the automotive industry, systems which pose a threat to the safe operation for all users of the road if they fail, are those where functional safety occupies a crucial role. At the same time, these systems are developed and maintained with additional care including adherence to international standard for road vehicles – ISO 26262. As a rule, each element of the system must be checked using Functional Safety principles, that is not limited to products, but also to the delivery framework, which the product has been based on. Therefore, for safety-related systems, the safety engineering process itself, must be confirmed.
For this purpose, ISO 26262 introduces Confirmation Measures. These are grouped into 3 categories:
- Confirmation Review
Scope of each concern respectively:
- Work products objectives (Functional Safety Concept, Software Architectural Design)
- Implemented process with regards to process objectives (ISO 26262)
- Item or the characteristics of an element with regards to process objectives (Body Control Module)
This article focuses on Functional Safety Audits. Let’s look at what the Safety Audit is, how to prepare yourself for it, how to conduct one and what to do with the results.
What is a software safety audit?
A Functional Safety Audit is a confirmation measure concerning the functional safety process (ISO 26262) and is, in many ways, similar to the A-SPICE assessment. It’s a formalised examination with all relevant parties involved, in order to identify gaps and anomalies in the established ISO 26262 process.
ISO 26262 audit and Automotive SPICE assessment can be performed in a coordinated manner to avoid duplication of work and any inconsistencies. For this purpose, an extended Process Assessment Model (PAM) is introduced.
Software Safety Audit is an example of an audit that is limited to ISO 26262 chapters connected with software development process.
The following organisation independence is required to conduct an audit according to ISO guidelines:
- Audit, as a process comes with specified scope, agenda, templates, checklist and roles.Automotive Safety Integrity Level (ASIL) determines not only the rigor assigned to development of the system, but also the level of independence required for a particular confirmation measure. Quality Managed (QM) systems are those directed and coordinated with regard to quality. For QM and ASIL A there’s no requirement for performing a functional safety audit.
- ASIL B requires the lowest level of independence (I0) audit to be performed by a person not involved in the creation of any work product, outside of the project.
- ASIL C requires level 2 independence (I2) audit shall be performed by a person independent from the team responsible for creation I.e., not under the same manager.
- ASIL D requires highest level of independence (I3) audit to be performed by a person that is independent from the department responsible for creation. Ideally a separate auditing body from a different company.
Why should you conduct regular safety audits?
There are number of benefits which functional safety audits bring to both the project and the organisation, among which among which the following are the most crucial:
- Safety culture improvement
- Identification of safety development cycle weak points
- Limitation of product liability
An absence of of regular audits will increase the probability that incorrect that incorrect process implementation will impact different projects. As a result, many different product inconsistencies arise in the assessment.
As a rule it must be stated that the Functional Safety Audits are most beneficial when performed in the early stage of the project/product development.
What are the steps for completing a safety audit?
Safety Audits start with determining who is a person responsible for process auditing, with assertion of required independence level.
Then each and every ISO 26262 artifact in the scope of the audit is evaluated from different perspectives including:
ISO 26262 does not provide any template or framework for conducting audits, therefore for this activity, Spyrosoft propose certified Functional Safety Professionals (CFSE) with expertise to perform and supervise auditing process, who assures that the agenda and audit steps are covered.
What to do with the audit results
Once the audit is finished the results will be aggregated into an Audit Report.
Audits results include:
- Points of major non-conformity
- Point of minor non-conformity
- Actions to be taken to improve or resolve identified gaps and anomalies.
These improvement recommendations (in the case of non-compliance) will be addressed and possibly resolved by responsible competencies.
Functional Safety Audit shall be finalised before the production release, it’s advised to perform it as soon as the process according to ISO 26262 is established in the company.
It’s generally advised to involve the auditor as soon as possible.
What is our approach to safety audits at Spyrosoft?
Before the Auditing process starts, the customer is asked to populate a pre-audit checklist, to align both parties before the actual audit.
Pre-Audit checklist is both guidance and a template which enables auditors and all involved parties to assess which elements of ISO 26262 are relevant for auditing activities. It facilitates the creation of agenda to tailor the activities for the specific context of development, including the development of a software application layer in accordance with ISO 26262 requirements and recommendations.
Spyrosoft auditing process includes:
Audit is carried out with an Audit Checklist based on which the final audit report is performed.
About the author