[Simulink] 用 Simulink 开发符合 ISO26262 和 AUTOSAR 的应用软件

转载自MATLAB微信公众号文章，链接如下：https://mp.weixin.qq.com/s/b2-19RnNFzYc12dyEXDJ_g## ，仅做个人学习笔记记录，如有侵权，立即删除。

作者：李智慧

参考ISO26262的要求，同时考虑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）。这里只针对ASWC进行说明。

在Simulink中，功能的划分体现在：

• 将模型虚拟分组来创建抽象层
• 根据调度需求将模块分组
• 利用模型引用来控制模型的规模

具体的软件分层类似于AUTOSAR中的分层，软件单元通常要求为独立模型，一遍于单独开发、验证与管理。

ISO 26262、Simulink、AUTOSAR 三者的映射关系示例：

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

Simulink与AUTOSAR之间的映射关系表：

Simulink	AUTOSAR
虚拟子系统	原子软件组件
原子子系统	可运行实体
被触发的原子子系统	RTE事件激活的可运行实体
Simulink端口	软件组件的接口

软件单元 Software Unit

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

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

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

使用模型引用的方式测试软件单元
通过顶层模型（Top Model。也可称之为测试框架 – Test Harness）引用软件单元模型的方式来进行单元测试（Unit Test）。

单元测试的基本要求之一是测试人员不可以修改被测单元（不管是模型还是代码）。

所以要建立测试框架，输入激励信号以及输出的观测都要在测试框架环境下完成。
对于模型，可以采用模型引用（Model Reference）实现被测模型与测试环境的独立。

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

• 正常仿真模式（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

使用函数调用子系统（Function-call Subsystem）描述运行实体
AUTOSAR 当中，一个运行实体（Runnable）是指一个原子软件组件（AUTOSAR Atomic Software Component）提供的最小代码段，同时也是一个可以被单独调度的任务。

函数调用子系统提供了调度控制机制，可以很容易地实现模型各个部分周期性或非周期性的调度控制

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

挖坑，运行实体间变量IRV？

软件组件 software component

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

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

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

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

上图为一个空白的软件单元模型

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

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

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

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

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

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

软件组件SWC的层次化结构

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

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

上图为省略了调度部分的系统级模型

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

上图为组合模型引用软件组件模型

应用软件调度

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

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

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

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

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

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

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

stateflow实现集中化调度示例

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

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

挖坑： 如何用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 要求的应用软件开发。

参考文献：
【1】与AUTOSAR兼容的Matlab/Simulink自动代码生成技术[D]