Functional Safety, Automotive SPICE, and Cybersecurity in New-Product Development

Organizations in the automotive and related industries such as steel, plastics, and semiconductors have been heavily influenced by automotive industry standards and practices like IATF 16949, advanced product quality planning (APQP), failure mode and effects analysis (FMEA), and production parts approval process (PPAP). These are collectively called “Core Tools” and include measurement system analysis (MSA) and statistical process control (SPC).

During the last 10 years, a significant number of new technologies has been introduced in automobiles, including autonomous breaking, auto lane change, adaptive cruise control vision systems, and various sensor-operated alerts. Soon, more than 50 percent of a new car’s value will be found in its electronics (i.e., semiconductors) and software (see figure 1).

Figure 1: Automotive electronics cost as a percentage of total car cost worldwide from 1950 to 2030

These new technologies also are resulting in multipoint failures and software-related failures in automobiles. Data show that 15 percent to 50 percent of warranty failures are attributable to software defects (see figure 2). Now, more than ever, it is important to recognize the need for improved product development processes in systems, hardware, and software. Until now, the automotive industry has relied almost exclusively on APQP and other Core Tools.

“According to the ‘2016 Automotive Warranty and Recall Report’ software-related recalls have gone from less than 5 percent of recalls in 2011 to 15 percent by the end of 2015.... There have been 189 distinct software recalls issued over five years—covering more than 13 million vehicles... 141 of these presented a higher risk of crashing.”
—Bengt Halvorson, The Car Connection, June 2, 2016

Figure 2: Software is now to blame for 15 percent of car recalls; root cause analysis by Omnex shows up to 50 percent of warranty and recalls relate to software. Functional safety can address these in software and hardware.

At the same time that these technology and related hardware and software changes are occurring, the automotive industry is shifting from combustion engines to electric power, and soon, to autonomous vehicles. One can see many different strategies applied around the world. In the United States, for example, Tesla and General Motors are leading the charge toward autonomous vehicles. GM is applying its “super cruise” in combustion engines, while Tesla is applying its autopilot to electric vehicles.

The three parallel developments of 1) increased electronics and software in automobiles; 2) increased software failures; and 3) automobile product shift from combustion engines to electric and autonomous have required new standards and methodologies in automobile vehicle and parts design as well as manufacturing.

Seven standards or methodologies are levers to this shift in automobile design and manufacturing (see figure 3). In this article we will address four of them. The first three are functional safety (ISO 26262); automotive software process improvement and capability determination (SPICE), a maturity model derived from ISO/IEC 15504; and cybersecurity (SAE J3061 and ISO 21434).

Figure 3: The seven levers of the automotive industry

The fourth is the need for technology to manage new-product development (i.e., supply chain initiatives) within the automotive industry. Automobile design and manufacturing have lengthened their supply chains from system design to include extensive hardware and software links that extend all over the globe, including the United States, Canada, Europe, Mexico, China, and India (see figure 4).

Figure 4: Global automotive supply chains now include extensive hardware and software links.

Note: Safety of the intended function (SOTIF), shorthand for ISO/PAS 21448, is excluded from this discussion because it is primarily an OEM standard for autonomous vehicles and often used for handling scenarios involving artificial intelligence. Explaining how it is pertinent to every functional safety design would distract from this discussion.

Agile APQP is another key methodology that incorporates agile at scale (i.e., agile used for system, hardware, and software development) as well as automotive SPICE, APQP, and PPAP methodologies. That discussion is also outside the scope of this article. Moreover, IATF 16949, or the organizational processes of purchasing, sales, design, and change management, are all affected by these new standards but also will not be addressed here.

New product development with APQP and PPAP

Automotive and related organizations such as steel, plastics, or semiconductors use a five-phase new product development process as shown in figure 5.

The five phases are:
1. Planning
2. Product design
3. Manufacturing process design
4. Product and process validation
5. Feedback and corrective action

Each of these phases has inputs and outputs. For example, phase two includes product design, design FMEA, design for manufacturability, design for assembly, lessons learned from previous similar products, design requirements, and design output. The APQP methodology does not effectively consider or model the challenge of simultaneously designing the system, subsystem, hardware, and software. When AIAG first released APQP in 1995, automobiles were mechanical in orientation and did not include much hardware and software. Today, with the significant increase in hardware and software, and the advent of large systems, the following methodologies have come to the forefront:
• Structure analysis
• Engineering V-model
• Requirements flow down
• Testing flows up

Figure 5: The five phases of advanced product quality planning (APQP). Note how the entire methodology focuses on one element of the structure, i.e., system, subsystem, hardware, or component.

New product development frameworks: functional safety, automotive SPICE, and cybersecurity

The frameworks for functional safety, automotive SPICE, and cybersecurity standards all assume a structure analysis of system, subsystem, hardware, and software architecture for new product development as well as an engineering V-model evaluation (see figure 6 for an example of structure analysis). Each of these elements have its own project plan (APQP) and its own functional safety project plan. These frameworks don’t clearly call out the supplier; however, it is assumed that they include the supplier seamlessly in the structure, i.e., through distributed development.

Each of these new standards focuses only on phase two of APQP, and each starts with planning (phase one of APQP) or stakeholder requirements and ends when the design is released. The standards do not address manufacturing process design for the system, subsystem, or hardware elements of the structure. The focus is solely on product design, with no mention of the production part approval process (PPAP), where the testing is performed using production parts made in the production environment.

Figure 6: Antilock braking systems structure

Following structure analysis is the engineering V-model that links the design of the system, subsystem, hardware, and software via functions and requirements as the design flows down and includes testing as the product is recursively tested upward (see figure 7). The engineering V-model requires features and requirements from stakeholders to flow down and incorporate into functions and requirements at the system, subsystem, hardware, and software levels. It is a more detailed evaluation in that there is an interim architectural requirement that focuses on interfaces. Those familiar with design failure mode and effects analysis (DFMEA) can think in terms of a block diagram, but the engineering V-model goes even further. Each requirement has a unique ID, and the incorporation is traced into each level or element of the structure. For software there is system, module, and unit-level incorporation based on the software’s structure.

Figure 7: Engineering V-model

Requirements management then becomes an important part of the new APQP framework that must incorporate functional safety, automotive SPICE, and cybersecurity. It is best to define the requirements as functions and requirements, since this allows us to take the incorporation at each element directly into the DFMEA for the system, subsystem, hardware, and software. Hardware and software DFMEAs are also becoming requirements, as is analysis of multipoint failures in hardware using tools such as fault tree analysis and failure mode and effects and diagnostic analysis (FMEDA).

Linking DFMEA and DVP&R

The DFMEA and design verification plan and report (DVP&R) are fundamentally linked through the preventive and detective controls in the DFMEA and the detective controls in the DVP&R. These DFMEA and DVP&R links automatically enable the requirements flow down and testing flow up. Software tools make it easy to link functions and requirements management in the structure along with the respective DFMEAs and DVP&R, even when design and testing are distributed to locations around the globe. Omnex has accomplished this within the AQuA Pro and requirements flow-down software tool.

Omnex advises adopting the AIAG-VDA FMEA with linked DVP&R or AIAG’s FMEA 4th edition, which incorporates structure analysis, linked functions and requirements, and linked DVP&R. Implementing software is key. Understanding this, Omnex developed a solution that integrates and links DFMEA, DVP&R, process flow, PFMEA, control plan, and work instructions (see figure 8).

Figure 8: Changes to the current product design framework or process

The current product design frameworks based on APQP, and the Core Tools need to change to accommodate structure analysis, engineering V-model, function and requirements flow down, and the related testing flow up. Furthermore, the new product development timing between system, subsystem, hardware, and software need to be aligned as shown in figure 9.

Figure 9: APQP-based new-product development processes in system, subsystem, hardware, and software development, with concurrent alignment of product design and the engineering V-model from phase two of APQP. After design, each organization then continues with its manufacturing process development, and product and process validation processes, including PPAP.

New engineering competencies, including supplier quality engineer (SQE)

With this degree of evolutionary change in the industry, there are a number of competencies that OEMs and the automotive supply chain must incorporate in their systems, including:
• Requirements management with bidirectional traceability
• Engineering V-model
• Configuration management
• Documenting functions and requirements, and incorporation of functions and requirements
• Developing test criteria and test cases
• Managing distributed development with intercompany agreements
• Conducting assessments, audits, and work-product reviews in functional safety, automotive SPICE, and cybersecurity

Each of the standards for functional safety, automotive SPICE, and cybersecurity include detailed competency requirements that Omnex has identified.

Tools for integration

A major challenge when implementing APQP with functional safety, automotive SPICE, and cybersecurity centers around distributed development of automotive products that encompass system, subsystem, hardware, and software. These new standards require development to keep in lockstep and to ensure everyone is designing the product to the most current requirements. Keep in mind, the hundreds of APQP documents have just increased by a few hundred now required by functional safety, automotive SPICE, and cybersecurity. Requirements management and testing flow up, DFMEA, DVP&R, timing management, and PPAP all require that the customer get an overall status report and be able to guide development.

In practical terms, without a software tool it is impossible to keep requirements up to date in a distributed development model, or to manage both internal and supplier “on time” development. Keep in mind automakers must still manage overall internal status, supplier status, and PPAP status along with safety cases for both functional safety and cybersecurity. This difficult and cumbersome management is the challenge of product development today.

Omnex has addressed this challenge with training, implementation, and software. An important part of this solution is Omnex’s development of an integrated tool that can manage the system, subsystem, hardware, and software development internally, as well as the supply chain for APQP, functional safety, automotive SPICE, and cybersecurity.

For more on this subject, join Chad Kymal, Omnex CTO and founder, and Dirk Dusharme, editor in chief of Quality Digest, for the webinar, “Safety Products, and Electric (EV) & Autonomous (AV) Vehicle Standards,” Tuesday, Oct. 1, 2019, at 11 a.m. Pacific, 2 p.m. Eastern. Register here.

About The Author