Part 2 of ISO 26262, Management of Functional Safety, is the critical one for your company to initially embrace, even though 12 parts exist within ISO 26262. Here’s why:
STEP 1: A Safety Culture Is Vital
First and foremost, cultivating a company-wide safety culture is the most important step when establishing the functional safety process within an organization. Management must be fully committed, or implementation will not work; a complete adoption will be amiss. The start truly must be from the top down to be effective and have sustainable positive results.
This commitment may not always be easy, since there could be conflicts between functional safety and either cost or timing, perhaps both. A proper safety culture necessitates the encouragement to stop a project, if, for instance, a safety violation occurs. Likewise, proper authority must be given to those responsible to uphold the safety requirements. This also presumes sufficient resource quantities are allocated to projects, which are adequately trained. Ultimately, the company culture will designate safety as the highest priority.
Note: While safety culture is found within the project-independent framework, it is worth breaking out as its own entity, due to its significance.
Figure 1: Management Objectives
STEP 2: Project-Independent Framework
The safety culture can be significantly impacted, adding unnecessary project risk, without proper communication. While your company may preach it has open communication pathways, as do most, take a hard look for any potential blind spots. For instance, overallocated resources will naturally communicate less.
Likewise, barriers set between functions or departments may create an invisible wall of sorts. These barriers could be indirectly or directly caused by your existing company culture. Regarding an indirect example, company goals, which may be aligned at the top, trickle down to functional or departmental goals, and can become quite polarized. When bonuses are tied to goals, self interest can occur, resulting in communication breakdown. After all, self interest or self preservation is a human trait, so audit down to keep this communication barrier mitigated.
Because the automotive industry and its products have a much greater wireless presence, cybersecurity poses a great risk to not only the product but to maintaining functional safety for the product. Perhaps a cyber issue could violate a safety goal or requirement, or inversely, a safety requirement competes with a cyber requirement.
Communication between these two functions are necessary, which may not have been the case in the past, depending on company structure. Moreover, any department within your organization could require a voice within electrical and electronic (E/E) product development. They may need to have a seat within the project team. Your company would need to align its structure to eliminate this direct barrier.
Virtually all functions within your organization are impacted by functional safety, especially if they will be on project teams. This means most employees will need some level of training, along with a qualification means to determine the training’s effectiveness. Although, the training and resultant skillsets should vary, depending on the roles and responsibilities (R&R).
Competency management becomes essential to match and track the respective skill level to the R&R. A matrix can and should be devised to identify the criteria required, which may include “non-functional safety” skills, such as product domain knowledge, experience launching programs for a particular function, management expertise, and post-launch capability. These examples, if insufficiently experienced, could cause a gap in content or decision making, potentially compromising functional safety compliance.
A safety gap or anomaly (issue hereafter), whether identified above or elsewhere, must be tracked to resolution within a formal process. The safety manager should be involved, and if the product changes, a change management (CM) process is to be followed, from time of identification to a completed resolution. Your organization may utilize its existing quality management system (QMS), but adapt its issue resolution or corrective action process to comply with ISO 26262. It also can engage its CM process, if a change does occur.
To effectively implement functional safety, it is dependent on your company having an existing QMS, which complies with a quality management standard, such as automotive specific IATF 16949, in conjunction with ISO 9001. There is great use for your QMS, since some ratings will yield a ‘QM’ evaluation, determined from the Hazard Analysis and Risk Assessment (HARA).
All of the content just described goes into your development process, categorized as organization-specific rules and processes in ISO 26262 lingo. Beyond these, additional templates and processes can be genericized to establish a baseline for the project-dependent work products and requirements. Depending on the project itself, the entire safety lifecycle may be tailored to fit the need. Your entire process, whether safety or QMS, does not have to be used for each and every project. It depends on the situation.
STEP 3: Project-Dependent Framework
To effectively run a project, there are project-specific requirements to be integrated within the process. Your company may already have a process setup, in which case it may only need adapted for ISO 26262’s guidelines. These extra steps will establish the basis required to execute a functional safety E/E project, whether it be the concept and/or development phases for any of the system, hardware, or software levels.
Before a project can effectively get off the ground, the important step is to ensure the project’s R&R are well defined for all safety-related activities. To prevent project outcome variability, the process should have this built into its structure. Each project role should be well defined.
ISO 26262 discusses in greater detail two critical roles, the project manager (PM) and the safety manager (SM). Your company and its management shall support the PM and give the role, not only project responsibility, but also project authority. Beyond this, the PM shall verify sufficient resources are applied to a project, made easier by having the R&R already in place.
Once the PM is identified, the position is to ensure an SM is in place, to protect the safety activities. The SM does not need to complete all safety activities, but the role is responsible for planning and must ensure the safety activities are completed and stored within the safety case as supporting evidence. Together, these two roles will protect functional safety within the project, the SM having a greater emphasis.
Next, an impact analysis is conducted to determine the best arrangement for the project. It is important to note what part of the development cycle is affected, to determine whether the impact analysis is at item or element level (or both). If in Part 3, the concept phase, the impact analysis will likely be conducted at the item level. If within Parts 4, 5, and/or 6, the system, hardware, software phases, the analysis will likely be at the element level.
Once the impact is known, safety lifecycle tailoring is necessary. There should be rationale behind the tailoring, to maintain compliance. However, the impact analysis will be the start for justification, while the Automotive Safety Integrity Level (ASIL) rating, determined in the HARA will also determine the rigor level. All of this will be modified within what is called the safety plan.
Figure 2: ASIL Increase Due to Autonomous Technology
For an SM, the safety plan is the crucial component to effectively track safety activity progression. Often times, the safety plan takes the form of a timeline, since it must either be referenced within or is even integrated within the project plan itself. As with a project plan, the safety plan is a living document, requiring regular updates.
If the safety plan is the tracking mechanism, the safety case is the evidence for the safety lifecycle. The safety lifecycle is the method to create a safe product and maintain it post development. If an ‘event’ does occur, the safety case should be the documented proof, which explains all the work done within the safety lifecycle. The safety case should demonstrate the effort your company took to develop and produce a safe product.
The safety case is further scrutinized, since ISO 26262 has a built in ‘checks and balances.’ The standard outlines, through confirmation measures, the various checkpoints required along the way, conducting either a confirmation review, assessment, or audit. These are reflections of sorts, a look back at what was just completed, to justify the actions taken, via an independent review. ASILs determine the level of independence. The ultimate question for these audits is whether the project maintained functional safety compliance.
The final determination is whether the product is ready for production, having just completed the development cycle and the various evaluations. Sufficient evidence must be presented from the safety case and once approved, a time stamp, along with a baseline is created for the application. Once complete, the release for production report should be added to the safety case.
STEP 4: Post-Development Activity
Post-development is where your company makes all of its revenue, if a product supplier. This last step contains multiple phases: ‘production, operation, service, and decommissioning’, which is the bulk of the safety lifecycle, at least in time. There is a great deal of effort to ensure a safe product is developed, although the safety mindset should be carried out into post-development supply. A handoff often occurs between the development side of your organization and the manufacturing and service sides. Competent personnel should be designated to ensure functional safety is maintained.
Summary
The industry is undergoing its migration to ISO 26262. While the initial adoption was slow, it is exponentially picking up steam. The content provided outlines the pros for implementing now. The major con is the upfront cost associated, but now that you are informed, the long-term financial benefits should be clear. Remember, it’s all in the long game.
Finally, if you still are not fully convinced on ISO 26262’s true value, look at it this way. Try to imagine an ‘event’ does occur, which severely impacts someone you know, whether a friend, a loved one, or even you. Yes, this scenario may be like a kick to the chest but is the reality for people out there today. A life lost is a life worth saving.
Note: The circumstance described is absolutely one of the hardest ones to face. In fact, the author tears up, just thinking about how significant it truly could be. LHP’s purpose is to save lives through engineering.