软件定义汽车时代，面向服务的软件架构（Service Oriented Architecture, SOA）为软件定义汽车提供了一套良好的解决方案。
SOA将车辆传统的面向信号的架构升级为面向服务的架构，面向服务的架构是一种系统架构设计的方法论，通过将系统的能力抽象成多个服务，并运用多个服务之间的依赖关系来满足车辆系统的多种需求。
汽车SOA常采用上层应用程序+中间层操作系统+底层硬件的分层开发模式，实现了软硬件解耦。SOA将上层应用程序的不同功能单元进行模块化，定义为不同的服务（Service），服务是可发现的软件实体，服务之间可以通过服务接口实现相互访问，并且可以动态发现和调用其他服务。服务接口的设计采用标准的接口定义和通信协议，使服务独立于硬件平台、操作系统及应用程序内部软件代码。
SOA架构具备以下特点：
▲ 复用性：通过服务之间的编排，重组，单个服务可以在不同的应用程序中重复使用；
▲ 灵活性：服务独立于硬件和操作系统，支持跨车型、跨平台使用，可实现灵活部署；
▲ 屏蔽异构性：服务之间采用的标准化接口，屏蔽不同硬件、软件、开发语言间的差异，更容易与其他系统集成；
▲ 增强互操作性：SOA架构依赖于标准化的中间件，更易于实现数据共享，软件程序的互操作性较高；
▲ 拓展性：在不改变硬件设施的前提下可以根据业务需求增加新的服务，且单个服务可以独立的拓展和升级。
面向服务的架构开发为主机厂实现软件定义汽车提供了可能性，SOA可帮助企业构建灵活，可拓展，可维护的系统，支持多个平台使用，快速响应市场变化和业务需求。
SOA架构的具体优势主要体现在以下几个方面：
▲ 为汽车平台未来的发展提供了基础，ECU的升级（如版本升级，功能升级，信号升级）只需变更上层代码，无需变更底层硬件，为未来功能的拓展和更新提供了保障，形成更大的汽车开发生态系统。汽车销售后，整车功能可以持续升级迭代，延长了主机厂的服务周期。
▲ 节约成本，传统的汽车架构采用面向信号的方式，控制器由不同的供应商提供，软硬件具有较强的耦合关系，集成难度大，通信困难，复用性差，如果想升级功能或增加新的功能，从软件代码到硬件到通信链路整体都需要重新配置。SOA可实现软硬件解耦，在脱离硬件设备的基础上实现功能的升级和替换。
▲ SOA架构适配多个车型，软件的升级和更新可以为智能汽车带来更多的使用场景和功能，基于SOA架构，为汽车应用开发提供一个标准的基础平台，主机厂可在现有的架构平台之上运用服务，实现更多的功能使用场景，灵活构建系统。
▲ 增加供应商多元化选择，主机厂由硬件制造转型为软件开发，整车功能软硬件不再受制于供应商，主机厂可在已有的硬件设施基础上，改进软件代码，实现功能的拓展。
将应用程序抽象成服务，需要综合考虑多方面的因素，如技术，成本，安全等。服务发布的信息传达了它的目的和能力，并给潜在用户提供了关于该服务应该如何通过程序进行调用和使用的详细信息，没有发布的服务信息用来保护它和未来用户之间形成的耦合关系的完整性，从而保障服务在满足契约的前提下进行演化的能力。
服务抽象的原则一般以划分层级的原则进行设计，服务进行分层管理，将相同类型的服务打包到相同的服务层，决不允许将不同类型的服务放到同一逻辑层，尽可能做到服务组合，而非迭代继承服务。
一般划分为三个层级：基础服务（Basic Service）、扩展服务（Extended Service）以及应用服务（Application Service），如下图所示。
基础服务提供车辆最基础的功能，和电子电气硬件（如传感器）强相关，比如摄像头数据的提供和处理功能；
扩展服务相对更复杂，其功能的实现需要调用多个基础服务，如不同传感器（毫米波雷达、激光雷达，摄像头等）的数据融合功能；
应用服务一般为用户可感知的功能，并且与车辆场景强相关，如驻车辅助功能，应用服务的实现，依赖于一个或多个扩展服务。
目前适用于SOA架构通用接口的中间件主要包括：SOME/IP，DDS，MQTT，HTTP，各中间件的特点如下：
▲ SOME/IP：位于传输层之上的应用层通信协议，动态的创建服务提供者和服务使用者之间的连接，服务上线后广播告知域内其他节点，其他节点收到服务广播后，请求或者订阅相关服务接口。
▲ DDS：新一代分布式实时通信中间件协议，采用发布/订阅体系架构，强调以数据为中心，提供丰富的QoS服务质量策略，以保障数据进行实时、高效、灵活地分发，可满足各种分布式实时通信应用需求。
▲ HTTP：互联网常用的服务协议，使用GET/POST等机制来获取或者设置相关数据。在汽车行业内，一般用于车内节点和云端无线通信协议，传输大于10MB的数据。
▲ MQTT：互联网常用的服务协议，基于订阅和发布机制来获取或者设置相关数据。在汽车行业内，一般也用于车内节点和云端无线通信协议，传输小于10MB的数据。
HTTP，DDS，MQTT和SOMEIP均可用于实现SOA架构的通信，只是负责的场景不同，SOME/IP，DDS协议用于车内节点之间的服务通信，HTTP，MQTT用于一般用于车内节点和云端无线模块通信。
服务治理可以实现服务的复用，降低开发成本，提高服务质量，提高服务的可靠性和安全性，对于服务化架构开发非常重要。服务治理包含如下部分：
▲ 服务设计：服务有详细的设计要求，确保服务的设计满足业务需求。
▲ 服务实现：根据服务接口实现代码开发，确保服务开发质量和可靠性。
▲ 服务部署：服务可成功部署至目标环境中，服务具备跨平台属性，在不同环境、硬件、系统中部署一个或多个实例，以达到最大化的重用率。
▲ 服务管控：服务管控包含服务监控和服务管理，服务监控是指服务运行过程中，及时发现和解决问题，保证服务的稳定性和可靠性；服务管理是指在整个服务的生命周期内对服务进行管理，包括版本控制、服务状态管理、服务执行管理、安全管理、数据管理等，给服务乃至整个系统提供强有力的性能保证。
▲ 服务的权限配置：服务发布后，可控制对外的授权管理，保证只有被授权才可以使用服务。
▲ 服务升级：服务可进行升级和更新，以满足业务需求和技术要求。
SOA的目的是建立驱动汽车平台不断升级的架构，服务架构需要深入理解业务本质，业务本质是根基，根基打好了，我们才能在此基础上追溯，抽象，归纳，演绎不同场景，拓展业务，升级业务，因此，汽车架构平台的升级脱离不开基础平台。
如何去深入理解业务本质，可参考传统的电子电气架构开发方法，传统的汽车电子电气架构采用整车V模型的开发方法，即从整车的需求分析到功能设计，到系统设计，再到软硬件的实现，架构搭建起需求设计和软硬件实现之间的桥梁。SOA架构在传统架构分析方法上，增加服务概念，进行服务设计及服务通信矩阵设计。
SOA架构设计流程大致可拆分为以下几点：
▲ 需求分析
需求分析包含两个方面，一个方面是整车平台级别的需求，需要综合考虑多方面因素，如目标车型的类型，配置，定位，市场定价，性能，以及销售区域等，得到功能清单；另一方面是考虑功能层面的需求，从用户，车辆，使用场景三者关系出发，梳理出用户在特定场景下使用该功能的期望表现，即功能的UseCase，基于UseCase分析，得到功能定义的需求项，包含功能性需求，非功能性需求，约束性需求。
▲ 功能设计
为了满足在功能需求分析阶段定义的各项需求，提出产品能力（Product Capability，PC）这个概念，PC是车辆为了满足某项功能需求而需要提供相关能力的抽象描述，通过PC来划分模块的职责边界，PC通过接口Operation对外提供具体的能力操作。总体来说，功能设计是通过PC间Operation接口的时序调用来表征体现的。PC与UseCase进行关联，完整的PC库建立后，可以针对每一个UseCase绘制对应的时序图。如下图所示：
▲ 模块设计
将功能设计阶段提取的车辆具备的各项能力分配到不同模块，在模型库中进行模块架构搭建，针对模块内部实现方案进行详细设计，遵循“高内聚、低耦合”的原则进行SWC划分和服务提取。
经过各方面的评估（实时性、复用性、安全性、可拓展性等）认为哪些SWC适合服务化、可将其抽象为服务，基于服务，设计服务的参与者（服务提供者、服务消费方），服务接口，同时根据逻辑功能架构设计服务的依赖关系。
服务接口设计应遵循每个服务（Service）可以包含一个或多个服务接口，每个服务接口具有唯一的类型（如SOME/IP服务接口分为RR Method、FF Method、Field_Setter等）。一个服务接口对应一个服务接口数据元素。服务接口设计参考SOA中间件原则，根据不同的使用场景选择不同的接口协议。
完成服务设计后，根据硬件架构，结合软件架构以及服务部署原则，将服务部署到对应的运行环境中。
以上介绍了SOA架构开发过程中的基础知识，关于使用具体中间件下服务的设计与实现，如基于SOMEIP的服务通信设计，请参考怿星科技公众号的其他文章，欢迎持续关注我们的研究。