之前文章《老板说项目要上AUTOSAR,我慌得一批》讲过,在新世纪,汽车产业蓬勃发展,欧洲大陆的车企们,瞄准了这是一块大蛋糕,于是在2002年成立了一个联盟,搞了个叫AUTOSAR的标准,以期一统天下。次年,他们就开搞了,开始制作这个AUTOSAR的草图。 话说,这是要定义一套标准,一个统一的架构,那这架构有什么内容呢? 一位工程师,将其想法用草图表达了出来 并解释说,这个架构大概分三层,然后看看在座的各位。会议上的其他人面面相觑,都想说,这么简陋,能统一江湖?这位工程师也不理会,不慌不忙,继续画下去: 工程师解释说,关键在这个BSW,还可以分个三四层:
还有,Application就是应用,跟其他架构写的应用类似,就不用多说了。而这个Runtime Environment(RTE)呢? RTE是给应用提供通信服务的,Applcation通过它可以访问BSW的功能,做统一标准的接口,从而实现非常方便的可移植性了,各模块也独立了。 工程师言简意赅,没有做更多的解释,然后就想细化这个架构图: 然后,他微微笑了下:这应该清晰了吧,横着看竖着看都很好理解。比如说这个Memory Service,就可以让Application通过RTE调用,做了很多方法application访问的接口,它是通过调用Memory Hardware Abstraction来访问Memory Drivers的。 通过这三层关系就实现市面上大部分功能需求了。但是,总会有这几层实现不了的功能吧,怎么办?Complex Drivers就可以提供给用户自己定义啦,可以做一些复杂的驱动。 总的来说,基础软件(BSW)可以按以下类型分:
等等,还有个东西差点漏了——Library
举例说明,SPIHandlerDriver是允许多业务并发访问,为了抽象出SPI的所有功能,这些已经用为SPI功能的IO是不能做他用的。 CDD CDD即Complex Driver,上文也提到了,它是用来实现BSW里面非标准化功能的。也就是说,标准化定义以外的功能可以通过CDD来实现,如UART,MCAL是没有定义UART的标准化的。 (这个话题,后续再详细讲解。) I/O Hardware Abstraction I/O Hardware Abstraction是一组模块,从外围I/O设备(片上或板上)的位置和ECU硬件布局(例如µC引脚连接和信号电平反转)中抽象出来。I/O硬件抽象不会从传感器/执行器中抽象出来!可以通过I /O信号接口访问不同的I/O设备。 Communication Hardware Abstraction Communication Hardware Abstraction是一组模块,从通信控制器的位置和ECU硬件布局中抽象出来。对于所有通信系统,都需要特定的通信硬件抽象(例如,对于LIN,CAN,FlexRay)。 例如,ECU具有带2个内部CAN通道的微控制器和带4个CAN控制器的附加板载ASIC。CAN-ASIC通过SPI连接到微控制器。 可通过总线特定的接口(例如CAN接口)访问通信驱动程序。 Memory Hardware Abstraction Memory Hardware Abstraction 是一组模块,从外围存储设备(片上或板载)的位置和ECU硬件布局中抽象出来。 例如,可以通过相同的机制访问片上EEPROM和外部EEPROM器件。可以通过特定于存储器的抽象/仿真模块(例如EEPROM抽象)访问存储器驱动程序。通过在闪存硬件单元顶部模拟EEPROM抽象,可以通过存储器抽象接口对两种类型的硬件进行通用访问。 Onboard Device Abstraction Onboard Device Abstraction 包含用于ECU板载设备的驱动程序,不能将其视为传感器或执行器,例如内部或外部看门狗。这些驱动程序通过µC抽象层访问ECU车载设备。 Crypto Hardware Abstraction Crypto Services Crypto Services包含两个模块:
Memory Services Memory Services由一个模块NVRAM管理器组成。它负责非易失性数据的管理(从不同的内存驱动器读取/写入)。 它以统一的方式向应用程序提供非易失性数据。内存位置和属性的摘要。提供非易失性数据管理机制,例如保存,加载,校验和保护和验证,可靠的存储等。 System Services System Services是一组模块和功能,可由所有层的模块使用。示例包括实时操作系统(包括计时器服务)和错误管理器。 其中一些服务是:
它提供基本的申请服务以及基本软件模块。 有专门的模块可用于AUTOSAR中错误处理的不同方面, 例如:
并结合下图给出解释:
AUTOSAR提供了一种灵活的方法来支持与安全相关的ECU,可以使用两种方法:
注意:分区基于OSApplications,OS-Application的TRUSTED属性与ASIL/non-ASIL不相关。 使用不同BSW分区的示例,看门狗堆栈放置在自己的分区中
经过以上的解答和分解,会议上的各位都点头表示同意,但是还是有人提了个问题,我们定义这么多功能模块,不一定所有产品都会用到,如何裁剪? 下图显示了基本软件模块到AUTOSAR层的映射 我们称这个为ICC3,那ICC2是怎样的? 这个便是ICC2了。 到目前为止,本文档中显示的集群是该项目定义的集群。 当前,AUTOSAR并未将ICC2级别上的群集限制为专用群集,因为许多不同的约束和优化标准可能会导致不同的ICC2群集。 可能存在不同的AUTOSAR ICC2集群,可以根据要定义的ICC2遵从性方法声明符合性。 ICC1呢? 在符合ICC1的基本软件中,不需要模块或集群。未指定此专有基本软件的内部结构。 纳尼?又回到原来的三层结构? 兼容AUTOSAR(ICC1-3)的基本软件(包括RTE)必须具有ICC3模块规范指定的外部性能。例如,针对以下行为:
另外,关于ICC3中的系统描述,ICC1 / 2配置应兼容。 工程师,想了想,面对座上的期盼的目光,慢悠悠地说,我们下次会议再讨论吧……(因为要下班了,万恶资本主义的欧洲,他们的工程师,不!加!班!!) 关注公众号号“嵌入式软件实战派”,获得更多关于AUTOSAR相关的内容。
|
|
来自: 西北望msm66g9f > 《培训》