 
- UID
- 872339
|

关键字:AUTOSAR 车载网络 ECU 汽车开放系统架构
为AUTOSAR组件提供服务
—基础软件层和操作系统
基础软件(BSW)是一种标准化软件,不包含任何功能,但为运行时环境提供依赖于硬件和独立于硬件的服务。所需的服务包括内存服务(NVRAM管理器)、网络通信管理服务、诊断服务和状态管理。当应用层中定义的AUTOSAR软件组件要求服务时,运行时环境的任务是在真正的ECU上完成映射。
运行时环境不提供任何机制来从远程ECU获取服务,AUTOSAR规范也不允许这样做。所有服务要求都必须在“本地”ECU上得到满足。在真正的ECU上运行的基本操作系统(OS或OSEK)不了解AUTOSAR“可运行实体”的概念。操作系统拥有一个可调度活动列表,这些活动通过调度算法进行管理(图3)。

图3:将软件功能分配给真正的ECU。
关于硬件
AUTOSAR分层软件架构可以分离硬件的应用逻辑,以便重复利用和携带。运行时环境和操作系统与微控制器抽象层(MCAL)相连,可以访问主微控制器上的物理端口。微控制器抽象层为每个微控制器所特有,使操作系统和基础软件能够访问数字输入/输出、模拟数字转换、FLASH和EEPROM支持等设备。图4显示了AUTOSAR ECU中不同硬件和软件层之间的关系。

图4:组件在真正的ECU中如何组装在一起。
(点击查看大图)
支持新方法
有了一个自上而下的AUTOSAR设计方法,汽车OEM可以操作整个网络的完整模型。AUTOSAR设计工具允许提取单个ECU,连接性和接口信息在AUTOSAR XML(arxml)中有定义。这个接口定义之后将传给一级供应商,进行进一步的细节设计和实施。由于拥有标准化格式,相同的定义可以在公开投标时同时传给几个一级供应商。标准描述的好处在于在ECU描述中可以避免任何的设计不定性,并且随着AUTOSAR标准的发展,存在误解的可能性越来越小。这个标准已经与硬件无关,因此能够很好地利用新行业趋势的好处,如车内以太网、混合技术车辆网络(CAN/Flexray)、异构多核平台以及车载网关布置。
想要试试看?
包括Mentor Graphics公司在内的一些商业机构为AUTOSAR设计提供评估套件,这些套件包括架构设计到单个ECU配置。Mentor Graphics还拥有其VSX工具套件以及支持CAN、FlexRay、LIN和以太网的ECU硬件开发板。这些工具以Eclipse为基础,利用开源工具链进行从源代码到运行实现的一系列设计。相对于大规模地将车内ECU一次性改到AUTOSAR方法来说,低风险的AUTOSAR研究和试验更可取。
结论
AUTOSAR为车载网络和ECU设计提供预定义的标准方法,找到了进入每个汽车OEM和一级机构的方式。AUTOSAR标准提供了改善工艺和重新利用组件的机会,但是也存在学习一个新ECU设计流程和工具的挑战。AUTOSAR的早期采用者一直在将这些知识运用到主流设计中,可用于量产的工具和资源如今已广泛推出。AUTOSAR的采用还将帮助机构达到功能安全标准ISO26262的要求,因为它支持一个可重复、定义明确,且自上而下的设计流程。
|
|