上一篇文章详细阐述了整个SOA的架构特点、实现基础、应用优势和开发流程，让大家对整个SOA设计过程。整个核心思想是采用自上而下的方法进行设计，以改造在现有车辆程序和平台上实现的现有功能或系统的EE架构（逆向工程）。目前国内很多主机厂现有的功能开发流程都比较激进。发展较快后，无法实现平台化应用，无法进行分布式架构中众多模型间的软件复用。更不用说更高级别的集中式架构设计。这种没有具体逻辑功能架构的完整构建方式，往往会制约软件定义汽车的强烈需求。因此，在面向服务的SOA开发过程中，我们建议更多地分析网络拓扑结构、网络通信、ECUs平台架构、功能需求和用例场景，作为SOA改造的切入点。但如果功能比较复杂，还是需要使用逻辑功能架构来定义一个高质量完整的SOA。基于SOA的EE架构设计方法完全遵循自上而下的研发方法，将新功能或系统引入车辆程序和平台。该方法以给定的特性、系统需求、测试用例和逻辑功能架构为输入，由功能所有者在软件平台上设计为域控制器级别的通用基础服务类型，同时支持子系统和功能列表。对于上面提到的业务驱动的SOA开发方式，本文将结合业务分析的例子进行整体的描述。以下一代高端自动驾驶系统的开发为例，终端用户期望在目前已实现功能的基础上，进一步增加功能的应用场景，同时提升目前已实现功能的性能指标.SOA架构系统建模的基本原则SOA参考架构是对抽象的架构元素进行建模，独立于具体的解决方案、技术和协议。该参考架构可以有效解决服务消费者和提供者的交互问题，涉及关键要素（包括行为、信任、交互和控制）的参与、实现和管理。为SOA提供的服务流程模型包括描述、可见性、交互、策略等几个大模块。其中，服务描述用于定义、使用、部署、管理和控制服务所需的交互信息，涉及服务的可访问性、服务接口、服务功能以及与服务关联的策略信息。服务接口描述应该包括行为接口（Action）和信息接口（Process），信息处理需要使用信息交互方式MEP（这种交互方式可以理解为时序图）。服务可达性是指服务参与者能够相互定位和交互。这种可达性需要服务的位置和描述通信方法的协议等信息，并涉及了解端点、协议和服务的存在。服务功能是对所提供的服务在现实世界中可能产生的效果的定义。功能定义需要保证其功能效果符合技术规范的定义。下面我们将对基于SOA服务架构构建的ADAS系统进行详细的原理分析。整个基于SOA架构的开发过程可以概括为：对于整个SOA载体的开发过程，需要从整体上划分为两个层次的开发。一种是SOA的顶层服务开发，主要涉及面向服务的开发模式。功能定义阶段主要由FunctionOwner从整体功能设计的角度来把握，内容涉及以下内容：1.定义业务需求，包括对标市场主流机型的场景，接收功能配置列表项目组，并从售后的角度对用户需求进行调研，进而生成功能场景库。如果同时考虑自动驾驶系统的数据采集口，需要考虑场景数据的来源，包括自然采集数据、高精地图数据、标准规范文件、数据记录场景、道路等。交通规则。不同的场景库（如自然驾驶场景库、重组场景库、法律标准场景库、事故场景库、交通法规场景库等）。上述场景库可以通过ADAS功能安全测试生成预期的功能安全场景库，通过V2X终端功能测试生成V2X场景库。假设我们要实现点对点自动驾驶的最终目标，首先需要对目标进行分解，从而挖掘用户所有可能的使用场景。例如，需要及时进行加速、减速、变道、居中等操作。具体来说，就是对系统的感知、规划、决策等控制能力的拆解。在感知方面，附加在车辆上的多个传感器的能力要求被定义为产品能力（PC）。在规划和决策方面，基于检测到的感知信息进行目标级语义融合，进而生成可用的轨迹信息并预测轨迹。是否存在碰撞风险目标，整个过程需要在模块Module中的不同软件组件SoftwareComponent（SWC）中分别定义和实现。在决策过程中，上述子目标动作的行为被拆解。例如，加速和减速需要底盘动力系统的集成控制；对中控制需要对转向系统进行有效控制；，还需要控制车身系统（如转向灯）。2.构建Module服务架构Module架构实际上实现了整个SOA架构从底层硬件层到顶层硬件层的整个功能设计模型。该模块总结了其底层软件组件的SWC模块。他们实现产品功能并创建服务和算法来实现功能。从下面这个简单的SOA软件封装模型可以知道，它包含几个大的模块：如上图所示，Module模块向车内的消费者应用程序和系统提供车辆的原子信息和使用模式。所有管理或控制用户功能和传感器/执行器的应用程序都应使用元服务来评估该功能是否应由其自己的功能执行。这样做以对用户和系统有意义的方式提供了更好的安全性、健壮性和快速访问。基于ADAS开发距离，整个Module服务模块可以理解为实现ADAS功能的各种封装模块，如车身域、底盘域、电源域、娱乐域等，可以拆解成多个子模块模块的一层中的模块。每个子模块都可以定义自己的产品能力PC和软件组件SWC。3、分解模块产品能力从场景库中分解出对应的测试用例Usecase，每个Usecase对应统一建模语言的设计流程，包括对应的用例图、活动图、时序图。以上三张图至少需要对应功能设计中的时序图。下图a所示的用例图需要从用户的角度描述系统功能，并指出每个功能的操作符。图b显示了每个产品能力对应的时序图。时序图中的每个子单元是实现某个用户功能所需要调用的产品能力单元，调用过程遵循从上到下的流程。比如一个函数需要先进行函数自检，就需要在初始调用单元画一个回环箭头，调用自己的自检函数单元；如果要调用关联系统的实现函数，需要画一个箭头指向关联的实现单元，通过在箭头上赋值相应的调用函数名来实现对实现功能模块的调用。以上整个过程会涉及到系统的硬件架构设计，在后续的硬件部署中会详细介绍。对于上述功能定义的场景要实现，需要对自动驾驶系统相关的域控制器或传感器进行边界能力设计。这里我们称之为ProductCapability（PC），主要针对自动驾驶系统。产品能力的需求设计由系统设计架构师设计，需要判断需求是否适配对应的自动驾驶系统功能—>PC是否准确—>如果没有对应的PC，如何添加it——>如果是，哪个型号Module提供PC实现—>如果没有对应的配套Module，如何添加该Module（包括软件模块定义中考虑如何实现功能模块和非功能模块）。以上一系列问题都是我们需要重点关注的部分。4.模块软件组件能力分解功能软件开发阶段主要由软件模块所有者从整体功能软件开发的角度进行规划，包括所涉及的软件模块与功能所有者设计的功能之间的映射，以及相应的过程涉及软件。模块架构设计、软件概要设计、软件详细设计。整个软件设计过程主要需要与系统设计阶段的架构、功能、场景一一对应。同时，在Module的总体设计中，主要是实现产品软件组件（SoftwareComponent）的静态接口设计，整个设计过程需要与前述的产品能力PC（即，每个产品能力PC都需要有相应的软件组件SWC来实现）。具体的SWC设计方法和映射原理将在后续文章中详细阐述。5、与功能安全和预期功能安全相关的设计过程如前所述，在正向设计过程中，同步设计需要同时考虑功能安全。自上而下，需要在场景库设计阶段制定功能安全目标Saftygoal。危害分析与风险评估HARA分析是在定义用户案例阶段进行的，以识别项目功能故障导致的危害，对危害事件进行分类，进而定义相应的安全目标，避免不可接受的风险。在定义活动图和时序图的过程中，需要同时进行整个功能安全需求FSR设计。在模型详细设计阶段，需要根据系统功能UML设计阶段的时序设计和接口设计，在软件阶段进行更详细的SWC动态时序设计和详细的接口设计。同时，在模型的详细设计阶段，功能技术安全要求设计TSR也可以同步进行。技术安全要求（TSR）是功能安全要求（FSR）的细化，它细化了功能安全的概念，并考虑了功能概念和初步架构。通过分析技术安全要求来验证是否符合功能安全要求。因此，FSR是项级功能安全要求。对于系统级的开发，需要将FSR细化为系统级的TSR，然后才能进行完整的系统设计。总结本文对整个SOA架构设计过程进行了详细的流程分析，包括收集用户需求，根据用户需求定义使用场景，根据使用场景构建不同的模块实现不同的功能子项，每个功能子项item需要定义有几个产品能力模块，接口模块，软件组件模块。最后，SWC调用相应的函数调用I/O模块硬件和底层驱动模块。同时，从正向开发的角度来看，在自上而下的设计过程中，需要充分考虑与功能安全/预期功能安全相关的safetygoal、FSR、TSR设计过程。
