翻译自
http://www.pulse-ar.com/en/AUTOSARTutorial_01_BSL基础软件层 Basic Software layers: 按照从上层到底层顺序介绍
1. 运行环境 Runtime Environment (RTE)
RTE是基础软件架构中特殊的部分,它的目标是将软件模块与它的环境抽象区分开.RTE的产生分为两个阶段:
-
"contract" 协定阶段: 当XML SW-C 描述有效时,产生应用头文件,这些头文件使用产生的API来实现SW-C.
- "generation"生成阶段: 当所有的配置都完成时,完整的RTE将被生成,包括API和内部的架构.
注:从R4.0版本开始,RTE生成就包括了BSW任务调度(涉及OS tasks)
AUTOSAR_SWS_RTE是RTE的主要规格文档, 包括:
-
RTE原理的描述(chapter 2)
-
AUTOSAR方法论中,RTE的生成(chapter 3)
-
RTE规格 (chapter 4)
- RTE API (chapter 5)
-
基础软件调度器(Basic Software Scheduler)的参考(chapter 6)
- RTE ECU 配置 (chapter 7)
开发者使用的章节:
-
Software Components 开发者应该从chapter 2 (RTE 原理)开始 ,参考chapter 5 (RTE API) 和 7 (BSW Scheduler)
- Basic Software 开发者 应该关注 chapters 3 (RTE 生成), chapter 5 (RTE API) 和 chapter 7 (BSW Scheduler)
-
RTE generators开发者 应该关注 chapters 4 (RTE 规格), chapter 5 (RTE API) 和 chapter 7 (BSW Scheduler).
2. 系统服务 System Services
服务层是基础软件在最高层:I/O信号由ECU抽象层处理, 服务层主要负责诊断和看门狗管理.
对于Software Components的开发者:
首先关注通信管理(AUTOSAR_SWS_COMManager), ECU 状态管理(AUTOSAR_SWS_ECUStateManager) 和 开发错误的跟踪 (AUTOSAR_SWS_DevelopmentErrorTracer). 这些服务将被优先使用.
接下来阅读:
文档(Cryptographic services, ...) 只在需要使用的时候,作为参考.
对于Basic Software开发者:
首先关注ECU 状态管理 (AUTOSAR_SWS_ECUStateManager), 此文档描述了ECU是如何开始运行,如何停止运行,从而了解BSW模块应该怎样设计才能满足这个运行机制.
接下来阅读:
开发错误追踪Development
Error Tracer (AUTOSAR_SWS_DevelopmentErrorTracer, 快速浏览). 功能禁止管理(Function Inhibition Manager) (AUTOSAR_SWS_FunctionInhibitionManager) 和诊断通信管理 (AUTOSAR_SWS_DiagnosticCommunicationManager) .
对于RTE Generators开发者:
没有特别的阅读数序推荐,下面是一些与系统服务层相关的文档介绍:
-
AUTOSAR_SWS_COMManager:
通信管理(ComM) 模块,收集总线通信需求 ,这些需求来自(BswM, a runnable
entity, a SW-C 或 一组SW-C) ,协调总线通信需求. 从SW-C 角度来看, COMManager主要功能是使能通信功能 (FULL/NO_COMMUNICATION) 和 获取通信模式的状态.
-
AUTOSAR_SWS_DiagnosticCommunicationManager: 诊断通信管理 (Dcm) 模块, 确定诊断数据流和管理诊断状态 , 特别是诊断的安全状态.
-
AUTOSAR_SWS_DiagnosticEventManager:
诊断事件管理(Dem),处理和保存诊断错误和相关的数据. 保证诊断数据以标准的方式保存在NVRAM中,这样OEM和供应商达成一致. Dem同样发送错误信息给 Dcm .
-
AUTOSAR_SWS_FunctionInhibitionManager:
功能禁止管理(Fim),通过内部ID的方式,授权SW-C或者BSW是否使能ID对应的功能. 使用
FiM_GetFunctionPermission 获取权限,这个服务在诊断功能中被使用.
-
AUTOSAR_SWS_ECUStateManager:
Ecu 状态管理(EcuM),包括如下阶段: 启动 (在SW-C执行前), 睡眠 (侦测唤醒事件) 和 关闭 (停止服务). 从SW-C角度来看,EcuM 可以根据SW-C需求,让ECU进入睡眠或者关闭模式(使用 AUTOSAR ports, §7.10). EcuM 主要角色是初始化和停止OS, SchM 和 BswM.
-
AUTOSAR_SWS_WatchdogManager:
看门狗管理(WdgM),监视程序运行过程.
当看门狗发现错误, 它通知SW-C,使用RTE模式机制进行恢复 , 或者在Dem中记录, 或者重新启动错误的部分. 如何以及什么时候使用看门狗,不在AUTOSAR规定范围, 可参考相关标准 (e.g. IEC 61508 or ISO 26262) .
-
AUTOSAR_SWS_DevelopmentErrorTracer:
开发错误追踪 (Det),只定义了API,模块内部的功能,由开发者和集成商来实现,以达到调试的功能.
-
AUTOSAR_SWS_CryptoServiceManager:
Crypto Service Manager (Csm) provides access to cryptographic
functions. From a SW-C or BSW standpoint, this module is used either to
compute a MAC (to send it alongside the protected data) or to check it
(based on a received frame). The library uses the private/public key
concept.
3. 通信服务 Communication Services
注: 从SW-C角度看,所有的通信服务都要通过RTE (使用 AUTOSAR ports), 因此这里将关注通信的机制和配置.
AUTOSAR_SWS_COM 和 AUTOSAR_SWS_PDURouter是通信方面顶层的文档. COM 模块位于RTE 和 PDU Router之间: RTE使用COM服务来发送和接收信号, 接下来COM模块使用适当的PDU Router发送和接收信号. PDU
router依靠底层的通信驱动,
一个"interfaces" 模块可以控制几个底层的驱动. 通信分层结构如下图所示:
AUTOSAR R4.0版本中, 定义了下面的接口:
每个文档的结尾处描述了用于配置的参数.
4. 存储器服务 Memory Services
存取器服务包含在NVRAM管理模块中,它可以访问(on-chip 或者 on-board)非易失性存储器. 文档 (AUTOSAR_SWS_NVRAMManager)描述了NVRAM模块.
有3种不同的API,它们受限于硬件. §7.1.4.7中描述了这三种类型, §8描述了API的规格定义. NVRAM管理模块依赖于存储器抽象层 Memory Hardware Abstraction layer (AUTOSAR_SWS_MemoryAbstractionInterface), 存储器抽象层抽象了存储器芯片和ECU. 存储器抽象层依赖下面几个底层驱动:
注: AUTOSAR_SWS_FlashTest and AUTOSAR_SWS_RAMTest 也是 "memory drivers"的一部分, 它们提供测试硬件的功能.
5. IOHW抽象层
IOHW 抽象层是"ECU 抽象层“的一部分, 通过映射I/O硬件抽象层接口到ECU信号来访问MCAL驱动. 附件文档中, AUTOSAR_SWS_IOHardwareAbstraction描述了此抽象层.
I/O 驱动:
6. MCALs服务
控制器抽象层位于架构的最底层,它包括下面的模块:
-
通信驱动: ethernet driver, FlexRay driver, etc.
-
I/O 驱动: ADC, PWM, etc.
-
存储器设备驱动: 内部和外部的EEPROM 和 Flash
-
控制器驱动: 看门狗驱动, MCU 驱动, etc.
这层实现了AUTOSAR的一个主要目标: 使顶层独立于硬件.