普法芬快讯

SOA架构的“破局”逻辑

传统基于can信号的架构，也可以实现远程空调，大灯的控制，存在的问题是软硬件耦合太多，修改或者增加一个功能，如果涉及到网络信号的更改，关联到多个控制器，需要协调多个供应商来处理。

SOA是一种架构设计方法，目标是推进车内功能服务化，实现软硬件的解耦，新功能只要服务组合就可以实现，可以快速部署。

以上基础概念非常好理解，但这条路走起来没那么快，需要在设计的时候转变传统开发思路：

一个就是成本考虑的思路，传统的控制器是以硬件bom为关注点的，软件预留资源很少，SOA或者说SDV思路下，对硬件资源要做适当的预留，对应具体模块关联的传感器，执行器数据都要作为服务接口设计开放出来。

二是对于服务接口，不要因为现在看不到应用场景就不开放，应该尽量分解到基础服务，原子服务，并标准化，这样在OEM的层级就可以建立一套标准的服务库，可以对车型设计赋能。如果行业认可，就有可能推动成为行业的标准，一旦服务接口标准化，会反过来推动硬件传感器，执行器的标准化。

基于服务，车云一体就有很多想象空间，车作为一个服务端，提供了非常多的传感器的数据，云端可以基于这些服务衍生出非常丰富多彩的应用。

SOA本质上是硬件平台变成服务，进而开放给所有功能。因此这种架构本质上是沿用消费电子领域，开源软件建立平台生态的路子，当参与的功能开发者多了，整个产业就如智能手机产业一样，整个市场被扩大化了。因此驱动力本质上还是很足的，毕竟有利益在那里。但是应该看到的是，汽车有一个最特别的地方，涉及人身安全，所以玩法不能全盘照搬，哪些服务，在何种场景下才能开放，这是全行业需要思考、规范、约定的。同理功能具体的安全责任、出了事故后的安全判责、具体法规体系的制定，这些势必决定了整体生态建立的准入资格难度、市场活力、市场化进程。所以还是任重道远。

中央集成架构

中央集成架构，从长远来看是必将导致降成本的。另外集成带来原本的ECU间信号变成内部信号，程序执行上时间的优化，带来性能的提升还是有可能的，当然目前来看提升不大，执行器机械响应速度还没有这么快。以前车辆功能需要根据ECU资源，人为分配，因此功能逻辑的分布式与之间的解耦，带来了功能逻辑上的人为简化，集中式架构以及算力提升的必然趋势，带来了功能逻辑集成优化的基础，显然会给用户带来更好的功能。当然现阶段成本下不来造成的优势无法展现，也是客观事实。

Autosar和SOA

首先，需要明确的一点，Autosar软件架构和SOA软件架构并不是冲突的。Autosar架构更多的是一种规范，统一了软件接口、交换格式、方法论标准。其中Autosar所实现软硬件分离也正是SOA架构所需要的，但Autosar是一种面向信号的软件架构，而SOA是一种面向服务的软件架构。这也表明SOA更侧重一种架构策略层面的指导思想。可以理解成SOA在Autosar的基础上对ASW进一步分层，以便实现更大的解耦。所以，如果现有热管理软件暂不满足Classic Autosar架构，需现对其进行改造以满足Classic Autosar架构。然后在进行以下转换。

SOA的本质是由信号导向转变为服务导向。SOA软件既然需要面向服务，首先就需要暴露自己的能力以供其他服务调用。而热管理软件作为一个为空调及三电系统服务的软件模块，所以热管理软件的服务接口大部分面向于空调及三电系统。正是基于以上情况建议将热管理软件大部分逻辑算法布置于SOA软件架构的基础服务层。

而鉴于热管理系统涉及到多部件控制策略的强耦合，所以热管理软件只有传感器和执行器可以置于元服务层释放服务接口以供诊断及后市场使用。即需要将热管理软件中传感器、执行器信号转换及硬件诊断部分从热管理主体软件中拆分出来。

业务合作联系方式：

电话：13162059306

邮箱：olivia.li@pufaffen-electronics.com

职位投递联系方式：

电话：16621652379

邮箱：hr@pufaffen-electronics.com