作者 | 不可说

出品 | 汽车电子与软件

#01

引 言

本文基于SDV发展背景，剖析了一份AUTOSAR AP软件架构。包括其主要组成部分、层次结构以及各层之间的交互关系。为了验证该软件架构的可行性与有效性，计划进行模拟部署测试。

同CP平台一样，MATLAB/Simulink通过AUTOSAR Blockset工具箱对AP平台也有了一定的支持，本文将解析下Simulink中AP的模型架构以及进行简单的部署仿真测试。

#02

AP模型导入与服务接口分析

1）模型准备

首先准备一下模型文件，该模型文件来源于MATLAB Example；

里面含有一个总括的模型文件：HeadLightControlSystem.slx；三个模型引用的文件：HeadLightActuator.slx、HeadLightController.slx、OutdoorLightSensor.slx以及数据字典：HeadLightControlSystemData.sldd

可以通过下述命令行找到对应的模型示例文件：

open_system("HeadLightControlSystem")；

打开总模型文件：HeadLightControlSystem

这个架构模型有三个组件，OutdoorLightSensor、HeadLightController和HeadLightActuator。OutdoorLightSensor处理从传感器接收到的数据，并使用自适应事件（adaptive events）将数据发送到HeadLightController。HeadLightController调用HeadLightActuator中的方法，使用自适应方法（adaptive methods）打开或关闭前照灯。HeadLightActuator根据从HeadLightController接收到的输入打开或关闭汽车头灯。

OutdoorLightSensor 上的名为SensorData的port类型是Output，对应的HeadLightController上的SensorData的port类型是Input；Interface类型是SensorDataIntf；

HeadLightController上的名为HeadLight的port类型是Client，对应的HeadLightActuator上的HeadLight的port类型是Server；Interface类型是HeadLightIntf；

下面是针对每个模块的具体分析；

2）OutdoorLightSensor分析

OutdoorLightSensor内部模块与逻辑比较简单，将一个常量OutdoorLightData信号通过Event Send模块转换为message消息，通过“Bus Element Out”端口发送出去；Event Send模块功能是将信号转换为保留信号值和数据类型的事件，专门服务于AP的模块；

打开数据字典：

该模块包含一个Service Interfaces，名为SensorDataIntf，也就是我们从模型概览中看到的port对应的Interface类型；该Service Interfaces只包含一个Event事件，事件接口名为LightData；

该AP应用模块只包含一个ProvidedPorts，名为SensorData，对应上面的Service Interfaces；

这两部分的配置可以理解为，一个名为SensorDataIntf的服务，只包含一个Event事件，在OutdoorLightSensor模块中实例化为一个Provided类型服务，对外部模块（HeadLightController）提供服务，对应服务port名为SensorData；

在Simulink模型中，开发者会构建各种模块以代表不同的系统组件和功能。这些模块在映射到AUTOSAR时，需要对应到AUTOSAR软件组件（SWC）、端口（Port）、数据元素（Data Element）等概念上。通过映射，Simulink中的设计能够转化为AUTOSAR架构下的实现，进而在ECU（电子控制单元）上运行。

因此有如下图的Simulink模块和Autosar元素的map关系：

名为LightData的Bus Element Out Simulink模块关联了名为SensorData的Autosar Provided Port中包含的LightData事件。

3）HeadLightController分析

该子系统内又包含了一个消息出发的子系统，这个消息触发源，对应的Bus Element In1，接收的就是OutdoorLightSensor发过来的SensorDataIntf服务中的LightData事件消息；

打开Message Triggered Subsystem：

内部包含一个函数调用系统（其实函数原型是服务的port名加上服务里的方法及对应参数构成）。因此从模型上看，该模块又包含了其他服务的Method方法，并且该模块是作为服务的客户端去调用该服务的方法；

打开该模块的数据字典：

里面包含两个Interfaces，SensorDataIntf与HeadLightIntf两个服务，SensorDataIntf服务与上面OutdoorLightSensor包含的是一致的，只不过这里是作为Client端实现的；

HeadLightIntf这个服务包含了一个setHeadLight方法，该方法只有一个输入参数，lightStatus，因此可以理解为该方法对应的通信类型就是Fire-Forgot类型，只有请求参数，无返回参数。

HeadLightController包含两个RequiredPorts，一个是与OutdoorLightSensor通信的SensorData port，请求LightData事件数据的，另一个HeadLight，是请求HeadLightActuator设置灯光状态的setHeadLight方法；

这部分的配置可以理解为，HeadLightController包含两个服务的客户端，一个名为SensorDataIntf的服务，只包含一个Event事件，在HeadLightController模块中实例化为一个Required类型服务，对外部模块（OutdoorLightSensor）请求服务，对应服务port名为SensorData；另一个名为HeadLightIntf的服务，只包含一个Method-FF方法，在HeadLightController模块中实例化为一个Required类型服务，对外部模块（HeadLightActuator）请求服务，对应服务port名为HeadLight；

查看这一部分Simulink模块和Autosar元素的map关系：

名为HeadLight的Bus Element In2 Simulink模块关联了名为HeadLight的Autosar Required Port中包含的LightData事件。

名为LightData.setHeadLight的Bus Element In1 Simulink模块关联了名为HeadLight的Autosar Required Port中包含的setHeadLight方法。

4）HeadLightActuator分析

里面又包含一个函数子系统，不过，从这个层级也可以看出该函数就是服务HeadLightIntf中的setHeadLight方法；

打开子系统，里面展示了函数的输入参数以及还有一个函数子系统；

再打开该函数子系统，里面封装了了AP AUTOSAR的ara::log模块，这个我们后续仿真的时候可以观测到。

打开数据字典：

里面包含一个Interfaces，HeadLightIntf，上面HeadLightController包含的是一致的，只不过这里是作为Server端实现的；

HeadLightActuator包含一个ProvidedPorts，是与HeadLightController通信的HeadLight port，提供设置灯光状态的setHeadLight方法；

这部分的配置可以理解为，一个名为HeadLightIntf的服务，只包含一个Method方法（setHeadLight），在HeadLightActuator模块中实例化为一个Provided类型服务，对外部模块（HeadLightController）提供服务，对应服务port名为HeadLight；

打开Simulink模块和Autosar元素的map关系：

名为LightData.setHeadLight的Bus Element Out1 Simulink模块关联了名为HeadLight的Autosar Provided Port中包含的setHeadLight方法。

#03

部署与测试

1）部署目标环境

AUTOSAR AP应用是跑在Linux系统上的，因此需要Linux环境的虚拟机或者服务器，要求可以通过SSH连接，并且知道其IP；测试ip：192.168.24.92；

并且要安装Docker；Docker镜像是一个特殊的文件系统，包含了容器运行时所需的程序、库、资源、配置等文件，以及为运行时准备的一些配置参数（如环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。镜像使用分层存储技术，使得镜像的复用、定制变得更为容易。容器是镜像运行时的实体，可以被创建、启动、停止、删除、暂停等。容器的实质是进程，但与直接在宿主执行的进程不同，容器进程运行于属于自己的独立的命名空间，拥有自己的root文件系统、网络配置、进程空间等。这种隔离性使得容器封装的应用比直接在宿主运行更加安全。

这里要做这个模拟部署，Docker是必须的，因为MATLAB是要通过XCP连接，创建Docker镜像，AP应用运行在该镜像实例化的容器内。

2）模型配置

对OutdoorLightSensor子系统进行配置

代码生成→ 接口→ external mode(外部模式)勾选上

硬件实现要配置为：Embedded Coder Linux Docker Container

配置XCP服务器，输入目标机的IP；

3）部署模拟

打开Linux运行时管理器

输入配置信息，并Connect；如果之前并未连接过该Linux环境，Connect会失败，需要点击旁边的Update Target，这步骤就是将模拟部署需要的镜像matlab-ecoder-linuxruntime-image发送过去，这一步骤时间可能较长；如果之前连接过该Linux环境，进入该界面后会自动连接上；

配置，目标APP在目标Linux环境下的安装位置；选择一个仅自己使用的文件系统下就好；

点击Creat&Deploy Application Package，选择子系统slx文件；三个子系统重复这个操作；

编译子系统，生成mldatx文件，发送到Linux环境中，自动部署；

对Sensor这个app启动Monitor&Tune，对Controller和Actuator这两个app启动 Start Application；将三个应用都启动，并观测；

因在Actuator模块中封装了ara::log模块，所以从log上可以看到对应灯光状态值为1；

修改Sensor模块中输入的lightData，使其大于5，从log中可以看出此时灯光状态值变为了1；

从Linux环境中也可以看出正在运行的matlab linux环境下的 ecoder image；

同样，也可以查看上面三个模块app对应的进程。

#04

小 结

本文详细的剖析了一个AUTOSAR AP应用层模型，想要全面揭示其AP架构设计背后的逻辑与精髓，分析其各个核心元素含义，这些元素作为AUTOSAR AP模型构建的基础，包括但不限于软件组件（SWCs）、服务、服务接口、通信Port以及数据管理机制（如客户端-服务器模式的数据访问）并且解析了与Simulink模型的对应关系；

后面又搭建环境，部署应用，测试了模型的逻辑性，这一过程不仅验证了模型设计的正确性，也体现了AUTOSAR AP平台在实际开发中的灵活性与高效性。

这个过程体现了AUTOSAR AP平台的一种开发方法，基于MBD的开发带来了一定的直观性的便利，但在面对复杂的AUTOSAR AP元素配置时，其直接性仍有待提升。特别是当涉及到大量细致的配置项时，MBD方法可能无法完全覆盖所有细节，需要开发者结合文档与经验进行手动调整；因此可选择性的交流本文的开发思路，而非具体的配置项。

/ END /

投稿请添加公众号管理员微信：btighteast