内容提要：在本文中，我们提出了安全关键系统的无缝设计和验证流程。基于UML的标准化建模语言用于表示从功能规范到硬件和软件的设计流程。

摘要

当今车辆的电气化和大量新辅助功能意味着系统越来越复杂。这些系统的传感和控制是高度分布式和连接的电子控制单元的工作。为了跟上快速增长的汽车市场的步伐，组件和功能的可重用性如今是降低成本和缩短上市时间的关键。特别是当系统对安全至关重要并且需要可靠性时，新的方法和工具对于支持开发过程中的可重用性方面至关重要。基于模型的方法结合起来，有助于不同利益相关者之间的沟通，提供不同的观点并充当信息的中央存储。通过在我们的硬件模型上应用可靠性分析和基于仿真的验证方法，并进一步自动生成第一个虚拟原型，我们能够减少所涉及的工具，从而实现整个系统的正确性、完整性和一致性。

1.简介

当今世界，各个领域的嵌入式电气/电子（E/E）系统的数量正在很大程度上增加。当我们思考过去几年的复杂性时，很明显出现了新的应用程序，其中系统不仅相互交互，而且对物理世界产生影响，即所谓的网络物理系统。根据其应用，它们必须满足不同的要求，包括时序限制、性能行为、低功耗、散热甚至不同环境条件下的工作能力。这里的要点是，我们生活在一个网络物理系统无处不在的世界，它们对我们的日常生活产生影响，这些系统的故障可能会对人们造成严重的损害或伤害。因此，我们必须确保这些系统的可靠性。

当我们转向汽车领域时，这一点更加明显。可以看出，电动汽车的趋势导致了向全 E/E 系统的转变。传感和控制是高度分布式电子控制单元 (ECU) 的工作，毫不奇怪，通过汽车中的所有这些新功能，目前一辆现代汽车中集成了上百个此类微控制器。这种情况也对当今汽车中的软件数量产生了影响，其代码总数可达上亿行。由于许多相互影响的新（辅助）功能的出现，该行业面临着新的问题。反过来，这提高了复杂系统的设计、开发和验证的复杂性，并使工程师在开发应用程序时付出了巨大的努力。在安全方面，这些系统必须满足ISO 26262（道路车辆功能安全）等标准。由于该标准现在在法庭上被视为最先进的标准，因此原始设备制造商及其供应商需要按照推荐的措施和方法开发和测试其系统。

当我们讨论系统的设计时，我们立即想到一种建模语言，即统一建模语言(UML)。UML植根于软件领域，为各种工程领域铺平了道路并建立了基于模型的思维，远远跨越了传统软件设计的界限。由于UML附带了多个扩展，例如MARTE、SysML或EAST-ADL，因此来自不同领域的工程师可以充分利用面向对象方法的潜力。引入MARTE是为了克服实时和嵌入式系统设计中的巨大复杂性问题。它提供了对硬件、软件以及系统设计进行建模的功能。

由于当今最先进的汽车不仅存在一个版本，而且存在数百种具有不同功能的变体，因此每一种都必须经过详尽的测试才能满足标准。必须行驶数百万公里的测试公里才能确保汽车的可靠性，在真实环境中对其进行测试既不经济也不安全。仿真在现代汽车的验证中发挥着越来越重要的作用，因为它具有轻松改变虚拟环境和以不同变化形式表示汽车的优势，尤其是从经济角度来看。仿真可以在早期开发阶段进行，此时功能的详细实现尚未确定，而且可以在明确定义硬件和软件的平台特定模型（虚拟原型）上进行。每次都可以监控、重现和重新运行所应用的验证方法和测试。仿真的另一个优点是它不仅可以昼夜运行，而且可以大规模并行。SystemC是一种与UML/MARTE方法具有相同理念的规范和仿真语言。与UML一样，它共享MDA（模型驱动架构）方法，从计算独立的系统设计开始，一直到硬件和软件设计。

ISO 26262建议针对硬件平台使用不同的验证方法。其中包括设计演练、FTA/FMEA、硬件架构指标评估，但更重要的是，更高ASIL级别的硬件原型设计和仿真。这些仿真，包括虚拟样机，可以用于进一步的硬件验证方法，例如故障注入测试，这是目前测试硬件可靠性的关键。一些研究机构现在正致力于执行故障注入，以及更高的抽象级别，例如事务级建模（TLM）。这样做的优点是该方法可以应用于更快的仿真模型，而不会丢失来自更详细模型（RTL，寄存器传输级别）的信息。虚拟原型的优点是可以在第一个真正的硬件原型可用之前更早地测试嵌入式软件。虚拟硬件设计的变化比真实平台的变化要快得多，真实平台需要数周或数月的重新设计和生产，这反过来又会影响上市时间。通过密集仿真，可能会遇到极端情况，但也可能会遇到长期可靠性错误，这也可以防止代价高昂的产品召回。可以仿真和再现环境对虚拟原型的影响，而真实的测试平台无法进行这种验证。缺点是，复杂的虚拟原型（VP）不是一朝一夕就能开发出来的。需要经验丰富的设计师和工程师付出大量努力才能构建所谓的实际硬件的数字孪生。因此，我们的建议是重用开放虚拟平台(OVP)等开放库中的虚拟硬件原型模型。

在这项工作中，我们提出了一种新颖的安全感知虚拟原型设计和开发流程。该设计流程符合ISO 26262标准，并满足其最终生产出可靠产品的所有要求。整个系统，从第一个功能规范到硬件设计，都是由标准化建模语言指定的。在从硬件规范生成虚拟样机之前，对该规范应用并执行了多种可靠性分析方法。这样可以在仿真测试原型之前对硬件设计的安全性进行早期评估。此外，我们展示了将生成的虚拟原型集成到系统设计中，以验证接口及其功能。整个方法可通过名为SHARC（分层嵌入式微电子系统的仿真和验证）的开发设计和验证框架获得。

2.相关工作

研究人员旨在通过单一信息源原则实现开发过程中涉及的多个工具之间的信息一致性。为了在不同团队和利益相关者之间的开发过程中实现可靠性（安全性、防护性），他们决定放弃以文档为中心的方法，并在设计中使用UML和SysML的功能。这反过来又提高了整个正在开发的系统的一致性、正确性和完整性。这种方法中的工具链更多地关注系统和软件开发，没有考虑硬件开发。研究人员还建议更新他们的个人资料，以便有效地进行硬件开发。

为了克服设计和仿真模型的一致性问题，研究人员提出了SysML和Matlab/Simulink之间的模型转换框架。它们支持从早期概念阶段到软件实现的一致且可追踪的细化，并且以双向方式进行。研究人员还声称，基于模型的设计有助于为不同的利益相关者提供不同的视图、不同的抽象级别以及信息的集中存储。尽管如此，研究人员的重点更多地放在系统设计的软件架构生成上，而不是硬件设计的要求。

流行的方法已经表明，UML作为建模语言可以有效地与FMEA（失效模式和影响分析）、故障树分析（FTA）、设计演练、代码生成等分析和验证方法一起使用。就验证系统行为的仿真而言，UML的缺点是，代码生成只能在非常晚的阶段，甚至在设计过程结束时完成，此时所有细节都是众所周知的。设计中的后期更改成本高昂，会导致模型不一致，而且逆向工程是一项容易出错且繁琐的任务。新项目中的大多数组件都可以重复使用，并通过添加新功能进行简单扩展，以减少成本和上市时间。因此，重用整个安全概念、可靠的设计和机制对于减少开发复杂系统所需的工作量变得越来越重要。这种情况促使人们迫切需要新技术，通过重用经过验证的系统组件来仿真早期开发阶段的行为。

3.应用案例

在本文中，我们将展示我们针对当今汽车领域相关问题的方法，即锂离子动力电动汽车的电池管理系统。该工业用例由位于奥地利和美国的CISC Semiconductor GmbH提供。该用例将有助于更全面地说明我们方法的创新能力和优势。随着越来越多的车辆采用锂离子电池供电，工程师在确保可靠性和容错性方面面临的挑战也大大增加。电池管理系统 (BMS) 等监控系统非常精确地测量电池的电压、温度和电流，对于确保电池的安全运行条件至关重要。该信息必须转发到车辆范围内的控制器网络，以确保系统可靠且充分利用。过热甚至爆炸的问题过去经常发生。这些问题的主要原因是再生制动能量摄入过高或恶劣的环境条件。因此，管理系统和机制对于确保人员不处于危险之中且不造成损害至关重要。

为了实现我们用例的第一个可执行规范，我们使用的方法，将UML/MARTE设计模型与SystemC（-TLM）/SystemC-AMS中的可重用仿真模型（模型库）连接起来，根据它们的用途，一直到更详细的模型。所提供的模型库包含模拟和数字模型，以便在系统级对功能规范进行早期快速评估。此外，通过这种方法，我们消除了将收集的数据导出到其他仿真工具（如Matlab/Simulink）的繁琐任务，并将UML/MARTE设计保留为单一的信息源。此外，我们依赖于标准化和开放的建模和仿真语言，并保持较低的许可成本。

图1：使用UML/MARTE的电动汽车用例的总体系统级描述

电动汽车的整体系统如图1所示。为了简化起见，我们只考虑电动汽车的主要部件，对电池和BMS进行分析。其中包括采用锂离子技术的电池组、测量电池电压和温度的BMS、逆变器ECU、控制器和电动机模型。有两个主要因素影响电动汽车的行为。驱动器提供所需的速度（每分钟转数），另一方面提供电机轴上的负载。这些刺激可以根据新欧洲驾驶循环(NEDC)等标准化操作或在2017年推出的全球统一轻型车辆测试程序 (WLTP) 等新标准来设置。

4.硬件平台规范

根据收集到的功能和可执行规范信息，我们现在更深入地研究硬件设计。由于MARTE和SystemC在从系统开发转向硬件和软件开发方面有着相同的理念，因此我们现在能够通过细化来指定BMS平台的内部架构。由于这项工作的主要目标是建立一个ISO 26262安全平台，这是开发过程中的重要一步，并且需要付出大量努力，因为必须将许多不同的方法和措施应用于硬件平台，以确保可靠安全的产品的最终结果。

由于OVP虚拟原型或多或少由一组包含TCL脚本的SystemC-(TLM)文件组成，因此这项工作的一个目标是将虚拟原型的整个生成过程纳入安全关键系统的无缝设计流程中。此外，VP的设计和配置基于图形建模标准，在本例中为UML/MARTE。这种方法的优点是能够在从UML模型生成实际原型之前评估和分析硬件设计的配置。OVP本身不支持安全验证，迄今为止OVP也没有嵌入到无缝设计流程中。

正如前一章提到的，UML/MARTE为硬件平台的规范提供了多个级别的详细信息。硬件资源模型（HRM）包提供了多种模型以逻辑和物理方式描述HwProcessor、HwBus、HwDevice或HwMemory等子系统。尽管UML/MARTE提供了一组丰富的不同构造型来描述硬件平台，但它没有提供OVP方法所期望的硬件配置的详细级别。几个强制属性，例如总线接口或内存映射或VLNV MARTE标准目前不支持（供应商、库、名称、版本）原则。

为了克服这些问题，我们依靠IP-XACT标准的规范，这有助于我们以足够高的细节程度定义我们的平台，以生成虚拟原型。IPXACT和OVP都依赖VLNV原理来构建模型。因此，我们基于研究人员的方法，通过IP-XACT中的硬件描述属性来扩展MARTE标准。

图2：SaVeSoC的硬件平台，包括MARTE的IP-XACT扩展

图2描绘了该平台的组合结构架构模型，包括处理器、总线、存储器、CAN和两个ADC。为简单起见，我们仅展示电池管理系统设计的主要组件。设计人员可以使用MARTE库中的标准模型轻松构建自己的系统，例如用于CPU的HwProcessor、用于外设的HwI_O或HwComponent、用于内存的HwRam 或用于内部总线或CAN总线的HwBus。根据组件的性质，设计人员能够使用IP-XACT标准中的特定硬件属性（例如内存映射和总线接口）来扩展组件。MARTE模型的描述中还显示了IP-XACT标准的属性。IP-XACT的进一步扩展（例如VLNV）也可以添加到硬件组件中。

5.虚拟样机的生成与评估

5.1 硬件配置评估

根据图2中我们的硬件平台的规格，我们能够对我们的硬件设计执行不同的评估方法。正如前面章节提到的，有多种方法可用于评估我们的硬件架构的可靠性和安全性，其中之一就是硬件架构指标评估。硬件架构指标在ISO 26262的第5部分（硬件级别的产品开发）中处理。这将根据故障处理的要求评估项目的硬件架构。本部分还包括通过适当的安全机制避免系统性和随机性硬件失效的指导。每个安全相关的硬件元件均针对单点故障 (SPFM)、残余故障和多点故障 (LFM) 进行分析。它还描述了硬件架构在应对随机硬件失效（PMHF）方面的有效性。每个硬件部件都应通过安全机制进行保护。诊断覆盖率证明了这些机制的有效性。项目（根据ISO 26262的系统或系统阵列）是否通过或未通过给定的ASIL也是硬件架构指标评估的结果。为了达到特定的ASIL，必须满足表1中的值（FIT-及时失效）。

表1：架构指标-根据ISO 26262评估硬件是否达到特定ASIL

为了对我们的硬件规格进行评估，我们采用了研究人员的方法。这些方法利用UML/MARTE和IP-XACT的功能来执行多种量化方法来评估硬件平台的可靠性。此外，他们在IP-XACT中定义了故障模型的扩展，可以在不同的硬件平台配置中重用。这些重用策略在工业界常用，被称为克隆和拥有。现有的和重复使用的安全模型可以通过对修改后的平台甚至新产品进行早期安全评估来提供重要的反馈。当然，在开发过程中重用安全工件时，必须考虑整个平台的更改和适应。由于本文的主要贡献是将虚拟原型生成并集成到无缝设计和开发流程中，因此我们不会详细介绍硬件评估。

5.2 虚拟样机的生成

这项工作的概述目标之一是在实际平台可用之前，在开发阶段在目标系统的实际硬件原型上开发和测试嵌入式软件。嵌入式软件通常是在桌面环境、主机系统的通用操作系统上编写的。这种方法通常与目标平台有很大不同，并且部分编写的软件需要调整。处理这个问题的一种方法是使用指令集仿真器（ISS）和硬件可视化。由于SoC设计中供应商的组件多种多样，因此仿真可能非常困难。硬件仿真器在这个问题上非常流行，但需要对所开发系统进行详细的RTL描述，这与同质开发环境的概述目标相矛盾。OVP使创建虚拟平台模型成为可能，并支持SystemC TLM 2.0。OVP模型的执行速度比RTL中开发的模型快得多，因为它们的抽象级别更高，但仍然适合建模目的。

依靠模型驱动工程的思想，以图形方式对虚拟硬件原型进行建模。经过全面的硬件安全分析后，还会生成开发的系统设计并将其集成到现有的建模框架中。因此定义了一种方法，将相应的UML平台描述转换为专有的TCL文件，其中包含使用OVP iGen工具生成源代码所需的信息。对于图形平台描述，我们依赖UML/MARTE的功能。超出MARTE功能的附加属性由附加IP-XACT构造型定义。TCL和IP-XACT都依赖于VLNV原理。编译为共享对象后，虚拟平台可以与提供的库中的其他组件一起进行仿真。

该方法保证了平台与现有仿真框架的无缝集成，并实现虚拟硬件平台与其嵌入的物理环境模型的联合仿真。OVP iGen转换器从TCL脚本获取信息，并使用OVP库的模块化组件生成完整的SystemC TLM2.0平台。生成的虚拟原型可用于进一步的硬件仿真，例如TLM级别的故障注入。

5.3 虚拟样机的集成与验证

由于我们的整个方法（从功能规范到硬件和软件设计）依赖于相同的建模语言，此外还依赖于相同的硬件描述语言和系统建模语言，因此我们可以轻松地将生成的安全感知虚拟原型重新应用到功能规范中的系统设计。生成后，具有完整接口规范的SaVeSoC平台的硬件描述被添加到UML模型库中，并且可以重新应用于系统设计，包括在SystemC中生成的仿真文件。根据ISO 26262的建议，在测试整个系统功能的虚拟原型时，这可以节省集成时间。系统级测试平台还可以重复用于整个系统（包括集成VP）的验证。整个过程如图3所示。通过在传统方法中添加更小的V模型，我们正在缩小当今工具流程中存在的系统设计和硬件开发之间的技术和组织差距。由于我们使用的设计和仿真语言共享无缝的开发流程，因此这些设计级别之间不需要信息传输。规范中不断变化的需求也可以轻松有效地对虚拟原型进行测试。

图3：SaVeSoC集成到功能规范的过程

图4描述了最终的系统级描述，包括电池和新定义的BMS硬件。电池组件不再是在SystemC中描述功能的黑匣子。现在它是一个白盒，其中指定了电池组件的详细硬件。它由SaVeSoC元件组成，该元件是BMS的硬件平台，包括用于合理性检查的应用程序。它通过两个ADC测量电池组的电压和温度，并计算充电状态和健康阶段。电池模型的接口保持不变，接口描述没有变化。由于我们依赖相同的仿真引擎，因此现在可以在更高级别的环境中轻松测试虚拟原型，这也加快了整体仿真时间。将VP集成到功能规范时的一个挑战是功能之间的通信接口SystemC-AMS和OVP平台的仿真环境，因为这些平台主要用于处理嵌入式传感器测量的数据。因此，我们实现了保证不同SystemC方言之间数据交换的通信信道。研究人员认为，仿真引擎在单个进程中执行，SystemC和OVP仿真器在不同的软件线程中运行。主要关注与QEMU或OVP共同仿真SystemC RTL模型的能力。为了避免使用套接字带来的开销，他们通过共享内存和同步机制建立了通信通道。此外，他们开发了一个SystemC桥来实现与外部硬件仿真器的连接。因为原始组件库并不意味着周期精确 ，主要重点是建立现有SystemC-AMS组件与OVP中提供的TLM2.0模型之间的通信。有文章描述了双方的主要属性以及如何在内部执行同步。SystemC AMS提供所谓的转换器端口，用于在定时数据流 (TDF) 模块和普通SystemC信号之间建立连接。如果访问此类端口，AMS内核会触发中断，从而导致上下文切换到SystemC/OVP仿真器。因此，实现的关键部分是从SystemC-AMS线性信号流 (LSF)到TLM的转换，以及如何处理任意LSF模块到OVP平台ADC外设的数据流。

图5显示了将初始LSF信号转换为TLM信号所使用的组件。sca_lsf::sca_-tdf_sink是SystemC AMS库的一个组件，用于对任意输入数据进行采样并将其转换为TDF。自定义的adc_module处理TDF信号，以便在其processing()过程中将其写入adc0的Adin端口。adc0是OVP库的一部分，并稍加修改以满足我们的需求。ADC的端口实现了回调函数，触发ADC的转换。然后可以使用已实现的驱动程序读取它并在CPU上执行。由于OVP模块需要使用某个tlm_signal_port作为TLM目标套接字进行通信，因此我们调整并改进了研究人员的方法来满足我们的需求。

图4：虚拟原型集成到系统设计的功能规范中以验证功能

其次，我们省略了建议的有关数据丢失的内部FIFO。这可以通过参考AMS仿真的恒定采样率来推断。然而，如果处理器每秒不能执行足够的指令，固定大小的FIFO仍会导致数据丢失。

图5：SystemC AMS和OVP TLM2.0之间交互的通信通道

6.结论

在本文中，我们提出了安全关键系统的无缝设计和验证流程。基于UML的标准化建模语言用于表示从功能规范到硬件和软件的设计流程。这种基于模型的方法简化了参与开发过程的不同利益相关者之间的沟通，并充当单一信息源。通过FTA、FMEA、硬件架构指标和基于仿真的验证等推荐的安全分析方法的紧密结合，我们在整个开发过程中实现了一致性、正确性和完整性。通过对业界知名硬件描述IP-XACT的扩展来评估硬件架构。现有的和可重用的硬件描述用于系统设计和集成。我们的工具辅助方法有助于加快评估过程，并通过可重用性降低成本。然后，评估的硬件描述用于自动生成安全感知硬件虚拟原型，用于测试功能规范的正确性。这弥补了当今安全关键系统开发工具链中的技术和组织差距。此外，根据功能安全标准的建议，这种早期的虚拟原型可用于故障注入测试。此外，我们的方法是作为Eclipse的插件开发的，因此每个Papyrus UML编辑器都可以用于网络物理系统的安全开发，只需添加我们的插件即可。进一步的工作将包括为生成的虚拟原型自动生成TLM故障注入测试。

详询“牛小喀”微信：NewCarRen

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