One of the best things that has happened in the last few months (After starting Drivvize) is the chance to speak with a lot of companies who are getting started on their safety journey. Apart from being able to work on new technologies, it also gives us a sneak peek into the concerns and problems facing these companies with respect to FuSa implementation. What we have tried here is to consolidate the broad categories of issues faced. We have also tried to look at it from a 10,000 feet view to arrive at solutions that could be applied for most of these issues.
A word of caution: We recognize that every organization is unique and hence there could be some variations to the problems faced. Due to these variations (Ex: Process compliance levels, organizational maturity, organizational structure etc.), some fine tuning or customization of the broader solution will have to be done to get the solution to work.
Common Questions and General Observations and our proposed solutions:
1. We have started working on this particular program at ASIL-X and we are at prototype/A-Sample/B-Sample stage. When should we get started on FuSa activities?
Answer:
In an ideal world, safety activities should start from Request for Information (RFI) or Request for Quote (RFQ) stage. This way, any ASIL related cost - be it purchase of a tool set, ASIL ‘certified’ micro, ASIL ‘certified’ software stack – will be baked into the overall cost of the program. If you missed the bus in the RFI/RFQ stage, it is better to start safety work right at program kick-off. Some of the major risks of starting safety activities late are:
- Missed program timelines or not having ASIL compliance during vehicle launch
- FIT target not met (This could lead to late HW changes)
- Increased cost due to missed ASIL related purchases (and buying ASIL SW components from certain vendors introduces unrealistic delays in programs! You know which vendor we are talking about!)
2. We are finding it difficult to bring in FuSa engineers into the organization. What should we do? (A variation to this question is: Will your team be able to come in and help us achieve safety?)
Answer:
One of the alternatives that we have tried in the past and where we have been fairly successful is recruiting safety engineers from within the organization. Instead of going out to the outside market every time, we tried to bring in Systems or SW engineers who are good in their domain & who have also shown interest in learning FuSa. This has the obvious advantage that they already know the domain in which you are working and they are also familiar with the process within the organization. The flipside is that you might have to mentor/coach them on FuSa concepts. However, this task would become easier if they already showed interest in learning FuSa. Then, it would just become a matter of pointing them in the right direction (Or right articles like ours!) and they should be well on their way.
3. We have always pushed back to the OEM/Tier-1 saying that they should provide the safety goals to us. Is there a possibility that we could develop some of our SW components as ASIL-X without safety goals?
Answer:
The short answer is “Yes”. Companies could develop their SW components as Safety Element out of Context (SEooC) without having a safety goal specified by the OEM. As per Part-10 of the ISO 26262 standard, SEooC could be applied for Systems, HW or SW. If you have used any 3rd party software that was provided as ASIL ‘certified’, the chances are that you have already used a SW SEooC.
General Observations:
4. An awareness of safety and its importance is still in its nascent stage. Even though the awareness has improved a lot compared to 5 years ago, it still is a long journey that is in front of us.
Answer:
Trainings are sure shot ways to bring awareness to an organization. An essential aspect of this is that the trainings should start from the top-level of the organization. Time & time again we have seen that the top management sets the tone for the safety culture in an organization. Without having the support of these folks would mean that we are almost setting up the project and eventually the organization for failure. Once the general safety awareness trainings for the top management is given, we could move on to detailed deep-dive trainings for the people who are going to be directly involved in the development of the product. These deep-dive trainings need to be a judicious mix of technical and process aspects of safety. Apart from the trainings, making available a mentor to guide the team while they navigate FuSa for the first time would be absolutely critical.
5. The myth that safety is just paperwork still percolates and seems a bit deep rooted.
Answer:
We cannot emphasize this enough - Safety is as much about technical solutioning as it is about process compliance. Without the right technical solution to address the safety concern, we are making a product that may be high on availability & reliability but low on safety. Trainings (focusing more on the technical side of safety) are the best way to address this scenario in organizations. Trainings like “How to create a Technical Safety Concept”, “How to perform SW safety analysis” are some of the topics an organization could concentrate on to change the perception about safety being a paperwork exercise.
What we have brought out here are the most common questions we have been asked or general observations we have made in our journey as FuSa consultants. As we motor through the FuSa path, we are sure to come across more interesting terrain with even more interesting observations. Till that time, safe driving!