一、SOA架构的优势
整车电子电气架构EEA是一个复杂的系统工程，需要从多个维度进行开发，不仅是架构平台的功能需求Feature，同时还要考虑成本、性能、可靠性、开发可行性、环境优好性、鲁棒性、可用性、功能安全、信息安全等方面，为了设计一个好的架构，各个OEM需要根据自身公司愿景、使命、目标、产品定义进行上述质量属性的优先级排序，高优先级的质量属性在进行架构评估时可承担更多的权重，如果说我们把所有上述质量属性看的同样重要，就等于说一个也不重要。 那么近年甚嚣尘上的SOA能够带来那些特性呢？我觉得其最大的优势还是灵活性和可扩展性，面对智能化汽车功能的快速迭代，OEM需要更加敏捷的软件开发模式，SOA架构服务的抽象、服务自治、服务松耦合、服务可重用等特性从而为OEM带来了更多的灵活性以及面向未来不可知业务的可扩展性。如下图是一个具体的实例来说明SOA架构的灵活性：在Cental&Zone架构中区域控制器下面作为智能传感器/执行器的ECU还是在AutoSAR CP或其他Free RTOS上进行开发的，如果要单独更新某个小的功能，在开发阶段需要重新配置ECU RTE，在集成编译阶段以整体ECU软件为单元进行编译，在部署阶段需要部署ECU的整个软件。而在中央计算单元VCM（Vehicle Computer Module）采用面向服务架构SOA当需要在车端安装一个新的APP，在设计阶段，包括设计、编译、集成和部署的整体过程都是独立自主，可单独编译以及独立的动态部署，实现与我们手机安装APP一样的效果。
注：上面的这个实例简单理解就是我们以前通过OTA来更新车端嵌入式ECU 的软件实际是FOTA，类似于我们每次需要在手机上增加一个功能都需要更新整个操作系统一样，费时、费力且用户体验差，而通过SOA在车端增加功能就像我们目前在手机上安装软件一样（SOTA），简单、快捷且在下载软件的同时不影响手机的正常使用。 二、SOA架构的开发方法2.1 MBSE SOA开发方法概览前面说到SOA架构的优势，目前行业内不论国外还是国内，不论乘用车还是商用车基本已经达成共识，SOA一定是未来智能汽车的发展趋势，但是对于怎么设计服务、服务的颗粒度大小、怎么实现服务重用还在不断探索，我这边根据以往的经验以及自己的思索与各位同仁分享基于模型的SOA架构开发方法，其主要分为如下几个阶段：a)需求分析：该阶段主要的工作是以Function List为输入进行用例Use Case分析，采用用例驱动的开发方法可以建立需求和功能之前清晰的追溯关系，可更好的应对智能汽车时代需求的快速迭代，通过用例分析收集所有相关方对车辆功能的需求，并将用例UseCase与需求Requirement进行映射关联，该阶段可输出架构设计文档FDR（Function Description Requirement）;b)功能设计：对需求分析阶段的每一个Use Case进行功能实现逻辑的设计，运用UML动态图（序列图、活动图、状态机）以及UML静态图来表达PC(Product Capability)之间的交互，以及PC和Use Case之间的映射关系，同时将用户级别的需求分解到PC层级，并将PC以及PC层级的需求分配到对应的模块Module，该阶段可输出架构设计文档FR(Function Realization);注：关于PC的概念以及PC与我们通常说的逻辑功能架构LC(Logical Component)的区别在下面功能设计详述。c)模块设计：前面两个阶段主要是功能开发工程师（Function Owner）的职责，而接下来在模块设计阶段系统工程师(System Owner)依据模块架构（后面详述）划分的模块职责以及分配的PC及PC需求，承接功能设计的需求进行模块详细技术方案的设计，划分SWC、设计服务接口、服务的依赖关系，以及基于服务的功能实现方案设计，同时将SWC/服务部署到ECU，此阶段可输出架构设计文档MRD(Module Requirement Description);EE芯视频推荐 d)ECU开发：模块设计阶段将各模块的SWC部署到平台网络拓扑架构中的各个ECU中（包括AutoSAR CP以及AutoSAR AP ECU），从而可形成ECU开发的输入需求，该阶段可输出架构设计文档SWRS（Software Requirement Specification）;e)网络通信设计：在进行SWC到ECU的部署后可导出Signal List，Service List，用于下游通信的设计（CAN、LIN、Ethernet），本话题可在后续文章详细描述架构设计与通信设计怎么有效衔接，怎么保证架构功能设计与通信设计的一致性等内容。
图2：MBSE SOA开发流程
2.2 SOA开发-需求分析在SOA开发过程中，必须有清晰的模型作为依据，才能有效发挥SOA的优势，需要有一套有效的流程、方法和工具来分析和设计服务架构，相对于传统汽车软件开发采用基于功能分解的面向过程分析方法，“用例驱动的开发方法”和“面向服务的架构设计方法”是SOA软件架构开发的两个主要特点，软件工程对Use Case的定义：“Use Case是一种在开发新系统或软件改造时捕获潜在需求的技术，Use Case分析除了能产生功能型需求和提供业务可能性分析外，它还能为后续的系统功能设计提供结构化设计和行为设计的一首素材，Use Case提供了用系统化语言翻译用户需求的能力，Use Case是衔接业务过程分析和系统设计的关键环节”。功能定义阶段主要工作就是根据产品经理输入的用户功能，开展详细用户使用场景的定义，创建Use Case,定义前置条件、后置条件、基本路径、异常路径、替代路径，分析功能需求及非功能需求。 - 保证每一个用例有一个清晰的功能性目标，保证目标在足够广泛的范围内，把用例分解成几个场景；
- 一个用例应该唯一属于一个Domain，比如对于对于“中控屏打开氛围灯”用例，应该由车身域负责氛围灯的功能开发工程师来负责设计，而HMI不能对中控屏设置氛围灯再设计用例，避免相关方用例重复创建；
- 在用例设计时需站在用户的角度来描述用户与功能的交互，此时车辆功能是一个黑盒，同时避免用技术性的语言描述技术实现方案的相关内容，从而保证用例能够在不同车型复用，同时遵循需求逐渐细化的设计思想；
- 在设计用例的同时要分析用例需求，并将用例需求关联到相关用例，便于追溯。
2.2 SOA开发-功能设计
2.2.1 PC的概念在详细描述功能设计之前，我们先了解功能设计使用的一个重要元素PC-Product Capability ,其可以类比我们以前EEA设计逻辑功能架构层中的LC-Logical Component,其是一个功能产品的能力抽象，只有在正确的级别上进行逻辑功能体系中逻辑元素的抽象，Function Owner才能设计出良好的功能架构，低级别的抽象可能会导致逻辑功能架构对未来解决方案的适用性丧失（无法重用），高级别的抽象可能会花费更多的时间和精力才能将需求转换为具体的技术方案，这可能会导致对实际客户功能的错误解释。如下是引自PREEvision Manual中对LC的描述：“The Logical Function is the smallest available unit. It is connected to Senses and Actuations or further Logical Functions.Service Functions, Building Blocks and Activity Chains define an arbitrary fragment of the Logical Function Architecture.They may be used to define the relevant logical components for implementing Customer Features.”我个人认为不管是PC还是LC，对于Function Owner进行功能设计，其主要的作用就是进行功能需求分配，对于本文所述的SOA开发方法，PC就是将需求分析阶段相关方的需求通过功能设计分配到不同的Module，因此PC的颗粒度及能力范围应该与一个Module相匹配，及PC的能力应该有一个Module来提供，不能在Module之间进行分配，因此PC应该具有唯一性，不应该在不同的Module反复进行定义。因此对于OEM在进行实际设计过程中要形成Product Capability Inventory,并借助于工具实现PC的创建、变更、分配审批流程，从而保证功能功能需求能够在技术方案上真正实现。 2.2.2 功能设计功能设计阶段承接需求分析阶段Use Case及UC Requirement,即把需求分析阶段确认的用例翻译为行为模型，在定义用例的行为模型时通常采用3类UML图-序列图、活动图、状态图，同时采用静态图-Function-PC Mapping Diagram用来描述Function->UC->PC->Module之间的追溯关系，同时借助于Enterprsie Architect的Relationships Matrix Specification 导出功能分配矩阵表。功能设计序列图是必须的，因为通过序列图才能分析出PC的操作（Operation）需求，同时活动图、状态机可作为补充。1)针对每一个用例尽量创建一个对应的序列图描述功能实现方案，同时将功能实现序列图与对应的UC做Mapping，从而将功能需求与功能实现方案之间进行完整追溯；2)Function Owner在进行功能实现方案设计时，从PC Inventory中选择归属于不同Module的PC，并使用PC提供的能力（Operation）来实现功能，在此Function Owner需要将UC Level Requirement分解到PC上，并与PC做Mapping，形成PC Level Requirement，并将PC Level Requirement分配到Module，经过System Owner审核接收后可作为Module设计的输入。这个过程需要Enterprise Architect和需求管理工具（如Polarion）进行有效的数据同步，借助于需求管理工具实现流程需求分配、流程审配等工作； 图6：架构设计工具Enterprise Architect与需求管理工具Polarion数据交互3)虽然本方法论时遵循基于模型的系统工程MBSE方法，但是必要的文字还是要写的，例如对图形增加注释，从而使阅读者能更清晰易懂你的功能实现方案；2.3 SOA开发-模块设计2.3.1 模块架构设计为了更好的管理依赖关系和构建软件架构，应该使服务分层，因此提供不同服务的模块也遵循分层的架构，同时整车电子电气系统是一个复杂的系统，涉及多个相关领域，包括Body、Motion、Energ、Safety、Info、HMI，因此根据组织架构及分层策略形成了模块架构的矩阵图：模块架构从上往下依次分为Fleet Management层、Vehicle Management 层、Vehicle Coordination层、Vehicle Control层、Sensor&Actuator层以及Platform Service层，根据我在上一篇文章《面向信号与面向服务SOA混合架构设计方法》所说的目前SOA架构一般是在如图8中的第二（Integration Layer）及以上层级实施，采用面向服务的架构设计方式，而在第一（Sensor/Actuator Layer）层级主要采用面向信号的设计方式，因此上述模块架构中Sensor&Actuator层不仅包含囊括面向信号的AUTOSAR CP软件需求设计，同时包含信号到服务转换（S2S）的软件需求设计，而在S&A层及以上则是面向服务的设计，因此在Vehicle Control、Vehicle Coordination及Vehicle Management层的Module中我们通常进行Service Design及AUTOSAR AP 软件需求设计； 2.3.2 模块设计经过上述与组织架构、产品架构匹配的模块架构设计后，整个平台中的所有模块都被分配了指定的System Owner负责，这个System Owner对于模块的实现技术方案是熟悉的，通常是由从事过该专业岗位多年的系统工程师（或软件架构师）来承担，其接收并审核Function Owner依据功能实现分配的PC Level Requirement，并与Function Owner进行充分的沟通明确完善需求后，设计实现PC的SWC，并对PC进行更新、维护，但需要经过架构工程师System Architcter的批准，该过程可借助于Polarion进行流程的审批，
对于Sensor&Actuator层的Module，我们按照AUTOSAR CP软件架构设计SWC、Port、Interface、Data Element,同时要设计硬件抽象SWC（S2S）作为信号到服务的转换组件，从而实现面向信号的SWC与面向服务的SWC之间的交互；对于Sensor&Actuator及以上的Module，我们设计Adaptive SWC、Service Interface、Service Operation(Method/Field/Event)以及DataType;在此过程中我们利用Enterprise Architect创建SWC 设计图(如图9)用来表达SWC对外交互的接口，包括Require Interface以及Provide Interface.完成SWC的详细设计后，还需编制基于服务的功能实现方案，以明确功能实现方案的服务调用关系，其实际表达的是SWC组件之间的交互怎么实现功能需求，基于服务的功能实现设计通常采用UML序列图设计，如图10：
在项目开展过程中，模块设计过程有如下一些注意事项：1)模块设计根据PC及PC 需求设计SWC，需将PC需求分解到SWC，形成SWC的需求，并将SWC需求与PC需求借助于需求管理工具（如Polarion）进行Mapping，从而进行需求的追溯及需求覆盖度的观测；2)上述过程需要对Enterprise Architect进行二次开发，以支持AUTOSAR 软件架构建模；3)SWC划分的颗粒度可依据OEM掌握的KnowHow及自身能力，以保证SWC能部署到网络拓扑架构中的唯一ECU为基本原则。 2.3 SOA开发-ECU开发在模块设计阶段完成SWC的详细设计后，System Architect可依据架构规范中部署策略把各模块中的SWC部署到网络拓扑架构中的运行环境中（ECU等），从而可形成ECU级别的软件需求规范SWRS(Software Requirement Specification),可文档可用于内部软件开发团队或外部供应商进行ECU软件开发的参考。
图11：架构开发各阶段输出物 三、结语上述基于Enterprise Architect的SOA开发方法来自与项目实践，在实际实施过程中会有一些困难，具体总结如下： |
