基于SOA的车身控制器设计

【摘 要】随着车辆功能逐渐增多，用户需求不停更新，车辆软件需要快速迭代才能给用户更好的服务体验，更快的功能体验，真正满足千人千面的需求，从分布式EE架构转变为现在的中央计算加区域控制的架构，以SOA的形式实现软硬解耦，将更多的功能以原子服务的封装集中到车身控制器（BCM），根据动态配置进行不同服务的调用。本文从整车架构、BCM的功能定义、原子服务划分讲述BCM的原子服务设计。

当下汽车行业正面临转型的革命，随着新四化的提出，软件定义汽车已成为必然趋势，软硬件的解耦程度决定了企业产品的差异性，对硬件来说，需要可兼容、可扩展，对软件来说，需要升级快、可移植性好，因此从架构层面需要基于SOA来进行开发，将传统的分布式架构转为中央集中式架构，由中央计算单元与区域控制组成，将功能按颗粒度大小封装成不同的原子服务，以标准的服务接口进行调用，在功能交互过程中，交互双方无需考虑对方的协议，原子服务设计是决定软硬件耦合深度的重要因素，好的原子服务设计可以降低整车成本、屏蔽异构性且服务组合可以实现不同的功能，做到动态配置车辆功能。

1 汽车架构的设计差异

1.1 传统EE架构开发

传统EE架构的开发流程如图1所示，由市场首先对车型定位，针对定位寻找相应的或更高配置的主流车型进行对标，主要对标其外形、内饰、静态功能和动态功能并牵头全员填写竞品分析表，将分析结果整合并调研用户需求后整理输出配置表、技术梳理配置表，找到各自的相关项，转换为技术方案，将配置表分解为多个功能逻辑，再将功能逻辑分配给多系统，输出网络通信需求表，根据需求表，输出子系统的需求文档，文档中写明I/O、人机交互界面、性能要求、应用场景等，子系统根据功能分配自己的网络接口和硬件接口，最后完成系统的原理图和网络开发。

图1 传统EE架构的开发流程

1.2 在SOA下的EE架构开发

基于SOA的EE架构开发流程如图2所示，与传统相比，在输出配置表和转换功能逻辑是一致的，区别在于：功能逻辑转换后，没有直接分配系统而是将功能逻辑转换为原子服务，根据颗粒度大小，定义出硬件抽象服务并定义原子服务的接口，根据架构，将服务接口部署在不同的模块内，由于现汽车的自动驾驶等级越来越高，导致功能安全等级相应提高，因此针对不同功能所需求的功能安全等级不一致，需要安全工程师梳理后，再根据所分配的功能安全等级、原子服务设计以及软件模块，进行软件架构和硬件架构设计。

图2 基于SOA的EE架构开发流程

2 功能定义

以中央计算单元加区域控制的形式BCM集成了车身功能、空调功能、路由等功能，还具有网络管理、信号检测等功能，车身功能包括后除霜、外部灯光、内部灯光、前照灯调节功能、防盗、背门控制、中控功能、雨刮洗涤、后视镜功能、喇叭、天窗功能、RKE、PKE、玻璃升降、座椅调节等；空调功能主要是对泵、空调箱等电机或电磁阀的驱动，包括空调水泵驱动、电机水泵驱动、冷凝器风扇驱动、空调板驱动、冷却泵驱动、制冷机功能、空调箱功能、鼓风机驱动等；路由功能分为信号路由和线束路由，信号路由是因为BCM还承担网关的角色，BCM与中央计算单元采用百兆或千兆以太网连接，与其他ECU采用CAN或十兆以太网连接，需要将其他ECU的信号转发至中央计算单元，实现信号路由，而线束路由则是将需要转接的硬线信号，通过BCM控制器进行转接；因为整车在下电后既要保证车辆在一定时间内蓄电池不亏电又要保证车辆功能能够唤醒，因此网络管理尤为重要，网络管理包括定义唤醒模式、睡眠模式，需要根据不同的通信方式进行睡眠管理；信号检测包括碰撞信号、门开关检测、门状态检测、温度检测、阳光检测、挡位开关检测、灯光开关检测等。

3 系统框图

根据架构和功能定义，得到BCM的系统框图（图3），电源管理模块将外部KL30常电转换为系统芯片所需的系统电压并保持稳定，MCU芯片支持数字信号和模拟信号的输入。一般开关类的信号为数字信号，如门开关；传感器一般为模拟信号，如温度传感器、位置传感器等，或部分开关是PWM形式也属于模拟信号，如灯光亮度调节、碰撞信号等。BCM内部有CAN收发器，支持CAN或CANFD的信号，将LIN信号作为硬件预留，有实时性要求不高且非安全类的产品可使用LIN通信，MCU有主MCU和辅MCU，辅MCU主要是对功能作冗余备份，对于外部灯光驱动有两种形式，分别为高边驱动HSD和低边驱动LSD，在大部分场景下，使用HSD较多，将LSD作为硬件预留，但HSD的驱动电流一般小于15A，如洗涤泵、电机水泵常采用半桥芯片和MOS管来驱动，不同的MOS管驱动电流不同，可以支持近400A的电流驱动，BCM内置以太网交换机和PHY芯片，支持十兆/百兆/千兆以太网的ECU通信。

图3 BCM的系统框图

4 服务API设计

服务的软件架构如图4所示，分为硬件层、基础软件层、功能软件、硬件/设备抽象层、原子服务层、RTE运行环境和应用层，因为BCM不存在音视频接收和图片接收，因此没有SOC、GPU或DSP等异构芯片。在软件层，对于硬实时信号，使用classical autosar，针对软实时使用adaptive autosar，adaptive autosar也是实现原子服务的关键，硬件/设备抽象层，是对输入接口、传感器/执行器等硬件进行抽象，目的是屏蔽硬件差异对软件的影响，原子服务则是通过排列组合为应用层提供统一接口，提高开发效率，RTE为应用层的APP提供运行环境，应用层是将功能体验直接面向用户，形成产品竞争力。

图4 服务的软件架构

原子服务设计，首先根据function list，列出BCM的所有功能，然后按照颗粒度大小，将功能转换为合适的API描述，在服务API描述中定义服务类型，可以是最小服务API，也可以是组合后的API，最小服务API如左前门开关服务，组合后API可以是左前门服务，此服务包括门锁状态、车把手状态、车门状态、车门开度、儿童锁状态等。一般BCM的原子服务定义为如下：车门服务、尾门服务、车窗服务、天窗服务、遮阳服务、车钥匙服务、车外鸣笛服务、低速报警服务、外后视镜服务、座椅服务、座椅通风加热服务、方向盘调节服务、迎宾服务、雨刮洗涤服务、制动灯服务、转向灯服务、报警灯服务、日行灯服务、雾灯服务、近光灯服务、远光灯服务、位置灯服务、倒车灯服务、激光灯服务、后牌照灯服务、logo灯服务、前照灯调节服务、空气净化服务、顶灯服务、手套箱服务、除霜除雾服务等。对于设备服务，定义如下：门开关、门锁、尾门开关、尾门锁、尾门电机、车窗开关、车窗电机等，根据输入条件和输出控制，隔离相应的设备。

以温度检测服务为例，依据SOME/IP的报文格式，需要定 义service ID/method ID、client ID、session ID、RPC type、返回值、报文周期、调用描述等，服务的调用方法有method、filed、fire and forget、event，其中method又分为RR和FF类型，filed分为setter/getter和notifier，那么该服务里的provider是BCM，consumer是中央计算单元。服务接口可以定义为几种形式，当使用RR-method时，对温度传感器状态检测，使用FF-method时，通知中央计算单元温度过高，当使用field，温度值检测，当使用event时，检测到超过某一阈值后再上报。以field温度值调用为例，服务的server为BCM，服务的client为中央计算单元，service ID为0x4003，Instance ID为0x0001，server port为30500，client ID为0X0003，client port为30500，服务描述为：该服务主要识别室外温度值，RPC type是field，field属性字段名为Snsr_TemperOut，field字段数据类型为float ntfT（），RPC Specific Type为getter，Method Name为OutSIdeTemp，以上ID和port仅作为示例，具体由车企根据实际情况确认。

5 测试搭建

传统的测试无论是软件测试、硬件测试、集成测试都无法满足当下基于SOA的控制器设计，传统软件并未深入使用AUTOSAR架构和引入功能安全概念，更多使用的是供应商自身的软件架构平台，导致测试无法统一且无法满足现设计，功能集成测试更多是针对信号相关方的发送与接收，验证发送时间的正确性和接收方接收的正确性以及发送的间隔时间等，但新型架构下的功能集成测试需要重新搭建，在软件测试中，需要搭建新的测试平台，如软件单元测试中，需增加服务接口测试、服务调度测试等，在软件集成测试中，各个组件拼接后，在PCBA上需要调度CPU资源测试、内存隔离测试等，由于车身控制器与车辆数字钥匙相关，在硬件中需要增加安全芯片，以HSM对系统内部监测，以SE对外部通信监测，因此软件安全测试中，需增加主被动攻击测试、芯片时序、密钥安全测试以及数字钥匙证书测试，要求满足国密等级。

6 原子服务技术思考

SOA的实现不仅是一个独立事件，涉及到EE架构以及整个生态的搭建，已有的软件平台已成熟且可靠，新的软件投入给车企及供应商都带来成本大幅增加且对工程师的技能更为严苛，需要掌握复合型的知识体系，SOA基于SOME/IP实现，SOME/IP在数据传输时有延迟且是软实时。

各个软件层与通信层需要协同调度，多者的一致性会影响服务响应的实时性，调度时间长产生较差的体验感；用户不同的车辆需求，要求服务有更高的部署灵活性，然后如何部署既能兼容定制化又能灵活配置；传统对网络测试基本是基于CAN或LIN，引入SOA概念后，需要搭建一套新的针对以太网的测试平台；原子服务设计有评价指标，好的评价指标会指导后续设计的可行性，统一设计理念，降低差异化；传统的一个功能会拆分为多个服务，且服务可能存在于不同的ECU，增加了软件的复杂度且影响性能；每个服务都需要有独立的配置、部署、监控和收集，增加了成本；硬件的冗余和对于功能安全ASIL认证和AUTOSAR的使用，产生的费用也会增加成本。

7 结论

针对以上概述，合适颗粒度的服务原型不仅可以从组织层面、架构层面、运维层面、设计层面等多方面降低成本且做到产品的差异化，真正满足用户千人千面的需求且适应当前电子电气架构开发，在车身控制器上不存在异构芯片设计和多操作系统共存的情况，但关于智能座舱或自动驾驶模块，会比车身控制器面临更大的挑战，但车身控制器也需提前考虑。随着架构和开发能力的提高，未来车身控制器与自动驾驶或智能座舱融合也逐渐变为可能。

参考文献

[1]中国汽车工业协会软件定义汽车工作组.软件定义汽车服务API API Version 2

[5]中国汽车基础软件生态委员会（AUTOSEMO）.车载SOA软件架构技术规范1.0[S].

[6]马建辉，王知学，侯冬冬，等.一种集成式汽车BCM的设计与实现[J].汽车电器，2019（2）：25-27.

[7]汤自宁，吴瑾，王冠达，等.集成于车身控制器的胎压接收模块硬件设计[J].汽车电器，2019（6）：37-3

[8]张文杰，洪宇，孙宗姚，等.基于新架构的汽车远程诊断系统的应用[J].汽车文摘，2021（5）：24-27.

[9]庄夏.API网关架构设计实例[J].汽车文摘，2018（5）：99-100.

[10]向劲松，蒋豪，邓晨辉，等.集成胎压监测的车身控制器设计[J].汽车文摘，2017（3）：49-53.

END

添加下方信加入汽专业交流群