刘 聪,陈 敏Liu Cong,Chen Min
面向服务的电子电气架构研究与应用
刘 聪,陈 敏
Liu Cong,Chen Min
(上海禾骋科技有限公司,上海 201805)
汽车行业技术升级对电子电气架构提出了更高兼容性、灵活性、迭代能力等要求,介绍了面向服务的电子电气架构设计,提出面向服务架构的开发流程、关键步骤及设计原则,并结合项目开发实例进行分析。
面向服务;汽车电子电气架构;软件架构
汽车行业正在向更高算力、更高平台化、更高灵活性方向发展,促进了电子电气架构的重大变革。物理架构将向域集中及区域控制方向演进[1],软件架构需要解决软件复杂度提升、功能迭代频繁的问题。SOA(Service Oriented Architecture,面向服务架构设计)解决了汽车电子电气架构面临的各种挑战,在国内外各大整车企业得到逐步应用。
汽车电子电气架构已从传统的分布式演进到集中式,在功能部署上从基于功能切换到基于物理区域划分;但传统的架构开发方式以功能实现链路为核心、以信号为依托,在需要实现新增功能时,面临着功能定义及功能开发效率低下、功能迭代开发周期长的问题,较难实现功能快速迭代,无法实现最优的用车体验。
基于SOA的电子电气架构以灵活性、可拓展性为传统开发方式所面临的问题提供了可行解决方案,其功能可分解为各个独立的服务,服务之间通过服务接口交互,并通过服务的组合及部署实现功能应用。这种基于服务的架构设计可实现软硬件解耦、功能灵活组合与快速实施,这些特性解决了汽车架构设计面临的挑战,使得SOA架构得到逐步应用。
广义上讲,SOA平台系统由3大系统组成:开发者平台、云后台和车辆。授权认证的开发者登录专属的开发者平台后,可以通过场景编辑等方式开发新的应用程序。开发者平台通过云平台与车辆建立连接,通过服务通道发送服务指令,通过OTA(Over The Air,远程升级)通道向车辆推送个性化的应用程序,实现了功能的快速组合、应用的快速迭代。
结合项目实践提出基于SOA架构的功能开发及服务设计方法。
对基于SOA的电子电气架构设计从功能场景分析,得出服务清单,并对服务进行详细设计、分层和映射,进而得到软件模块的定义;同时结合车辆已有的传感器、执行器等硬件基础,将硬件能力抽象为服务,通过服务组合得到应用功能[2]。关键步骤包括功能设计、服务设计、模块设计、通信设计等[3]。
在功能设计阶段,首先完成功能用例库,输入产品经理提供的功能需求清单,输出针对特定功能的用例。当完成多个功能定义后,也就形成了基于整体功能的用例库。功能用例库的开发流程如图1所示。
图1 功能用例库开发流程
针对功能用例进行详细设计,输入为功能用例库和当前车辆的硬件配置,输出为实现这些功能用例的服务,此阶段中服务库基于当前功能用例分析和硬件配置分析建立,整体流程如图2所示。
图2 功能详细设计开发流程
在服务设计阶段,基于功能设计阶段生成的服务库进行服务接口详细设计,定义服务接口的类型和设计规则。
2.2.1 服务接口类型
服务接口分为数据类、指令类和事件类。数据类型接口可以被get、set、notify调用,指令类接口可以直接被RR(Request/Response)、FF(Fire&Forget)调用,事件类接口可以被notify调用。各服务接口均遵循请求/响应或订阅/发布的交互机制。
2.2.2 服务接口设计规则
1)RR控制类指令
RR控制类指令应用于需要执行一段时间才会有效执行反馈的控制类指令,其Response(响应)中需要携带控制状态,此时RR的Response仅表示接收到Request,并做了必要的前提判断,并非真正的执行结果。
对于可以对控制指令的Request做出及时反馈的控制类指令,其Response可直接携带是否执行成功的信息。
2)通知类指令
通知类指令必须涵盖该控制类指令所涉及的所有状态,例如控制任一车窗全部开度的RR控制指令,必须有获取/通知车窗当前位置的状态类指令与之对应。
所有通知类指令携带的状态数据必须包含指示数据有效性的信息,有如下几种情况:(1)状态数据对应的CAN(Controller Area Network,控制器局域网)信号本身已有invalid枚举项或信息,沿用并无需添加内容;(2)状态数据对应的CAN信号为连续量,例如单电池电压(0~4 095 mV),不在此范围内的数值即为无效值,不再额外定义invalid指示信息。
2.2.3 服务分类
对服务进行分类及整合,将服务划分为基础服务、拓展服务、协调服务,其分层结构如图3所示,具体分类原则为:(1)基础服务层为实现过程无任何依赖的需求,多指传感器、执行器;(2)拓展服务层依赖基础层和域内同层,一般指算法包;(3)有跨域交互需求的服务均在协调服务层。
图3 服务分层结构
模块设计阶段,依据服务定义创建相应的SWC(Software Component,软件组件),定义对应SWC的接口信息及接口数据类型,描述SWC的静态依赖关系及动态依赖关系,将最终得到的SWC进行打包部署,得出最终的输出给到软件开发团队。
从服务到SWC映射的设计方法包括:(1)根据SWC之间的调用关系明确SWC之间的详细设计,包括实现某个需求所需的SWC之间的时序图、活动图、状态机;(2)明确SWC之间的信息传递,即服务接口;(3)在SWC部署阶段,考虑各成熟ECU的功能实施方案,如底盘安全均在ESC(Electronic Stability Control System,电子稳定控制系统)中,同时结合整车最终的域控制器方案定义每个SWC的归属。
通信设计阶段,完成数据类型定义、通信行为定义、SD(Service Discovery,服务发现)全局定义、SD ECU定义等。此阶段属于网络设计,数据命名、数据类型定义等参照AUTOSAR(Automotive Open System Architecture,汽车开放系统架构)标准,不再进行详细说明。
在某项目开发中,采用以太骨干网通信方式,并引入SOA架构设计理念,通过开发实例对SOA架构开发流程进行说明。
在车身域和娱乐域中,选出功能用例和对应的服务,具体见表1。功能列为功能清单输入,包含迎宾功能、灯光功能、智能空调和账户管理4个功能;用例列由各功能定义;服务列为实现该特定用例所需要的服务。表1中功能用例和服务定义为部分示例。
表1 功能用例和服务定义示例
续表1
在已有功能和服务基础上,添加一个新的智能迎宾场景,该场景定义为用户携带智能钥匙靠近车辆后,车辆自动解锁,外灯能够自动开关远光灯一次(迎宾效果),同时用户打开门进入车内,空调可以自动打开并调整到该用户定制的温度、风速和风向。原有的迎宾功能不具备此功能,如果采用传统的电子电气架构开发方法,需要重新定义功能用例和功能实现方案、功能分配方案,会影响开发效率。
基于SOA的架构系统,可以根据现有功能用例库、服务库进行快速的功能定义和功能开发,节省开发效率。在现有的功能用例库中,可以快速拆解出智能迎宾是由功能用例库中的UC-001、UC-003、UC-004、UC-005和UC-006组成;再根据各用例和服务的关联关系,得出实现该功能场景所必须的服务包括S0001、S0002、S0003、S0006、S0007、S0008、S0009、S0010、S0011、S0012、S0013和S0014。以上可实现复用原有设计,达到快速完成功能定义和功能开发的目的,如图4所示。
图4 智能迎宾功能设计
在总结传统电子电气架构开发所面临的问题和挑战的基础上,提出SOA架构开发流程,说明开发流程的具体要求及设计原则,结合项目实例进行展示。未来,基于SOA的设计能力会是整车厂重点发展的能力,其设计理念会得到更广泛的应用。
[1]刘佳熙,丁锋.面向未来汽车电子电气架构的域控制器平台[J].中国集成电路, 2019, 28(9):6.
[2]VETTER A,OBERGFELL P,GUISSOUMA H,et al,Development Processes in Automotive Service-oriented Architectures[C]//2020 9th Mediterranean Conference on Embedded Computing(MECO),2020.
[3]华一丁,龚进峰,戎辉,等.基于模型的智能汽车电子电气架构发展综述[J].汽车零部件,2019(2):4.
2021-07-14
1002-4581(2021)06-0034-04
U463.6.02
A
10.14175/j.issn.1002-4581.2021.06.010