10个SOA框架设计中需要考虑的问题-EDN 电子技术设计

 这篇文章写了关于汽车SOA过去的10个问题，文中提到：不仅是SOA框架，在智能汽车上的整个服务框架设计都面临着同样的抉择与挑战：实时性 vs 灵活性，跨平台 vs 轻量化，功能安全ASIL_D vs QM，微内核与宏内核等等。

前言

自上一篇技术闲谈之汽车SOA过去已近两年，当时撰文时，SOA还只是个构想与趋势，现在已经在汽车行业的各厂商中全面铺开，甚至有人开玩笑说，“不懂SOA出去都没法跟人聊天”。这方面的文章在公众号、博客上也不少。

但是讲SOA的服务设计、如何使用的很多，讲SOA框架的很少看到。从个人角度来看，SOA从构想到“真正”落地，技术难度还是很大，其核心就在于“SOA框架”的复杂度较高。

今天，咱们就来讲讲为什么“SOA框架设计”那么复杂。希望最近加入，或者想加入汽车行业的小伙伴都能看懂。

一、为何需要一个SOA框架？

这是一个最根本性的问题，SOA框架说白了就是让服务与服务之间可以相互发现和相互通信的东西，那为什么不用一个现成的IPC (Inter process communication) 呢，而要自己去重新设计与开发？常见IPC如dbus, MQTT, binder, SOME/IP, DDS，都被广泛使用与验证。

简单的回答是：没有合适的。展开来是这样的：

问题1：SOA服务是否需要部署在MCU上？

首先，要回答的是“什么是MCU”？

MCU(Micro Control Unit)是车上最广泛使用的控制单元。回到10年前的汽车行业，车上除了“中控大屏”外，所有的电子控制器都是属于MCU，如新能源车上必备的VCU（车辆控制单元）、BMS（电池管理系统）等等。MCU的特点是“低功耗”、“低算力”、“低内存”、“实时”。

其次，“为什么用MCU而不是强大的MPU”呢？

因为车辆在长期停放中，车上可供电的只有一个50~60Ah的小电瓶，而MPU在待机时的电流过高，很容易让小电瓶的电耗光。所以在汽车行业中，如果真的要用高性能的MPU，一般会搭配一个小的MCU来做电源管理，让MPU在待机时完全关闭，从而达到待机电流3~4微安甚至更低。

再次，“SOA服务是否需要部署在不可或缺的MCU上呢”？

当然要。比如说，当驾驶员踩加速踏板时，VCU需要根据踩的幅度、当前车辆的驾驶状态（如用户是否设置限速）、电池剩余的电量（是否电量过低）、车辆驾驶模式（运动、节能、雪地）等等决定告诉“电机”是否提高转速，及提高多少。这就是一个典型的SOA服务，会被其他域所使用（如智能驾驶的自适应巡航功能），且只能部署在一个实时、高功能安全等级的系统和芯片上，而从成本上来考虑，只能是一个MCU。

结论：

在MCU上，上面列举的dbus, MQTT, binder, SOME/IP, DDS等，要么就完全不可用，要么就性能不佳。所以，留下的选择无非几种：

不部署在MCU上，或者不计成本将部分MCU替换成MPU
优化MCU上开源IPC的性能
自行开发一套IPC

如果你发现MCU上和MPU上选择的不是同一个IPC（大概率不是同一个），那么你就需要一套SOA框架来做抽象。

二、如何挑选合适的IPC？

接着上面讲，要开发一个SOA框架，其中最基础的就是IPC的选择。这里讲几个关键的问题。

问题2：IPC是否支持静态表？

从功能安全的角度来看，服务发现必须同时支持“动态发现”与“静态配置”两种方式，以起来冗余备份的作用。正常情况下，服务之间通过“动态发现”来通信，如“名字服务”、“广播”等，但若系统出现故障时，必须能允许最基础的部分通过“静态表”被发现。

问题3：IPC是否有单点脆弱性？

同样是出于“功能安全”的需求，IPC是不能有单点脆弱性的。比如有一些设计，会通过整车的单一的“名称服务”来做服务发现，但是一旦这个单一的“名称服务”失效，则会对车辆的正常运行造成很大影响。所以，按功能安全的要求，“名称服务”至少要有一个备份的实例才行。

问题4：IPC是否支持冗余服务？

还是出于“功能安全”的需求，关键服务必须要有多个实例存在，其提供的服务名称、标识、方法、事件等等都必须一模一样。这个如何支持呢？

三、如何保证服务编程的一致性？

在挑选完合适的IPC之后，问题又来了，如果要支持多种IPC，如何保证服务编程的一致性呢？对于服务而言，不应该感受到底层的IPC的差异。这时，就需要定义自己的框架接口(APIs)。

但是光定义完框架接口还没有结束，对于每一个服务而言，还需要做这三件事：

用合适的语法来表示自己提供的服务接口、数据类型 (Interface Definition Language)
将自己收到的二进制数据解析为内存中的数据结构 (Deserialization)
将内存中的数据结构转换为二进制数据，并发送出去 (Serialization)

所以，框架还需要选择合适的IDL，并且根据IDL生成对应的序列化代码(SerDes)。

问题5：定义框架接口时需要注意哪些？

框架接口的定义从大的原则上来讲，主要关注的是低耦合性。具体体现在两方面：

独立于任何的IPC：以具备支持未来更多IPC的可能性。
独立于所使用的平台：以具备支持未来更多平台的可能性。

问题6：如何选择合适的IDL？

每一个IPC都有自己对应的IDL，如DDS对应的OMG IDL、gdbus用的XML、Google的Fuchsia用的自己同名的FIDL等等。可以自己创造一种IDL，当然也可以选用现成的IDL。那么这里主要讲两个因素。

首先，这个IDL是否支持生成服务接口，而非仅生成序列化相关的代码？

比如说，对于服务的消费者而言，要使用一个服务前，首先要与其建立连接或发现这个服务，那个IDL的代码生成器是否会根据服务端的名称自动生成以下：

创建服务端的proxy实例
完成服务发现的细节代码
处理内存分配与释放的问题

又比如说，在调用服务的方法时，代码生成器是否会生成以下代码：

调用对应方法的序列化函数
调用对应参数类型的序列化函数
处理内存分配与释放的问题

总之，如果IDL支持生成服务接口相关的代码，会大大减少所有服务开发者编程的时间，以及降低问题的出现率。

其次，这个IDL的代码生成器是否支持扩展？

从IDL生成代码的步骤与编译器的步骤基本一致。用一张图来表示

KQzednc

Source: https://www.tutorialandexample.com/phases-of-compiler

关于各个步骤的意义在此不赘述。对于IDL的代码生成器而言，中间代码生成器与代码优化可省略，其他的是必不可少的。

如果一种IDL对应的代码生成器是不可扩展的，那就意味着，要么你不能扩展这种IDL，要么你就得把从第一步到最后一步全部重写——巨大的工作量和风险。

四、那些非功能需求怎么办？

对于汽车行业，有时功能需求可能挺简单，但是非功能需求却会大大增加其复杂度，甚至完全推翻之前的方案。这里大致讲三种非功能需求：功能安全、信息安全、性能

问题7：功能安全的E2E(end to end)保护是否要满足？

在汽车行业，对于人身安全相关的通信，是需要提供E2E的通信保护的。在ISO26262中有提到：

需要通过一定的机制防止通信错误的出现
如果仅“防止”还不够的话，需要提供足够高置信度的错误检测机制

所以，这个需求就一定要实现。而传统的IPC机制无法满足这一点，需要在SOA framework中加以实现。

问题8：如何防范人为的攻击？

汽车的信息安全是一个大的话题，但通用的做法一般是做威胁建模，然后挑选优先级最高者进行。较为常见的保护措施是这几个：

通信加密，防止攻击者在信道上进行窃听，但会消耗额外的CPU资源，并引入少量的时延。
身份认证与鉴权，防止攻击者伪装成合法用户，一般来说有预置密钥、PKI(public key infrastructure)体系两种做法，其主要影响的是建立连接的时间。
通信内容进行数字签名，防止攻击者对通信内容进行修改，但对CPU资源的消耗较大，也会引入一定的时延

这些保护措施都需要结合实际情况使用，以保证服务和系统的可用性。

问题9：如何满足性能要求？

性能往往是产品中最不可妥协的部分，其直接会影响到用户体验。对于SOA框架而言，最重要的几个性能指标如下：

通信时延：对于最高优先级的消息，从进入用户端的SOA框架，到客户端从SOA框架收到，其要求是多少？1ms，10ms，还是100ms？这会极大的决定SOA框架的实现方式。
通信时延的抖动：在满足通信时延的同时，其抖动的分布要求应该如何？是95%置信率？还是6 sigma？
通信带宽：对于主干网络中性能最弱的MCU，使用该SOA框架，其是否能充分利用网络带宽？比如网络带宽是100Mbps，该MCU在干净的环境下是否能逼近这个值？

五、仅仅SOA框架就够了吗？

大家都知道，SOA服务理论上最大的优势是动态灵活部署，也就是说部署在A控制器上的服务，仅仅通过更改部署配置就可以部署在B控制器上。那么，这一点，仅仅依靠SOA框架就够了吗？

问题10：如何真正的做到“动态灵活部署”？

理论上来说，这个是几乎不可能的。因为只有当车辆上的控制器，跟云端的服务器一样，除了硬件配置稍有不同外，运行的操作系统、安装的应用软件、使用的通信中间件、运行时框架都一样，才能做到完全的“动态灵活部署”。

那么，这里我们就讨论一下“有限的动态灵活部署”，也即“硬件相近的控制器间”的动态灵活部署。除了“通信中间件”——SOA框架外，还需要运行时框架的一致性，其一般会包含下列功能：

服务的调度：即不同服务或进程可以有不同的优先级
Log & Trace：统一的日志系统
- 服务的监控：统一的监控与管理框架
- 资源的控制：统一的资源控制框架
- 服务执行的控制：统一的服务开始、中断、结束控制

等等。

责编：Lefeng

文章来源及版权属于汽车电子与软件，EDN电子技术设计仅作转载分享，对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。如有疑问，请联系Demi.xia@aspencore.com

阅读全文，请先

汽车电子与软件

进入专栏

汽车电子

上一篇： 助力智能穿戴产品新功能应用，豪鹏科技锂电池获飞利浦新风口罩采用 下一篇： 新一代5.3蓝牙版本，AI通话降噪，倍思BowieE9真无线耳机拆解

微信扫一扫
一键转发
最前沿的电子设计资讯
请关注“电子技术设计微信公众号”

热门评论
最新评论

换一换

杂志声明

10个SOA框架设计中需要考虑的问题