基于SOME_IP的车载网络通信矩阵的设计_吴珍珍.pdf

2023年1月机电技术机电技术基于基于SOME/IP的车载网络通信矩阵的设计的车载网络通信矩阵的设计吴珍珍（东南（福建）汽车工业股份有限公司，福建 福州 350108）摘要随着车载以太网技术研究的深入，SOA软件架构的应用也越来越广泛。SOME/IP作为SOA的通信基础，成为了实现SOA的关键环节。文章介绍了SOME/IP通信的基本原理及设计方法，通过一个简单的应用实例，阐述了SOME/IP通信矩阵的设计过程及要点；同时基于VN5640搭建测试平台，验证了SOME/IP协议的一致性。关键词车载以太网；SOME/IP矩阵；Use Case中图分类号：U461.99文献标识码：A文章编号：1672-4801（2023）01-084-05DOI：10.19508/ki.1672-4801.2023.01.023作者简介：吴珍珍（1986），女，工程师，硕士，主要从事车载网络设计工作。近年来，汽车电子技术发展迅速，尤其在音影娱乐系统、车联网、智能驾驶系统、智能座舱等领域，涌现了大量摄像头、传感器、激光雷达等先进技术，随之电控单元数量急剧增长，车载通讯总线承载的数据量呈爆发性增长，通信性能要求更高。由于新技术的集成，汽车功能更加复杂，且新技术更新迭代周期越来越短，因此需要更高效、更便捷、更灵活的开发方式。传统汽车采用分布式E/E架构，基于CAN/LIN/CANFD 等总线进行通讯，带宽不足、软件升级不便，功能集成不便，且电控单元的算力有限，已经成为现阶段汽车技术发展的瓶颈。将 SOA 架构设计理念引入汽车软件设计中，突破了传统架构的瓶颈，车载通信架构也由传统的 CAN/LIN/CANFD 总线向车载以太网总线方向发展，以满足高性能通信需求。基于车载以太网的SOME/IP协议作为SOA架构的通信基础，将会得到越来越多的应用。1SOME/IP简介SOME/IP是基于IP的可扩展、面向服务的中间件，是一种满足汽车需求的开放式协议，位于TCP/IP协议之上，由AUTOSAR定义并完善。SOME/IP通信协议，将通信传输主体定义为服务器（Server）和客户端（Client），服务器提供服务，客户端请求服务。SOME/IP传输的内容实体为服务（Service），一项服务实体通常由 Fields、Events 和 Methods 等组成。SOME/IP 向上为应用层提供API接口，向下通过TCP/IP协议进行通讯，如图1所示。应用程序应用程序SOME/IPTCP/UDPTCP/UDPIPIP网络接口网络接口客户端服务器图图1 1车载以太网模型图车载以太网模型图1.1SOME/IP报文格式2SOME/IP 报文格式如图 2 所示。Message ID由Server ID和Method ID组成，在整车内部具有唯一性，作用与 CAN ID 相同。Method ID 最高位若为0，则表示通过method方式进行RPC调用；若为1，则表示传输 events。Request ID 可以区分对同一服务的多次调用。Client ID，在 ECU端具有唯一性。Session ID在会话激活后，每次会话递增1。Message Type 字段用于区分不同类型的SOME/IP消 息。通 常 使 用 的 类 型 有 REQUEST、REQUEST_NO_RETURN、NOTIFICATION、RESPONSE、ERROR。每条报文传输都需要 ReturnCode，表示请求是否已经处理。Payload为有效载0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31Message ID(Service ID/Method ID)32 bitLength32 bitRequest ID(Client ID/Sessino ID)32bitProtocol Version8bitMessage Type8 bitInterface Version8 bitRerurn Code8 bitPayloadvariable sizeBit offset图图2 2SOME/IPSOME/IP报文格式报文格式84第1期荷，是SOME/IP报文传输的主体内容。Payload字段的长度取决于使用的传输协议，传输协议为UDP，Payload字段的长度范围为01400 byte。1.2SOME/IP SD服务发现1，3-4和通信方式SOME/IP SD 可视为一种特殊的 SOME/IP 报文，是对 SOME/IP报头及 Payload 进行二次定义，将 其 Message ID 字 段 固 定 为 0 xFFFF 8100。SOME/IP SD 传输的报文主要有 FindService、OfferService 和 SubscribeEventGroup 等。每个 ECU都具有Server Service和Client Service。作为Server Service，SD功能要求发送OfferService，当service不需要时，能停止服务，同时对其他ECU的FindService进行回复。作为Clientr Service，SD功能要求监听服务器的OfferService，判断服务器提供的服务是否为所需的服务，同时能根据ECU本身的需 求，发 送 FindService，定 位 所 需 要 的 服 务。SOME/IP SD 的另一个作用是控制 Eventgroup 的发送。当客户端有Event需求时，需要先完成SD订阅，服务器才能发送Event。RPC定义了在SOME/IP通信过程中，服务端和客户端之间的SOME/IP交互方式5。服务实体Event、Method 和 Field对应的RPC方式不同，具体如图3所示。ClientServerresponserequestMethod with responseClientServerrequestMethod Fire&forgetClientServernotificationSubscribe for EventgroupEventnotificationClientServerresponseGetter/SetterFieldField notificationSubscribe for EventgroupField notification图图3 3RPCRPC交互方式交互方式2SOME/IP通信矩阵设计在实际应用中，整车的SOME/IP通信矩阵设计与功能需求密切相关，设计者需要充分了解功能逻辑以及通信数据的处理逻辑，而CAN通信矩阵设计仅需要了解通信数据内容，对应信号的处理逻辑，并不是必要的设计信息。SOME/IP报文是基于车载以太网传输，在设计通信矩阵时，除了需要关注通信数据外，还需要分配合理的车载以太网Layer1至Layer4的参数。车载以太网协议簇较复杂且配置更灵活，故SOME/IP通信矩阵设计灵活性也更高。SOME/IP通信矩阵设计流程如图4所示。首先需要进行整车功能需求分析，明确该功能在系统之间的逻辑交互，根据功能逻辑，形成Use Case需求文档。Use Case将明确服务需求及服务的交互方式。由于整车通信需求庞大，为便于描述，下文仅以座椅通风加热功能需求进行详细设计。功能需求功能逻辑分析UseCase分析SOME/IP通信矩阵设计创建ARXML结束图图4 4SOME/IPSOME/IP通信矩阵设计流程通信矩阵设计流程2.1网络架构及功能需求实车部分网络架构如图5所示。中央网关与大屏之间通信采用车载以太网100BASE-T1，座椅调节控制器通过 CAN总线与中央网关通信。大屏与座椅调节控制器的数据交互，需要通过网关进行Ethernet-CAN路由。功能需求：用户在大屏上，通过触摸大屏按键，可以分别调节主座和副座的通风或加热等级，以及关闭或打开通风、加热功能，并且显示实际状态。网关(EGW)大屏(AUDIO)座椅调节控制器(DAM)100BASE-T1100BASE-T1CAN.图图5 5网络架构网络架构2.2功能逻辑分析1）状态显示功能逻辑：在大屏主页面中点击座椅控制按键，进入座椅控制二级菜单，在二级菜单中显示座椅加热通风的状态。座椅调节控制器DAM分别发送主/副驾驶座的加热和通风的状态信号，大屏根据接收到的通风加热状态信号，显示吴珍珍：基于SOME/IP的车载网络通信矩阵的设计852023年1月机电技术机电技术OFF/1级/2级/3级。2）开关控制功能逻辑：触发主/副驾驶座椅加热开关，切换主/副驾驶座椅加热请求为OFF/1级/2级/3级，同时发送该加热请求信号。触发主/副驾驶座椅通风开关，切换主/副驾驶座椅通风请求为 OFF/1 级/2 级/3 级，同时发送通风请求信号。DAM接收到请求信号后进行控制执行。2.3Use Case分析根据功能逻辑设定，EGW收到大屏发送的开关控制请求后，回复 RequestACK，确认收到。并且EGW检测到DAM发送的座椅状态信号发生变化时，发送事件消息给大屏。大屏收到消息后，更新对应开关指示状态。具体交互过程如图6所示。AUDIO(Client)EGW(Server)按下开关RR_Request主驾驶加热控制副驾驶加热控制主驾驶通风控制副驾驶通风控制RR_Response请求确认ACKNotifier_value changeEGW发送座椅加热状态:主驾驶加热状态副驾驶加热状态主驾驶通风状态副驾驶通风状态座椅通风加热等级改变图图6 6座椅通风加热设定座椅通风加热设定根据上述分析，座椅加热通风功能可以拆分为两个Use Case。Use Case_001 座椅通风加热设置，详情如表1所示。Use Case_002 状态显示，详情如表 2 所示。其中 SeatHeatVentStaStruct 的成员为副驾座椅加热状态DAM_ASS_Heat_Mode、副驾座椅通风状态DAM_ASS_Ventilate_Mode、主 驾 座 椅 加 热 状 态DAM_Dri_Heat_Mode、主 驾 座 椅 通 风 状 态DAM_Dri_Ventilate_Mode。2.4SOME/IP矩阵设计及ARXML文件生成SOME/IP 矩阵需包含 SOME/IP-SD 的参数设置、服务配置、Matrix定义、数据类型定义四部分内容。SOME/IP-SD的参数通常采用全局的定义，也即全车带以太网通信的 ECU 均采用相同的SOME/IP-SD参数。该参数主要定义SOME/IP-SD消息发送的时间参数、端口号、多播地址、TTL。服务配置通常需要定义服务名称、Service ID、服务的 Server 和 Client、MAC 地址、IP 地址、端口号、VLAN、PCP、Client ID、Transport Protocol 参 数。Matrix 主要针对 SOME/IP 及 SOME/IP-SD 消息中的报头及Payload参数进行定义，同时还需要定义RPC 方式，如表 35 所示。在 Matrix 中定义的SOME/IP Payload 数据类型是多样化的，可以是Enum、Struct、Union等。数据类型定义，是详细定义Matrix中DataType Reference列的参数，相当于CAN矩阵中信号的定义。为便于软件开发及后续测试验证，需要将SOME/IP矩阵文档转化为数据库文档。在车载以太网通信系统中，常用的数据库文档为ARXML文件。目前是基于PREEvision软件进行建模，然后导出ARXML文件。在PREEvision中新建 productline，打开 SOA&Ethernet Exploer。依据 SOME/IP表表1 1Use Case_Use Case_001001Fun.StepFun.Trigger（In）Fun.SequenceFun.SequenceFun.EndDescription用户触发AUDIO界面开关AUDIO-EGW座椅通风加热开关模