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方法可能无法完全覆盖所有细节，需要开发者结合文档与经验进行手动调整；因此可选择性的交流本文的开发思路，而非具体的配置项。
来源：汽车电子与软件
