I have been in the automotive industry for over 20 years, and for those of us in the industry, we know the pressure to deliver newly designed components, systems and ultimately vehicles in an increasingly shorter time is very real.

With the inclusion of functional safety, it seems that many engineers feel there is increased pressure and an increased overall workload in the development cycle, which increases the development cycle timing. But is this true?

I will admit that there is an increased workload from a documentation standpoint; however, I contend that the inclusion and application of functional safety within a program can actually assist in shortening the development time. This is not necessarily because applying the principles, methods and practices of ISO 26262 are essential to ensuring the absence of unreasonable risk (which is obviously THE most important aspect of functional safety) but because the process, when performed properly, assists in ensuring the product development process within each organization is actually followed.

What? The product development process is not usually followed?!? Sure it is! There are plans put in place, there are processes that are followed, there are gate checks to ensure that everyone is on track to meet the timing. However, as many of us are aware, in a majority of cases the original timing for the program, the timing that is required to properly complete all the normal development work, is reduced.  This timing reduction means that some activities within the development process need to be condensed, which in many cases results in redesign or rework, which ultimately adds time to the project.

So how does functional safety assist in this? It doesn’t allow us to increase the timing of the project, but it does require us to properly plan for the project, which assists in ensuring that we are meeting the targets for each phase. Meeting those targets greatly reduces the likelihood of rework and redesign, which can allow us to complete the project within the planned timing constraints.  Let’s take a look at some of the aspects that assist in this:

1.Understanding the system design requirements from a vehicle perspective at the onset of the program

From the OEM to the supplier to the sub-supplier, understanding what is really necessary from a functional and performance perspective, before rolling up your sleeves and getting to work designing the system or component, is imperative to proper design. This sounds elementary, of course we know this, we are all educated in engineering and this is the proper engineering process.  But more often than not, things get missed because some aspects are not fully understood or completely evaluated. Developing an Item Definition, looking at all the aspects of interactions of each system, as well as functional and performance requirements, provides a clear understanding of what is known about the system and what additional information might be necessary. Since the Item Definition is a prerequisite to the HARA (so this is required before you have even determined if there are any safety requirements within the program), this should be done on every system and every new program.

2. Review and agreement of the DIA

I have written a previous blog on the importance of the DIA. In a nutshell, by having an open and complete discussion regarding the responsibilities of the program, expectations of work products, etc., each level of the supply chain can properly plan resources and timing for the project.

3. Proper development and traceability of requirements

Requirements development and traceability is not unique to functional safety, this should be followed as part of a normal QM process. What functional safety adds, at least for the safety related requirements, are a clear definition as to what should be included in a properly developed requirement and a verification of the functional safety concept (functional safety requirements) and technical safety concept (technical safety requirements), including the traceability of those requirements. The clear definition provided by ISO 26262 of what must be included in properly developed requirements reduces the ambiguity of what should be included in the design, which will focus the design team from the beginning of the program. The verification of these requirements, performed before the design work should begin, and throughout the program as requirements are updated, ensures a focused and complete design throughout the project.

4. Early development of the validation plan

The development of the validation plan is also not unique to functional safety, but the methods and recommendations provided in ISO 26262 will help to more clearly define how the validation will be performed, throughout all levels of the product (component, system, vehicle) development and will identify where there may be misunderstandings or incomplete verification or validation.

If the items above are performed when necessary in the project, there will be a clearer understanding of what is required for design, verification and validation. By having this clear definition up front, this should reduce the likelihood of missed or incomplete requirements and the subsequent achievement of those requirements. Which in the end should assist in keeping the project on track for timing or potentially reducing the overall timing of the project.

As the old saying goes, “Measure twice, cut once.”

Leave a Reply.

You can use the following tags to spruce up your comments: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>