Everyone who has been a part of an automotive project ideation and product development understands how critical project planning is.
Based on experiences in software development projects, a product development team may opt for various different approaches of SDLC.
One of such proven approaches is Plan-Do-Check-Act, a general practice followed during project planning, especially in compliance verification scenario.
- PLAN– Development Interface Agreement, Safety Plans
- DO– Concept documents, analysis documents, software codes
- CHECK– any form of validation like MISRA C and other audits,
- ACT– on preventive actions based on the derivations from Check stage.
With ISO 26262 coming into the picture, one more dimension called safety planning has become a critical part of such project management planning (PLAN-Do-Check-Act). ISO 26262 mandates that the organization that wishes to implement functional safety in automotive software development, needs to follow a well-defined safety culture.
In order to implement this safety culture during the safety lifecycle of the automotive software, some safety activities have to be planned and executed.
The importance of the safety planning can be gauged from the fact that the entire Part 2 of the ISO 26262 guidelines document has been dedicated to the functional safety management and the Aspects that Need to go into the Safety Plan Document.
Let’s dig deeper!
What Goes into ISO 26262 Recommended Functional Safety Plan Creation and Execution?
Safety planning management is concerned with the execution as well as the documentation of each and every safety related activity. We will discuss these activities in detail and see how are they executed and documented.
- Organization Structure in Functional Safety Planning
- Project Roles & Responsibilities
Part 2- Section 6 of ISO 26262 documents recommends that a project manager should be appointed at the initiation of a functional safety project, that has the mandate of achieving specific safety goals (as per the ASIL definitions).In addition to the project manager, a safety manager also needs to be appointed who will be responsible for following activities related to safety planning and coordination:
- Delegation of task based on skill set, competence, and qualification
- Maintenance of the safety plan throughout the safety lifecycle
- Monitoring the progress of all the automotive functional safety activities
- Project Resources at Work
In addition to the human resources that we discussed in the above section, software tools, databases, templates etc. are also required to achieve functional safety goals.The organization has to provide all such resources and it is the role of the safety manager to ensure that human resource gets access to them.
- Project Safety Lifecycle as Recommended by ISO 26262
- Safety case Creation
In the process of developing fail-safe automotive Electric and Electronic (E&E) systems, it is necessary to provide an evidence-backed assurance. This assurance comes from the output of the safety lifecycle that is derived from the work products (documents, design and analysis artefacts) prepared during the lifecycle.Safety case is the argument that provides the assurance that safety requirements for a system have been implemented at the vehicle level (called an item in ISO 26262 terminology). This argument is not just a simple derivation from the work products. It is in fact, a justification of why and how the available pieces of evidence have achieved the desired level of functional safety (ASIL).
- Work Products Creation
During the course of ISO 26262 recommended safety planning, several documents are created at different stages of safety lifecycle. Organization specific rules and processes, safety plan, safety case, functional safety assessment plan and confirmation measure reports are some of the work products that are generated during the safety planning process.These work products act like evidences that are required to substantiate that safety planning, for the automotive product development, has been performed according to the guidelines laid down by ISO 26262.
- Development Interface Agreement (DIA)
- Planned Safety Activities
- Automotive Functional Safety Techniques and Measures to Achieve Applicable ASIL
- Confirmation Measures/Review is another table that is an integral part of safety planning. Again, it can be a part of DIA or be kept separate. Different service providers follow different approach which entirely depends on their understanding and requirement.
- ISO 26262 Mandated Safety Audits & Assessments
Achieving functional safety in the automotive software development needs all the stakeholders to work towards this common goal. The interaction among the project team members needs to be defined in the safety planning activity sheet.
Aspects such as role definition, who interacts with whom, who escalates to whom etc. are required to be mentioned clearly in this section of the safety planning activity sheet.
ISO 26262 document provides a product lifecycle diagram that needs to be referred to while creating the safety plan. One may not use the full diagram in every project as each project may have different scope.
For instance, concept development and hardware design may not be the part of the project. Hence, we need to mark those areas that come under the scope of the particular project.
DIA is an elaborate sheet that depicts all the work products for the service provider, OEM and the vendor. It is easy to understand it by considering three entities as the stakeholders of the project, as mentioned before- OEM, Vendor and Service provider.
The table will have all the work products that need to be created. The entity that is responsible for it will be marked as ‘R’. The one who will support it will be marked as ‘S’. The entity that needs to be informed about a particular work product will be marked as ‘I’ and finally the approving entity will be marked as ‘A’.
The Table below will make the interface agreement more clear to understand:
As there is an interfacing done between the entities in the course of development, the table is named- Development Interface Agreement (DIA).
Development Interface Agreement is a part of safety plan activity. From the documentation point of view, DIA can be kept separate or together with safety plan doc.
It is a breakdown of all the activities to be done in the project. This table will cover all the required parts of the ISO 26262- from development activity of the functional requirement to the safety requirements. Any kind of additional reports and analysis that needs to be created in sync with safety requirements will also be listed here.
Development activities sheet and safety activity sheet can be combined or can be kept separate. However, from the activity perspective, both of them will be carried out simultaneously.
The analysis of software and hardware required in the project needs due diligence. If you look at part 6 of the ISO 26262 documents, several tables are provided that shows the methods and techniques for hardware and software analysis. The method to be chosen for this analysis is also decided based according to these tables. The following is one such table.
While doing safety planning management, the designated user will include the methods and techniques that have been chosen for the projects. Talking specifically, these methods will depend on the topic to be covered, for eg. modeling and coding guidelines.
The ISO 26262 guideline suggests that which method needs to be implemented for the desired ASIL The procedure to achieve the ASIL also has to be mentioned in its separate column. If for some reason, some methods are skipped, the justification also needs to be given as remarks.
The table below will make things clear:
This section is essentially for the review of various work products like test cases, HARA, FIT/Gap analysis, FME (Failure Mode & Effects) Analysis, safety plan, qualification of the components etc. The confirmation can be done by the service providers themselves, certifying agencies or the consultants.
The frequency of audits by internal safety assessment team can be decided by the safety manager or the project manager. The assessment can be done by internal teams but audit is usually carried out by external agencies, especially when certification is required.
The Final Thoughts
Functional Safety compliance is different from other QAs like CMMI etc. It deals with very specific functional area and requires certain skills and qualifications. Moreover, achieving functional safety in automotive software development is evidence based. These are some of the reasons why safety planning becomes a crucial part of ISO 26262 compliance.
The blog touches upon all major aspects of safety planning management as recommended by Part-2 of ISO 26262 guideline. Look for this space for more such informative blogs on ISO 26262 and Functional Safety.
