面向服务的架构SOA的出现可以打破车内静态交互模型，并且建立功能灵活治理的系统架构。确保新增功能的实现可以与车辆原有的系统架构、驱动方式、通信方式相匹配。（SOA）总体思路是设计组件模型，将不同的应用功能服务进行拆分，并通过定义恰当的通信接口将相应的服务串联起来。接口定义是独立于实现服务的硬件平台、操作系统和编程语言。确保构建在不同系统中的服务可以以一种统一和通用的方式进行交互。
SOA是基于系统的概念，这种系统是由一组服务组成的，其中一个服务可以轮流使用另一个服务，应用程序可以根据各自的需要调用一到多个服务。这一点上，SOA与Autosar的工作方式是一致的，因此，当前自动驾驶系统的开发中往往采用了基于Autosar的SOA设计模式。
一、基于Autosar的SOA软件架构
基于SOA开发模式的软件架构（见下图）主要在于通过软件抽象层——运行时环境 (RTE) 拆分独立于硬件的应用软件（ASW）和面向硬件的基础软件 (BSW)。一方面，这个抽象层能够为OEM自动驾驶系统开发特定的、有竞争力的软件应用程序。另一方面，它简化了独立于 OEM 的 基础软件标准化，其中，基础软件进一步分为以下几层，“服务”、“ECU 抽象”、“微控制器抽象”。此外，它是 ECU 软件可扩展性的前提条件。
运行时环境RTE是从基础软件中抽象出应用层，并组织它们之间的数据和信息流量。这构成了在应用层面向组件、独立于硬件的软件结构的基础，软件模块可以作为独立的单元存在。
例如，下一代自动驾驶系统采用SOA软件模块架构，其所有顶层功能都由底层软件模块实现。这些软件模块共同构成了应用程序。各个软件模块仅直接与 RTE 通信。因此，无论是在 ECU 内还是超出 ECU 边界，都设计了清晰的通信边界。通过这种独立性，可以在不了解使用或计划的硬件情况下开发软件组件，或者更确切地说是在 ECU 之间分配现有软件模块。
二、基于SOA构建软件设计方法
除了基于SOA的软件架构模块设计外，AUTOSAR针对汽车软件开发提出了一套标准化的方法论，构建 ECU 中的软件模块，将各种 ECU 集成到具有不同总线系统的车辆通信网络。它定义了通用工件和相关活动，特别是活动的依赖关系。
在 SOA的设计方法中可以使用AUTOSAR的相关信息，定义了一种具有语义约束的正式数据交换格式，这种数据信息作为标准描述了存储在 AUTOSAR XML (.arxml) 文件中，这种ARXML文件实际是由顶层SOA系统架构设计者通过构建相应的SWC组件接口来生成的。软件组件描述为应用软件提供了标准化的组件模型，系统描述定义了系统上的纯软件层与物理系统架构之间的关系，许多工具使用这些描述来配置和生成AUTOSAR 中RTE的基础软件。
基于SOA架构的流程设计方法的原理如下图所示。其中各框图表示了带有交叉链接的 ECU 实例。它描述了网络拓扑、每个通道的通信以及各种 ECU 上软件模块的分配。
基于Autosar的SOA软件架构设计方法
除了具备描述汽车行业 E/E 系统的基本能力外，还有许多方面需要实际交换格式的支持，例如可以通过技术文档（包括规范、定义、技术要求等）、接口需求表等可追溯性来贯穿整个软件生命周期。这种集成的变体管理允许 OEM 和供应商共同深入到基本的 AUTOSAR 产品线，并在必要时与其合作伙伴交换相互的信息，对这些变体的共同理解和一致解释是联合开发项目成功合作的关键因素。
各种SWC组件接口调用示意图
SOA中的应用程序接口用于确保应用程序模块与 RTE 进行有效链接。其中，AP Autosar并未标准化应用程序的内部功能流程，例如算法，而是将在应用程序之间交换的信息。
一方面Autosar使用专用语法将基本接口机制进行了标准化。这种标准化接口规范允许软件设计人员和开发人员独立于任何特定硬件或 ECU 来开发软件模块，这种软件模块可以在包含其使用的数据类型、单位和缩放因子下进行扩展或重用。另一方面对车辆域主体中应用程序接口的语义、内涵、舒适性、动力传动系、底盘以及乘客和行人保护进行了标准化。重点是广泛引入应用程序的接口规范，以重点突破软件模块的重用和交换。最后，标准化应用程序接口的使用对于应用程序的重用至关重要。
三、系统架构-虚拟功能总线
为了开发功能系统架构，AUTOSAR 引入了虚拟功能总线的概念——VFB（Virtual FunctionBus）。为了避免误解，应该明确指出：AUTOSAR 已经指定了 VFB 概念。这个概念在市场上可用的各种系统架构工具中实现。
VFB 允许描述整个系统中应用模块之间的功能交互，此描述独立于实际 ECU 的架构和实施的网络。通过这种方式，VFB 将应用程序从硬件中抽象出来，在这里，软件组件被分配给 ECU，在每个 ECU 中，VFB 的功能由 RTE 和底层基础软件实现。在进一步架构构建过程中，功能系统架构被映射到物理架构上或者说在 ECU 和网络拓扑上。SOA中将单个应用程序描述为软件组件 (SWC)。VFB 既提供了它们之间的通信机制，也提供了使用基本软件服务到软件组件的机制，各种机制由所谓的端口表示。
四、SOA软件分层
1、应用软件
SOA软件架构的层模型将应用软件以软件组件的形式放置在应用层中，可以将软件组件分组为在外部再次充当软件组件的组合。通过这个通用组件概念，可以将软件组件的任何嵌套层次结构实现为一个系统。应用软件可以独立于硬件进行设计和开发。
软件组件通过端口进行通信，每个端口代表某种通信机制。应用程序之间通信中最重要的机制是“发送方-接收方”用于由数据发送方发起的通信，以及“客户端-服务器”用于接收方发起的通信。除此之外，还有用于过程控制（外部触发事件）或用于访问某些参数（校准、操作模式、非易失性存储器）的更多端口。每个端口都有一个接口，用于确定要通信的数据类型。AUTOSAR 已在编程语言 C 中定义了端口的精确映射。下图显示了 ECU 内以及不同 ECU 中的应用程序之间的通信路径。
软件组件在 AUTOSAR中由 “软件组件模板”做特定描述。除了端口和接口的描述之外，这还包含所谓的内部行为。在 AUTOSAR 的上下文中，“内部行为”是描述与时间或事件相关的过程控制（事件和调度）相关的组件。这包括“可运行实体”的定义，即底层操作系统可在事件或时间上调度的最小软件实体。需要说明的是，要在组件中明确实现的算法不属于“内部行为”。
在实践中，有几种典型的方法来填写或编辑软件组件描述。许多基于模型开发的设计工具如EA、Rapshody等，可以从图形模型中生成软件组件描述，并允许编辑相应的条目。此外，RTE 生成器通常允许编辑软件组件描述。对于具有特定硬件要求的应用程序，例如作为依赖于某些传感器或执行器的软件，AUTOSAR 提供了所谓的传感器/执行器软件组件，其中可以在软件组件描述中注明此类约束。
2、实时运行环境
AUTOSAR 运行时环境 (RTE) 从基本软件的任何实现细节和控制设备的硬件中提取应用程序。它表示特定 ECU 上 VFB的运行时实现。RTE 提供应用程序之间的通信机制和访问基础软件服务的机制。这还包括为通信提供数据缓冲和排队。RTE 的实际程序代码取决于应用程序及其通信、使用的基础软件服务和调度。在实践中，代码是由 RTE 生成器根据软件组件描述信息创建的。
严格来说，RTE 是一种“中间件”层技术，它可以通过去中心化网络实现应用层组件的重新定位。
3、基础软件
基础软件通过 RTE 为应用程序提供所有系统服务和功能。尽管基本软件的功能对于应用程序来说是必不可少的，但车辆用户通常不会很好地注意到这些功能。随着对硬件的依赖性越来越大，基本软件进一步划分为多个层次：即服务层、ECU 抽象层和微控制器抽象层。反过来，每一层都包含代表精确指定功能范围的单独模块。AUTOSAR 基础软件总共包含大约 80 个不同的模块，标准对每个模块都有一个要求和软件规范。其中模块的功能行为及其接口是用 C 定义的，因此一个模块的两种不同但符合标准的实现可以直接互换。基本软件模块的功能行为参数化及其配置使用与应用程序组件相同的形式描述机制。控制单元基本软件模块的配置描述总结在ECU配置描述中。
五、基于Autosar的SOA 服务
服务层包括通信服务、诊断协议、存储服务、ECU工作模式管理等系统服务，以及作为独立模块的AUTOSAR操作系统（OS）。AUTOSAR OS 基于实时系统标OSEK/VDX，在某些领域得到扩展，但在其他领域也受到限制。它是静态配置和缩放的，并提供基于优先级的实时行为和中断处理。在运行时，可以使用各种用于内存访问或时间行为的保护机制。AUTOSAR OS 也适用于小型和较低性能的微控制器，同时也支持多核对代码、数据使用和使用多个内存分区，服务的模块是独立于硬件的操作系统。这些系统服务可通过 RTE 提供给应用程序，应用程序不能直接访问底层的基本软件模块。这是保留提供服务作为其功能的一部分从而访问 ECU 或微控制器资源。服务模块及其底层模块也称为功能栈，例如 FlexRay 的通信栈。此类堆栈有时会作为一个大型软件单元来实现和集成，而没有 AUTOSAR 定义的底层模块结构。虽然这破坏了抽象原则并降低了灵活性，但由于实现的效率和性能可能更高，因此在 AUTOSAR 中使用函数堆栈进行处理很普遍。
六、硬件抽象
服务层主要用于硬件抽象。首先，ECU 抽象层将 ECU 布局（即外围模块如何与微控制器连接）与上层分离。尽管这一层是特定于 ECU 的，但它独立于微控制器。下一级抽象是由微控制器抽象层实现的，其中包括微控制器特定的驱动程序。例如，这些驱动程序是用于数字输入和输出的 I/O 驱动程序，或用于将模拟信号转换为数字值的 ADC 驱动程序。因此，AUTOSAR 标准直接支持标准化硬件。
复杂驱动层用于处理特殊情况，例如，用于控制具有特殊实时要求或具有特定机电硬件要求的复杂传感器或执行器。此类模块并未标准化为 AUTOSAR 基本软件模块，因为这里需要汽车制造商或供应商的特定专业知识和知识产权。然而，复杂的驱动程序和标准化的模块必须满足 AUTOSAR 基础软件中接口机制的要求。
七、基于Autosar的SOA系统配置
在 AUTOSAR 的上下文中，系统是指网络控制单元的组合或集成，其中可能包括车辆的所有 ECU。系统配置遵循 VFB 级功能系统架构的开发。在设计系统配置时，会根据系统的实际物理架构做出决定。这些决定主要与系统拓扑有关，即哪些控制单元可用以及它们如何连接。对于每个控制单元，都有关于处理器架构、处理器容量、内存、接口和外围设备或信号方法的资源描述。网络拓扑的描述范围从总线系统到各个通道的通信矩阵。此外，它还包括确定哪个应用软件组件应该在哪个控制单元上运行，所有这些信息都记录在系统描述中。在实践中，这可以通过系统架构设计工具以及 VFB 设计（也称为系统生成器）或通过基本软件模块的配置工具来完成。
系统配置成功需要通过对各个控制单元的进一步配置，最后通过软件集成来完成，每个 ECU 都是独立的，即如果需要，它可以并行运行。此外，某个控制单元的所有相关信息都被复制到系统配置之外的 ECU 描述中。这被命名为系统描述的 ECU 摘录。ECU 描述还汇总了每个基本软件模块的配置描述。基本软件配置的许多参数直接来自系统描述软件组件的描述。其余的自由参数通过使用基本的软件配置工具来设置。在几乎所有基本软件模块的配置步骤之后，属于配置的代码由生成器生成——就像在 RTE 中一样。
应用软件组件的实现是算法和编码的创建，可以与系统配置完全并行完成，因为这一步独立于硬件。最终，基础软件的整个代码连同 RTE 代码以及所有应用软件组件的代码都集成到每个控制单元的 ECU 软件中。
八、总结
整体上讲，面向服务的SOA架构设计主要包含五个步骤：梳理整车功能、规划SOA架构、服务定义、服务矩阵和ARXML设计、服务验证和仿真；SOA不是一种具体的技术实现，而是一种模板软件架构，而AP AUTOSAR则称是一个模板SOA。如何利用Autosar构建好的SOA模型是我们需要特别关注的。本文详细阐述了面向服务的SOA软件设计过程，以Autosar为基础分析软件架构及其设计方法、系统配置、硬件抽象、软件分层等。
来源：焉知智能汽车 作者：Jessie
