您好,欢迎来到中国汽车电子电气架构发展论坛2020!

从工程师的角度看AUTOSAR

发布日期:2020-08-04

GRCC 汽车电子电气架构创新发展论坛 今天 

手机阅读

点击上方蓝色字体,关注我们

引言:


“软件定义汽车”的火热带动了工程师们对于汽车电子软件热烈地讨论。不曾想到,隐藏在控制器内部,默默地发挥着作用的汽车电子软件,如今备受瞩目。本人毕业到现在,一直在汽车行业做软件,切身感受到一系列的变化。写软件的方法在变,行业技术标准在变,和OEM合作模式在变,还有敏捷转型等等。10多年前,有人认为汽车行业是夕阳产业,IT是朝阳产业。现在看来,无论是汽车还是IT,依然朝气蓬勃,更令人欣喜的是,这两个产业的融合为未来的发展带来了新的契机。

1
开端-OSEK/VDX

OSEK/VDX标准的出现代表着汽车电子软件标准化的开端,该标准的构成:实时的操作系统(OSEK OS),通讯子系统(OSEK-COM)和网络管理系统(OSEK-NM)。
在OSEK出现之前,软件生产商们仅依靠自身积累,写出的软件五花八门,水平参差不齐,有些甚至没有清晰的软件层次结构,这样写出的软件质量堪忧,并且可维护性是很差的。有了OSEK标准的借鉴和指导,很多软件生产商依照OSEK标准开发出了自己的软件产品。像汽车行业的Tier1,提供软件与硬件整套完整方案是常态,Tier1自研的完善可靠的软件产品也是其核心竞争力之一。
OSEK OS是实时操作系统,可以满足大多数汽车控制器的任务调度要求。另外其可移植性和可扩展性很高,可以轻松移植到新MCU平台。对于实时性要求,除了要有好的操作系统,也需要程序设计者合理地规划常规任务和中断处理程序,如果任务阻塞或执行时间过长,会极大的影响正常任务的调度。近年来,软件系统的实时性和确定性执行也不断地在演进。确定性操作系统,再配合逻辑执行时间(LET)模型,可提供更高级别的功能安全机制。
下图摘取自OSEK标准文档,图中展示了OSEK/VDX的基本结构和各组件间的关系。这也算是典型的带网络通信的汽车ECU软件的*小系统了。



在2000年左右,Tier1的ECU软件自研比例非常高,对软件产品的掌控力也相当强,底层软件和应用层软件都由Tier1完成开发。OEM和Tier1之间软件开发的合作方式,主要是由OEM向Tier1分发书写格式和内容非常规范化的需求文档,有些做到好的,则采用格式化的语言来描述需求,甚至是伪代码的书写形式。
V模型开发流程(瀑布模型的进阶)是当时的主流。按自上而下的过程递交交付物,并在相对应层级依次验证,是V模型开发的特点。V模型开发迭代周期长,一般与功能交样时间相匹配。迭代次数少,一般5到6次迭代后,基本就到SOP量产了。当时汽车ECU功能定义固化早,每个ECU功能数量较少,需求开发相对稳定,在当时看来,V模型的开发流程是非常合适的。
 
2
进阶-AUTOSAR

上文提到了OSEK,因为它与AUTOSAR颇具渊源,AUTOSAR的部分设计也参考了OSEK标准。OSEK是汽车软件标准化的第一步,它影响的范围是ECU层面。OEM和Tier1之间稳定的合作方式也已经形成。但汽车软件标准化的进程并没有停下来。
这里插句题外话。OEM和Tier1的这种合作模式下,Tier1的系统与软件能力变得格外的强,另外OSEK的标准化,总线设计的标准化,也让各个厂家设计的ECU之间的连通变得简单。在这个背景下,Tier1对整车电子电器架构的影响很大,依靠Tier1的能力,攒起一套主流的电子电器架构也成为可能。行业头部的整车厂,Tier1,芯片等其他环节的供应商,对电子电器架构的构想也一定程度上推动着行业的发展。
上文有提到过,OEM需要花费相当大的精力来书写需求说明书,以描述ECU的应用层功能,完成后交予Tier1来开发软件。而随着车上的ECU数量不断增加,信号复杂程度增加,传统的开发方式显露出了开发复杂,维护困难等弊端。让汽车电子系统开发更灵活,更有效率,成为汽车工程师的目标。AUTOSAR的诞生旨在达成这个目标。AUTOSAR从一开始就志在整体汽车电子开发的标准化。所以AUTOSAR所涵盖的方法论,虚拟功能总线,元模型与模板工具,软件架构及模块,所有这些工作都导向这一目标。可以毫不夸张的说,AUTOSAR是汽车工程师的智慧结晶。
AUTOSAR的推出,OEM与Tier1之间的合作方式有了微妙的变化。在介绍新的合作方式之前,这里介绍下AUTOSAR的核心概念:虚拟功能总线(VFB)。
下图引用自AUTOSAR标准。如图,VFB之上描述的是软件组件(SWC),以实现软硬分离。OEM着重于系统层面的设计,包含SWC的设计及它们之间的通信方式。VFB是虚拟总线,真实的情况是它们以Flexray,CAN总线方式通信,或者是ECU的内部通信。而这些都会在整车开发流程中的SWC部署,网络设计中体现。


在了解以上的基本概念后,再来讲讲OEM和Tier1的合作方式有哪些。
方式一:
OEM:以AUTOSAR的标准方法设计系统及软件架构,并以ARXML的形式导出,同时负责应用层软件SWC的开发。
Tier1:以AUTOSAR的标准方法完成基础软件的配置与生成,复杂驱动软件的开发,*终软件的集成与版本释放,并提供硬件平台。
特点:双方关注自己负责的软件部分,耦合部分不多,沟通成本*低。
方式二:
OEM:基本与方式一相同,但OEM自己不开发应用层软件。
Tier1:除了方式一提到的内容,还包括应用层软件的开发。
特点:软件开发的工作都落到了Tier1身上,但应用层软件需求沟通的成本较高。
方式三:
OEM:除了系统及软件架构设计以外,OEM还负责应用层及底层软件开发,包括*终软件的集成与释放。
Tier1:仅配置MCAL部分的软件。
特点:OEM包揽了大部分的软件工作,Tier1的价值仅在于提供硬件平台(包括MCAL软件)。
方式四:
OEM:按自身的方式设计系统架构及发布需求,但并不是AUTOSAR的标准方法,应用层软件开发为备选。
Tier1:以AUTOSAR的标准方法完成底层软件,应用层软件为备选,取决于OEM是否提供基于标准接口的应用层软件。
特点:此方式用到了AUTOSAR软件标准架构和模块,但缺少了精髓的系统设计部分。 
另外,AUTOSAR也改变了软件工程师需要的技能和工作方式。手工代码渐渐转向基于模型的开发,底层功能模块依靠工具配置及代码生成。验证软件的方式也更多样,模型仿真,SIL,HIL等等。

3
突破-AP AUTOSAR

从本节开始,AUTOSAR会标注CP (Classic Platform) 和AP (Adaptive Platform),以示区分。
CP AUTOSAR标准其实也在不停的演进中,Ethenet, Crypto, E2E, SOME/IP等等也是在4.X的版本中才出现。基本上,有新的技术需要运用,AUTOSAR就有推出相应的标准。
但CP平台毕竟有它的局限性,对于高算力的应用场景无能为力。AP AUTOSAR的出现正是应对高性能计算平台的需要,AP AUTOSAR的定位是运行于POSIX操作系统之上的中间件。设计者也不乏考虑,AP平台和CP平台在一个架构下共存的问题。所以它与生俱来,具备和CP AUTOSAR有良好的交互能力。
高性能计算平台必然是未来电子电器架构的主角,已经有不少架构师们设想把它运用到多域控制器,以及中央计算平台当中。AP AUTOSAR在高性能计算平台的作用不可小觑。这可以从AP AUTOSAR的设计细节得出。

ARA:COM提供应用层之间标准且可靠的通信方式,统一化的通信方式有助于避免由于通信机制的不同造成的设计缺陷。同时支持事件驱动和轮询模式也是它的主要特点,因实时应用程序通常基于轮询模式,而支持此模式可以保证前后级数据传递式样的一致,避免不必要的上下文切换。

ARA:EXEC主控应用程序的生命周期,设计者同时也考虑了功能安全方面的设计,例如状态恢复,资源管理,确定性执行等机制。

ARA:SM 收集应用程序的各种异常状态并适时地调整相应的应用程序功能,为功能安全提供有效的机制。

ARA:PHM提供监控应用程序的能力,并在检测到异常后执行恢复动作。它支持几种典型的任务监测机制:alive, deadline, logical supervision。

其他AP AUTOSAR包含的API及Service组件不在这里一一介绍。可以看出,APAUTOSAR除了提供基本的应用层开发平台中间件,同时也有不少功能安全上的考虑,其中一些机制可以有效的应对ISO26262软件部分“Freedom from interference”中提出的相关需求。
AP AUTOSAR在这样一个复杂的环境下诞生,工程师们必定对其赋予厚望,从它的设计思路来看,AP AUTOSAR不但吸取了现有成熟的技术,同时也有所创新,引入互联网技术的同时也不乏考虑其适用性和可靠性。如今AP AUTOSAR刚经历了几个版本,对比CP AUTOSAR从萌芽到茁壮成长的过程,AUTOSAR的未来必定可期。

来源:公号 “汽车电子与软件”

微信号: gh_91169d63a91e




相关文章

样式换色?我推荐这2种方法!
教你一招如何快速活跃现场氛围!
推荐一波好看的标题样式~






SELECTED EVENTS




 

长按二维码识别关注


 

/长按二维码申请加入 EEA 技术交流群/ 


我就知道你“在看”


  • 电话咨询
  • 021-22306692
  • 15021948198
None