Process Assessment Model SPICE for Mechanical … · SPICE for Mechanical Engineering 1 Process Assessment Model ... made possible by the kind contribution of the following companies

Process Assessment Model

SPICE for Mechanical Engineering

1

Process Assessment Model SPICE

for Mechanical Engineering - Proposal-

Version: 1.4 Release date: 06.07.2017 Distribution: Public.

For the worldwide SPICE community and any other interested parties. Status: Released.



2

Copyright notice Copyright 2015-2017 International Assessor Certification Scheme e.V. (hereafter referred to as intacs). All rights reserved.

Redistribution and use with or without modification are permitted provided that redistribution repro-duces the above copyright notice, this list of conditions and the following disclaimer in the documenta-tion and/or other materials provided with the distribution.

THIS DOCUMENTATION IS PROVIDED BY INTACS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL INTACS BE LIABLE FOR ANY DIRECT, IN-DIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIM-ITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CON-TRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.1

Acknowledgement This process model was created by the intacs working group Mechanic SPICE whose work was only made possible by the kind contribution of the following companies and particularly their employees involved.

Brose Fahrzeugteile GmbH & Co. KG

Conti Temic microelectronic GmbH

F+S Fleckner und Simon Informationstechnik GmbH

Hilti AG

KUGLER MAAG CIE GmbH

Mando Corporation Europe GmbH

Robert Bosch GmbH

ZF Friedrichshafen AG

The members of the working group would especially thank all the reviewers of the standard whose val-uable input helped to increase the quality of the model for its initial release.

1 License inspired by https://www.freebsd.org/copyright/freebsd-license.html

https://www.freebsd.org/copyright/freebsd-license.html



3

Content

Copyright notice ............................................................................................................................................2

Acknowledgement.........................................................................................................................................2

1 Introduction ...........................................................................................................................................5

1.1 Scope .............................................................................................................................................5

2 Statement of compliance .......................................................................................................................6

3 Mechanical System Engineering ............................................................................................................7

3.1 Mechanical System Requirements Analysis ..................................................................................7

3.2 Mechanical System Architectural Design ................................................................................... 10

3.3 Mechanical System Integration and Integration Test ................................................................ 13

3.4 Mechanical System Qualification Test ....................................................................................... 16

4 Mechanical Component Engineering .................................................................................................. 18

4.1 Mechanical Component Requirements Analysis ........................................................................ 18

4.2 Mechanical Component Design ................................................................................................. 21

4.3 Mechanical Component Sample Production .............................................................................. 23

4.4 Test against Mechanical Component Design ............................................................................. 25

4.5 Test against Mechanical Component Requirements ................................................................. 27

Annex A – Conformity of the process assessment and reference model .................................................. 29

Annex B – Work Product Characteristics .................................................................................................... 30

Annex C – Terminology............................................................................................................................... 34

Annex D – Key Concepts ............................................................................................................................. 42

D.1 The "Plug-in" Concept ...................................................................................................................... 42

D.2 The Tip of the "V" ............................................................................................................................. 42

D.3 Terms “Element”, “Component", “Unit” and “Item” ....................................................................... 43

D.4 Traceability and Consistency ............................................................................................................ 44

D.5 “Agree” and “Summarize and Communicate” ................................................................................. 44

D.6 “Evaluate”, “Verification Criteria” and “Ensuring compliance” ....................................................... 44

D.7 The Relation between “Strategy” and “Plan” .................................................................................. 44

Annex E – Mapping to ISO/TS 16949:2009 ................................................................................................ 45



4

List of Figures

Figure D.1 – The “Plug-in” concept ............................................................................................................ 42

Figure D.2 – The tip of the “V” ................................................................................................................... 43

Figure D.3 – The terms “element”, “component” and “item” ................................................................... 43

Figure D.4 – Traceability and consistency .................................................................................................. 44

List of Tables

Table B.1 – Structure of WPC tables .......................................................................................................... 30

Table B.2 – Work product characteristics .................................................................................................. 30

Table C.3 – Terminology ............................................................................................................................. 34

Table E.4 – Mapping to ISO/TS 16949:2009 ............................................................................................... 45



5

1 Introduction

1.1 Scope

The mechanical engineering processes define a process set for the development of pure mechanical systems (e.g. steering columns) and mechanical components (e.g. screws). These are linked to Automo-tive SPICE according to the Plug-In Concept defined in Automotive SPICE v3.0.

Interfaces to the following processes are covered:

Mechatronic processes (SYS.X)

Production

Test environment development

The entire development of production processes is not covered.

Management and supporting processes as well as generic practices of Automotive SPICE shall be used as defined in the Automotive SPICE PAM v3.0 but have to be adapted to a mechanical context.



6

2 Statement of compliance The Mechanical SPICE process assessment model and process reference model is intended to be compli-ant with the ISO/IEC 33004, and thus usable as the basis for conducting an assessment of process capa-bility. ISO/IEC 33020 is used as an ISO/IEC 33003 compliant measurement framework. A statement of compliance of the process assessment model and process reference model with the re-quirements of ISO/IEC 33004 is under development by intacs.



7

3 Mechanical System Engineering

3.1 Mechanical System Requirements Analysis

ID

MSE.1

Process Name

Mechanical System Requirements Analysis

Process Purpose

The purpose of the Mechanical System Requirements Analysis process is to derive the mechanical sys-tem requirements from the upper system requirements together with all affected stakeholders.

Process Outcomes

As a result of successful implementation of this process:

1) the mechanical system requirements are derived from the upper system requirements and the upper system architecture;

Note: If the mechanical system is the highest system the source of these requirements are the only the stakeholders, in other cases the requirements’ source is the upper system requirements and the upper system architecture.

2) the mechanical system requirements are categorized and analyzed for correctness and verifiability;

3) the impact of mechanical system requirements on the operating environment is analyzed and com-municated;

4) prioritization for implementing the mechanical system requirements is defined;

5) the mechanical system requirements are updated as needed;

6) consistency and bidirectional traceability are established between upper system requirements and mechanical system requirements; and consistency and bidirectional traceability are established between upper system architecture and mechanical system requirements;

7) the mechanical system requirements are evaluated for cost, schedule and technical impact; and

8) the mechanical system requirements are agreed and communicated to all affected stakeholders.

Base Practices

BP1: Specify mechanical system requirements.

Use the upper system requirements and the upper system architecture as well as changes to the upper system requirements and architecture to identify the required functions and capabilities of the mechan-ical system. Specify functional and non-functional mechanical system requirements in a mechanical sys-tem requirements specification. [OUTCOME 1, 5, 7]

NOTE 1: Non-functional requirements may include e.g. production, maintenance, exchangeability of systems and components in the field, logistic, packaging, sizing, weight, price per unit, producibility, environmental, design guidelines, modelling guidelines and patents.

NOTE 2: Mechanical system requirements should include tolerances as necessary.

BP2: Structure mechanical system requirements.

Structure the mechanical system requirements in the mechanical system requirements specification by e.g.

grouping to project relevant clusters like architecture elements,

sorting in a logical order for the project,

categorizing based on relevant criteria for the project,

Element#_D.3_Terms_



8

prioritizing according to stakeholder needs.

[OUTCOME 2, 4]

NOTE 3: Prioritizing typically includes the assignment of mechanical content to planned releases. Refer to SPL.2 BP1.

BP3: Analyze mechanical system requirements.

Analyze the specified mechanical system requirements including their interdependencies to ensure cor-rectness, technical feasibility and verifiability, and to support risk identification. Analyze the impact on cost, schedule and the technical impact. [OUTCOME 2, 7]

NOTE 4: The analysis of impact on cost, schedule and quality supports the adjustment of project esti-mates. Refer to MAN.3 BP5.

BP4: Analyze the impact on the operating environment.

Analyze the impact that the mechanical system requirements will have on upper system elements and the operating environment. [OUTCOME 3, 7]

BP5: Develop verification criteria.

Develop the verification criteria for each mechanical system requirement that define the qualitative and quantitative measures for the verification of a requirement. [OUTCOME 2, 7]

NOTE 5: Verification criteria demonstrate that a requirement can be verified within agreed constraints and is typically used as the input for the development of the test cases or other verification measures that should demonstrate compliance with the mechanical system requirements.

NOTE 6: Verification which cannot be covered by testing is covered by SUP.2.

BP6: Establish bidirectional traceability.

1. Establish bidirectional traceability between upper system requirements and mechanical system requirements.

2. Establish bidirectional traceability between the upper system architecture and mechanical sys-tem requirements.

[OUTCOME 6]

NOTE 7: Bidirectional traceability supports coverage, consistency and impact analysis.

BP7: Ensure consistency.

1. Ensure consistency between upper system requirements and mechanical system requirements.

2. Ensure consistency between the upper system architecture and mechanical system require-ments.

[OUTCOME 6]

NOTE 8: Consistency is supported by bidirectional traceability and can be demonstrated by review rec-ords.

NOTE 9: In case of mechanical development only, the upper system requirements and upper system architecture refer to a given operating environment. In that case, consistency and bidirectional tracea-bility has to be ensured between stakeholder requirements and mechanical system requirements.

BP8: Communicate agreed mechanical requirements.

Communicate the agreed mechanical system requirements and updates to mechanical system require-ments to all relevant stakeholders. [OUTCOME 8]

Output Work Products

01-51 Application parameter [OUTCOME 1]

13-04 Communication record [OUTCOME 8]

13-19 Review record [OUTCOME 6]

Element#_D.3_Terms_



9

13-21 Change control record [OUTCOME 5, 7]

13-22 Traceability record [OUTCOME 1, 6]

15-01 Analysis report [OUTCOME 2, 3, 4, 7]

17-08 Interface requirements specification [OUTCOME 1]

17-ME01 Mechanical system requirements specification [OUTCOME 1]

17-50 Verification criteria [OUTCOME 2]



10

3.2 Mechanical System Architectural Design

ID

MSE.2

Process Name

Mechanical System Architectural Design

Process Purpose

The purpose of the Mechanical System Architectural Design Process is to establish an architectural de-sign and to identify which mechanical system requirements are to be allocated to which elements of the mechanic, and to evaluate the mechanical system architectural design against defined criteria.

Process Outcomes


1) a mechanical system architectural design is defined that identifies the elements of the mechanical system;

2) the mechanical system requirements are allocated to the elements of the mechanical system;

3) the interfaces of each mechanical system elements are defined;

4) the static and dynamic behaviour and design constraints of the mechanical system elements are de-fined;

5) consistency and bidirectional traceability are established between mechanical system requirements and mechanical system architectural design; and

6) the mechanical system architectural design is agreed and communicated to all affected stakeholders.

Base Practices

BP.1: Develop mechanical system architectural design.

Develop and document the mechanical system architectural design that specifies the elements of the mechanical system with respect to functional and non-functional mechanical system requirements. [OUTCOME 1]

NOTE 1: The mechanical system is decomposed into elements across appropriate hierarchical levels down to the mechanical components (the elements on the lowest level of the mechanical system archi-tectural design) that are described in the mechanical component design.

NOTE 2: Consider make, buy and reuse options.

NOTE 3: Model-based development (e.g. FEM, SysML) may facilitate the collaboration of the different engineering domains.

BP.2: Allocate mechanical system requirements.

Allocate all mechanical system requirements to the elements of the mechanical system architectural design. [OUTCOME 2]

BP.3: Define interfaces of mechanical elements.

Identify, develop and document the interfaces of each mechanical system element. [OUTCOME 3]

BP.4: Identify special characteristics.

Identify and document special characteristics of the mechanical system elements. [OUTCOME 1]

NOTE 4: The identification of special characteristics is supported by e.g. simulation, risk analyses, sizing calculations.

BP.5: Describe dynamic and static behaviour.

Evaluate and document the dynamic and static behaviour of and the interaction between mechanical

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_



11

system elements. [OUTCOME 4]

NOTE 5: Static and dynamic behaviour is determined by e.g. stress, force, pressure, strain, temperature, operating modes (open, closed, in motion, misuse, emergency, etc.)

BP.6: Consider, determine, and document design constraints.

Determine and document design constraints for all mechanical system elements and take them into account for creating the mechanical system architecture. [OUTCOME 4]

BP7: Evaluate alternative mechanical system architectures.

Define evaluation criteria for architectural design. Evaluate alternative mechanical system architectures according to the defined criteria. Record the rationale for the chosen mechanical system architecture. [OUTCOME 1, 2, 3, 4, 5]

NOTE 6: Evaluation criteria may include quality characteristics (cost, weight, packaging, modularity, maintainability, expandability, scalability, reliability, safety and usability) and results of make-buy-reuse analysis.

BP8: Verify mechanical system architectural design.

Ensure that the mechanical system architectural design meets all mechanical system requirements. [Outcomes 4, 5]

NOTE 7: Verification of mechanic system architectural design may include FEA, simulation, or Product FMEA.


1. Establish bidirectional traceability between mechanical system requirements and elements of the mechanical system architectural design.

2. Establish bidirectional traceability between elements of the mechanical system architectural de-sign and elements of the system architectural design.

[OUTCOME 5]

NOTE 8: Bidirectional traceability covers allocation of mechanical system requirements to the elements of the mechanical system architectural design.



1. Ensure consistency between mechanical system requirements and the mechanical system archi-tectural design.

2. Ensure consistency between elements of the mechanical system architectural design and ele-ments of the system architectural design.

[OUTCOME 1, 2, 5, 6]


NOTE 11: Mechanical system requirements include mechanical system architectural requirements, refer to BP7.

BP11: Communicate agreed mechanical system architectural design.

Communicate the agreed mechanical system architectural design and updates to mechanical system architectural design to all relevant stakeholders. [OUTCOME 6]


04-ME01 Mechanical system architectural design [OUTCOME 1, 2, 3, 4, 5]



13-22 Traceability record [OUTCOME 5]

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_



12

17-08 Interface requirement specification [OUTCOME 3]

13-ME01 Characteristics classification record [OUTCOME 1]



13

3.3 Mechanical System Integration and Integration Test

ID

MSE.3

Process Name

Mechanical System Integration and Integration Test

Process Purpose

The purpose of the Mechanical System Integration and Integration Test Process is to integrate the me-chanical items (mechanical component items and/or mechanical system items) into larger mechanical items up to a complete integrated mechanical system item consistent with the mechanical system archi-tectural design and to ensure that the mechanical items are tested to provide evidence for compliance of the integrated mechanical items with the mechanical system architectural design, including the inter-faces between the mechanical items.

Process Outcomes


1) a mechanical system integration strategy consistent with the project plan, release plan and the me-chanical system architectural design is developed to integrate the mechanical items;

2) a mechanical system integration test strategy including the regression test strategy is developed to test the mechanical items interactions;

3) a specification for mechanical system integration test according to the mechanical system integration test strategy is developed that is suitable to provide evidence for compliance of the integrated mechani-cal items with the mechanical system architectural design, including the interfaces between the me-chanical items;

4) mechanical items are integrated up to a complete integrated mechanical system according to the integration strategy;

5) test cases included in the mechanical system integration test specification are selected according to the mechanical system integration test strategy, and the release plan;

6) integrated mechanical items are tested using the selected test cases and the results of mechanical system integration testing are recorded;

7) consistency and bidirectional traceability are established between the elements of the mechanical system architectural design and the test cases included in the mechanical system integration test speci-fication, between test cases and test results and between integrated mechanic items and recorded pro-cess data; and

8) the results of the mechanical system integration test are summarized and communicated to all af-fected stakeholders.

Base Practices

BP1: Develop mechanical system integration strategy.

Develop a strategy for integrating mechanical sub-systems consistent with the project plan and the re-lease plan. Identify mechanical sub-systems based on the mechanical system architectural design and define a sequence for integrating them. [OUTCOME 1]

BP2: Develop mechanical system integration test strategy including regression test strategy.

Develop a strategy for testing the integrated mechanical item following the mechanical system integra-tion strategy. This includes a regression test strategy for re-testing integrated mechanical item if a me-chanical item is changed. [OUTCOME 2]

BP3: Develop specification for mechanical system integration test.

Element#_D.3_Terms_

https://apps.ce.collabserv.com/wikis/home?lang=de-de#%21/wiki/W755daaaff955_44b6_88c7_fd3b45638da6/page/Test%20specification



14

Develop the test specification for mechanical system integration test including the test cases according to the mechanical system integration test strategy for each integrated mechanical item. The test specifi-cation shall be suitable to provide evidence for compliance of the integrated mechanical items with the mechanical system architectural design. [OUTCOME 3]

NOTE 1: Compliance to the architectural design means that the specified integration tests are suitable to prove that the interfaces between the mechanical items fulfill the specification (e.g. special characteris-tics) given by the mechanical system architectural design.

BP4: Integrate mechanical items.

Integrate the mechanical items to integrated mechanical system item according to the mechanical sys-tem integration strategy and record process data according to the integration strategy. [OUTCOME 4]

BP5: Select test cases.

Select test cases from the mechanical system integration test specification. The selection of test cases shall have sufficient coverage according to the mechanical system integration test strategy and the re-lease plan. [OUTCOME 5]

BP6: Perform mechanical system integration test.

Perform the mechanical system integration test using the selected test cases. Record the integration test results and logs. [OUTCOME 6]

NOTE 2: See SUP.9 for handling of non-conformances

NOTE 3: Capable test environment as defined in the test strategy needs to be available for performing mechanical system integration and integration test.


1. Establish bidirectional traceability between elements of the mechanical system architectural de-sign and test cases included in the mechanical system integration test specification.

2. Establish bidirectional traceability between test cases included in the mechanical system inte-gration test specification and mechanical system integration test results.

3. Establish bidirectional traceability between integrated mechanical items and recorded process data according to the mechanical system integration strategy.

4. Establish bidirectional traceability between integrated mechanical items and the considered mechanical system item.

5. Establish bidirectional traceability between the mechanical integration test results and the inte-grated mechanical systems.

[OUTCOME 7]



1. Ensure consistency between elements of the mechanical system architectural design and test cases included in the mechanical system integration test specification.

2. Ensure consistency between test cases included in the mechanical system integration test speci-fication and mechanical system integration test results.

3. Ensure consistency between integrated mechanical items and recorded process data according to the mechanical system integration strategy.

4. Ensure consistency between integrated mechanical items and the considered mechanical sys-tem item.

5. Ensure consistency between the mechanical integration test results and the integrated mechan-ical systems.

[OUTCOME 7]

NOTE 5: Consistency is supported by bidirectional traceability and can be demonstrated by review rec-

Element#_D.3_Terms_

Element#_D.3_Terms_



15

ords.

BP9: Summarize and communicate results.

Summarize the mechanical system integration test results and communicate them to all affected stake-holders. [OUTCOME 8]

NOTE 6: Providing all necessary information (e.g. test results, recorded process data) from the test case execution in a summary enables stakeholders to judge the consequences.


08-ME01 Sample control plan [OUTCOME 1, 2]

17-ME02 Assembly instruction [OUTCOME 1]

13-ME02 Assembly record [OUTCOME 4]

08-50 Test specification [OUTCOME 3,5]

13-50 Test result [OUTCOME 6, 8]


17-ME03 Bill of material (BOM, Build list) [OUTCOME 3, 4, 7]

11-ME01 Mechanical System [OUTCOME 4]





16

3.4 Mechanical System Qualification Test

ID

MSE.4

Process Name

Mechanical System Qualification Test

Process Purpose

The purpose of the Mechanical System Qualification Test Process is to ensure that the integrated me-chanical system is tested to provide evidence for compliance with the mechanical system requirements.

Process Outcomes


1) a mechanical system qualification test strategy including regression test strategy consistent with the project plan and the release plan is developed to test the integrated mechanical system;

2) a specification for mechanical system qualification test of the integrated mechanical system according to the mechanical system qualification test strategy is developed that is suitable to provide evidence for compliance with the mechanical system requirements;

3) test cases included in the mechanical system qualification test specification are selected according to the mechanical system qualification test strategy and the release plan;

4) the integrated mechanical system is tested using the selected test cases and the results of mechanical system qualification test are recorded;

5) consistency and bidirectional traceability are established between mechanical system requirements and mechanical system qualification test specification including test cases and between test cases and test results; and

6) results of the mechanical system qualification test are summarized and communicated to all affected stakeholders.

Base Practices

BP1: Develop mechanical system qualification test strategy including a regression test strategy.

Develop a strategy for mechanical system qualification testing consistent with the project plan and the release plan. This includes a regression test strategy for re-testing the integrated mechanical system if a mechanical sub-system is changed. [OUTCOME 1]

BP2: Develop specification for mechanical system qualification test.

Develop the specification for mechanical system qualification testing including test cases based on the verification criteria according to the mechanical system test strategy. The test specification shall be suit-able to provide evidence for compliance of the integrated mechanical system with the mechanical sys-tem requirements. [OUTCOME 2]

BP3: Select test cases.

Select test cases from the mechanical system qualification test specification. The selection of test cases shall have sufficient coverage according to the mechanical system qualification test strategy and the release plan. [OUTCOME 3]

BP4: Test the integrated mechanical system.

Test the mechanical system using the selected test cases. Record the mechanic system qualification test results and logs. [OUTCOME 4]


NOTE 2: Capable test environment as defined in the test strategy needs to be available for performing





17

mechanical system qualification testing.


1. Establish bidirectional traceability between mechanical system requirements and test cases in-cluded in the mechanical system qualification test specification.

2. Establish bidirectional traceability between test cases included in the mechanical system qualifi-cation test specification and mechanical system qualification test results.

3. Establish bidirectional traceability between the mechanical system qualification test results and the integrated mechanical systems.

[OUTCOME 5]



1. Ensure consistency between mechanical system requirements and test cases included in the mechanical system qualification test specification.

2. Ensure consistency between test cases included in the mechanical system qualification test specification and mechanical system qualification test results.

3. Ensure consistency between the mechanical system qualification test results and the integrated mechanical systems.

[OUTCOME 5]



Summarize the mechanical system qualification test results and communicate them to all affected stakeholders. [OUTCOME 6]

NOTE 5: Providing all necessary information from the test case execution in a summary enables stake-holders to judge the consequences.


08-52 Test plan (DVP) [OUTCOME 1, 2, 6]

08-50 Test specification [OUTCOME 2, 3]







18

4 Mechanical Component Engineering

4.1 Mechanical Component Requirements Analysis

ID

MCE.1

Process Name

Mechanical Component Requirements Analysis

Process Purpose

The purpose of the Mechanical Component Requirements Analysis process is to establish the require-ments for the mechanical component.

Process Outcomes


1) the mechanical component requirements are derived from the upper system requirements and upper system architecture;

2) mechanical component requirements are categorized and analyzed for completeness, correctness, and verifiability;

3) the impact of mechanical component requirements on the operating environment is analyzed;

4) prioritization for implementing the mechanical component requirements is defined;

5) the mechanical component requirements are updated as needed;

6) consistency and bidirectional traceability are established between upper system requirements and mechanical component requirements; and consistency and bidirectional traceability are established between upper system architectural design and mechanical component requirements;

7) the mechanical component requirements are evaluated for cost, schedule and technical impact; and

8) the mechanical component requirements are agreed and communicated to all affected stakeholders.

Base Practices

BP.1: Specify mechanical component requirements.

Use the upper system requirements and the upper system architecture and changes to the upper sys-tem requirements and the upper system architecture to identify the required functions and capabilities of the mechanical component. Specify functional and non-functional mechanical component require-ments in a mechanical component requirements specification. [OUTCOME 1, 5, 7]

NOTE 1: If the system requirements and the system architectural design refer to a given operating envi-ronment, then the stakeholder requirements should be used as the basis for identifying the required functions and capabilities of the mechanic component.

NOTE 2: Non-functional requirements may include e.g. production, maintenance, logistic, environmen-tal.

BP2: Structure mechanical component requirements.

Structure the mechanical component requirements in the mechanical component requirements specifi-cation by e.g.

grouping to project relevant clusters,

sorting in a logical order for the project,

categorizing based on relevant criteria for the project,

prioritizing according to stakeholder needs.



19

[OUTCOME 2, 4]

NOTE 3: Prioritizing typically includes the assignment of mechanical content to planned releases. Refer to SPL.2 BP1.

BP.3: Analyze mechanical component requirements.

Analyze the specified mechanical component requirements including their interdependencies to ensure correctness, technical feasibility, producibility and verifiability, and to support risk identification. Analyze the impact on cost, schedule and the technical impact. [OUTCOME 2, 7]

NOTE 4: The analysis of impact on cost, schedule and quality supports the adjustment of project esti-mates. Refer to MAN.3 BP5.

BP4: Analyze the impact on the operating environment.

Analyze the impact that the mechanical component requirements will have on interfaces of system ele-ments and the operating environment. [OUTCOME 3, 7]

BP5: Develop verification criteria.

Develop the verification criteria for each mechanical component requirement that define the qualitative and quantitative measures for the verification of a requirement. [OUTCOME 2, 7]

NOTE 5: Verification criteria demonstrate that a requirement can be verified within agreed constraints and are typically used as the input for the development of the test cases or other verification measures that should demonstrate compliance with the mechanic component requirements.

NOTE 6: Verification which cannot be covered by testing is covered by SUP.2.


1. Establish bidirectional traceability between upper system requirements and mechanical compo-nent requirements.

2. Establish bidirectional traceability between the upper system architecture and mechanical com-ponent requirements.

[OUTCOME 6]

NOTE 7: Redundancy should be avoided by establishing a combination of the approaches BP6.1 and BP6.2 that covers the project and the organizational needs.



1. Ensure consistency between upper system requirements and mechanical component require-ments.

2. Ensure consistency between the upper system architecture and mechanical component re-quirements.

[OUTCOME 6]


NOTE 10: If the system requirements and the system architectural design refer to a given operating en-vironment, then the stakeholder requirements should be used as the basis for identifying the required functions and capabilities of the mechanic component.

BP8: Communicate agreed mechanical component requirements.

Communicate the agreed mechanical component requirements and updates to mechanical component requirements to all relevant stakeholders. [OUTCOME 8]




Element#_D.3_Terms_

Element#_D.3_Terms_



20

13-21 Change control record [OUTCOME 5, 7]

13-22 Traceability record [OUTCOME 1, 6]

15-01 Analysis report [OUTCOME 2, 3, 4, 7]

17-08 Interface requirements specification [OUTCOME 1]

17-ME04 Mechanical component requirements specification [OUTCOME 1]

17-50 Verification criteria [OUTCOME 2]



21

4.2 Mechanical Component Design

ID

MCE.2

Process Name

Mechanical Component Design

Process Purpose

The purpose of the Mechanical Component Design process is to provide an evaluated design for the mechanical component.

Process Outcomes


1) a design is developed that describes the mechanical component;

2) interfaces of the mechanical component are defined;

3) consistency and bidirectional traceability are established between mechanical component require-ments and mechanical component design; and consistency and bidirectional traceability are established between upper system architecture and mechanical component design; and

4) the mechanical component design is agreed and communicated to all affected stakeholders.

Base Practices

BP.1: Develop mechanical component design.

Develop a design for the mechanical component using the functional and non-functional mechanical component requirements including interfaces. [OUTCOME 1]

While developing the mechanical component design the requirements and data relevant for production are identified and documented.

NOTE 1: Non-functional requirements may include e.g. price per unit, maintenance, logistic, packaging, size, weight, manufacturability, environmental constraints, design guidelines, modelling guidelines, fail-ure times.

NOTE 2: Design for Manufacturing and Design for Assembly may be used to ensure manufacturability.

BP2: Evaluate mechanical component design.

Evaluate the mechanical component design in terms of interaction, criticality, technical complexity, risks, measurability and verifiability. [OUTCOME 1,2]

NOTE 3: The results of the evaluation can be used as input for test against mechanical component de-sign.

BP3: Verify mechanical component design.

Ensure that the mechanical component design meets all mechanical component requirements. [Out-comes 4, 5]

NOTE 4: Verification of mechanic component design may include FEA, simulation, or Product FMEA.


1. Establish bidirectional traceability between mechanical component requirements and mechani-cal component design.

2. Establish bidirectional traceability between the mechanical system architectural design and me-chanical component design.

[OUTCOME 3]

NOTE 5: Redundancy should be avoided by establishing a combination of the approaches BP4.1 and



22

BP4.2 that covers the project and the organizational needs.



1. Ensure consistency between mechanical component requirements and mechanical component design.

2. Ensure consistency between the mechanical system architectural design and mechanical com-ponent design.

[OUTCOME 3]


BP6: Communicate agreed mechanical component design.

Communicate the agreed mechanical component design and updates to the mechanical component design to all relevant stakeholders. [OUTCOME 4]


04-ME02 Mechanical component design [OUTCOME 1, 2]



https://apps.ce.collabserv.com/wikis/home?lang=de-de#%21/wiki/W755daaaff955_44b6_88c7_fd3b45638da6/page/Traceability

https://apps.ce.collabserv.com/wikis/home?lang=de-de#%21/wiki/W755daaaff955_44b6_88c7_fd3b45638da6/page/Traceability



23

4.3 Mechanical Component Sample Production

ID

MCE.3

Process Name

Mechanical Component Sample Production

Process Purpose

The purpose of the Mechanical Component Sample Production process is to produce a mechanical com-ponent item that reflects properly the mechanical component design and mechanical component pro-duction strategy.

Process Outcomes


1) a mechanical component production strategy is developed, communicated to, and agreed on with all affected stakeholders,

2) mechanical component items are produced according to the mechanical component design,

3) bidirectional traceability are established between the produced mechanical component and recorded process data according to the mechanical component production strategy; and consistency and bidirec-tional traceability are established between recorded process data and the mechanical component pro-duction strategy (control plan), and

4) information gathered during production is communicated to all affected stakeholders.

Base Practices

BP1: Develop mechanical component production strategy.

Develop a strategy for production of the mechanical component item. The mechanical component pro-duction strategy shall be consistent with the mechanical component design, project plan (e.g. estima-tion of number of built items needed), release plan (e.g. definition of releases and their content), and test strategy (e.g. mapping of test methods to releases). [OUTCOME 1]

The mechanical component production strategy may contain the definition of the production method(s), verification method(s) (control plan).

BP.2: Agree on mechanical component production strategy.

Communicate the agreed mechanical component production strategy between all involved stakeholders (e.g. engineering, sample shop, production). [OUTCOME 1]

NOTE 1: The communication of the mechanical component production strategy to suppliers is handled by ACQ.4 Supplier monitoring.

BP.3: Ensure and support production of mechanical components.

Ensure and support production of mechanical component items according to:

the mechanical component design

mechanical component production strategy

the requirements and data relevant for production.

Record process data according to the mechanical component production strategy. [OUTCOME 2, 4]

NOTE 2: Production here means only sample phases (e.g. prototype building, pre-series production) and does not cover the process of industrialization.

BP.4: Establish bidirectional traceability.

1. Establish bidirectional traceability between mechanical component production strategy and me-



24

chanical component design.

2. Establish bidirectional traceability between the produced mechanical component item and rec-orded process data according to the mechanical component production strategy.

3. Establish bidirectional traceability between recorded process data and mechanical component production strategy (control plan).

[OUTCOME 3]


BP.5: Ensure consistency.

1. Ensure consistency between recorded process data and mechanical component production strategy (control plan).

2. Ensure consistency between produced mechanical component item and recorded process data according to the mechanical component production strategy.

3. Ensure consistency between recorded process data and mechanical component production strategy (control plan).

[OUTCOME 3]


BP.6: Provide feedback to all affected stakeholders

Communicate information gathered during the production of the mechanical component to all affected stakeholders. [OUTCOME 4]

These information may contain:

Capability of chosen production method

Manufacturability of the mechanic component

Improvement potentials for future releases

Process data and information


NOTE 6: The communication of information mentioned above is handled by ACQ.4 Supplier monitoring in case of production at a supplier’s site.

Affected stakeholders may be:

Industrialization

Series production

Mechanical engineering

Project management


11-ME02 Mechanical Component [OUTCOME 2]

19-ME01 Production strategy [OUTCOME 1]

13-ME03 Production record [OUTCOME 2, 4]



15-01 Analysis report (Containing analyses results of e.g. suitability of chosen production method regarding effectiveness, timing, cost) [OUTCOME 4]



25

4.4 Test against Mechanical Component Design

ID

MCE.4

Process Name

Test against Mechanical Component Design

Process Purpose

The purpose of the Test against mechanical component design process is to test the mechanical compo-nent item to provide evidence for compliance of the mechanical component item with the mechanical component design.

Process Outcomes


1) a strategy for test against mechanical component design including regression test strategy is devel-oped;

2) a specification for test against mechanical component design is developed according to the strategy for test against mechanical component design that is suitable to provide evidence for compliance of the mechanical component item with the mechanical component design;

3) test cases included in the test specification for test against mechanical component design are selected according to the test strategy for test against the mechanical component design and the release plan;

4) the mechanical component item is tested according to the strategy for test against mechanical com-ponent design and the test specification for test against mechanical component design and the results are recorded;

5) consistency and bidirectional traceability are established between the mechanical component design and the test specification for test against mechanic component design as well as between the test speci-fication for test against mechanical component design and test results; and

6) results of the test against mechanical component design are summarized and communicated to all affected stakeholders.

Base Practices

BP.1: Develop strategy for test against mechanical component design including regression test strate-gy.

Develop a strategy for test against mechanical component design including regression test strategy for re-test if the mechanical component design is changed. The test strategy shall define how to provide evidence for compliance of the mechanical component item with the mechanical component de-sign. [OUTCOME 1]

NOTE 1: The test strategy shall contain a planning of needed items for testing and the allocation of tests to be performed within different releases. The needed amount of items for dedicated tests shall consid-er that random and systematic faults have to be detected.

BP.2: Develop test specification for test against mechanical component design.

Develop test specification for test against mechanical component design including test cases that are suitable to provide evidence for compliance of the mechanical component item with the mechanical component design according to the test strategy. [OUTCOME 2]

BP.3: Select test cases.

Select test cases from the test specification for test against mechanical component design. The selection of test cases shall have sufficient coverage according to the test strategy for test against mechanical component design and the release plan. [OUTCOME 3]

https://apps.ce.collabserv.com/wikis/home?lang=de-de#%21/wiki/W755daaaff955_44b6_88c7_fd3b45638da6/page/Consistency



https://apps.ce.collabserv.com/wikis/home?lang=de-de#%21/wiki/W755daaaff955_44b6_88c7_fd3b45638da6/page/Coverage

https://apps.ce.collabserv.com/wikis/home?lang=de-de#%21/wiki/W755daaaff955_44b6_88c7_fd3b45638da6/page/Coverage



26

BP.4: Test mechanical component item.

Test the mechanical component item using the test specification for test against mechanical component design according to the strategy for test against mechanical component design. Record the test results and measured values. [OUTCOME 4]

NOTE 2: See SUP.9 for handling of non-conformances.

NOTE 3: Capable test environment as defined in the test strategy needs to be available for performing test against mechanical component design.


1. Establish bidirectional traceability between the mechanical component design and the mechanic component test specification for test against mechanical component design.

2. Establish bidirectional traceability between the test results and tested mechanical component items.

3. Establish bidirectional traceability between test cases included in the mechanic component test specification and mechanic component test results.

[OUTCOME 5]



1. Ensure consistency between the mechanical component design and the test specification for test against mechanical component design.

2. Ensure consistency between the test results and tested mechanical component items.

3. Ensure consistency between test cases included in the mechanic component test specification and mechanic component test results.

[OUTCOME 5]



Summarize the test results and communicate them to all affected stakeholders. [OUTCOME 6]



08-50 Test specification [OUTCOME 2]

08-52 Test plan [OUTCOME 1]


13-19 Review record [OUTCOME 3, 4]


13-50 Test result [OUTCOME 3, 5, 6]



27

4.5 Test against Mechanical Component Requirements

ID

MCE.5

Process Name

Test against Mechanical Component Requirements

Process Purpose

The purpose of the Test against Mechanical Component Requirements process is to test the mechanical component to provide evidence for compliance of the mechanical component with the mechanical component requirements.

Process Outcomes


1) a strategy for the test against mechanical component requirements including regression test strategy consistent with the project plan and the release plan is developed;

2) a specification for the test against mechanical component requirements is developed according to the strategy for the test against mechanical component requirements that is suitable to provide evidence for compliance of the mechanical component with the mechanical component requirements;

3) test cases included in the test specification for the test against mechanical component requirements are selected according to the test strategy for the test against mechanical component requirements and the release plan

4) the mechanical component is tested according to the strategy for the test against mechanical compo-nent requirements and the test specification for the test against mechanical component requirements, and the results are recorded;

5) consistency and bidirectional traceability are established between the mechanical component re-quirements and the test specification for the test against mechanical component requirements as well as between the test specification for the test against mechanical component requirements and test re-sults; and

6) results of the test against mechanical component requirements are summarized and communicated to all affected stakeholders.

Base Practices

BP.1: Develop strategy for the test against mechanical component requirements including regression test strategy.

Develop a strategy for the test against mechanical component requirements consistent with the project plan and the release plan. This includes a regression test strategy for re-testing the mechanical compo-nent if it has been changed. [OUTCOME 1]

NOTE 1: The test strategy shall include a plan of which items need to be tested and the allocation of tests to be performed within different releases. The needed amount of items for dedicated tests shall consider that random and systematic faults have to be detected.

BP.2: Develop test specification for the test against mechanical component requirements.

Develop test specification including test cases for the test against mechanical component requirements that are suitable to provide evidence for compliance of the mechanical component with the mechanical component requirements according to the test strategy. [OUTCOME 2]

BP.3: Select test cases.

Select test cases from the test specification for the test against mechanical component requirements. The selection of test cases shall have sufficient coverage according to the test strategy for the test



28

against mechanical component requirements and the release plan. [OUTCOME 5]

BP.4: Test the mechanical component.

Test the mechanical component using the test specification for the test against mechanical component requirements according to the strategy for the test against mechanical component requirements. Rec-ord the test results and measured values. [OUTCOME 3]

NOTE 2: See SUP.9 for handling of non-conformances.

NOTE 3: Capable test environment as defined in the test strategy needs to be available for performing test against mechanical component requirements.


1. Establish bidirectional traceability between the mechanical component requirements and the test specification for test against mechanical component requirements.

2. Establish bidirectional traceability between the test specification for the test against mechanical component requirements and test results.

3. Establish bidirectional traceability between the mechanic component qualification test results and the tested mechanical component items.

[OUTCOME 4]



1. Ensure consistency between the mechanical component requirements and the test specification for the test against mechanical component requirements.

2. Ensure consistencybetween the test specification for the test against mechanical component requirements and test results.

3. Ensure consistency between the mechanic component qualification test results and the tested mechanical component items.

[OUTCOME 4]



Summarize the test results and communicate them to all affected stakeholders. [OUTCOME 5]



08-50 Test specification [OUTCOME 2]

08-52 Test plan [OUTCOME 1]


13-19 Review record [OUTCOME 3, 4]





29

Annex A – Conformity of the process assessment and refer-ence model -- Under development by intacs --



30

Annex B – Work Product Characteristics Work product characteristics listed in this Annex can be used when reviewing potential outputs of pro-cess implementation. The characteristics are provided as guidance for the attributes to look for, in a particular sample work product, to provide objective evidence supporting the assessment of a particular process.

A documented process and assessor’s judgment is needed to ensure that the process context (applica-tion domain, business purpose, development methodology, size of the organization, etc.) is considered when using this information.

Work products are defined using the schema in table B.1. Work products and their characteristics should be taken as a starting point for evaluating whether work products are contributing to the intended purpose of the process in a given context, and not as a check-list of what every organization must have.

Work product identifier

A unique identifier for the work product which is used to reference the work prod-uct.

Work product name

Provides an example of a typical name associated with the work product character-istics. This name is provided as an identifier for the type of work product the prac-tice or process might produce. Organizations may call these work products different names. The name of the work product within the organization is not significant. Similarly, organizations may have several equivalent work products which contain the characteristics defined in one work product type. The formats for the work products can vary. It is up to the assessor and the organizational unit coordinator to map the actual work products produced in their organization to the examples given here.

Work product characteristics

Provides examples of the potential characteristics associated with the work product types. The assessor may look for these in the samples provided by the organization-al unit.

Table B.1 – Structure of WPC tables

The work products defined in table B.2 extend the work products listed in Annex B of Automotive SPICE. The generic work products (ID nn-00) stay the same. To avoid confusion, IDs of work products listed in this annex have been extended by ME (ID nn-MExx).

Table B.2 – Work product characteristics

WP ID WP Name WP Characteristics

04-ME01 Mechanical system architectural design

Describes the overall mechanical structure

Identifies the required mechanical elements

Identifies own developed and supplied mechanical ele-ments

Identifies the relationships and dependencies be-tween mechanical elements

Describes how variants for different model series or con-figurations are derived

Describes the dynamic behaviour of the mechanic

Consideration is given to:

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_



31

o any required mechanical performance character-istics

o any required mechanical interfaces

o any required critical characteristics

E.g. block diagram, P diagram/boundary diagram (Inter-face control document), system structure, 3D model

04-ME02 Mechanical component design

Provides detailed design (could be represented as a drawing, CAD model, data sheet, requirements and data relevant for pro-duction, handmade prototype)

08-ME01 Sample control plan A control plan shall contain:

specifications to be verified

process parameters to be verified

verification methods to be used

a procedure how to handle non-conformances

verification infrastructure/equipment to be used

11-ME01 Mechanical System Mechanical System is a group of at least two mechanical elements (e.g. Mechanical Components, Mechanical Sys-tems) of the architecture.

Mechanical System is an integration of at least two me-chanical items (e.g. Mechanical Components, Mechanical Systems)

11-ME02 Mechanical Component

Mechanical Components are the lowest level of mechani-cal elements of the architecture.

The produced lowest level of mechanical elements of the architecture is also called Mechanical Component.

13-ME01 Characteristics classification record

List of all identified characteristics including classification of the characteristics

13-ME02 Assembly record Identification of the used BOM

Identification of assembled items (e.g. serial number, batch num-ber, lot number)

Records related:

findings

observations

deviations from the plans (e.g. assembly plan, control plan etc.)

13-ME03

Production record Identification of the used BOM

Identification of assembled items (e.g. serial number, batch num-ber, lot number)

Records related:

findings

observations

deviations from the plans (e.g. assembly plan, control plan etc.)

17-ME01 Mechanical system requirements

Identifies standards to be used Identifies any structure considerations/constraints

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_



32

specification Identifies the required elements Identifies the relationships between elements


any required performance characteristics

any required interfaces

any required characteristics (critical, safety etc.)

17-ME02 Assembly instruction Is based on the architecture and contains a description of the steps how the mechanical items shall be assembled/integrated to a mechanical system according to the release plan.

Assembly instruction and control plan are elements of the inte-gration plan.

An assembly instruction contains:

assembly steps

order of the assembly steps

process parameters

required infrastructure (e.g. fixtures, tools, jigs) for the assembly/integration

17-ME03 Bill of material The bill of material (BOM) is a list of all elements of the system including:

ID of the elements

ID of the BOM

Number of instances of elements

Version of elements

17-ME04 Mechanical component requirements specification

Identifies standards to be used

Identifies any considerations/constraints


any required performance characteristics

any required interfaces

any required characteristics (critical, safety etc.)

any design requirements

19-ME01 Production strategy Identifies what needs and objectives or goals are to be satisfied

Establishes the options and approaches for satisfying the needs, objectives, or goals

Establishes the evaluation criteria against which the strategic options are evaluated

Identifies any constraints/risks and how these will be addressed

The development of the production strategy is carried out by definition the following fields of production:

process design

locations

vertical range of manufacture

manufacturing equipment

structure and logistics of manufacturing

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_



33

suppliers

staff structure

reference to release plan

reference to project plan

reference to test strategy



34

Annex C – Terminology Table C.3 lists the definition of some terms considered to be helpful for understanding the mechanical extension of Automotive SPICE. It lists some mechanical related terms as well as the interpretation of some terms taken from Automotive SPICE and used in the mechanical context.

Table C.3 – Terminology

Term Origin Description

Application parameter

Automotive SPICE® 3.0

An application parameter is specifying design characteristics of mechanic components or systems determining functions, be-havior or properties.

The notion of application parameter is expressed in two ways:

the logical specification (including name, description, unit, value domain or threshold values or characteris-tic curves, respectively), and

the actual quantitative data value it receives based on the selected variant / application.

Assembly instruction

n/a Is based on the architecture and contains a description of the steps how the mechanic items shall be assembled/integrated to a mechanic system considering the release plan.

Assembly instruction and control plan are elements of the integration strategy.

An assembly instruction contains:

assembly steps

order of the assembly steps

process parameters

required infrastructure (e.g. fixtures, tools, jigs) for the assembly/integration

Bill of material

n/a The bill of material (BOM) is a list of all elements of the sys-tem including:

ID of the elements

Number of instances of elements

Version of elements Capable test environment

n/a Documented, qualified (e.g. gauge repeatability and repro-duceability [R&R]) and released test infrastructure.

Component n/a The components are the lowest level elements of the mechan-ical system architectural design for which finally the compo-nent design is defined.

Consistency Automotive SPICE® 3.0

Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Con-sistency is supported by bidirectional traceability.

See also chapter D.4.

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_



35

Control plan IATF ISO16949 Appendix A

Is a plan which ensures that the processes are defined and implemented and that the assembled system fulfills the re-spective specifications.

A control plan shall contain:

specifications to be verified

process parameters to be verified

verification methods to be used

a procedure how to handle non-conformances

verification infrastructure/equipment to be used Coverage n/a There are:

all objects,

relevant objects,

mapped objects.

Coverage is a measure used to describe the ratio of mapped objects to relevant objects for a specific purpose.

For instance:

Requirements coverage: ratio of mapped system re-quirements versus relevant system requirements

Dimensional test coverage: ratio of tested dimensions versus total numbers of dimensions

Item test coverage: degree of tested items versus all created items

Verification coverage for critical characteristics: ratio of tested or verified (e.g. production process capability – cpk) critical characteristics based on control plan

Design constraints

n/a Limits which must be considered when designing elements.

Limit the number of design variants.

Examples: packaging, costs

Dynamic behaviour

n/a Time dependent physical behaviour of system/components, e.g. thermal behaviour, deformation, motion, vibration, fluid mechanics.

Integration strategy

n/a Defines the order of assembly steps of items based on the release plan.

Integration test

n/a The emphasis of integration testing is on the interfaces and interactions between the different items.

Interaction n/a Interaction occurs between elements of the respective system or between elements of the respective system and the operat-ing environment.

Element#_D.3_Terms_

Element#_D.3_Terms_

Element#_D.3_Terms_



36

Model-based development

n/a Development which is based on models (e.g. analytical, nu-merical) that represent the reality of the respective element in a sufficient way and that are used for sizing, design, simula-tion, optimization and validation.

Note: The sufficient representation of reality shall be verified with tests.

Operating environment

n/a Operating environment is the context in which the considered system works.

Production n/a Production is defined as component manufacturing or system assembly or the combination of both.

Production relevant requirements and data

n/a Identifies requirements and data related to production, like:

process parameters

guidelines

maintenance requirements

required technologies

Element#_D.3_Terms_



37

Production strategy


Wikipedia

ASPICE 3.0 WP 19-00 Strategy

Identifies what needs and objectives or goals there are to be satisfied

Establishes the options and approach for satisfying the needs, objectives, or goals



in the context of production.

Wikipedia [05.03.2017] https://de.wikipedia.org/wiki/Produktionsstrategie

The production strategy is the fundamental setup of a produc-tion system to create goods.

The development of the production strategy is carried out by definition the following fields of production:

process design

locations

vertical range of manufacture

manufacturing equipment

structure and logistics of manufacturing

suppliers

staff structure

reference to release plan

reference to project plan

reference to test strategy

make or buy decision

production process parameters (e.g. pressure, rates, calibration data)

https://de.wikipedia.org/wiki/Produktionsstrategie



38

Regression test strategy


ASPICE 3.0 WP 19-00 Strategy

Identifies what needs and objectives or goals there are to be satisfied

Establishes the options and approaches for satisfying the needs, objectives, or goals



in the context of regression testing.

A regression test strategy shall define:

when to perform regression tests

how to identify and select effective tests for regression testing

how to identify the possible impact of a change that needs regression testing

Regression testing

Selective retesting of a system or item to verify that modifica-tions have not caused unintended effects and that the system or item still complies with its specified requirements.

(See ASPICE 3.0 Glossary)

Release plan n/a Identifies the functionality and features to be included in each release

Identifies the associated elements required (i.e., hardware, software, documentation etc.)

Mapping of the customer requests and requirements to be satisfied to particular releases of the product

Release can be sample phases (e.g. A0, A1, B, C, D)

Purpose of releases can be concept verification, design verifi-cation, design validation, process verification, process valida-tion

Releases n/a A release is an approved baseline of versions of elements and other configuration artifacts (e.g. documents, process descrip-tions, test reports, records).

A release shall have a purpose. The purpose of releases can be concept verification, design verification, design validation, process verification, process validation

Element#_D.3_Terms_

Element#_D.3_Terms_



39

Special characteristics

n/a Special characteristics are e.g.:

Significant characteristics having high impact on de-signed function and on customer satisfaction.

Critical characteristics having high impact on safety and/or legal aspects of the designed function.

Note: A proper method to identify and rate special characteristics is an FMEA.

Further details can be found in

ISO TS 169494 – 2009 (par. 7.3.2.3)

VDA 4

Stakeholder PMBoK Guide Third Edition

Persons and organizations such as customers, sponsors, the performing organization or the public who are actively in-volved in the project or whose interests are positively or nega-tively affected by the performance or completion of the pro-ject. They may also exert influence over the project and its deliverables.

Static behaviour

n/a Time independent physical behaviour of items over required life time, e.g. transmission ratio, weight, mass, geometry.

Test case IEEE 1012-2004 (A) A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specif-ic requirement.

(B) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.

Test specification

n/a The test specification is the container in which all test cases are listed.

Traceability n/a Traceability refers to the existence of references or links be-tween work products.

Traceability supports coverage analysis, impact analysis, re-quirements implementation status tracking etc.

See also chapter D.4.

Upper system n/a The system is broken down into its constituent elements (sys-tems and components) in a tree like structure. The Upper Sys-tem is one level above the level in focus.

Verification criteria

n/a Verification criteria define the qualitative and quantitative criteria for verification of a requirement.

Verification criteria demonstrate that a requirement can be

Element#_D.3_Terms_



40

verified within agreed constraints. (Additional Requirement to 17-00 Requirements specification)



41

Verification method

IEEE 1012-2004 Each requirement must be verifiable. Methods for qualitative or quantitative verification of objects or artifacts, like:

tests reviews simulations calculation tolerance analysis

Verification (A) The process of evaluating a system or component to de-termine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.

(B)The process of providing objective evidence that the soft-

ware and its associated products conform to requirements (e.g., for correctness, completeness, consistency, accuracy) for all life cycle activities during each life cycle process (acquisi-tion, supply, development, operation, and maintenance); satis-fy standards, practices, and conventions during life cycle pro-cesses; and successfully complete each life cycle activity and satisfy all the criteria for initiating succeeding life cycle activi-ties (e.g., building the software correctly).



42

Annex D – Key Concepts The following sections refer the key concepts that have been introduced in the Automotive SPICE PRM resp. PAM 3.0 and describe the adaptations performed in order to create SPICE for Mechanical Engi-neering.

D.1 The "Plug-in" Concept

The process interfaces provided by Automotive SPICE are used to extend the process scope as shown in the following picture.

Figure D.1 – The “Plug-in” concept

D.2 The Tip of the "V"

Automotive SPICE has reorganized the software processes to have per process on the left side of the V one corresponding process on the right side. SPICE for Mechanical Engineering takes this concept but splits SWE.3 Software Detailed Design and Unit Construction into two processes: MCE.2 Mechanical Component Design and MCE.3 Mechanical Component Sample Production. This separates the engineer-ing activities in MCE.2 from the physical production of the product in MCE.3 to reflect the actual pro-ceeding in the industry in a better way (see Figure D.2).



43

Figure D.2 – The tip of the “V”

D.3 Terms “Element”, “Component", “Unit” and “Item”

The definition of element, component and item can be seen in the following picture. Unit – as term from Software engineering – is not used in this standard.

Figure D.3 – The terms “element”, “component” and “item”

Elements are all structural objects on architectural and design level on the left side of the "V". An architecture specifies the elements of the system.

MSE.1Mechanical System

Requirements Analysis

MSE.2Mechanical System Architectural Design

MSE.4Mechanical System Qualification Test


Integration and Integration Test

MCE.1Mechanical Component Requirements Analysis

MCE.2Mechanical Component

Design


Production

MCE.5Test against mechanical

Component Requirements


Component Design

Mechanic System Engineering (MSE)

Mechanic Component Engineering (MCE)


Requirements Analysis

MSE.2Mechanical System Architectural Design

MSE.4Mechanical System Qualification Test


Integration and Integration Test

MCE.1Mechanical Component Requirements Analysis


Design


Production


Component Requirements


Component Design

elem

ents

co

mp

on

ents

item

s



44

Elements are hierarchically decomposed into smaller elements down to the components which are at the lowest level of the architecture.

Components are the lowest level elements of the mechanical system architectural design for which in the end the component design is defined.

Items exist only on the right side of the V-model. They are the implemented / produced counterparts of a corresponding element. This constitutes an n:1 relationship between item(s) and element.

D.4 Traceability and Consistency

Traceability and consistency as defined in Automotive SPICE 3.0 have been adopted as is but extended with traceability and consistency between the built product and corresponding test reports and tracea-bility and consistency between built components and systems to reflect compliance with the bill of ma-terial.

The complete traceability and consistency requirements of SPICE for Mechanical Engineering is shown in the following picture.

Figure D.4 – Traceability and consistency

D.5 “Agree” and “Summarize and Communicate”

This concept has been adopted from Automotive SPICE 3.0 without changes.

D.6 “Evaluate”, “Verification Criteria” and “Ensuring compliance”


D.7 The Relation between “Strategy” and “Plan”




45

Annex E – Mapping to ISO/TS 16949:2009 This chapter maps the processes of SPICE for Mechanical Engineering on Base Practice level to the dif-ferent chapters of ISO/TS 16949:2009.

Table E.4 – Mapping to ISO/TS 16949:2009

Chapter SPICE for Mechanical Engineering Chapter ISO/TS 16949:2009

3 Mechanical System Development 7 Produktrealisierung

3.1 Mechanical system requirements analysis 7.2 Kundenbezogene Prozesse

BP1 Specify ME system requirements 7.2.1; 7.3.2 & 7.3.2.1

Ermittlung der Anforderungen auf das Produkt; Ent-wicklungseingaben & Eingaben für Produktentwicklung

BP2 Structure ME system requirements

BP3 Analyze ME system requirements 7.2.2; 7.2.2.1; 7.2.2.2

Bewertung der Anforderungen in Bezug auf das Pro-dukt; Bewertung der Herstellbarkeit

BP4 Analyze the impact on the operating environment 7.2.2; 7.2.2.1;

Bewertung der Anforderungen in Bezug auf das Produkt

BP5 Develop verification criteria 7.3.5 Entwicklungsverifizierung

BP6 Establish bidirectional traceability 7.1.4 & 7.3.7

Lenkung von Änderungen & von Entwicklungsänderun-gen

BP7 Ensure consistency 7.1.4 & 7.3.7


BP8 Communicate agreed ME requirements 7.2.3; 7.2.3.1; 4.2.4

Kommunikation mit den Kunden; Lenkung von Auf-zeichnungen

3.2 Mechanic system architectural design 7.3 Entwicklung

BP1 Develop ME system architectural design

BP2 Allocate ME system requirements

BP3 Define interfaces of mechanic elements

BP4 Identify significant and critical characteristics 7.3.2.3 Besondere Merkmale

BP5 Describe dynamic and static behaviour 7.3.3.1 Ergebnisse der Produktentwicklung

BP6 Consider, determine, and document design constraints 7.3.3.1 Ergebnisse der Produktentwicklung

BP7 Evaluate alternative ME system architectures 7.3.2.1 Eingaben für Produktentwicklung

BP8 Establish bidirectional traceability



BP10 Communicate agreed ME system architectural design 7.2.3; 7.2.3.1; 4.2.4


3.3 Mechanic system integration test 7.3 Entwicklung

BP1 Develop mechanic system integration strategy

BP2 Develop ME system integration test strategy incl. regres-sion test strategy

BP3 Develop specification for mechanic system integration test 7.3.5 Entwicklungsverifizierung

BP4 Integrate mechanic components and mechanic items 7.3.6.2; 7.5.1

Prototypenprogramm; Lenkung der Produktion u. der Dienstleistungserbringung



46

BP5 Select test cases 7.3.5 Entwicklungsverifizierung

BP6 Perform mechanic system integration test 7.3.5, 8.2.4

Entwicklungsverifizierung; Überwachung und Messung des Produkts




BP9 Summarize and communicate results 7.2.3; 7.2.3.1; 4.2.4


3.4 Mechanic system testing 7.3 Entwicklung

BP1 Develop ME system qualification test strategy including regression test strategy

BP2 Develop specification for mechanic system qualification test

7.3.5 Entwicklungsverifizierung


BP4 Test integrated mechanic system 7.3.5, 8.2.4







4 Mechanical Component Development 7 Produktrealisierung

4.1 Mechanical component requirements analysis 7.2 Kundenbezogene Prozesse

BP1 Specify ME component requirements 7.2.1; 7.3.2 & 7.3.2.1

Ermittlung der Anforderungen auf das Produkt; Ent-wicklungseingaben & Eingaben für Produktentwicklung

BP2 Structure ME component requirements

BP3 Analyze ME component requirements 7.2.2; 7.2.2.1; 7.2.2.2

Bewertung der Anforderungen in Bezug auf das Pro-dukt; Bewertung der Herstellbarkeit

BP4 Analyze the impact on the operating environment 7.2.2; 7.2.2.1;

Bewertung der Anforderungen in Bezug auf das Produkt

BP5 Develop verification criteria 7.3.5 Entwicklungsverifizierung

BP6 Establish bidirectional traceability 7.1.4 & 7.3.7




BP8 Communicate agreed ME component requirements 7.2.3; 7.2.3.1; 4.2.4


4.2 Mechanic component design 7.3 Entwicklung

BP1 Develop ME component design

BP2 Evaluate ME component design




BP5 Communicate agreed ME component design 7.2.3; 7.2.3.1; 4.2.4




47

4.3 Mechanic component production 7.5 Produktion und Dienstleistungserbringung

BP1 Develop mechanic component production strategy 7.3.2.2; 7.5.1.1

Eingaben für die Produktionsprozessentwicklung; Produktionslenkungsplan

BP2 Agree mechanic component production strategy

BP3 Produce ME components 7.3.6.2 & 7.3.6.3; 7.3.3.2

Prototypenprogramm & Produktionsprozess- und Produktfreigabe; Ergebnisse der Produktionsprozess-entwicklung




BP6 Provide feedback to all affected parties

7.2.3; 7.2.3.1; 7.3.2.2; 4.2.4

Kommunikation mit den Kunden; Eingaben für die Produktionsprozessentwicklung; Lenkung von Auf-zeichnungen

4.4 Test against mechanic component design 8.2 Überwachung und Messung

BP1 Develop strategy for test against ME comp design incl. regression test strategy

BP2 Develop test specification for test against ME comp design


BP4 Test ME component 7.3.5, 8.2.4







4.5 Test against mechanic component requirements 8.2 Überwachung und Messung

BP1 Develop strategy for ME component testing including regression test strategy

BP2 Develop test specification for ME component testing


BP4 Test ME component 7.3.5, 8.2.4







Documents

Process Assessment Model SPICE for Mechanical … · SPICE for Mechanical Engineering 1 Process Assessment Model ... made possible by the kind contribution of the following companies