在汽车制造商和一级供应商避免责任的背景下，公认的技术规则作为法律要求的标准具有重要的实际意义。道路车辆电子控制单元的安全性目前主要通过 ISO 26262 的要求和流程来保障。特别是随着道路交通自动化程度的不断提高以及现代车辆随之而来的复杂性，一个问题浮出水面：功能安全所追求的目标是否足以打造安全的车辆系统。目前有多项标准正在制定中。ISO 26262 的第二版涵盖了安全功能的正确性（功能安全）。安全功能的完整性 —— 也称为使用安全性，在 ISO WD/PAS 21448 标准草案中进行了描述。安全功能的不妥协性（网络安全）例如在 SAE J 3061 文档中有所体现。这些不同的标准目前相互孤立，且在相互关联上存在不一致之处。本文展示了如何基于一个共同的元模型，将复杂电子车辆系统工程中这些迄今为止相互孤立的子任务进行整合。

本文的主要重点在于为道路车辆电子控制单元的整体安全导向开发制定一个过程框架。这使得三个已确定且迄今为止并行推进的标准化项目能够相互交织。为此，要将现有的异构且方向各异的开发活动（功能安全、网络安全和使用安全）整合到一个正式的过程模型中。该过程模型基于以下大致的阶段划分：

· 概念阶段

· 规范活动（下游）

· 特性保障（上游）

· 维护和运营

2.1 安全相关电子控制系统的构思

安全相关电子控制系统的构思始于在实际开发之前的一个阶段对使用安全设计方面的考量。如果在这个层面上的一个粗略概念被认为总体上适合预期用途，那么实际的系统开发就会开始，同时考虑功能安全和网络安全。图 1 展示了系统开发概念阶段中设计活动之间的关系。可以清楚地看到，虽然各个开发流程仍然具有需要按顺序处理的设计方面，但在系统开发的特定点上，需要对设计方面进行同步，以便它们能够相互协调地开发，并最终 “一致地” 组合成一个整体系统。

图 1：系统开发概念阶段中设计方面之间的关系

2.1.1 使用安全设计方面

开发安全的驾驶员辅助系统的起点是确定功能和系统规范（运行设计域，ODD）。ODD 涉及自动化系统应运行的条件。此类条件的示例包括道路类型、地理位置、清晰的车道标记、天气条件、速度范围、照明条件以及其他由制造商定义的系统性能标准或限制。例如，对于一个不能识别横向交通的车辆横向控制辅助系统，车辆制造商可以为高速公路类道路（无横向交通）设置一个 ODD，并设计辅助系统，仅在可能的情况下允许车辆激活自动化控制系统。通过这种方式，确保 ODD 始终得到满足。
安全辅助系统的构思先于我们从 2011 年开始所了解的 ISO 26262 中的实际系统开发。在此，会对辅助系统概念进行早期的 “预验证”，然后实施被证明合适的辅助系统概念。其目标是实现 “稳健的” 自动化功能。使用以下设计参数：

· 将责任归还给驾驶员

· 系统的技术改进（传感器、执行器、控制算法）

· ODD 的限制

· 对用户可预见误用带来的潜在危险的评估

2.1.2 功能安全设计方面

汽车功能安全电子控制系统开发的起点是所谓的项目定义。这是与在使用安全框架内开发的 ODD 的接触点，或者说项目定义是与网络安全的功能定义并行制定的。项目定义会纳入危害识别和风险评估（GuR，即危害分析和风险评估，HARA）中。基于对潜在危险场景的系统识别（例如通过危害与可操作性研究，HAZOP），对相关风险进行评估（参见 ISO 26262-3）。结果是，为每种危险确定完整性等级（汽车安全完整性等级，ASIL），这些等级需要在安全相关电子控制系统的开发中实施，以避免随机失效和系统性错误。为了给从业人员提供实际支持，目前已有关于进一步明确伤害严重程度、频率 / 持续时间和驾驶员可控性等参数的建议。

对于在 GuR 中识别出的每个危害事件，都必须设定一个安全目标。安全目标是待开发控制系统的最高安全需求。它们产生了必要的功能安全需求，以避免每个危险事件的不可接受风险。安全目标尚未从技术角度表达。如果可以通过切换到一个或多个安全状态来实现安全目标，则必须指定相应的安全状态。

为了实现安全目标，功能安全概念包含安全措施，包括在安全需求中详细描述并随后在控制系统的架构元素中实施的安全机制（英文：Safety Measures）。功能安全概念描述了故障检测和避免、向安全状态的过渡、容错机制（在这种机制下，故障不会直接导致违反安全目标，并且控制系统仍然保持在安全状态，可能会有性能限制、降级）、故障检测和向驾驶员发出警告，以将风险存在的持续时间（暴露参数）限制在可接受的水平（例如通过故障指示器和警告灯），以及在必要时从多个由不同功能同时生成的控制请求中选择最合适的控制请求的仲裁逻辑。

2.1.3 网络安全设计方面

威胁分析和风险评估（TARA）识别威胁并评估已识别威胁的风险和残余风险。TARA 的结果指导所有后续的网络安全活动。通过识别潜在威胁和评估已识别的威胁风险，可以将系统开发中的宝贵资源（特别是人员）导向具有最高风险潜力的威胁。威胁分析和风险评估包括两个方面：

· 威胁分析（威胁识别）—— 确定系统或组织（利益相关者）的潜在威胁。

· 风险评估（威胁分类）—— 对特定已识别威胁相关的风险进行评估和分类。

网络安全目标是最高的网络安全需求，包括为待开发控制系统实现网络安全的目标。网络安全目标是根据 TARA 的结果确定的。一旦识别出具有最高风险潜力的威胁，就为每个具有最高风险潜力的威胁确定网络安全目标。网络安全目标可以针对需要避免的内容，或者与潜在威胁相反的内容来指定。例如，如果潜在威胁是 “恶意干预车辆横向控制”，则针对该潜在威胁的网络安全目标可以表述为 “避免或防止恶意干预车辆横向控制”。一个潜在威胁可能有多个网络安全目标，多个潜在威胁可能有相同的网络安全目标。网络安全目标和相关风险用于确定实现系统网络安全的总体策略。

网络安全概念描述了为所考虑的控制系统维护网络安全的总体策略。此时，网络安全概念可能包含在 TARA 期间确定的总体网络安全目标、与每个网络安全目标相关的风险以及实现网络安全目标的潜在高层策略。实现网络安全目标的策略可能取决于与网络安全目标相关的威胁的潜在风险潜力。在接下来的开发阶段，即系统级产品开发中，网络安全概念将被分解为具体的技术措施并加以细化。

2.2 安全相关电子控制系统的规范

在概念阶段之后，将细化大致的要求，并将其分解为技术解决方案概念。结果是形成所考虑控制系统的硬件和软件的详细规范。

2.2.1 使用安全设计方面

使用安全设计活动不会随着概念阶段的结束而结束。如果在系统开发的后续阶段从使用安全的角度提出未解决的问题，则会相应地调整概念阶段的成果。从这个意义上说，从使用安全考虑得出的要求会在迭代方法中逐步细化或修正。

2.2.2 功能安全设计方面

技术安全需求应根据概念阶段确定的功能安全概念以及初步的架构假设来制定。这里需要考虑例如外部接口，如通信和用户接口、任何限制，如环境条件或功能限制以及系统配置要求。安全机制扮演着特殊的角色。这包括指定控制系统对影响安全目标实现的刺激的反应。这包括故障和相关的刺激组合，同时考虑不同的操作模式和系统状态。
技术安全需求应在技术安全概念的框架内分配给架构元素。在此，技术安全需求被完整、可追溯地分解到硬件和软件。此外，还记录了同步硬件和软件开发所需的要求（所谓的硬件 - 软件接口，HSI）。

2.2.3 网络安全设计方面

在概念阶段定义了网络安全概念。在规范阶段，基于在系统级进行的漏洞分析对网络安全概念进行分析，以识别在外部未授权访问方面最易受攻击的系统功能。这种分析以及对具有高网络安全优先级的功能和数据的确定，用于创建技术网络安全概念。网络安全概念定义了在系统级为保护这些高优先级功能和数据而在网络安全设计方面做出的具体技术决策。示例包括：

· 某些功能的隔离。例如，特定功能的计算是否应在单独的电路中进行？

· 对策的使用（例如加密、解密）。

· 不在系统中存储当前 GPS 位置的副本。

· 深度防御策略（英文：“Defense in depth”）。

2.3 安全相关电子控制系统的特性保障

一般来说，测试应在开发生命周期的不同时间点由不同的人员进行。原则上，测试由具备专业资质的人员进行时效果最佳。这些人员应独立于开发团队，且不得参与待测试系统的构思、构建和运行。原则上，必须采用可重复的测试方法，该方法可在每次系统更改时重新使用。不同设计方面的具体测试方法差异很大。

所有三个设计方面都需要独立评估。这应该以伴随开发的评估形式进行，如图 2 所示。在此过程中，对阶段性工作成果（工作产品）进行评估，并在过程协议中记录未解决的问题。未解决的问题会在开发过程中重新审议，并在开发取得进展时予以解决。在系统开发结束时未解决的 “未解决问题” 将以应用条件的形式传递给生命周期的下一个集成阶段。图 3 示例性地展示了对于汽车安全相关电子控制系统的审批决策，需要对所有三个设计方面进行综合的证据收集。

图 2：伴随开发的评估方法模型

图 3：安全档案（ISO 26262）与网络安全档案（SAE J 3061）之间的关系

2.3.1 使用安全设计方面

在使用安全的特性保障框架内，必须证明：a. 已知 / 不安全的系统状态得到控制（验证）；b. 未知 / 不安全的系统状态在实际应用中不会以足够的置信度发生。这在验证和确认的框架内进行：

SOTIF 验证：必须对系统和组件（传感器、算法和执行器）进行验证，以证明它们在已知的不安全场景（从早期分析中得出）中按预期运行，并且它们得到了充分的测试覆盖。在此使用有针对性的基于需求的测试、车辆集成测试和故障注入测试。

SOTIF 确认：必须对系统和组件（传感器、决策算法和执行器）进行确认，以证明它们在实际应用中不会造成不可接受的风险。

2.3.2 功能安全设计方面

为了证明功能安全，使用了各种测试方法或其组合。系统被故意推向极限，以证明它在所有环境中都能按照规范运行，或者指定的安全机制能正确发挥作用。其中包括以下测试方法：

故障注入测试使用特殊手段将故障注入系统。这可以通过特殊的测试接口或专门准备的通信设备在系统内部进行。该方法常被用于提高技术安全需求的测试覆盖率，因为在正常运行中，安全机制通常不会被调用。

压力测试用于检查系统在高运行负载或高环境要求下的正常运行情况。示例包括在系统高负载下的测试，或具有极端用户输入或来自其他系统的请求的测试，以及在极端温度、湿度或机械冲击下的测试。

2.3.3 网络安全设计方面

对于网络安全，有多种测试方法来证明安全特性：

基于需求的测试证明技术网络安全概念的所有要求都得到满足和正确实施。

针对威胁的对策测试：测试用例来自攻击树或威胁矩阵。这些测试确保对策能有效应对所考虑的威胁。

一般漏洞测试：这种测试策略侧重于使用工具或已发布的指南来发现潜在漏洞。

渗透测试：渗透测试确定对 IT 网络、单个 IT 系统或（网络）应用程序的攻击潜力。为此，评估对信息网络或单个 IT 系统进行故意攻击的成功可能性，并据此推导出必要的补充安全措施，或者检查已实施安全措施的有效性。

2.4 安全相关电子控制系统的生产和运营

必须有一个明确定义的流程来处理在安全相关电子控制系统中识别到的事件。有一些经过验证的程序：来自其他行业。

事件报告：关于观察到的网络安全事件的报告是设计有效对策的基础。这些报告必须详细且及时。

对报告事件的评估：必须对收到的报告就其说服力及其对所考虑系统的潜在影响进行评估。

原因分析：在组织内不同领域专家的参与下，分析事件发生的原因。在此过程中，收集和保存关于事件的证据，并记录从中得出的结论。

对策规划，包括以下三个基本步骤：

· 遏制事件，防止其进一步扩散。

· 纠正事件原因，识别并专门弥补现有漏洞。

· 恢复系统，使受影响的系统恢复到可运行状态。

监控对策的实施，确保在内容和时间上得到适当解决。
事件的后续处理，包括对所采取措施的最终文档记录，以及从结构上推导出未来系统技术和组织方面的改进（经验教训）。

2.4.1 使用安全设计方面

现场数据在使用安全设计中也发挥着重要作用。在 SOTIF 过程中，这涉及以下三个方面：

· 利用现场经验细化危害分析。可以从现场观察中分析事故和未遂事故的数据。从中可以推导出危险的触发事件（“触发事件”）。通过这种方式，现场数据支持 SOTIF 全面考虑应有功能安全性的目标。未知 / 不安全的系统状态会及早显现（它们变得已知 / 不安全），然后可以进行结构化的危险控制。

· 利用现场数据为 SOTIF 验证的测试用例进行结构化推导。这涉及证明对已知 / 不安全系统状态的完整和正确控制。

· 规划确认，涉及证明未知 / 不安全的系统状态也能以所需的置信度得到控制。在此，根据类似系统的现场经验，定义测试驾驶的目标值。

2.4.2 功能安全设计方面

产品安全的判例法（特别是参见 [2]）要求汽车电子控制系统制造商采取组织措施来履行其产品观察义务。从法律角度来看，产品观察义务的结果使制造商能够建立有效的危险控制（通过控制已识别危险的措施）。为此，制造商必须建立针对与其投入使用的安全相关电子控制系统有关的功能安全事件的现场监控程序。这对制造商有以下好处：

现场数据及其结构化分析有助于发现和找到功能安全的潜在问题。基于此，启动处理这些问题的行动。

现场数据提供了经验证据，可用于安全相关的论证（所谓的 “使用中验证” 论证，参见 ISO 26262-8 第 14 节）。

2.4.3 网络安全设计方面

特别是对于网络安全，需要明确定义的流程以及通信路径，通过这些路径可以报告与安全相关电子控制装置网络安全有关的事件。这一点至关重要，因为网络安全的威胁格局在不断发展（例如攻击者可用的资源），在开发时无法完全预见。网络安全相关事件例如可以由驾驶员、监管机构（联邦机动车运输管理局、联邦信息安全办公室，BSI）、媒体或制造商报告。对于上述所有群体，都应该清晰、简单地说明如何向制造商报告事件。随后是对已识别事件的结构化处理（见上文）。

所提出的方法为确保日益复杂的道路交通自动化功能做出了贡献。按照 “按需而为 —— 尽可能少” 的原则，驾驶功能必须得到适当的保障。整体的保障过程体系为更高级自动化和联网控制单元的有效市场引入做出了贡献。通过统一建模，可以揭示不同设计方面之间的不一致之处。可以明确设计任务处理不完整的地方，或者可以提升系统开发各个子任务之间的协同效应。