前述文章已经对整个SOA的架构特性、实现基础、应用优势及开发流程进行了相应的详细阐述，从而对于整个SOA的设计流程已经有了大概了解。整个核心思想是采用自上而下的方法进行设计，以改造现有车辆程序和平台上实施的现有功能或系统的EE架构(逆向工程)。

当前国内较多的OEM的现有功能开发过程都是比较激进的，以较为迅速的方式开发出来后，无法实现平台化应用，在分布式架构中的很多车型之间就无法进行软件重用，更别说更高级别的集中式架构设计方式了。这种无具体逻辑功能架构的完整构建方式往往制约了对于软件定义汽车的强烈需求，因此在以面向服务SOA开发的过程中，我们更多的是建议将网络拓扑、网络通信、ECUs平台架构、功能需求和用例场景作为分析作为SOA转换的起点。但是如果特性很复杂，那么仍然有必要使用逻辑功能架构来定义高质量和完整性的SOA。

基于SOA的EE架构设计方法完全遵循一种自顶向下的研究开发方法，从而引入到车辆程序和平台的新特性或系统。这种方法是以给定特性、系统需求、测试用例及逻辑功能架构为输入，在软件平台上由功能所有者Function Owner设计以域控制器级别公共的基础服务类型，同时支持子系统和功能列表。

对于前文所述的业务驱动型SOA开发方法来说，本文将针对性的以一个业务分析的例子进行整体说明。以开发下一代高阶自动驾驶系统为例，终端用户期望在当前实现的功能基础上，进一步增加功能适用场景，同时提升当前已实现功能的性能指标。

SOA架构系统建模基础原理

SOA 参考架构是对抽象架构元素进行建模，独立于特定的解决方案、技术、协议。该参考架构可以有效解决服务消费者和提供者的交互问题，涉及其中的关键要素（包含行为、信任、交互、控制）的参与、实现和管理。针对SOA所提供的服务过程模型包含描述、可见性、交互、策略等几个大模块。其中服务描述用于进行定义、使用、部署、管理等方式控制服务所需的交互信息，这些信息涉及服务可达性、服务接口、服务功能、服务相关联的策略信息。

服务接口描述应包含行为接口（Action）和信息接口（Process），其中信息的处理需要使用信息交互模式MEP（这种交互模式可理解为一种时序图）。服务可达性是为了使服务参与者能够相互定位和交互，这种可达性需要有服务位置和描述通信方式的协议等信息，并涉及了解服务的端点、协议和存在性。服务功能是针对所提供的服务可能在真实世界中产生的效果的定义，该功能定义需要保证其功能效果满足技术规范定义。

接下来，我们将基于SOA的服务架构构建针对ADAS系统的实例进行详细原理分析。整个基于SOA架构的开发流程可概括如下图：

对于整个SOA的整车开发流程来说，需要从整体商划分为两个层面的开发，其一是SOA的顶层服务开发，该层主要涉及面向服务的开发模式。

功能定义阶段主要是由功能负责人Function Owner从整体功能设计角度上进行把握，其内容涉及如下：

1、定义业务需求

包括对标市场主流车型的场景，接收项目组功能配置清单，从售后的角度对用户需求进行调研，随即生成功能场景库。如果同时考虑自动驾驶系统的数据采集端口，需要考虑场景数据来源，包括自然采集数据、高精地图数据、标准法规文档、数据记录场景及道路交通法规等可以生成不同的场景库（如自然驾驶场景库、重组场景库、法规标准场景库、事故场景库、交通法规场景库等）。如上的场景库又可以通过ADAS功能安全测试生成预期功能安全场景库，通过V2X终端功能测试生成V2X场景库。

假设我们需要实现点对点自动驾驶这一终极自动驾驶目标，则需要首先对该目标进行分解，从而挖掘用户的所有可能使用场景。比如需要进行适时加速、减速、换道、对中等操作。在细化下去，就是包含其感知、规划及决策的系统控制能力拆解了。感知方面则是对车辆附着的多个传感器分别进行能力需求定义Product Capability（PC），规划决策方面则是会根据检测的感知信息进行目标级语义融合，然后生成可用的轨迹信息，并预测该轨迹是否有碰撞风险目标，这整个过程需要在模块Module中不同软件元组件Software Component（SWC）中进行分别定义和实现。决策执行中对如上各个子目标动作的行为拆解，比如加减速则需要对底盘——动力系统进行一体化控制，对中控制则需要对转向系统进行有效控制，换道则除了转向系统EPS外，还需要对车身系统（如转向灯）进行控制。

2、搭建Module服务架构

Module架构实际是实现整个SOA架构从底层硬件层到顶层硬件层的整个功能设计模型，该模块汇总了其下软件组件SWC模块，它们实现了产品功能并创建服务和算法来实现功能。从如下简单的SOA软件封装模型中可知其中包含几个大模块：

如上图所示，Module模块将车辆和使用模式的原子信息提供给车辆中的消费应用程序和系统。所有管理或控制用户功能和传感器/执行器的应用程序都应使用元服务来评估该功能是否应由其自身的功能执行。这样做可以提供更好的安全性、健壮性，以用户和系统有意义的方式实现快速访问。

以ADAS开发距离，整个Module服务模块可以被理解为实现ADAS功能的各个封装模块，比如车身域、底盘域、动力域、娱乐域等可分别拆解为module中其中一层的多个子Module。各个子module又可以定义自己的产品能力PC和软件组件SWC。

3、分解Module产品能力

从场景库分解出相应的测试用例Usecase，各Usecase对应着统一建模语言设计过程，其中包括相应的用例图、活动图、时序图。如上三种图形在功能设计中至少需要有时序图相对应。

如下图a所示用例图需要从用户角度描述系统功能，并指出各功能的操作者。图b所示为针对各个产品能力所对应的时序图，时序图中各子单元是实现某一个用户功能所需要调用的产品能力单元，调用过程遵循从上至下过程。比如，如果某个功能先要进行功能自检，就需要在初始调用单元中画出回环箭头来调用自身的自检函数单元；如果要调用关联系统的实现函数，则需要画出箭头指向关联实现单元，并通过在箭头上赋予相应的调用函数名称来实现对该实现函数模块的调用。

如上整个过程会涉及系统的硬件架构设计，将会后续硬件部署中进行详细介绍。对于要实现如上述功能所定义的场景，需要设计自动驾驶系统相关的域控制器或传感器进行边界能力设计。这里我们称之为产品能力（Product Capability，PC），这种产品能力主要是针对自动驾驶系统。产品能力的需求设计是由系统设计架构师进行设计的，他需要判定该需求是否能够适配对应的自动驾驶系统功能——>该PC是否准确——>如果没有对应PC，该如何新增——>如果有，该PC实现方式是由哪个模型Module来提供——>如果没有相应的支撑Module，该如何新增该Module（包括考虑在软件模块定义中如何实现功能性模块和非功能性模块）。

如上这一系列问题都是我们需要重点考虑的部分。

4、分解Module软件组件能力

功能软件开发阶段主要是由软件模块负责人Module Owner从整体功能软件开发角度进行规划，其中包含涉及的软件模块与功能负责人设计的功能进行映射，相应的过程涉及软件模块架构设计、软件概要设计、软件详细设计。整个软件设计过程主要是与系统设计阶段的架构、功能、场景均需要进行一一对应。同时，在Module概要设计中主要是进行实现产品软件组件（Software Component）SWC静态接口设计，整个设计过程还要与前述产品能力PC进行相互映射（即每个产品能力PC都需要有一个相应的软件组件SWC来实现）。具体的SWC设计方法和映射原理会在后续文章中进行详细阐述。

5、功能安全与预期功能安全相关的设计过程

如上正向设计过程中，需要同步考虑功能安全进行同步设计。从上至下需要在设计场景库阶段制定功能安全目标Saftygoal。在定义用户案例阶段进行危害分析与风险评估HARA分析，识别项目的功能故障引起的危害，对危害事件进行分类，然后定义与之对应的安全目标，以避免不可接受的风险。在定义活动图和时序图过程中需要同时进行整个功能安全需求FSR设计。

在模型详细设计阶段，需要根据系统功能UML设计阶段的时序设计、接口设计来进行软件阶段更为详细的SWC动态时序设计、详细接口设计。同时，在模型详细设计阶段还可以同步进行功能技术安全需求设计TSR。技术安全要求(TSR)是对功能安全要求(FSR)提炼,细化了功能安全的概念,同时考虑功能性的概念和初步的体系架构。通过分析技术安全需要来验证符合功能安全需求。因此，FSR是item级的功能安全要求,进行系统阶段的开发,需要将FSR细化为system级的TSR，然后可进行完整的系统设计。

总结

本文对整个SOA的架构设计过程做了详细的过程分析，其中包括搜集用户需求，根据用户需求定义使用场景，根据使用场景构建不同的Module实现不同的功能子项，各个功能子项又需要定义自己的产品能力模块、接口模块、软件组件模块几个。最后由SWC调用相应的函数调用I/O模块硬件和底层驱动模块。同时，从正向开发的角度考虑，在自顶向下的设计过程中，需要充分考虑功能安全/预期功能安全相关的Saftygoal、FSR、TSR几大设计流程设计。​