安全案例可视化方法及车联网安全设计模式研究

# 安全案例可视化方法及车联网安全设计模式研究 ## 1 现有安全分析方法的局限性 在安全分析领域，当前存在多种方法，但都有一定的局限性。例如，一些方法虽能进行安全分析，却无法在一个图中对所有相关信息进行可视化展示。 Nordmann 等人提出通过对每个组件进行安全分析并构建整个系统的故障树来创建组件故障树（CFT）的方法。该方法依据 SysML 的内部块和活动图严格描述的语义，结合每个组件的故障树分析（FTA）结果构建 CFT。然而，分析师和审查人员可能会错过跨越组件边界的故障传播或原因，以及 SysML 模型中不明确的链接。 Clegg 等人提出了一种用于 SysML 的补充故障模型符号，采用故障树模型作为故障模型。此方法将故障模型与系统模型相结合，但未描述如何在一个图中集成系统模型和故障模型。 Tim Gonschorek 提出了一种名为 SafeDeML 的建模语言，将故障模型与系统模型相结合，但同样未描述如何在一个图中同时表达这两个模型。 ## 2 相关标准与方法 ### 2.1 AIAG/VDA FMEA 手册和 OMG 标准 AIAG/VDA FMEA 手册引入了 FMEA - MSR（用于监测和系统响应的补充 FMEA）。传统的设计故障模式及影响分析（DFMEA）分析故障模式的原因和影响之间的故障链，而 FMEA - MSR 分析混合故障链，即故障模式、监测和系统响应的链。监测涉及检查故障原因或故障模式，系统响应处理监测到的故障，减轻的故障影响是处理故障的结果。 Geoffrey Biggs 等人指出，OMG 的标准化组织将把 FTA 和 FMEA 纳入安全和可靠性分析配置文件。但相关论文中的图将故障模型指代为故障树模型，未表达混合故障链。 ### 2.2 对相关工作的思考 基于模型的安全分析（MBSA）是一个活跃的研究领域，但目前并不侧重于改进对故障行为的解释。为了提高安全分析结果的内聚性，我们提出将故障模型和系统模型集成到一个图中，并采用活动模型来更好地理解故障模型的图形表示。通过将故障的发生、检测、响应以及系统设计以活动模型的形式在一个图中展示，可以更轻松地理解系统在故障时的行为。 ## 3 描述故障模型的图结构 ### 3.1 符号要求 为了提高符号的解释能力，我们定义了以下要求： - **提高安全分析结果在一个图中的内聚性**：安全分析工件应将内容聚合到一个图中，以便直观理解元素之间的关联。 - **采用活动模型可视化混合故障链**：故障模型应采用活动模型，以提高与系统模型结构的兼容性。虽然故障树模型适用于推导最小割集和计算故障率，但活动模型更适合可视化故障和安全机制的行为。 - **表达水平传播**：水平传播是指故障从一个父元素中的子元素传播到另一个子元素。符号应提供一个表达组件之间故障传播的水平传播模型。故障树模型适合表示故障的层次结构，但不方便展示组件之间的故障传播，因此开发者有时会为了简洁而省略 FT 图中的水平传播。我们认为当前复杂安全关键设备的审查人员需要理解水平传播，可视化水平传播将提高图的可理解性。 ### 3.2 符号的元模型 我们根据上述要求设计了系统模型和故障模型的元模型： - **系统模型的表达**：我们采用 SysML 来表示系统模型，以增加安全分析工件与基于模型的系统工程（MBSE）的亲和力。系统模型包括项目、元素和功能，还包括检测故障的措施和减轻故障影响的措施。 - **故障模型的表达**：故障模型包括故障模式、故障检测、系统响应和故障影响，用于描述故障的行为。 - **系统模型和故障模型的关系**：元模型提供了功能和故障模式之间的关系，以及故障检测与故障检测机制、系统响应与故障处理机制之间的关系。 - **故障的传播**：我们通过具有“≪causes ≫”构造型的链接来表示故障之间的因果关系。 ## 4 安全分析结果导入 SysML 图 ### 4.1 不同工件元素之间的对应关系 我们假设不同安全分析结果和系统设计的组件之间存在对应关系，分析师必须提供每个工件中这些组件之间的关系。FTA 中的事件和 FMEA 中的故障模式可能是一对多的对应关系，因为 FTA 分析结果的粒度可能比 FMEA 结果更粗，抽象级别更高。具体对应关系如下表所示： | SysML(IBD) | FMEA | FTA | | --- | --- | --- | | 部件属性或块 | 元素 | (无) | | 部件属性 | 功能 | (无) | | 故障模式 | 事件 | (无) | | 故障影响 | 事件 | (无) | | 检测 | 事件（缺乏检测） | 部件属性 | | 检测措施 | (无) | (无) | | 系统响应 | 事件（缺乏系统响应） | 部件属性 | | 减轻措施 | (无) | (无) | ### 4.2 FTA 结果的假设和故障树模型的转换 冗余系统的 FT 图具有相似的形状，系统的故障行为通过用与门连接多个冗余元素的故障来表示。但其他检测机制，如完整性检查，通常未在图中表示。因此，我们定义了以下规则来表示 FT 图中故障检测和故障处理机制（系统响应）的行为，并将其与 FMEA 和 SysML 组件关联： - FT 图由故障事件和逻辑门组成。在我们的方法中，只有当故障事件与安全机制的故障（缺乏保护）同时发生时，FT 图才违反安全目标。 - FT 图通过缺乏故障检测和缺乏系统响应（缺乏故障处理）的逻辑和（或门）来表示安全机制故障（缺乏保护）。 - FT 图中的事件具有根据事件类型添加前缀的 ID，我们通过前缀识别事件类型。 - 如果 FTA、FMEA 和 SysML 中元素之间的关系可从可追溯性管理工具获取，我们可以利用这些数据构建模型中的关系。如果关系不可用，分析师必须在导入安全分析结果后，以数据形式或通过 SysML 建模工具的图形操作提供这些关系。 我们的方法采用活动模型作为故障模型，但 FT 图基于故障树模型，因此在上述假设下，将故障树模型转换为活动模型。 ## 5 案例研究 ### 5.1 系统分析与数据导出 我们对一个简单的控制系统进行了安全分析，并使用本文描述的方法进行可视化。由于该方法假设安全分析将基于现有的 SysML 模型进行，我们创建了一个普通的内部块图（IBD），并将 ID 作为标记值附加到 IBD 组件上，以表示 FTA/FMEA 组件与 SysML 组件之间的关系。 系统设计基于 AIAG/VDA FMEA 手册中的 FMEA - MSR 进行分析。分析完成后，我们从 FMEA 表中导出了监测、系统响应、功能、故障模式、故障影响及其关系作为 CSV 文件。同时，我们在严格限制下进行了 FTA，并为事件和逻辑门分配了 ID，以管理与 SysML 和 FMEA 结果的关系，FTA 结果也导出为 CSV 文件。 ### 5.2 组件发生点的明确 在 FMEA - MSR 的风险分析和优化步骤中，需要分别为以下组件明确发生点： - 诊断监测 - 系统响应 - 系统响应后的最严重故障影响 FMEA - MSR 中其他事件（元素、功能和故障模式）的发生点在结构分析、功能分析和故障分析的每个层次结构步骤中指定。由于监测、系统响应和故障影响可能发生在与功能和故障模式不同的组件中，分析师或设计师需要明确指出发生点。具体组件及发生点如下表所示： | Diag ID | 诊断监测动作 | SysResp ID | 系统响应 | FE ID | 系统响应后的最严重故障影响 | | --- | --- | --- | --- | --- | --- | | DET - 1 | 比较器 | STR - 1 | 关闭阀门 | FEF - 1 | 阀门关闭 | | DET - 2 | 计算的完整性检查 | STR - 1 | 关闭阀门 | FEF - 1 | 阀门关闭 | | DET - 3 | 执行器的完整性检查 | STR - 1 | 关闭阀门 | FEF - 1 | 阀门关闭 | ### 5.3 数据导入与混合故障链展示 将 FTA 和 FMEA 数据（CSV 文件）导入 SysML 模型后，审查人员将混合故障链（故障影响的传播）放置在 IBD 上。由于在一个图中显示系统中的许多混合故障链不切实际，审查人员绘制多个图，每个图包含与要审查的故障模式对应的混合故障链。审查人员在图中指定要审查的功能和故障模式，工具递归提取由于故障模式的影响而发生的故障影响，并将其绘制在 IBD 上。 ## 6 可视化的效果 ### 6.1 发现分析结果中的错误 通过可视化方法，我们可以更容易地发现分析结果中的错误。例如，在一个故意错误的分析中，“阀门开度请求固定为零”是“阀门开度计算”功能的一个故障模式。分析师错误地确定该故障由“检测偏差”检测到，但实际上该故障不能由“执行器的完整性检查”检测到，因为它会在发送到“执行器的完整性检查”的阀门开度请求中导致相同的偏差。如果审查人员在 FMEA 表中看到“检测偏差”，可能会错误地认为分析结果正确。但如果查看可视化图，就可以理解“完整性检查”如何在图中比较阀门开度请求和传感器检测到的阀门开度，从而更容易发现错误。 ### 6.2 不同详细程度的故障传播展示 不同详细程度的安全分析结果展示了不同的故障传播情况。简化的 FMEA - MSR 结果省略了水平传播，只绘制了故障模式“无驱动电流”与检测“检测与参考的偏差”之间的直接关系，审查人员可以在一个图中看到故障模式和安全机制之间的关系，便于发现两者之间的不匹配。而详细的结果使用 FTA 结果的详细信息展示了更详细的水平传播关系，审查人员可以从图中理解故障的行为，但这种详细的分析结果比普通工件更复杂，可能不切实际。我们的方法可以可视化安全分析结果的简化或省略程度，便于分析师或审查人员判断该程度的适用性。 ## 7 车联网安全设计模式——SECREDAS 方法 ### 7.1 车联网安全背景 在过去几年中，自动驾驶成为众多技术参与者的目标。自动驾驶需要新的先进机制来提供安全功能，而增加的通信使自动驾驶车辆更容易受到攻击。安全在一些领域（如 IT 行业）已经成熟，现在正扩展到汽车行业。为了避免重复劳动，可以评估和调整现有的安全方法和工具，使其适用于其他领域，如汽车行业。 ### 7.2 SECREDAS 项目方法 在欧洲 H2020 ECSEL 项目 SECREDAS 中，对现有的方法、工具、协议、最佳实践等进行分析、组合和改进，使其适用于车联网领域。为了提供模块化和可重用的设计，将解决方案收集为设计模式。SECREDAS 设计模式描述了解决与自动化系统相关的安全、安全和隐私问题的解决方案模板。 ### 7.3 设计模式的分组和分类 设计模式的分组和分类对于方便选择过程非常重要，因为选择是一项具有挑战性的任务，而薄弱的分类方案可能导致安全模式（设计模式的一个子组）应用稀疏。SECREDAS 安全模式基于现有的技术（即通用技术元素），通过参考通用架构描述如何以及在何处将其应用于车联网环境。这使开发人员能够轻松找到常见问题的解决方案，并通过提供具体、可靠的解决方案减少开发工作量。整个方法和分类方案通过一个示例安全模式进行说明。 综上所述，通过将故障模型和系统模型集成可视化的方法，以及车联网安全设计模式的研究，有助于提高安全分析的效果和车联网系统的安全性。未来，我们还需要进一步研究该方法在大型系统中的有效性、对整个安全分析工作的改进以及安全分析工件之间对应关系的完整性等问题。 ## 8 未来工作展望 ### 8.1 大规模系统中的实用性研究 当前的方法在小规模案例研究中，故障传播简单，可视化具有实用性。但在大规模系统中，故障数量众多，整个故障模型由多个图表示，需要进一步研究该模型在这种情况下的实用性。可以考虑以下步骤进行研究： 1. 选择具有代表性的大规模系统作为研究对象。 2. 应用现有的可视化方法对该系统进行安全分析和故障模型可视化。 3. 评估可视化过程中的复杂度、效率以及审查人员对故障传播的理解程度。 4. 根据评估结果，提出改进措施或优化方法。 ### 8.2 对整个安全分析工作的改进 目前主要关注通过提高 FTA 和 FMEA 安全分析工件的可见性来改进审查活动。但本文描述的符号和功能可能对安全分析的其他活动也有帮助。可以从以下方面进行研究： 1. 分析传统安全分析工作的流程和痛点。 2. 研究如何在 SysML 建模工具中使用故障模型，以简化安全分析的各个环节。 3. 对比使用新方法和传统方法在安全分析工作中的效率、准确性和全面性。 4. 根据对比结果，总结新方法对整个安全分析工作的改进点和适用场景。 ### 8.3 安全分析工件对应关系的完整性 在对 FTA 和 FMEA 结果进行建模时，由于两者目的和意图不同，组件在开发过程中不一致且不同步。虽然开始时关联和可视化了现有安全分析方法的结果，但为了更好地结合多种安全分析方法进行建模，需要研究安全分析方法之间的协作方法。具体步骤如下： 1. 分析 FTA 和 FMEA 方法的特点、目的和适用场景。 2. 找出两种方法组件之间不一致和不同步的原因和表现形式。 3. 探索建立一种统一的框架或规则，使两种方法的组件能够更好地对应和协作。 4. 通过实际案例验证协作方法的有效性和可行性。 ## 9 总结 本文提出了一种使用活动模型可视化故障传播的方法，将 FTA 和 FMEA 的结果与 SysML 的功能块图集成在一个图中。通过对该方法效果的分析，发现它有助于理解安全分析结果中的缺陷和遗漏。 可视化传统安全分析结果中故障的行为，并通过活动模型表达故障模型，对改进安全分析具有显著效果。同时，SECREDAS 方法为车联网的安全设计提供了模块化和可重用的解决方案，通过设计模式的分组和分类，方便开发人员选择合适的安全措施，减少开发工作量。 以下是整个安全分析和可视化过程的 mermaid 流程图： ```mermaid graph LR classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px; classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px; A([开始]):::startend --> B(现有安全分析方法):::process B --> C{是否存在局限性}:::decision C -->|是| D(提出改进方法):::process D --> E(设计元模型):::process E --> F(导入安全分析结果):::process F --> G(案例研究):::process G --> H(可视化效果分析):::process H --> I(发现分析结果错误):::process H --> J(展示不同详细程度故障传播):::process I --> K(改进安全分析):::process J --> K K --> L(车联网安全设计模式研究):::process L --> M(SECREDAS 方法):::process M --> N(设计模式分组分类):::process N --> O([结束]):::startend C -->|否| O ``` 整个研究过程涵盖了安全分析方法的改进、故障模型的可视化以及车联网安全设计模式的探索，为提高系统安全性提供了有效的方法和思路。未来的研究将进一步完善这些方法，使其在更复杂的系统和场景中发挥更大的作用。