How to breeze through a FuSa assessment

Eventually, the time for the projects to be released for production has come, the development team did all that was planned, every deadline was met, the customer is more than happy and has no objections. Everyone did their job perfectly, everything is in its exact place, all documentation is prepared and each step of each relevant process is followed and documented. There is nothing to fix, there are no gaps identified and the team can move to other exciting activities. 

Sounds a little like a fantasy? That’s because the above situation is…  never the case.  

Increased complexity in the interconnected world also has its impact on the automotive industry. Projects, especially those considered as a system-of-systems, which include not only multiple suppliers to distributed development, but carry challenges in infrastructure, are often difficult to coordinate. Additionally, independent organisational issues e.g. different work culture, multiple locations, different time-zones, etc. often pile up, reaching their pinnacle the closer it is to the deadlines. 

Usually the mark in the calendar with the name of “ISO 26262 Audit”, “Assessment” or “Safety Case Delivery”, “FuSa Release Report” is the trigger that forces the Project and FuSa management team to look closer at the state of FuSa affairs.  

Why is an assessment needed at all? What is the goal of it?

The reason why the assessment, audit, or safety case is required is straightforward. The argument without the proof is hardly an argument, additionally, an argument that is not understood and not clear is also not an argument.

That’s why presenting it in an organised manner, with all its assumptions, limitations and even potential downfalls, is a crucial point. Without reaching an agreement between all the stakeholders about the safety of the product, there is no possibility of understanding the underlying risk. Preparing such arguments connecting all the already existing blocks is more difficult than it sounds at the beginning. 

The analogy to running a marathon stems from the similarity to the famous Ancient Greek run, where there are no stops allowed. You cannot miss any step because reaching the finish line may impact the success of the entire venture. Similarly, FuSa marathon requires running through all the documentation, listing all the potential gaps and eventually fixing them one by one.   

Audit & Assessment process 

This article illustrates the steps in preparing for ISO 26262 Assessment (FuSa assessment). Preparing Audit and Safety Case is not very different and often follows the assessment. 

As an important starting note, please consider that passing an assessment depends on the scope of an assessment. In a lot of cases, as the development area is limited, assessment scope might also be limited, e.g., software development and testing life cycle. 

To pass the assessment you can’t avoid preparing bulletproof, robust, and diligent project documentation. If there is one area that is often neglected and destroyed the project schedules way too many times, it is the documentation. 

How to prepare for FuSa assessment 

“By failing to prepare, you are preparing to fail” – Benjamin Franklin 

Assessment as every battle (even those where an argument is the only weapon) should never happen without preparation. Here I would like to present few typical steps, each with a short example that might sound trivial, but are often an Achilles’ heel in the entire assessment process. Some of the questions you should answer at this stage are as follows.

Functional Safety assessment best practices

Is the assessment agenda known to all involved parties? 

Do we have a specific slot to discuss a given topic? It often happens that the subject experts are not aware that they might need to provide an argument and fail in preparing such.

Are the assessment items assigned to a specific person? 

Are the experts, ideally owners of the given document or another artifact, clearly assigned their responsibility?

Do we have proof of specific activities and is it properly documented? 

For writing embedded software components, usually a strongly typed language with subsets like C or C++ is used. What coding guidelines are used? Is there a proof that it’s used, e.g. static code analysis? 

Is the proof up to date?

Are all the safety-related work products up to date, e.g. safety analysis performed on the initial architecture might not consider safety-related components that were implemented in the latest release?

Is there a proper verification and/or confirmation review record available? 

Are all the work products reviewed using an appropriate review method (technical, walk-through, inspection) and considering a required independence level and technical roles?

Safety analyses for ASIL B projects shall undergo a verification and confirmation review of an independent technical expert.

Is there a “repair plan” for the identified gaps? 

If the gaps have been identified is there an incompleteness record of work products kept track of?

If Software Qualification Report is missing for a specific development tool, how is such a task tracked? Who is responsible for it? What is the deadline?

Closing words 

Your projects release for production depends on assessment results, and if you are not sure where to start preparing for it and how to approach presenting an argument in an organized fashion it might be beneficial to consider a pre-assessment project evaluation. 

Our Spyrosoft Functional Safety team has hands-on experience in preparing and passing assessments from various possible angles and different major OEMs. 

For more info visit our site and contact us.