基于UML/MARTE的汽车安全关键系统设计方法

如今汽车中电子 / 电气系统的复杂性正不断提升。高度分布式系统（即所谓的信息物理系统）与物理世界相互作用并对其产生影响，这带来了新的挑战。行业需要像 UML/MARTE 这样的建模语言，在整个设计过程中为工程师和管理人员提供支持，以降低成本并缩短产品上市时间。尤其对于安全关键系统，从高层系统描述到硬件和软件的详细建模，在各个抽象层级都必须考虑安全因素。在此过程中，不仅要考虑功能需求，还需兼顾非功能需求。本文提出了一种无缝的模型驱动架构方法，用于在功能安全标准 ISO 26262 的整个设计阶段对安全关键系统进行建模。此外，为解决可追溯性问题，本文采用 SysML 扩展 MARTE，以实现半形式化需求建模。为验证该方法的有效性，将其应用于电池管理系统这一工业用例。结果表明，MARTE 完全适用于汽车领域不同粒度层级的系统建模，且符合功能安全需求。

如今的汽车由高度复杂的电子 / 电气（E/E）系统构成，其中的传感器与执行器相互联网，实际上，现代汽车或多或少可被视为 “装在车轮上的智能手机”。显而易见，汽车正朝着全电子 / 电气化方向发展，传统内燃机正逐渐被淘汰。这些系统的传感与控制工作由高度分布式的电子控制单元（ECU）完成，目前一辆电动汽车中集成的微控制器数量已多达 100 个，这一现象并不罕见。

近年来，车载电子 / 电气架构的发展趋势以及新型应用的出现，推动系统朝着多核、异构、网络化和可重构的方向快速转变。此类系统的设计与开发极为复杂，给来自不同领域的（硬件和软件）设计师在应用开发过程中带来了巨大挑战。下一代此类系统需能够在系统的不同部分（如多个 ECU、单个 ECU 多核架构中的处理器和数字信号处理器（DSP））上并行运行。应用领域正不断拓展，涵盖多媒体、信息娱乐、高级驾驶辅助系统（ADAS）、导航等多个方面。这一变化对设计、开发和管理工作产生了影响，进而导致生产成本增加和产品上市时间延长。欧洲工业界也已认识到这一问题。

随着汽车领域复杂性的不断提升，安全已成为未来汽车开发的关键问题。特别是对于与物理世界相互作用并产生影响的信息物理系统而言，仅对单一行为进行测试已远远不够。在开发周期的早期阶段，就必须在各个粒度层级对整个系统进行验证。汽车电子 / 电气系统功能安全标准 ISO 26262也推荐采用这一做法。ISO 26262 是功能安全标准 IEC 61508 在汽车领域的适应性版本，目前汽车原始设备制造商（OEM）及电子 / 电气系统供应商均需遵守该标准。ISO 26262 在产品全生命周期的各个抽象层级为管理人员和工程师提供支持。由于需要考虑多种系统假设和设计方案，基于模型的方法成为工程师和多方利益相关者开展工作的重要基础。该方法能帮助设计师快速、全面地了解系统，为沟通提供有效途径，尤其适用于涉及多个设计团队参与的复杂系统开发场景。

MARTE 是对这类系统进行建模的有效工具。它是 UML2 的扩展规范，具备对硬件、软件以及时序和性能行为进行建模的能力。目前，许多半导体厂商和供应商都在使用 MARTE。尽管 MARTE 在汽车领域的应用尚未普及，但随着汽车电气化进程的推进，越来越多的组件与电子 / 电气系统相关联，未来 MARTE 必将在降低开发成本、缩短开发时间方面发挥重要作用。此外，MARTE 是欧洲 Catrene 项目 OpenES中的主导系统设计语言。OpenES 是一项欧洲发起的倡议，旨在填补当前系统设计领域的空白，开发通用解决方案以保持行业竞争力。该项目特别关注对功能需求的整体支持，同时也重视对时序、热问题和功耗等非功能需求的支持。

UML 的另一优势在于，目前已有多款商业和开源工具对其提供支持，例如 Eclipse 的 Papyrus。该工具能帮助设计师使用 UML 以及 MARTE、SysML 等扩展规范进行系统建模。

本文提出了一种在不同抽象层级对安全关键系统进行建模的方法。研究表明，现有建模语言能够完整呈现功能安全标准 ISO 26262 的整个设计流程，且无任何妥协，同时还能为安全分析提供额外功能支持。为此，本文采用了在 OpenES 项目中完善的模型驱动架构（MDA）改进版本。研究证明，从项目定义、系统设计到软硬件分离的整个过程，都可映射到图 1 所示的基于模型的方法中。在该方法中，ISO 26262 的每个层级在 MDA 中都有对应的层级，这有助于设计师和工程师在设计阶段的各个层级保持一致的认知。此外，在需求阶段，本文利用 SysML 的功能在不同抽象层级对各项需求进行建模，从而实现与设计阶段模型和图表的无缝衔接。研究还表明，MARTE 非常适合汽车领域复杂系统的设计工作。

图1. ISO 26262设计阶段到MDA映射

本文结构如下：第 2 节介绍研究现状及相关工作；第 3 节简要概述功能安全及安全生命周期；第 4 节阐述模型驱动架构方法及所使用的建模语言；第 5 节介绍将该方法应用于电池管理系统案例研究的具体情况；最后在第 6 节得出结论。

多篇文献探讨了如何在协同设计过程中使用 MARTE，这些文献阐述了 MARTE 如何与模型驱动架构及规定的抽象层级相契合，同时也讨论了在设计过程中如何在不同抽象层级对硬件和软件进行建模，以及如何对额外功能属性进行建模和如何将软件应用映射到平台等问题。然而，这些文献既未考虑与 SysML 需求的可追溯性，也未涉及安全约束的建模。

文献 的作者提出了在安全关键系统开发中应用 ISO 26262 的概念，重点探讨了该功能安全标准第 3 部分（概念阶段）和第 4 部分（系统级产品开发）中涉及的系统层面问题，但未考虑硬件或软件的详细建模。此外，该文献未采用 UML 等标准进行系统建模，也无法在整个设计阶段实现无缝流程。该方法既未说明如何在流程中添加行为图，也未定义安全状态或其他行为功能，且仅部分实现了与结构图表和行为图表的可追溯性。

文献讨论了在汽车行业及功能安全标准中如何将 SysML 用作需求表示工具。这些文献的作者展示了如何在不同抽象层级以半形式化的方式对需求进行建模，同时也解决了安全生命周期需求阶段不同层级之间的可追溯性问题。其中一种方法通过扩展 SysML 来定义安全关键系统的需求；文献则考虑了需求与结构模型和行为模型的分配问题。该方法很好地展示了如何利用 SysML 在不同抽象层级对需求进行建模，但遗憾的是，它并未覆盖 ISO 26262 的整个设计阶段，且仅局限于 UML/SysML 图表的可追溯性。本文将以该方法为基础，实现标准所推荐的全方面可追溯性。由于上述方法均未将 MARTE 视为硬件和软件的详细建模语言，因此本文将展示如何利用 SysML 实现与多个层级 MARTE 模型的可追溯性。

EAST-ADL是汽车领域一种成熟的建模语言，主要用于汽车嵌入式电子系统的开发，常与致力于软件开发生标准化的 AUTOSAR 协同使用。该语言是在 ITEA 合作项目 EAST-EEA 以及后续的 ATESST、MEANAD等项目的背景下开发的。由于 EAST-ADL 已被纳入 Eclipse Papyrus，因此也可使用 SysML 需求模型来定义需求。

EAST-ADL 分为五个抽象层级，每个层级对应相应的系统行为，分别是车辆层、分析层、设计层、实现层和操作层。EAST-ADL 建立在 AUTOSAR 基础之上，仅覆盖从车辆层到设计层的抽象层级，而实现层和操作层则通过 AUTOSAR 进行建模。这种架构使得 ISO 26262 标准所要求的自上而下的可追溯性以及需求可追溯性的实现变得极为繁琐且容易出错。ATESST 和 MEANAD 项目的目标之一是实现功能安全标准与 EAST-ADL 抽象层级的映射，但这些层级与模型驱动架构并不兼容，且该方法也未涵盖 ISO 26262 的所有设计层级。此外，EAST-ADL 缺乏对时序、性能属性及其他额外功能属性的引用能力，而 MARTE 则对这些属性进行了详细的处理。

随着汽车领域越来越多的系统涉及实时嵌入式系统，将安全标准应用于 MARTE 已成为安全关键系统开发的下一步重要工作。

ISO 26262 是功能安全标准 IEC 61508 在汽车电子 / 电气系统领域的适应性版本。由于 ISO 26262 在法律层面被视为行业最佳实践，如今汽车原始设备制造商（OEM）及其供应商均需遵守该标准。该标准针对与安全相关的电子 / 电气系统因故障而引发的危害进行了规范，并涵盖了产品全生命周期内的功能安全方面。它以行业标准的 V 模型（即汽车安全生命周期）的形式，对危害识别、设计、实施和测试等环节进行了规定。该标准还通过汽车安全完整性等级（ASIL）分析，明确了硬件和软件组件开发所需的各项安全需求。针对每个具有 ASIL 分类的危害事件，需制定相应的安全目标。这些安全目标是整个安全生命周期链条的起点，进而形成安全档案，以证明系统具备可接受的安全性。安全档案用于收集和呈现证据，为安全声明和论证提供支持。本文主要关注 V 模型的左侧部分，即从概念阶段到产品开发阶段的内容。由于 V 模型右侧涉及验证、测试和生产环节，超出了本文方法的研究范围，因此暂不涉及。本文采用 MDA 方法，展示如何在汽车安全标准的设计阶段对安全方面进行建模。

4.1 建模语言

UML 是对象管理组织（OMG）制定的建模标准，它通过图形化方式对软件及其他系统进行规范和文档化描述，能够全面呈现系统的整体情况、各个组件及其相互之间的交互关系。UML 包含多种类型的结构图（如类图、组件图、复合结构图）和行为图（如活动图、用例图、状态机图）。尽管 UML 非常适合软件开发，但它不具备设计硬件和非功能属性的能力。

另一种方法是采用领域特定建模语言 SysML。它采用了 UML2 的子集，并提供了额外的扩展功能，用于在系统工程中描述复杂系统。SysML 为 UML2 新增了两种图表（需求图、参数图），分别用于需求工程和性能分析，为需求到组件或行为图的分配提供了良好机制，但在硬件和资源建模方面不够精准。

MARTE 是 OMG 为解决 UML 在平台建模方面的不足而制定的适应性规范。MARTE是一种领域特定建模语言，适用于信息物理系统中实时嵌入式软件的基于模型的设计与分析。MARTE 作为 UML2 的一种规范，提供了 UML 所缺失的实时系统建模额外机制。其优势在于，通过 HRM（硬件资源模型）和 SRM（软件资源模型）构造型，能够精确地对硬件和软件资源进行建模。此外，借助 MARTE 的分配机制，可以将软件应用分配到硬件资源上。MARTE 遵循信息物理系统的理念，关注整个系统而非一系列专门的部件，这也与 ISO 26262 对安全关键系统设计的建议相符。

随着采用更正式的建模语言并进一步挖掘其潜力的趋势日益明显，MDA 方法的重要性也不断提升。从不同子规范的定义可以看出，MDA 已融入 MARTE 语言之中。欧洲层面也认识到了这一发展的重要性，在 Catrene 项目 OpenES 中，MARTE 和 MDA 方法占据了重要地位。本文方法仅使用标准化的 MARTE 元素。

4.2 改进的模型驱动架构

在 OpenES 项目中，由于 OMG 制定的标准 MDA 层级未得到充分明确的规定，且缺乏形式化定义，项目合作伙伴对 MDA 方法进行了改进（如图 1 所示）。该图展示了 ISO 26262 设计阶段不同层级与 MDA 层级之间的映射关系。在本文方法中，功能安全标准的每个层级在 MDA 方法中都有对应的层级。各层级的详细定义如下：

计算独立模型（CIM）：旨在提供系统级视图，主要聚焦于系统的功能结构，不涉及功能实现方式的具体信息，尤其不包含软硬件识别相关内容。此外，这类模型的精度不足以支持模型执行。尽管 CIM 缺乏显式或隐式的计算模型，但它可以包含系统级用例，以展示不同功能块之间的同步和异步通信。不过，CIM 的抽象程度较高，无法对非功能属性进行规范。

平台独立模型（PIM）：除具备 CIM 的功能外，还包含 UML 状态机、活动图等额外的行为模型。此外，在该改进层级中，可以表达时序、功耗、热问题、安全性等非功能属性。PIM 并非完全可执行的模型，仅能对整个系统的部分内容进行更精确的细化。如果未在图表中直接表达行为，则可将模型与现有的实现代码相关联。这些模型可用于对系统行为进行早期的高层级仿真。PIM 所呈现的规范内容，在不同平台间具有稳定性，不会因平台变化而改变。

改进的 PIM：该层级的明确设立旨在与 OpenES 的子系统定义概念相契合。它通过对 PIM 进行功能分解，使分解后的每个功能块粒度足够精细，能够分配到单个硬件或软件执行资源上。也就是说，一个 PIM 功能块不能分配到多个执行资源上，因此需要先将功能块拆分为不同的子功能。此外，在将这些子功能映射到不同执行资源之前，需明确它们的通信接口。

平台特定模型（PSM）：涵盖多个方面的内容。首先，它需包含用于描述执行平台的元素，包括硬件和软件执行资源。在硬件方面，模型可包含寄存器、内存映射信息等底层细节；在软件方面，执行平台描述可明确操作系统相关信息，如任务、调度算法、中间件服务等。除平台描述外，PSM 还包含对 PIM 模型的进一步改进，即将平台无关的功能组件转换为平台特定的组件，并明确引用执行资源服务。PSM 的部分内容可通过下文所述的分配模型生成。

分配模型：是改进的 PIM 与完整 PSM 之间的中间环节，用于描述如何将改进后的平台无关功能组件分配到硬件或软件执行资源上。这意味着 PSM 的部分内容需预先存在，以便识别和引用这些执行资源。分配模型可作为额外功能属性分析工具的输入，用于验证特定的映射是否能够满足预期的额外功能属性约束。同时，它也可作为代码生成或模型转换的来源，以获取详细的平台特定应用模型。由于分配模型更像是连接更高细节模型的纽带，因此在本文方法中不将其视为一个独立的层级。

为展示如何在功能安全标准的整个设计阶段运用 MARTE 和 MDA 方法，本文以 CISC 半导体公司提供的带有能量回收功能的电池管理系统为例进行工业验证。随着越来越多的车辆采用锂离子电池供电，工程师确保电池可靠性和容错性的挑战也大幅增加。过去，电池过热甚至爆炸的问题屡见不鲜，其主要原因是再生制动过程中能量摄入过高，或恶劣环境条件的影响。因此，管理系统和相关机制至关重要，它们能确保人员安全，避免财产损失。诸如对电池单体温度和电压进行冗余且多样化测量等安全机制，可减少单点故障、残余故障和多点故障的发生。此外，在高完整性等级下，对传感器数据进行多次多样化计算也是一项重要措施。由于全面探讨该项目的所有安全方面超出了本文的范围，因此本文重点关注电池状态监测。电池管理系统的各组成部分详细说明如下：

电池监测单元（BMU）：作为电池的主控制器，负责采集来自电池单体传感器的各类数据。BMU 计算电池的荷电状态（SOC）和健康状态（SOH），同时负责电池单体均衡、单体保护以及电池需求管理。此外，它还控制一个硬件开关，用于连接电池与电动机。

电池控制单元（BCU）：在充电过程中，负责控制充电器输出的电压和电流曲线。除控制外部充电器充电外，BCU 还监测再生制动过程中的充电情况，并在电池充满电时进行能量释放。当发生故障时，可通过 BCU 实现电池隔离，或由 BCU 向动力传动控制器（PTC）发送信号以限制车速。

动力传动控制器（PTC）：是电池与电动机之间的主要接触器，负责控制车辆和车轮转速，并向监测电池状态的 BMU 发送指令，以启动电动机。

电池：由 12 个串联连接的单体组成，每个单体均配备温度传感器和电压测量接口。

显示器：用于显示当前电池的 SOC 和 SOH，并在达到临界阈值时向驾驶员发出警告。

在功能安全标准框架下，开发过程的首要且关键步骤是明确项目定义。项目定义指的是在车辆层面实现特定功能的一个或多个系统组合，安全标准将应用于该系统组合。一个系统是由至少包含传感器、控制器和执行器的一组元素构成，其中每个元素既可以是硬件部分，也可以是软件部分。图 2 通过 UML 复合结构图和信息流的形式，将项目定义建模为功能块，清晰呈现了 CIM 层级下整个项目的全貌，包括其边界以及与外部环境的接口。在该层级中，仅展示各功能块之间的通信方式，而不具体规定功能的实现方法。

图2. 项目定义：高级功能视图

通过项目定义以及危害分析和风险评估，为每种危害制定相应的安全目标。每个安全目标都有其对应的 ASIL 等级，该等级根据操作场景的严重程度、暴露度和可控性进行分类。在本案例中，设定的 ASIL C 级安全目标为：“必须避免电池温度过高”。这些安全目标是功能安全概念（FSC）中规定的功能安全需求（FSR）的基础（ISO 26262，第 3-8 部分）。本案例中衍生的一项 FSR 为：“电池管理系统（BMS）应监测并控制电池，确保电池在工作范围内运行”。

ISO 26262 标准针对不同 ASIL 等级，推荐了多种实现安全的方法和设计技术。在本案例中，为提高系统的可靠性和可用性，采用了异构双工模式。该模式使用额外且多样化的硬件组件，不仅能够处理随机故障，还能应对系统性故障。不同的硬件组件会使硬件产生不同的响应，同时也能提高对共因失效的覆盖范围。由于本项目的 ASIL 等级为 C 级，标准推荐使用两个独立且多样化的信号来控制电池单体，以实现冗余和多样化。本文将此与 ISO 26262 的分解机制相结合，将 ASIL C 级传感器分解为两个 ASIL B（C）级传感器，这样既能保持相同的分类等级，又能通过独立的冗余和多样化测量提高可靠性。

下一步，将之前定义的 FSR 细化为：“若两个测量值显示电池单体数据存在差异（合理性检查），则系统应切换至安全状态”。安全状态是指系统在发生故障时应呈现的预期行为，可确保系统安全运行。在本案例中，安全状态包括 “降低功率（降级功能）” 甚至 “切断电池与电动机之间的连接”。

图3. 架构假设：系统设计的预版本，没有提供有关所用平台的信息

功能安全概念的输出结果是初步的架构假设（如图 3 所示），它是系统设计的初步版本，也是功能需求的实际解决方案。在该图中，各组件之间的关系表达更为明确，系统视图更为详细。此外，图中还包含了组件实例的 MARTE 流端口（输入、输出、双向）以及组件之间的连接器。在该抽象层级（PIM），模型与具体实现无关，因此不涉及功能实现所依赖的技术细节或平台。通过使用 MARTE 通用资源模型（GRM），可以对系统设计做出初步假设。利用 “通信介质（communicationMedia）” 构造型，可以定义 CAN 总线的容量、传输模式等属性；采用 “计算资源（computingResource）” 构造型，能够在较高抽象层级对处理资源进行建模，无需关注 CPU 速度、内存容量等细节。

在此阶段，还需添加活动图、状态机图等额外的行为模型，以描述系统行为，并将这些行为图分配到架构假设的各个模块中。图 4 通过节点和边对安全状态进行建模。借助 “定时处理（timedProcessing）” 构造型，还可在活动图中考虑初步的时序约束（图中未显示），具体可通过值规范建模语言（VSL）将持续时间指定为 “value = 30；unit = ms”。在后续的细化步骤中，结合硬件 - 软件接口（HSI）的更多细节，可以对图中每个节点的时序行为进行更精确的定义，例如详细描述系统响应时间或故障响应时间。MARTE 的优势在于，能够通过定性和定量标注的方式，在行为描述中捕捉时序信息。这些预期的行为规范可为后续过程中的模型验证提供重要输入。行为图和时序约束的另一作用是，后续可用于生成基于仿真的验证所需的测试平台，还可将其与仿真结果进行对比分析。

图4. 安全状态：具有额外功能计时属性的活动图

完成系统设计的初步版本后，需将 MARTE 模型与已有的 SystemC-TLM 实现模型相结合。这样便可通过高层级仿真，深入研究各组件之间的依赖关系。为此，本文使用了 SHARC工具，这是一款基于 Eclipse 开发的工具，适用于对不同抽象层级的信息物理系统进行建模和仿真。SHARC 是 SyAD/SIMBA的增强版本，支持对以 SystemC、Matlab 或 VHDL 编写的各类分布式组件进行协同仿真，还可切换至系统中单个组件的较低实现层级（如 RTL 级）进行仿真。这对于采用故障注入等方法验证硬件安全机制至关重要，也是 ISO 26262 中硬件设计验证方法所推荐的做法。

初步架构假设、HSI、失效模式与影响分析 / 故障树分析（FMEDA/FTA）以及硬件架构指标共同作用，最终形成技术安全需求（TSR）。可通过文献中描述的方法，对 UML 模型进行 FMEA/FTA 分析。在本案例研究中，TSR1 定义为：“每 30 毫秒对两个模拟传感器（温度和电压）进行合理性检查。若温差超过 10°C 的容差阈值且持续时间超过规定值，则切换至安全状态”。这进而形成了系统设计的第一个正式版本。

在此阶段，需初步确定将通过硬件和软件分别实现哪些功能。根据 OpenES 改进的 PIM 的定义，如果无法将每个模块分配到硬件或软件（即不具备原子性），则必须将系统拆分为子系统。本文通过之前采用的分解机制，将 ASIL C 级传感器拆分为两个 ASIL B（C）级硬件传感器，从而对架构进行细化。在 UML 类图中，通过组件聚合实现 ISO 26262 各层级之间的纵向可追溯性。

在硬件平台建模方面，采用 MARTE 硬件资源模型（HRM）。图 5 将电池拆分为多个电池单体，每个单体都与标有 MARTE“硬件传感器（hwSensor）” 构造型的电压和温度传感器相连。图中还包含两个处理单元，分别是标有 “硬件计算资源（hwComputingResource）” 的微控制器和标有 “硬件专用集成电路（hwASIC）” 的 ASIC，二者均为 “硬件资源（hwResource）” 构造型的特化类型。这两个处理单元用于独立、冗余地计算来自传感器的数据，从而提高系统的容错能力。为清晰区分硬件和软件，将传感器处理任务和管理任务分别分配到微控制器（即电池管理单元）这一计算资源上。

图5. 系统设计：将应用程序分配给使用的硬件平台

在将应用分配到平台的这一环节，可按照文献中描述的方法，在 MARTE 中进行可调度性分析。这样能够在确定具体实现方案之前，对不同设计方案进行早期分析，这对于安全关键系统的设计尤为重要，因为在这类系统中，必须谨慎处理资源分配，确保多媒体应用等常规任务不会影响安全关键任务，也不会占用安全关键任务在规定时间内运行所需的资源。可将某个任务切换到另一个拥有独立受保护内存的处理单元上运行，通过这种方法，能够分析不同任务分配到处理器核心时的最坏情况。

将系统功能块拆分为硬件和软件组件后，即可制定硬件和软件的需求。设计方法的最终层级（PSM），即硬件和软件架构设计，便是根据这些需求推导而来。

MARTE 规范提供了一系列硬件建模概念，可用于构建详细的计算硬件模型。在本案例中，通过复合结构图对硬件进行设计，以图形化方式展示输入 / 输出接口（如图 6 所示）。在系统级设计的 BMU，此时被拆分为四个详细组件：CPU、ROM、RAM 和 CAN 控制器。借助 MARTE HRM，为这些模块添加特化构造型标签，以明确其属性。此外，还可在硬件描述中添加硬件设计所需的其他安全相关属性标注，如失效率、是否与安全相关、硬件安全机制以及相关的诊断覆盖率等。本文还采用了自定义的 MARTE 规范，以 IP-XACT标准对硬件进行描述。

图6. 硬件描述：电池管理单元的详细结构

在软件设计中，采用传统的类图对软件任务进行描述。MARTE 软件资源模型（SRM）和高层应用模型（HLAM）足以对系统的各项约束（如消息大小、内存大小）进行定义。下一步，为 BMU 的管理任务添加 ThresholdCheck ()、Display ()、PlausibilityCheck () 等操作，并使用 MARTE 时序标记为任务添加时序属性。随着模型细节的不断丰富，这些模型后续可用于自动生成 SystemC环境下的硬件和软件代码。Gaspard2 框架利用 MARTE 模型生成用于综合的 RTL 代码，或用于高层级仿真的 TLM 代码，从而填补了从早期安全关键需求分析、系统规范制定到仿真与综合之间的空白。

ISO 26262 标准中频繁提及的一个关键问题是确保可追溯性。可追溯性始于安全目标，贯穿整个需求和设计阶段，涵盖从功能安全需求（FSR）、技术安全需求（TSR）等衍生需求到行为模型和结构模型的各个环节。为了为不同领域的工程师和管理人员提供支持，同时为安全档案中的论证提供依据，必须在生命周期的每个层级确保可追溯性。

在本文方法中，采用 SysML 对需求树进行建模，并通过 SysML 的 “衍生（derived）” 构造型建立各项需求与不同层级之间的关联。若某项需求的描述不够详细，可通过 “细化（refine）” 构造型关联另一项更详细的需求。图 7 显示，通过将每项需求分配到对应的组件或图表，不仅实现了生命周期内的纵向可追溯性，还实现了横向可追溯性。另一种方法是在 Papyrus 中以指定的类表格形式展示 SysML 需求，这种方式能清晰呈现所有需求及其 “满足（satisfiedBy）” 关系。该表格具备动态更新功能，当需求与模型之间的关联关系发生增减或修改时，表格会立即更新，同时也适用于大型系统。

图7. 组件和图表的需求分配：垂直和水平可追溯性

本文提出了一种基于模型驱动架构（MDA）的方法，用于在功能安全标准 ISO 26262 的设计阶段对不同粒度层级的安全关键系统进行建模，其中 MDA 层级的规范和细化工作是在欧洲 Catrene 项目 OpenES 中完成的。研究采用面向实时嵌入式系统的 UML 规范 MARTE，在 ISO 26262 设计阶段的所有抽象层级对安全方面进行建模。结果表明，无需使用任何自定义的 UML 扩展规范，MARTE 就非常适合汽车领域电子 / 电气系统的建模工作。通过采用标准化建模语言，实现了与该领域其他工具的高度复用性。此外，借助 SysML 实现了需求与组件及行为模型之间的横向和纵向可追溯性，通过与 MARTE 图表的关联，达到了 ISO 26262 标准所要求的高可追溯性水平。本文通过将该方法应用于电池管理系统，验证了其有效性。

未来的工作将围绕设计模型的仿真展开，以实现安全关键系统的验证。借助 SHARC 工具，可将 MARTE 模型与不同抽象层级下以 SystemC 或 Matlab 编写的实现模型相关联。下一步，将利用行为模型自动生成用于基于仿真验证的测试平台。