随着行业的 SOA 理念大火,带着一系列的解读和思考观点横行于世,笔者大多仔细研读过,虽然增加了很多碎片化知识和曾经的盲点,但也同样带来了更多的疑惑,本文撰写初衷是基于车厂的角度思考,如何在现有整车架构和软件资产下,进行 SOA 的设计开发,并从工具链和操作方法上给出案例。 1. 分布式 ECU-基于信号的架构设计现在我们来看,在域控制器开发阶段,针对传统车厂,在分布式 ECU,或区域控制器集成,已经有了深厚的架构开发和经验积累的前提条件下,如何转型并进行中央域控的服务设计。 服务设计相对软件架构设计影响较大,接下来着重分析 SOA 服务设计。 2. 中央域控架构-基于 SOA 服务设计为了后续方便理解,我们大致把国内的整车电子电器架构分为三个阶段:
2.1. 服务设计依据
2.2. SOA 设计区别3.0 架构全面采用 SOA(service-oriented Architecture)设计思想进行构建,上一代 2.0 架构采用的是 POP(procedure oriented programming)面向过程的设计思想,需要注意的是,在 SOA 设计中,自上而下的设计方法中引入了 OOP(object oriented programming)面向对象的抽象与封装概念,这是为了在 2.0 现有架构基础上,能够继承原有 FR,FDR,LC,然后进行迭代开发。 也就是说通过 Class 的抽象,在原有 LC 一层新添加了类图的设计,通过抽象的类进行用例设计进行功能链路实现。后续进行服务化设计,只要满足类中的属性和方法能够实现即可,而不必去关心设计的服务如何支撑整个子系统及功能链路的实现。
2.0 架构上 MBSE 设计图上 LC 映射实现 3.0 架构上 MBSE 设计图上 LC 映射实现 2.3. 接口命名规范在进行 SOA 服务设计时,需要遵循如下命名规范 2.3.1. 基础规范
2.3.2. Service Instance 服务实例服务实例及指代定义的服务实现,后文若单独写服务,则意为服务实例
eg. LedControlSrv 2.3.3. Service Interface 服务接口SOA 平台上服务之间通信接口有 Event、Method 和 Field 三种形式, ServiceInterface 用于定义 Event/Method/Field 消息类型和具体的命名空间,与具体的通信协议无关。
eg. LedControlSrvIf 2.3.4. EventEvent 接口表示实际传输的数据,以数据为操作对象,只要能够清晰的表达数据的含义即可,命名规范遵循基础规范,后缀要以 eg. CurrentVleEvt : 电流值 Event 消息传递方式如下图所示,为服务端主动向客户端发送,并且会触发客户端的 callback 函数进行数据处理。 2.3.5. MethodMehtod 接口表示某种控制,通讯方式采用 RPC 远程调用,通常有动词行为,比如控制,状态查询,传输,注册,设置等。其中 Method 又分为 F&F,与 R&R 两类,FF 为单次调用,不需要反馈,RR 为 request resoponse,需要反馈。
整体设计依据遵循 CURD/REST 这类成熟的互联网通用接口概念 CURD REST 接口名称需要表达清楚该方法的含义,推荐使用动名词进行命名,采用驼峰命名规范,基于如上 CURD/REST 参考,命名要以后缀
eg. setSoundOnMtd : 鸣响喇叭 Method 消息传递方式如下图所示,为客户端主动向服务端请求,可以设定是否有服务端的返回值。 2.3.6. FieldField 表示一种属性,通常指状态值或某种信息,名称应该清楚的表达该属性的含义。 Field 包含如下三类信息:
eg. VehMoveFld : 车辆移动控制 Field 消息传递方式如下图所示 3. 服务设计方法针对大部分 OEM,需要在现有整车架构上进行服务设计升级,也就是已有 base 的 LC 需求,和工程级的软件 swc,需要依据这两类已有资产,使用 OOP 面向对象的抽象与封装手段,进行 SOA 服务化重构。 本章节以车身控制器中 需要注意的是,在设计服务接口时,要清楚的知道不同接口的实际特性和性能消耗。Event 为 服务端主动向客户端 发送请求,而 Method 恰好相反,为 客户端主动向服务端 进行请求调用。根据如上接口描述,整体服务设计遵循如下方案要点。
3.1. 需求分析示例软件模块主要实现危险警报功能,在整车条件允许的情况下,如果按下手机 app 上的警报按钮,则会触发车辆进行声光报警。 需要注意 针对 VFC/PNC 相关软件逻辑,虽然在 3.0 架构上已经不复存在,但是需要保留功能分区划域的思想,也就是针对不同场景需要触发不同的软件组件来执行完成,针对不同的 PNC,在 3.0 架构上可以作为 VLAN 划分的设计参考。 使用 gitee 进行需求编写,与原 LC 中需求进行追溯 3.2. 类的抽象和封装使用 OOP 手段,根据需求和已有的软件模块,进行类的抽象,并将有可能被多次调用的软件逻辑进行类方法的封装,后续多次执行的代码逻辑,仅在实例化的类中执行一次即可。
类图: 时序图: 3.3. 服务设计上一章推导出,所设计的类就是一个需要实现服务,根据此原则,在 gitee 中进行服务设计。 服务设计包含如下步骤和要素:
3.3.1. 数据类型设计在 3.3.2. 服务接口设计在 3.3.3. 服务实例设计在 3.3.4. 配置文件导出以及代码框架生成通过 gitee 能够导出所有服务 list 的 csv 文件,基于此开发工具进行 arxml 文件和代码框架的转换生成,最终进行基于 SOA 服务化的软件开发。 代码框架可以参考笔者之前的回答。 4. 小结针对已有历史软件资产的厂商,进行 SOA 架构升级的方法大致如上,此处借用了 gitee 企业版辅助进行架构设计,也希望大家意识到,软件定义汽车,不仅仅是软件产品,甚至整车研发的工具链和开发流程也都会慢慢靠向软件开发的生态工具链,抱残守缺,是注定要被时代淘汰的,此处诺基亚和柯达会深有感触。 最后附上最新的 SDV 工作组,标准服务的定义文档,去年开始,我们国内的汽车行业也有了属于自己的技术标准组织,SDV-软件定义汽车工作组,负责标准化车辆的服务接口名称;AutoSEMO 中国车辆基础软件协会,负责标准化 SOA 架构下的中间件开发规范。所以,AutoSAR 的生与死在未来是个值得思考的问题。 版权声明:本文为知乎「Tomato」的原创文章,已获作者发表许可。 |
|