Process ID

HWE.1

Process name

Hardware Requirements Analysis

Process purpose

The purpose is to establish a structured and analyzed set of hardware requirements consistent with the system requirements, and the system architectural design.

Process outcomes

1) Hardware requirements are specified;

2) Hardware requirements are structured and prioritized;

3) Hardware requirements are analyzed for correctness and technical feasibility;

4) The impact of hardware requirements on the operating environment is analyzed;

5) Consistency and bidirectional traceability are established between hardware requirements and system requirements.

6) Consistency and bidirectional traceability are established between hardware requirements and system architectural design;

7) The hardware requirements are agreed and communicated to all affected parties.

Base practices

HWE.1.BP1: Specify hardware requirements. Use the system requirements, and the system architecture including interface definitions, to identify and document the functional and non- functional requirements of the hardware according to defined characteristics for requirements.

Note 1: Characteristics of requirements are defined in standards such as ISO IEEE 29148, ISO/IEC IEEE 24765, ISO 26262-8:2018, or the INCOSE Guide For Writing Requirements.

Note 2: Examples for defined characteristics of requirements shared by the above-mentioned standards are verifiability (i.e. verification criteria being inherent in the requirements sentence), unambiguity/comprehensibility, freedom from design and implementation, and not contradicting any other requirement.

Note 3: In case of hardware development only, the system requirements and the system architecture refer to a given operating environment. In that case, stakeholder requirements can be used as the basis for identifying the required functions and capabilities of the hardware.

Note 4: The hardware-software-interface (HSI) definition puts in context hardware and therefore is an interface decision at the system design level (see SYS.3). If such a HSI exists, then it may provide input to hardware requirements.

HWE.1.BP2: Structure hardware requirements. Structure and prioritize the hardware requirements.

Note 5: Examples for structuring criteria can be grouping (e.g. by functionality) or variants identification.

Note 6: Prioritization can be done according to project or stakeholder needs via e.g. definition of release scopes. Refer to SPL.2.BP1.

HWE.1.BP3: Analyze hardware requirements. Analyze the specified hardware requirements including their interdependencies to ensure correctness, technical feasibility, and to support project management regarding project estimates.

Note 7: See MAN.3.BP3 for project feasibility and MAN.3.BP5 for project estimates.

Note 8: The analysis of technical feasibility can be done based on a given hardware design (e.g., platform) or by prototype development.

HWE.1.BP4: Analyze the impact on the operating environment. Identify the interfaces between the specified hardware and other elements of the operating environment. Analyze the impact that the hardware requirements will have on these interfaces and the operating environment.

HWE.1.BP5: Ensure consistency and establish bidirectional traceability. Ensure consistency and establish traceability between hardware requirements and the system architecture. Ensure consistency and establish traceability between hardware requirements and system requirements.

Note 9: Redundant traceability is not intended. concern.

Note 10: There may be non-functional hardware requirements that the hardware design does not trace to. Examples are development process requirements. Such requirements are still subject to verification.

Note 11: Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage.

Note 12: In case of hardware development only, the system requirements and system architecture refer to a given operating environment. In that case, consistency and bidirectional traceability can be ensured between stakeholder requirements and hardware requirements.

HWE.1.BP6: Communicate agreed hardware requirements and impact on the operating environment. Communicate the agreed hardware requirements and results of the analysis of impact on the operating environment to all relevant parties.

HWE.1 Hardware Requirements Analysis

Outcome 1

Outcome 2

Outcome 3

Outcome 4

Outcome 5

Outcome 6

Outcome 7

Output Information Items

13-52 Communication Evidence

X

13-51 Consistency Evidence

X

X

17-58 Hardware Requirement

X

X

X

17-54 Requirement Attribute

X

15-51 Analysis Results

X

X

Base practices

BP1: Specify hardware requirements

X

BP2: Structure hardware requirements

X

BP3: Analyze hardware requirements

X

BP4: Analyze the impact on the operating environment

X

BP5: Ensure consistency and establish bidirectional traceability

X

X

BP6: Communicate agreed hardware requirements

X

Process ID

HWE.2

Process name

Hardware Design

Process purpose

The purpose is to provide an analyzed design based on the hardware requirements, that is suitable for manufacturing, and to derive production-relevant data.

Process outcomes

1) A hardware architecture and hardware detailed design is designed that identifies the elements of the hardware and describes their behavior as well as their interfaces, and the dynamic interactions of the hardware elements;

2) The hardware architecture and the hardware detailed design is analyzed and special characteristics are identified;

3) Consistency and bidirectional traceability are established between hardware requirements and hardware design;

4) Hardware production data is derived from the HW detailed design and communicated to all affected parties;

5) Information for production test is derived from the HW detailed design and communicated to all affected parties;

6) The hardware architecture and hardware detailed design and the special characteristics are agreed and communicated to all affected parties.

Base practices

HWE.2.BP1: Develop hardware architecture. Develop the hardware architecture that identifies the hardware components. Document the rationale for the defined hardware architecture.

Note 1: Examples for aspects reflected in the hardware architecture are ground concept, supply concept, EMC concept.

Note 2: Examples for a design rationale can be implied by the reuse of a standard hardware, platform, or product line, respectively, or by a make-or-buy decision, or found in an evolutionary way.

HWE.2.BP2: Develop hardware detailed design. Based on components identified in the hardware architecture, develop the detailed design description and the schematics for the intended hardware variants, including the interfaces between the hardware elements. Derive the layout, the hardware bill of materials, and the production data.

Note 3: The identification of hardware parts and their suppliers in the hardware bill of materials may be subject to a pre-defined repository (see also IATF 16949:2016, clause 8.4.1.2.).

Note 4: Hardware detailed design may be subject to constraints such as availability of hardware parts on the market, hardware design rules, layout rules, creepage and clearance distances, compliance of HW parts with industry standards such as AEC-Q, REACH.

HWE.2.BP3: Specify dynamic aspects. Evaluate and document the dynamic behaviour of the relevant hardware elements and the interaction between them.

Note 5: Not all hardware elements have dynamic behaviour that needs to be described.

HWE.2.BP4: Analyze the hardware architecture and the hardware detailed design. Analyze the hardware architecture and hardware detailed design regarding relevant technical aspects, and support project management regarding project estimates. Identify special characteristics.

Note 6: Examples for technical aspects are manufacturability for production, suitability of pre-existing hardware components to be reused, or availability of hardware elements.

Note 7: Examples of methods suitable for analyzing technical aspects are prototype testing, simulations, calculations, quantitative or qualitative analyses such as FMEA.

HWE.2.BP5: Ensure consistency and establish bidirectional traceability. Ensure consistency and establish traceability between hardware elements and hardware requirements. Ensure consistency and establish traceability between the hardware detailed design and components of the hardware architecture.

Note 8: There may be non-functional hardware requirements that the hardware design does not trace to. Examples are development process requirements. Such requirements are still subject to verification.

Note 9: Bidirectional traceability further supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage.

HWE.2.BP6: Communicate agreed hardware architecture and hardware detailed design. Communicate the agreed hardware architecture and the hardware detailed design, including the special characteristics and relevant production data, to all affected parties.

HWE.2 Hardware Design

Outcome 1

Outcome 2

Outcome 3

Outcome 4

Outcome 5

Outcome 6

Output Information Items

04-52 Hardware Architecture

X

04-53 Hardware Detailed Design

X

15-51 Analysis Results

X

13-51 Consistency Evidence

X

17-57 Special Characteristics

X

13-52 Communication Evidence

X

04-54 Hardware Schematics

X

X

X

14-54 Hardware Bill of Materials

X

X

X

04-55 Hardware Layout

X

X

X

03-54 Hardware Production Data

X

X

X

04-56 Hardware Element Interface

X

Base practices

BP1: Develop hardware architecture

X

X

X

BP2: Develop hardware design

X

X

X

BP3: Specify dynamic aspects

X

BP4: Analyze the hardware architecture and the hardware detailed design

X

BP5: Ensure consistency and establish bidirectional traceability

X

BP7: Communicate agreed hardware architecture and hardware detailed design

X

X

X

Process ID

HWE.3

Process name

Verification against Hardware Design

Process purpose

The purpose is to ensure that the production data compliant hardware is verified to provide evidence for compliance with the hardware design.

Process outcomes

1) Verification measures are specified for verification of the hardware against the hardware design, including the interfaces between hardware elements and the dynamic aspects;

2) Verification measures are selected according to the release scope considering criteria for regression verification;

3) Verification is performed, if applicable on production data compliant samples, using the selected verification measures, and verification results are recorded;

4) Consistency and bidirectional traceability are established between hardware elements and verification measures;

5) Bidirectional traceability is established between verification measures and verification results;

6) Verification results are summarised and communicated to all affected parties.

Base practices

HWE.3.BP1: Specify verification measures for the verification against hardware design. Specify the verification measures suitable to provide evidence for compliance of the hardware with the hardware design and its dynamic aspects, including includes

 techniques for the verification measures

 pass/fail criteria for verification measures

 a definition of entry and exit criteria for the verification measures

 necessary sequence of verification measures

 the required verification infrastructure and environment setup

Note 1: Examples on what a verification measure may focus on are the timeliness and timing dependencies of the correct signal flow between interfacing hardware elements, interactions between hardware components.

Note 2: Measuring points can be used for stepwise testing of hardware elements.

HWE.3.BP2: Ensure use of compliant samples. Ensure that the samples used for verification against hardware design are compliant with the corresponding production data, including special characteristics.

Note 3: Examples of compliance are sample reports, record of visual inspection, ICT report.

HWE.3.BP3: Select verification measures. Document the selection of verification measures considering selection criteria including regression criteria. The documented selection of verification measures shall have sufficient coverage according to the release scope.

Note 4: Examples for selection criteria can be prioritization of requirements, the need for regression due to changes to the hardware design, or the intended use of the delivered hardware release (e.g. test bench, test track, public road etc.)

HWE.3.BP4: Verify hardware design. Verify the hardware design using the selected verification measures. Record the verification results including pass/fail status and corresponding verification measure output data.

Note 5: See SUP.9 for handling of non-conformances.

HWE.3.BP5: Ensure consistency and establish bidirectional traceability. Ensure consistency and establish bidirectional traceability between hardware elements and the verification measures. Establish bidirectional traceability between the verification measures and verification results.

Note 6: Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage.

HWE.3.BP6: Summarize and communicate results. Summarise the verification results and communicate them to all affected parties.

Note 7: Providing all necessary information from the test case execution in a summary enables other parties to judge the consequences.

HWE.3 Verification against Hardware Design

Outcome 1

Outcome 2

Outcome 3

Outcome 4

Outcome 5

Outcome 6

Output Information Items

08-60 Verification Measure

X

08-58 Verification Measure Selection Set

X

15-52 Verification Results

X

13-51 Consistency Evidence

X

X

13-52 Communication Evidence

X

Base practices

BP1: Specify verification measures for the verification against hardware design

X

BP2: Ensure use of compliant samples

X

BP3: Select verification measures

X

BP4: Verify hardware design

X

BP5: Ensure consistency and establish bidirectional traceability

X

X

BP6: Summarize and communicate results

X

Process ID

HWE.4

Process name

Verification against Hardware Requirements

Process purpose

The purpose is to ensure that the complete hardware is verified to be consistent with the hardware requirements.

Process outcomes

1) Verification measures are specified for verification of the hardware against the hardware requirements;

2) Verification measures are selected considering criteria for regression verification;

3) Verification is performed, if applicable on production data compliant samples, using the selected verification measures, and verification results are recorded;

4) Consistency and bidirectional traceability are established between verification measures and hardware requirements;

5) Bidirectional traceability is established between verification measures and verification results;

6) Verification results are summarized and communicated to all affected parties.

Base practices

HWE.4.BP1: Specify verification measures for the verification against hardware requirements. Specify the verification measure to provide evidence for compliance with the hardware requirements. This includes

 techniques for the verification measures

 pass/fail criteria for verification measures

 a definition of entry and exit criteria for the verification measures

 necessary sequence of verification measures

 the required verification infrastructure and environment setup

Note 1: The system verification measures may cover aspects such as thermal, environmental, robustness/lifetime, and EMC.

HWE.4.BP2: Ensure use of compliant samples. Ensure that the samples used for the verification against hardware requirements are compliant with the corresponding production data, including special characteristics, provided by hardware design.

Note 2: Examples of compliance are sample reports, record of visual inspection, ICT report.

HWE.4.BP3: Select verification measures. Document the selection of verification measures considering selection criteria including regression criteria. The documented selection of verification measures shall have sufficient coverage according to the release scope.

Note 3: Examples for selection criteria can be prioritization of requirements, the need for regression due to changes to the hardware requirements, or the intended use of the delivered hardware release (e.g. test bench, test track, public road etc.).

HWE.4.BP4: Verify the compliant hardware samples. Verify the compliant hardware samples using the selected verification measures. Record the verification results including pass/fail status and corresponding verification measure output data.

Note 4: See SUP.9 for handling of non-conformances.

HWE.4.BP5: Ensure consistency and establish bidirectional traceability. Ensure consistency between hardware requirements and verification measures. Establish bidirectional traceability between hardware requirements and verification measures. Establish bidirectional traceability between verification measures and verification results.

Note 5: Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage.

HWE.4.BP6: Summarize and communicate results. Summarize the verification results and communicate them to all affected parties.

Note 6: Providing all necessary information from the test case execution in a summary enables other parties to judge the consequences.

HWE.4 Verification against Hardware Requirements

Outcome 1

Outcome 2

Outcome 3

Outcome 4

Outcome 5

Outcome 6

Output Information Items

08-60 Verification Measure

X

08-58 Verification Measure Selection Set

X

15-52 Verification Results

X

13-51 Consistency Evidence

X

X

13-52 Communication Evidence

X

Base practices

BP1: Specify verification measures for the verification against hardware requirements

X

BP2: Ensure use of compliant samples

X

BP3: Select verification measures

X

BP4: Verify hardware

X

BP5: Ensure consistency and establish bidirectional traceability

X

X

BP6: Summarize and communicate results

X