智能驾驶系统是一个非常复杂的系统:
- 复杂的行泊车功能
- 高算力的感知规控算法
- 异构的计算平台
- 复杂的电子电气架构
- 安全、灵活、可诊断、可升级、可仿真等等
如何设计一个如此复杂的系统?
mbd(model-base-design),广泛应用在自然科学、金融经济、社会分析等各领域,帮助理解复杂系统。
如何设计一个mbd系统,需要哪些技术?
不管用什么样的方法设计一个系统,都是将复杂的系统拆解成更小粒度的组件,标准化这些组件的原型设计,管理这些组件的生命周期,支撑这些组件的诊断、部署和升级,实现基于业务的通讯和读写数据。
- 系统需要哪些类型的组件原型?如何管理他们?
- 组件在承担业务逻辑和交互承担怎样的差异化的角色?
- 如何部署、诊断、处理故障和升级?
- 基于不同的基础软件,这些模型怎么实例?
带着这些问题,一起看下面mbd的基础技术。
先梳理mbd相关组件原型定义,分析组件生命周期管理逻辑,以及他们如何支撑业务架构。
组件原型之一:服务
背景:
一个复杂系统考虑降低复杂度、耦合度、提高复用性、灵活性,就需要使用soa。
将整个复杂系统拆解成低耦合的服务,并通过一系列服务管理手段来管理其生命周期,形成子系统/子产品矩阵。
系统拆解第一技术就是soa。
soa技术:
- 服务生命周期管理。作为系统基础组件之一,服务生命周期管理是系统生命周期管理的重要组成。
- 服务基础原型就是就是用来支撑生命周期管理,封装管理相关逻辑。
- 因为服务是通过更细颗粒度的组件组成,所以服务生命周期管理内部转化为其他类型组件的生命周期管理,并通过其他组件管理器来实现。比如一个服务是由一个功能组或者一个状态机实现,在这个原型基础上可以扩展对内部状态机的管理。
- 服务接口标准化,分为业务型接口和管理型接口。只有标准化接口才能方便复用和管理。
- 管理型接口部署在基础原型中,在服务依赖关系和对内组件管理上可以扩展。
- 业务型接口部署在扩展原型中,基于业务扩展出不用业务类型的服务原型,形成差异化的业务服务模板。
- 服务的健康度管理。业务型故障上报和健康度上报通过CM,而组件管理类型故障发布订阅通过服务管理总线。
应用场景:
- 将分布式的硬件资源抽象成服务,并统一接口发布出来,上层应用可以动态的发现这些服务,并使用。
- 智驾的冗余功能以服务的形式集成,边界清晰、接口标准,可以独立开发、灵活集成。
软件实现:
- 每一个服务都是一个服务client;
- 每一个操作系统之上都需要一个服务mgr,去发现、管理、共享服务client;
- 服务的一级基础原型应该是统一的template,所有client都是template的一个实例,这个模板用来实现服务生命周期管理相关的逻辑;
- 服务的二级原型应该是基于业务的,这个模板用来标准化业务接口,但也能够支撑业务上的扩展性;
组件原型之二:功能组
使用soa将复杂系统拆解到一定颗粒度之后,因为工作量或者无法低耦合的继续拆解。但此子系统的复杂度还是很高,无法通过独立的状态机来清晰的完成。那么就需要一些组件高耦合的来实现这个子系统。
在这样一组状态机的原型中,无法使用服务来管理内部状态机之间的合作逻辑,我定义这样的状态机组合为功能组。
功能组原型:
组件原型之三:状态机
模板管理/原型设计
运行数据
配置管理
日志管理
数采管理
诊断管理
故障VS健康管理
故障和健康度管理:
为什么没有将诊断、配置等概念拿出来讲,而是在这里分析故障和健康度管理。是因为诊断、配置对于组件类型差异是没有区别的,而故障和健康度管理是存在差异
通讯adapter
资源adapter
实例adapter
部署adapter
数据adapter
升级adapter
除了模型通用要素,智驾系统还有哪些要素?
系统状态层
业务模型:
功能管理层(AD功能,业务服务)
功能模型层
数据&通讯适配层
部署和通讯适配(仿真和)
硬件模型:
对手件
网络
计算平台(支撑部署、存储、算力)
软件系统模型要素?
通讯适配(网络orshm)
软件实例化(os,fs,em,sm,fg,cm,soa等基础软件)(基础软件接口标准化,支撑上层模型实例,比如仿真)
软件开发模型化?
组织架构模型
交付架构模型
流程架构模型
免责声明:本文系网络转载或改编,未找到原创作者,版权归原作者所有。如涉及版权,请联系删