浅谈功能安全系统需求

最新推荐文章于 2025-08-04 16:13:20 发布

原创最新推荐文章于 2025-08-04 16:13:20 发布 · 990 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#安全 #功能安全 #汽车电子 #汽车 #系统架构 #系统安全

汽车功能安全分析专栏收录该内容

27 篇文章

订阅专栏

写在前面

本系列文章主要讲解功能安全系统需求的相关知识，希望能帮助更多的同学认识和了解功能安全系统需求。

若有相关问题，欢迎评论沟通，共同进步。(*^▽^*)

需求性文件对于产品开发的重要性不用多说，研发中的许多问题都是由于不完整的、不成熟的、不正确的、模糊有歧义的、糟糕的系统需求而引发的。对于功能安全领域，如何开发出安全、可靠的产品，良好的系统需求性文件是关键的一个环节，我们将结合功能安全标准以及实践经验，来讲讲如何写好功能安全产品系统需求的一些良好实践方法。

1. 需求的结构化

系统需求应采用结构化的方法，根据需求类型进行分类，逐级细化，拆分到最简单直观的层次，常见的结构化分类方式包括：

系统应用场景及任务概要；
输入文件；
参考标准；
功能需求（包括安全功能及对应的安全目标，和非安全功能）；
性能需求；
接口需求；
环境适应性需求；
可信性需求（可靠性、可用性、可维护性、维修保障）；
系统约束和假设；
其它。

其中1，2，3，9，10为系统需求的描述性内容（information），为4，5，6，7，8提供支撑，而4，5，6，7，8则为系统需求的正式内容（specification）。

2. 需求的基本属性

EN50126、DO-178C、ISO26262都有对需求属性的基本要求，包括：

完整性（complete）：每个需求项应包括对应此项的全部必要信息，不需要进一步扩展；

正确性（precise）：需求描述的内容如功能定义、性能要求等是正确的；

无歧义（unambiguous）：不能模棱两可，需求只能有一个解释，设计实现者可以无歧义地理解；

可验证（verifiable）：需求是可验证的，通过评审、分析或测试的验证方法，以确定需求被正确的实现，对于可测性需求能够对照需求完成测试用例；

可追踪（traceable）：需求的可追踪性以便其可以追踪到更底层的需求，纵向追踪如软件到代码级，硬件到板级，横向追踪如需求与测试用例之间的对应关系；

可维护（maintainable）：需求条目的修改、删除、增加是清晰可见的，项目内部对于需求的更新有着一致的认识。

为什么需求有着以上的属性，有些人认为我是这么想的，写这么复杂干什么。系统需求在产品开发生命周期中作为顶层文件，不同的参与方都将利用系统需求开展开发、安全分析、验证确认等工作，因此需求必须明确、清晰、简洁，以易于理解。

3. 良好需求的示例

1. 系统功能需求

系统功能应逐级分解，以致到最低层不可再分解的条目。如图，以制动系统的紧急制动功能为例，从顶层功能向下分解，包括EB1（制动指令获取）、EB2（制动指令传递）、EB3（列车载荷计算）、EB4（紧急制动力计算）、EB5（部分制动力丧失后再分配）、……。每个子功能再按照输入-处理-输出的逻辑关系进行描述。

图 1 制动系统的紧急制动功能示例

2. 安全相关功能需求

对于安全相关功能，不仅应标记出从风险分析分配的安全目标（SIL等级），而且在需求的通用属性要求外，还应规定：

1. 安全侧（safe state）定义

定义从故障发生、系统检测到故障到进入到安全侧的最大允许时间，轨道交通叫做SDT（safe down time），汽车叫做FTTI（fault tolerant time inteval）。

2. FTTI时间指标定义

故障诊断安全措施，常见的故障诊断措施如：输入数据的非预期性，是否超限、数据冻结不更新、短路、开路等；
通信链路的七类典型失效模式及防护措施；
冗余数据的比较，输入数据、输出指令的比较；
CPU、内存中内部错误，各类自检机制。

采用哪些故障诊断措施，依赖于系统的危害分析以及选定的安全完整性等级。

安全功能的目标在于防范风险，系统完整性在于系统的健壮性，因此更多考量的是各种故障场景下，系统是否有监控、差异化的故障诊断和响应机制，保障系统发生导向危险失效后能够在规定的时间内导向安全侧。因此对于安全功能要求，以上三点要求缺一不可。

3. 可信性需求

轨道交通常称为RAM需求，包括可靠性、可用性、可维护性和维修保障，常用MTBF、MTTR、可用性A等定量指标进行规定，但在规定定量指标前，确定系统的下述属性非常重要。

系统的应用场景和任务概要——以确定可信性指标对应的系统是在何种应用场景下，执行哪些任务；
系统失效判据——根据系统失效的影响范围，可以将指标进行有区分度的定义，比如影响列车安全的故障、影响列车服务的故障、未对服务质量产生影响但需要维修保障的故障，对应的可信性指标是不同的；
系统的工作条件和环境条件；
用于验证指标符合预期的方法。

4. 性能需求

可以划分为时间性需求和空间性需求，时间性需求有系统运行周期、响应延时、上电启动时间、重启时间等；

空间性需求有内存容量、处理器容量、通信缓存容量、带宽容量，考虑未来的可扩展性和灵活性。

5. 文字和图形化的结合

采用图文结合的方法用于需求编写，如：

系统接口图——用于描述系统内外部接口，并在接口需求再详细描述接口规格；
状态转移图——用于描述系统不同模式之间的转换关系，每个状态用文字描述；
数据流图——用于描述不同系统之间的数据流和时序关系。

但应注意图形并不能完全替代文字，而是作为文字的辅助，帮助阅读者的理解。

其它还有一些通用性的需求，如可测试性、可制造性等，不再赘述。另外，现代安全关键系统的需求编写，还常采用形式化/半形式化、基于模型的设计方法，下面讲讲这些方面。

首先应该了解需求的一些特性要求，需求的要求分为单个需求项要求和一组需求的整体要求。

单个需求项应符合以下要求：

单一的：一条需求是一个明确的，不可分割的元素，它表达的是唯一的一个要求；
简洁的：一条需求必须以单个句子的形式来写，长度不要超过两到三行，大段的文字需要断句分开；
清晰的：句子结构简单，不拖泥带水，没有额外的修饰，阅读者可以完全理解需求；
精确的：需求中使用的所有元素都是可识别的，并有充分的特征；
抽象的：一条需求只是描述需求，不应该是一个具体的技术实现方案；
无二义性的：对该需求的解读应有助于对该需求的理解，并只有一种可能的解释，要用简洁的语言表达，不要用太复杂的句子；
可验证的：必须有一种可行的验证需求的方法，常用的方法有走读、建模、分析、测试；
可实现的：从成本和进度上考虑，需求是可实现的。

由单个需求项构成的一组需求，应符合以下要求：

完整的：没有遗漏的需求，需求集的内容是完整的。完整性比较难以判断，它与需求分析的详尽程度有关。在项目中的需求编写过程，容易忘记定义软件需求在不希望发生的事件中的行为（比如硬件故障，用户输入的数据错误等等）。在确定需求的过程中，有必要检查这些需求是否包括在内，不要让软件实现人员去考虑这些问题；
一致的：需求之间不能有不一致的地方，并在文件中有唯一的标识，需求中使用的专用词汇在每条需求中的表达要一致；
非冗余的：在一组要求中，相同的信息和需求不应多次出现，只表达一次；
充分的：需求的内容是充分的，不需要为了理解需求，去回顾需求之外的其它文件；
结构化的：需求集有清晰的结构，如软件需求按照类别分为功能、接口、性能、硬件约束、安全性、可维护性、可靠性、可用性、可移植性、健壮性等；
模块化的：同一类型的需求应放在一个明确的结构内进行分组；
可扩展的：有灵活的结构，适应需求的变更；
可追溯的：需求与其它项目文件（上下层集）建立追溯关系。

每条需求除了它的内容外，还具备以下这些属性：

属性	描述
ID	需求的唯一标识符
类型	功能、接口、RAM、性能、……
TEXT	需求的内容
SOURCE	需求的来源
STATE	开发中、挂起、已实现、已测试、……
PRIORITY	Key, mandatory, optional, desirable
Verifiable	是/否
type of Verification	走读、分析、建模、测试
Testable	是/否
Version	版本

在了解以上需求的要求和各类属性后，如何编写需求以符合以上的要求。需求表达可以采用自然语言和模型语言两种方法或它们的组合，现在有一种认识，认为模型语言要比自然语言更高级，但是模型的建立并不能替代自然语言表达的需求，如果需求编写者用自然语言表达出来的需求是模棱两可的，那也不能奢望他用模型语言能够表达清楚。

从实践来说，推荐两种方法相结合：

在高层次的需求，用自然语言表达更恰当，可以结合一些半形式化方法（公式、图形、表格、流程图、时序图或其它UML和SysML）作为补充。

在低层次的需求，定义了精确的硬件和软件行为，采用形式化或半形式化方法更合适，但也没有必要每条需求都用。

在需求的表达上有基本的规则可以遵循，建立一个需求模板是很有必要的，使得需求简单且易于理解，减少自然语言对语义表达的影响。

在Klaus Pohl. Chris Rupp的《Requirements Engineering Fundamentals》一书中，推荐了一类描述功能需求的自然语言模板如下：