内容提要：本连载学习课堂分为三章，此为第四章，为了解决复杂的 ADS 系统中的安全分析问题，详细介绍了三种技术：MBSE、CBD以及仿真和协同仿真技术。

连载学习课堂：

ADAS（高级驾驶辅助系统）是ADS（自动驾驶系统）这个大概念的一部分。基于现有 ADAS 的高度连接和联网的信息物理系统，可以实现比较先进的 ADS 功能。

自动化需要信息与其环境的交互，这些交互增加了系统的复杂性。为了确定预期的系统行为，必须知道所有可能的交互所产生的作用，以便识别 ADS 的所有失效，这些失效可能会通过系统边界传递，导致其他系统失效。隐形连接能够影响非期望的系统运行状态，使其不能被识别为失效模式。

在复杂的汽车系统中，功能安全是降低失效引起的安全关键风险的重要课题。

本连载分为三章，重点讨论以下几个方面：

第一章：ADS 所面临的普遍问题和挑战

第二章：ADS 在功能安全方面所面临的挑战

第三章：在功能安全的概念阶段，如何对 ADS 的具体项目进行功能抽象？（包含：相关项定义、HARA、ASIL、安全目标和 FSC 五个详细步骤）

第四章：解决 ADS 系统中的复杂性的安全分析技术，详细介绍了三种技术：MBSE、CBD以及仿真和协同仿真技术

ADS 安全关键系统中存在的复杂性是我们必须要考虑到的问题，通过故障识别和故障环节技术可以检测和缓解复杂性带来的负面影响。如今的汽车电子系统开发中，已经有了成熟的安全分析方法和技术（如用于确定 ASIL 等级的HARA、FMEA和FTA等安全分析技术）。考虑到 ADS 的复杂性，对现有的这些技术需要进一步改进和发展，以便在系统工程中实际应用。本文将为大家介绍三种方法，如下：

1. Formal/semiformalspecifications by Model-Based SystemsEngineering

基于模型的系统工程的正式/半正式规格

2. Formalverification by Contract-BasedDesign

通过基于协议的设计进行正式核查

3. Simulation and Co-Simulation

仿真和协同仿真

01 基于模型的系统工程（MBSE）

MBSE 的定义为：”基于模型的系统工程(MBSE)应用系统建模作为系统工程过程的部分…支持开发系统的分析、规格说明、设计、和验证。“

MBSE 方法是一种半正式的方法，支持工程师在规范阶段对系统进行分析，并将现实还原为抽象的模型表示。定义特定级别的需求，阐述系统的虚拟解决方案，并按级别划分为系统嵌系统、系统、子系统和组件等具有代表性的组件。较低级别的模型提供了有关实现的更多具体细节。在建模阶段，需要将预期和非预期的功能（=故障行为）分开，这个需求由系统的特定功能属性和安全相关属性来表示。

ISO 26262 第6部分强烈推荐将基于模型的工程方法用于 ASIL C/D 级的软件开发，对于这种软件密集型系统的系统级，应多使用这种方法。MBSE的主要标准化工作组是对象管理组织（OMG），该组织是一个国际性的技术标准联盟，其特点是开放会员制和非营利性。OMG任务团队是专门为各种技术和行业制定企业集成标准的部门。

系统级有各种标准化的通用建模语言（如SysML、MARTE或EAST ADL）。这些建模语言已经由学术界、研究界和工业界通过许多欧盟研究计划进行了阐述、改进、应用和评估。如何通过使用不同的建模元素对系统进行建模，MBSE提供了许多可能性，但对于实际应用来说，如何将元素的数量减少到一个子集并能为工程师提供指导和建模约束才是需要的。

基于模型的系统工程方法是指实现全部或部分系统工程过程，并产生系统模型作为其主要工件的方法。系统模型为规范系统的预期行为提供了基础，并能用于错误模型的识别和推导。误差模型主要用于处理故障在不同级别的传播，包括从单一组件到车辆层面的危险。误差模型的应用可以支持不同的安全分析方法（如FTA或FMEA）。安全分析的输出按安全要求确定安全措施，通过安全概念中的检测、预防、降级或警告行动来降低潜在故障。SAE 上有一篇技术论文中描述了一种使用SysML的汽车领域的可能方法。除此之外，还有研究提出了一个概念元模型的配置文件，以涵盖系统安全的相关方面，并基于SysML描述了安全原型(safety steriotypes)（如Hazard、Harm、HarmContext...）。该配置文件对安全标准和安全分析技术中常见的安全概念进行了建模。SysML的这个配置文件可以用来直接在与系统设计相同的模型中对系统的安全相关信息建模。此外，该配置文件还支持安全工程师和系统开发人员之间的交流，能加强双方对系统易发生的风险和系统抗风险功能的理解。

使用 SysML 的 MBSE 方法可以解决以下问题：

• 提供一种通用的、标准化的描述语言，以改善系统工程师和其他工程师之间的沟通。

• 支持对系统模型进行不同类型的检查，以验证规范规则（如系统设计，以达到正确性和完整性）。

• 通过利用系统模型向另一个描述模型的转换和其他相关方面的扩展(如错误建模)，改进系统建模工件的处理。

• 提供了相关安全工件的可追溯性，可以对特定安全问题进行变更管理和影响分析。MBSE的另一个好处是可以通过不同类型的需求定义、安全设计和安全论证模式来重用现有的最佳实践。

02 通过基于协议的设计（CBD）进行正式验证

CBD 是一种正式的方法，它通过所谓的 "保证"来指定一个能够为其环境提供什么（如服务、数据、信息、能源）的组件/系统，该组件/系统通过 "假设"来指定其环境需要什么（如服务、数据、信息、能源）。"保证"可以是输出接口/通道的性能和限制，只有确认了所有的假设时，”保证“才有效。

假设是指系统或组件的输入接口或通道的环境约束。软件密集型系统及其组件的耦合很难处理所有可能影响系统安全的潜在隐性环节。CBD 能够保证系统模型只参与定义的系统状态。通过采用CBD，只有指定的系统状态才可以参与，并且只允许通过定义的、众所周知的通道进行系统的耦合和通信。

可以通过提供一些模式来假设和保证协议，这些模式是根据时间、安全、安保等不同的特性来定义的，或者是可以自动检查的形式化的模式。所有系统模式的总和确定了所有可能的协议。

CBD 将系统组件描述为黑盒，并通过与其他系统组件的接口定义其行为。所有种类的可依赖性方面例如：时间(如实时协议)、安全(如ASIL x或反应时间)、安保(如认证证书)，都以协议的形式制定，并可通过这种方式管理。

不同级别的协议定义如下，例如：

不同SW模块之间的协议

SW模块和HW组件之间的协议

不同硬件组件之间的协议

硬件组件和子系统之间的协议

CBD 能够协调组件及其提供的服务的互操作性和边界限制，也能够协调不同级别组织上的数据。通过模块化，可以降低系统设计时组件的复杂性。每个组件都由有限的属性和约束目录(limited catalogue)来描述，这些属性和约束建立了安全性。如果所有的协议都没有任何矛盾，通过一致性测试，就能很快分辨出协议之间的冲突地方。

令人满意的测试能检查出组件的实现是否与协议一致。现在终于有了足够的工具支持（例如用于模型检查）。一些出版文献，如 ISO 26262 讨论了在工程和安全标准的要求下使用协议的问题。

安全要求可以通过对项目及其要素的协议进行表征，通过提供对其环境的明确要求作为假设，保证构成安全要求。因此，通过明确声明每个元素/项目对环境的期望，协议丰富了一个项目/元素的安全规范，确保了能满足安全要求。此外，他们还表明，可以通过验证协议的支配属性来确保安全要求的一致性和完整性。

协议给认证提供了支持，因为协议提供了形式化的论据，可以在所有设计阶段评估和保证设计的质量。此外，B协议可以在任何设计过程中使用。协议为所有方法提供了 "正交"支持，并可作为支持技术，在任一流程中用于组成和设计完善。

03仿真和协同仿真

仿真方法通常用于汽车工业，在汽车工业中，引入了来自不同合作学科的复杂嵌入式系统来实现高度相互依赖的功能。在这种情况下，仿真方法可以让工程师在没有整个系统原型的情况下预测复杂嵌入式系统的行为。像自动驾驶系统这样的复杂系统，由于其多学科的特性，需要一个考虑系统内部行为交互的数据结构。仿真和MBSE方法的结合支持了建模活动，提高了设计过程中仿真活动的集成度。这种结合支持解决产品整体行为（多物理、局部和全局行为）的系统呈现，从而能考虑多个系统级别。

ISO 26262 标准 推荐在不同的系统集成度上验证仿真方法（例如ISO 26262第3部分用于验证HARA的可控性参数）。对于系统设计验证，ISO 26262第4部分表3建议将仿真作为一种高度推荐的方法和技术，例如 ASIL C/D 的故障注入和背靠背测试。

论文《System Level Modeling, Simulation and Verification Workflow for Safety-Critical Automotive Embedded Systems》中展示了一种基于模型的安全关键型嵌入式系统工作流程。文中的方法在安全关键系统的开发过程中主要包括三个方面，即系统建模、系统仿真和基于仿真的系统验证。通过使用软件过程工程元模型(SPEM)，以一致和无缝的方式定义工作流程，实现从初步概念到最终的系统验证报告的连续性。与ISO 26262给出的要求相一致，所演示的工作流程通过使用建模和仿真，可以在开发的早期阶段进行系统级的安全验证。

论文《Complex System Simulation Proposition of a MBSE Framework for Design-Analysis Integration》中提出了一种基于数据模型的软件框架，管理复杂的系统结构。该数据模型结构行为信息主要考虑了三种交互行为，即：组件仿真模型之间的交互行为、考虑多层次行为的交互行为（如使用组件仿真进行模块仿真）和领域行为之间的交互行为（如机械部件的热影响），在所谓的协同仿真环境中。这种方法可用于通过MBSE方法对规范进行早期验证，以提供足够的针对安全措施的早期验证反馈。

在自动驾驶的背景下，除了嵌入式系统行为外，还可以模拟不同的方面，如车辆与环境、其他车辆或系统的交互或车辆与驾驶员的交互，车辆子系统的交互，以动态证明系统和部件的指定行为。

04其他安全相关的话题

—信息安全对功能安全的影响

系统开发的主要目标之一是确保在所有操作条件下都可“无视不合理风险”。而通常根据是否考虑功能安全或信息安全，所谓的“无视不合理风险”具有不同的含义。

从功能安全角度来看，将系统（不包括人工环境系统）内部的环境风险降到最低是必要前提。然而这可能会导致系统技术故障，例如电动汽车的高压电池系统引起的火灾危险或 ADS 意外加速而引起的事故。

从信息安全角度看，系统在某一环境面临的潜在威胁可能是故意操纵造成的，所以必须将黑客攻击等恶意行为降到最低。

功能安全代表了系统对所有外界潜在危害的观察，而信息安全则是将车辆的内外部环境及其对车辆内部系统的影响进行比较。信息安全措施的采取旨在保护系统免遭非法使用和操纵（黑客、低成本备件等）的侵害。在汽车行业中，信息安全原则涉及车辆功能的开发以及车辆与周围环境（例如其他汽车）或物联网（例如云服务）方面的创新潜力。从这个角度来说，需要解决的首要难点是将功能安全与信息安全两者进行关联协调并避免相互冲突的影响。不同情境下非法车辆系统访问的目的包括：

操纵车辆及其组件，以及破坏或停用车辆功能—降低“某个服务有效性”（例如，对可能会损坏动力总成的电机扭矩极限进行更改）

通过更改功能属性来调试车辆—降低“功能完整性”（例如，芯片调试、操纵速度表或停用警告消息）

企图非法获取个人数据—降低个人数据的“完整性”（例如，用户的驾驶行为、对商店、饭店或酒店的喜好）

在汽车开发过程中，ISO 26262为功能安全生命周期问题的解决提供了指南。但是，仅仅出于信息安全考虑在汽车工程实践中还远远不够。在常见的抽象层次中，功能安全和信息安全之间存在许多相似之处，因此，将 ISO 26262 开发过程与信息安全问题交织在一起似乎对整个汽车开发非常有效。在信息安全中，定义某个安全项目后，需要对安全风险和危害进行分析，从而总结出相应安全措施以及安全目标。在系统设计、验证和确认之后，应进行联合评估，以对系统基于 ISO 26262 所达到的功能安全等级以及安全威胁进行评级。考虑到功能安全和信息安全两者之间的相似性，从信息安全主题方面扩展ISO 26262框架似乎是明智且必要的。

—ADS的责任

在未来的自动驾驶汽车中需要规定所有涉及到的人员和系统各自的责任，从而在事故中进行明确的责任认定划分。

法律中对不同的职责和责任进行了描述，如：

机动车保管人的责任：机动车保管人承担与机动车有关的所有操作风险均—ADS的故障不会改变机动车自动系统的操作责任。

驾驶员的责任：根据法律（民法）规定，在事故中，如无确定的证明，应认定为驾驶员的行为过错。在 ADS 发生故障的情况下，驾驶员可提供相关证明要求证明。

机动车责任保险：如果受损害的第三方向车主或驾驶员提出索赔，则由参保的保险公司承担—ADS的故障不会导致机动车保险重责任原则的任何变化。

产品制造商的责任：如果将有缺陷的产品推向市场，则原始设备制造商（OEM）应当对产品承担相应责任。原始设备制造商（OEM）必须提供证据证明产品没有缺陷并且不会造成损坏。同时必须认真指导并鼓励驾驶员根据所系统设置合理操作必要功能。需提供给驾驶员完整详细的操作说明将以保障系统设计的安全性。

基础设施的责任：未来高度自动化汽车功能的实现离不开精确的数据支持。这些数据会参考当地条件和具体时间进行记载。车辆基础设施应需要提供所有必要的信息，并对安全性和功能性负责。

此外，主观判断的作用也不容忽视。在复杂的驾驶条件下，驾驶员可能无法人为处理突发事件，以致面临“困境”。有时，甚至无法做到在不伤害任何人的情况下处理紧急情况。因此，在此类情况下作出能够将伤害降到最低的决定变得至关重要。对于人类而言，有时很难判断一个时间属于“瘟疫还是霍乱”，所以对于机器而言则更加困难。为解决这一难题，未来高度自动化的系统将需要某些算法来确定具体的风险。

因此，车辆中的“事件数据记录器”将成为记录撞车或事故相关信息的必要条件。在事故发生后，它会收集并分析来自这些设备的信息，以帮助确定发生了什么。这类似于在飞机上记录飞行过程中的所有关键数据的“黑匣子”。根据抽象水平和自动化程度，需要对标准化的定义和理解进行进一步研究，以便评估和分类。

—ADS功能验证

ADS功能的验证离不开系统的（涉及安全方面）测试方法。对于一个复杂的系统，测试方法必须将模拟和实际测试相结合，从而测试xiL（x在环）和在环方法中的模型/软件/处理器/硬件/车辆的不同集成水平。现阶段，V模型、耐久性测试、xiL测试、开环离线感知测试、“特洛伊木马”测试、分步实施测试、复杂测试等都是常用的驾驶功能验证方法。这些测试方法各自有不同的潜力和劣势，例如“特洛伊木马”测试主要针对功能测试，且不会对串行汽车产生危害。

尽管可以用测试来表征与安全相关的系统状态，ADS 还是存在无法执行安全确认策略的缺陷，因为故障机制只能由系统决定而不能通过功能进行触发。在自动驾驶情况下，车辆自身可能无法仅仅根据自身系统的反应来给出决策，所以还需要对其他道路使用者的行动和反应进行预判，但这样依旧无法确保百分百精确。也就说，根据道路使用者的反应模型来进行判断是远远不够的。系统并非在所有事件中都做出发应，决策的精度取决于事件发生的时间，并且仅在简单的行车情况下才能准确判断。第一阶段的自动化功能开发主要集中在技术的突破，但是，自动化功能对于汽车安全性息息相关，所以如果没有对这一功能的设计采取适当的验证步骤，就无法在消费市场推出无人驾驶车辆。

ISO 26262 标准旨在成为汽车功能安全方面的一个标准，用于处理E/E安全相关系统（包括这些系统的相互作用）的故障行为所造成的危害。该标准不涉及动力总成控制或任何类型的等 ADAS 的 E/E 系统标称性能。因此，ISO 标准也可用于任何级别的自动驾驶。但是，由于必须处理高度的网络功能，这类系统的复杂性远远高于今天的工程师所习惯处理的系统。为了充分实现自动驾驶系统的功能，我们必须全面考虑。

在本系列连载中，讨论了以下几个问题：

高度互连的功能日益复杂和系统属性（如可用性、可靠性、安全性和保障性）的影响之间必须加以协调。

对自动驾驶系统功能而言，ISO 26262的概念阶段愈加重要，因为自动驾驶系统的开发超越了目前最先进的工程方法和技术。特别是以下几个方面：驾驶员在HARA中的影响方面，安全目标的定义和自动驾驶系统特定级别的相应属性（如安全状态），以及功能安全概念从 fail-safe 到 fail-operational 策略的变化。

如今，有很多方法可用于支持复杂的系统，但为了开发自动驾驶系统，必须对这些方法加以改进。本文还讨论了处理日益复杂的问题的技术：基于模型的系统工程，通过基于合同的开发进行正式验证，以及仿真和协同。在这些方法中，哪种方法可以并适用于满足具体的安全关键需求，仍需根据具体情况在具体的安全案例中加以界定和论证。

作者：牛喀网特邀专家
牛喀网文章，未经授权不得转载！