安全过程的需求结构

根据ISO26262系列标准开发安全需求的流程和顺序如图8和图9所示，并概述如下。具体条款以下列方式表示：“m-n”，其中“m”表示部分的编号，“n”表示该部分中的条款或子条款的编号。

进行危险分析和风险评估（见ISO26262-3：2018的第6条【危害分析和风险评估】），以确定风险并确定这些风险的安全目标。

导出的功能安全概念，它指定了满足安全目标的功能安全要求。这些要求定义了将用于该相关项的安全机制和其他安全措施。此外，还确定了支持这些需求的系统架构要素（见ISO26262-3：2018的第7条【功能安全概念】）。

导出的技术安全概念，规定了技术安全要求及其分配给系统要素，供系统设计实现。这些技术安全要求将指导硬件和软件之间要素的分割（见ISO26262-4：2018的第6条【技术安全概念】）。

系统设计将按照技术安全要求进行开发。它们的实现可以在系统设计规范中指定（见ISO26262-4：2018的第7条【系统设计】）。

最后，将提供硬件安全要求和软件安全要求，以符合技术安全要求和系统设计（见ISO26262-5：2018的第6条【硬件安全要求规范】和ISO26262-6：2018的第6条【软件安全要求规范】）。

图8说明了ISO26262硬件需求与设计子阶段之间的关系。

图8-从概念到硬件的安全要求、设计和测试流程

图9说明了ISO26262系列标准的软件需求、设计和测试子阶段之间的关系。

图9-从概念到软件的安全要求、设计和测试流程

? 系统设计：

系统设计从相关项定义（3-6）不断细化到系统架构设计（4-6）。

? 测试层面间的相关性：

各层次的测试规范和测试用例主要取决于相应的要求和设计。它们通常不相关于其他测试级别的测试规范、测试用例和测试结果。测试规范通常取决于测试环境。

? 测试层面对需求和设计层面的相关：

测试规范和测试用例是从同层面别上的需求中导出的，由同一层面的设计信息支持。

示例：对于性能测试，有关设计的信息是必要的。

? 软件安全需求验证：

软件安全需求验证阶段（6-11）需要软硬件进行集成。

? 外措施等技术：

外部措施和其他技术在车辆层面得到验证。

责任编辑：haq