d driving worldwide business excellence ri c e vin l l e … · (fmea), and production parts...

Considerations of Functional Safety, Automotive SPICE, and Cybersecurity in Automotive New-Product DevelopmentNew technologies and an expanded supply chain have increased design and production complexity

DRIVING WORLDWIDE BUSINESS EXCELLENCE

WWW . O M N E X . C O M

By Mr. Chad Kymal and Dr. Juan Pimentel


2 DRIVING WORLDWIDE BUSINESS EXCELLENCE WWW.OMNEX.COM

Chad Kymal is the CTO of Omnex Inc., an interna-tional consulting and training organization head-quartered in the United States. After graduating from the General Motors Institute, Chad spent a number of years working at General Motors and KPMG. Over the course of Chad’s successful ca-reer, he has served on the Malcolm Baldrige Board of Examiners and has received numerous quality achievement awards, including the Quality Profes-sional of the Year award by the American Society for Quality (ASQ) Automotive Division in 2005. In addi-tion to his bachelor’s degree from GMI, Chad holds both a master’s degree in industrial and operations engineering from the University of Michigan and an MBA Cum Laude from the University of Michigan. He is a member of Tau Beta Pi.

Chad both developed and teaches auditor training for ISO 9001, ISO 14001, and ISO 45001, as well as an Integrated Management Systems Lead Audi-tor training course where all three standards are combined in a single audit. Chad is the founder of AQSR, a global registrar that routinely provided in-tegrated audits in QMS, EMS, and OHSMS. Chad is also on the ISO/TC 176, ISO/TC 207, PC283 commit-tees for ISO 9001:2015 (Quality Management), ISO 14001:2015 (Environmental Management) and ISO 45001 (Health and Safety Management Systems.

Omnex has been working in the Automotive indus-try for 30 years and Omnex principals been active in writing different automotive standards including QS 9000, ISO/TS 16949, Semiconductor Supplement, APQP, FMEA and Core Tools. Chad conducted the first world-wide witness audit for QS 9000 a pre-decessor to IATF 16949. He is the author of seven books and more than 100 papers including several on integrated management systems.

Chad has spent over 20 years in System, Hardware and Software development in various capacities. He assesses and works in Automotive Systems, hard-ware and software for Agile, ASPICE, and Functional Safety ISO 26262.

Chad is a certified Lead Auditor for IATF 16949, ISO 14001, ISO 9001, FSSC 22000, HAACP, ISO 45001, AS9100, ISO 13485 and teaches many other courses for Omnex. He is also an INTACS certified assessor for ASPICE.

Dr. Juan Pimentel is the Omnex Principal Consul-tant with extensive Systems Engineering, Safety and Cybersecurity experience. His knowledge and expe-rience includes applied research, product develop-ment, electric vehicles, autonomous vehicles, safety and cybersecurity assessment and assurance. In ad-dition to assuring safety and cybersecurity though compliance/conformance he understands the need for reducing costs.

Dr. Pimentel has extensive experience various auto-motive areas that includes electric powertrains, elec-tric motors, electric batteries including battery man-agement systems, in-vehicle networks such as the CAN bus, ROS, high speed in-vehicle communication networks, microcontrollers (MCUs) with high level of safety and security. He has performed a number of functional safety projects involving the standards IEC 61508, IEC 61511, and ISO 26262 in areas ranging from oil & gas, automotive, electric vehicles, and au-tomated vehicles. He has performed consulting and developed courses on systems engineering, func-tional safety and cybersecurity aspects of electric and autonomous vehicles.

During the last few years he has been involved with the Internet of Things (IoT), software define radios (SDR), penetration testing, ADAS and automated ve-hicles, and how to design vehicles with high levels of safety and security. He has participated and con-tinues to participate on various IEEE, SAE, and ISO standards. He is on the SAE Vehicle Electrical Hard-ware Security Task Force and on the SAE/ISO 21434 automotive cybersecurity standard task force as well as on the ISO/PAS 21448 standard task force.

Juan has a Bachelor of Science, Electrical Engineer-ing, Universidad Nacional de Ingenieria, Lima, Peru. Master of Science and Ph.D. in Electrical Engineering, University of Virginia.

CHAD KYMALCTO, Omnex Inc.

DR JUAN PIMENTELOmnex Principal Consultant

SPEAKERS

3WWW.OMNEX.COM DRIVING WORLDWIDE BUSINESS EXCELLENCE

“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

Product design in autonomous and electric vehicles requires a product architec-ture of systems, subsystems, hardware, and software, as well as requirements management and the “Engineering V.” Electronics, hardware, and software in the product also necessitate new software standards. Automotive SPICE, a software ca-pability standard required by many OEMs, has the voice of the customer translat-ed into system architectural requirements, which flow down to system require-ments, then to software architecture, next to software requirements, and finally into unit requirements. As the requirements flow down, customers, suppliers, sub sup-pliers must work closely together because product development of Functional Safety, SOTIF, Cyber Security, and AIAG-VDA FMEA demands linked development.

Automotive Electronics Cost as a Percentage of Total Car Cost Worldwide from 1950 to 2030

ABSTRACT

Organizations in the automotive and other industry sectors such as steel, plastics, and semi-conductors 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). Excluding the IATF 16949 which is the Automotive Quality Management Systems standard, the others are collectively called “Core Tools” which includes measurement system analysis (MSA) and statistical process control (SPC).

During the last 10 years, a significant number of new technologies have been introduced in automobiles, including autonomous breaking, auto lane change, adaptive cruise control, vision based driver assistance systems, and various sensor-operated driver warning systems. It is ex-pected that 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. (What is the source of this Figure?)

1950 1960 1970 1980 1990 2000 2010 2020 2030

Year

Sh

are

of

Tota

l Co

st

0%

10%

20%

30%

40%

50%

60%


01 IATF 16949:2016

ISO 26262

AUTOMOTIVESPICE

SUPPLY CHAIN PRACTICES

SOTIF

CYBERSECURITY

AGILE APQP

02

03

04

05

06

07

The 7 Levers of Automotive Industry

Automotive Quality Management System followed by Automotive Organizations Worldwide. IATF 16949 + ISO 9001 + Customer Specific Requirements define the requirements for Automotive Organizations Globally

Functional Safety Standard that starts with HARA, Safety Goals and Safety Require-ments. Functional Safety starts with the System, then flows down through ASIL levels and Safety Goals to Sub Systems, Hardware, Software and Operations.

Safety of the Intended Functionality or SOTIF studies the performance limitations or insufficient situational awareness with or without reasonably foreseeable misuse.

SAE J3061 and ISO/SAE 21434 Cybersecurity Standards define how to keep Autonomous Cars and E Cars safe from being hacked.

Agile techniques to deliver APQP inputs/outputs to produce “Shippable” products or PPAP delivered in iterative sprints.

Automotive SPICE is derived from ISO 15504 (SPICE). Automotive SPICE (ASPICE) is a standard tailored specifically for the software developers in the automotive industry to evaluate and improve the capability and maturity of their Software Development Life Cycle (SDLC) processes for mechatronic systems.

The new EV and AV standards require the customer, supplier and sub suppliers to work closely together. ISO 26262 Functional Safety, ISO/PAS 21448 SOTIF, ISO 21434 &SAE J3061 Cybersecurity Standards all link functions and requirements between the System, Sub System, hardware and software. Software quality, functional safety, and cybersecurity all require the customer and their supply chain to work in lockstep or the product will fail.

Figure 3: The seven levers of the automotive industry

Seven standards or methodologies are levers to this shift in automobile design and manufactur-ing (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).

The three parallel developments of 1) increased electronics and software in automobiles; 2) in-creased software failures; and 3) automobile product shift from ICEs to electric and AVs are requiring new standards and methodologies in automobile vehicle and parts design as well as manufacturing.

These new technologies also are resulting in multipoint failures and software-related fail-ures in automobiles. Data show that 15 per-cent to 50 percent of warranty failures are attributable to software defects (see figure 2). In addition, these new technologies also introduce a significant number of vulnerabil-ities thus enabling hackers to mount attacks and target vehicle assets. 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 ex-clusively on APQP and other Core Tools.

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

Figure 2: Software is now to blame for 15 percent of car recalls; many OEMs have reported that up to 50 percent of warranty and recalls are related to soft-ware. Functional safety can address these in soft-ware and hardware.


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

The fifth, Safety Of The Intended Function (SO-TIF), addressed in the standard ISO/PAS 21448, is excluded from this discussion because it is thought primarily as an OEM standard for au-tonomous vehicles and often used for handling scenarios involving functional insufficiencies and misuse. Explaining how it is pertinent to ev-ery functional safety design would distract from this discussion.

The fourth is the need for technology to man-age new-product development (i.e., supply chain initiatives) within the automotive indus-try. Automobile design and manufacturing have lengthened their supply chains from sys-tem 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).

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 methodolo-gies. That discussion is also outside the scope of this article. Moreover, IATF 16949, which incor-porates 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 Developmentwith APQP and PPAPAutomotive 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 of APQP are:

1. Planning2. Product design

3. Manufacturing process design4. Product and process validation

5. Feedback and corrective action


Both the APQP and PPAP are in significant need for updates based on these methodologies and the shift from ICE to EV and AV. The documents currently required in PPAP need to be thought through in light of many new practices and resulting documentation (called work products in the new standards) which may be more important than the current documents submitted which are relevant to a mechanical internal combustion engine product formulated over 25 years ago.

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 ef-fectively 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. Phase IV includes the submis-sion of a Production Part Approval Process or PPAP which signified the ending point of Phase IV and approval of the process for high volume production. The PPAP involves a submission of documents and approval of the submission typically by a customer for a supplier. 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 (Systems Engineering) Engineering V-model Requirements flow down Requirements Management

Testing flows up Traceability Configuration Management

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 CybersecurityThe 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 struc-ture analysis). Each of these elements has its own project plan (APQP) and more specific func-tional safety, cybersecurity, and software 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 for production. Both ISO 26262 Functional Safety (FS) and ISO 21434 Cybersecurity (security) have a concept phase where a risk analysis is conducted to identify the ASIL level or CAL of the product. The ASIL or CAL are safety or cybersecurity related hazards and/or requirements that are the output of the Hazard and Risk Analysis (HARA) and the Threat and Risk Analysis (TARA). These requirements are identified in the Functional and Cybersecurity Safety Concept phases which are not represented in APQP currently. The new automotive standards do not address manufactur-ing 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. Automotive SPICE or software processes don’t enter into the discussion on the concept phase. The system requirements which are the result of the concept phase are the start of AUTOMO-TIVE SPICE standards. When studying OEM Stakeholder requirements, they often have software requirements intermingled with Product features and system requirements.

Figure 6: Antilock braking systems structure


Following structure analysis is the engineering V-model that links the design of the system, sub-system, hardware, and software via functions and requirements. The design flows down on the left side of the V-model and is complemented by testing as the product is recursively tested up-ward on the right side of the V-model (see figure 7). The engineering V-model requires features and requirements from stakeholders to flow down and incorporate into functions and require-ments 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 requirements di-rectly into the DFMEA for the system, subsystem, hardware, and software. Hardware and soft-ware 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 (FME-DA). Note: Be careful, a FMEDA is not a FMEA, they are different work products with different purposes and results.


Traceability and Configuration

Traceability of requirements and configuration management of work products are requirements of the new standards. This is an unprecedented level of management of new product develop-ment documents. AUTOMOTIVE SPICE requires system and software documents to be in con-figuration management. Once we include functional safety and cybersecurity, this will include hardware. The only part of the structure that is not included for traceability is mechanical parts. There is no need to just exclude these, Omnex recommends consistent practices for the entire new product development processes. For the next section, we will discuss systems without limit-ing our discussion to what is the minimum required by standards.

Traceability in the new standards begins with system requirements, which then need to be linked to the next level of requirements, e.g., subsystem, software, and hardware regardless where they are designed (in house or at suppliers). These requirements then are linked to design doc-uments, test cases, and test results. Also linked via traceability are DFMEAs, DVP&Rs (test plans), Process Flows, PMFEAs, Control Plans, Inspection Sheets, Inspection records and SPC records. The traceability cannot only be top down, but rather they need to be top down, and bottom up. Configuration Requirements require the configuration of each of these documents be main-tained for any type of design release. The configuration needs to extend to test software and lab set ups. In our assessments, each of the automotive suppliers have half a dozen or even a dozen software tools managing these documents. These tools are very specialized for hardware, or software or systems. This makes configuration management very difficult. No tool is able to meet all the demands from requirements management, project planning, functional safety planning, audits/assessments, issue tracking, change management, problem solving, etc. In the last section we discussed how Omnex is integrating all this functionality in its EwQIMS software.

Linking DFMEA and DVP&R for the V Model

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. The DFMEA and DVP&R linkages 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 world. Omnex has accomplished this with 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, with structure analysis, linked functions and requirements, and linked DVP&R. A software tool that provides these linkages is key part of this. Understanding this, Omnex developed a solution that integrates and links DFMEA, DVP&R, process flow, PFMEA, control plan, and work instructions (see figure 8).


APQP or New Product Development in the Automotive OEM or supplier needs to change to accommodate ISO 26262 Functional Safety, ISO 21434 Cybersecurity, and AUTOMOTIVE SPICE product development methodologies. Integrating methodologies does not mean project manag-ing three different organizations – engineering, functional safety, and cybersecurity. Integration of NPD with APQP, functional safety, cybersecurity, and AUTOMOTIVE SPICE means having the same engineers design and test the product that includes functional safety, cybersecurity and AUTO-MOTIVE SPICE requirements. There are some specialist’s roles, but most of the requirements can be met with the existing engineering team without increasing head count. However, the new product development timing between system, subsystem, hardware, and software needs to be aligned as shown in figure 9.

Integration will require integrated work products that satisfy all of the new standards. It will also include structure analysis (systems engineering), engineering V-model, requirements flow down, testing flow up, traceability, and configuration management.

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

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 traceabilityEngineering V-modelConfiguration managementDocumenting and incorporating functions and requirementsDeveloping test criteria and test cases for functional safety, cybersecurity and AUTOMOTIVE SPICEManaging distributed development with intercompany agreementsConducting 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 – Omnex’s EwQIMS Software

A major challenge when implementing APQP with functional safety, Automotive SPICE, and cyber-security center around distributed development of automotive products that encompass system, subsystem, hardware, and software. These new standards require development to keep in lock-step 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 an additional few hundred more now required by functional safety, Automotive SPICE, and cybersecurity. Requirements manage-ment, testing flow up, DFMEA, DVP&R, timing management, and PPAP all require that the custom-er 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 cum-bersome 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 information on how Omnex can specifically help you and your supply chain, contact us today.

315 E. Eisenhower Parkway, Suite 214,

Ann Arbor, Michigan 48108, USA

Phone: 734.761.4940 Fax: 734-761-4966E-mail: [email protected]

WWW . O M N E X . C O M

OMNEX INCWorld Headquarters



d driving worldwide business excellence ri c e vin l l e … · (fmea), and production parts...

Documents