Exclusion of special vehicles and mopeds

Define hardware security requirements

Refine the HSI hardware-software interface specification

Check consistency with the concept of technical safety

Specification of functionality-related security requirements

Design verification criteria

Create a design that supports security-oriented analytics

Specify functional safety requirements throughout the lifecycle

Verify compliance with security requirements

Architectural design

Detailed design

Initial purpose to support design specifications

Identification of safe faults, single point faults and multiple faults

Verification according to ISO 26262-82018

Design verification methods

Safety-related special characteristics shall be specified if safety analysis has shown these characteristics to be relevant.

Provide evidence on the suitability of architectural design

Estimated failure rates for hardware parts

Diagnostic coverage of security mechanisms

Provide evidence that the residual risk of breach of security objectives is low

Probability metric for random hardware failures PMHF

Evaluation of each cause of breach of EEC safety objectives

A method for evaluation of each cause of a safety goal violation due to random hardware failures is illustrated by flowcharts

Each dual point failure is first evaluated regarding its plausibility. A dual-point failure is considered implausible if both faults leading to the failure are detected or perceived in a sufficiently short time with sufficient coverage.

If a fault evaluation fails to comply with the criterion combining occurrence of the fault and coverage of the safety mechanisms, the corresponding dual point failure can then be evaluated against a criterion of occurrenc

A residual fault occurring in a hardware part shall be considered acceptable if the failure rate class ranking complies with the targets given in Table 8 for the diagnostic coverage (with respect to residual faults) of the corresponding hardware part.

Quantitative target values of requirements 9.4.2.2 or 9.4.2.3 shall be expressed in terms of average probability per hour over the operational lifetime of the item.

Quantitative target values for the maximum probability of the violation of each safety goal at item level due to random hardware failures as required in ISO 26262-4:2018, 6.4.5, shall be defined using one of the sources

When an item consists of several systems, the derived target value of requirement 9.4.2.2 may be directly allocated to each system composing the item.

Ensure compliance with hardware security requirements

Qualification of hardware parts according to quality standards

Specification of test cases for integration testing

Hardware durability and robustness verification

Functional and environmental testing

Statistical and limit tests

Mechanical and accelerated life tests

Derivation of safety requirements from the technical concept

Avoid failures that do not significantly increase risk

Definition of hardware architectural metrics

Reasoning to Meet Failure Metrics

Assessment based on security analysis

Procedure for budgeting PMHF in systems

Classification of security mechanisms according to their function