关于用 Simulink 开发应用软件相关介绍和分享

致力于汽车行业基于模型设计流程的实现以及电控单元开发方面的技术咨询工作。他专注于嵌入式代码生成、系统集成、模型验证、处理器在环（PIL）实现、模型架构设计以及MBD工具定制等方面的开发及工具链的深入应用。在加入迈斯沃克之前，李智慧曾供职于法雷奥、德尔福、中汽中心等公司，有10年的汽车行业产品开发经验。

图形化建模是架构设计普遍使用的方法。而 Simulink 已经成为许多系统工程师进行架构设计的利器。不管是在仿真验证阶段还是快速原型阶段，都可以利用 Simulink 非常方便地对复杂控制模型进行功能的组织、划分、调度等工作。

本文参考 ISO 26262 的要求，同时考虑 AUTOSAR 代码生成的兼容性，给出使用 Simulink 实现软件架构设计的一些建议。

应用层软件功能划分

ISO 26262-6 要求创建层次化结构的软件组件（Software Components — SWC）。软件组件应满足规模适中、高内聚、低耦合的要求。软件组件加上ASIL（Automotive Safety Integration Level，汽车安全完整性等级）的要求就决定了开发及验证的方法。软件架构中的最小实体（Entity）就是软件单元（Software Unit）。

在 AUTOSAR（Automotive Open System Architecture）中，应用层软件由应用软件组件组合（Compositions of Application Software Components）组成。一个应用软件组件（Application Software Component — ASWC）要符合特定的模板，而且通过虚拟功能总线（Virtual Functional Bus — VFB。）与其他应用组件进行通信（在控制器内部，VBF 的具体实现是运行时环境 Run-time Environment — RTE）。Runnable（或可译为运行实体）是应用软件组件提供的、可以独立调度的最小代码片段。

【注】在 AUTOSAR 文档中，软件组件（通常指的是原子软件组件 - Atomic Software Component）可以细分为应用软件组件（Application Software Component）和传感器-执行器软件组件（Sensor-Actuator Software Component）。本文考虑与 Simulink 建模的相关性，只讲应用软件组件。如果传感器-执行器软件组件也用 Simulink 建模实现，可以参照应用软件组件开发方法，在 Simulink 建模层面不强调其差异性。

不管在 ISO 26262 还是 AUTOSAR 中，对于软件单元在层次化结构中的具体定位都没有明确规定，实践中通常根据具体软件架构以及应用复杂度而定。

在 ISO 26262 架构下，如果某个软件组件功能独立而且实现简单，它本身就可以是一个软件单元；如果功能复杂，则可以进一步划分为几个软件单元。

在 AUTOSAR 中情况类似：一个应用软件组件可以只包含一个（也可能是几个）运行实体，而且功能简单，那么这个应用软件组件本身就可以使一个软件单元；如果包含多个运行实体而且功能较为复杂，每个运行实体可以是软件单元；如果某些运行实体的功能非常复杂，则可以进一步将一个运行实体划分为几个软件单元来实现。

在 Simulink 中，功能划分体现在：将模型虚拟分组来创建抽象层；根据调度需求将模块（block）分组；利用模型引用（Model Reference）来控制模型的规模。具体的软件分层类似于以上提到的 AUTOSAR 中的分层。软件单元通常要求为独立模型，以便于单独开发、验证以及管理。其他层次根据复杂度而定。

下图给出了一个 ISO 26262、Simulink、AUTOSAR 三者的映射关系示例：

该示例表示的是最为复杂的一种情况：一个应用软件组件包含多个复杂运行实体，而运行实体进一步划分，有多个软件单元模型实现。从上到下都是通过模型引用的方式逐级展开。以下各个章节都是基于这种情况示例。

软件单元（Software Unit）

MathWorks建议

使用 Simulink模型来表达软件单元

相比于子系统库而言，一个模型有自己的仿真及代码生成配置参数，可以单独仿真、测试以及增量式生成代码。由于模型的使用，多个软件单元可以并行开发，并且在配置管理系统中可以单独管理。

MathWorks建议

使用模型引用（Model Reference）集成软件单元

顶层模型（集成模型）只是一个整体框架，具体的各个软件单元通过模型引用连接。在这种架构下，利用 Simulink 本身的模型更新（快捷命令 Ctrl+D）功能，可以很容易地完成软件单元集成后的静态验证。可以检查软件单元之间的接口是否匹配，可以检查软件单元模型与顶层集成模型配置参数的兼容性（例如解析器的选择、硬件相关设置等）从而保证代码生成的一致性。

运行实体（Runnable）内部软件单元（SU）的集成

在顶层模型这一层，Simulink 模块可以显示软件单元的模型信息以及数据流和模块执行顺序。

MathWorks建议

使用模型引用的方式测试软件单元

通过顶层模型（Top Model。也可称之为测试框架 – Test Harness）引用软件单元模型的方式来进行单元测试（Unit Test）。单元测试的基本要求之一是测试人员不可以修改被测单元（不管是模型还是代码）。所以要建立测试框架，输入激励信号以及输出的观测都要在测试框架环境下完成。对于模型，可以采用模型引用（Model Reference）实现被测模型与测试环境的独立。

模型 SU1 进行 PIL 模式单元测试的框架模型

一个软件单元模型可以在多种模式下测试验证：

正常仿真模式（Normal Mode）

模型在环（Model-in-the-loop -- MIL）

软件在环（Software-in-the-loop -- SIL）

处理器在环（Processor-in-the-loop -- PIL）

上图所示的测试框架模型可以由 Simulink 软件自动生成（上图由 Simulink Test 生成，也可以根据实际需要，由 Simulink Verification and Validation 或者 Simulink Design Verifier 生成类似的测试框架）。工程师只需要根据功能需求，输入测试用例（测试数据或测试序列）即可。

同样的测试框架模型以及测试用例可以在各个测试阶段重复使用：

模型阶段 – 正常仿真模式或模型在环 – MIL

在 PC 机上验证生成的代码 – SIL

在目标处理器上验证生成的代码 – PIL

Simulink 自带的仿真数据观测器（Simulation Data Inspector）可以很方便的完成测试数据观测及分析：

不同测试用例数据（输入或输出）图形化显示或对比

不同测试阶段结果对比（比如 MIL 和 SIL 对比，MIL 和 PIL 对比等）

用仿真数据观测器分析数据

此外，Simulink Design Verifier还可以帮助工程师生成一些特定目的的测试数据来提高测试覆盖度。

AUTOSAR运行实体（Runnable）

MathWorks 建议

使用函数调用子系统（Function-call Subsystem）

描述运行实体

AUTOSAR 当中，一个运行实体（Runnable）是指一个原子软件组件（AUTOSAR Atomic Software Component）提供的最小代码段，同时也是一个可以被单独调度的任务。函数调用子系统提供了调度控制机制，可以很容易地实现模型各个部分周期性或非周期性的调度控制。

函数调用子系统描述运行实体

每个函数调用子系统由一个或几个互相连接的软件单元（如图：运行实体内部软件单元的集成）组成。运行实体间数据交互的完整性采用AUTOSAR 运行实体间变量（Interrunnable Variable，简称IRV）机制来保护。因为所有函数调用由一个统一的触发源产生，所以仿真的时候不会产生数据完整性问题。

软件组件（Software Component）

对于应用层软件来说，ISO 26262当中的软件组件（SWC）对应于 AUTOSAR 中的应用软件组件（ASWC）。

MathWorks建议

采用独立模型来描述AUTOSAR应用软件组件(ASWC)

在一个Simulink模型里将一个软件组件对应的所有函数调用子系统封装起来，在用Embedded Coder生成代码时，这些函数调用子系统会自动映射到相应的运行实体（Runnable）。

MathWorks建议

要对应用模型架构与AUTOSAR 的兼容性进行验证

在架构设计的早期，工程师可以只创建运行实体（Runnable）模型框架，其中的软件单元（Software Unit）为空模型（只有顶层输入及输出，内部没有逻辑及连接，如下图所示）。

空白的软件单元模型

Embedded Coder（要求包含 AUTOSAR 支持包）可以分析模型架构，确认各个应用软件组件（ASWC）是否可以根据 AUTOSAR（指定版本）的要求正确地访问数据接口以及是否可以正确地使用运行实体间变量（IRV）。

AUTOSAR 接口配置验证

软件单元（Software Unit）集成完成之后，在应用软件组件（ASWC）生成代码之前，可以利用 Embedded Coder 分析模型的 AUTOSAR 符合性，包括软件单元（Software Unit）建模正确性分析，比如数据的耦合性检查、全局数据存储检查、全局跳转模块检查等等。

Embedded Coder 在生成 C 代码的同时，还会生成对应的 arxml 文件，该文件符合指定的 AUTOSAR 版本，可以导入到外部 AUTOSAR 编辑工具（AAT）进一步完成系统级集成。

MathWorks建议

在 Simulink 环境下完成

AUTOSAR应用软件组件的测试验证

应用软件组件（ASWC）这一级的集成测试可以完全在 Simulink 的环境下完成。

为了验证生成的源代码，Embedded Coder 将生成的代码编译打包成 S 函数（S-Function），创建软件在环模块（SIL block）。由于选择了 autosar.tlc 作为系统目标文件（System Target File），S 函数运行所需要的 AUTOSAR RTE 接口会自动配置（不需要RTE代码生成）。

软件在环（SIL）和处理器在环（PIL）模块可以在原始模型测试环境下直接替换被测模型（采用模型引用配置）。

同一测试环境完成不同测试

软件组件（Software Component -- SWC）的层次化结构

MathWorks建议

用虚拟子系统描述应用抽象层

ISO 26262 建议采用层次化的结构来组织软件组件（参照 ISO 26262-6 第 7 章）。在AUTOSAR 中，应用软件组件（ASWC）集成在一起称为组合（Composition）。在 Simulink 中，采用虚拟子系统对功能模块进行分组，从而实现抽象层的概念。组合（Composition）加上被控对象模型（Plant Model），可以仿真运行整个应用系统（下图省略了调度部分）。

系统级模型

在组合层次采用模型引用来集成软件组件：

组合模型引用软件组件模型

应用软件调度

ISO 26262 要求指定每一个算法块的调度方法及执行顺序。

运行实体（Runnable）内部软件单元（SU）的执行顺序

MathWorks建议

如果没有对具体数据的依赖性，要将执行顺序显示出来

在函数调用子系统（Runnable）内部，Simulink可以显示每个模型（软件单元 - SU）的执行顺序（参考上图：运行实体内部软件单元的集成）。如果模型之间存在数据依赖，Simulink可以自动判断并设定执行顺序。如果没有依赖，Simulink根据输出端口编号给出推荐的执行顺序，用户可以通过优先级选项修改执行顺序。

运行实体的调度（Scheduling of Runnables）

MathWorks建议

使用Stateflow 或MATLAB模块创建集中的调度器

Simulink 中的函数调用子系统由函数调用事件（Function-call Event）触发。可以产生触发事件的模块有 Stateflow、MATLAB 模块及函数调用生成器（Function-call Generator）。为了清楚表达所有软件单元复杂的调度关系，建议使用 Stateflow 状态图。

Stateflow 实现集中化调度示例

在Stateflow中，时间逻辑（Temporal Logic）可以用来产生周期性触发事件，数据输入端的转移条件可以用来产生非周期触发事件。每个并行状态右上角的数字显示了该状态的执行次序。每个状态里的事件列表定义了触发的先后顺序。

应用层通常有许多触发事件。为了提高效率，可以用 MATLAB 脚本自动创建这样的调度器，并且自动连接到相应的函数调用子系统。

软件集成人员在 AUTOSAR RTE 中进行运行实体（Runnable）的运行任务分配时，可以参照用 Stateflow 描述的任务调度。反过来，也可以参照 RTE 中的任务分配调度，设计 Stateflow 调度器。

应用层软件接口

ISO 26262 要求完整定义软件单元（SU）及软件组件（SWC）之间的接口。

ISO 26262 建模标准检查（Model Advisor）可以验证软件单元建模的合规性。通过运行模型更新检查功能，Simulink 引擎自动检查接口连接及数据定义的正确性。Embedded Coder（包括 AUTOSAR 支持包）可以用来确认应用软件组件（ASWC）接口定义是否完整以及是否符合 AUTOSAR 的要求。

Simulink 软件提供的工具链（主要用到算法开发类、测试验证类、代码生成类等工具箱）以及开发方法可以很好地满足符合 ISO 26262 及 AUTOSAR 要求的应用软件开发。