1
Why SOA?
在整个智能网联汽车大环境下,电子电气架构(EEA)面临着变革,面向服务的架构SOA多次被提及,我们先来看看到底为什么要用SOA?
汽车行业发展趋势
先来看几组数据:
2015年,已有1.1亿辆联网车辆行驶在路上
2025年,联网车辆将达到4.7亿,其中,有90%将行驶在路上
2025年,联网车辆中,将有800万是自动驾驶车辆
当代车辆局限性
当今汽车中约有150个ECU,约7个网络。如此复杂的系统,是否能够满足汽车发展趋势的需求?
据统计,飞机大约有40,000,000行代码,而当今汽车约有100,000,000行代码,自动驾驶汽车的代码量将到达300,000,000行。如此庞大的代码量,当今的车辆架构是否还能满足需求?
未来汽车将会面临着一系列的问题,如:
新增信号
新增节点
变更功能等
当今车辆主要的架构:
就上述架构而言,我们根据需求思考几个问题:
新增信号流怎么办?修改通信矩阵?
突然增加一个节点,怎么办?修改路由表?
变更功能如何从其他节点获取所需信息?
变更功能的实现与原系统架构通信方式不匹配怎么办?
很显然,传统架构已经无法满足,因此我们需要新的架构来满足我们的需求:
SOA的优势
SOA基本架构如下,当然,后期我们也会在线上worksho中进一步与大家进行深入分享交流:
PS:线上worksho详情戳:
那么上述架构有哪些优点呢?如下:
软硬件分离,降低开发难度
灵活部署软件,功能重新分配
更新升级快
易于扩展维护
总的来讲,已知的E/E架构满足不了需求,所以要用SOA。
数字时代代表创新和不断更新升级,汽车将来也会像手机一样,在销售完后,依然可以持续升级性能。而引进SOA整车通信,将使得整车可以持续创新!
2
面向服务的架构SOA概述
相信各位朋友多多少少也接触过SOA,知道了为什么要用SOA,我们再来捋捋SOA是个啥?
What 架构?
SOA是“ 面向服务的架构 ”,要想捋清楚SOA,我们需要先了解清楚什么是架构?
在系统设计过程,需秉承一套可以被分享,可以被评审,可以被记录,可以被流程化的设计思路,这就是“架构”,
架构是一套如何以服务的形式组织整车功能的决策集合。主要包括以下内容:
从上图我们也可以得知,架构设计时,有以下热点问题:
缓存
并行处理
配置管理
数据访问
异常管理
分层
故障记录
状态管理
验证方法
工作流程等
简单来说,架构是产品需求和技术需求之间的一座桥梁!!
架构设计原则
了解清楚了架构的概念,我们来看一下架构的设计原则,主要包含五个部分:
服务分解
服务功能完全独立不重复
一个服务只承担特定的一个功能特性,同时一个功能特性也只能在一个服务中,不能在其他系统中重复定义
避免过度设计
在功能细节不明确,或者功能不断进化的情况下,需要避免过早的进行大量设计工作
服务功能通过服务接口来交互从而不关心其他服务的内部功能逻辑
严格分层
相同类型的服务打包到相同的服务层,决不允许将不同类型的服务放到同一逻辑层
服务之间不能跨层调用,同时要保持服务的独立性
性能属性
性能属性代码必须尽可能的从应用功能逻辑代码中抽离
尽量避免数据类型格式的转换,比如频繁的物理值和信号值之间转换是必须要避免
工具和流程
建模分析和可视化仿真工具分析:提前识别风险和漏洞,尽可能简化软件开发
规范化工作流程后,设计流程可以循环使用,简化开发和理解
协议选择
上述,我们介绍了交股的设计原则,但是,避免不了的是通信问题!现如今与面向服务的架构相关的通信协议主要有:
SOME/IP
DDS
MQTT
HTTP
四种协议的对比如下图:
可根据具体项目需求进行选择!
服务流程设计
前面我们一直再提面向服务的架构,那么如何设计呢?主要包含以下五个步骤:
(1)梳理整车功能
(2)规划SOA架构
(3)服务定义
(4)服务矩阵和ARXML设计
(5)服务验证和仿真
当然,我们后期会在线上workshop中进行更是深入的技术分享!
介绍了这么多,那么到底什么是SOA?
SOA软件架构
我们认为:
SOA不是一种具体的技术实现,而是一种模板软件架构!!!
软件架构我们容易理解 ,比如AUTOSAR,但是模板又如何理解?
还有个问题?AP AUTOSAR号称是一个SOA,这又该如何理解?由于篇幅原因,我们将会在《搞一下AP AUTOSAR进阶应用》中进行分享!
从软件层面来看SOA时,我们可以CP AUTOSAR、AP AUTOSAR、以及非AUTOSAR系统,通过以太网的方式连接起来,如下图:
从整车层面来看,主要包括应用服务、扩展服务和基础服务,如下图所示:
在整车层面,SOA架构构建的流程如下:
3
Q & A
领取专属 10元无门槛券
私享最新 技术干货