出品 | 汽车电子与软件
AUTOSAR AP平台通过提供高性能计算与通信能力、灵活性和可扩展性、OTA支持、实时性与安全性保障以及渐进部署与动态管理等功能,解决了CP平台在面对现代汽车电子系统快速发展时所面临的一系列问题。这些改进使得AP平台能够更好地满足汽车制造商和供应商对汽车电子系统开发的需求,推动汽车电子系统的不断升级和创新。
本文计划基于MBD方式,从零开始搭建一个AP模型,该模型能够清晰地表达AP架构的服务通信架构、逻辑控制流程、输入输出关系以及各组件间的交互机制,实现简单的逻辑控制,并生成代码分析下这种方式对于AP的开发利弊,供参考讨论。
在AP AUTOSAR架构中,集成了多样化的接口与服务体系,涵盖通讯、日志记录、诊断等多个方面,共计十余个功能模块协同工作,共同构筑起一个功能完备的层级结构。这些接口与服务的核心价值在于赋能OTA的实施、促进运行时环境的动态配置调整与服务的发布/发现,并显著增强了对高性能车载软件在计算能力与数据处理速度上的支持能力。通讯模块(Com)设计基础在于两种主流的通讯标准:SOME/IP与DDS。
起初,DDS在除汽车行业外的多个领域内展现了广泛的应用潜力,而现如今,它也正逐渐吸引汽车行业内的瞩目。本质上,DDS作为一种中间件技术,其核心理念在于从复杂的网络架构、多样化的数据格式及操作系统细节中剥离应用逻辑,转而聚焦于数据本身,实现高度的数据中心化。它运作的核心机制是基于发布/订阅模式,确保数据能够在不同的网络节点间高效、灵活地传递,同时,该通讯方式同样有对动态服务发现的支持,进一步增强了其在复杂系统环境中的适应性和可扩展性。
DDS中间件
目前呢,几个较新版本的MATLAB对SOME/IP和DDS通信方式都有一定的支持,并且对于软件架构和软件模型,可以自动生成对应的C或C++代码。
那Simulink如何来支持面向服务的架构?前面也提到了一个关键概念是面向服务的通讯。应用服务是通过中间件进行发送和接收来实现通讯的。通讯里面最基本的元素是消息,它包含了事件和数据,在Simulink中,可以使用消息对面向服务通讯进行建模。
服务中的消息通讯
可以使用消息和事件库中的一些特定块、基础模块来发送和接收消息。以及配置和使用消息队列,也可以查看仿真过程中跨模型交换的一些消息序列。同时也可以为C/C++代码生成配置接口,以便你生成的代码可以集成到所选择的中间件中。
因此,可以继续使用Simulink模块对应用的算法进行建模,甚至为这些新的应用重用一些已有的模型。降低重复开发的工作量,提升开发效率。
现在较新的MATLAB版本可以在总线路由多条消息,也可以将队列总线一起使用。也可以使用消息和事件库中的合并功能将多条消息进行合并,变成一条。
Simulink也支持事件的记录和动画功能,可以用来查看模型中函数调用子系统、Simulink消息、函数模块的事件、还可以进行动画的设置。因此这些功能是可以帮助我们更好的去理解复杂系统。
要搭建AP模型,首先要做下AP服务设计及SWC软件架构设计,本次计划实现一个氛围灯功能,分为两个SWC模块,首先是一个氛围灯原子模块,负责氛围灯开闭状态反馈及开闭、颜色控制,再一个是氛围灯基础模块,负责氛围灯的模式控制及反馈,对外部控制器提供这些能力,当然,他也需要调用氛围灯原子模块的功能来实现自身的功能;
因此计划设计两个SWC:氛围灯原子模块AmbiAtomicSWC与氛围灯基础模块AmbiBasicSWC,AmbiAtomicSWC对外提供AmbiAtomic服务,AmbiBasicSWC对外提供AmbiBasic服务,自身也需要调用AmbiAtomic服务;
设计的服务/Interface以及服务内接口/Element元素如下表内容:
功能 | 服务 | 接口描述 | 接口 | 参数 | 参数类型描述 | 参数类型 | 参数范围 |
氛围灯 | 氛围灯原子服务 AmbiAtomic | 开闭控制 | setAmbLiOnOffReq | 入参:switchSts 出参:result | 开闭类型 | Uint8 | 0:关 1:开 |
开闭通知 | onAmbLiOnOffChange | 返回类型:switchSts | 开闭类型 | Uint8 | 0:关 1:开 | ||
颜色控制 | setAmbLiColorReq | 入参:color | 整型 | Uint8 | 1:颜色1 2:颜色2 | ||
氛围灯基础服务 AmbiBasic | 模式控制 | setAmbLiModeReq | 入参:mode | 模式类型 | Uint8 | 0:关闭 1:模式1 2:模式2 | |
模式通知 | onAmbLiModeChange | 返回类型:mode | 模式类型 | Uint8 | 0:关闭 1:模式1 2:模式2 |
#04
首先要依据Autosar软件架构模板创建个AP模型画布,如下:
创建模板
模型默认是CP架构的,要切换到AP架构;
创建两个AP Component,按照上面设计的SWC进行重命名,构建并填充好端口名,暂时以SOA服务名作为端口名,注意端口是Client/Server类型;
在SWC模块上,右键选择Creat Simulink Behavior,将其转换为Simulink元素;
转换为如下的模型,AmbiAtomic服务默认生成了一个函数调用子系统,AmbiBasic服务默认生成了一个函数调用子系统以及一个function caller;
接下来需要进行服务数据的设计填充,打开Autosar字典分别对两个SWC进行配置;
AmbiAtomic服务是根据外部创建的AmbiAtomic端口同名生成的,这里不做修改也可以,不过默认的ProvidedPorts里面的Instance Id并未配置,这里手动给配置为1;
按照接口表手动修改默认生成的f1方法,最后变为两个Method方法,一个Event事件;
下一步就是在Simulink界面中配置与刚才设计的AUTOSAR元素对应的Simulink模块,这也是Simulink搭建AUTOSAR模型的硬性要求,所有元素都必须一一匹配;
首先修改原有的f1函数,修改后的函数名为AmbiAtomic服务中的一个Method方法名,修正对应的入参及出参,同时修改对应的bus element out的名称,格式为port.method,这里为:AmbiAtomic.setAmbLiOnOffReq;
添加该服务里另一个Method setAmbLiColorReq;
添加该服务里的Event onAmbLiOnOffChange;
对于服务的Server端,提供Event事件需要使用message send模块,但是必须存在于函数子系统中,对于函数输入端口,也要勾选上“输出函数调用”
最后检查下Simulink元素和Autosar元素的映射关系,不能有未map的,如有可以补上;
到这里,相当于完成了AP架构设计部分,最后添加一点实现逻辑的软件单元:
客户端可以调用服务中setAmbLiOnOffReq与setAmbLiColorReq方法,存储(设置)氛围灯开闭及颜色,并且调用setAmbLiOnOffReq设置开闭时,调用成功时会回复1,同时,AmbiAtomicSWC作为AmbiAtomic服务的服务端,会把氛围灯开闭状态通过Event事件通知到客户端;最后这部分AP模型呈现如下:
首先也是要修改Autosar字典数据内容,AmbiBasicSWC一共包含两个服务:AmbiBasic与AmbiAtomic,分别对应进行Server端和Client端的实例化,注意,simulink这里不允许具有一样的Instance Id,即便是不同服务的不同port,还不理解为什么不允许这样……
其余配置都按照服务设计的内容来就行;
AmbiBasicSWC中AmbiAtomic服务配置
AmbiBasicSWC中AmbiBasic服务配置
下一步同样在Simulink界面中配置与刚才设计的AUTOSAR元素对应的Simulink模块,首先配置AmbiBasic服务作为Server端的内容,这一部分与AmbiAtomicSWC配置方式基本一致,具体细节就不展开了;
对于AmbiAtomic服务的客户端配置展开说下,要实现对服务内的两个Method方法的调用,以及Event事件消息的接收;
对Method的调用需要使用FunctionCaller模块,对Event事件的接收需要使用到Message Receive模块,该模块是从收到的消息中提取数据并写入输出信号端口。如果模块执行时没有新消息,则模块或者写入默认数据,或者保留从最后一条消息中读取的数据。
检查下Simulink元素和Autosar元素的映射关系,不能有未map的,如有可以补上;
到这里,相当于完成了这部分的AP架构设计部分,最后添加一点实现逻辑的软件单元:
允许有AmbiBasic的客户端,调用AmbiBasicSWC中的AmbiBasic服务端,进行氛围灯模式的设置,并且把模式状态返回回去;同时,再通过AmbiAtomic客户端解析氛围灯模式,调用服务中setAmbLiOnOffReq与setAmbLiColorReq方法,对服务端设置氛围灯开闭及颜色,并且接收关闭状态消息,完成简单的逻辑闭环控制。
最后这部分AP模型呈现如下:
最后模型呈现如下;
生成的文件如下:
ambiatomic_skeleton.h 内部定义了SOA服务的服务端行为,比如服务发布、停止发布、Event事件,Method行为等。
AmbiAtomicSWC.cpp内则是服务内Event、Method行为模型对应的代码;
AmbiAtomicSWC.cpp内的初始化动作也可以关注下:
AmbiBasicSWC生成的代码文件稍微多一些,因为他既有服务的客户端(Proxy),也有服务的服务端(Skeleton);
Proxy内容大致如下:
AmbiBasicSWC.cpp初始化函数中也加入了服务发现的find部分代码;
本文设计了含有两个SWC、两个SOA服务的AUTOSAR AP软件架构,建立了AP模型对应的Simulink模型,分析了模型中的AUTOSAR AP元素,最后也成了AP平台的C++代码。
但是,也存在着不少信息是在当前Simulink环境下没办法进行配置,比如SOA服务的服务ID,服务Method、Event等接口的通信ID、没有办法去选择AP平台的通信方式,是SOME/IP还是DDS等,服务的部署信息等也没有相应模块可以配置,因此该Simulink工具箱还有蛮大的上升空间;目前来说,还是Vector系列的AP工具更为常用些,当然,如今不少Tire1也都自己的AP工具,欢迎大家交流讨论AP的开发方法论、流程及工具等。