SOA服务导向架构的软件架构与开发_服务导向架构(soa)-CSDN博客

本文链接：https://blog.csdn.net/yiyu20180729/article/details/136661140

多域融合SOA架构

随着整车电子电气架构从分布式架构、域控制器架构到中央计算架构演变，汽车智能化产品在量产开发过程中面临诸多挑战，如开发周期缩短、算力与成本难以平衡、智驾场景功能持续升级迭代、研发投入持续加大等，如何提升整车架构下的协同开发效率，降低软件开发成本，成为当下行业关注的重要议题。

倡导的“软件先行”创新研发模式，通过软硬件有效解耦，减少域控制器升级、芯片替换等硬件变化所带来的软件开发工作量，致力于解决域控制器架构下跨域开发等复杂问题。

NeuSAR SF提供统一的通信接口、通信能力和基础服务，将不同硬件、操作系统、通信总线、通信协议封装抽象，实现线程、进程、域控制器内异构核、车云之间服务调用的一致性，助力车企节约开发时间和研发投入。

自动驾驶中间件

针对自动驾驶算法高性能、确定性和实时性等特点，东软睿驰自动驾驶专用中间件的不同模块帮助实现典型自动驾驶关键需求，构建高度智能和可靠的自动驾驶系统。

Framework：解决典型自动驾驶关键需求，如高可靠的实时调度、快速状态切换、功能快速启动（PDC、AVM等）、特殊模式的资源管理（长续航、哨兵等）；

EAL：解决典型智驾核心性能问题，如异构多核部署、内存/缓存使用策略、高效核间通信、传感器数据实时性及帧同步、调度方案优化、“零拷贝”机制；

Core：实现典型复杂系统可靠性，解决传感器故障检测及恢复、通信故障、系统故障、系统确定性等问题；

Module：通过开放接口的平台设计，提供标准化接口，算力、资源占用评估工具，数据采集与回放API，产线功能SDK以及全周期OTA方案，实现多方算法联合开发。

服务导向架构

SOA设计流程

工具链

网络拓扑设计

最终会落实为网络拓扑和线束设计，当然电源、供电、诊断也会一起解决。

进入到SOA时代，中间件是关键，即自适应AUTOSAR，简称AP。AP采用经典的代理(Proxy)-框架(Skeleton)模式来完成SOA模型的描述。这种模式将直接交互的客户端(Client)和服务端(Server)分离，也可理解为应用软件和底层硬件脱离，由代理负责传递信息来完成服务调用，客户端和服务端不需要处理通信层详细信息。服务组件由服务单元提供的“业务逻辑”和适配目标系统环境相关的“基础设施逻辑”两部分组成。

在开发过程中，这两部分是解耦的，可同时进行的，且软件形态是灵活的。有些新兴造车如特斯拉，对AUTOSAR不屑一顾，完全按照消费类电子软件开发方式开发，结果就是无法重复利用研发成果，重复开发工作明显。AP不是一个中间件的名称，它是一系列中间件的集合，此外AUTOSAR只是定义了方法论，具体还要厂家二次开发。

在服务组件中，服务单元的逻辑可以是源码或被封装为SDK形式，且不关心具体的编程语言；基础设施逻辑 (Interface和Message) 则以C++的形态编码，与服务管理中间件一起确保服务的动态响应性和服务自身的可扩展性，其软件形态同样可以是源码或SDK形式提供。

中间件最核心的功能是通信，AP最核心的部分是SOME/IP或DDS，DDS目标是自动驾驶领域，SOME/IP是目前的主流。SOME/IP(Scalable Service-Oriented MiddlewarE Over IP) ，即“运行于IP之上的可伸缩的面向服务的中间件”，由宝马最早发明，也是最早使用以太网的车厂。SOME/IP属于应用层协议，它提供面向服务的通讯接口。SOME/IP定义的服务接口包含方法（Methods），事件（Events），字段（Fields）和事件组（Eventgroups），可以支持请求/响应模式的远程服务调用，也可以支持订阅/发布模式的消息通知。SOME/IP的访问方式分为事件通知（Notification）、远程过程调用（Remote Procedure Call，RPC）和访问进程数据（Getter、Setter）3种。其中，事件通知与传统CAN通信消息类似，服务端周期性或者事件变化时向客户端发送特定消息；远程过程调用是当客户端有请求的时候，向服务端发送一个请求消息，服务端根据情况返回响应；访问进程数据可以使客户向服务器端写入（Setter）或者读取（Getter）数据。

目前主流的面向服务的中间件有数据分发服务（Data Distribution Service, DDS）、基于IP的可扩展面向服务的中间件（Scalable service-Oriented MiddlewarE over IP, SOME/IP）、消息队列遥测传输协议（Message Queuing Telemetry Transport, MQTT）。DDS是由对象管理组织（Object Management Group, OMG）制定的一种面向服务的通信中间件协议。采用发布订阅模型，强调以数据为中心，提供多种服务质量策略（Quality of Service, QoS），以保障数据实时、高效、灵活地分发，可满足各种分布式实时通信的应用需求。

DDS在国防、航天、电网、医疗、能源等领域取得大量成功的应用，其优良的性能经过了长期的验证。在汽车领域，早在2018年，AUTOSAR AP在通信管理模块中加入了DDS技术；ROS2、Apollo CyberRT的底层也是基于DDS协议；Orin、Xavier等面向自动驾驶的系统级芯片SoC上也都预留了DDS的接口。DDS已被奥迪、大众等多家汽车厂商应用于智能驾驶、泊车充电、仿真测试平台等场景；据悉国内的造车新势力小鹏汽车等也已将DDS技术应用到量产车型上。

DDS能够实现低延迟、高可靠、高实时性的数据融合服务，能够从根本上降低软件的耦合性、复杂性，提高软件的模块化特性，数据分发DDS 是OMG提供的用于以数据为中心的连接的中间件协议、连接框架和应用, 应用程序接口（API）标准。它继承了分布式系统的组件，提供了低延时的数据连接、极高的可靠性和可扩展的体系结构，满足业务和任务关键型应用程序的需求。与SOME/ IP、MQTT相比，DDS具有以下特点：

1）SOME/IP 是针对汽车领域的中间件，在车载领域已经应用了较长的时间。MQTT适用于低带宽及不稳定的网络，但它依赖于一个中央代理。DDS本身是一个工业级别的通信标准，适用于多种应用场景，但用在汽车领域时可能需要做专门的裁剪。

2）相比于SOME/IP，DDS引入大量标准内置特性，在灵活性、可伸缩性等方便更具优势。

3）SOME/IP主要采用远程过程调用（Remote Procedure Call, RPC）的通信方式，服务器（server）和客户机（client）之间仍有一定的耦合性。而DDS采用发布/订阅机制，实现了通信双方在时间、空间和数据通信上的多维松耦合。

4）SOME/IP没有定义QoS机制，只能保证数据可靠，不能保证延迟。MQTT也具有保证稳定传输的机制的，但其仅支持QoS0、QoS1、QoS2的QoS策略。DDS具有丰富的QoS策略，能够满足高复杂性、高灵活性的数据流要求。

5）SOME/IP基于传输控制协议（Transmission Control Protocol, TCP）或用户数据包协议（User Datagram Protocol, UDP），只能在基于网络层为IP类型的网络环境中使用。而DDS基于实时发布订阅协议（Real-Time Publish-Subscribe, RTPS）可以有多种实现，且DDS独有的DDS Security、DDS Web功能可以为用户提供车-云-移动端一站式的解决方案。

国内百度的自动驾驶使用了DDS。

用DDS比较容易取得ASIL-D级认证。