寻找供应商
广告
首页 > 电子系统测试 > 正文

功能安全系统需求的良好实践

2021-12-17 20:49:02·  来源：薄说安全  
　
需求性文件对于产品开发的重要性不用多说，研发中的许多问题都是由于不完整的、不成熟的、不正确的、模糊有歧义的、糟糕的系统需求而引发的。对于功能安全领域，
需求性文件对于产品开发的重要性不用多说，研发中的许多问题都是由于不完整的、不成熟的、不正确的、模糊有歧义的、糟糕的系统需求而引发的。对于功能安全领域，如何开发出安全、可靠的产品，良好的系统需求性文件是关键的一个环节，笔者将结合功能安全标准以及实践经验，来讲讲如何写好功能安全产品系统需求的一些良好实践方法。
需求的结构化
系统需求应采用结构化的方法，根据需求类型进行分类，逐级细化，拆分到最简单直观的层次，常见的结构化分类方式包括：
  1. 系统应用场景及任务概要；
  2. 输入文件；
  3. 参考标准；
  4. 功能需求（包括安全功能及对应的安全目标，和非安全功能）；
  5. 性能需求；
  6. 接口需求；
  7. 环境适应性需求；
  8. 可信性需求（可靠性、可用性、可维护性、维修保障）；
  9. 系统约束和假设；
  10. 其它。
其中1，2，3，9，10为系统需求的描述性内容（information），为4，5，6，7，8提供支撑，而4，5，6，7，8则为系统需求的正式内容（specification）。
需求的基本属性
EN50126、DO-178C、ISO26262都有对需求属性的基本要求，包括：
完整性（complete）：每个需求项应包括对应此项的全部必要信息，不需要进一步扩展；
正确性（precise）：需求描述的内容如功能定义、性能要求等是正确的；
无歧义（unambiguous）：不能模棱两可，需求只能有一个解释，设计实现者可以无歧义地理解；
可验证（verifiable）：需求是可验证的，通过评审、分析或测试的验证方法，以确定需求被正确的实现，对于可测性需求能够对照需求完成测试用例；
可追踪（traceable）：需求的可追踪性以便其可以追踪到更底层的需求，纵向追踪如软件到代码级，硬件到板级，横向追踪如需求与测试用例之间的对应关系；
可维护（maintainable）：需求条目的修改、删除、增加是清晰可见的，项目内部对于需求的更新有着一致的认识。
为什么需求有着以上的属性，有些人认为我是这么想的，写这么复杂干什么。系统需求在产品开发生命周期中作为顶层文件，不同的参与方都将利用系统需求开展开发、安全分析、验证确认等工作，因此需求必须明确、清晰、简洁，以易于理解。
下面举一些示例来说明下什么是良好的需求。
良好需求的示例
1.系统功能需求
系统功能应逐级分解，以致到最低层不可再分解的条目。如图，以制动系统的紧急制动功能为例，从顶层功能向下分解，包括EB1（制动指令获取）、EB2（制动指令传递）、EB3（列车载荷计算）、EB4（紧急制动力计算）、EB5（部分制动力丧失后再分配）、……。每个子功能再按照输入-处理-输出的逻辑关系进行描述。


系统需求结构化示例
2.安全相关功能需求
对于安全相关功能，不仅应标记出从风险分析分配的安全目标（SIL等级），而且在需求的通用属性要求外，还应规定：
  • 安全侧（safe state）定义；
  • 定义从故障发生、系统检测到故障到进入到安全侧的最大允许时间，轨道交通叫做SDT（safe down time），汽车叫做FTTI（fault tolerant time inteval）


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）作为补充；
在低层次的需求，定义了精确的硬件和软件行为，采用形式化或半形式化方法更合适，但也没有必要每条需求都用。


EN50128 软件需求推荐的技术方法


ISO26262 安全需求推荐的技术方法
自然语言（文本语言）作为需求表达的基本方法，人们在日常表达经常存在歧义，在需求管理中，经常会举下面这个例子。


以上这个例子虽然有些夸张，但实际项目中不同的人由于知识背景、社会背景和经验能力的差别，对同一需求的理解确实千差万别，需求和设计实现出现这么大的差异也就不足为怪了。
在需求的表达上有基本的规则可以遵循，建立一个需求模板是很有必要的，使得需求简单且易于理解，减少自然语言对语义表达的影响。
在Klaus Pohl. Chris Rupp的《Requirements Engineering Fundamentals》一书中，推荐了一类描述功能需求的自然语言模板如下：


在这个模板框架中，采用"主语+动词+宾语+补语 "的结构，要求的强烈程度分为SHALL/SHOULD/WILL/MAY，需求的过程表达了三种行为：
  • 系统自动执行该过程；
THE SYSTEM SHALL/SHOULD/WILL/MAY <process verb>
  • 系统提供该过程作为给用户的服务；
THE SYSTEM SHALL/SHOULD/WILL/MAY provide <whom?> with the ability to<process verb>
  • 系统根据另一个系统的输入执行流程，系统等待外部触发事件执行；
THE SYSTEM SHALL/SHOULD/WILL/MAY be able to <process verb>
最后additional details中，用于确定系统在什么条件下执行该流程，常见的条件有逻辑条件和时间条件。
第二个减少需求理解的冲突和误解的方法是，尽早地建立一份项目组共享的术语、缩写和缩略语清单，它包括：
  • 与系统特定相关的技术类术语；
  • 缩写和首字母缩略词；
  • 日常语义在给定的场景中特殊含义；
  • 具有相同含义的不同词；
  • 具有不同含义的相同词。
通过定义术语列表，可以大大提高需求的可理解性，从一开始就避免对可能导致冲突的术语的误解和不同的解释。

以上是对需求的要求、属性和编写规则的一些方法，良好的需求文本对于项目组的每一个成员而言，能够使项目的目标更明确可达，提高协作的工作效率，对于有外部审核要求的项目，简洁清晰的需求对于外方审核也会减少不必要的沟通成本。对需求编写者个人来说，写出一份赏心悦目的需求文档，如同做出一道色香味俱全的美味佳肴，工作的心情自然舒畅。
参考文件：
EN50126-1 2017 Railway Applications - The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS) Part 1: Generic RAMS Process
EN50129 2018 Railway applications – Communication, signalling and processing systems – Safety related electronic systems for signalling
ISO26262-4 2011 Road vehicles - Functional safety -Part 4: Product development at the system level
分享到：
 
反对 0 举报 0 收藏 0 评论 0
  • 汽车测试网V课堂

    汽车测试网V课堂

  • 微信公众号

    微信公众号

  • 汽车测试网手机站

    汽车测试网手机站

• EMC电波暗室的一些资料介绍学习 增加知识储备 • 电动车EMC测试&标准分享
• 汽车电子零部件EMC发射失败解析 • 汽车电子与普通电子产品在静电测试上的差异
• 汽车电磁兼容(EMC)问题的研究 • 汽车电子EMC实验室建设规划的必要性
• 福禄克公司汽车电子测试解决方案 • 比亚迪｜VCU 系统功能安全概念阶段的开发
• 汽车总线测试的“解忧杂货店” • 车载以太网工具链
0 条相关评论
广告
  • 广告

编辑推荐

最新资讯

  • 广告
  • 广告
沪ICP备11026917号-25