广告

新一代汽车电子电气架构开发的职责边界

2022-07-14 汽车电子与软件 阅读:
近两年牵头参与了多个,基于SOA的全新架构项目。在和客户一起开展项目的过程中,也遇到了很多共性的问题。所以想借这个机会,和大家分享一下,希望对大家有所启发。有错误,不恰当的地方,欢迎大家指正。

前言Vekednc

01Vekednc

近两年牵头参与了多个,基于SOA的全新架构项目。在和客户一起开展项目的过程中,也遇到了很多共性的问题。所以想借这个机会,和大家分享一下,希望对大家有所启发。有错误,不恰当的地方,欢迎大家指正。Vekednc

开发过程中的痛点Vekednc

02Vekednc

近年来,由于汽车电子电气架构的快速迭代,很多主机厂都处于新老架构交替的重要时期,搭建一个全新的架构,对于任何团队都将是一个不小的挑战。任何新生事物的出现,都是对传统的革命,我们需要抱着积极的心态,至少在一定程度上打破原有的思维和框架,从而建立新的秩序。Vekednc

在SOA架构设计项目中,无论是和主机厂,或是我们团队内部,都对项目开展了多次复盘总结,大概得出了下图中的这些共性问题。包括:“职责边界”,“传统和变革共存”,“服务是什么”......Vekednc

Vekednc

这些问题需要从宏观上,或者从思维意识上,给予特别的重视。今天我们就——“职责边界”,来重点聊一聊。Vekednc

我们知道,汽车电子电气是个异常复杂的系统,不可能由一个人,一个组织来完成。所以站在主机厂角度,梳理出正确的事情,然后把他们交给正确的组织来做,就显得异常重要。Vekednc

当然这也涉及到公司的业务策略,对未来的定位,比如公司是否致力于主导打造完整的生态链,还是掌握核心的软件,还是仅仅专注于市场需求的理解及实现,等等。Vekednc

无论如何,宏观的职责分工在一开始就需要规划清楚,否则所有的工作是没法有效开展的,就算开展了,也会逐步偏离初衷,变难以控制。Vekednc

职责定义Vekednc

03Vekednc

在我们讨论职责边界之前,应该先清晰一个问题,“职责由何而来?”,只有清楚了职责的由来,才能梳理出职责的准确定义,并进一步明确职责的边界。Vekednc

为了得到答案,先让我们回到最初的起点,看看我们对车辆的定义是怎样的。车辆是仅仅作为交通工具,还是发展成为所谓的第三生活空间?无论是哪种发展方向,有一点是肯定的:车辆都是为人来服务的Vekednc

从下图中,我们可以看到车辆使用时的三个要素:环境,车辆和用户。车辆需要感知环境,来满足用户的需求。从这点来看,也能说明为什么把整个车辆作为系统的边界来定义用户需求。(环境和用户在这里都是广义的,我们就不展开了。)Vekednc

Vekednc

接下来我们拨开车辆的外壳,进到车辆的内部,来看下车辆是如何感知环境来满足用户需求的。这个层级已经属于解决方案了,核心元素是传感器ECU执行器Vekednc

Vekednc

从上图中,我们可以看到,环境中的一切物理表象,通过传感器转化为对应的电信号,然后这些模拟电信号,传输到在ECU内部,转化为数字信号。然后在软件世界进行沟通,计算和分析,之后将控制指令转化为模拟信号。模拟信号传递到执行器,执行器遵照这些指令,结合自身的物理特性,执行器完成功能在物理世界的最终实现。这个层级看得见摸得着,传统的零部件供应商基本也是按照这个职责来划分。Vekednc

对于传感器和执行器,目前的现状和趋势是各家的技术和方案逐渐趋同,以后应该是向标准化的方向发展了。当然这些不是我们今天讨论的范围,ECU才是我们今天讨论的重点。我们可以看到ECU在感知环境和满足用户的过程中起到了关键的分析与控制的角色,所以ECU才是满足车辆定义的核心元素。由此,也回答了我们之前的问题,当我们讨论架构开发中的职责,其实本质是溯源到ECU所承担的职责。Vekednc

接下来我们再拨开ECU的外壳,到ECU内部来看看。这里我们提到的ECU是个泛化概念,对于用户,不太在乎是1个ECU还是100个ECU实现了他们所期望的功能。但是从架构的角度,我们需要评估需要有哪些ECU,这些ECU分别承担什么职责是最优化的。Vekednc

我们详细来看看ECU可能承担的职责,这里将忽略ECU的中间件,应用层,操作系统......这些是用以 “实现” ECU职责的部件,但我们今天单讲 “职责”,不讲 “实现”。Vekednc

在下图中,我们根据不同的职责,将ECU分成多个软件层级。Vekednc

Vekednc

最底层的是Device (S&A) abstraction,这里是指传感器,执行器这些物理部件的抽象。Vekednc

Vekednc

当我们和其他人进行沟通,或者协作时,首先要保证有同样的语言。如果都不能理解对方说了什么,好的沟通结果根本无从保证。Vekednc

Vekednc

这里的Device (S&A) Abstraction其实就是这个作用,他们是在软件世界里对实际物理设备的抽象,或者说翻译。Vekednc

除了Device (S&A) abstraction以外,其他的每一层都发挥着独有的作用为了更好的理解ECU每一层所承担的职责,我们可以将他与人体机能进行类比,如下图所示:Vekednc

Vekednc

  • Device (S&A) abstraction:Vekednc

这个最底层的作用就相当于人的双手,双脚,是最终接触这个世界的对象。Vekednc

  • Device (S&A) control:Vekednc

这层就是对Device的控制,比如对天窗电机的控制,开还是关等等,类似于人手部的肌肉,控制手的活动。Vekednc

  • Gateway of communication:Vekednc

这层主要是通讯的枢纽,类似于人的关节,连接身体的各个部位。Vekednc

  • Domain/zone level control:Vekednc

这层是功能域控制,是对控制之间的协调。比如为了保证车身的稳定,需要考虑如何协调制动控制和转向控制。类似于神经系统,如何协调手脚,来保持身体平衡。Vekednc

  • Cross-domain/vehicle scope control:Vekednc

这层就是整车范围内的规划。比如所谓的场景定义汽车,基于场景来进行整车范围内的规划。这类似于人的大脑,处理一个项目,考虑要做哪些事情,前后次序是什么等等。Vekednc

这个层级架构,从下往上,层级越高,处理的事务就越复杂,就越需要规划和计算,层级越低,越简单,只需要条件反射。这和人,也是一样的。Vekednc

在了解了ECU可能承担的职责以后,接下来我们来看看,架构在演变过程中ECU的职责是怎么变化的Vekednc

分布式架构Vekednc

首先是最传统的分布式架构,ECU承担了设备抽象和设备控制的职责,每个ECU基本上是各司其职,尽可能不打扰对方。这个架构里,人承担了总体规划,思考分析,及车辆行为的协调的职责Vekednc

Vekednc

域(Domain)控架构Vekednc

接下来是功能域架构,在原来的基础上增加了功能域控制器,来承担域内的协调及域间的沟通。Vekednc

Vekednc

区域控制+中央计算架构Vekednc

最后,就升级为区域控制+中央计算的架构,在这个架构中,人大脑的职责也要被取代了。到这一步,车辆将真正发展成为数据世界中的一环。Vekednc

Vekednc

因为每个公司或多或少都有遗留的资产或者负担,包括基于原有架构的打造的,车型,组织架构,流程和工具,原有的零部件和供应链体系等等。另外,支持新架构的产品体系还没有完全打通,尤其是在性能,功能安全等方面,所以这个架构还处于,传统控制器和新架构控制器同时存在的中间状态,各自的职责还在不断的发生演进,这背后会有不同的力量在推动。Vekednc

接下来,我们聊下为什么要分层?Vekednc

这和我们对架构的理解,以及供应商合作方式都有很大的关系。Vekednc

Vekednc

我们暂且以ECU这个颗粒度来举例。在上图中,如果把一个ECU和另一个ECU的交互定义为一个复杂度,那么左边这平级架构中的每个ECU因为自身功能,需要沟通的话,都将有3个可能的复杂度。最终,这4个ECU组成的架构,一共将存在3*4,12个复杂度。Vekednc

而如果把其中一个ECU提高一个层级,通过这个ECU来协调底层的ECU。这个ECU将依然保持3个复杂度,但是底层的每个ECU,复杂度都将变成1。那这4个ECU组成的架构,就变为6个复杂度。Vekednc

大家可以看下这个差异。同样是4个ECU的总数,但最终的复杂度数量却减少了一半。ECU数量越大,两种架构的复杂度差异也将越大。Vekednc

另外,因为不同层级复杂度的明确,对于如何宏观分配资源,规划平台,我们就心中有数了。Vekednc

需要注意的是,这个例子,只是以ECU为单位,对功能实现来讲,颗粒度必须下沉到软件单元才有意义。这种情况下,因为架构分层引起的数量差就更加可怕了。Vekednc

从这点上,也能理解,为什么在传统的架构和供应商体系中,有任何小的改动都如此缓慢和昂贵了。我们如果不从根本上解决复杂度,其他的措施都是扬汤止沸,治标不治本Vekednc

职责边界Vekednc

04Vekednc

从车辆定义再到ECU层级的拆解,我们对开发过程中ECU所承担的职责已经较为清晰了。最后,根据ECU所承担的职责,我也对实际开发过程中的职责边界给出自己的看法。Vekednc

Vekednc

在上图中,我们先将整个开发分为两个大的阶段,需求开发和产品开发,然后根据之前提到的ECU层级,将产品开发划分为3级,每一级又拆分为软件产品和硬件产品。然后基于这个分类,应当由主机厂,还是合作商来承担某一分类的职责,在图中给出了推荐程度。Vekednc

因为传统OEM的开发设计人员,不太懂软件,而传统的软件商只关注单个ECU,没有整车视野,所以在这个变革的历史阶段,市场上需要有能结合两种能力和视野的方案供应商,来弥补缺失的地方。(在实际的情况中,方案商也可能是软件供应商。)Vekednc

最后,重点说明两点:Vekednc

  1. 在新的架构体系下,主机厂除了负责需求开发,还应该掌控域控制器及中央控制器的软件开发,只有这样,才真正培养迭代能力,保证产品质量,拥有真正的话语权。Vekednc

    注:掌控不一定代表需要事必躬亲,什么都是自己来做。Vekednc

  2.  最底层的ECU,建议软硬件同一供应商,因为在这一层软硬件耦合性较大。再往上,域和中央控制器的ECU,建议软硬分离,由不同的供应商负责,而且因为领域的不同,可能存在多个软件供应商,如此一来,主机厂的协调沟通就尤其重要。Vekednc

作者介绍Vekednc

05Vekednc

Vekednc

ENDVekednc

责编:Admin
文章来源及版权属于汽车电子与软件,EDN电子技术设计仅作转载分享,对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。如有疑问,请联系Demi.xia@aspencore.com
汽车电子与软件
汽车电子与软件
  • 微信扫一扫
    一键转发
  • 最前沿的电子设计资讯
    请关注“电子技术设计微信公众号”
广告
热门推荐
广告
广告
EE直播间
在线研讨会
广告
广告
面包芯语
广告
向右滑动:上一篇 向左滑动:下一篇 我知道了