MBD讲解与实践 1.1 AutoSAR、ASPICE与MBD

本篇文章主要介绍汽车电子领域的两个技术规范：AUTOSAR与ASPICE，并讲解一下我们在MBD开发中与他们的关系。首先，并不是所有整车厂或者零部件厂都会涉及，目前只有部分乘用车市场，特别是面向欧洲整车厂的乘用车零部件软件开发会涉及比较多。关于AUTOSAR与ASPICE也不是本文的重点介绍对象，读者只需了解即可。

一、AUTOSAR与MBD

1.1 AUTOSAR简介

AUTOSAR (AUTomotive Open System ARchitecture，汽车开放系统架构) 是行业领先的汽车制造商和供应商于2003年秋季提出的标准化倡议。--摘自Vector官网

我们把AUTOSAR理解成一种规范化的软件架构即可，它把ECU软件分为几个层级：ASW(应用层)、RTE(运行时环境)、服务层、抽象层(ECU抽象、微控制器抽象)、复杂驱动，其中除了ASW和RTE，统称BSW(基础软件)。

AUTOSAR的大部分功能都在BSW，我们MBD开发只需关注ASW和RTE相关的知识即可，对其他部分感兴趣的朋友可以去查阅一下详细介绍AUTOSAR的相关文章。

1.2 应用层与组件

通过本节最开始的示意图可以看到，应用层(Application Layer)只与RTE(Runtime Environment)相邻，因此，应用层的数据传输只在内部或ASW-RTE之间进行。

那么，应用层内部是怎样的呢？请看下图：

 

应用层由ASW SWC(Software component)组成，多个软件组件构成应用层的全部功能逻辑。AUTOSAR中的一个组件，通常对应代码中的一个.c文件或MBD开发中的一个模型。组件内部还能够细分为一个或多个Runnable，通常对应代码中的一个函数或MBD开发中的顶层Subsystem。Runnable的触发方式有多种，如初始化、周期、CS接口调用等，应用层常用的有初始化和周期两种。

1.3 RTE与接口

上图中，可以看到组件之间的虚线连接，代表组件之间的数据传输，那么数据传输的具体方式是怎么实现的呢？

组件之间、应用层与其他层级之间的通信，全部是通过软件接口(Interface)完成。通过上图也可以发现，无论是组件之间的数据交互，还是ASW与BSW之间的数据交互，都是通过RTE实现的，具体实现方式和代码后续会文章说到，此处不展开。常用的软件接口又两种：

1. SR Interface(Sender-Receiver)：可以简单地理解为数据传输，应用层大多用SR接口，简单明了。
2. CS Interface(Client-Service)：可以简单地理解为函数调用，调用其他组件的Runnable。

组件内部数据传输，即不同Runnable之间的数据传输不采用接口，也不经过RTE，而是采用IRV(Internal Variable)内部变量完成。

1.4 Arxml文件

到这里，有的读者可能有疑惑了，前面讲了一堆AUTOSAR相关的，但是一点也没有讲到MBD呀！

别急，这个小结就能将上面的一堆东西与MBD串联起来。

首先，我们要了解到Arxml文件这一文件格式，这是一种基于xml格式，专用于AUTOSAR的描述文件，基于AUTOSAR架构开发的所有软件结构(包括数据类型、组件定义、底层软件配置等)都能通过Arxml文件描述。

那么，我们将AUTOSAR与MBD结合的方式就找到了，首先基于AUTOSAR设计ASW软件架构，得到每一个组件的组件描述(组件名称、Runnable、接口、数据类型等)，通过AUTOSAR工具生成相应的Arxml文件与RTE文件。而Matlab支持直接将SWC的Arxml文件转化为空模型，具体实现方式后续的章节会详细讲解。

 

 从架构设计到Arxml文件，可能会用到专业的架构设计软件(如Vector DaVinci Developer)，或公司内部开发软件或定制软件，方式多种，朋友们根据实际情况处理即可。

二、ASPICE与MBD

2.1 ASPICE简介

Aspice（Automotive SPICE）中文翻译为汽车软件过程改进及能力评定。是为保证软件质量的规范，要求供应商按照Automotive SPICE的要求进行产品的设计与开发。是汽车行业中常用于质量管理的工具。

对于ASPICE，我们可以简单地理解为，按照规范，在特定的软件开发节点完成对应的活动(软件开发相关活动指上图中SWE.1-SWE.6)并输出技术文档，其中SWE.2-SWE.4与MBD开发是强相关的，SWE.6与MBD部分相关。

此处不展开讲解，感兴趣的朋友可以直接去ASPICE官网下载规范详细阅读。

2.2 软件架构设计

软件架构设计是软件需求分析之后的一个活动，此活动的输出物为软件架构设计规范或称软件架构设计说明书。在软件架构设计规范中，需要定义出每一条需求是怎么通过架构实现的，以及软件架构的各个要素(组件、接口、调用关系、数据传输方向、调度周期、内存分配等)。

与应用层强相关的就是SWC的定义了，在这个活动中，每个SWC被清晰地定义出来，通过架构设计软件生成对应地Arxml文件，给到下一个活动。

2.3 软件详细设计和单元构建

在软件架构设计完成之后，是不是就可以开始搭模型了呢？

并不是，因为中间还有一个软件详细设计的过程，软件单元构建才是我们搭模型的过程。当然，这两个过程在ASPICE中是同一个活动，先后顺序并没有强制要求，有很大部分公司都弱化了软件详细设计这一过程，或则选择事后补文档。

那么软件详细设计到底要完成哪些工作呢？

软件详细设计过程最重要的输出物就是软件详细设计规范了，在这个文档里面，定义了软件架构中的描述的功能，具体被哪些软件单元所实现、软件单元之间的数据交互、每个软件单元的实现方式。其实就是在我们动手搭模型之前的一个构思，当然有的整车厂要求比较严格，会十分细致地审视供应商地软件详细设计过程是否按规范完成。

当软件详细设计过程完成之后，模型的设计也就是单元构建也就水到渠成了，只需要根据软件详细设计规范中定义的软件单元实现方式，通过Matlab/Simulink搭建模型即可。

2.4 软件单元验证

软件单元验证，顾名思义就是验证上述活动中输出的模型是否满足软件详细设计。单元验证分两个部分：静态验证和动态测试。

1. 静态验证：主要通过静态扫描的方式，分析模型是否满足各种设计规范(MAAB、ISO26262、MISRA C)、有无除零溢出等其设计缺陷。
2. 动态测试：通过设计测试用例，基于Matlab动态仿真，测试软件单元的逻辑功能是否与软件详细设计中描述的一致。

软件单元验证输出物为验证报告，一般通过定制单元验证工具完成，Simulink也有自带的单元验证功能。此活动的主要工作量在于测试用例的编写，一般是不同的软件开发者交叉验证或由组件开发者本人完成此项活动。

2.5 软件集成测试

软件集成测试活动主要是在软件集成编译之后，在单板环境实际跑测试用例来完成，用于测接口完整性。基于MBD开发方式，可以通过模型层面的集成，进行部分的仿真验证工作，找出后续需要通过HIL测试等手段才能测出的问题。

本篇内容对于没有接触过AUTOSAR和ASPICE的朋友来说可能有些空洞，没关系的，下一篇我们用一次实践来练习一下。