翻译自 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). 这些服务将被优先使用.

     接下来阅读:

•  Watchdog 管理 (AUTOSAR_SWS_WatchdogManager) : 实现软件安全 (建议在软件开发前期就被考虑到)
• 功能禁止管理(AUTOSAR_SWS_FunctionInhibitionManager) 和 诊断通信管理(AUTOSAR_SWS_DiagnosticCommunicationManager):增加维护功能

          文档(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版本中, 定义了下面的接口:

• AUTOSAR_SWS_CANInterface
• AUTOSAR_SWS_EthernetInterface
• AUTOSAR_SWS_LINInterface
• AUTOSAR_SWS_FlexRayInterface
• AUTOSAR_SWS_TTCANInterface (时间驱动的 CAN)

每个文档的结尾处描述了用于配置的参数.

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_FlashDriver
• AUTOSAR_SWS_EEPROMDriver
• AUTOSAR_SWS_SPIHandlerDriver (访问外部EEPROM 或者 Flash memory)

      注: AUTOSAR_SWS_FlashTest and AUTOSAR_SWS_RAMTest 也是 "memory drivers"的一部分, 它们提供测试硬件的功能.

5. IOHW抽象层

IOHW 抽象层是"ECU 抽象层“的一部分， 通过映射I/O硬件抽象层接口到ECU信号来访问MCAL驱动. 附件文档中， AUTOSAR_SWS_IOHardwareAbstraction描述了此抽象层.

    

      I/O 驱动:

• AUTOSAR_SWS_PortDriver: 控制器端口初始化，访问真实的I/O
• AUTOSAR_SWS_DIO:离散输入输出驱动
• AUTOSAR_SWS_ADC: 模拟数字信号转换驱动
  
• AUTOSAR_SWS_PWM: PWM驱动
• AUTOSAR_SWS_ICU: 输入捕获驱动, 用于 PWM 演示, 频率测试,等.

6. MCALs服务

      控制器抽象层位于架构的最底层，它包括下面的模块:

• 通信驱动: ethernet driver, FlexRay driver, etc.
• I/O 驱动: ADC, PWM, etc.
• 存储器设备驱动: 内部和外部的EEPROM 和 Flash
• 控制器驱动: 看门狗驱动, MCU 驱动, etc.

      这层实现了AUTOSAR的一个主要目标: 使顶层独立于硬件.