safety manager
person or organization responsible for overseeing and ensuring the execution of activities necessary to achieve functional safety (3.67)
Note 1 to entry: At different levels of the item's (3.84) development, each company involved can appoint one or more different persons by splitting assignment in accordance with the internal matrix organization.
- Proactive nature
- Process knowledge
- BIG picture understanding
- Detail orientation
- Superior planning
- Leadership
- Risk analysis
1. Proactive Nature
In line with the ‘7 habits of highly effective people’ by Dr. Covey, the first & foremost habit for an effective safety manager is the habit of being proactive. What do we mean by that in a FuSa context? Safety is all about identification of risks and taking suitable actions to either eliminate or minimize their impact. For this to happen well, safety manager should think ahead and identify items that could potentially become showstoppers in the future.
A non-exhaustive list of ‘proactive’ measures a safety manager could take is given below:
- Ensuring that the selected hardware could meet the target metrics. Doing a rough back of the hand calculation comes handy at this point.
- Working with 3rd party supplier of SEooC HW components. This is to ensure that the FIT values for these critical components are available. Also, for some of the complex microprocessor/microcontroller, it is essential to ensure that the Diagnostic Coverage (DC) calculation sheets are provided by the 3rd party supplier.
- Working with the 3rd party suppliers (SW and HW) to ensure that they are aware of the project milestones and the dates provided by them are meeting our deliverable timelines.
- Identifying whether all the essential HW & SW components, tools are available at the required ASIL.
- Ensuring that a process exists for communicating the compiler/linker settings chosen by the SW team is passed on to all the 3rd party SW suppliers.
- Establishing a detailed safety deliverable timeline. This should be done after understanding the program timelines, the 3rd party deliverables timeline, and the nature of the work product. (More on this in the ‘Superior Planning’ section)
2. Process Knowledge
A deep knowledge of ISO 26262 should be a prerequisite for a good safety engineer. For a safety manager, it is not just the knowledge of the standard but the ‘why’ behind the standard itself. One of the issues we have seen with safety managers is that they sometimes blindly stick with the ‘process’ given in the ISO 26262 document and are not able to move beyond the standard to clearly articulate the risk behind not meeting a process completely. Behind every process is a reason for doing it and being able to crystallize this ‘Why’ is essential to coming up with good risk mitigation or possible alternative solutions.
3. BIG picture understanding
When working on any program as a functional safety manager, it is essential to move beyond the requirements that needs to be satisfied by our ECU and think about the safety goals at the vehicle level. “What is the hazard(s) if this safety goal is violated”, “How much time does the driver have to do something about the problem”, “Who are the consumers of my output and how do they use it at vehicle level” are some of the questions that the safety manager should strive to find answers for. The answers to these questions help us in identifying the appropriate failure modes we should be addressing as part of our safety mechanisms. As an example, consider the following use case. Assume that your ECU is sending out the vehicle speed and before it sends it out, it limits the sent speed to 80 kmph. Due to some reason, assume as well that there is a bug in your ECU because of which the speed limit function is not working as expected. If this bug is detected just before a crucial milestone for which the SW must be released, there are only 2 possible high-level options. Fix the bug as soon as possible or live with the bug for this release and come back to it in the immediate future. As a safety manager, if you are already aware that the same speed limiter check is done by the ECU (As a redundant check) who uses your signal, will it not save some sleepless nights for you?
The other aspect that he needs to recognize is that the safety manager should be able to go beyond the ISO 26262/SOTIF standard and understand the big picture view of safety. It could mean that he should be aware of product safety, the regulatory framework like NHTSA or NCAP. More importantly, he should understand how all these different/differing standards work in tandem. The ability to piece together this puzzle regarding these standards and regulatory framework helps a safety manager appreciate the landscape of safety better and make better decisions when risks are identified in the implementation.
4. Detail Orientation
Paradoxical as it may sound, an effective safety manager should be able to switch seamlessly from a big picture view to being detail oriented. Safety is in the details, and being able to meticulously follow every small thing to closure is essential for delivering a good safety program. The focus on details could manifest itself in many ways & a few are listed below for reference:
- Thorough reviews of work products.
- Excellent checklists used during those reviews. As a side note, excellent checklists are built over time from the standard, lessons learned and from the varied experiences of other safety professionals.
- A detailed plan of the activities to be done (This is such a critical item that this deserves a separate point by itself!)
5. Superior Planning
One of the best ways to ensure that the finer details of safety are translated into reality is to have superior planning. A good safety manager starts planning for their activities from the quote stage itself. The ability to think of all the possible things that could go wrong during the development of an ECU and to be able to translate those into checkpoints at the appropriate times in the project timeline is critical to ensure that the details don’t slip through the sieves. A superior plan should contain not just the ‘when’ but also the ‘what’, ‘who’ and the ‘how’. For example, instead of saying that the unit testing results should be checked, a good plan should say that ‘statement & branch coverage’ would be checked and that the acceptable level of coverage should be above X% for an ASIL-B program. The timeline by which this would be checked should also be captured (In this instance, it is better to align this timeline to the program milestone). When doing the planning, one should be able to differentiate between long lead activities (Ex: FMEDA, FMEA, SW DFA, SW Safety Analysis etc.) and the short duration activities (Ex: Verification & Confirmation reviews of various work products etc.) & plan things accordingly. It is imperative that such long lead activities are planned at the appropriate time in the development phase. Also, any dependencies with other teams within the organization should also be stated clearly in advance to avoid any surprises.
As part of the planning, the safety manager should also be able to make strategic decisions. These strategies even could be about taking some decisions that introduce a risk in the short term for the program. The idea, once again, is to ensure that the risks are managed sufficiently and with the long term in mind. An example for this could be about starting the FMEDA activities even while the TSRs are getting finalized in a project where the timelines are short. The short-term risk in this approach is that we assume that certain TSRs would be implemented and hence the HW metrics are calculated based on those assumptions. However, in the worst-case possibility that some of the TSRs are not implemented due to technical limitations, then the HW metrics achievement could be in jeopardy. On the other hand, if we don’t start the FMEDA early and we wait for the TSRs to be finalized, we might not have the time to complete it before the relevant project milestones. The safety manager should be able to look at both the short-term & long-term risks, short-term & long-term objectives of the program and come up with strategies accordingly.
6. Leadership
While leadership is essential in every walk of life, it is one of the most (If not the most) important attribute for an effective safety manager. If it is a common trait expected from every single individual, why mention it separately for a safety manager? A couple of reasons:
a. Safety is – by its very nature – an activity that requires a lot of cooperation with other teams. Safety cannot be (and should NOT be) done in isolation and requires that the safety team works in tandem with other teams. This means that the safety manager takes up the role of a collaborator who acts as a bridge between the safety team & other developments teams like systems, HW, SW etc. Doing this well would ensure that the program is launched with very few hiccups.
b. Safety teams tend to be smaller in size (At least in comparison to SW/Systems teams!) and hence making effective use of the available persons’ skill is essential for completing projects on time within the budgeted cost. The safety manager needs to ensure that the right people are available for analyzing and writing technical safety requirements, to perform FMEDA calculations, to support the SW teams in case of questions etc. (Note: This aspect is dependent on the roles & responsibilities within an organization and hence should be understood from that context). We have generally found that every safety engineer should have a strong system understanding (Irrespective of whether they are SW or HW specialists) so that they always get the big picture view. Also, having people with SW/HW development experience as part of the safety team helps in getting a balanced view of all the essential aspects.
c. Safety manager – at times – will have to make some tough decisions and hence the safety manager is expected to have the courage to stick to his stand. One of the examples is when a product release needs to be made and a critical safety issue is found in the product. In such a scenario, safety manager might have to inform the management that the product should not be released till the critical issue is resolved.
7. Risk Analysis
The definition of ‘Functional Safety’ as per ISO 26262 is: absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems. The keyword here is ‘unreasonable’ and hence a safety manager should not be aiming for eliminating all the risks from a program (Which is impossible anyways). An effective safety manager should be able to clearly differentiate the risks that needs to be eliminated from the risks that should be reduced and the risks that one could live with. The safety manager should have various lenses through which he looks at the problem and be able to propose suitable actions. As an example, let us say that SW qualification looks like a good option for a QM component that could not be made/purchased as ASIL. When evaluating such an approach, it is essential that a long-term perspective be taken. Is this a SW component that gets frequently updated? If yes, the risk is about being able to support the SW qualification activity for each of these iterations. Is the cost of this repeated re-evaluation factored into the budget? Will the team have person(s) who will be available to do this activity as & when the SW change happens? Even though these are not technical risks per se and could be classified as project management risks, the safety manager should be able to think along these lines as well to ensure the safety of the product over the entire production cycle.
Conclusion
The 7 habits that we have specified above are based on our experiences working in various organizations and different settings with varying process & safety culture. We have tried our best to refine & crystallize our thoughts into things which are universally true. It is very much possible that a different set of habits might feel important to someone else in a different context and those could be valid as well. The important thing is to ensure that you pick and choose the right set of behavior that works for you and your context.