Autosar学习----AUTOSAR_SWS_BSWGeneral(八)

💥💥🔍 🔍 欢迎来到本博客❤️❤️💥💥
🐡优势:❤️博客内容尽量做到通俗易懂,逻辑清晰。
⛳️座右铭:恒心,耐心,静心。
⛳️ 欢迎一起交流分享

目录

10.1 配置规范简介

本节补充了相应BSW模块规范第10章的内容。建议阅读以下文档以获得更全面的理解:

  • AUTOSAR分层软件架构
  • AUTOSAR ECU配置规范

该文档详细描述了AUTOSAR的配置方法论和配置元模型。以下内容仅为该主题的简要概述,不能替代ECU配置规范文档。

10.1.1 配置和配置参数

配置参数定义了BSW模块实现的通用部分的可变性。这意味着只有通用或可配置的模块实现可以根据系统和ECU配置时使用的软件和硬件进行适配。配置参数的配置可以在软件过程中的不同时间实现:编译前、链接前或构建后。文中使用“配置类”一词来指代特定的配置时间点。不同的配置类将导致不同的实现和设计过程,具体规定在本文件及BSW模块自身的规范中。

10.1.2 变体

变体描述了一组配置参数。在一个变体中,参数只能属于一个配置类。不同的使用案例需要不同类型的可配置性,因此提供了以下配置变体:

  • VARIANT-PRE-COMPILE:仅允许在“编译前”实现单个配置参数。
  • VARIANT-LINK-TIME:允许在“编译前”或“链接时”实现单个配置参数。
  • VARIANT-POST-BUILD:允许在“编译前”、“链接时”或“构建后”实现单个配置参数。

10.1.3 容器

容器持有一组配置参数。这意味着所有配置参数都保存在容器中,子容器可以引用其他子容器,并且可以为这些引用分配多重性。多重性定义了包含参数的可能实例数量。配置参数被聚集到容器中,通常是因为:

  • 配置参数在逻辑上属于同一组(例如,适用于整个NVRAM管理器的一般参数)。
  • 配置参数需要实例化(例如,NVRAM管理器的内存块规范参数——这些参数必须为每个内存块实例化)。

10.1.4 配置参数表

配置参数表分为三个部分:

  • 一般部分
  • 配置参数部分
  • 包含/引用容器的部分
10.1.4.1 一般部分

包含配置参数的基本信息。

10.1.4.2 配置参数部分
  • 名称:通过名称标识参数。
  • 描述:解释配置参数的意图。
  • 类型:指定参数的类型(例如,uint8…uint32),如果可能则标记为“–”。
  • 单位:指定参数的单位(例如,ms),如果可能则标记为“–”。
  • 范围:指定参数的范围(或可能值),如果可能则标记为“–”。
  • SWS项目要求ID:与参数相关的要求标识。
  • 容器名称:通过名称标识容器。
  • 描述:解释容器的意图和内容。
  • 后构建变体:指示该容器在不同后构建变体中是否可以有不同数量的实例。
  • 多重性:描述参数在不同后构建变体中的实例数量。
10.1.4.3 包含/引用容器的部分

描述引用有效(子)容器的名称及其多重性和范围/依赖性。

10.1.5 配置类标签

配置参数部分通过标签补充了每种类型的配置类的额外说明:

  • 编译前:指示配置参数是否应为编译前配置类。
  • 链接时:指示配置参数是否应为链接时配置类。
  • 构建后:指示配置参数是否应为构建后配置类。

10.2 一般配置规范

10.2.1 配置文件

有关配置文件结构的更多信息,请参见第5.1章。配置数据文件应具有可读性和可理解性。

10.2.2 配置参数的实现名称

配置参数的名称在相应的BSW模块规范中定义。示例包括:

  • 名称:EepNormalWriteBlockSize
  • 描述:在正常模式下,每个作业处理周期内写入的字节数。实现类型为Eep_LengthType。

配置参数名称的规范要求与API函数和实现文件的命名原则相同。所有配置参数名称应以模块缩写或其大写形式开头。

10.2.3 Pre-Compile Time Configuration

预编译时配置参数在编译开始之前设置,因此相关配置必须在源代码级别完成。这种配置允许将静态配置与实现解耦。示例代码如下:

/* File: CanTp_Cfg.h */  
/* Pre-compile time configuration */  
#define CANTP_USE_NORMAL_ADDRESSING STD_OFF  
#define CANTP_USE_NORMAL_FIXED_ADDRESSING STD_OFF  
#define CANTP_USE_EXTENDED_ADDRESSING STD_ON  
10.2.3 编译前配置

编译前配置参数在编译开始之前设置,因此相关配置必须在源代码级别完成。这种配置允许将静态配置与实现解耦。

10.2.4 链接时配置

链接时参数的使用允许在交付为目标代码的BSW模块中实现可配置功能。这种配置在编译后、链接前实现。

10.2.5 构建后配置

10.2.5 Post-Build Time Configuration

后构建时配置机制允许BSW模块在以目标代码形式部署时实现可配置功能。后构建时配置的主要特点和要求如下:

  1. 后构建配置数据结构的实现

    • 如果BSW模块具有后构建时配置参数,则后构建配置数据必须在一个结构中定义,即后构建配置数据结构。
  2. 配置指针的使用限制

    • 每个BSW模块的后构建配置数据结构应通过配置指针进行引用。只有ECU状态管理器(EcuM)包含指向需要在BswM初始化之前初始化的后构建配置数据结构的配置指针。其余的BSW模块通过BswM使用配置指针进行初始化。
  3. 后构建配置数据的存储

    • 后构建配置数据位于一个单独的段中,可以独立于实际代码加载。这种情况适用于可加载的CAN配置等场景。为了实现配置的独立加载,必须知道这些参数的内存布局。
  4. 指向后构建时可配置数据的引用指针

    • 如果BSW模块在运行时依赖于后构建配置数据,则应使用指向外部配置实例的引用(指针)。该引用应通过BSW模块的初始化函数(即<Mip>_Init())通过一个常量限定的函数参数提供。
  5. 示例代码

    • 示例代码展示了如何定义后构建时配置数据结构和初始化函数:
      /* File: ComM_PBcfg.h */  
      ...  
      /* Type declaration of the Configuration Type */  
      struct ComM_ConfigType_Tag {  
          ...  
      };  
      ...  
      /* File: ComM_PBcfg.c */  
      #include <ComM.h>  
      ...  
      /* post-build time configurable data */  
      const ComM_ConfigType ComM_Config = {  
          ...  
      };  
      ...  
      /* File: ComM.h */  
      #include <ComM_PBcfg.h>  
      ...  
      /* Forward declaration: */  
      typedef struct ComM_ConfigType_Tag ComM_ConfigType;  
      extern void ComM_Init(const ComM_ConfigType * ComMConfigPtr);  
      ...  
      
  6. 固定内存位置的后构建配置

    • 如果后构建配置放置在固定的内存位置,并且没有BSW模块的配置使用在后构建时需要解决的变更点(variation points),则可以将引用解析为常量指针。在这种情况下,将固定指针传递给BSW模块的初始化函数。任何间接引用应尽可能简单。
  7. 后构建时配置参数的定义

    • 所有后构建时配置参数在后构建时配置源文件中定义,并在后构建时配置头文件中声明。

总结来说,后构建时配置为BSW模块提供了灵活性,使其能够在不重新编程ECU的情况下,根据不同的配置需求进行调整。通过定义后构建配置数据结构和使用配置指针,模块能够在运行时根据需要加载和初始化配置。

10.2.6 配置变体

独立于配置类(编译前、链接时和构建后),配置变体使ECU能够在车辆中根据所选配置变体重用不同角色。不同的配置变体可以在同一配置中存在,这些变体通过不同的变更点进行指示。

### 回答1: AUTOSAR是一种汽车电子系统的标准化架构,SWS代表的是Software Specification,即软件规范。而Diagnostic Event Manager(DEM)是一种应用于车载诊断系统的软件,主要用于监控车辆中的各种故障诊断事件,例如发动机故障代码、传感器故障等等。 Demo作为一个基本的软件单元,属于Diagnostic Communication Manager(DCM)的一部分,主要有三个任务:监测车辆中的各种故障诊断事件、生成并发送伴随信息到其他汽车电子控制单元(ECU)以便进行故障诊断和修复、与其他的DCM实例交换信息,以便协同处理。 在AUTOSAR框架下,DEM的功能是由DCM提供,并与其他ECU同步工作以确保整个车辆的状态与性能都处于最佳状态。实现这个功能需要DEM与DCM之间的数据交互、状态传递和控制。同时,DEM还必须能够处理各种诊断类别和事件类型的数据,包括:DTC(Diagnostic Trouble Code)、FM(Failure Memory)、PIP(Permanent Initialization Fields)、FDC(Fault Detection and Counter)等等。 总之,AUTOSAR-SWS-DiagnosticEventManager是用于汽车电子控制单元(ECU)的诊断系统中的一个重要模块,它通过DSA(Diagnostic Services Active)和DSD(Diagnostic Services Data)表示的诊断信息来监测车辆各种故障情况,并与其他ECU进行数据交互和状态控制,成为整个电子系统的关键组成部分。 ### 回答2: AUTOSAR(汽车开放系统和网络联盟)是一个全球跨越商业和学术行业的合作组织,分别由汽车制造商、供应商和工具供应商组成。AUTOSAR旨在创建一个标准的软件架构和平台,以支持汽车电子系统开发,从而提高可重复性、互操作性和可维护性。其中一个AUTOSAR的子系统就是软件诊断系统(SW-Diagnostic)。 AUTOSAR-SWS-DiagnosticEventManager是AUTOSAR软件诊断事件管理器(Diagnostic Event Manager,DEM)的标准化实现。它主要的作用是监测发生在车辆中的故障,并向车辆系统的其他模块或外部设备(例如诊断工具)提供相关信息,以便及时进行故障排查和维修。其具体功能包括以下内容: 1. 故障代码管理:管理诊断事件的故障代码,包括与发生的故障相关的描述、优先级和故障类型等信息。 2. 事件管理与分类:管理和分类所有SW-Diagnostic中的事件,确保不重复且能够追踪事件。 3. 事件信息提供:向其他模块和外部设备提供SW-Diagnostic事件的相关信息,包括诊断会话的控制和管理。 4. 接口统一:为不同类型的诊断功能提供一个统一的接口,以方便进行故障检测和维修工作。 5. 自愈能力支持:提供自我诊断和故障排查的相关信息,以支持自愈能力的实现。 总之,AUTOSAR-SWS-DiagnosticEventManager是SW-Diagnostic的关键组件之一,其标准化实现可以使车辆系统的诊断和维修能力得到大大提升,同时也可以支持车辆智能化和自主驾驶等新技术的发展。 ### 回答3: AUTOSAR SWS DiagnosticEventManager是汽车行业中广泛使用的一种系统管理软件。主要用于故障诊断和错误处理等相关的功能。它的目标是提高汽车系统诊断效率和确保更加可靠的错误检测、管理和处理。该软件主要包含以下几个模块: 1. DtcStatusManager:负责管理汽车系统中的所有诊断事件的状态。它可以记录诊断事件的数量、类型和状态,并根据需要生成报告或警报。 2. Dem:负责实现汽车系统中的数据采集和故障诊断。它的主要职责是收集汽车各个部件的故障信息,并分析警告信息是否属于实际故障,从而快速定位故障点,减少故障排查时间。 3. DemEventParameter:是一个定义了不同故障事件对应的传输参数的类。它可以定义如何传输故障事件数据和信息,以实现故障诊断的效果。 4. DemEvent:是一个定义了诊断事件类型和数据信息的类。它可以记录汽车系统中发生的故障事件,包括故障代码、故障信息、故障类型等。 AUTOSAR SWS DiagnosticEventManager可以与其他汽车系统软件互相配合,优化和提高汽车整体性能。 例如,它可以与OBD系统相结合,从而实现更好的故障诊断和处理效果,同时也可以更加方便地对汽车故障信息进行采集和记录。该软件主要应用于汽车电子控制单元、汽车仪表盘显示模块、汽车音响等车载系统中。它的目标是帮助汽车制造商提高汽车诊断效率和检测水平,从而提高车辆安全性和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值