一、SOA架构的优势
整车电子电气架构EEA是一个复杂的系统工程,需要从多个维度进行开发,不仅是架构平台的功能需求Feature,同时还要考虑成本、性能、可靠性、开发可行性、环境优好性、鲁棒性、可用性、功能安全、信息安全等方面,为了设计一个好的架构,各个OEM需要根据自身公司愿景、使命、目标、产品定义进行上述质量属性的优先级排序,高优先级的质量属性在进行架构评估时可承担更多的权重,如果说我们把所有上述质量属性看的同样重要,就等于说一个也不重要。
注:上面的这个实例简单理解就是我们以前通过OTA来更新车端嵌入式ECU 的软件实际是FOTA,类似于我们每次需要在手机上增加一个功能都需要更新整个操作系统一样,费时、费力且用户体验差,而通过SOA在车端增加功能就像我们目前在手机上安装软件一样(SOTA),简单、快捷且在下载软件的同时不影响手机的正常使用。
图2:MBSE SOA开发流程
在SOA开发过程中,必须有清晰的模型作为依据,才能有效发挥SOA的优势,需要有一套有效的流程、方法和工具来分析和设计服务架构,相对于传统汽车软件开发采用基于功能分解的面向过程分析方法,“用例驱动的开发方法”和“面向服务的架构设计方法”是SOA软件架构开发的两个主要特点,软件工程对Use Case的定义:“Use Case是一种在开发新系统或软件改造时捕获潜在需求的技术,Use Case分析除了能产生功能型需求和提供业务可能性分析外,它还能为后续的系统功能设计提供结构化设计和行为设计的一首素材,Use Case提供了用系统化语言翻译用户需求的能力,Use Case是衔接业务过程分析和系统设计的关键环节”。功能定义阶段主要工作就是根据产品经理输入的用户功能,开展详细用户使用场景的定义,创建Use Case,定义前置条件、后置条件、基本路径、异常路径、替代路径,分析功能需求及非功能需求。
我个人认为不管是PC还是LC,对于Function Owner进行功能设计,其主要的作用就是进行功能需求分配,对于本文所述的SOA开发方法,PC就是将需求分析阶段相关方的需求通过功能设计分配到不同的Module,因此PC的颗粒度及能力范围应该与一个Module相匹配,及PC的能力应该有一个Module来提供,不能在Module之间进行分配,因此PC应该具有唯一性,不应该在不同的Module反复进行定义。因此对于OEM在进行实际设计过程中要形成Product Capability Inventory,并借助于工具实现PC的创建、变更、分配审批流程,从而保证功能功能需求能够在技术方案上真正实现。
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)进行有效的数据同步,借助于需求管理工具实现流程需求分配、流程审配等工作;
模块架构从上往下依次分为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 软件需求设计;
3)SWC划分的颗粒度可依据OEM掌握的KnowHow及自身能力,以保证SWC能部署到网络拓扑架构中的唯一ECU为基本原则。
图11:架构开发各阶段输出物
上述基于Enterprise Architect的SOA开发方法来自与项目实践,在实际实施过程中会有一些困难,具体总结如下:
组织架构:如康威定律所言,支撑上述设计流程的实施需要有与之匹配的组织架构、岗位分工;
自身掌握的KnowHow深浅不一,如何能够在所有Domain应用统一的方法及流程进行设计,并能有效协作需要自己不断探索;