程序员经验分享-hwhale

一文搞懂AUTOSAR的DEM模块

2023-05-16

 Dem全称为Diagnostic Event Manager，负责故障事件的处理、故障数据的存储和管理。

简单说其功能是故障事件确认前的故障debounce，故障事件确认时的故障数据存储，故障发生后的故障老化、故障替代。

1、AUTOSAR DEM模块整体框架

AUTOSAR标准中对Dem模块最上层分了两菜单栏（参见图1），分别是

  • DemConfigSet
  • DemGeneral

DemConfigSet 负责不同DTC、event等的配置。

DemGeneral 负责DTC、event的共用部分，包括冻结帧、扩展帧、使能条件等。 

图1 Dem的上层架构

下面主要介绍上层菜单下的配置选项。

DemConfigSet 下包含图2所示的配置项，下面针对常用的配置选项进行介绍。

图2 DemConfigSet配置项 

1. DemComponent

DemComponent又名MonitorComponent，主要用于有关联的故障事件。

比如传感本身发生故障，这时控制器读取的数据应该被视为无效。

一个DemComponent是若干故障事件的集合：

在DemComponent内部，故障事件有优先级：

当最高优先级的故障事件状态为Failed导致其他故障事件状态也为Failed。

或者父节点DemComponent的状态为Failed，导致子节点DemComponent内的故障事件状态变成Failed，这种故障叫做连续错误（consecutive FAULT）。

其他被认为是偶发错误（casual FAULT）。

另外如果DemComponent内部故障事件优先级被忽略，那么仅有当父节点DemComponent的状态为Failed导致子节点DemComponent内的故障事件状态变成Failed被称作是连续错误（consecutive FAULT）。

 2. DemDTCAttributes

DemDTCAttributes用于配置DTC的属性包括：

  1. 老化周期
  2. 故障优先级
  3. 存储方式（立即存储还是下电存储）
  4. 快照数据需记录的最大组数
  5. 参考的冻结帧数据快照数据
  6. 故障数据存储的memory

其中快照数据、扩展数据等需要在DemGeneral中配置。

3. DemDTC

DemDTC用于配置故障的DTC值（诊断故障码）、DTC的严重程度以及参考的DTC属性、Obd属性等。

4. DemDebounceCounterBaseClass、DemDebounceTimeBaseClass

这两项主要用于为不同的故障事件配置不同的debounce策略，

可以是基于计数器的debounce策略，

也可以是基于时间的debounce策略，

或者由SWC自定义，具体请查看AUTOSAR故障Debounce策略。

5. DemObdDTC

DemObdDTC用于配置obd类故障事件是否支持Pto以及故障事件的DTC值等。

6. DemPidClass

用于配置Pid以及相关联的应用层信号。

7. DemEventParameter

DemEventParameter用于配置故障的类型（BSW or SWC）、故障需要多少个运行循环才能确认、是否支持预存储功能、故障事件的debounce策略以及参考的DTC属性、DemComponent、使能条件、运行循环等。

以上参数基本为DemConfigSet比较重要的配置项，其他未介绍的可以查看标准。

DemGeneral

DemGeneral主要用于配置DemConfigSet中不同event、DTC共用的一些参数，所以相对来说比较杂，下面针对一些进行介绍。

1. DemDataElementClass

DemDataElementClass用于配置内部、外部元素，如表1所示，用于配置扩展数据和快照数据的数据源。其中内部元素如表2所示，外部元素主要分通过C/S或S/R接口获取应用层的数据。

 

2. DemDidClass

DemDidClass用于配置快照数据的Did 以及对应的DemDataElementClass。

3. DemExtendedDataRecordClass

该项用于配置扩展数据的id、扩展数据触发储存条件和参考的DemDataElementClass。

4. DemFreezeFrameRecordClass

该项主要用于配置快照数据的触发存储条件以及快照id。

5. DemFreezeFrameClass

该项用于配置快照数据包含的数据，数据来自DemDataElementClass。

 DEM DTC的Debounce策略

故障诊断是由Dem模块和SWC共同完成的，如下图3所示，SWC中的Monitor Function对故障条件进行实时监控，并实时将故障条件的判定结果反馈至Dem模块判断是否发生故障，如图4所示。

图3 SWC与Dem模块

图4  Dem_SetEventStatus调用示意图

故障诊断由SWC与Dem模块共同完成的，故故障的debounce策略即可在SWC中实现，也可在Dem模块中实现。如果在SWC中，Dem_SetEventStatus()函数传给Dem的状态为passed或failed，如果在Dem，Dem_SetEventStatus()函数传给Dem的状态为prepassed或prefailed。

下面主要介绍在Dem中实现的debounce策略。Dem中提供了两种debounce策略，分别为基于计数器的debounce策略和基于时间的debounce策略，如图5所示。

图5 dem模块支持的debounce策略

基于计数器的Debounce策略

在这种策略下，Dem会提供一个计数器（fault detection counter）用来记录判断的结果，当Diagnostic Monitor上报至dem的状态为prefailed，计数器会按步长增加，当达到设定的限值时，故障状态变成failed。当上报状态为prepassed，计数器按步长减少，当达到设定的限值时，故障状态变成passed。当以下对改策略涉及的重要参数进行解释。

1、FDC(fault detection counter)：错误计数器，其范围为-128~127；

2、DemDebounceCounterFailedThreshold：故障从prefailed状态跳转至failed的限值；

3、DemDebounceCounterPassedThreshold：故障从prepassed状态跳转至passed状态的限值；

4、DemDebounceCounterIncrementStepSize：当DiagnosticMonitor上报Prefailed，错误计数器的增加量；

5、DemDebounceCounterDecrementStepSize：当DiagnosticMonitor上报Prepassed，错误计数器减少量；

6、DemDebounceCounterJumpDown：是否使能JumpDown功能。JumpDown功能是指当上一次Diagnostic Monitor上报的状态是prefailed，而当前上报的是prepassed，且当前计数器的值大于DemDebounceCounterJumpDownValue，错误计数器的值会重置为DemDebounceCounterJumpDownValue。如果JumpDown功能禁止，计数器按步长减少；

7、DemDebounceCounterJumpDownValue：当JumpDown功能使能，该变量定义了计数器的重置值；

8、DemDebounceCounterJumpUp：是否使能JumpUp功能。JumpUp功能是指当上一次Diagnostic Monitor上报的状态是prepassed，而这次上报的是prefailed，且当前计数器的值小于DemDebounceCounterJumpUpValue，错误计数器的值会重置为DemDebounceCounterJumpUpValue。如果JumpUp功能禁止，计数器按步长增加；

9：DemDebounceCounterJumpUpValue：当JumpUp功能使能，该变量定义了计数器的重置值；

下面用图6来讲解以上参数及基于计数器的debounde策略。

图6 基于计数器的debounce策略图

其中：

1、5表示JumpDown功能；

3、4表示JumpUp功能；

2表示当前计数器小于DemDebounceCounterJumpDownValue ，所JumpDown功能没有激活；

6表示DemDebounceCounterJumpDownValue ；

7表示DemDebounceCounterJumpUpValue；

8表示DemDebounceCounterFailedThreshold ；

9表示DemDebounceCounterPassedThreshold ；

10、12表示故障确认，由于计数器的值达到了fail的限值；

11故障恢复，由于计数器的值达到pass的限值；

13表示Dem接收的状态为failed，所以故障直接置位；

14表示Dem接到的状态为passed，所以故障恢复；

15表示DemDebounceCounterIncrementStepSize；

16表示DemDebounceCounterDecrementStepSize；

基于时间的Debounce策略

在这种策略下，计数器的初始值为0，其范围为-128~127，当Dem接收到Diagnostic Monitor发送的状态值开始计数，计数器的增长方向由接收到的状态决定，当计数器的值在一定时间达到阈值，完成此次判断，如果在未达到阈值时，Dem接收的状态发生变化，计数器会重新开始计数，并且计数方向也发生转变。

对于基于时间debounce的策略主要配置以下几个参数：

1、DebounceTimeBasedTaskTime：该变量定义基本的检测周期；

2、DemDebounceTimeFailedThreshold：定义故障状态从prefailed跳转至failed需要多少个DebounceTimeBasedTaskTime周期；

3、DemDebounceTimeFailedThreshold：定义故障状态从prepassed跳转至passed需要多少个DebounceTimeBasedTaskTime周期；

下面用图7来讲解以上参数以及基于时间的debounce策略。

图7 基于时间的debounce策略图

其中：

t failed：表示故障failed需要的时间，该值等于DebounceTimeBasedTaskTime乘以DemDebounceTimeFailedThreshold；

t passed：表示故障passed需要的时间，该值等于DebounceTimeBasedTaskTime乘以DemDebounceTimePassedThreshold；

1、表示Diagnostic Monitor传至Dem的状态为prefailed；并经过t failed时间故障状态编程failed；

2、表示Diagnostic Monitor传至Dem的状态为prepassed；此时计数器重新开始计数;

3、由于2时刻开始计数未达到阈值时，Dem接收的状态发生变化，此时计数器开始重新计数，并计数方向发生变化，经过t failed时间后，故障状态编程failed。

4、Dem接收的状态为failed，所以故障直接置位了；

5、Dem接收的状态为passed，所以故障直接恢复了；

6、表示故障已发生；

7、表示故障未发生；

03.

DEM 故障数据存储策略

在AUTOSAR的Dem模块中提供了DemEventDisplacementStrategy配置选项用于选择不同故障数据存储策略，分别为DEM_DISPLACEMENT_NONE,DEM_DISPLACEMENT_PRIO_OCC,DEM_DISPLACEMENT_FULL。

当故障存储策略选择为DEM_DISPLACEMENT_NONE，如果故障数据存储区存满时，新发生故障的数据不会被存储；当故障存储策略选择DEM_DISPLACEMENT_PRIO_OCC，通过比较故障优先级(Priority)、故障发生时间(Occurrence)、bit6(TestNotCompletedThisOperationCycle bit)状态判断故障数据是否存储；当故存储策略选择DEM_DISPLACEMENT_FULL时，通过比较故障优先级(Priority)、故障发生时间(Occurrence)、bit6(TestNotCompletedThisOperationCycle bit)状态和故障状态(Active/Passive status)判断故障数据是否存储。

其中故障优先级(Priority)是在开发Dem模块时，对各故障配置一个固定的优先级；故障发生时间(Occurrence)是指故障上报至Dem模块的时间，当故障再次发生(同一个驾驶循环)新的故障数据会覆盖上次一的故障数据；故障状态(Active/Passive status)是指故障当前的状态，Active代表故障发生，Passive代表故障未发生。

图8是AUTOSAR故障数据存储的详细逻辑图。

图8 故障存储策略

如果DemOBDEventDisplacement设置为TRUE，，则故障存储策略会忽略满足以下条件的故障：

已有故障为排放相关的故障(AND)已有故障触发了MIL(OR)Pending位置位为1(OR)(已有故障有合法的冻结帧数据(OR)已有故障优先级大于或等于当前故障)。

04.

DEM DTC 状态位含义

DTC status表示一个故障的状态，是故障数据存储、故障老化等机制的依据条件之一，DTC status总共包含8位，各位的含义见表3：

Bit

描述

0

TestFailed

1

TestFailedThisOperationCycle

2

PendingDTC

3

ConfirmedDTC

4

testNotCompletedSinceLastClear

5

testFailedSinceLastClear

6

TestNotCompletedThisOperationCycle

7

WarningIndicatorRequested

表3 DTC status

下面先对八个状态位进行详细介绍。

Bit0 testFailed

故障诊断通常是周期性执行的，如果当前周期检测到故障条件满足，表示故障发生了，testFailed会立即置1，下一个周期如果检测到该故障条件未满足，则testFailed会立即恢复为0。testFailed恢复为0还有两种情况：一种调用Dem<…>clearDTC函数清除故障信息（USD 0x14服务，或OBD 0x04服务），第二种调用Dem_ResetEventStatus函数对该故障状态位进行复位。testFailed逻辑图见图9。

AUTOSAR标准中对testFailed还有关于是否需要存储的描述，可以通过配置项DemStatusBitStorageTestFailed进行配置。对于支持WWH-OBD的控制器则需将该配置项配置为true。

图9 testFailed位逻辑图

Bit1 TestFailedThisOperationCycle

TestFailedThisOperationCycle用于表示当前运行循环是否出现过testFailed = 1。一旦testFailed出现过置1的情况，TestFailedThisOperationCycle会被置1，TestFailedThisOperationCycle位恢复为0的条件有两种：第一种是用Dem<…>clearDTC函数清除故障信息（USD 0x14服务，或OBD 0x04服务）；第二种是该运行循环结束或新的运行循环开始。TestFailedThisOperationCycle的变化逻辑请参照图10.

 

图10 TestFailedThisOperationCycle位逻辑图

Bit2 PendingDTC

PendingDTC用于表示故障在当前运行循环或者上一个运行循环出现过testFailed被置位为1，并且PendingDTC的状态只有在当前循环测试完毕之后才会更新，也就是说如果上一个循环故障发生了，PendingDTC位置1，当前循环故障没有发生，但是PendingDTC仍为1，只有在下一个循环才会恢复为0。该位恢复0的条件有两种：第一种是用Dem<…>clearDTC函数清除故障信息（USD 0x14服务，或OBD 0x04服务）；第二种是当前运行TestFailedThisOperationCycle未置为1，且TestNotCompletedThisOperationCycle未置为1，同时运行循环结束或者下一个运行循环开始。该位的逻辑图见图11。

PendingDTC主要用于某些故障需要多个运行循环才能确认（Bit3 confirmedDTC=1）的情况下，目前遇到的主要是OBD排放相关的故障需要实现PendingDTC位。

图11 PendingDTC逻辑图

Bit3 confirmedDTC

confirmedDTC表示故障已经确认，故障数据存储至EEPROM或者FEE（如果支持实时存故障数据）。另外需要注意的是confirmedDTC置位为1不表示故障还发生，故障当前是否发生主要由testFailed状态确定。该位恢复为0的条件有以下三种：第一种为故障老化；第二种为故障替代；第三种是用Dem<…>clearDTC函数（USD 0x14服务，OBD为 0x04服务）清除故障信息。该位的逻辑图见图12.

图12 confirmedDTC逻辑图

Bit4 TestNotCompletedSinceLastClear

TestNotCompletedSinceLastClear表示自从上次调用Dem<…>clearDTC函数清除故障信息后，是否成功执行对故障进行检测，该位的逻辑图见图13。

TestNotCompletedSinceLastClear=1，表示该故障自从上次清除之后还未进行检测。

TestNotCompletedSinceLastClear =0，表示该故障自从上次清除之后已成功进行检测。

图13 TestNotCompletedSinceLastClear逻辑图

Bit5 TestFailedSinceLastClear

TestFailedSinceLastClear表示自从上次动用Dem<…>clearDTC函数清除故障信息后，testFailed是否出现过置位为1。TestFailedSinceLastClear=0表示自从上次清除DTC之后，故障未发生过，TestFailedSinceLastClear=1表示自从上次清除之后故障又发生过。该位的复位条件有三种：第一种为调用Dem<…>clearDTC函数（USD 0x14服务，OBD为 0x04服务）清除故障信息，第二种是故障老化；第三种为故障替代。该位的逻辑图请参照图14。

图14 TestFailedSinceLastClear逻辑图

Bit6 testNotCompletedThisOperationCycle

testNotCompletedThisOperationCycle表示该运行循环故障是否进行检测，或者说故障是否进行测试，该位的逻辑图见图15。

testNotCompletedThisOperationCycle=0表示当前循环已对该故障进行检测，进行测试。

testNotCompletedThisOperationCycle=1表示当前循环还未对该故障进行检测，进行测试。

图15 testNotCompletedThisOperationCycle逻辑图

Bit7 WarningIndicatorRequested

WarningIndicatorRequested用于某些故障发生需要通过仪表盘的MIL灯通知用户。

WarningIndicatorRequested=1表示请求点亮仪表盘的MIL灯。

WarningIndicatorRequested=0表示不请求点亮仪表盘的MIL灯。

对于不需要通过仪表盘告知用户的故障，WarningIndicatorRequested始终为0，该位的逻辑图见图16.

图16 WarningIndicatorRequested逻辑图

上面主要单独对DTC status的各位进项介绍，下面通过一张状态图（如图17）来介绍各状态位的变化。

图17 状态图

其中：

0 表示接收到清除故障信息命令，初始化DTCstatus byte；

1,2表示在运行循环1中故障检测，或者说故障测试已经开始，所以bit4、bit6状态发生变化；

3,4,5,6表示testFailed，TestFailedThisOperationCycle，pendingDTC，testFailedSinceLastClear位同时从0变为1，表示已检测到故障发生，但该故障需要两个运行周期才能确认，所以confirmedDTC还是为0.

7表示故障恢复；

8表示故障再次发生；

9,10表示在运行循环1结束，运行循环2开始的分界点，由于运行循环2中故障还未进行故障诊，所以testFailedThisOperationCycle状态从1变成0，testNotCompletedThisOperationCycle状态从0变成1；

11表示在运行循环2中故障检测还未开始，这时testfailed的状态可以有制造商指定是否保留上一个循环中testFailed的状态，在AUTOSAR中可以通过DemStatusBitStorageTestFailed配置项配置；

12表示在运行循环2中故障检测已经执行；

13、14表示在运行循环2中故障发生了，所以testfailed、testFailedThisMonitoringCycle置位为1；

15、由于故障在两个循环中都存在，confirmedDTC置位为1；

16、用于记录故障连续在多少个运行循环出现，用于确认故障的confirmedDTC是否达到置1的条件；

一文搞懂AUTOSAR的DEM模块之前分开写过几篇DEM模块的文章，为了方面大家查找，把这几篇进行汇总。https://mp.weixin.qq.com/s?__biz=Mzg4NjIxODk4Mg==&mid=2247496230&idx=1&sn=711b3032878d7fefe15ab2cf78595ccb&chksm=cf9fbbaff8e832b97b752c0559a2cc41348cfd8c78ddb19be019608a87d23c98ed4d0beaab64&scene=21#wechat_redirect

Autosar诊断基础——诊断事件管理(DEM)_u012406840的博客-CSDN博客1https://blog.csdn.net/u012406840/article/details/107603731

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)

AUTOSAR

dem

一文搞懂

一文搞懂AUTOSAR的DEM模块 的相关文章

  • AUTOSAR——AUTOSAR基础

    一 AUTOSAR AUTOSAR全称为 AUTomotive Open System ARchitecture xff0c 译为 汽车开放系统体系结构 二 AUTOSAR核心思想 1 xff09 提倡 在标准上合作 xff0c 在实现上竞

  • AUTOSAR_DCM&DEM(UDS&OBD)

    1 术语与缩写 术语 DCM Diagnostic Communication Manager DEM Diagnostic Event Manager UDS Unified diagnostic services OBD On Boar

  • CP AUTOSAR 简介

    嵌入式系统不支持硬件抽象 xff0c 使得我们每次在进行新的处理器更换之后 都需要进行重新进行底层软件的开发 2003年建立autosar 组织 autosar官方文档非常长2万多页 xff0c 从这里可以看出什么 xff1f 1 auto

  • Autosar 软件中间件

    我们都知道手机 xff0c 电脑啥的在应用之下 xff0c 硬件之上 xff0c 还有一个东西叫操作系统 xff0c 车辆里也有类似的东西 操作系统 xff0c 中间件 xff0c 应用软件 各司其职分工不同 操作系统 我负责对硬件 xff

  • AUTOSAR和ROS有哪些联系和区别

    AUTOSAR和ROS有哪些联系和区别 xff1f AUTOSAR和ROS有哪些联系和区别 xff1f 用ROS可以实现AUTOSAR的功能吗 xff1f 从Linux和Ros系统转向AP该如何转 xff1f 为什么需要转 xff1f AP

  • ETAS Adaptive AUTOSAR 自适应平台示例视频教程

    ETAS AP AUTOSAR自适应平台示例视频教程 本系列文章旨在提供一个详细的操作指南 xff0c 以构建ETAS AP AUTOSAR自适应平台的示例 实践练习的目标是加强AUTOSAR自适应平台中的理论概念 xff0c 并更好地理解

  • Adaptive AUTOSAR 简介 (2021版)

    目录 1 Adaptive AUTOSAR 简介 Adaptive平台 一种新的 AUTOSAR 1 1 Adaptive的案例 1 2 经典平台与适应性平台的比较 1 3 单一系统 1 4 架构 逻辑架构 1 5 软件架构 本文图片来源

  • 从Adaptive AUTOSAR的角度看SOA

    前言 身处汽车行业的我们深知 xff0c 新技术的应用或者新概念的提出 xff0c 一定是事出有因的 通常是为了抢夺新技术高地 xff0c 让汽车更好地满足未来的需求 那么 xff0c 汽车电子电气架构领域掀起的这股SOA热潮是由什么导致的

  • Adaptive AUTOSAR——Update and Configuration Management（VRTE 3.0 R21-11）

    16 1 What is Update and Configuration Management 更新和配置管理 xff08 UCM xff09 是自适应平台服务中的一个功能集群 作为一种自适应平台服务 xff0c UCM实现了自适应平台的

  • Adaptive AUTOSAR 文档官方如何阅读

    目前很多关于 Adaptive AUTOSAR 的文章都是官方文档的简化翻译 xff0c 不如直接看官方文档更全面深入 Adaptive AUTOSAR 文档官方下载地址 Adaptive Platform AUTOSAR https ww

  • Adaptive AUTOSAR-诊断管理-Diagnostic Server概述和诊断通信

    Diagnostic Server 对于AUTOSAR adaptive平台 xff0c 不用重新刷写整个ECU即可添加新的软件包 xff0c 各个软件包描述为SoftwareClusters xff0c 每个SoftwareCluster

  • Autosar Xcp移植

    前言 xff1a 可能有兄弟胸中有点疑问 Vector ETAS等软件包都有XCP xff0c 你移植个吊 xff0c 但是我的MICORSAR BSW中没发现XCP静态代码 xff0c 倒是在CFG中发现了XCP配置选项 xff0c 难道

  • [Adaptive Autosar]深入理解--Persistency

    目录 1 Per架构 2 Per初始化 3 Per错误处理 4 多进程访问 5 冗余存储 6 安装和更新per数据 7 Key Value 方式 8 file storage 方式 9 典型使用代码 Persistency模块对比 CP 中

  • AutoSar之微控制器抽象层MCAL

    微控制器抽象层位于AUTOSAR BSW的最底层 xff0c 包含内部驱动 xff0c 可直接访问微控制器和外设芯片 从具体应用来看 xff0c MCAL主要包括微控制器驱动 存储器驱动 通信驱动和输入输出驱动四个部分 xff0c 各部分又

  • 雾化片的工作原理_超声波加湿器原理，一文搞懂

    打开水箱盖子 xff0c 加入适量的纯净水 xff0c 接通机器电源 xff0c 打开控制开关 xff0c 一股白色的水雾瞬间从机器上方喷射出来 没错 xff0c 这就是我们家庭常用的超声波加湿器 而在使用过程中有这么几个疑问 xff1a

  • 一文搞懂C语言中位域

    位域的定义和存在的意义 定义 xff1a 允许在一个结构体中以位为单位来指定其成员长度 xff0c 这种以位为单位的结构体成员称为 位段 或者 位域 意义 xff1a 有些信息在存储时 xff0c 只需占几个或一个二进制位 xff08 bi

  • 【ROS进阶】一文搞懂ROS话题通信机制与消息队列

    文章目录 一 话题通信机制解析1 话题通信机制简介2 消息队列分析3 使用技巧 二 实验验证 xff08 一 xff09 subscriber队列长度对数据传输影响 xff08 二 xff09 数据传输时间延迟 三 总结 一 话题通信机制解

  • AUTOSAR-自旋锁（spinlock）与互斥锁

    AUTOSAR多核OS为实现核间资源互斥 保证数据一致性 设计了自旋锁机制 该机制适用于核间资源互斥 对于多核概念 需要一种新的机制来支持不同内核上任务的互斥 这种新机制不应在同一内核上的 TASK 之间使用 因为它没有意义 在这种情况下

  • IPC-核间通讯

    1 IPC通讯是AUTOSAR体系结构中的核心组成部分 它使得不同的软件组件可以相互通信 协同工作 从而实现整车系统的功能 IPC可以理解为核间通讯 就是一个芯片有多个核 现在想让多核之间通信 达到下面几个目的 数据共享 不同的软件组件之间

  • Autosar软件架构

    软件架构 应用层通过 Simulink模型实现 模型的代码生成使用统一配置脚本 底层软件模块满足AUTOSAR 4 2 1标准要求 其软件架构如下图所示 软件架构 2 2 2 Com通信模块配置 BCU通过唤醒信号控制相应CAN消息的通信使

随机推荐

  • Adaptive AUTOSAR 简介 (2021版)

    目录 1 Adaptive AUTOSAR 简介 Adaptive平台 一种新的 AUTOSAR 1 1 Adaptive的案例 1 2 经典平台与适应性平台的比较 1 3 单一系统 1 4 架构 逻辑架构 1 5 软件架构 本文图片来源

  • 从Adaptive AUTOSAR的角度看SOA

    前言 身处汽车行业的我们深知 xff0c 新技术的应用或者新概念的提出 xff0c 一定是事出有因的 通常是为了抢夺新技术高地 xff0c 让汽车更好地满足未来的需求 那么 xff0c 汽车电子电气架构领域掀起的这股SOA热潮是由什么导致的

  • 什么是BSP？理解LINUX BSP

    BSP 可支持操作系统更好地运行于硬件主板 BSP xff08 Board Support Package xff09 指板级支持包 对于一般的嵌入式系统 xff0c 硬件部分需要嵌入式硬件工程师设计硬件电路 xff0c 而新出厂的电路板需

  • c++11 std::move() 的使用

    std move函数可以以非常简单的方式将左值引用转换为右值引用 xff08 左值 左值引用 右值 右值引用 参见 xff1a http www cnblogs com SZxiaochun p 8017475 html xff09 通过s

  • Adaptive AUTOSAR 学习笔记 3 - AP 背景、技术及特征

    本系列学习笔记基于 AUTOSAR Adaptive Platform 官方文档 R20 11 版本 本文从AUTOSAR EXP PlatformDesign pdf开始 xff0c 一边学习 xff0c 一边顺带着翻译一下 尽力而为 x

  • MySQL导入数据（命令行、脚本方式）

    docker安装MySQL并导入数据 安装步骤省略 xff0c 详细可参考百度上文档 一 命令方式 1 把数据传进服务器中 dfc span class token annotation punctuation 64 BBC span sp

  • Linux 终端快捷键

    Linux 终端快捷键 你可能会有这样的疑问 xff1a 对于有些快捷键 xff0c 明明有等效的 一个按键就能搞定的操作 xff0c 为什么非要舍近求远 用两个组合键来实现 xff1f 当对键盘 终端命令熟练到一定程度之后 xff0c 你

  • Adaptive AUTOSAR----Adaptive studio

    Adaptive studio Adaptive Studio 是包含在 RTA VRTE SK 中的 AUTOSAR 编辑器 Adaptive studio 通过高级抽象支持所有 adaptives autosar arxml 元素的配置

  • Linux tcpdump命令详解

    简介 用简单的话来定义tcpdump xff0c 就是 xff1a dump the traffic on a network xff0c 根据使用者的定义对网络上的数据包进行截获的包分析工具 tcpdump可以将网络中传送的数据包的 头

  • 什么是 E2E 保护 ？

    安全在每个领域都是一个永恒的话题 xff0c 汽车也不例外 xff0c 而随着最近几年汽车电动化 智能化和网联化的发展 xff0c 汽车安全也越来越受到用户及开发人员的重视 xff0c 安全的要素也是多方面的 xff0c 例如用户可能关心在

  • CAN总线基础

    概述 汽车电子设备的不断增多 xff0c 对汽车上的线束分布以及信息共享与交流提出了更高的要求 传统的电气系统往往采用单一连接的方式通信 xff0c 这必将带来线束的冗余以及维修的成本的提高 单一布线连接 传统的单一通信的对接方式 xff0

  • 说一说LIN总线

    前几天小编画点时间看了一些关于LIN总线基础的内容 xff0c 把其中的关键点提取了出来 xff0c 在这里分享给大家 在这里你可能要问 不都有CAN总线了吗 xff1f 这个LIN总线又是从哪里来的 xff1f 其实理由很简单 xff0c

  • CAN FD 介绍

    随着电动汽车 xff0c 无人驾驶汽车技术的快速发展 xff0c 以及对汽车高级驾驶辅助系统和人机交互HMI需求的增加 xff0c 传统的CAN总线在传输速率和带宽等方面越来越显得力不从心 xff0c 其主要原因如下 xff1a 1 通常整

  • FlexRay 介绍

    汽车上的总线技术包括 xff1a LIN CAN CAN FD FlexRay MOST及Ethernet xff0c 我们之前已经分享了LIN xff0c CAN CAN FD总线 在开始阅读之前 xff0c 如果你对已介绍的总线技术还不

  • FlexRay总线原理及应用

    由于传统的CAN解决方案不能满足汽车线控系统 xff08 X by Wire xff09 的要求 于是在 2000 年 9 月 xff0c 宝马和戴姆勒克莱斯勒联合飞利浦和摩托罗拉成立了 FlexRay 联盟 该联盟致力于推广 FlexRa

  • SENT信号介绍

    Vehicle攻城狮 The people who are crazy enough to think they can change the world are the ones who do SENT背景介绍 提到车载总线 xff0c

  • Linux 日志管理

    常用日志文件 系统日志是由一个名为syslog的服务管理的 xff0c 如以下日志文件都是由syslog日志服务驱动的 xff1a var log boot log xff1a 录了系统在引导过程中发生的事件 xff0c 就是Linux系统

  • SPI 通讯协议

    Cuitbasics 汽车ECU设计 2 2 当您将微控制器连接到传感器 xff0c 显示器或其他模块时 xff0c 您是否考虑过这两种设备是如何相互通信的 xff1f 他们到底在说什么 xff1f 事实上电子设备之间的通信就像人类之间的交

  • UART串口通讯

    UART代表通用异步接收器 发送器也称为串口通讯 xff0c 它不像SPI和I2C这样的通信协议 xff0c 而是微控制器中的物理电路或独立的IC UART的主要目的是发送和接收串行数据 xff0c 其最好的优点是它仅使用两条线在设备之间传

  • 一文搞懂AUTOSAR的DEM模块

    Dem全称为Diagnostic Event Manager xff0c 负责故障事件的处理 故障数据的存储和管理 简单说其功能是故障事件确认前的故障debounce xff0c 故障事件确认时的故障数据存储 xff0c 故障发生后的故障老

热门标签