[ISO 26262, Work Product] Technical Safety Requirements Specification

Brief Introduction

The technical safety requirements specify the technical implementation of the functional safety requirements at their respective hierarchical level; considering both the item definition and the system architectural design, and addressing the detection of latent failures, fault avoidance, safety integrity and operation and service aspects.

Generated in

Technical Safety Concept Design

Used in

to be added

Content

Implementation of the Functional Safety Concept

Technical safety requirements regarding functionality, dependencies, constraints and properties of the system elements and interfaces needed for their implementation.

  • The technical safety requirements shall be specified in accordance with the functional safety concept and the system architectural design of the item considering the following:
    • the safety-related dependencies and constraints of items, systems and their elements;
      • Design constraints can result from:
        • environmental conditions,
        • the installation space,
        • the implementation itself (e.g., available performance, thermal capacity, thermal dissipation),
        • other functional or non-functional requirements (e.g., security, physical limits of used technology).
    • the external interfaces of the system, if applicable;
    • the configurability of the system.
      • It is determined by variants in the system elements, by configuration data or by calibration data and is often used as part of the strategy to reuse existing systems for different applications.
    • The technical safety requirements shall specify the stimulus response of the system that affects the achievement of safety requirements. This includes the combinations of relevant stimuli (and failures) with each relevant operating mode (and defined system state).
      • E.g., The Brake System ECU disables ACC (Adaptive Cruise Control) braking, if a received ACC command message fails Error Detection Code (EDC) checks.
    • If the system / element also contains Non-safety-related functions (i.e., functions that are not specified in safety requirements), their specification also need to be documented or referenced.
      • Other requirements can come from Economic Commission for Europe (ECE) rules, Federal Motor Vehicle Safety Standard (FMVSS), company platform strategies, functional concepts or other concepts such as cybersecurity concept.
    • Technical safety and non-safety requirements shall not contradict.

Safety Mechanisms

Technical safety requirements regarding the safety mechanisms to be implemented in the system elements and interfaces.

  • The technical safety requirements shall specify the safety mechanisms that detect faults and prevent or mitigate failures present at the output of the system that violate the functional safety requirements including:
    • the safety mechanisms related to the detection, indication and control of faults that are:
      • in the system itself including communication channel
        • self-monitoring is a common method to detect random hardware faults, if appropriate, also to detect systematic faults.
        • Safety mechanisms can be specified with respect to the appropriate level within the system architecture.
      • in other external elements that interact with the system (e.g., other electronic control units, power supplies or communication devices)
    • the safety mechanisms that contribute to the system achieving or maintaining the safe state of the item
    • the safety mechanisms to define and implement the warning and degradation strategy
    • the safety mechanisms that prevent faults from being latent (usually via self-tests during power up or power down)
  • For each safety mechanism that enables an item to achieve or maintain a safe state, the following shall be specified:
    • the transition between states;
    • the fault handling time interval
    • the emergency operation tolerance time interval
  • To avoid multiple-point failures, the diagnostic test strategy shall be specified for each safety mechanism implemented to detect multiple-point faults, considering:
    • the reliability requirements of the hardware components with consideration given to their role in the architecture and their contribution to a multiple-point failure;
    • the specified quantitative target values for the maximum probability of violation of each safety goal due to random hardware failures (see ISO 26262-5:2018, Clause 9);
    • the assigned ASIL derived from the related safety goal, the related functional safety requirement or technical safety requirement at a higher hierarchical level;
    • the multiple-point fault detection time interval.
    • Diagnostic test strategies include:
      • periodic testing of the system or elements during operation
      • self-tests of elements during power-up or power-down
      • testing the system or elements during maintenance
  • The development (w.r.t. ASIL) of safety mechanisms that are implemented only to prevent dual point faults from being latent shall at least comply with:
    • ASIL B for technical safety requirements assigned ASIL D;
    • ASIL A for technical safety requirements assigned ASIL B and ASIL C;
    • QM for technical safety requirements assigned ASIL A.
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值