Maturity level assurance for new parts

1

Joint Quality Management

in the Supply Chain

Product creation

Maturity level assurance for

new parts Methods, measurement criteria, documentation

3rd revised edition, October 2021

Online download document

Joint Quality Management

in the Supply Chain

Product creation

Maturity level assurance for

new parts Methods, measurement criteria, documentation

3rd revised edition, October 2021

Verband der Automobilindustrie e. V. (VDA)

3

ISSN 0943- 9412

Copyright 2022 by Verband der Automobilindustrie e. V. (VDA) Quality Management Center (QMC) Behrenstraße 35, 10117 Berlin

4

Non-binding VDA recommendation

The Association of the German Automotive Industry (VDA) recommends its members to apply the following guidelines for the implementation and maintenance of quality management systems.

Exclusion of liability

This VDA volume is a recommendation that is freely available for general use. Anyone who implements it is responsible for ensuring that it is used correctly in each case.

This VDA volume takes into account state-of-the-art technology, current at the time of issue. Implementation of VDA recommendations relieves no one of responsibility for their own actions. In this respect, everyone acts at their own risk.

The VDA and the people involved in the publication of VDA recommendations shall bear no liability.

If during the use of VDA recommendations, errors or the possibility of misinterpretation are found, it is requested that these be reported to the VDA immediately so that any possible faults can be corrected.

Copyright

This publication is protected by copyright. Any use outside of the strict limits of copyright law is not permissible without the consent of the VDA and is liable to prosecution. This applies in particular to copying, translation, microfilming and storage and processing in electronic systems.

Translations

This publication will also be issued in other languages. The current status must be requested from VDA QMC.

5

Preface to the third edition

Increasing product complexity and greater competition, combined with the higher quality demands of end-users and rising warranty and goodwill costs have an ever-greater influence on the cooperation between automobile manufacturers and the supply industry. Recently, the integration of mechatronic parts and software into vehicles has further increased the need for ever-closer collaboration.

This cooperation is characterized by the intensive interactions involved in the product creation process (product and process development up to the start of full production). Activities within the scope of quality assurance are therefore primarily focused on assessing project maturity in order to ensure lasting and robust series-production quality.

This VDA publication places the emphasis on a comprehensive and consistent presentation of maturity levels within the framework of progress in a project covering new parts, combined with an objective assessment of the maturity of the product and manufacturing process at agreed times within the product creation process.

This present VDA publication can be linked with the VDA standard “Robust Production Processes”. Thus, no matter which products are to be supplied, a positive maturity level status in all respects is the starting point for robust production processes and is integral to the set of measurement criteria applied at the start of production. In this regard, the measurement criteria in Section 5 “Standards in the process” marked with an “X” in the listed sets of measurement criteria (“RPP” column) are important prerequisites which must be satisfied. The processing of these criteria can be carried out on the basis of this present publication. The status of these criteria must be demonstrated at the “check-point” of the robust production process (cf. also VDA publication “Robust Production Processes”, Section 4).

The methodology for assessing project maturity based on quantifiable characteristics (maturity level measurement criteria) represents an extension of previous advance quality planning methods and can be integrated in the basic requirements (e.g. IATF

6

16949) and methods already published (e.g. APQP, PPA, Project management).

The maturity level assurance method can be applied both in internal customer-supplier relationships (within an organization, e.g. groups of companies) and in external customer-supplier relationships (between an organization and its customer or between the organization and its supplier). A significant element is therefore the rules covering cooperation at all stages in the supply chain, with the integration of all those involved in the project. To this end, important customer-supplier relationships are defined within the framework of milestone assessments in projects (new projects, face-lifts or other modification projects initiated by the customer), a concrete cooperation model in the project is described and thus the early, cross-functional integration of all those involved is assured.

Definitions of customer and the products to be supplied:

The customer is the recipient of the products to be supplied, no matter at what level of the supply chain. The last customer in the supply chain is the OEM and not the vehicle’s end user. Products to be supplied are contractually agreed new parts/products (products comprise all result categories, e.g. hardware, services, software and processed materials)1 with their associated development and production processes (e.g. calculations, design and development, logistics concepts).

1 See ISO 9001:2015 A.2

7

This present volume is a revision of the second issue, dated October 2009.

The reasons for the revision were:

• Stronger focus on software applications in the vehicle

• Requirements regarding maturity level assurance within the framework of agile product development.

The most significant changes and adaptations which have been made are:

• Revision of the set of measurement criteria based on user feedback in accordance with a continual improvement process, and new requirements

• Introduction of further measurement criteria for product maturity level assurance

• Integration of further measurement criteria and notes regarding software maturity level assurance, including requirements with regard to automotive cybersecurity

• Additions to the notes on the measurement criteria to include the principles of agile collaboration between the customer and the supplier

• Revision of A, B and C risk classification, addition of specific contents of software application in the vehicle

• Definition of A-, B-, C-, D-samples and assignment to the maturity levels

This publication is a guideline for companies in the automotive industry in implementing the maturity level methodology in the validation of the products to be supplied. It may also be regarded as a requirement in a customer-supplier relationship (included, for example, in purchasing conditions, requirements specifications and project-specific requirements).

Berlin, September 2021

VDA Verband der Automobilindustrie e.V.

9

Contents

1. Objective, purpose and scope of the study ........................................... 12

1.1 Objective and purpose......................................................... 12

1.2 Scope of the study ............................................................... 14

1.2.1 Risk classification (prioritizing) ............................................ 14

1.2.2 Applying maturity level assurance depending on risk classification ........................................................................ 15

1.3 Applying maturity level assurance in the supply chain ........ 15

1.4 Sample classification (A-, B-, C-, D-samples) ..................... 17

2. Contents of maturity levels .................................................................... 18

2.1 Phases of maturity level assurance ..................................... 21

2.1.1 ....... Requirement ........................................................................ 21

2.1.2 ......... Start ..................................................................................... 22

2.1.3 ......... Control ................................................................................. 25

2.1.3.1 Preparation .......................................................................... 26

2.1.3.2 Assessment ......................................................................... 26

2.1.3.3 Carrying out maturity level assurance depending on the risk classification (prioritization) ................................................. 31

2.1.3.4 Implementation .................................................................... 31

2.2 Status report covering maturity level, corrective actions and escalation ............................................................................ 32

2.2.1 ......... Maturity level status report .................................................. 32

2.2.2 ......... Escalation ............................................................................ 33

3. Communication in the supply chain ....................................................... 34

3.1 Exchange of information at “round table” meetings ............ 35

3.1.1 ......... Responsibilities .................................................................... 36

3.2 Exchange of information via "supplier self-assessment" ..... 37

10

3.2.1 ....... The supplier presents their assessment and actions to the customer (“B” risk-classified (prioritized) part) .................... 37

3.2.2 ......... Information provided by the supplier ("C" risk-classified (prioritized) part) .................................................................. 37

3.3 .......... Software maturity level meetings ........................................ 37

4. Standards in the process ....................................................................... 40

4.1 Risk assessment and classification (recommendation) ...... 40

4.2 A-, B-, C-, D-samples .......................................................... 43

4.3 Set of measurement criteria for maturity level assessment 48

11

Illustrations

Fig. 1.1 Principle of risk classification .................................................... 14

Fig. 1.2 Application levels according to risk classification ..................... 15

Fig. 1.3 Illustration of a critical path ....................................................... 16

Fig. 1.4 Allocation of the sample phases to the individual maturity levels .................................................................................................. 17

Fig. 2.1 Overview of the contents of maturity levels ML0 to ML7 .......... 18

Fig. 2.2 Allocation of measurement criteria to indicators ....................... 19

Fig. 2.3 The contents of maturity level assurance ................................. 20

Fig. 2.4 Schematic illustration of the maturity level assurance method .................................................................... 21

Fig. 2.5 Scheduling of maturity levels, milestones M1 to M8 in the overall vehicle schedule ....................................................................... 22

Fig. 2.6 Carrying out maturity level assurance in the supply chain ....... 24

Fig. 2.7 The principle of maturity level assessment ............................... 26

Fig. 2.8 Definition of traffic-light colors for maturity level assessment ... 27

Fig. 2.9 Overall assessment of maturity level based on consumer’s assessment ............................................................................... 27

Fig. 2.10 Example of a cascade of maturity level traffic lights ................. 29

Fig. 2.11 Analysis of the measurement criteria for all components based on a maturity level for assessment of process quality .............. 30

Fig. 2.12 The reporting principle in terms of hierarchy ............................ 32

Fig. 2.13 Example of escalation: customer activity at the supplier's premises ................................................................................... 33

Fig. 3.1 The principle of a communication cascade, based on ML2 ..... 34

Fig. 3.2 “Round table" organization ....................................................... 35

Fig. 3.3 Timing of software maturity level meetings, depending on release planning/software delivery ........................................................ 39

Fig. 3.4 Timing of software maturity level meetings, depending on release planning/software delivery ........................................................ 39

12

1. Objective, purpose and scope of the study

The following chapters describe three topics:

• The method of maturity level assurance in the supply chain

• Communication in the supply chain

• Standards in the process.

Those using this method will be in a position to identify products where the maturity level is critical and to assess their status at specified project milestones in the product creation process on an inter-disciplinary basis, using standardized maturity levels. Deviations from the objective are controlled by appropriate action management within the supply chain.

1.1 Objective and purpose

Maturity level assurance is a control method within project management, initiated by the customer. By applying specified rules, including the introduction of so-called “round tables”, online applications, B2B portals etc., both the suppliers of products and the customer’s internal organization are involved jointly at an early stage in the product creation process. Additional work and delays can be avoided where the elements of maturity level assurance are consciously integrated at an early stage in project management.

The principal objective of the maturity level assurance method is to improve the launch quality, delivery quality and field quality of the products supplied, by harmonizing the contents and operations in the supply chain.

By employing a structured procedure which interrogates the status of defined measurement criteria relating to the associated maturity levels, which in turn are oriented to the milestones of the overall project plan established by the automobile manufacturer, the agreed quality of the products to be supplied is assured.

13

The maturity level assurance method:

• establishes a joint understanding of specialist terms and expressions and their definitions,

• involves stakeholders across the entire supply chain into the product creation process at an early stage,

• offers all those involved the opportunity to take an active part in action and escalation, and

• leads to the early detection of deviations from the project objectives, so that corrective actions can be taken without delay.

By agreement between the parties, the method can easily be adapted to the requirements of any individual project.

The cooperation model described below generates transparency and a joint understanding of the project work by all those involved in the product creation process.

It must again be stressed that the method is a project management tool and does not replace project management in any way; instead, it expands project management by adding the aspect of maturity level control.

Those involved in the project take part in the relevant “round tables” where an appropriate procedure is agreed (for example, using video and telephone conferences, web meetings, B2B portals). A joint kick-off meeting, to be attended by all parties involved, is recommended at the beginning of the process (initial phase) depending on the risk classification (A, B or C, see Chapter 4.1) or experience using the maturity level assurance method.

14

1.2 Scope of the study

In principle, the maturity level assurance system can be used for all new products as well as for changes (see also trigger matrix, VDA Volume 2).

1.2.1 Risk classification (prioritizing)

Risk classification is carried out at each stage of the supply chain (Tier ‘n’ stage) by the customer for the product(s) to be supplied by the next stage down.

After placing the order, the classification must be updated, if appropriate jointly with the supplier – that is, the product risk and supplier risk are combined to establish the overall risk (cf. ML2, item 2.6.1 in chapter 4.3).

Fig. 1.1 Principle of risk classification

15

1.2.2 Applying maturity level assurance depending on risk classification

Depending on the risk classification, cooperation within the framework of maturity level assurance is carried out at three different application levels (for the intensity of cooperation, see Figure 1.2 and Chapter 2.1.3.3 “Carrying out maturity level assurance depending on the risk classification (prioritization)”).

Fig. 1.2 Application levels according to risk classification

1.3 Applying maturity level assurance in the supply chain

Maturity level assurance for products to be supplied is incorporated into the existing project management and is based on a maturity level milestone philosophy with a total of eight maturity levels (ML0 to ML7). The timings of these are agreed jointly between customer and supplier at the start of the project. The maturity level assessments ML0 and ML1 are done by the customer in

16

collaboration with a development supplier, if required. From ML2 onwards, the customer collaborates with the series supplier. Each maturity level describes the status regarding achievement of the objective in terms of the maturity of product, process and project at the agreed milestones. At the same time, potential risks in the overall project are detected at an early stage, so that they may be countered by appropriate actions, schedules and responsibilities. All maturity levels build upon each other and must be assessed in the specified sequence in the product creation process on the basis of clearly defined measurement criteria.

Fig. 1.3 Illustration of a critical path

Note:

An essential requirement in achieving the objective is to involve qualified personnel in the maturity level assurance process.

In case of issues critical to the maturity level, Tier n suppliers can be involved in a higher-level “round table” provided that the contractual partners give their consent.

17

1.4 Sample classification (A-, B-, C-, D-samples)

In the product development process, A-, B-, C-, D-samples serve

• to confirm the functional principle

• to check the installation space and manufacturability, in order to specify a constructive design

• to carry out tests

• to achieve technical release

to ultimately achieve a release based on the tests in order to achieve release for full production (PPA process).

The complete description/definition can be found in Chapter 4.2.

The sample phases were assigned to the individual maturity levels accordingly (see Figure 1.4).

Fig. 1.4 Allocation of the sample phases to the individual maturity levels

18

2. Contents of maturity levels

The maturity level assurance model begins with ML0 in the concept phase and ends with ML7 following SOP (generally not later than 6 months after SOP).

Fig. 2.1 Overview of the contents of maturity levels ML0 to ML7

Maturity levels are aligned both with the project schedule for the vehicle (or the customer’s product) and the project-specific timings for the products to be delivered. They can easily be integrated into the associated product creation processes established by the OEMs or the suppliers.

Figure 2.1 gives an overview of the various maturity levels with their associated indicators. Standardized measurement criteria are allocated to these maturity level indicators (see “Set of measurement criteria” in Chapter 4.3).

19

Fig. 2.2 Allocation of measurement criteria to indicators

The maturity level assurance system is an “open” system. The measurement criteria relating to all MLs (maturity levels) are defined so that they are universally valid and can be applied for all the functional areas of a vehicle (including software, electrical and electronic components).

The sets of measurement criteria consist of measurement criteria and associated explanatory notes and examples. The measurement criteria must be selected on a product-specific/process-specific basis, supplemented if required, analyzed and assessed. Notes on VDA publications in the comment column are only provided for reference purposes, are not part of the basis of assessment and no claims are made that they are complete. To illustrate change-overs from one maturity level to the next, relevant measurement criteria are set again as repeat questions (“R” questions) in the following maturity levels.

20

Fig. 2.3 The contents of maturity level assurance

21

2.1 Phases of maturity level assurance

Fig. 2.4 Schematic illustration of the maturity level assurance method

The three phases for the implementation and realization of maturity level assurance are broken down into:

• Prerequisite,

• Start, and

• Controlling.

2.1.1 Requirement

In order for the maturity level assurance method to be used, it is necessary to make customer-specific preparations for the products to be supplied.

Prerequisites:

1. Approval must be given for the use of the maturity level method within the customer’s organization

2. A description must be provided of the product to be manufactured (e.g., framework demands, component specification).

3. There must be initial, provisional planning covering the products to be supplied – that is, alignment with the product creation process for the vehicle and the module or component project plan.

22

4. Potential suppliers

5. There must be a common standard covering risk classification in the supply chain.

6. A risk classification must be available for all the products involved (see Chapter 1.2.1 Risk classification).

2.1.2 Start

The start of the maturity level assurance process depends on the current situation regarding the award of orders and contracts. The scheduling of the individual maturity level results from the component-specific schedule; the designations of the maturity levels ML0...7 serves as a reference (e.g. scheduling ML3 in accordance with the planned date of the “release of technical specifications”).

Fig. 2.5 Scheduling of maturity levels, milestones M1 to M8 in the overall vehicle schedule

23

Maturity levels ML0 and ML1 contain the measurement criteria applicable within the customer’s organization. However, they also cover interfaces to concept suppliers and innovation suppliers (development suppliers). At the latest, maturity level assurance with the supplier should begin at ML2 (“Specifying the supply chain and placing the order”). Starting later (that is, after ML2) will significantly limit the controls which can be applied. If a start is made after ML0 (for example, at ML1 or ML2) it is recommended that a check is made on all the criteria for the previous maturity levels (in this example, ML0 or ML0 and ML1) and that their status is assessed.

When starting a maturity level assurance process for a specific product to be supplied, the following points must be agreed between the customer and the supplier:

1. Specification of the level of application, depending on the risk classification, and agree on the manner in which it is to be implemented.

2. Alignment and documentation of the maturity levels to the milestones in the product creation process which has been established by the OEM or the customer.

3. Specification of the responsibilities involved in the maturity level assurance process, both on the customer’s side and the supplier’s side:

• Responsibility for contents, objectives and the planning of timings and reviews

• Establishing cross-departmental teams with agreed methodologies and forms of communication (“round tables”, see chapter 3.1)

4. Specification of scheduling:

• Generate the schedule from the overlying project schedules and product creation processes

• Communicate the schedule across the entire supply chain (see Chapter 3)

• Integrate the maturity level timings into the overall product creation process

24

• Specify planned status reports for the maturity levels, to be issued to the project control groups, i.e. control group for the project

• Specify planned completion dates for the maturity levels, including essential review/preview dates. (Recommendation: At least one review/preview date is recommended for each of the maturity levels; additional dates should be planned, depending on the results of the assessments). The review and preview can be combined for the relevant maturity level.

Fig. 2.6 Carrying out maturity level assurance in the supply chain

5. Confirmation of project objectives relating to the product to be supplied:

• Specify the measurement criteria (e.g. criteria covering electrical and electronic parts or software are not relevant to bare metal parts).

6. Agreeing on the procedure for assessing the measurement criteria:

• Papers and documents relating to the assessment should be checked by the team regarding their contents (e.g. FMEAs, QM plans, control plans, production sequence plans, layouts, etc.).

25

7. Carrying out a risk assessment for the operations in the supply chain in order to identify potentially critical paths.

8. Specification of documentation requirements for the maturity level management:

• Project documentation

• Action management

• Escalation procedure

• Reports on the maturity level status.

9. Specification of criteria for closing the project and transferring it to production (see also ML7).

2.1.3 Control

Control consists of the following steps:

• Preparation of the maturity level assessment,

• Assessment including the definition of actions in case of results deviating from the measurement criteria

• Status report to the relevant control groups for the project and confirmation of the defined actions (see Chapter 2.2)

• Implementation of the actions, demonstration of the effectiveness of the actions and assessment of the respective measurement criterion

• Post-assessment of the completed maturity levels,

and represents a repeating control loop for each maturity level.

26

2.1.3.1 Preparation

The following procedure is recommended as preparation for the maturity level assurance process:

• Obtain necessary maturity level assurances from the supply chain

• The supplier should carry out a self-assessment, including proposed actions if deviations are noted

• Confirm the date for the maturity level assessment.

2.1.3.2 Assessment

The individual maturity levels are assessed on the basis of “traffic-light” colors.

Fig. 2.7 The principle of maturity level assessment

A set of measurement criteria is allocated to each maturity level.

All measurement criteria are formulated in such a way that they can be clearly answered with a “yes” or “no”.

Each individual measurement criterion is assessed with a traffic-light color (RED, YELLOW, GREEN). The assessment criteria for the traffic-light colors are defined in Figure 2.8.

27

Fig. 2.8 Definition of traffic-light colors for maturity level assessment

The following rules apply for the maturity level assessment:

1. The achievement of all measurement criteria is indicated by a "yes" or "no". Each measurement criterion is assessed with a traffic-light color. The assessment made by the person receiving the result is the assessment which counts.

Fig. 2.9 Overall assessment of maturity level based on consumer’s assessment

28

2. Each maturity level (ML) is given an overall assessment. This overall assessment is the same as the worst assessment of any of the individual measurement criteria within that single ML.

3. If an assessment of an ML is not provided or is incomplete at the time it is due, the overall assessment of the ML is automatically set to RED and the escalation procedure is launched.

4. In the event of changes which influence the objective of the project (e.g., a change of concept, change of supplier, etc.), the influence on the preceding maturity level assessments must be assessed.

5. The assessment is carried out separately at each level of the product to be supplied. For this purpose, each next-higher level in the supply chain must assess what influence the traffic-light color has on subsequent and higher-level stages of the delivery project (see Figure 1.3).

6. If the maturity level is assessed as RED the new objectives must be confirmed by the responsible party.

7. Questions answered with “no” require follow-up actions to be defined. Clear timings and responsibilities must be specified for implementing these actions. The objective is to complete the specified actions before the next maturity level is reached and to assess their effectiveness.

8. Actions not yet completed must be tracked until the measurement criteria are assessed as GREEN. This applies in particular to uncompleted actions in the last maturity level (ML7). As long as these have not been completed, ML7 must be repeated.

Once the assessment has been completed, status reports are issued regularly to the control groups handling the project (see Chapter 2.2).

The cascade of maturity traffic lights shown in Figure 2.10 illustrates how the overall assessment of the maturity level (ML) is determined by the worst individual assessment (cf. item 2 in the rules for maturity level assessment).

29

Fig. 2.10 Example of a cascade of maturity level traffic lights

The cascade of maturity traffic lights ensures transparency and traceability of the maturity level status depending on the objective, both at all maturity levels for a component and at all maturity levels within a project.

In the vertical plane, the topmost traffic light in the cascade (Figure 2.10) automatically adopts the worst color of all the traffic lights under it. In other words, if a maturity level is not set to GREEN when the next maturity level stage is reached, this next maturity level stage automatically adopts the color of the previous one, regardless of the individual assessment:

• ML3 is assessed overall as YELLOW because the worst individual result is YELLOW (ML1 and ML3)

30

• ML4 is assessed overall as RED because the worst individual result is RED (ML4)

• ML5 is assessed overall as GREEN because all the other individual results are also GREEN.

In addition to displaying a cascade of maturity traffic lights in a single illustration which shows in full the progress of maturity levels in a project, it is also possible to measure the quality of individual processes, so that potentials for improvement can be derived (see Figure 2.11).

Fig. 2.11 Analysis of the measurement criteria for all components based on a maturity level for assessment of process quality

31

2.1.3.3 Carrying out maturity level assurance depending on the risk classification (prioritization)

For parts classified as “A” risks (prioritized) the person carrying out the assessment and the person receiving the result must assign a traffic-light color. In the case of “B” and “C” risk-classified (prioritized) parts the supplier must carry out their own assessment (self-assessment). In other words, the supplier assesses the fields in which they are producer or consumer in the same way as for “A” risk-classified (prioritized) parts. In this case, however, the customer does not carry out an assessment. The result of the assessment is then entered in the “Overall assessment” column.

For “B” risk-classified (prioritized) parts the supplier presents their assessment results and actions to the customer and the customer gives active acknowledgment of the assessment results (plausibility check).

In the case of “C” risk-classified (prioritized) parts, the supplier transmits their assessment results to the customer in the manner agreed upon.

If the maturity level risk changes in the course of work on the project, the maturity level assurance may deviate in individual cases from the “ABC” risk classification system, for example, “round table” meetings may be held for a “B” risk-classified (prioritized) part if, e.g., changes are involved which jeopardize the achievement of the project’s objectives.

2.1.3.4 Implementation

For activities carried out after the maturity level assessment, the following procedure is recommended:

• Definition of actions in order to achieve the measurement criterion, responsibility and deadline

• Demonstrate that the agreed actions have been carried out on time and effectively.

• New assessment of the criterion after confirmation of the effectiveness of the actions.

32

2.2 Status report covering maturity level, corrective actions and escalation

Significant elements to ensure the effective use of the maturity level assurance method are a reporting system (ideally standardized), agreed throughout the entire supply chain, a procedure for specifying and tracking corrective actions and an escalation procedure.

Fig. 2.12 The reporting principle in terms of hierarchy

2.2.1 Maturity level status report

The reporting - including its format and frequency - on the maturity level status throughout the supply chain is specified at the “Start” phase of the project (see Chapter 2.1.2) and will depend on:

33

a) the risk classification (see Chapter 4.1 in association with Chapter 1.2.1), and

b) the customer's requirements

The contents of the status reports are determined from the measurement criteria. A procedure must be agreed between customer and supplier for specifying and tracking corrective actions, including their documentation.

2.2.2 Escalation

Escalation is initiated by the assessment of a maturity level as "RED".

The escalation procedure in the customer’s organization and the supplier’s organization must be specified at the start of the project. The relevant responsible contact persons in the organizations' hierarchy must be named.

Escalation takes place over the entire maturity level status and according to the level of action management. It can therefore be understood by all those involved.

Fig. 2.13 Example of escalation: customer activity at the supplier's premises

34

3. Communication in the supply chain

Communication flows from the customer (OEM, Tier n) to the suppliers involved in the supply chain (Tier n +1). The customer is the driver for carrying out communication.

Rapid and prompt communication at lower levels is absolutely essential in order to ensure that on-time evaluations can be made on higher-level maturity levels, e.g. Vehicle maturity level at the OEM. This must be borne in mind by those involved when specifying the milestones.

The following figure provides an illustration of the principle of a communication cascade, based on ML2.

Fig. 3.1 The principle of a communication cascade, based on ML2

35

3.1 Exchange of information at “round table” meetings

A core element of communication in the supply chain is the introduction of so-called “round table” meetings. The “round table” meetings are attended by representatives from specialist departments, both from the customer’s and the supplier’s organization e.g.:

Quality management Production planning Development Sales Purchasing Logistics

As described above, a “round table” is a team of experts assembled on a cross-functional basis. It is important to establish the make-up of the team at an early stage and to ensure that the same expertise is represented both on the customer’s and the supplier’s side. If the "round table" is expanded in individual cases to include other specialist departments, this "mirror-image" representation should be maintained.

Fig. 3.2 “Round table" organization

36

The “round table” must not be regarded as a “separate committee” which is responsible only for maturity level assurance. It is the central steering committee between customer and supplier, dedicated to achieving the project objectives and is an integral part of the project activities. This also means that participants of the “round table” should also be involved in the project (for further types of collaboration, see VDA Volume Agile Collaboration). “Round table” meetings can be held at the customer’s premises or at the supplier’s premises and can also take place in the form of online meetings if this is agreed upon.

3.1.1 Responsibilities

Within the scope of the “round table” communication, responsible persons must be named both on the customer’s and the supplier’s side, e.g. for:

• Chairing the “round table” meetings

• The specification of the project contents and objectives

• Coordinating and organizing reviews, previews, etc.

• Action management

• The reporting of results and

• The initiation of escalation, if required

This principle (see Figure 3.1) must be cascaded in the supply chain – i.e., the customer's "maturity level officer" will sit at a "round table" with the supplier's "maturity level officer" to discuss products which have been identified as subject to risk.

37

3.2 Exchange of information via "supplier self-assessment"

3.2.1 The supplier presents their assessment and actions to the customer (“B” risk-classified (prioritized) part)

The organization and responsibilities, both for the customer and the supplier, must be carried out in a similar manner to that described for the exchange of information using the “round table” system (see Chapters 3.1.1 and 3.1.1.1). The supplier’s maturity level officer presents to the customer the result of their assessment and actions to be taken. For the customer, representatives of quality management, development, purchasing, logistics, etc. take part in this meeting. In this way the results of the assessments and actions can be communicated directly and confirmed by the customer.

3.2.2 Information provided by the supplier ("C" risk-classified (prioritized) part)

The assessment is carried out as described in Chapter 3.2.1. The results of the assessment and actions to be taken (if required) are made available to the customer’s maturity level officer in the agreed format (e.g. In the form of an Excel document or using the customer’s IT system).

The contents of the maturity level assessment and the dates when they must be provided for “C” parts will be decided by discussion and an appropriate contractual agreement with the customer. A dialog takes place between customer and supplier if it is expected that the objective will not be achieved.

3.3 Software maturity level meetings

The purpose of the software maturity level meetings is for the supplier and the customer to discuss the status of the software development. Essential participants include those involved in development and quality for the purpose of maturity level tracking and reporting (“4 eyes” principle).

38

Control takes place via the MLA maturity levels and a software-specific milestone plan including synchronization points (deliveries of functions and software releases) the timing of which - e.g. 4 times per week - is determined jointly by the customer and the supplier (see measurement criterion No. 2.7.4. In conjunction with repeat question W5.1 in chapter 4.3).

As part of the software level meetings, relevant project maturity level assessments are carried out, which essentially serve to achieve two goals.

Firstly, the maturity level and the quality of the software project at the current time are assessed, and it is made possible to predict them at future points in time. Secondly, problems can be detected and identified early on in the software project, and relevant counter-measures can be initiated.

The software maturity level meetings can be held as bilateral talks - e.g. between the customer and the supplier - but also with several internal and external participants in the spirit of agile project management using agile methods (Scrum, sprint planning, etc.).

For this purpose, the customer, for example, invites all required software suppliers (internal and external, taking the competitive situation as well as competition law/compliance into consideration) for overall coordination of software contents and software interfaces, while also chairing the meeting.

39

Fig. 3.3 Timing of software maturity level meetings, depending on release planning/software delivery

Fig. 3.4 Timing of software maturity level meetings, depending on release planning/software delivery

40

4. Standards in the process

4.1 Risk assessment and classification (recommendation)

Risk classification A, B or C Assessment Comments

1. Product-related criteria (product)

1.1 Complexity (type and number of functions, level of system integration, number of system/communication interfaces, integration of further software deliveries, number of variants (vehicle configuration), number of development partners/locations involved, ASIL classification, customer-specific, country-specific and statutory requirements

high = 2, average = 1, low = 0

1.2 Product innovation (concept, design, material, function, appearance, feel, new functions, new system/software architecture, networking in the vehicle

basically new = 2, new = 1, known = 0

1.3 Critical problems in the past (field rejects, in-house problems, warranty costs)

No. of incidents: very frequent = 2, frequent = 1, low = 0

1.4 Launch problems in the past (high number of unplanned releases)

high = 2, average = 1, low = 0

1.5 Development efforts, including software (expertise, capacity, change of development processes/methods (e.g. change to agile development), new development sites)

critical = 2, fairly critical = 1, not critical = 0

2. Production process-related criteria (process)

2.1* Process innovation

new technology for the supplier = 2, for the location = 1, none = 0

2.2* Predicted process stability (level of automation, manufacturability, manual production, production system, scrap levels)


2.3 Production facility/machinery technology (for software e.g. relevant servers, Flash equipment)

new technology for the supplier = 2, for the location = 1, no new technology = 0

2.4* Infrastructure (number and complexity of sub-suppliers, location, logistics)


2.5* Delivery/call-off times (combination of long transport distances/range of variants, JIT/JIS deliveries, several delivery locations)

Examples: JIS process, preliminary process for overseas shipments, critical or completely new process = 2, multi-stage process or new supplier = 1, established delivery process/JIT process or C parts = 0

41

Risk classification A, B or C Assessment Comments

3. Time-related criteria

3.1* Procurement times for production facility and machines (plant availability and qualification ensured by the start of process validation)


3.2* Procurement times for tools and materials (parts availability and qualification ensured by the start of process validation)

Examples: Long-running tool = 2, medium-running tool = 1, short-running tool = 0 Availability of primary materials (z. B. semiconductors, leather, etc.) critical = 2, fairly critical = 1, not critical = 0

3.3 Implementation of development efforts (including software) in accordance with the overall schedule and the quality specifications


4. Supplier-related criteria

4.1 Supplier assessment (new supplier, existing supplier: reliability of deliveries, overall reliability, sub-supplier management, compliance with process requirements regarding development/production)


4.2 New product for the supplier (product, process)

new = 2, new for the location = 1, known to the supplier = 0

4.3 New supplier production location (development, production)

new, no experience = 2, new, with experience = 1, previous or known location = 0

4.4 Supplier organization and structure (complexity of the supply chain, contact persons, availability, capacity, structure)


4.5 Problems with earlier (other) deliveries (project management, compliance with deadlines, problem management)

very frequent = 2, frequent = 1, low = 0

42

Risk classification A:

36–18 points (suggestion)

Risk classification B:

17–08 points (suggestion) Requirement: no more than 5 individual assessments of 2 points, otherwise risk classification A

Risk classification C:

07-00 points (suggestion) Requirement: no individual assessments of 2 points, otherwise risk classification B

)* not relevant for scopes of delivery only consisting of software

Risk classification A:

For software-only deliveries: 24–12 points (suggestion)

Risk classification B:

For software-only deliveries: 11–5 points (suggestion) Requirement: no more than 3 individual assessments of 2 points, otherwise risk classification A

Risk classification C:

For software-only deliveries: 4-0 points (suggestion) Requirement: no individual assessments of 2 points, otherwise risk classification B

The automatic assessment by points should be regarded as a proposal. A relevant risk assessment deviating from it is possible!

43

4.2 A-, B-, C-, D-samples

A-sample

A-samples are functional samples that are only drivable to a limited extent. They serve to illustrate the basic functions. The use on public roads is not permissible in case of products relevant for driving safety. 1. Purpose of use: Laboratory testing, simulation, test rigs, testing mules (function and/or installation space). Confirmation of the functional principle. 2. Nature of the sample: Functional samples that are only drivable to a limited extent. No statements as to service life can be derived. There may be limitations with regard to the following characteristics: Scope of functions, robustness, absence of faults/errors, dimensions, material, temperature resistance, media resistance, voltage range, EMC, appearance, feel, diagnostic capability, etc. Negative impacts on operational safety are not permissible (safety of high voltage systems, etc.). 3. Software requirements: Scope of functions and interfaces according to agreement with the customer. 4. Production: Sample production – only partly final materials and semi-finished products, auxiliary tools, modification of already existing products. General information: The respectively delivered stages must be documented in accordance with the customer’s specifications. If, within a sample phase, a further subdivision into stages/phases becomes necessary, the contractor must describe and agree on this with the customer. In that case, a number is added to the designation of the samples, e.g. A1-sample. Traceability must be ensured at any time, e.g. labeling of the samples.

44

B-sample

B-samples are functional, drivable samples made with auxiliary tools that provide sufficient operational safety for initial tests under driving conditions inside the vehicle and on the test bench. Use on public roads is possible with a special permit and once street clearance has been granted by the competent authority (e.g. KBA – German Federal Motor Vehicle and Transport Authority). 1. Purpose of use: Testing of the prototype – verification of the complete functional scope of technical requirements. Verification that product requirements have been met, durability testing including detection and elimination of remaining vulnerabilities. With these samples, the installation space, manufacturability is tested and a constructive design is specified. Start of design validation by supplier and customer (durability testing according to load profile). 2. Nature of the sample: Customer specifications are met, depending on the agreement and intended use (scope of functions, life cycle, dimensions, material, temperature resistance, media resistance, voltage range, EMC, appearance, feel, diagnostic capability, etc.). All hardware and functional requirements have been met, the samples are not yet suitable for full production in all respects. Connection and installation dimensions are in line with the scope of functions and, where appropriate, full production. Useful life may be limited due to special production. If required, components are used that are not suitable for full vehicle use. Negative impacts on operational safety are not permissible (safety of high voltage systems, etc.). 3. Software requirements: The software must allow for hardware testing and hardware use in the overall system in accordance with the release plan. Limitations with regard to the scope of software are possible. The scope of functions and the interfaces are implemented in accordance with the software specification for the intended use (diagnostic and flashing capability are ensured). 4. Production: Production does not take place under full production conditions or using full production processes (e.g. sample production). Spare parts, components have been manufactured using auxiliary/prototype tools and predominantly produced using final materials. Discrete circuits instead of hybrid circuits and customer ICs are permissible.

45

B-sample

General information: The respectively delivered stages must be documented in accordance with the customer’s specifications. If, within a sample phase, a further subdivision into stages/phases becomes necessary, the contractor must describe and agree on this with the customer. In that case, a number is added to the designation of the samples, e.g. B1-sample. Traceability must be ensured at any time, e.g. labeling the samples.

46

C-sample

C-samples are components made with production tools (first parts made with production tools). No technical restrictions that have an impact on driving safety are allowed. Use on public roads is possible with a special permit and once street clearance has been granted by the competent authority ( e.g. KBA - German Federal Motor Vehicle and Transport Authority). 1. Purpose of use: Testing for achieving technical release. Completion of design validation by supplier and customer (durability testing according to load profile). Start of process validation by supplier and customer. 2. Nature of the sample: Fulfillment of specification requirements. Deviations of surface characteristics that have no impact on functional requirements are permissible. 3. Software requirements: Software allows for full production or field load/stress for hardware and mechanics. Full production functionality implemented in accordance with the release plan, but the software specification has potentially not yet been fully satisfied. 4. Production: Production takes place with production tools and under conditions that are similar to full production conditions. Restriction/limitations as compared to the planned full production are permissible. This includes, for example, adjustments of parameters, missing interlinkage of full production. The production may still take place at the toolmaker’s or the plant manufacturer’s premises. Manufacturability in the planned full production process is confirmed. The component tests are carried out with full production test equipment or equivalent protective measures (including required tolerance limits). General information: The respectively delivered stages must be documented in accordance with the customer’s specifications. If, within a sample phase, a further subdivision into stages/phases becomes necessary, the contractor must describe and agree on this with the customer. In that case, a number is added to the designation of the samples, e.g. C1-sample. Traceability must be ensured at any time, e.g. labeling of the samples.

47

D-sample

D-samples are produced entirely with production tools and under full production conditions (parts made with production tools). Samples with which the production process and product approval process is carried out, with the aim of achieving a release for full production (PPA process).

1. Purpose of use: Testing serving to achieve release for full production (PPA process). Type approval sample for approval by a registration office, e.g. KBA (German Federal Motor Vehicle and Transport Authority), CCC, general labeling obligation. Completion of process validation by supplier and customer.

2. Nature of the sample: Usable without restrictions (suitable for full production). All quality requirements are consistently met. 3. Software requirements: Full production functionality available. Complete fulfillment of the specification requirements. Release of the software parameters in accordance with agreement with customer. Software is available in the form agreed upon with the customer and for the intended use. 4. Production: Parts from production tools and production facilities and from the production location. The process parameters and the manufacturing process correspond to those in full production, for the initial phase, parameter adjustments are possible, as long as representativity is ensured. Addition (e.g. flashing) of new software contents is done using production facilities. Testing and synchronization process have been fully implemented. General information: The respectively delivered stages must be documented in accordance with the customer’s specifications. If, within a sample phase, a further subdivision into stages/phases becomes necessary, the contractor must describe and agree on this with the customer. In that case, a number is added to the designation of the samples, e.g. D1-sample. Traceability must be ensured at any time, e.g. labeling of samples.

PPA sample

See D-sample including PPA report (see VDA Volume 2)

48

4.3 Set of measurement criteria for maturity level assessment

Overview of measurement criteria: Maturity level 0

Due date: DD/MM/YYYY

Innovation release for series development

No. ML indicator Measurement criteria Examples for evaluation criteria Producer Consumer Overall

assessment

0.1.1 Project management

Assumptions have been defined.

Assumptions relating to the location: Customer’s development and production location(s) Assumptions relating to the project: The proportions of in-house and third-party development have been defined and delimited. The project structure/collaboration model is available (development sites to be incorporated) A rough milestone plan including the critical path is available Locations for project management, requirements engineering, development and testing. The system architecture for the overall vehicle/powertrain is available. Product line, derivative, preliminary/projected quantities, proportion of special equipment, capacity/ flexibility, resource requirements (capacity requirements per department), schedules, project organization (areas of responsibility by task have been specified, ideally with names), collaboration model between the development parties has been defined. Assumptions relating to the scope: Scope of order placement, level of assembly, component schedule, potential suppliers, supply mode, packaging concept (disposable, reusable), number of variants, product life cycle including supply of spare parts (repair requirements in the series, supply after EOP), disposal concept E/E and/or software: Assumptions relating to the project: Process handbook and process map and process descriptions are available in compliance with ASPICE regulations. Has the hardware and software architecture been defined on the system and component levels? Security relevance has been assessed.

Customer Product project team

0

pplicable instructions


49


assessment

0.2.1 Innovation / concept / reliability

New, previously unknown product technologies, product applications or new characteristics, as well as new technical processes or development methods have been determined for the vehicle in question.

Project-specific “new ground”. Specification by the division responsible for technology. Previously unknown procedures in the development and manufacturing process have been named. Project risks arising from these procedures have been derived. Have all assumptions in relation to the innovation been documented? Have the new technologies been described? Are there lessons learned from predevelopment/previous projects? Are the resources for investigations regarding patent law and licensing law clear and available? Have issues or conditions pertaining to patent law and licensing law been clarified/resolved? E/E and software: Are new architectures and concepts being used for the realization? Are new software development methods being used for the realization (agile methods, agile project management) Is an established project management method used or are new project management methods used?


0

0.2.2

The innovation assessment has been finalized. The system boundaries of the innovations within the overall system have been defined. Interactions with interfaces within the vehicle are known.

Including systems, sub-systems and components, electrical, mechanical and geometric system boundaries (e.g. boundary diagram), software, etc.. Have the new interfaces between the systems and components been assessed and analyzed? Are there acceptance and approval criteria, and have these been defined and agreed? Statutory/regulatory/customer-specific requirements and requirements pertaining to functional safety (ASIL level)/cyber security have been assessed (taking into account the “state of the art”). Have requirements been determined according to the current “state of scientific knowledge”? Is a risk analysis available with regard to this? Are there already FMEA-based documents on the basis of basic development, which can be built upon on a product-specific level? Changes to the framework conditions must be taken into consideration. Is a description of the system/the system boundaries and the interactions/interfaces available? E/E and software: Have all interfaces between systems, modules and components been defined and are the associated project participants known


0



50


assessment

and involved (input/output interactions of the characteristics/components). Are there acceptance and approval criteria, and have these been defined and agreed?

0.2.3 A fundamental statement of the technical feasibility of the innovations is available.

Statement by the division responsible for technology and (where applicable) the project manager of the supplier developing the technology. The feasibility of the technical concepts has been verified based on calculations, simulations/digital verification and/or experimental samples. An initial economic assessment is available, the limits/requirements regarding feasibility have been assessed. A fundamental statement of the technical feasibility of the innovations is available, including potential risks and defined counter-measures for the mitigation of the risks. Have acceptance/approval criteria been defined? (Reference: VDA publication “Robust Production Process”, VDA Volume 4). E/E and software: Are new technologies and development systems used? Have the required system, maintenance and verification concepts been defined?


0

0.3.1 Procurement process

A procurement market analysis has been drawn up.

Assessment of the market for procuring the innovation by a cross-functional team under the leadership of the purchasing department (e.g. potential analysis in accordance with VDA Volume 6.3). Risk analysis for product availability (even after EOP) Have conditions and requirements with regard to patent law/licensing law been taken into consideration in accordance with the “state of the art” for the analysis of the procurement market? The date by which a selection of suppliers can still be made without having to consider further project risks has been determined. E/E and software: Have all required outside services/products (libraries, e.g. Qt, system software, e.g. AutoSAR) and external partners (e.g. SDK - Software Development Kit) been assessed? Have alternative concepts been identified and assessed (e.g. FOSS risk (Free and Open-Source Software))?


0



51


assessment

0.4.1 Risk management

All known influences and effects on product quality (fulfillment of the customer’s expectations) have been captured and documented.

Usage profile including all conditions of the usage market (e.g. environmental influences) has been defined. Product and process risks, at the premises both of the customer and the supplier (if already known), relating to innovations, quality, reliability, on-time readiness for series production, environment, society, public authorities, etc. are documented such that they can be referenced. Are there lessons learned/reliability statements from previous projects? (e.g. 0 km, field performance) The customer/supplier can present system and component FMEA analyses and risks for design and process. (Reference: VDA publication “Robust Production Process”, VDA Volume 6.1, VDA Volume 6.3, IATF 16949, AIAG & VDA FMEA handbook, VDA publication “Lessons Learned”, VDA publication “Product Integrity"). E/E and software: Have risk assessments including security been carried out and documented? Have reliability indicators been defined (e.g. MTTF mean time to failure)? Has a preliminary assessment of the FOSS (Free and Open-Source Software)-relevant parts been carried out? Has the availability and maintenance of the software systems used (debugging/defect and problem management, closing security gaps and/or increasing security standards throughout the project duration) been fully assessed?


0

0.4.2

Risk classification (ABC classification) has been carried out for the products to be supplied (preliminary classification).

All components are assessed without “supplier” criteria within the framework of pre-classification. (Reference: VDA publication “Robust Production Process”, VDA Volume 6.1, IATF 16949). E/E and software: ABC pre-classification was carried out for software as well.


0

0.4.3

A fall-back or alternative strategy based on validated manufacturing technology has been defined for all projects and models.

Fall-back or alternative strategies must be pursued until such time as the innovation has been validated on a project-specific basis (proof by means of functional sample). Maturity level assessment must be pursued on the basis of a risk classification for the fall-back solution. Have stop criteria been specified for “parallel” fall-back or alternative strategies? Relevant decision points for switching over to fall-back or alternative strategies to avoid additional project risks have been determined and have been taken into consideration in the project schedule. (Reference: VDA Volume 6.1, VDA Volume 6.3, IATF 16949).


0



52


assessment

0.1.2 (W1.1)

Project management

A preview has been carried out for the next maturity level (preview).

The activities required for achieving the next maturity level are known and scheduled in the project. Responsible persons have been assigned for these activities. Are there currently assessments/findings which could endanger the achievement of the next maturity level?


0



53



Requirements management for the contract to be issued


assessment


The results of the strengths / weaknesses analysis and/or lessons learned have been incorporated into both product design and production process.

Products and processes (development/product creation, production, service/after market/product use, inspection and testing processes within the framework of production and service); analysis and testing facilities considered within development (e.g. electronics: design for testability, design for analysis). Are standards and development guidelines used? Are lessons learned databases and SWOT analyses available? Can relevant issues/topics be derived from that? What where the top reasons for past recalls, cost drivers in terms of warranty costs? Which measures were implemented that are also effective for the new project? Proof of effectiveness required. How is it ensured that these measures are also applied in the new project? (Reference: VDA publication “Robust Production Process”, VDA publication “Lessons Learned”).


0

1.1.2 The customer's project organization concept is available.

Has final project planning taken place? The overall schedule, including the critical path and the key dates for the project, are available on the customer’s side. Have contact persons with tasks, competencies and responsibilities been specified (roles: project management, development, production planning, process development and planning, logistics, quality, procurement, product safety officer, etc.). Have the required resources (e.g. budget, people, ...) been defined and ensured for the project and qualified for the specific tasks? Are there qualification plans to ensure the necessary qualifications? Has a communication and escalation process and a supervisory control group/supervisory body been specified? (Reference: VDA Volume 6.1, VDA Volume 6.3, IATF 16949). E/E and software: A person responsible for functional safety and automotive cybersecurity has been named.


0

1.1.3 Data exchange formats, paths of communication and

Interfaces (systems, formats, project management tools, data exchange (e.g. 3D models, test results, etc.), System access and system responsibilities, etc. have been

Customer Product project team 0


54


assessment

the project language have been agreed.

specified. The project language has been specified (also for the interfaces, if required). Have the development tools/test tools been defined? (Reference: VDA Volume 7). E/E and software: Have the software interfaces to the test applications been specified? Have the programming languages and the compilers been defined?

1.2.1 (W3.1)

Innovation / concept / reliability

Warranty cost, reliability and field forecasts have been drawn up. Measures for achievement of targets relating to the products to be supplied have been defined.

Subitem in the component requirements specification; planning reserves; Experience gathered from current of predecessor car series (8D reports, lessons learned, benchmarks, OEM studies, independent market surveys, field monitoring) is available. Going through the 8D reports with the highest error severity (e.g. biggest cost drivers - view step D7 “Prevent Recurrence”, and check in how far these measures are applicable to the new project). Warranty periods have been specified. Test requirements for lifespan tests have been defined. Component-specific targets have been defined. E/E and software: Has there been any experience from previous projects regarding errors (lessons learned) or cyber risks in the field?


0


The released component requirements specification for the products to be ordered, including relevant technical interactions in the system and all applicable documents, is available.

The component requirements specification defines and describes the requirements regarding the products to be ordered (components, hardware including software, only software, scope of services, ...). The project schedule is available. Initial results from fundamental investigations, technology carriers and (long-term) studies have been taken into consideration (“state of scientific knowledge”) Relevant checkpoints include, e.g.: - Completeness (z. B. functional and non-functional requirements (noise, EMC, labeling, …), including applicable documents) - Scope of order placement (e.g. including software, services, …) - Package data or drawings and interfaces to other systems/components have been specified. -Assessment results/classifications based on the customer’s risk


0


55


assessment

analyses (e.g. safety and security requirements) - Patent use, licenses (e.g. Free and Open Source Software (FOSS)) - Use of parts specified by the customer - Markets in which the product is to be used - Warranty/guarantee periods have been specified - Requalification requirements/tests of conformity of production - After market strategy (spare parts, …) - Product-specific as well as general customer-specific (technical/commercial) and statutory/country-specific requirements (e.g. Component certification such as CCC, ECE, INMETRO, technical compliance, etc.) are known and have been taken into consideration. - The quality targets (e.g. reliability, quality in the field, corrosion protection requirements, residual dirt requirements, surface, function, stability/strength, etc.) are available and have been adapted and defined at the level of the products to be supplied. - Test requirements/complete testing specification for the customer and the supplier (e.g. requirements regarding service life, verifying the plausibility of testing periods in relation to the overall schedule) - The material specifications have been defined. - Special characteristics - Decorative requirements - Misuse and intended use (restriction/exclusion of use) - The requirements regarding change management have been specified (change periods) - Requirements with regard to industrialization processes (manufacturing, logistics, testing, traceability, diagnosis) - Requirements regarding project management and the development processes (e.g. ASPICE level has been defined, reporting formats, …) - The customer’s requirements for the supplier with regard to the IT tools and interfaces to the customer’s tool have been defined. (Reference: VDA publication “Robust Production Process”, VDA Volume 6.3, VDA publication “Component Requirement Specification” VDA publication “Product Integrity”, DIN 69905, VDA Volume 6.1, IATF16949, VDI/ VDE 3694). E/E and software: - Information security requirement including classification (confidential, strictly confidential) - TISAX level has been specified - The customer’s system/software architecture has been specified - Requirements regarding the use of hardware resources such


56


assessment

as processor performance and memory have been defined. - Have requirements regarding full functionality, performance, security, compatibility, usability, maintenance, etc. been derived from the customer’s assessment of the architecture and have they been incorporated into the requirement specification?

1.3.2

Order placement strategy and scope of order placement have been defined.

- Supplier pool, supplier networks defined. - Timings for order placement agreed on a cross-functional level. - The extent of parts specified by the customer, including the responsibility matrix, has been defined. The suppliers’ release criteria have been defined (e.g. risk assessments, contingency plans, financial information, required certifications of management systems (IATF, 14001, TISAX, etc.).


0

1.3.3 (W2.1)

Sales markets, market launch dates, quantities (capacities) have been specified.

●Launch curves, production peak, maximum daily output ● Model mix, optional equipment rates ● Spare part demand/CKD demand (CKD - Completely Knocked Down) ● Shift models, agreed flexibility ● Critical process elements in terms of increasing capacity ● Sales markets/countries of destination including (local) statutory requirements are defined. (Reference: VDA publication “Robust Production Process”, VDA publication “Product Integrity”).


0

1.3.4

The extent of supplies and services and areas of responsibility have been specified. Interfaces have been unambiguously defined for the scope supplies and services to be ordered.

The contents of contracts (e.g. for services extending beyond the production of parts), assignment of responsibility (e.g. issues relating to product liability and product validation) have been defined for the scope of supplies and services to be ordered. The performance spectrum of the development service provider has been defined and agreed. Interfaces to the full production supplied have been described and documented. (Reference: VDA publication “Robust Production Process”). E/E and software: All interfaces have been defined and all interface partners are known. Acceptance and approval criteria have been defined and agreed. Is there a service interface agreement, including RASI (Responsible Accountable Support Information)? The responsibilities for the release of services have been


0


57


assessment

defined, and it has been agreed in which way the releases are documented (based on which system characteristics).

1.4.1 Product development

Special (customer-specific) characteristics have been specified.

Product characteristics which are not adequately robust, which are difficult to realize in production and which, in case of deviations, have direct and severe impacts (security, law, function) can be identified as special characteristics. Special characteristics must be communicated and safeguarded in a suitable manner in the supply chain. Special characteristics have been specified on the basis of a multidisciplinary decision-making process. (Reference: VDA publication “A process description covering special characteristics (SC)”, VDA Volume 6.3, AIAG & VDA FMEA handbook, ISO 26262 Functional Safety). E/E and software: Are the requirements regarding software security, Automotive cybersecurity and information security (ISO 27001) known and taken into consideration? Have security targets been identified, relevant risks been assessed and derived system and software requirements which are relevant to ASIL been defined in accordance with ISO 26262, and are they known to all parties? Are the required certifications available, e.g. have we, as the manufacturers, defined which relevant certifications of the supplier must be available? Have the processes been aligned with these requirements and are they capable of handling special characteristics in the supply chain (i.e. characteristics relevant to safety and certification as well as requirements regarding functional safety, Automotive cybersecurity).


0

1.4.2

Concepts have been drawn up for the extent of repair, spare parts and diagnosis (applicability is determined by product complexity).

Subitem in the component requirements specification; regulations governing the contractually agreed supply of spare parts in terms of supply, tool location transfer and production of spare parts (e.g. defining the scope of sampling inspections for spare parts). Requirements regarding the field failure analysis process and related to the products to be supplied have been determined. (Reference: VDA publication “Robust Production Process”). E/E and software: Is there an error analysis and error elimination process in order to identify and lastingly eliminate software errors?


0


58


assessment

Have the required diagnostic functions been fully described and implemented? The possibility of over-the-air updates has been taken into consideration. Update intervals for security updates have been specified.

1.5.1 Supply chain/supply of parts

Alternatives to the supply concept have been assessed; the logistics requirements have been drawn up.

Supply concept: in stock, JIT (Just In Time), JIS (Just In Sequence). Packaging concept: disposable, reusable (universal/special). Incoterms (International Commercial Terms): e.g. DDU (Delivered Duty Unpaid)/FCA (Free CArrier). Packaging/supply concept takes into account corrosion protection requirements and residual dirt requirements, special packaging material for sensitive surfaces and ESD protection. Fire protection and safety regulations for special electronic components (e.g. lithium ion batteries) have been taken into consideration. Special storage conditions (temperature, air humidity, minimum storage life of sensitive components, etc.) are specified.


0

1.6.1 Product validation

The functionality of the innovation has been verified within the overall system (A-sample).

The functionality of the innovative component has been verified based on calculations, simulations/digital verification and/or function and experimental samples in the product (vehicle/sub-system/system/digital prototypes) or testing mule based on a predecessor and modified for the purpose of testing the innovation. The production of samples is done by means of sample/prototype production, only partly final materials and semi-finished products, auxiliary tools, modification of already existing products.


0

1.6.2

The simulation and test / trial planning to validate product quality has been specified.

Customer-supplier relationships have been considered (where these are known in the supply chain); testing: Virtual and real testing. Test planning is done on the basis of the released component requirements specification. Testing periods for design verification/product validation and system tests have been defined and coordinated with the release planning. The verification tests from comparable previous projects in accordance with the FMEAs are transferable and applicable to the current project. Which currently required tests are not available and must additionally be implemented? A work plan must be established for this (effort/cost, acceptance criteria, responsibilities, etc.). The quantity, purpose of use and the use dates of prototypes


0


59


assessment

have been specified. E/E and software: The required simulations/reference models have been specified. The AKV (German abbreviation for: tasks, authority, responsibility) within the project have been clarified and confirmed (software simulation/HIL/vehicle test). The test planning takes into account the delivery of software in accordance with the defined release plan.


A product risk assessment has been carried out.

Risk assessment with the focus on the product (e.g. innovations) using methods acknowledged within the automotive industry (e.g. ABC analysis, critical path in accordance with VDA publication “Minimizing Risks in the Supply Chain”, FMEA, design reviews). (Reference: VDA publication “Robust Production Process”, AIAG & VDA handbook). Which preventative measures have been implemented and can be applied in order to avoid the causes of the highest risks? Which preventative measures cannot be realized and thus lead to risks for the OEM, the end user, as well as risks regarding legality and warranty and goodwill costs? Project risks based on the status of the supplier selection have been identified and confirmed in the project. Relevant actions have been defined. Risks of not achieving the project objectives due to the selected suppliers have been determined, and additional measures have been specified accordingly. E/E and software: Software has been taken into account in the system and design FMEA, risk management has been implemented and is updated on a regular basis (see also MAN.5 ASPICE model). Parts from existing software architectures were tested and assessed regarding their operability in the target environment. Cyber security has been taken into consideration.


0

1.7.2 Interfaces to other projects andcomponent applications have been clarified.

The influence and interactions (e.g. tolerances, EMC compatibility, etc. ) arising from other projects /deliveries have been analyzed, communicated and evaluated (e.g. Identical or carry-over parts). Timing and content requirements regarding other applications have been determined, assessed and taken into consideration in the project plan.


0


60


assessment

E/E and software: Interfaces and interface partners have been documented and agreed upon, including AKV (German abbreviation for: tasks, authority, responsibility).

1.7.3 (W1.2)

Points outstanding from previous maturity level assessments have been closed (review).


0

W1.1 (0.1.2)

Project management




0


61



Specifying the supply chain and placing the order


assessment


The component requirements specification and all applicable documents are available, have been examined and checked by the supplier and submitted to the customer with comments.

Important checkpoints include, e.g.: - Completeness (z. B. functional and non-functional requirements (noise, EMC, labeling, …), including applicable documents) - Scope of order placement (e.g. including software, services, …) - Package data or drawings and interfaces to other systems/components have been specified. -Assessment results/classifications based on the customer’s risk analyses (e.g. safety and security requirements) - Patent use, licenses (e.g. Free and Open Source Software (FOSS)) - Use of parts specified by the customer - Markets in which the product is to be used - Warranty/guarantee periods have been specified - Requalification requirements/tests of conformity of production - After market strategy (spare parts, …) - Product-specific as well as general customer-specific (technical/commercial) and statutory/country-specific requirements (e.g. Component certification such as CCC, ECE, INMETRO, technical compliance, etc.) are known and have been taken into consideration. - The quality targets (e.g. reliability, quality in the field, corrosion protection requirements, residual dirt requirements, surface, function, stability/strength, etc.) are available and have been adapted and defined at the level of the products to be supplied. - Test requirements/ complete testing specification for the customer and the supplier (e.g. requirements regarding service life, verifying the plausibility of testing periods in relation to the overall schedule) - The material specifications have been defined. - Special characteristics - Decorative requirements - Misuse and intended use (restriction/exclusion of use) - The requirements regarding change management have been specified (change periods) - Requirements with regard to industrialization processes (manufacturing, logistics, testing, traceability, diagnosis) - Requirements regarding project management and the

Supplier Customer

0

62


assessment

development processes (e.g. ASPICE level has been defined, reporting formats, …) - The customer’s requirements for the supplier with regard to the IT tools and interfaces to the customer’s tool have been defined. In case of request according to drawing: The complete dataset is available (and/or drawing). (Reference: VDA publication “Robust Production Process”, VDA 6.3, VDA publication “Component Requirement Specification” VDA publication “Product Integrity”, DIN 69905, IATF16949). E/E and software: - Information security requirement including classification (confidential, strictly confidential) - TISAX level has been specified - The customer’s system/software architecture has been specified - Requirements regarding the use of hardware resources such as processor performance and memory have been defined. - Have requirements regarding full functionality, performance, security, compatibility, usability, maintenance, etc. been derived from the customer’s assessment of the architecture and have they been incorporated into the requirement specification?

2.1.2

A component requirements specification finally agreed between the customer and the supplier is available.

All outstanding issues (including requirements from the applicable documents) have been clarified between the customer and the supplier based on a list of deviations. The agreed status constitutes, among other things, the binding definition of the scope of order placement and forms the basis for the start of change management. The scope of supplies and services and the areas of responsibility have been defined; interfaces have been unambiguously defined for the scope of supplies and services. In case of request according to drawing: The complete, finally agreed dataset is available (and/or drawing). (Reference: VDA publication “Robust Production Process”, VDA publication 6.3).

Customer Supplier

0

2.1.3

A system/software architecture has been specified and forms the basis for implementation.

- An architecture review (e.g. based on use cases) has been carried out. - The connection between the specification, design and detailed design is recognizable. - The source code is created based on the design and commented on based on the requirements.

Customer Supplier

0

63


assessment

- The operability of parts from existing software architectures in the target environment has been confirmed.


A quotation by the supplier, meeting the requirements for order placement, has been submitted to the customer.

Within the framework of the contract review, the supplier must examine, confirm and document the manufacturing feasibility of the planned scope of delivery, including a risk analysis (covering both the tooling and manufacturing concept). All the documents for the development contract have been agreed (e.g. component requirements specifications, contractual content (including sustainability in the supply chain, assignment of responsibility, quality assurance agreement (including warranty agreement and confidentiality agreement) etc.). Logistics requirements (e.g.: delivery concept (warehouse, JIT (Just In Time), JIS (Just In Sequence)), safety stock (e.g. stockpiling semiconductors, special storage and security conditions, etc.) have been taken into consideration. (Reference: VDA publication “Robust Production Process”, VDA publication 6.3, IATF 16949). E/E and software: The quotation takes into account all software-specific aspects (development, test, integration). The software tool chain (e.g. modeling tool, compiler, static code analysis, test environment) has been agreed between the customer and the supplier. Automotive cybersecurity: The TISAX certification is available. The customer’s information security requirements, including classification (confidential, strictly confidential), have been taken into consideration. Secure coding guidelines have been specified by the contractor and confirmed by the customer.

Supplier Customer

0

2.2.2 Legally sustainable order placement has taken place on time.

Commercial agreements relating to the project have been reached (e.g. production locations, the supplier’s logistics, material prices, cost allocation for tools, allocation of development costs, test equipment (gauges and templates, etc.), shipping containers (special load carriers/alternative packaging)/shipping container development, service materials, training requirements, launch management). Features: - Nomination letter - Development and delivery agreement - Conclusion of purchasing contract.

Customer Supplier

0

64


assessment

Late orders must be documented separately should they lead to deviations between the supplier’s project schedule and the customer’s overall schedule. In case of request according to drawing: Legally sustainable order placement must take place on time and on the basis of the complete, finally agreed dataset (or drawing). E/E and software: The specification of the TCR (tasks, competence, responsibility) for development, tests, integration has taken place, and contracting parties have been named.

2.2.3

Nomination of direct order placements specified by the customer has been carried out.

Customer specifies - sub-contractors respectively - supply sources (e.g. “nominated suppliers”, “customer directed suppliers”). AKV (German abbreviation for: tasks, authority, responsibility) in the network and interfaces have been clarified, coordinated and agreed upon (e.g. Sample submissions, warranty & goodwill,...). (Reference: VDA publication “Robust Production Process”, VDA publication 6.3). E/E and software: Software and software tools (Tier n) which are purchased directly by the customer are known to the supplier and agreed upon with the customer.

Customer Supplier

0

2.3.1 (W2.2)

Supply chain/supply of parts

The relevant supply chains have been specified and reviewed with respect to their critical paths.

Measures have been derived and scheduled. Responsibilities have been assigned. Locations, suppliers, relocations, logistics concepts (Tier 2 to Tier n). Supplier provides evidence of a consistent supply chain management concept (supplier nomination process, definition of critical suppliers, monitoring, delivery performance, supplier enablement/deviation management). The sustainability of the supply chain is ensured. The sub-supplier is aware of the customer’s requirements and has accepted and confirmed them. - All activities by sub-suppliers are monitored during the development phase. - Regular communication takes place regarding project progress, deadlines and risks.

Supplier Customer

0

65


assessment

- Requirements and technical feasibility are regularly discussed. - Audits and joint reviews at the sub-suppliers’ premises are carried out. - The sub-supplier is aware of the customer’s requirements and has accepted them. Knowledge which is gained during the supplier selection process and which indicates project risks is taken into consideration regarding its impact on deadlines and expected maturity levels. (Reference: VDA publication “Robust Production Process”, VDA 6.1, VDA Volume 6.3, IATF 16949). E/E and software: Automotive cybersecurity: The relevant systems and applications for the processing and storage of cryptographic material have been specified and checked for critical paths (in relation to IT security) in accordance with end-to-end protection. The classification of the information is specified.

2.3.2

DELIVERY FOR FULL PRODUCTION: The supply and packaging concept (including Incoterms) has been defined between the customer and the supplier.

Supply concept: in stock, JIT (Just In Time), JIS (Just In Sequence). Packaging concept: Disposable, reusable (universal/special); packaging and delivery concept takes into account corrosion protection and requirements regarding residual dirt, special packaging material for sensitive surfaces and ESD protection. Fire protection and safety regulations for special electronic components (e.g. lithium ion batteries) have been taken into consideration. Special storage conditions (temperature, air humidity, minimum storage life of sensitive components, etc.) are specified. Incoterms (International Commercial Terms): e.g. DDU (Delivered Duty Unpaid)/FCA (Free CArrier). (Reference: VDA Volume 19.1, VDA Volume 19.2).

Customer Supplier

0

2.3.3

SUPPLY OF SPARE PARTS: The supply of parts is assured throughout the life-cycle and agreed by contract, or product cycles of standard components, discontinuation deadlines, etc. are known and have been taken into consideration. Need for development is known and has been communicated.

Development requirement in view of changes in semi-conductor supplies, particularly for life-cycle-sensitive components (e.g. ICs, memory chips, semi-conductors, etc.) to decide on components which may be substituted. Development requirement: Necessary outlay (costs, capacity, expertise, time required) during the development process. Special storage and safety conditions, minimum storage life in case of storage, storage and stocking of spare parts, etc. have been taken into consideration. (Reference: VDA Volume 19.1, VDA Volume 19.2). E/E and software:

Supplier Customer

0

66


assessment

The form and the scope of software support have been contractually agreed - even after EOP; a concept for software adjustment, e.g. in case of component cancellations by the sub-supplier, is available.

2.4.1 (W1.3)

Project management

The project organization has been specified with contact persons on the customer’s side.

Resources/capacities, roles and tasks (project management, development, production planning, process development and planning, logistics, quality, procurement, ...). An agile project organization/agile project management with the respective roles (e.g. product owner, SCRUM master) has been established, if possible. The AKV (German abbreviation for: tasks, authority, responsibility) within the project have been clarified, and representatives have been named. Required persons responsible for security and product safety have been confirmed. Automotive cybersecurity: Roles and responsibilities within the scope of information security have been defined an are known. An information security system has been implemented and is operating effectively.

Customer Supplier

0

2.4.2 (R1.3)

The project organization has been specified with contact persons on the supplier’s side.

Resources/capacities, roles and tasks (project management, development, production planning, process development and planning, logistics, quality, procurement, ...). An agile project organization/agile project management with the respective roles (e.g. product owner, SCRUM master) has been established, if possible. The AKV (German abbreviation for: tasks, authority, responsibility) within the project have been clarified, and representatives have been named. Required persons responsible for security and product safety have been confirmed. (Reference: VDA Volume 6.3). Automotive cybersecurity: Roles and responsibilities within the scope of information security have been defined an are known. An information security system has been implemented and is operating effectively.

Supplier Customer

0

2.4.3 Escalation rules / procedures have been specified.

Escalation within the project. Escalation rules have been agreed at both the customer’s and the supplier’s premises and communicated in the supply chain.

Customer Supplier 0

67


assessment

Refer to the methodology description in the text section of the VDA publication “Maturity level assurance for new parts”. (Reference: VDA publication “Robust Production Process”, VDA publication 6.3).

2.4.4

Data formats/documents, communication paths and the project language have been specified.

It must be ensured (e.g. by the supplier) that up-to-date versions of all the necessary documents (drawings, standards, test and delivery specifications) to the latest, current level are subsequently available at the production locations in the agreed language. The classification of the exchanged documents with regard to know-how and information protection has been specified.

Customer Supplier

0

2.4.5

The project schedule relating to the products to be supplied has been drawn up, agreed upon and released.

Takes account both of vehicle/sub-system specific data and data concerning the products to be supplied (maturity level deadlines, provision of prototype components, planning and procurement releases, PPA samples, etc.). (Reference:VDA Volume 6 Part 3). Schedule for samples phases/versions regarding software are known - Release planning (SYS, HW, SW, mechanics) - Samples phases - Product validation and release periods have been taken into account (Design Validation (DV)/Process Validation (PV), samples inspection)

Customer Supplier

0

2.4.6 (W1.4)

Deviations from the project targets at the level of the products to be supplied have been checked and highlighted, and measures have been defined.

→ Dates and deadlines (component, tools, facilities, other project deadlines) → Costs → Weight → Functionality (Reference: VDA Volume 6.1, IATF 16949, VDA publication “Robust Production Process”). E/E and software: Deviations from the release plan/FROP (Feature Rollout Plan). - Status metrics (comparison TARGET/ACTUAL) - 100% of the features are tested for each release. - Execution of tests for each release has been included as an integral part of the project plan. - A process for the internal release of release stages has been implemented and takes the customer’s requirements into account. - Aspects which have not been implemented in accordance with the agreed release plan or by the deadline have been named, and actions, target deadlines, as well as persons responsible for

Supplier Customer

0

68


assessment

the actions have been determined. The impact on the further implementation planning has been taken into consideration. Deviations from the specifications in terms of the consumption of resources (e.g. storage capacity/usage, processing power used) have been documented, and actions have been defined accordingly. Deviations from the specifications with regard to software creation have been documented, and actions have been defined.

2.4.7 (W1.5)

Interfaces to other projects and component applications by the supplier and customer have been clarified.

The influence and interactions (e.g. tolerances, EMC compatibility, etc. ) arising from other projects /deliveries have been analyzed, communicated and evaluated (e.g. Identical or carry-over parts). Multiple use e.g. in different series/products must be defined. A project management communication matrix is known and accepted by all parties. Interfaces to other modules within the same component or to other components are known.

Customer Supplier

0

2.4.8

The strengths and weaknesses analysis and lessons learned documentation have been updated. Actions have been derived.

The focus lies on the product and the process. Relevant processes from all affected departments (e.g. Diagnostic, spare parts, assembly and FMEA processes, all types of validation processes etc.). (Reference: VDA publication “Robust Production Process”, VDA publication “Lessons Learned”). E/E and software: A software risk assessment is available. Have requirements regarding functional safety and cyber security been derived and have they been taken into consideration?

Customer Supplier

0

2.5.1 Process development

The manufacturing validation planning for production processes to validate process quality has been specified.

Supplier provides evidence to show that he controls the technology with respect to manufacturing under full production conditions. → process innovations in particular. (Reference: VDA Volume 6.3, VDA publication “Robust Production Process”). E/E and software: A procedure has been defined in order to reach the ASPICE level specified by the customer (schedule and actions). Internal and/or external ASPICE assessments are planned. Automotive cybersecurity:

Supplier Customer

0

69


assessment

A procedure has been defined in order to reach the TISAX level specified by the customer (schedule and actions). Where appropriate, internal audits for process assessment have been planned (i.e. are the processes capable of meeting the requirements regarding the product - e.g. suitable tests for software functions).

2.5.2 Buildings and infrastructure are available.

Are new construction measures or renovation measures required with regard to the project and are they relevant? Based on the project, which requirements can be defined for the building/infrastructure? Have these requirements been taken into consideration in the planning of the new construction measures/renovation measures? In the case of new/modified buildings, the progress of building work must be monitored within the framework of the project. Attention must be given to critical approval procedures (electro-plating, coatings, etc.). Measuring chambers, laboratories and function testing rooms comply with the product-specific requirements (e.g. measuring volume, air conditioning, clean room requirements, ESD requirements, fire protection equipment, etc.) if required, TISAX-compliant design of buildings and infrastructure (means of access, etc.). (Reference: VDA Volume 6.3). E/E and software: All necessary IT environments to support the development processes are available and are used. Necessary drivers and software modules for development, such as - Test vehicles, test boards, equipment are approved. Interfaces between purchased software modules and drivers are documented. - Processes and the use of tools have been clarified and are implemented - The availability of the development environment and the necessary support are ensured throughout the product life cycle. - For system tests, a test environment is available with which the overall system can be tested using external interfaces. - The testing environment simulates nearly all external interfaces of the software - so situations can be simulated which cannot be or are difficult to be provoked respectively simulated by real system components. - It is possible to test single software modules with the testing environment.

Supplier Customer

0

70


assessment

Automotive cybersecurity: All necessary IT environments and systems for handling and processing cryptographic material are available and in use. - Cryptographic keys shall be protected according to the state of the art (e.g. NIST SP 800-57) while in transit and at rest - Idle timeouts shall be configured, after which re-authentication is required according to the state of the art. - Applications handling and storing cryptographic material shall be hardened and patched according to the state of the art. - Systems which must handle and store cryptographic material must use up-to-date antivirus software that has been configured according to best practices.

2.5.3

Joint specification of quantities, deadlines and intended purpose for tools for prototypes, small batches and full production has taken place.

Schedule (including the definition of running times for long, medium and short-running tools) determined by working backwards from the project schedule. Release and qualification periods for tool loops have been taken into consideration. Checked and released by the customer. (Reference: VDA Volume 2).

Customer Supplier

0

2.5.4

Coordination and optimization loops for tools for prototypes, small batches and full production from the supplier have been planned, scheduled, agreed and laid down in the component schedule. Prototype tools have been ordered and started in accordance with the schedule.

Refers to the various sample phases (standard control loops and - if time allows - other recursions) according to a current optimization method Release and qualification periods for tool loops have been taken into consideration.

Supplier Customer

0

2.5.5 Traceability for software project documentation is ensured.

E/E and software: - Configuration management: - A change history (analogous to part history) is defined for each document within the project and will be implemented (schedules, documentation, process descriptions). - The management of versions is implemented. - Traceability between requirements and code and test result is ensured.

Supplier Customer

0


Risk classification (ABC classification) for supplier / products to be supplied has been updated.

Combining product risk with supplier risk to obtain overall risk: Measures/follow-up processes are derived and agreed with the supplier. (Reference: VDA Volume 6.1, IATF 16949, VDA Volume 6.3).

Customer Supplier

0

71


assessment

E/E and software: ABC classification was carried out for software as well.

2.6.2

Risk assessment of the manufacturing process (with the focus on manufacturing process innovations) has been carried out.

Risk management with the focus on the manufacturing process. → validation records e.g. system FMEA process, planned actions/alternatives. (Reference: AIAG& VDA FMEA handbook, VDA Volume 6.1, VDA Volume 6.3, IATF 16949, VDA publication “Robust Production Process”).

Supplier Customer

0

2.6.3

A fall-back or alternative strategy based on validated manufacturing technology / software architecture has been updated for all projects and models, based on the status of the innovation validation. The date of the final decision as to when the innovation is validated has been defined.

Fall-back or alternative strategies must be pursued until such time as the innovation has been validated on a project-specific basis. If required, maturity level assessment must be pursued on the basis of an ABC analysis for the fall-back solution. Relevant decision points for switching over to fall-back or alternative strategies to avoid additional project risks have been determined and have been taken into consideration in the project schedule. Have stop criteria been specified for “parallel” fall-back or alternative strategies (see DVP - Design Verification Plan)? Also for the phases after EOP - service and supply of spare parts. E/E and software: Alternative architectures and implementations must be tested. The alternative to be realized must be specified on the basis of defined criteria and the decisions must be documented.

Supplier Customer

0


An interface analysis (e.g. System FMEA) for prioritized supplies and services has been carried out.

The focus lies on considering the product in the vehicle environment. (Reference: VDA Volume 6.1, VDA Volume 6.3, IATF 16949, AIAG & VDA FMEA handbook).

Customer Supplier

0

2.7.2

The planning of tests/trials takes account of all the features laid down in the component requirements specification.

1.) Applies to both virtual and real tests and trials. 2.) The emphasis is on the system, sub-system and component, including their interactions. 3.) Implementation planning defined for software components. 4.) Feedback of results from customers to suppliers must be assured throughout the entire supply chain. Knowledge (e.g. regarding weathering) acquired from failures in the field (predecessor vehicles) must be included in the inspection and testing plan. Changes during the tests must be documented between the supplier and the customer and must be realized in one of the following construction stages within the scope of the change management process.

Supplier Customer

0

72


assessment

Qualification periods for the respective sample phases have been taken into account. Are all system and component verification tests available at the company, and can they be implemented? Are all deviations of physical variables captured, in accordance with the analyzed failure modes (FMEA)? Which tests are missing? An analysis of the gaps in the verification phase must be carried out and shown. 1. Testing under the ambient conditions specified in the functional specifications. 2. Results from EMC, temperature, start-up/shutdown and under-voltage performance tests. 3. Attention must be given to the availability of third-party components. (Reference: VDA Volume 6.3). E/E and software Software tests have been included in the project plan as an integral part of software releases and system releases, and the relevant capacities have been planned (VDA Volume 6 Part 3). For all specified software requirements, suitable test cases have been defined and have been taken into consideration for the inspection and testing plan (related to the release).

2.7.3

Electric / electronic release planning has been agreed between the customer and the supplier.

Which E/E features (functions perceived by the customer and system functions such as, for example, speed indication, ABS, electronic stability program, rain/light sensor, automatic distance regulator, etc.) appear at which points in the agreed project time schedule? (Feature rollout plan). The feature rollout plan takes into account the functionality/functions and their use in the overall system (group of/interaction between several suppliers and systems/components, e.g. brake system, instrument cluster, sensors, airbag control units, etc.). A sufficient number of vehicles/testing mules are made available. The future development plan and variants have been taken into consideration in the feature rollout plan. The customer’s requirements (basic driving functions, ...) are fulfilled. A detailed release plan is available (release stages have been

Customer Supplier

0

73


assessment

defined, e.g. street release). The software delivery process and necessary infrastructure have been specified. The required documents have been defined. The supplier confirms the implementation of the release plan and takes this into consideration for project scheduling. Qualification periods for the respective sample phases have been taken into account.

2.7.4 (W5.1)

The software maturity level meetings have been planned and the aspects to be discussed regarding the maturity level of the product/process have been specified. The results from the software maturity level meetings are available.

Milestones and synchronization points have been coordinated with the system and overall project planning (deliveries of functions and software releases). Use of agile methods, agile project management (e.g. sprint planning) - invitation of all software suppliers (internal end external, taking into account the competitive situation as well as competition law/compliance) for overall coordination of software contents and interfaces by the customer. (Product: e.g. the stipulated reviews regarding the software development documents were carried out by independent persons (checks against architecture, standards and guidelines), the correct configuration and use of standard software modules has been proven, model tests were conducted in accordance with the requirements. Software development process: e.g. static code analyses were conducted for each software delivery and assessed based on the respective stage of development). The software maturity level meeting has been documented accordingly, and the documentation is available to the participants (actions, next dates and deadlines, other agreements). (Reference: VDA publication "Agile Collaboration").

Supplier Customer

2.7.5

The complete sample/prototype production and delivery process has been agreed.

Quantity, delivery point and intended purpose are known and have been communicated. Samples, prototypes, test models, etc. (sample levels, development status, scheduled deadlines, quantity, place of delivery for products based on the general/component schedule and intended purpose and restrictions, if applicable). The development level includes the parts level, the place of production, the manufacturing methods. Recipients of parts have been named. Samples including release level requirements (prototype parts, release stages). (Reference: VDA Volume 6.1, IATF 16949, VDA Volume 2).

Customer Supplier

0

74


assessment

2.7.6 (W5.2)

Error management has been established. Bugs (software) are tracked effectively until they have been fixed.

Errors/bugs subject to mandatory reporting must be listed in an error list and compared/checked together with the supplier and included in a customer error database. The customer and supplier must jointly define what constitutes bugs/errors subject to mandatory reporting. The results must be available in a documented form. Each bug/error must be given a unique identifier for precise identification (“ticket). Each bug has been classified according to its severity/priority level (e.g. categorization according to relevance in terms of safety or homologation, impact on level of comfort, ... A, B, C error). A complete overview of the known bugs for the products to be supplied, including the classification, is available.

Customer Supplier

0

2.8.1

PPA (production process and product approval)

All the tests and testing dates for verification of the initial sample inspection have been agreed with the supplier in accordance with the customer’s requirements (e.g. component requirements specification).

Content, quantity, scope and nature of the tests (e.g. weathering or penetration testing, ...) required for a successful initial sample inspection (normal procedure) including time scheduling and release periods. Planning, scheduling and conducting the coordination meeting for the PPA process. (Reference: VDA Volume 6.3, VDA Volume 2).

Customer Supplier

0

2.9.1 Process validation

The measurement / test concepts and inspection / test plans for the product which refer to the production process have been agreed between the supplier and the customer, and have been scheduled as well as documented, taking into account the complete potential delivery chain.

Consistent stipulations concerning mounting/reference points, special and other (e.g. attributive) characteristics are available in a documented and agreed form (concept, detailed measurement/test plan is available at the latest once the production control plan is available). Approach regarding the definition of boundary samples (e.g. decorative requirements) has been specified. (Reference: VDA Volume 5, VDA Volume 16 “Decorative Surfaces”, VDA Volume 6.3, VDA Volume 2).

Supplier Customer

0

2.9.2

The requirements regarding the integration process (software) have been specified on the overall product level.

The process of integration into the overall product/overall system has been agreed between the customer and supplier (e.g. integration of software from multiple suppliers (internal and external) into one control unit).

Customer Supplier

0

2.10.1 (W4.1)

Change management

Change management for changes to the product and the process has been agreed between the customer and the

Communication, contact persons, procedure, committees, systems, language, documentation, exchange formats and deadlines have been specified (for all technologies: Mechanical engineering, electronics (hardware and software)). If no coordinated change management system is specified, refer

Customer Supplier

0

75


assessment

supplier in the entire supply chain.

to the reference document on electronic systems issued by the German Electrical and Electronic Manufacturers’ Association (ZVEI) for electronic hardware. Changes to processes include, for example, changes of location, changes to manufacturing processes, service providers, IT-related changes, construction work (changes to internal supply processes) - Changes are assessed with regard to their feasibility - A risk and impact analysis is conducted for the changes that have been carried out in order to adjust the testing. (Reference: VDA publication “Robust Production Process”, VDA publication 6.3). E/E and software: - Costs, timeline & responsibilities for security updates have been clarified

W1.1 (0.1.2)

Project management



Customer Supplier

0

W1.2 (1.7.3)

Points outstanding from previous maturity level reviews have been closed (review).

Customer Supplier

not relevant not relevant not relevant

R2.1 (1.3.3)


Quantities (capacities) have been updated.

● Launch curves, production peak, maximum daily output ● Model mix, optional equipment rates ● Spare part demand/ CKD demand (CKD – Completely Knocked Down) ● Shift models, agreed flexibility ● Critical process elements in terms of increasing capacity The quantities (capacities) have been communicated to the sub-supplier. (Reference: VDA publication “Robust Production Process”, VDA publication ”Product Integrity”).

Customer Supplier

0

Supplier Customer 0

76


assessment

W3.1 (1.2.1)


Warranty cost, reliability and field forecasts have been drawn up. Measures for achievement of targets relating to the scope of supplies and services have been updated.

Experience gathered from current of predecessor car series (8D reports, lessons learned, benchmarks, OEM studies, independent market surveys, field monitoring) is available. Going through the 8D reports with the highest error severity (e.g. biggest cost drivers - view step D7 “Prevent Recurrence”, and check in how far these measures are applicable to the new project). Warranty periods have been specified. Test requirements for lifespan tests have been defined. Component-specific targets have been defined. E/E and software: Has there been any experience from previous projects regarding errors (lessons learned) or cyber risks in the field?

77



Release of technical specifications


assessment


The product development status meets the requirements laid down in the component requirements specification/functional specification. Technical specifications have been released.

TECHNICAL SPECIFICATIONS are a comprehensive description of a component (or software) including: - Data model release - Drawings/data model (e.g. Surfaces, radii, gap quality, component interfaces, characteristics relevant for certification and specified by the customer (e.g. CCC, ECE, INMETRO, etc.). - Standards - Dimensioning,/functional dimensions - Confirmation of special product characteristics (e.g. interface/connection characteristics) - Material requirements and material compatibility - Design requirements (color, material, grain finish, gloss) - Quality requirements - Part identification - Handling error safety study for the product - Specified scope of spare parts and repair concept - Corrosion protection concept - Cleanliness requirements/technical cleanliness E/E and software: Requirements pertaining to software creation are known and have been fully taken into consideration in the specification documents for the products to be supplied. - Requirements regarding cyber security and compliance with the General Data Protection Regulation (GDPR). The measurable output of the system/the component has been defined, and physical target values have been specified. (Reference: DIN 69905, VDA Volume 6 .1, VDA Volume 6.3, IATF 16949, VDI/VDE 3694, VDA publication “Component Requirement Specification”, VDA Volume 19.1, VDA Volume 19.2, VDA publication “A process description covering special characteristics”).

Supplier Customer

0


Concept and scheduling for the production tools for the products to be supplied are agreed and confirmed.

E.g. Stipulations relating to such details as the positions of tool split lines, connecting systems, positions of ejectors, slides, and inserts are defined jointly. The same may also apply to non-production tools, which serve only to safeguard the launch. Concrete tool schedules have been agreed between the supplier and the toolmaker. A maintenance concept for production tools is available. The customer’s specifications regarding the production of tools

Supplier Customer

0

78


assessment

have been taken into consideration in the supplier’s plans. The required toolmakers have been specified. Impacts of the transfers of tools to the production location on the schedule, including periods of requalification have been assessed and have been taken into account for project scheduling. (Reference: VDA publication “Robust Production Process”, VDA publication 6.3).

3.2.2

The schedule is available for new and modified factory facilities at the supplier’s premises for the supplier’s scope of supply.

e.g. paint shop, galvanizing plant, production facilities. Procurement/relocation times including qualification periods for the facilities have been taken into consideration. (Reference: VDA Volume 6.3).

Supplier Customer

0

3.2.3

The schedule is available for new and modified factory facilities at the customer’s premises which may potentially affect the supplier’s scope of delivery.

Particularly those affecting function, production and logistics concepts. E.g. assembly facilities, end-of-line test rigs, etc. Procurement/relocation times including qualification periods for the facilities have been taken into consideration.

Customer Supplier

0

3.2.4

Requirements relating specifically to production facilities for the products to be supplied have been specified.

PRODUCTION FACILITIES: All facilities or parts thereof which are used to produce, modify, test, transport, store and assemble the customer’s products (e.g. machines, plants, tools, fixtures, inspection, measuring and test equipment). The customer’s requirements with regard to production/test equipment and the manufacturing/testing process have been taken into consideration in the supplier’s plans. The material flow and process layout as well as a list of production equipment to be procured are available. (Reference: VDA Volume 6.3, VDA Volume 6.4).

Supplier Customer

0

3.2.5 Traceability regarding code and releases have been defined and agreed (software).

The following documents, among others, are managed by configuration management: Source code, test cases and results, specifications, designs, review records. - Configuration management supports, among other things, the management and maintenance of identical software modules in several variants and series. - A change history describes who made which changes when (possibly references to the features implemented/requirement fulfilled, change requests and bug fixes). - For each release, all valid documents and work results can be restored. - Baselines are planned.

Supplier Customer

0

79


assessment

The software tool chain including automatic code generation is agreed upon and observed by the customer and the supplier.


Orders for samples (prototype parts) have been placed according to the schedule, or samples are available.

In the orders, details of sample design and execution (e.g. functionality, mechanical properties, quality requirements, e.g. visual appearance, feel) must be specified in accordance with the planning status/release plan and the intended use (e.g. HIL, vehicle tests). For software: Levels of integration have been specified.

Customer Supplier

0

3.3.2

The functionality of the product (including innovations) has been demonstrated by the supplier (B-sample).

Geometric, functional verification (of mechanical systems, E/E and software) in accordance with the agreed release and test plan. For example, based on: - material analyses (low flammability) - samples - calculations - simulations/digital prototypes - tolerance analyses - safeguarding functionality under extreme climatic/environmental conditions, in accordance with the agreed validation plan based on the requirements specification, etc. Samples are not produced under full production conditions or using full production processes (e.g. prototype production/sample production). Spare parts, components have been manufactured using auxiliary/prototype tools and predominantly produced using final materials. Discrete circuits instead of hybrid circuits and customer ICs are permissible. Demonstration of the test results in the verification phase, showing the change in performance over the course of the test phase (e.g. by means of graphic representation, performance characteristics). Results regarding software requirements (functions can be experienced 100%) take all relevant test cases into account in accordance with the implementation plan. If test cases have not been verified, relevance regarding the assessment of testability has been checked. Change management is applied. (Reference: VDA Volume 6.3). Automotive cybersecurity:

Supplier Customer

0

80


assessment

A penetration test has been carried out for the product by the contractor, the results have been documented and communicated.

3.3.3

The functionality of the product (including innovations) has been verified by the customer in the overall vehicle/overall system.

The functionality of the product has been verified for example based on - testing vehicles/testing aggregates - testing mules, which are based on the predecessor and have been modified for the testing - test benches - digital prototypes. As contractually agreed, the supplier has access to a sufficient amount of test vehicles/testing mules that have the required maturity level for in-vehicle-testing. E/E and software: Software integration levels have been implemented in accordance with the implementation plan. It was possible to test the software on the system level (e.g. HIL), and the results are available. The supplier has access to a sufficient amount of customer cars for in-vehicle-testing. EMC is ensured. Results regarding software requirements (functions can be experienced 100%) take all relevant test cases into account in accordance with the implementation plan. If test cases have not been verified, relevance regarding the assessment of testability has been checked. Change management is applied.

Customer Supplier

0

3.3.4 (W5.3)

The DFME was applied to provide support for product design. The status of the DFMEA reflects the development progress.

Implementation in accordance with development/product responsibility. Measures have been defined and implemented. (Reference: VDA Volume 6.1, IATF16949, AIAG & VDA FMEA handbook, VDA Volume 6.3). E/E and software: A risk analysis for software (SW-FMEA) was started (e.g. hacking, bus overload, automatic test simulation, timing, non-plausible CAN-messages, border testing). A systematic approach for deriving security requirements on the vehicle/system level was followed by the OEM/system supplier, and the relevant results were passed on to the supplier/sub-supplier (TARA in conjunction with e.g. OCTAVE, STRIDE, etc.).

Supplier Customer

0

81


assessment

Automotive cybersecurity: A full risk analysis for the product (including consideration of interfaces parts provided by the customer and platforms) has been carried out, documented and communicated.

3.4.1 Full production verification

The requalification concept (frequency, location, scope) regarding the requirement specification stipulations has been agreed and laid down.

Including production monitoring (Conformity of Production (COP) testing), environmental conditions, etc.) and the associated documentation. (Reference: VDA Volume 6.3, VDA Volume 2).

Supplier Customer

0

3.5.1 (W6.1)

Process validation

The PDFME was applied to provide support for product design. The status of the PFMEA reflects the development progress.

The process of implementing measures from the process FMEA in the product design has been started for the specific component. Initial manufacturing process validation measures have been identified. The findings from the process FMEA have been taken into consideration in the planning of the manufacturing and testing process (e.g. for the selection of suitable facilities and equipment). (Reference: AIAG & VDA FMEA handbook, VDA Volume 6.1, VDA Volume 6.3, IATF 16949).

Supplier Customer

0

3.5.2

A positive forecast of robust manufacturing feasibility in full production across the entire supply chain is available (for example process FMEA, process flow chart, shop floor layout, statistical tolerance studies).

The focus is on the critical path in the supply chain (key technologies etc.); planning of the entire manufacturing process is available, including measurement variables and control loops. Ease of assembly is assured Manufacturing feasibility in the full production process has been assessed on the basis of simulations and prototypes. Critical characteristics have been assessed, in particular with regard to the required quality, and measures for safeguarding the launch have been taken into consideration in the project plan. (Reference: VDA publication “Robust Production Process”, AIAG & VDA FMEA handbook, VDA 6.1, VDA Volume 6.3, IATF 16949).

Supplier Customer

0


The supplier provides evidence of a systematic approach to dynamic capacity planning.

Indicate the course of action for capacity planning (including frequency of replanning/review), including change management, indicate the critical elements of the process (e.g. taking lead times into consideration).

Supplier Customer

0

3.7.1 (W7.1)

Risk management

Product-specific traceability is defined and agreed.

Integral element of the technical specification(technical requirements specification) release process. Identification markings for parts and traceability must be assured for identification during both the pre-production and full production stages.

Customer Supplier 0

82


assessment

See customer-specific stipulations. (Reference: VDA Volume 6.1, IATF 16949, VDA Volume 6.3).

3.7.2 (W7.2)

The scope of functions for the agreed products to be supplied (software, hardware, mechanics) is available in accordance with the agreed plans.

Potential functional limitations of the products to be supplied (hardware, software, mechanics) in comparison to the respective target (e.g. feature rollout plan, validation and certification plan) have been described. Analyses of the causes and a risk assessment have been conducted. An agreed and released action plan is available.

Supplier Customer

W1.1 (0.1.2)

Project management



Customer Supplier

0

W1.2 (1.7.3)


Customer Supplier

0

W1.3 (2.4.2)

The project organization (resources/capacities, contact persons, overall schedule, crucial project data) has been updated.


Supplier Customer

0

W1.4 (2.4.6)


→ Dates and deadlines (component, tools, facilities, other project deadlines) → Costs → Weight → Functionality (Reference: VDA Volume 6.1, IATF 16949, VDA publication “Robust Production Process”).

Supplier Customer

0

83


assessment

E/E and software: Deviations from the release plan/FROP (Feature Rollout Plan). - Status metrics (comparison TARGET/ACTUAL) - 100% of the features are tested for each release. - Execution of tests for each release has been included as an integral part of the project plan. - A process for the internal release of release stages has been implemented and takes the customer’s requirements into account. - Aspects which have not been implemented in accordance with the agreed release plan or by the deadline have been named, and actions, target deadlines, as well as persons responsible for the actions have been determined. The impact on the further implementation planning has been taken into consideration. Deviations from the specifications in terms of the consumption of resources (e.g. storage capacity/usage, processing power used) have been documented, and actions have been defined accordingly. Deviations from the specifications with regard to software creation have been documented, and actions have been defined.

W1.5 (2.4.7)



Customer Supplier

0

W2.1 (1.3.3)




Customer Supplier

0

Supplier Customer 0

84


assessment

W2.2 (2.3.1)

The supply chain has been updated. The sub-components equally fulfill the requirements of the current maturity level.

In the event of any deviations within the defined supply chain, measures have been drawn up, including an assessment of the effects on the products to be supplied (e.g. locations, suppliers, relocations, logistics concepts). The sustainability of the supply chain is ensured. The sub-supplier is aware of the customer’s requirements and has accepted them. A transfer of special features from subcomponents contained or from higher-level systems was checked. Identified characteristics are assigned to a type of characteristics. - Activities by sub-suppliers are monitored during the development phase. - Regular communication takes place regarding project progress, deadlines and risks. - Requirements and technical feasibility are regularly discussed. - Audits and joint reviews at the sub-suppliers’ premises are carried out. - The relevant requirements of the customer have been transmitted to the sub-suppliers. The sub-suppliers are aware of them and implement them. (Reference: VDA publication “Robust Production Process”, VDA 6.1, VDA Volume 6.3, IATF 16949). Automotive cybersecurity: The relevant systems and applications for the processing and storage of cryptographic material have been specified and checked for critical paths (in relation to IT security) in accordance with end-to-end protection. The classification of the information is specified.

W3.1 (1.2.1)




Supplier Customer

0

85


assessment

W4.1 (2.10.1)

Change management

Product and process changes have been communicated and approved within the supply chain.

The effects of changes on the measured variables of previous maturity levels have been checked and included in the maturity level assessment. Changes may be initiated by either the customer or the supplier; also includes pending changes (including electronic systems). Changes to processes include, for example, changes of location, changes to manufacturing processes, service providers, IT-related changes, construction work (internal changes to the supply process) - Changes are assessed with regard to their feasibility - A risk and impact analysis is conducted for the changes that have been carried out in order to adjust the testing. (Reference: VDA publication “Robust Production Process”, VDA publication 6.3). E/E and software: - Costs, timeline & responsibilities for security updates have been clarified

Supplier Customer

R5.1 (2.7.4)

Product validation

The results from the software maturity level meetings are available.

Milestones and synchronization points have been coordinated with the system and overall project planning (deliveries of functions and software releases). Use of agile methods, agile project management (e.g. sprint planning) - invitation of all software suppliers (internal end external, taking into account the competitive situation as well as competition law/compliance) for overall coordination of software contents and interfaces by the customer. (Product: e.g. the stipulated reviews regarding the software development documents were carried out by independent persons (checks against architecture, standards and guidelines), the correct configuration and use of standard software modules has been proven, model tests were conducted in accordance with the requirements. Software development process: e.g. static code analyses were conducted for each software delivery and assessed based on the respective stage of development). The software maturity level meeting has been documented accordingly, and the documentation is available to the participants (actions, next dates and deadlines, other agreements). (Reference: VDA publication "Agile Collaboration").

Supplier Customer

0

86


assessment

W5.2 (2.7.6)

Bugs (software) are tracked effectively until they have been fixed.


Customer Supplier

0

87



Completion of production planning


assessment


The production process planning has been released and is available. Manufacturing facilities have been authorized.

Manufacturing feasibility has been verified by means of prototype components (also for innovations)/comparable components. Material flow and process layout have been confirmed. Handling error safety planning (e.g. “poke yoke”) taken into consideration. All official regulations (according to requirements specification and other requirements, where applicable) and approval prerequisites, e.g. electro-plating, coating system (including e.g. fire protection systems) have been taken into consideration. The customer’s requirements regarding manufacturing and testing technologies/methods have been taken into consideration in the production planning (e.g. taking ESD requirements into account in line planning). The requirements regarding security and protection must be taken into consideration and met in accordance with the specifications. Completion of the PFMEA prior to final process decisions. Indicating the biggest risks and the means to avoid or detect them in the manufacturing process. Demonstration that all special characteristics have been included in product development and incorporated into quality monitoring throughout the process. (Reference: AIAG& VDA FMEA handbook , VDA Volume 6.1, VDA Volume 6.3, VDA Volume 6.7, IATF 16949, VDA publication “Robust Production Process”).

Supplier Customer

0

4.1.2

The production control plan is available. All special characteristics are included in the planning.

Confirmation of characteristics (products and process) is available. → Refers also to component requirements specification, drawings and quality agreements/specifications. Frequency, scope, random samples, methods have been planned and specified. ESSENTIAL CONTENTS: - Inspection, measuring and test planning - Are all special characteristics requiring process-accompanying quality monitoring available from product development? - Critical characteristics from FMEA - Product and process audits - Maintenance (e.g. monitoring tool wear)

Supplier Customer

0

88


assessment

- Implementation of flash concept - Requalification (e. g. periodical weathering tests). - etc. In addition to this, - Reliability tests - Reworking concepts - Acceptance criteria may be agreed and therefore have to be considered in planning. The type of documentation and the archiving period of test results regarding the monitored characteristics have been agreed upon. (Reference: VDA Volume 6.1, VDA Volume 6.3, IATF 16949, VDA publication “Robust Production Process”, VDA Volume 16 “Decorative Surfaces”).

4.1.3

The necessary resources, including qualification needs, have been specified and verified.

Resources and qualification needs (may concern production and development) are released by the management of the supplier’s organization. E.g. qualification covering the handling of the customer’s measuring and analysis instruments (e.g. delivery quality, punctuality), including the problem solving process (8D), qualification for the analysis of returns. (Reference: VDA Volume 6.1, VDA Volume 6.3, VDA publication “Robust Production Process”). E/E and software: The resource planning takes into account all necessary qualifications and capacities for bug fixing/rectification of errors and security updates during full production. Automotive cybersecurity: Resources and security qualification requirements have been released by the management of the supplier’s organization.

Supplier Customer

0

4.1.4

The tool concept, production concept and testing concept for the production of spare parts (parts produced after EOP (End of Production)) has been agreed within the supply chain.

Perhaps small batches produced at different production locations with separate tools/tool concepts, where applicable. Non-production spare parts: Components which, in their form, are not used in the full production process, e.g. exhaust systems (individual components). Requirements regarding the qualification and testing of non-production spare parts are part of the concept (e.g. always keeping in stock, preservation, storage, etc. are taken into account).

Supplier Customer

0

89


assessment


Gauges / testing equipment belonging to the customer and made available to the supplier for full production have been requested and ordered.

In certain cases, gauges/inspection and measuring equipment (belonging to the customer) are made available to the supplier for assuring the delivery quality (e.g. checking fixtures for bumpers, roof rim panels, light units, ...). Measurement system capabilities were demonstrated in advance (test runs, simulations, etc.). The customer and the supplier have agreed on the technical design of the testing equipment (e.g. special characteristics have been taken into consideration). Alternative methods or replacement gauges have been defined, agreed upon with the customer and are available (fall-back solution in case of test equipment failure in full production, in accordance with IATF 16949). (Reference: VDA Volume 5, AIAG MSA handbook, VDA Volume 6.1, VDA Volume 6.3, IATF 16949).

Customer Supplier

0

4.2.2

The supplier’s gauges / test equipment for full production have been requested and ordered.

Part of the production control plan. The supplier and the customer have agreed on the technical design of the test equipment (e.g. special characteristics have been taken into consideration). Alternative methods or replacement gauges have been defined, agreed upon with the customer and are available (fall-back solution in case of test equipment failure in full production, in accordance with IATF 16949). (Reference: VDA Volume 5, AIAG MSA handbook, VDA Volume 6.1, VDA Volume 6.3, IATF 16949).

Supplier Customer

0

4.2.3 Production tools have been ordered and started in accordance with the schedule.

Customer’s approval for procurement is available, tool schedule has been updated. The customer’s specifications regarding the production of tools have been taken into consideration in the supplier’s plans. The commissioned and approved toolmakers are known, including location. The specification of the tool and the schedule for construction, production and optimization are available. They include contingencies for tool transfers to the production location. A comparison between the planned tool use at the production location and the relevant customer milestones (production of production parts using production facilities in full production processes) has been made. (Reference: VDA 6.3).

Supplier Customer

0

4.2.4

Actions from the process FMEA have been incorporated in the production planning.

Actions from the PFMEA have been taken into consideration for the realization of the manufacturing and testing processes. Requirements have been included e.g. in the equipment requirement specification. Within the framework of industrialization, a new assessment of risks takes place, with

Supplier Customer

0

90


assessment

final completion of measures at the time the PPA process is carried out. (Reference: AIAG & VDA FMEA handbook, VDA Volume 6.1, VDA Volume 6.3, IATF 16949).

4.2.5

A concept for analyzing and processing internal failures (on the line) and failures at the customer’s premises (0 km and field), as well as parts of the product and market observation, if agreed, is available.

The failure elimination process including failure analysis has been agreed. Requirements relating to the analysis location have been agreed and implemented in full. Training courses are planned for the analysis personnel. Communication channels and information exchange concepts have been defined. Parts from service organization It is to be guaranteed by the supplier that the diagnostic concept for field failures has been defined according to VDA publication Field Failure Analysis and agreed by the customer Logistics requirements regarding the transport and the storage of defective parts have been determined. Customer requirements with regard to the test concept and aspects pertaining to testing (e.g. standard and load tests) must be taken into consideration in the supplier’s planning. Requirements regarding the exchange of data between the customer and the supplier have been specified (e.g. use of customer portals, specific IT solutions). (Reference: VDA publication “Field Failure Analysis”, VDA publication 6.3).

Supplier Customer

0

4.3.1


The timing and the extent of the process acceptance procedure have been specified.

The internal process acceptance procedure has been planned by the supplier. The contents of the joint process acceptance procedure have been agreed and dates have been set. Performance test in accordance with VDA Volume 2 e.g. customer-specific designations: - Pre-check - 2 day’s production - Run@rate - Full production process etc.. Customer requirements for process approval (e.g. regarding the method, quantity, or deadline) have been taken into account in the supplier’s internal planning. (Reference: VDA Volume 6.3, VDA Volume 2).

Supplier Customer

0

91


assessment

E/E and software: The supplier demonstrates by the agreed date that the agreed ASPICE level has been reached.


On-time availability of diagnostic and testing software is assured for the products to be supplied, in accordance with the component requirements specification.

Software for service and workshop purposes.

Supplier Customer

0

4.4.2 (W5.4)

The start-up of vehicle/powertrain production is secured by a relevant reflash concept.

- On-site support at the customer’s premises is ensured by the supplier’s residence engineers. - A reflash concept and the necessary resources (reflash equipment) for possible software updates are available at the supplier’s location.

Supplier Customer

4.4.3 (W5.5)

Results from vehicle and/or component tests have been exchanged and released.

Exchange between the customer and the supplier with documentation of results (e.g. test reports). Including software and hardware tests. Corrective actions have been agreed and scheduled. The availability of testing mules/test vehicles is planned and confirmed by the customer. E/E and software: Bugs found during the trials are documented in a system and forwarded to the supplier. The reduction of bugs is planned in a sensible way, considering that further bugs might possibly occur. The results of the software tests carried out in accordance with the test plan are available. For implemented software requirements, all associated test cases were taken into consideration.

Customer Supplier


The logistics concept from goods arriving at the supplier’s premises to finished products being loaded for dispatch has been defined and is being implemented on time.

- Take account of the principles of lean production (e.g ensure that the FIFO principle is applied, traceability, ...). - Sequence diagrams and flow charts - Logistics layout: Storage/buffer zones meet the component-specific requirements as agreed in the logistics concept (e.g. humidity-controlled/temperature-controlled storage of electronic components, requirements regarding cleanliness, ...) - System-based control (including interface to sub-suppliers) - Exclusion of mix-up/ confusion. Requirements specific to the products to be supplied and pertaining to the load carriers for in-house transport (e.g. ESD,

Supplier Customer

0

92


assessment

surface protection, cleanliness) and parts handling have been taken into consideration (also for sub-components).

4.5.2

The delivery concept from the goods leaving the supplier’s premises to their arrival at the fitting location at the customer’s premises has been specified and is being implemented on time.

- Take account of the principles of lean production. - Packaging, shipping containers and space requirements have been agreed and specified (including special shipping. containers). Packaging concept/delivery concept takes climatic conditions into account (e.g. corrosion protection requirements, cleanliness requirements) - Re-order time/need for a safety stock (e.g. keeping semiconductors in stock). - Taking into account the return concept regarding load carriers - Return concept for products complained about - Logistics simulation, test phases, etc. - Schedule for implementation.

Customer Supplier

0

4.5.3 Systematic processing of customer call-offs has been verified.

Requirements: Consistency throughout, from receipt of the order, right through to dispatch of finished products and to the sub-supplier (type of call-off, receipt and processing of delivery call-off, synchronizing the cumulative delivery quantity, MRP system (Material Requirements Planning System), communicating demand to sub-suppliers). Statement covering the frequency of demand planning (including changes to call-offs) and forwarding these to sub-suppliers, including demand horizon, emergency strategy in the event of a system failure. The IT systems (EDI) must not be changed without the customer’s consent. The EDI interfaces, as well as the times of the system call-ups have been defined.

Supplier Customer

0

4.5.4

Emergency analyses have been carried out for the supply chain and contingency plans have been drawn up.

What measures can be taken to safeguard against unexpected interruptions (e.g. strike, customs, force majeure, tools, production facilities, transport, etc.)? A list of possible disruptions and an assessment of them (appropriate risk assessment including response plan), including emergency contacts, is available. (Reference: VDA Volume 6.1, VDA Volume 6.3, IATF 16949, VDA publication “Robust Production Process”).

Supplier Customer

0


Orders have been placed throughout the entire supply chain.

The placement of orders in the supply chain by the supplier occurs at the latest once the series version has been approved by the customer’s development department. Orders to Tier n suppliers: “order” refers to delivery of parts/services (e.g. software development)/contracts for work

Supplier Customer

0

93


assessment

and services/ areas of sub-procurement. It also relates to parts supplied by the customer, which come within the procurement responsibility of the customer’s organization. (Reference: VDA Volume 6.3, VDA publication “Robust Production Process”, VDA publication “Product Integrity”). E/E and software: Orders have been placed with sub-suppliers with regard to software development and software tests. The sub-supplier structure has been communicated to the customer.

W1.1 (0.1.2)

Project management



Customer Supplier

0

W1.2 (1.7.3)


Customer Supplier

0

W1.3 (2.4.2)



Supplier Customer

0

W1.4 (2.4.6)

Deviations from the project targets at the level of the products to be supplied have been checked and highlighted,

→ Dates and deadlines (component, tools, facilities, other project deadlines) → Costs → Weight

Supplier Customer

0

94


assessment

and measures have been defined.

→ Functionality (Reference: VDA Volume 6.1, IATF 16949, VDA publication “Robust Production Process”). E/E and software: Deviations from the release plan/FROP (Feature Rollout Plan). - Status metrics (comparison TARGET/ACTUAL) - 100% of the features are tested for each release. - Execution of tests for each release has been included as an integral part of the project plan. - A process for the internal release of release stages has been implemented and takes the customer’s requirements into account. - Aspects which have not been implemented in accordance with the agreed release plan or by the deadline have been named, and actions, target deadlines, as well as persons responsible for the actions have been determined. The impact on the further implementation planning has been taken into consideration. Deviations from the specifications in terms of the consumption of resources (e.g. storage capacity/usage, processing power used) have been documented, and actions have been defined accordingly. Deviations from the specifications with regard to software creation have been documented, and actions have been defined.

W1.5 (2.4.7)



Customer Supplier

0

W2.1 (1.3.3)



● Launch curves, production peak, maximum daily output ● Model mix, optional equipment rates ● Spare part demand/ CKD demand (CKD – Completely Knocked Down) ● Shift models, agreed flexibility ● Critical process elements in terms of increasing capacity The quantities (capacities) have been communicated to the sub-supplier.

Customer Supplier

0

95


assessment

(Reference: VDA publication “Robust Production Process”, VDA publication ”Product Integrity”).

W2.2 (2.3.1)


In the event of any deviations within the defined supply chain, measures have been drawn up, including an assessment of the effects on the products to be supplied (e.g. locations, suppliers, relocations, logistics concepts). The sustainability of the supply chain is ensured. The sub-supplier is aware of the customer’s requirements and has accepted them. A transfer of special features from subcomponents contained or from higher-level systems was checked. Identified characteristics are assigned to a type of characteristics. - Activities by sub-suppliers are monitored during the development phase. - Regular communication takes place regarding project progress, deadlines and risks. - Requirements and technical feasibility are regularly discussed. - Audits and joint reviews at the sub-suppliers’ premises are carried out. - The relevant requirements of the customer have been transmitted to the sub-suppliers. The sub-suppliers are aware of them and implement them. (Reference: VDA publication “Robust Production Process”, VDA 6.1, VDA Volume 6.3, IATF 16949). Automotive cybersecurity: The relevant systems and applications for the processing and storage of cryptographic material have been specified and checked for critical paths (in relation to IT security) in accordance with end-to-end protection. The classification of the information is specified.

Supplier Customer

0

W3.1 (1.2.1)



Experience gathered from current of predecessor car series (8D reports, lessons learned, benchmarks, OEM studies, independent market surveys, field monitoring) is available. Going through the 8D reports with the highest error severity (e.g. biggest cost drivers - view step D7 “Prevent Recurrence”, and check in how far these measures are applicable to the new project). Warranty periods have been specified. Test requirements for lifespan tests have been defined. Component-specific targets have been defined. E/E and software:

Supplier Customer

0

96


assessment

Has there been any experience from previous projects regarding errors (lessons learned) or cyber risks in the field?

W4.1 (2.10.1)

Change management



Supplier Customer

0

W5.1 (2.7.4)

Product validation


Milestones and synchronization points have been coordinated with the system and overall project planning (deliveries of functions and software releases). Use of agile methods, agile project management (e.g. sprint planning) - invitation of all software suppliers (internal end external, taking into account the competitive situation as well as competition law/compliance) for overall coordination of software contents and interfaces by the customer. (Product: e.g. the stipulated reviews regarding the software development documents were carried out by independent persons (checks against architecture, standards and guidelines), the correct configuration and use of standard software modules has been proven, model tests were conducted in accordance with the requirements. Software development process: e.g. static code analyses were conducted for each software delivery and assessed based on the respective stage of development). The software maturity level meeting has been documented accordingly, and the documentation is available to the participants (actions, next dates and deadlines, other

Supplier Customer

97


assessment

agreements). (Reference: VDA publication "Agile Collaboration").

W5.2 (2.7.6)



Customer Supplier

0

W5.3 (3.3.4)

Technical product changes are incorporated into the FMEA (Product). Results from vehicle and/or component tests have been taken into account.

Implementation in accordance with development/product responsibility. Measures have been defined and implemented. (Reference: VDA Volume 6.1, IATF16949, AIAG & VDA FMEA handbook, VDA Volume 6.3). E/E and software: A risk analysis for software (SW-FMEA) was started (e.g. hacking, bus overload, automatic test simulation, timing, non-plausible CAN-messages, border testing). A systematic approach for deriving security requirements on the vehicle/system level was followed by the OEM/system supplier, and the relevant results were passed on to the supplier/sub-supplier (TARA in conjunction with e.g. OCTAVE, STRIDE, etc.). Automotive cybersecurity: A full risk analysis for the product (including consideration of interfaces parts provided by the customer and platforms) has been carried out, documented and communicated.

Supplier Customer

0

W6.1 (3.5.1)

Process validation

Technical changes to the process are incorporated into the FMEA (Process). Results from vehicle and/or component tests have been taken into account.

Actions are being implemented in accordance with the schedule. The findings from the process FMEA have been taken into consideration in the planning of the manufacturing and testing process (e.g. for the selection of suitable facilities and equipment). (Reference: AIAG & VDA FMEA handbook, VDA Volume 6.1, VDA Volume 6.3, IATF 16949).

Supplier Customer

0

Supplier Customer 0

98


assessment

W7.1 (3.7.1)

Risk management

Product-specific traceability is implemented in the supply chain.

Component identification and traceability must be ensured for pre-production and also full production identification. The supplier confirms the implementation of the plans regarding the traceability of subcomponents and shows that the customer’s requirements have been met. See customer-specific stipulations. (Reference: VDA Volume 6.1, IATF 16949, VDA Volume 6.3).

W7.2 (3.7.2)



Supplier Customer

99



Parts from production tools and production facilities are available


assessment

5.1.1


All of the tests and testing dates for production process and product approval (PPA) have been confirmed by the supplier.

The content, number, scope and type of tests, including a schedule, for a comprehensive PPA process required for the customer’s decision to grant delivery approval (as agreed in the coordination meeting regarding the PPA process) are available. If required, the production and the measurement methodology of reference /boundary samples is agreed upon with the customer. Dates for the release of surfaces (e.g. color, grain finish) must be planned and take place in due time, prior to the PPA date. The requalification concept (frequency, location, scope) regarding the requirement specification stipulations has been agreed and laid down. (Reference: VDA Volume 2).

Supplier Customer

0


Standard shipping containers, special shipping containers and any alternative packaging have been approved, and the planned quantities are available for pre-production.

Standard shipping containers (not product-specific, e.g. EU mesh box pallets, EUR-pallets, small load carriers). Special shipping containers (product-specific, e.g. special packaging, thermoformed trays). Alternative packaging agreed as temporary alternative for the two types of containers; e.g. corrosion protection, residual dirt and ESD requirements are taken into account to the extent agreed. Transport containers for transporting defective parts from the customer to the supplier have been approved. (Reference: VDA publication “Robust Production Process”, VDA Volume 19.1, VDA Volume 19.2).

Customer Supplier

0

5.2.2 Delivery call-offs for pre-production, including the launch program, are available.

Delivery call-offs have been specified on the basis of the launch curve with defined model and equipment spectra. Dates and deadlines for provision of the components have been agreed. Call-off orders/individual orders are also available to the sub-suppliers, dates for the provision of sub-components have been coordinated and confirmed. Software: The software statuses to be used for pre-production have been

Customer Supplier

0

100


assessment

agreed upon between the customer and the supplier. (Reference: VDA publication “Robust Production Process”).

5.2.3

The full production capacities at the supplier’s premises have been confirmed.

The full production capacities defined at the supplier’s premises (customer-specific plant capacity updated and confirmed, personnel availability and qualifications) have been confirmed to plan. Capacities have been confirmed by the sub-suppliers.

Supplier Customer

0


Development release by customer at component level. Confirmation of tests is available.

The development level of the higher-level system (e.g. vehicle) is released by the customer’s development department. All tests (for example based on testing vehicles/testing aggregates, testing mules which are based on the predecessor and have been modified for the testing, test benches, digital prototypes) have been completed successfully. Design release is issued on the basis of parts from full production, ie. the component is OK in terms of function and materials. Materials, corrosion protection concept have been documented in the drawing and in the relevant systems. (Reference: IATF 16949, VDA Volume 6.1). E/E and software: The supplier’s release process for software has been performed and confirmed as specified (e.g release for test drivers). Results regarding software requirements take all relevant test cases into account in accordance with the implementation plan. If test cases have not been verified, relevance regarding development release has been assessed. Automotive cybersecurity: The contractor has checked the product for security vulnerabilities (CVE). The identified vulnerabilities are communicated to the customer, and necessary avoidance measures have been discussed. Vulnerabilities that require monitoring by the contractor throughout the life cycle have been defined.

Customer Supplier

0

5.3.2 Technical cleanliness has been demonstrated.

All required measures/tools (methods) for achieving technical cleanliness are available (assembly and logistics concepts, buildings, rooms, etc.). Initial tests have been carried out, their status has been demonstrated. (Reference: VDA Volume 19.1, VDA Volume 19.2)

Supplier Customer

5.3.3

Material data has been confirmed. The legal and customer requirements are met and the necessary

Material data is available (e.g. material data sheet, IMDS (International Material Data System). Materials and requirements for verifying material characteristics have been specified and have been checked with regard to

Supplier Customer

0

101


assessment

material data is recorded in the material data sheet.

fulfillment of statutory/market-specific and customer-specific requirements. Material data is gathered along the supply chain and transmitted. (Reference: VDA Volume 2).


Handling instructions in the customer’s organization have been implemented.

Avoid damage to the product by improper handling during removal and fitting of the component , after sales & service (e.g. handling of electric fuel pumps, electronic components, etc.).

Customer Supplier 0

5.4.2

Gauges / testing equipment belonging to the customer and made available to the supplier for full production have been requested and ordered.

Evidence of capability is available, the gauge’s full production capability has been verified. Specifications regarding the monitoring and maintenance of test equipment have been defined. Alternative methods or replacement gauges have been defined, agreed upon with the customer and are available (fall-back solution in case of test equipment failure in full production, in accordance with IATF 16949). (Reference: VDA Volume 5, AIAG MSA handbook, VDA Volume 6.1, VDA Volume 6.3, IATF 16949).

Customer Supplier

0

5.4.3

The supplier's gauges / testing equipment for full production have been requested and ordered.

Evidence of capability is available, the gauge’s full production capability has been verified. Specifications regarding the monitoring and maintenance of test equipment have been defined. Alternative methods or replacement gauges have been defined, agreed upon with the customer and are available (fall-back solution in case of test equipment failure in full production, in accordance with IATF 16949). (Reference: VDA Volume 5, AIAG MSA handbook, VDA Volume 6.1, VDA Volume 6.3, IATF 16949).

Supplier Customer

0

5.4.4 Process parameters and their tolerances are defined.

Verification takes place within the framework of the process acceptance procedure, i.e. checks are made regarding the way in which tolerance limits affect compliance with the specification for the products to be supplied. (Reference: VDA Volume 6.1, VDA Volume 6.3, IATF 16949).

Supplier Customer 0

5.4.5

The first parts made with production tools are available, The revision status is documented. (C-sample).

The first parts made with production tools are manufactured with the tools to be used in the subsequent full production process. The production tools must be capable of manufacturing the components in such a way that they meet the requirements for the component (tolerance, function, quality, fit in the assembly, etc.) in accordance with the agreed component requirements specification/performance specification. Manufacturing takes place with production tools under conditions that are similar to full production conditions (manufacturing can still take place at the toolmaker’s or the plant

Supplier Customer

0

102


assessment

manufacturer’s premises). Revision status is documented (e.g based on parts and tool history documentation) Start of coordination of tools. (Reference: VDA publication “Robust Production Process”, VDA publication 6.3).

5.4.6

Parts made with production tools are available, The revision status is documented. (D-sample).

Parts made with production tools conform to the final full production standard. Manufacturing takes place under full production conditions and with production tools/production facilities at the production location. The revision status has been documented (e.g. based on parts and tools history documentation) (Reference: VDA publication “Robust Production Process”, VDA publication 6.3).

Supplier Customer

5.4.7

The production facility/production facilities is (are) available. Machine capability has been established.

Proof of machine capability can also be provided by the manufacturer of the production facilities. (Reference: VDA publication “Robust Production Process”, VDA 6.1, VDA 6.3, VDA Volume 6.7, IATF 16949).

Supplier Customer

0

5.4.8

Buildings and infrastructure are complete and have been approved by the relevant public authorities.

Approved by the authorities (site-specific/country-specific), e.g. paint shop, galvanizing plant, occupational health and safety equipment, fire protection, etc. (Reference: VDA publication “Robust Production Process”, VDA 6.1, VDA Volume 6.3, IATF 16949).

Supplier Customer

0

W1.1 (0.1.2)

Project management



Customer Supplier

0

W1.2 (1.7.3)


Customer Supplier

0

W1.3 (2.4.2)


Resources/capacities, roles and tasks (project management, development, production planning, process development and planning, logistics, quality, procurement, ...). An agile project organization/agile project management with the respective roles (e.g. product owner, SCRUM master) has been established, if possible.

Supplier Customer

0

103


assessment

The AKV (German abbreviation for: tasks, authority, responsibility) within the project have been clarified, and representatives have been named. Required persons responsible for security and product safety have been confirmed. (Reference: VDA Volume 6.3). Automotive cybersecurity: Roles and responsibilities within the scope of information security have been defined an are known. An information security system has been implemented and is operating effectively.

W1.4 (2.4.6)


→ Dates and deadlines (component, tools, facilities, other project deadlines) → Costs → Weight → Functionality (Reference: VDA Volume 6.1, IATF 16949, VDA publication “Robust Production Process”). E/E and software: Deviations from the release plan/FROP (Feature Rollout Plan). - Status metrics (comparison TARGET/ACTUAL) - 100% of the features are tested for each release. - Execution of tests for each release has been included as an integral part of the project plan. - A process for the internal release of release stages has been implemented and takes the customer’s requirements into account. - Aspects which have not been implemented in accordance with the agreed release plan or by the deadline have been named, and actions, target deadlines, as well as persons responsible for the actions have been determined. The impact on the further implementation planning has been taken into consideration. Deviations from the specifications in terms of the consumption of resources (e.g. storage capacity/usage, processing power used) have been documented, and actions have been defined accordingly. Deviations from the specifications with regard to software creation have been documented, and actions have been defined.

Supplier Customer

0

W1.5 (2.4.7)

Interfaces to other projects and component applications

The influence and interactions (e.g. tolerances, EMC compatibility, etc. ) arising from other projects /deliveries have

Customer Supplier 0

104


assessment

by the supplier and customer have been clarified.

been analyzed, communicated and evaluated (e.g. Identical or carry-over parts). Multiple use e.g. in different series/products must be defined. A project management communication matrix is known and accepted by all parties. Interfaces to other modules within the same component or to other components are known.

W2.1 (1.3.3)




Customer Supplier

0

W2.2 (2.3.1)

The supply chain has been updated. The sub-components equally fulfill the requirements of the current maturity lvel.

In the event of any deviations within the defined supply chain, measures have been drawn up, including an assessment of the effects on the products to be supplied (e.g. locations, suppliers, relocations, logistics concepts). The sustainability of the supply chain is ensured. The sub-supplier is aware of the customer’s requirements and has accepted them. A transfer of special features from subcomponents contained or from higher-level systems was checked. Identified characteristics are assigned to a type of characteristics. - Activities by sub-suppliers are monitored during the development phase. - Regular communication takes place regarding project progress, deadlines and risks. - Requirements and technical feasibility are regularly discussed. - Audits and joint reviews at the sub-suppliers’ premises are carried out. - The relevant requirements of the customer have been transmitted to the sub-suppliers. The sub-suppliers are aware of them and implement them. (Reference: VDA publication “Robust Production Process”, VDA 6.1, VDA Volume 6.3, IATF 16949). Automotive cybersecurity:

Supplier Customer

0

105


assessment

The relevant systems and applications for the processing and storage of cryptographic material have been specified and checked for critical paths (in relation to IT security) in accordance with end-to-end protection. The classification of the information is specified.

W3.1 (1.2.1)




Supplier Customer

0

W4.1 (2.10.1)

Change management



Supplier Customer

0

W5.1 (2.7.4)

Product validation


Milestones and synchronization points have been coordinated with the system and overall project planning (deliveries of functions and software releases). Use of agile methods, agile project management (e.g. sprint planning) - invitation of all software suppliers (internal end external, taking into account the

Supplier Customer

106


assessment

competitive situation as well as competition law/compliance) for overall coordination of software contents and interfaces by the customer. (Product: e.g. the stipulated reviews regarding the software development documents were carried out by independent persons (checks against architecture, standards and guidelines), the correct configuration and use of standard software modules has been proven, model tests were conducted in accordance with the requirements. Software development process: e.g. static code analyses were conducted for each software delivery and assessed based on the respective stage of development). The software maturity level meeting has been documented accordingly, and the documentation is available to the participants (actions, next dates and deadlines, other agreements). (Reference: VDA publication "Agile Collaboration").

W5.2 (2.7.6)



Customer Supplier

0

W5.3 (3.3.4)


Implementation in accordance with development/product responsibility. Measures have been defined and implemented. (Reference: VDA Volume 6.1, IATF16949, AIAG & VDA FMEA handbook, VDA Volume 6.3). E/E and software: A risk analysis for software (SW-FMEA) was started (e.g. hacking, bus overload, automatic test simulation, timing, non-plausible CAN-messages, border testing). A systematic approach for deriving security requirements on the vehicle/system level was followed by the OEM/system supplier, and the relevant results were passed on to the supplier/sub-

Supplier Customer

0

107


assessment

supplier (TARA in conjunction with e.g. OCTAVE, STRIDE, etc.). Automotive cybersecurity: A full risk analysis for the product (including consideration of interfaces parts provided by the customer and platforms) has been carried out, documented and communicated.

W5.4 (4.4.2)

The start of production of the vehicle / powertrain is secured by a relevant reflash concept.


Supplier Customer

W5.5 (4.4.3)



Customer Supplier

0

W6.1 (3.5.1)

Process validation



Supplier Customer

0

W7.1 (3.7.1)

Risk management



Supplier Customer

0

Supplier Customer

108


assessment

W7.2 (3.7.2)



109



Production process and product approval


assessment

6.1.1


The components of the supply chain (sub-suppliers) have been released.

The production process and product approval comprises the assessment of processes and products. Supplied software is also part of the approval in accordance with the approval processes agreed with the customer. Assessment results product and process approval in accordance with PPA, PPAP. (Reference: VDA Volume 2, VDA Volume 6.1, VDA Volume 6.3, IATF 16949, VDA publication “Robust Production Process”).

Supplier Customer

0

6.1.2

All of the tests for the production process and product approval (PPA) have been carried out by the supplier in accordance with the agreed specification. The results are available.

The tests were carried out as agreed in the coordination meeting for the PPA process. The required evidence is available. (Reference: VDA Volume 2, VDA Volume 6.1, IATF 16949, VDA publication “Robust Production Process”).

Supplier Customer

0

6.1.3 Reference samples/boundary samples are available as agreed with the customer.

Reference/boundary samples have been agreed upon with the customer (e.g. surface, gloss level, etc.). (Reference: VDA Volume 2, VDA Volume 16 ”Decorative Surfaces").

Customer Supplier

6.1.4

The release of colors and the grain finish has taken place between the customer and the supplier.

The customer’s color charts and charts showing grain finishes are available as a requirement: Parts relevant for the color and the grain finish were presented and approved as OK. (Reference: VDA Volume 16 ”Decorative Surfaces").

Customer Supplier

6.1.5 Technical cleanliness has been demonstrated.

The achievement of the targets with regard to technical cleanliness has been demonstrated, coordinated and ensured within the scope of the production process and product approval. (Reference: VDA Volume 19.1, VDA Volume 19.2)

Supplier Customer

6.1.6 The supplier’s failure analysis process has been approved by the customer.

Agreement regarding the diagnostic and analysis process has been reached. (Reference: VDA publication “Field Failure Analysis”, VDA Volume 2, VDA 6.3).

Customer Supplier

6.1.7

All tests for product release in the PPA process have been carried out by the customer, results as a prerequisite for

Assembly trials, crash tests and test-rig tests, material checks, laboratory checks, dimensional cross-checks, weathering tests, integration tests and software tests (e.g. penetration tests), etc.. (Reference: VDA Volume 2).

Customer Supplier

0

110


assessment

the customer’s decision on the PPA process are available.

6.1.8

Production process approval at the supplier’s premises and under full production conditions (quality and quantity) has occurred.

For approval of the production process, evidence regarding process quality and process performance has been provided by the supplier (based on VDA Volume 2). (Reference: VDA Volume 2, VDA publication “Robust Production Process” or customer-specific checklists, VDA Volume 6.1, VDA 6.1, VDA Volume 6.3, IATF 16949).

Customer Supplier

0

6.1.9 Production process and product approval (PPA) is available.

Production process and product approval has been granted in the scope agreed upon. (Reference: VDA Volume 2, VDA Volume 6.3, VDA publication “Robust Production Process”).

Customer Supplier

0


The required amount of approved standard and special shipping containers is available.

Depending on the contractual agreement (planned amount of shipping containers). Requirements such as corrosion protection, residual dirt and ESD protection have been fulfilled to the extent agreed. (Reference: VDA Volume 2, VDA Volume 6.1, IATF 16949, VDA publication “Robust Production Process”, VDA Volume 19.1, VDA Volume 19.2).

Customer Supplier

0

6.2.2 Logistics process has been approved.

Matters to be examined within the framework of the acceptance procedure for logistics processes: - Logistics process from the supplier’s incoming goods department to the supplier’s outgoing goods department - Delivery process from supplier’s outgoing goods department to the customer - Packing concept. (Reference: VDA publication “Robust Production Process”).

Customer Supplier

0

W1.1 (0.1.2)

Project management



Customer Supplier

0

W1.2 (1.7.3)


Customer Supplier

0

W1.3 (2.4.2)


Resourcesc/capacities, roles and tasks (project management, development, production planning, process development and planning, logistics, quality, procurement, ...). An agile project organization/agile project management with the respective roles (e.g. product owner, SCRUM master) has been

Supplier Customer

0

111


assessment

established, if possible. The AKV (German abbreviation for: tasks, authority, responsibility) within the project have been clarified, and representatives have been named. Required persons responsible for security and product safety have been confirmed. (Reference: VDA Volume 6.3). Automotive cybersecurity: Roles and responsibilities within the scope of information security have been defined an are known. An information security system has been implemented and is operating effectively.

W1.4 (2.4.6)


→ Dates and deadlines (component, tools, facilities, other project deadlines) → Costs → Weight → Functionality (Reference: VDA Volume 6.1, IATF 16949, VDA publication “Robust Production Process”). E/E and software: Deviations from the release plan/FROP (Feature Rollout Plan). - Status metrics (comparison TARGET/ACTUAL) - 100% of the features are tested for each release. - Execution of tests for each release has been included as an integral part of the project plan. - A process for the internal release of release stages has been implemented and takes the customer’s requirements into account. - Aspects which have not been implemented in accordance with the agreed release plan or by the deadline have been named, and actions, target deadlines, as well as persons responsible for the actions have been determined. The impact on the further implementation planning has been taken into consideration. Deviations from the specifications in terms of the consumption of resources (e.g. storage capacity/usage, processing power used) have been documented, and actions have been defined accordingly. Deviations from the specifications with regard to software creation have been documented, and actions have been defined.

Supplier Customer

0

112


assessment

W1.5 (2.4.7)



Customer Supplier

0

W2.1 (1.3.3)




Customer Supplier

0

W2.2 (2.3.1)


In the event of any deviations within the defined supply chain, measures have been drawn up, including an assessment of the effects on the products to be supplied (e.g. locations, suppliers, relocations, logistics concepts). The sustainability of the supply chain is ensured. The sub-supplier is aware of the customer’s requirements and has accepted them. A transfer of special features from subcomponents contained or from higher-level systems was checked. Identified characteristics are assigned to a type of characteristics. - Activities by sub-suppliers are monitored during the development phase. - Regular communication takes place regarding project progress, deadlines and risks. - Requirements and technical feasibility are regularly discussed. - Audits and joint reviews at the sub-suppliers’ premises are carried out. - The relevant requirements of the customer have been transmitted to the sub-suppliers. The sub-suppliers are aware of them and implement them. (Reference: VDA publication “Robust Production Process”, VDA 6.1, VDA Volume 6.3, IATF 16949).

Supplier Customer

0

113


assessment

Automotive cybersecurity: The relevant systems and applications for the processing and storage of cryptographic material have been specified and checked for critical paths (in relation to IT security) in accordance with end-to-end protection. The classification of the information is specified.

W3.1 (1.2.1)




Supplier Customer

0

W4.1 (2.10.1)

Change management



Supplier Customer

0

W5.1 (2.7.4)

Product validation


Milestones and synchronization points have been coordinated with the system and overall project planning (deliveries of functions and software releases). Use of agile methods, agile

Supplier Customer

114


assessment

project management (e.g. sprint planning) - invitation of all software suppliers (internal end external, taking into account the competitive situation as well as competition law/compliance) for overall coordination of software contents and interfaces by the customer. (Product: e.g. the stipulated reviews regarding the software development documents were carried out by independent persons (checks against architecture, standards and guidelines), the correct configuration and use of standard software modules has been proven, model tests were conducted in accordance with the requirements. Software development process: e.g. static code analyses were conducted for each software delivery and assessed based on the respective stage of development). The software maturity level meeting has been documented accordingly, and the documentation is available to the participants (actions, next dates and deadlines, other agreements). (Reference: VDA publication "Agile Collaboration").

W5.2 (2.7.6)



Customer Supplier

W5.3 (3.3.4)


Implementation in accordance with development/product responsibility. Measures have been defined and implemented. (Reference: VDA Volume 6.1, IATF16949, AIAG & VDA FMEA handbook, VDA Volume 6.3). E/E and software: A risk analysis for software (SW-FMEA) was started (e.g. hacking, bus overload, automatic test simulation, timing, non-plausible CAN-messages, border testing). A systematic approach for deriving security requirements on the

Supplier Customer

0

115


assessment

vehicle/system level was followed by the OEM/system supplier, and the relevant results were passed on to the supplier/sub-supplier (TARA in conjunction with e.g. OCTAVE, STRIDE, etc.). Automotive cybersecurity: A full risk analysis for the product (including consideration of interfaces parts provided by the customer and platforms) has been carried out, documented and communicated.

W5.4 (4.4.2)

The start of production of the vehicle / powertrain is secured by a relevant reflash concept.


Supplier Customer

W5.5 (4.4.3)



Customer Supplier

0

W6.1 (3.5.1)

Process validation



Supplier Customer

0

W7.1 (3.7.1)

Risk management



Supplier Customer

0

Supplier Customer

116


assessment

W7.2 (3.7.2)



117



Project completion, transfer of responsibilities to production, start of requalification


assessment

7.1.1 Change management

All product and process changes have been implemented according to schedule. Handover of the project to full production organization has taken place.

Points outstanding from the handover of the project to full production organization are followed up on, and deadlines and responsible persons have been specified. Before the initial full production delivery, production process and product approval has been granted. The information has been transferred to the production change management process (e.g. a concept is agreed upon for eliminating remaining software errors). (Reference: VDA publication “Robust Production Process”, VDA 6.1, VDA Volume 6.3, IATF 16949).

Customer Supplier

0


All relevant documents (specification and verification documents) are available.

Requirements regarding archiving, labeling of documents and regarding traceability are met. ESSENTIAL CONTENTS: - Documents such as requirements specifications/product specifications, drawings and quality agreements/requirements, PPA. - The special characteristics (product and process) are available via the production control plan. - Work instructions (standardized work) - Preventive maintenance/servicing/cleaning (e.g. including critical spare parts, monitoring tool wear, etc.) - Implementing the flash concept - Requalification (e. g. periodical weathering tests) - Failure analysis process. (Reference: VDA Volume 2, VDA publication “Field Failure Analysis”, VDA Volume 6.1, VDA Volume 6.3, IATF 16949).

Supplier Customer

0

7.2.2

The “lessons learned” documentation has been drawn up and communicated. The results are incorporated into the relevant products and processes.

Feedback of experience from the project completed with ML7, with the integration of existing data (e.g. field failures, feedback from after-sales service, project database, know-how carrier file), must be assured as the input for new projects or developments. Ensured within the framework of workshops with all of the parties and relevant departments involved in the “round table” within the supply chain. (Reference: VDA Volume 6.1, IATF 16949, VDA publication “Lessons Learned”).

Customer Supplier

0

118


assessment


A robust process (reproducibility, 0-km quality, etc.) under full production conditions to a mature status has been verified on the basis of the specified characteristics.

Verification of the process performance agreed upon with the customer (e.g. OEE, rejects, 0 km failures) and process capability. (Reference: VDA publication “Robust Production Process”, VDA 6.1, VDA Volume 6.3, IATF 16949). Automotive cybersecurity: Verification that the process for the exchange of cryptographic material is ensured in accordance with end-to-end protection.

Supplier Customer

0

7.4.1 Full production verification

Specifications regarding requalification have been taken into account in the supplier’s plans, production monitoring has been started.

Requalification and further measures for monitoring full production, such as e.g. CoP (Conformity of Production) tests have been taken into account in the supplier’s planning for the products to be ordered in accordance with the customer’s specifications regarding the scope of testing and the test intervals. (Reference: VDA publication “Robust Production Process”, VDA 2, VDA 6.1, VDA Volume 6.3, IATF 16949). Automotive cybersecurity: Security-relevant events are defined, a logging and monitoring process is installed in accordance with the customer’s requirements (e.g. procedure in case of incidents has been defined).

Supplier Customer

0

7.4.2 The agreed capacities have been verified.

It has been demonstrated that with the resources used, the agreed quantity of products can be produced for the customer in the specified period of time and in accordance with the specifications. (Reference: VDA Volume 2).

Supplier Customer

0

W1.2 (1.7.3)


Handover certificate (handover of project to full production). (Reference: VDA Volume”Robust Production Process”, VDA Volume 6.1, VDA Volume 6.3, IATF 16949, VDA publication “Minimizing Risks in the Supply Chain”).

Customer Supplier

0

Maturity level assurance for new parts

Documents

Transcript of Maturity level assurance for new parts