2023年5月9日—10日由捷途汽车主办，盖世汽车承办的2023捷途汽车电子架构与智能驾驶论坛上，华为智能车控解决方案架构设计部长何朗表示，通过SDV分层解耦+服务化，实现乐高式开发和车型快速适配。同时，SOA与分层设计，能够最大化实现软硬件解耦，降低开发复杂度。
同时他还总结了华为在实践过程中总结出三条经验:在人机交互类应用中引入真事件机制，替代周期机制；在SoAd层将多个上层报文进行聚包，聚包到达触发条件后再添加ETH报文头发送；异步调用降低多任务时CPU占用和时延。
华为智能车控解决方案架构设计部长
以下为演讲内容整理:
SOA架构的思考与设计
近些年SOA服务化落地过程中，架构随着业务的发展不断进行调整，在这个过程中一些思考与解决措施与大家分享一下。首先回到软件定义的主题，面对日趋复杂的场景，智能化零部件的增多会带来相关的网络安全及隐私方面的需求。并且在软件开发过程中的落地流程也日趋复杂，所以都需要进行调整和变革。
我们在很多车型上做了实践，以及工程化的落地方案，包括和行业的生态伙伴们共同做了很多有益的探索。总体来看，软件适应汽车迭代过程中的周期性压力和要求、生态伙伴的增多以及生态运营的不断丰富等，需要将软件分为三层，并且在应用层要解决多种复杂问题。
在物理层，随着智能化部件的引入，对通信和电子信息架构的调整具有巨大的变化，但为了整体软件架构能保持稳定，所以引入了服务层，目前处于建设过程中。对软件架构的设计，有以下几个应对措施，在分层设计方面，设计了三层，这样可以把中间传统的跨ECU的开发，通过软件架构解耦到中间平台，这一层包含了设备抽象。简而言之把软件中通过经验固化形成标准库直接调用，让开发者有更多的精力进行面向消费者的差异化创新。
在解耦的过程中，发现物理层到应用层是随着车的电子信号而变化，并且对应的电子器件的差异化会导致需要进行适配工作。在软件架构中引入设备抽象和原子服务两层进行软硬件充分解耦，设备抽象的使命是屏蔽统一类型硬件不同硬件供应商或统一供应商不同型号的接口差异，原子服务将基本的原子能力抽象成标准化的接口，这些能力也会随着车型的变化固定下来，通过经验累积，形成可快速重用的资产。
在实践过程中，因为新的传感器引入，也会对智能化提出更高的要求，比如传感摄像头、雷达信号的引入等，如何向上提供更多的能力，也是消费者感兴趣的业务创新范围。通过一些实践，把新型的传感器对外的能力做原子化的封装，也可以利用已经封装好的能力形成一些新的业务。
在软件定义汽车SOA的架构中，我认为比较有价值的设计原理，是通过软件的差异去屏蔽不同硬件的能力，解决不同原子服务之间的耦合性，形成避免双向依赖，减少信号之间交互的复杂度。以及对服务接口的前向兼容，避免上层软件针对下层硬件的变化，产生新的架构变化。
SOA开发落地的性能挑战与实践
在SOA落地过程中遇到的主要挑战，是如何做到软件Onetrack，因软件规模日益庞大与复杂，分工也越来越精细。这种情况下，大量的软件工程如何做到跨车型和平台，甚至是引入一个新的供应商能快速融入当前的架构，成为一个大的课题。
比如在实际落地过程中，服务层、抽象层以及对应APP间的部署和调用间的关系非常复杂，必然会导致不仅要兼容很多功能，还要兼顾性能的考验。在保证服务层稳定和灵活部署的前提下，有利于新功能的快速移植和同步。
在这个过程中，会发现服务的灵活性不可避免带来通信的压力，具体表现在一是通过原有信息架构到服务化架构，为了保持灵活性所以会引入大量报文，各个服务器的接口间的独立会带来通信消息压力的巨幅增加；二是在传统的MCU去处理这些消息的时候，因为要应对不确定性的报文，最开始第一次SOA时，对消息的处罚机制都没有做约束，所以短时间会引入大量的报文，这种情况下对CPU的负载也是非常大的考验。
针对这两个表现，我们在很多车型上做了尝试，总结了服务部署的六条经验，比如功能安全高的, 部署在MCU上，多个CP间，若存在资源分布不均，优先部署在CP资源最富余的节点上等。同时，还要兼顾开发者能力的聚合，以及对消费者体验的实时性要求，把人机交互的应用或者相关的服务，就近部署到对应的VIU或座舱控制器上。比如以手动开启尾门特性为例，开门的应用是部署在尾门最近的VIU上，同时为了响应更快，对应的应用部署在座舱上，与物理按键原子服务就近共部署。
图源:演讲嘉宾材料
满足灵活部署的性能要求后，我们发现同样一个功能会分散在不同的区域控制器和中央控制器系统中，多种交互以及对应的通信开销会产生大量的报文冲击。在这样的情况下，为了保持车身域通信的灵活性，其消息粒度会变小，从而产生大量的报文，带来了通信传输的压力。
我们借鉴ICT中的通信经验，比如在2G时解决信息风暴或短信的拥塞的方法，，引入真事件机制，替代默认的周期机制，对周期性的报文通过操作系统及工具链的配置，允许这些报文形成聚合，在没有发生变化时默认延长周期，但发生变化时，就会立刻触发上报。采用周期性Event机制，每秒要产生20000+报文，而采用update on change机制，每秒产生的报文低于1000个，处理报文数减少了20倍以上，极大的降低了CPU处理开销。
对以太代替CAN的通信的方式，最大的变化是会引入大量的消息负载，通过引入NPDU的方式，把消息分成不同类型，区分轻重缓急，兼顾实时性和通信效率需求。如果不是很紧急的报文，可以累积到一定时间上报，这样的方式可以将负载大幅降低。
异步调用打破传统通信机制
传统的通信方式，对Autosar标准协议非常成熟，消息机制比较稳定，并且它的负载是通过底层统一处理。而SOA的形式下，会面临着大量阻塞的问题，具体原因是类似于RPC的服务方式，因为它的原理是要等到反馈结果之后，才能处理后面的动作。而服务化的方式后，会发现是多任务高频同时发送的场景，如果每个处理的任务都需要等待后续的任务才能往下走，不可避免的会导致队列会变得冗长。
针对这种情况引用异步调用机制，把一个闭环的消息变成了两次闭环消息。第一次把任务发到被调用方之后，不需要等待回调结果并行处理其他任务，这样可以把很多串行的任务变成并行。比如位置灯可能会部署在车不同区域的控制器中，可能会因为其他同时并发的任务而阻塞等待，但通过异步调用的方式，应用本身能在60毫秒之内处理完，也能够解决服务化所带来的问题。
服务化本身因为以太在面向于车载和功能安全应用，会面临着很多的挑战。对车灯或者车门要去协调各个地方的应用，所以针对延时以及同步等问题的处理，还需要后续考虑一些对策。总体来看，通过架构的标准化对齐产业链的各种语言，能够通过不同原子服务组合体现车型差异，并配置化适配，使能上层应用跨车型复用，同时通过设备抽象，屏蔽硬件的差异化，软硬件解耦，能够使软件在不同车型中更加灵活的移植，甚至做到不感知。
我们要想办法做到整车的灵活部署，以及对应的接口的标准化，使OTA新功能上线将变更和OTA范围控制在某一个控制器内，同时对其他应用来说，能够尽量做到不感知。以性能来看，以太通信打破了传统CAN周期处理思路，优化其处理性能，可以提高可靠性和加速转型。目前来看，最大的就是通信拥塞、调用问题和队列问题，通过异步调用以及消息触发的灵活性，对应聚合等方式可以逐步完善性能。
郑重声明：此文内容为本网站转载企业宣传资讯，目的在于传播更多信息，与本站立场无关。仅供读者参考，并请自行核实相关内容。
