功能安全、预期功能安全与信息安全的差异与协同

功能安全标准ISO 26262涵盖了系统和软件层面的生命周期，如图3所示（为简化说明，同步进行的硬件开发生命周期被省略）。虚线以上描述系统层面的活动，虚线以下则描述软件层面的活动。

V模型的左侧包含了系统和软件的规范、设计和实现活动。

在系统层面，从危害分析与风险评估（HARA）开始，从功能安全的角度识别和评估系统的潜在危害及相关风险。接着，确定汽车安全完整性等级（ASIL），得出相应的安全目标，作为顶层的安全需求。

功能安全目标随后细化为一个两阶段的过程。首先转化为一系列功能安全需求，然后转化为技术安全需求。最终的结果被分别记录在功能安全和技术安全概念中。

在建立了技术安全概念后，生命周期进入软件层面。在这一层面，首先定义软件安全需求，接着进行软件架构设计、软件单元设计及软件实现。

接着，我们进入V模型的右侧流程，包括必要的集成、验证和确认（V&V）活动。

这里的基本理念是逐步集成软件和系统，并通过相应的V&V活动确保V模型左侧每个步骤的功能安全。

一旦开发完成，生命周期将继续进入生产和运营阶段。

国际标准ISO/SAE 21434引入了一个网络安全（CySec）生命周期，如图4所示。该生命周期与前面讨论的功能安全生命周期在概念上有一定相似性。

在V模型左侧，初步威胁分析与风险评估（TARA）生成了高层的网络安全目标，并在系统（项目）层面被细化为网络安全概念。这一概念为组件和子组件层面的低层设计提供了指导。

请注意，相比于功能安全生命周期，这里的细化步骤更具通用性。而由于公司结构或系统特性的不同，具体步骤可能会有所差异。

V模型的右侧包括常规的集成、验证和确认活动。一网络安全确认活动之后，即是生产和运营阶段。

网络安全生命周期具有更强的迭代性。如图4的左上部分所示，上述概念、产品开发、生产和运营阶段活动以迭代的方式进行。通过OTA更新进行软件维护成为生命周期中一个重要的组成部分，这样做的原因之一是为了确保整个产品生命周期中必要的网络安全。

到目前为止，我们考虑了两个不同的生命周期：一个针对功能安全，另一个则针对网络安全。这两个标准本身仅指出了协调安全和网络安全活动的必要性，且对于做法只提供了一些概括性的指导。

ISO 26262标准要求应在功能安全、网络安全和其他相关的领域间建立并保持有效的沟通渠道。而网络安全标准ISO 21434也提出，组织应确定与网络安全相关或交互的领域，并建立和维护这些领域之间的沟通渠道，以确定网络安全如何融入现有流程，并实现信息交流的协同效应。

然而，这两项标准都缺乏对功能安全与网络安全协同工程的流程、方法和工具的更详细描述。

因此，两个生命周期的实际对接和协调仍是一个持续研究的领域。

值得注意的是研究项目“EmbeddedSafeSec”。[2]该项目的目标是开发一个流程模型和集成方法论，以确保在开发关键嵌入式系统时的功能安全和网络安全 [EmbeddedSafeSec]。

为此，功能安全和网络安全生命周期被结构化为相关活动，使其至少可以被部分组合成活动对，并能够作为协同工程的一部分被共同处理（见图5）。

图6展示了功能安全和网络安全活动在软件开发中的较为复杂的映射关系，图7则进一步详细展示了软件单元的集成活动。