ISO 26262 Functional Safety Requirement Types】_safety requirement example-CSDN博客

本文链接：https://blog.csdn.net/u013657997/article/details/124132674

本文详细介绍了ISO 26262功能安全标准在系统和软件层面的要求阶段，包括安全目标、功能安全要求、技术安全要求和软件要求。这些阶段为汽车行业中的分布式开发提供了指导，确保电子电气系统的功能安全性和风险管理。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

ISO 26262 Functional Safety Requirement Types

欢迎使用Markdown编辑器
- 新的改变
- ISO 26262 requirement phases on system and software levels

欢迎使用Markdown编辑器

在这里插入图片描述

Automotive E/E safety systems have found suitable development guidance in the ISO 26262 standard
Any system and software development must follow a requirement engineering process
This article explains the requirement types according to ISO 26262 Functional Safety

新的改变

With the aim to provide technical coherence, reliability and safety, requirements engineering is the process for defining, documenting and managing requirements. In the 90s, the IEEE provided a general definition of requirements engineering with five phases: elicitation, analysis, specification, verification and management. Within each industry, requirements engineering has been adapted to the specific domain of application and its constraints but these phases are still reflected. In the automotive industry, the growing complexity of E/E systems and the increasing amount of safety related functions motivated OEMs and suppliers to define a system development approach that focuses on mitigating the safety risks inherent to these systems while achieving their intended functionality. ISO 26262, on behalf of Functional Safety defines a dedicated requirement engineering process with different phases. In this article, we’ll describe the relevant aspects of each phase illustrated with examples.

##Requirements as blueprints to start an ISO 26262 distributed development

Distributed development between OEMs and suppliers is very common in the automotive. For the supplier selection, the OEM’s “Request-For-Quotation” must include at least two things: a formal request to comply with the ISO standard and the list of safety goals* or a set of relevant high-level safety requirements that the supplier will agree on. On an abstraction level, the OEM requirements describe the “What” and the supplier activities will implement the “How”. In the planning activities, roles, responsibilities, work products, selected methods and tools are captured and assigned to each stakeholder in a document called the “Development-Interface-Agreement” (DIA) which will drive the execution of the distributed development.