千月星跡

Autosar RTD是实时驱动程序(Real-Time Driver)软件的缩写。‌实时驱动程序(RTD)软件是由恩智浦半导体(NXP Semiconductors N.V.)发布的，‌是一套全新的创新型驱动程序集，可支持AUTOSAR、非AUTOSAR应用上的实时软件，主要用于Arm®Cortex ®- M内核，使所有软件层均符合ISO26262的要求，这套驱动程序集提供完整的IP和功能。

Watchdog，又称watchdog timer，是计算机可靠性（dependability）领域中一个极为简单同时非常有效的检测（detection）工具。其基本思想是针对被监视的目标设置一个计数器和一个阈值，watchdog会自己增加计数值，并等待被监视的目标周期性地重置计数值。一旦目标发生错误，没来得及重置计数值，watchdog会检测到计数值溢出，并采取恢复措施（通常情况下是重启）。总结一下就是计数——溢出——触发。

CANTP是CAN Transport Layer的简称。是基础软件通讯模块中最重要的模块之一。CanTp是AUTOSAR通信栈中负责网络解析的模块，主要负责接收CanIf层传输的N-PDU数据解析成I-PDU数据，并发送给PDUR模块。AUTOSAR CAN传输层规范是基于汽车领域最常用的国际标准ISO15765。ISO15765描述了两个适用的CAN传输层规范：OEM增强型诊断：采用ISO 15765-2；OBD诊断：采用ISO15765-4。1）分割发送方向上的数据。

它就是虚拟总线功能。它是autosar标准提出的一个概念，基于Autosar的一个软件分层理念。对它是理解可大可小。往大的说可以把VFB理解为一种中间件，一种介于系统和系统软件之间的，用于共享系统上各个资源和调度资源的软件。往小的说可以将VFB理解为RTE层，用于各个组件之间的交互。包括了服务，数据收发，模式切换等等。

AUTOSAR（Automotive Open System Architecture，汽车开放系统架构）是汽车电子行业的一个开放式标准和软件架构。软件分层架构：将软件分为应用层、运行时环境（RTE）、基础软件层等，各层分工明确，便于管理和开发。基础软件：包含操作系统、通信服务、内存管理等底层功能模块。虚拟功能总线（VFB）：提供了一种抽象的通信机制，使得应用程序无需关心实际的硬件连接。ECU 抽象：对电子控制单元进行统一的描述和定义，便于不同 ECU 之间的集成和交互。

AUTOSAR全称是Automotive Open System ARchitecture，是一个开放式的汽车电子系统架构标准，旨在为汽车电子软件开发提供一种标准化的方法和框架。AUTOSAR标准将汽车电子系统分为两个主要领域：软件和硬件，其中软件是基于面向对象的方法进行开发的，而硬件则包括处理器、传感器、执行器和通信总线等。AUTOSAR标准的目标是提高汽车电子系统的可靠性、安全性和可维护性，同时降低软件和系统的开发成本。

CP AUTOSAR虽然可以支持SOME/IP，但是CP AUTOSAR中SOME/IP只不过是把Sender-Receiver的CAN通信转换成了Client-Server的以太网通信，整个通信链路仍是静态配置的，并不是真正的面向服务的通信。▪ 在代码生成时，CP是生成基础软件模块相关的代码，AP生成的是FC相关的代码和Manifest，需要注意的是，AP中不是所有的FC都会生成相关的代码和Manifest。配套的OS一般是由专门的OS厂商开发的，如eSOL的eMCOS、黑莓的QNX等。

BSW供应商提供的AUTOSAR BSW模块有：EcuM、Os、WdgM、WdgIf、BswM、Rte这六种。AUTOSAR BSW当中常用的属于如下。

我们知道传统所说的“裸机编程”就是不带操作系统的编程，在系统需求相对比较简单的情况下使用裸机编程可以满足要求。但是随着系统需求越来越复杂，此时就需要用到模块化设计方法以及多任务编程思想，否则后期软件升级维护成本将会急剧增加。虽然我们可以采用传统编程方式（如计数器与状态机）来实现简单多个任务的调度，但是当涉及到多个任务之间的状态切换，优先级，现场保护，执行时间控制等方面就显得极为吃力，开发效率低下且极容易出错。

AUTOSAR中，将一个单片机数字I/O引脚（Pin）定义为DIO通道（Dio channel），可把若干个DIO通道通过硬件分组成为一个DIO端口（DIO Port），DIO端口中相邻几个DIO通道的逻辑组合则称为DIO通道组（DIO Channel Group）。MCU每个引脚都是一个port，对port引脚的方向（输入或输出）、运行期间引脚方向的可变性、引脚的工作模式、运行期间引脚工作模式的可变性、引脚的初始值、内部上拉的激活等进行配置。看门狗抽象，存储器硬件抽象，通信硬件抽象，io硬件抽象。

DCM模块的每个诊断服务可以配置安全访问等级在任何状态下，只有一个安全级别处于活动(active)状态，也就是只有一个安全级别能够被激活，其他安全等级处在锁定的状态下。安全级别(security level)编号是随意的，不同级别之间不意味着有任何关系，一般Level1是最基本的安全等级，必须要存在。在默认会话(Default Session) 中不允许解锁安全等级(Security level)。要获得一些权限，客户端必须首先切换到启用SecurityAccess服务的非默认会话。

DCM模块主要用来处理外部测试人员或机载测试系统的诊断请求并将诊断状态信息传输回到诊断工具，如通过读DID获取车辆相关信息，通过读取故障码DTC辅助维修人员进行故障定位等。DCM实现了OSI七层模型的应用层（还有会话层），其在Autosar架构中位于BSW，通过PduR一组通用的接口进行传输，但并不感知底层网络具体的实现类型。也就是对底层通讯协议没有要求，可以是CAN、Lin或以太网（DoIP）等。

DiagnosticSessionControl，SID是0X10，主要功能是控制服务端的会话模式切换。一般默认上电后是在默认会话模式下，当某一个服务端正在运行时，只会出现一个会话模式，不会同时存在两个会话模式。

DcmDslProtocol是协议配置容器，它是DSL子模块当中的一个配置容器。它由一个或多个DcmDslProtocolRow所组成。DcmDslProtocolRow也是一个容器，可以用来配置支持的协议层。它是在DCM中DSL模块当中的一个子模块。这个容器包含一个特定协议的通信通道配置。注意，它允许与多个Tester通信，因此可以为一个协议配置多个连接，可以有物理寻址也可以有功能寻址。Dcm与PDU进行连接的时候，会使用以下的配置项。这个容器包含诊断连接中接收通道的配置参数。

诊断通信管理(DCM)主要包括三个子模块：诊断服务层(Diagnostic Service Layer，DSL)、诊断服务调度(Diagnostic Service Dispatcher, DSD)、诊断服务处理(Diagnostic Service Processing, DSP)。DCM模块相关的标准主要包括三部分：ISO 14229(UDS，DCM遵循的主要标准)、ISO 15031(ISO 15031 (1-7))及SAEJ1939(OBD，与OBD相关的$01 -$0A服务)。

DLS子模块应该保存当前激活的安全等级状态。DLS模块提供两个接口用来设置和获取当前安全等级：获取当前激活的安全等级:Dcm_GetSecurityLevel()设置新的安全等级:DslInternal_SetSecurityLevel()SecurityLevel安全级别定义一般可以有以下这四种。

Interface在配置工具的语境下包含了输入输出Port，以及两个Port之间的连接关系的一个集合。Ports是SWC和SWC做接口（Interface）通信使用的端口，SWC通过RTE和BSW做接口（Interface）通信使用。当我们定义了Port，并使用Port将两个SWC之间连接起来之后，剩下的工作就是工具将通过RTE层内部实现两个SWC之间的连接。每个PortInterfaceMapping描述了恰好两个PortInterface的PortInterface元素的映射。

⼀个DemComponent是若⼲故障事件的集合，在DemComponent内部，故障事件有优先级，当最⾼优先级的故障事件状态为Failed导致其他故障事件状态也为Failed，或者⽗节点DemComponent的状态为Failed导致⼦节点DemComponent内的故障事件状态变成Failed，这种故障叫做连续错误（CONSECUTIVE FAULT），其他被认为是偶发错误（CAUSAL FAULT）。一个DemComponent是若干故障事件的集合，它是DemConfigSet当中的第一个配置项。

DemEventParameters用于配置故障的类型（BSW or SWC）、故障需要多少个运行循环才能确认、是否支持预存储功能、故障事件的debounce策略以及参考的DTC属性、DemComponent、使能条件、运行循环等。DEM_EVENT_STATUS_PREFAILED或者DEM_EVENT_STATUS_PREPASSED。DEM_EVENT_STATUS_FAILED或DEM_EVENT_STATUS_PASSED。标记这个事件的主键是什么，是一个1～65535的一个位置的数字。

DemDTCAttributes用于配置DTC的属性，包括老化周期、故障优先级、存储方式（立即存储还是下电存储）、快照数据需记录的最大组数以及参考的冻结帧数据快照数据、故障数据存储的memory等，它也是DemConfigSet当中最为重要的一个成员。一般被设置为40，Aging Counter达到这个次数之后，DTC的Confirmed状态位将会被清除。这里我的理解是定义了是否需要老化的一个开关。其中快照数据、扩展数据等需要在DemGeneral中配置，然后参照进来。定义参照的扩展数据记录的列表。

DemDTCAttributes用于配置DTC的属性，包括老化周期、故障优先级、存储方式（立即存储还是下电存储）、快照数据需记录的最大组数以及参考的冻结帧数据快照数据、故障数据存储的memory等，其中快照数据、扩展数据等需要在DemGeneral中配置。简单说其功能是故障事件确认前的故障debounce，故障事件确认时的故障数据存储，故障发生后的故障老化、故障替代。这个就是内部元素，保存着老化数据，故障发生次数等内部数据，一般在SID$19$06的时候，将这些内部数据通过扩展数据的形式表现出来。

BSW也会给DEM报故障。根据故障码能够判断出出现故障的汽车部件，根据具体的关联数据可以读到出现故障的时间以及当时的ECU的一些状态数据(记录易于判断故障原因的数据)但是DCM和DEM是两个不同的任务，所以一般是异步执行，DCM只负责把请求命令和写入目标给到DEM，在DEM任务中轮询DCM的任务请求，并实现数据的填充，后通知DCM任务完成。DCM模块处理来自外部测试人员或机载测试系统的诊断请求，转发来自外部诊断扫描工具的请求，并进一步负责响应消息的组装(DTC，状态信息等)，之后将传输到外部诊断扫描工具。

DSL的全称是Diagnostic Session layer。被翻译成诊断会话层。DSL用于处理诊断数据请求和响应的数据流；监控和确保诊断请求和响应的时序。DSD的全称叫做Diagnostic Service Dispatcher诊断服务调度。DSD模块负责检查诊断请求的有效性（诊断会话、安全访问级别、应用程序权限的验证），并跟踪服务请求执行的进度。DSP的全称是Diagnostic Service Processing诊断服务处理进程。

包括CAN、LIN、FlexRay在内的整车网络系统、ECU网络及软件组件内的访问进行了统一封装，模块则通过通信硬件抽象层进行通信：对上层的应用软件层隐藏了协议以及报文属性，并提供了统一的总线通信接口供应用软件层调用，提供了统一的网络管理服务。所谓的层，我们通常的理解就是横向的，但是这里BSW的分层不像上面横向那样规则，没有严格意义上的横向上的一层一层的，有些是在纵向上跨了多个层的，但横向上看大体上你可以说分为3层，也就是1～2～3三层。为数据的保存、加载、校验保护、验证以及安全存储提供了统一的机制。

应用软件层（Application Software Layer，ASW）包含若干个软件组件（Software Component，SWC），软件组件之间通过端口（Port）进行交互。端口之间是通过Interface进行了连接。每个软件组件可以包含一个或多个运行实体（Runnable Enity，RE），运行实体中封装了相关控制算法，其可由RTE事件（RTE Event）触发。每个端口虽然定义了软件组件（SWC）间通信内容及其方向，但是通信内容以及用于交互的操作却仍不得而知。

汽车开放系统架构联盟（AUTomotive Open System ARchitecture，AUTOSAR）联合推出了一个开放化的、标准化的汽车嵌入式系统软件架构：AUTOSAR规范。Autosar（AUTomotive Open System ARchitecture）就是汽车开放式系统架构。这是一个由整车厂，零配件供应商，以及软件、电子、半导体公司合起来成立的一个组织。AUTOSAR也是一种开放的软件架构，需要汽车制造商、零部件供应商、芯片供应商及软件公司共同合作来实现该软件架构。