In this post, we will talk about ISO26262 Part 4 Clause 6 Technical Safety Concept. (The other clauses are briefly described below this post.)
Basic explanation of Technical Safety Concept (TSC)
The Technical Safety Concept (TSC) is a process of deriving specific Technical Safety Requirements (TSR) to satisfy the Functional Safety Requirements (FSR) of the system and designing the system architecture based on them. This process includes the following main steps:
1. Deriving Technical Safety Requirements
- Deriving based on Functional Safety Requirements: Technical safety requirements are converted into technical requirements that can specifically implement the functional safety requirements. For example, specify the hardware and software conditions required for a specific function to operate safely.
- Adding Safety Mechanisms: Integrate additional safety mechanisms required to satisfy the functional safety requirements into the system architecture. This includes mechanisms such as fault detection, avoidance, and mitigation.
2. System Architecture Design and Update
- Integrate Safety Mechanisms: Update the initial architecture of the FSC phase by adding safety mechanisms. For example, it may include a redundant system configuration or a fault monitoring system.
- Assign Technical Safety Requirements: Assign technical safety requirements to the system architecture or individual elements (hardware, software).
3. Safety Analysis for System Architecture
- Perform Safety Analysis: Analyze whether the system architecture satisfies the functional safety requirements and does not violate the safety goals. Use methods such as FMEA (Failure Mode and Effects Analysis) and FTA (Fault Tree Analysis).
- Modify Architecture and Requirements: If the safety analysis results do not satisfy the functional safety requirements or violate the safety goals, modify the system architecture and technical safety requirements. This process is iterative.
4. Confirm Technical Safety Requirements
- Specify Conditional Responses: Technical safety requirements must specify conditional responses that affect the achievement of safety requirements.
- Specify Non-Safety Functions: Functions or requirements other than technical safety requirements must also be specified. – Ensure traceability: Traceability between technical safety requirements and functional safety requirements must be ensured, and the allocation to hardware or software elements must also be specified.
- Comply with fault tolerance time intervals: The fault tolerance time intervals specified in the functional safety requirements must also be included in the technical safety requirements.
5. Considerations
- Dependencies on other items: When determining technical safety requirements, consider whether they depend on other safety-related items.
- Constraints and external interfaces: Constraints such as the external interfaces and configurability of the system must also be considered.
- System configurability: Evaluate whether the system can actually be implemented.
Safety Mechanism
Safety mechanisms are system, hardware, and software measures that are necessary to detect a fault that may violate functional safety requirements, or to avoid or mitigate system failures. These mechanisms are specified according to technical safety requirements and are added to prevent system failures.
Major Safety Mechanisms
1. Self-detection, display, and control of faults
- Description: The system detects a fault on its own, notifies the user of it, and prevents or mitigates the failure through control when a fault occurs.
- Example: The function of the engine control unit (ECU) of a car detecting a fault and notifying the driver by displaying a warning light on the dashboard.
2. Transition and maintenance of safe state of items
- Description: This is a mechanism that transitions the system to a safe state when a fault occurs and maintains safety.
- Example: The function of the vehicle’s brake system automatically switching to safe mode when a fault occurs and maintaining minimum braking force. 3. Definition and Implementation of Performance Degradation and Warning
- Description: Degrades performance when a fault occurs to ensure safe operation of the system and provides a warning to the user.
- Example: Battery management system (BMS) degrades performance when overheated to ensure battery safety and displays a warning.
3. Latent Fault Detection
- Description: Detects and prevents latent faults that have not yet occurred.
- Example: Tire pressure monitoring system detects low tire pressure and displays a warning.
4. Detection, display, and control management of other system-related element faults
- Description: Function to detect, control, and notify the user of faults related to other elements in the system.
- Example: ECU detects and displays a fault in a sensor or actuator.
Technical requirements for safety mechanisms that move to a safe state
When using a mechanism that moves to a safe state, the following must be specified in the technical requirements:
- Transition between states: Clearly define under what conditions the system transitions to which state. – Assigned Fault Handling Time (FHTI): The time it takes to detect and handle a fault.
- Emergency Operation Time (EOTT): The time it takes to maintain minimum functionality in the event of a fault, if necessary.
Implementation of Safety Mechanisms According to ASIL Level
The implementation of safety mechanisms varies depending on the ASIL (Automotive Safety Integrity Level) level assigned to the technical safety requirement. Higher levels require more stringent safety requirements and may include the following countermeasures:
- Latent Fault Countermeasures: Measures to detect and prevent latent faults.
- Multiple Fault Countermeasures: Considering the possibility of multiple faults occurring simultaneously, mechanisms are established to detect and respond to them.
Fault Tolerant Time Interval (FTTI)
Since car accidents can occur in an instant, it is very important to set up safety mechanisms to operate immediately when a fault occurs. To do this, various time intervals related to the Fault Tolerant Time Interval (FTTI) are defined, and safety mechanisms are operated within these times to prevent accidents.
Definition and Description of Each Time Interval
1. Fault Tolerant Time Interval (FTTI)
- Definition: The minimum time between a fault occurring in an item and a hazardous event occurring, without any safety mechanisms being activated.
- Description: The safety mechanisms must operate properly during this time to prevent the fault from leading to an accident. For example, in the event of a brake system failure, the vehicle must have enough time to safely stop.
2. Fault Detection Time Interval (FDTI)
- Definition: The time it takes for a fault to occur and detect it.
- Description: The time it takes for a system to recognize a fault and detect it. For example, the time it takes a sensor to detect a fault.
3. Fault Reaction Time Interval (FRTI)
- Definition: The time it takes for a system to reach a safe state or emergency operation state after a fault is detected.
- Description: The time it takes for a system to immediately react and transition to a safe state or emergency operation state after a fault is detected. For example, the time it takes to safely stop an engine or maintain it at a minimum performance level when an engine fault occurs.
4. Fault Handling Time Interval (FHTI)
- Definition: The sum of the Fault Detection Time Interval and the Fault Reaction Time Interval.
- Description: The total time it takes for a fault to occur, be detected, and complete a response to it. Includes the time during which the system can safely respond after a fault is detected.
5. Emergency Operation Time Interval (EOTI)
- Definition: The time during which an emergency operation is maintained.
- Description: It refers to the time during which the system can remain in an emergency operation state. For example, the time during which the engine can be operated at minimum power before it completely stops.
System Architecture and Technical Safety Concept
System Architecture in the Technical Safety Concept Phase
The system architecture in the Technical Safety Concept (TSC) phase is designed based on the item definition and functional safety concept while maintaining consistency with the preliminary system architecture utilized in the functional safety concept phase. In this process, several important factors must be considered to meet the technical safety requirements and ensure the safety of the system.
1. Maintain Consistency with the Preliminary System Architecture
- Description: The preliminary system architecture developed in the functional safety concept phase must be maintained. If any differences are found with the preliminary system architecture, the functional safety concept phase must be repeated to update the functional safety requirements.
- Purpose: Maintain consistent design to ensure the safety and reliability of the system.
2. Design based on Item Definition and Functional Safety Concept
- Description: The system architecture is designed based on the item definition and functional safety concept. It defines the overall structure of the system and clarifies how each component interacts.
- Purpose: Design each element of the system to meet the functional safety requirements. 3. Implementation of technical safety requirements
- Description: The system architecture must be able to implement technical safety requirements. This ensures that each component of the system satisfies the technical safety requirements.
- Purpose: Satisfy technical safety requirements to ensure the safety of the system.
3. Definition of internal and external interfaces
- Description: The system architecture must define internal and external interfaces between elements. This ensures that other elements do not adversely affect safety-related elements.
- Purpose: Maintain safety by ensuring that each component of the system does not interfere with each other.
System architecture design and update procedures
1. Review preliminary system architecture
- Review preliminary system architecture at the functional safety concept stage.
- Compare with functional safety concept to maintain design consistency.
2. Design based on item definition and functional safety concept
- Design the system architecture based on item definition and functional safety concept.
- Clearly define each component of the system and its interactions.
3. Implementation of technical safety requirements
- Verify that the system architecture satisfies technical safety requirements. – Design each component to operate safely.
4. Define internal and external interfaces
- Define internal and external interfaces between elements.
- Design safety-related elements so that they are not affected by other elements.
5. Update when differences are found
- If differences are found from the preliminary system architecture, repeat the functional safety concept phase and update the functional safety requirements.
- Finalize the final system architecture through repeated reviews and modifications.
Safety Analysis and Random Hardware Failures and Countermeasures
Safety Analysis Methods
Safety analysis of system architecture is performed differently depending on the ASIL (Automotive Safety Integrity Level) grade of the assigned safety goal. ASIL A applies the inductive analysis method, while ASIL B, C, and D apply both inductive and deductive analysis methods. The main safety analysis methods are as follows:
1. FTA (Fault Tree Analysis)
- Deductive Analysis Method: Top-Down method, starting from one hazardous event and finding the cause step by step. – Use Case: Mainly used in high ASIL levels (B, C, D).
2. FMEA (Failure Mode and Effects Analysis)
- Inductive Analysis Method: Bottom-Up method, describes the phenomenon that occurs when individual causes occur in the upper steps to find the final hazardous event that occurs.
- Use Case: Used in all ASIL levels (A, B, C, D).
Analysis of System Architecture Design
Safety analysis is mainly performed using qualitative methods, and the causes and effects of random hardware failures and systematic failures are analyzed in detail. Failures inside or outside the items identified through this analysis must be eliminated or the effects must be mitigated to satisfy the safety goals or requirements. In addition, if a new risk source is identified, it must be included in the HARA (Hazard Analysis and Risk Assessment) analysis.
Types of failures and countermeasures
1. Systematic failures
- Causes: Process errors, design and requirements documentation errors, operating procedure errors
- Safety measures:
- Establishment of ISO 26262 procedures
- Reliable design
- Reuse of trusted technical safety concepts (TSC)
- Reuse of trusted fault detection and control mechanisms
- Reuse of trusted or standardized interfaces
2. Random hardware failures
- Causes: Aging, stress, life
- Safety measures:
- Safety measures to detect, control, and mitigate failures
- Implement fault detection as software using hardware diagnostic properties
- Transition to a safe state when a failure occurs
Fault handling methods
- Systematic failures can be reduced by following the processes of ISO 26262.
- Random hardware failures must be prevented from violating safety goals through separate hardware or software safety mechanisms. Since safety measures for random hardware failures cannot be perfect, an estimation method for safety goal violations must be selected and a target value must be set for it. It specifies the failure rate of hardware elements or the diagnostic coverage of safety mechanisms to achieve set target values.
Allocation to Hardware and Software
Once the system architecture and technical safety requirements are confirmed, the technical safety requirements are divided into system, hardware, and software elements for technical implementation and allocated. The ASIL (Automotive Safety Integrity Level) assigned to each element inherits the ASIL assigned to the technical safety requirements. This process is a very important step for ensuring the safety of the system.
Allocation Process
1. Definition of System Architecture
- Determine the system architecture that satisfies the technical safety requirements.
- Clearly define the roles and interactions of each element in the architecture.
2. Division and Allocation of Technical Safety Requirements
- Divide the technical safety requirements into system, hardware, and software elements and allocate them.
- The allocated requirements must be satisfied during the design and implementation stages of each element.
3. ASIL Inheritance
- The ASIL assigned to the technical safety requirements is inherited to each element.
- Each element in the system architecture must ensure safety according to the assigned ASIL.
Importance of Assignment
- Maintaining Safety: Each element must be designed and implemented to meet the assigned ASIL to maintain the safety of the entire system.
- Securing Traceability: As technical safety requirements are divided and assigned to system, hardware, and software elements, the roles and responsibilities of each element can be clearly traced.
- Efficient Management: Based on the assigned ASIL, safety analysis, testing, and verification for each element can be efficiently managed.
Hardware-Software Interface (HSI) Specification
The HSI (Hardware Software Interface) specification is a document that defines the interaction between hardware and software in accordance with the technical safety concept. It is initially specified during the system development phase, but is continuously updated during the hardware development (ISO 26262 Part 5) and software development (ISO 26262 Part 6). The HSI specification plays a very important role in ensuring the safety and functionality of the system.
What must be specified in the HSI
1. Hardware parts controlled by software
- Specifies the hardware components directly controlled by the software.
2. Hardware resources for software execution
- Defines the hardware resources (e.g. CPU, memory, bus, etc.) required for the software to execute.
3. Hardware diagnostic capabilities and software use of diagnostic capabilities
- Specifies the diagnostic functions provided by the hardware and how the software uses them.
Characteristics to be specified in HSI
1. Hardware operation mode and configuration parameters
- Default mode: Default hardware settings during normal operation.
- Initial mode: Hardware status and settings during initialization.
- Test mode: Hardware operation mode during testing.
2. Hardware functions supporting inter-element and software partitions
- Hardware functions: Hardware functions that support independent operation of multiple software partitions.
3. Sharing and exclusive use of hardware resources
- Memory sharing: How hardware resources are shared by multiple software.
- Exclusive use: When a specific resource is exclusively used by one software.
4. Access method to hardware devices
- Access method: How software accesses hardware devices (e.g., direct memory access (DMA), interrupts, etc.).
5. Timing constraints derived from technical safety concepts
- Timing constraints: Time constraints required to ensure system safety (e.g., data processing time, response time).
6. Definition of hardware diagnostic functions
- Hardware diagnostic functions: Diagnostic functions provided by hardware (e.g., overcurrent, short circuit, and overheat detection).
- Software-implemented diagnostic functions: Methods for implementing hardware diagnostic functions in software.
Production, Operation, Service, and Decommissioning
Specification for production, operation, service, and decommissioning during the system development phase is to ensure that the system architecture design is appropriate and that functional safety is achieved and maintained during production and operation. To this end, various requirements identified during the system architecture design should be included.
Requirements
1. Measures to Achieve, Maintain, or Restore Safety-Related Functions and Properties
- Description: Provide measures to achieve and maintain the safety-related functions and properties of the system, or to restore them in the event of a failure.
- Examples: Emergency stop function of an autonomous vehicle, regular inspection and maintenance of the brake system.
2. Special Safety-Related Characteristics
- Description: Specify special characteristics directly related to the safety of the system.
- Examples: Battery system that must operate only within a specific temperature range, operating conditions of airbags in the event of a crash.
3. Production Verification Measures
- Description: Define verification methods to verify that the system meets the safety requirements during the production phase. – Example: Quality inspection process on the production line, functional testing of hardware components.
4. Proper identification of the system or element
- Description: Specifies the method for accurately identifying the system or component.
- Example: Unique serial numbering, product tracking with QR code or barcode.
5. Service requirements (diagnostic data, service notes)
- Description: Specifies diagnostic data and service notes required for maintenance and service of the system.
- Example: Vehicle OBD-II (On-Board Diagnostics) data, periodic maintenance manual.
6. Disposal measures
- Description: Specifies procedures for safe disposal of the system at the end of its useful life.
- Example: Safe disposal procedures for batteries, environmentally friendly recycling of electronic equipment.
Diagnostic functions
- Provides field monitoring data: Diagnostic functions provide the data necessary to enable field monitoring of items or elements. This allows for the identification of faults and the determination of items to be inspected during service to restore or maintain functional safety.
- Example: Sensor data that monitors the engine’s operating status in real time to detect abnormalities and diagnose brake pad wear.
Verification
Verification is performed according to clauses 6 and 9 of ISO 26262-8:2018 to ensure the accuracy, completeness, and consistency of technical safety requirements. In addition, the system architecture design, HSI (Hardware Software Interface) specification, and safety specifications for production, operation, service, and disposal are verified by selecting an appropriate method according to the assigned ASIL (Automotive Safety Integrity Level) grade. The objectives of verification are as follows:
1. Confirm the consistency between the system architecture and technical safety requirements
- Confirm that the system architecture and technical safety requirements are consistent with each other.
2. Maintain consistency with the system preliminary architecture
- Confirm that the consistency with the system preliminary architecture established in the concept phase is maintained.
3. Confirm whether the requirements according to the assigned ASIL are satisfied
- Confirm that the requirements are satisfied according to the assigned ASIL.
If you are interested in other articles about ISO 2626 Series, please refer to the links below!
[ISO 26262] #2. Safety Mechanisms for Electrical and Electronic