【数据分发服务DDS】软件定义汽车【二】- 面向服务的架构设计

引言

上一篇文章主要介绍了电子电气架构、车载操作系统、基础软件平台等之间的关系，以及软件定义汽车的基本概念，本篇将继续深入，重点阐述三个问题：

• 智能电动汽车软件范畴
• 软件+硬件升级的基础
• 面向服务的软件架构设计

一、智能电动汽车软件范畴

按照新能源汽车的特点以及中央计算电子电气架构的发展趋势，可以按照以下三个类别，对智能汽车软件进行分类：动力与底盘控制器、车身控制器、中央计算单元。

面向服务的架构设计举例

上面这张图，软件上的分层看起好像和传统软件的架构也没太大区别，其实这里面最关键还是服务间的连接关系，其核心是需要SOA框架软件的实现一套服务管理的框架，类似与IT领域所说的 UDDI（Universal DescriptionDiscovery and Integration，统一描述、发现和集成），提供服务发布、查找和定位的方法。在这个框架下，服务节点可以动态加入，并且按照统一标准实现的所有服务都是对等的，服务之间可以动态的建立订阅/发布的关系，且相互之间以一种中立的服务描述语言为契约，是一种松耦合的关系。

服务可以分为三类，原子服务、组合服务、流程服务，原子服务提供的是最基本的功能，比如获取传感器的数据、升降车窗指令；组合服务是利用多个原子服务，实现了部分判断逻辑，比如升降车窗并不是任何条件下都能执行，还需其他条件去综合判断；流程服务，是根据业务功能定义的服务，比如产品上定义一个抽烟模式，需要同时打开车窗、天窗，并播放车主收藏的音乐，这就需要调用多个组合服务去实现。

原子服务，一般和硬件功能有关，硬件功能决定了原子服务的范围；组合服务，可以认为和某种策略和控制逻辑相关，比如实现一种新的驾驶模式；流程服务，可以认为是和特定场景下的产品功能。 **在SOA的软件框架下，“软件定义汽车”就变成了，在一个完备的原子服务集合当中，通过定义新的组合服务与流程服务，去实现新的产品功能。 而在硬件可升级的前提下，又可以通过硬件升级，去拓展原子服务的功能范围。**比如，换了带V2X的中央计算单元，就可以新增V2X相关的原子服务，然后定义一个新的流程服务，如，基于V2X的紧急刹车。

当然新的架构，也一定会带来新的挑战:

• 架构设计的挑战， 比如上面提到的服务的拆解、分类、分层，这类工作往往具有一定的灵活性，需要不断地去摸索和总结最佳实现。
• 功能安全的挑战，传统AutoSAR，功能静态部署，可以对每个分支流程，做危害分析，而SOA功能可以动态部署，无法预先做到每个场景都覆盖到。
• 信息安全的挑战，传统的离散系统，造成信息孤岛的同时，也无形之中构建了一道物理防火墙，现在服务都变成了对等节点，就需要一套完整的权限控制解决方案。

结语

本篇主要对智能汽车软件的范围、软硬件升级、SOA的内涵进行了介绍，下一篇将重点介绍，SOA实现的基础；对常见的技术概念，车载以太 、SOME/IP、DDS、Adaptive AutoSAR、ROS2 等，梳理各自所处的技术层次与要解决的问题，阐述其与SOA的关系。

译文连载

RTPS规范-译文连载：实时发布订阅协议（RTPS）DDS互操作 络协议规范-中文翻译_001

DDS规范-译文连载：DDS (Data Distribution Service) 数据分发服务-规范中文翻译_001

相关链接

【What：什么是DDS】【Why：为什么选择DDS】

【How：DDS如何工作

DDS科普：一文读懂DDS（数据分发服务）

产品介绍：BLUE DCS分布式数据连接解决方案

产品试用：海蓝云平台-Blue DCS

博文汇总：博文汇总（技术博客_行业应用_规范翻译）