车载软件诊断部分

最新推荐文章于 2024-07-26 08:29:16 发布
最新推荐文章于 2024-07-26 08:29:16 发布
阅读量336 收藏 10
点赞数 4
文章标签： 笔记
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/watershed1993/article/details/139775705
版权

车载软件诊断部分

CAN总线技术基础讲解合集

Link

CAN总线基础之物理层篇 20240603

汽车网络架构与常用总线汇总

CAN: Controller Area Network => 1986年德国Bosch研究开发，1991年奔驰首先应用

从以前电子元件的点对点复杂网络转向中心化简洁的网络

当前的车用总线：CAN(CANFD), LIN, 车载以太网 => LIN速率低成本低

汽车CAN网络细分：

  1. 动力CAN网络 => 高度CAN总线 PTCAN
  2. 车身CAN网络 BCAN
  3. 组合仪表CAN网络
  4. 诊断CAN网络 => 诊断工具 500kbs

上述 网络通过中心 网关/诊断接口 相连接， 汽车网络由CAN总线与LIN总线构成（后者用于低速的,比如驾驶员门控单元）

CAN总线在汽车网络中脱颖而出的秘密

采用短帧结构，报文帧的有效字节数为8个，可达汽车实时响应要求

报文ID值越小，优先级越高。非破坏性总线仲裁出力机制

可靠的CRC校验方式，满足汽车数据传输的可靠性要求

自动重发机制，自动脱离总线功能（节点错误严重的情况下）

通信距离最远达10km（速率5Kpbs以下）

通信速率最高1MB/s(此时距离最长40m)

节点数实际可达110个

CAN节点设计成本较低，通信介质采用双绞线

CAN物理层是如何保证汽车通信要求

与OSI模型相对应的话，CAN Physical Layer 对应物理层，CAN protocol对应数据链路层， 网络层以上就是empty了

实际应用中 CAN Physical Layer 分为 CAN Bus Connector, CAN Bus Medium, CAN Transceiver三个子层

CAN protocol => CAN Controller

CAN总线有ISO11898和ISO11519(低俗容错CAN)两个标准 =>一半默认为高度CAN ISO11898

异步串行通信：因为定时去采样，波特率误差会产生错误，所以需要加入填充位，用于同步

汽车CAN物理层常见故障与解析

举例：

测试CAN物理波形，发现报文出现严重的反射现象

=>就有很多 阻抗，信号反射等物理层面的性质讨论，车载软件开发毕竟与硬件联系很紧密, skip

CAN收发器坏掉了，厂家ECU有问题 and etc. => 对测试实际经验要求很高

新能源车也是要用CAN的啊

ID-RTR-FDC-DLC-Data-CRC-ACK => Data 八个字节

CAN数据链路层详解篇 20240604

CAN报文帧种类与帧格式解析

数据帧：帧起始, 仲裁段，数据段，CRC段，ACK段，帧结束 =>这个标准帧，还有扩展帧

帧起始SOF,由1个显性位组成。SOF代表“Start of Frame”（帧起始）
仲裁段ID[0:10], RTR 1bit => 1.5Byte
控制段IDE识别 1bit， RTR 1bit, DLC 4bit
数据段Data：Byte0-Byte7, 传输时首先发送MSB(最高位)，即Bit7,Bit6…Bit0 =>8Byte
CRC段CRC[0:14] + CRC界定符1bit =>2Byte
ACK段ACK应答位, ACK界定符，发送节点根据这个来判断发送成功 =>2bit
帧结束由7个连续的隐性位组成 EOF，帧间隔ITM3个连续隐形位组成，所以11个连续隐性位表示总线空闲

一个8个字节的标准帧，不考虑填充位，就是108bit

远程帧：RTR用于区别数据帧和远程帧，所以两者ID反而可以相同

错误帧

过载帧

帧间隔

CAN总线竞争与仲裁机制

ID值越小，优先级越高

CAN节点状态与错误处理机制

CRC错误

位填充错误

应答错误：发送节点在ACK阶段没有接收到应答信号

位发送错误

格式错误

CAN分析仪常用功能有哪些

数据链路层测试需求：报文自动化脚本发送… Macro File

CAN物理层测试需求：物理波形测量…

CAN FD基础 20240606

CAN FD与CAN2.0的区别

支持更高的速率

单个数据帧内传送率 从 8Byte 可扩展到 64 Byte. （Data field 0 to 64 byte）

向下兼容CAN2.0

Classical CAN, CAN FD8, CAN FD64

2011年，Bosch发布了CAN替代总线：CAN FD1.1版

2015年，ISO 11898-1正式将其标准化

CAN FD应用场景：软件下载和诊断时更高的带宽

绝大多数欧美厂商将在2022年之前采用CAN FD.

CAN与CAN FD网络兼容性问题

第三代CAN之CAN XL

CAN技术的发展与汽车应用

2010： 9 Networks，70 ECUs, 6000 Message

奥迪A8多达80个CAN ECU节点

下一代：CAN XL来了

在2018年，CAN XL是由CiA组织中的特别兴趣小组SIG提出的概念，并在同年十二月份开始标准规范起草

技术要求：

数据长度：高达以太网帧长度，2048个字节

波特率：高达10+Mbit/s

协议向下兼容CAN FD

应用场景：TCP/IP在CAN XL的实现；雷达传感器；汽车标定诊断的应用

UDS诊断基础讲解合集

Link

UDS诊断基础 20240607

UDS术语解释

OBD(On-Board Diagnostic)是包含了非常多标准的集合。单就OBD而言，最初起源于CARB(California Air Resources Board 加州空气资源委员会)为1988年之后生产的加州汽车所制定的排放法规。随着这套法规逐渐被标准化实施，后续又提出了标准化的车辆数据诊断接口(SAE-J1962，也就是现在常说的OBD接口)、标准化的诊断解码工具(SAE-J1978)、标准化的诊断协议(ISO 9141-2ISO 14230-4ISO 15765-4)、标准化的故障码定义(SAE-J2012ISO 15031-6)、标准化的维修服务指南(SAE-J2000)。所以OBD是具有强制标准需要参照的，是由法规要求的，最初目的是环保，同时方便售后维修。

UDS(Unified diagnostic services)就是统一诊断服务，与OBD最大的区别就在于“Unified”上，它是面向整车所有ECU(电控单元)，而OBD是面向排放系统ECU的。并且，UDS提供的是一个诊断服务的基本框架，主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来，所以基于UDS协议的诊断又常常被称为Enhanced diagnosic(增强型诊断)，UDS不是法规要求的，没有统一实现标准，其优势在于方便生产线检测设备的开发，同时更大的方便了售后维修保养和车联网的功能实现。

应用层诊断服务实现，ISO 14229-1(UDS)
表示层N/A
会话层N/A
传输层N/A
网络层数据转化桥梁，ISO 15765-2
数据链路层底层驱动, ISO 11898-1
物理层物理媒介+用户自定义, ISO 11898

=>基于CAN线的UDS报文可以看成没有传输层

ISO 11898协议就是我们俗称的CAN底层协议（物理层和数据链路层），定义了CAN帧的电平、数据长度、发送速率、位场结构、仲裁机制、校验机制等等。

网络层由ISO15765-2定义，主要有两个作用：为上层（应用层）提供服务以及定义网络对等层之间的通信规则。比如发送方式：单帧发送或多帧发送。这取决于需要发送的数据长度，如果数据无法通过一帧CAN Message发送就需要对数据进行分割处理并通过多帧的方式发送。多帧发送的第一帧会携带总数据大小信息（包括后续帧）。

UDS诊断组成部分截止到2020年，UDS诊断由以下8个部分组成：

ISO 14229-1-2020：规范和要求；

ISO 14229-2-2013：会话层服务；

ISO 14229-3-2012：CAN实现的统一诊断服务（UDSonCAN） ；

ISO 14229-4-2012：FlexRay实现的统一诊断服务（UDSonFR） ；

ISO 14229-5-2013：Internet协议实现的统一诊断服务（UDSonIP）；

ISO 14229-6-2013：K线实现的统一诊断服务（UDSonK-Line） ；

ISO 14229-7-2015：本地互联网络实现的统一诊断服务（UDSonLIN）；

ISO 14229-8-2020：时钟扩展外围接口实现的统一诊断服务（UDSonCXPI）。

对于CAN来说，物理层和数据链路层遵循ISO 11898协议；网络层方面，Classical CAN仅有8个字节的数据场与应用层处理多帧数据的需求构成了矛盾，ISO 15765-2协议解决了该问题，我们用CAN的8字节数据场会腾出一到两个字节的做法，来体现网络层的控制信息。

客户端：Tester 诊断仪， 发送诊断请求

服务器端：某个ECU，发送诊断响应

UDS的全称是Unified Diagnostic Services（统一诊断服务）

网络层(ISO 15765-2)格式

参考：Link

UDS网络层，又称为TP层（Transport Protocol Layer）。其存在的目的是为了解决ISO 11898协议中定义的经典CAN数据链路层与ISO 14229协议中定义的应用层，彼此之间数据长度不统一的问题。经典CAN数据链路层最大能够支持8个字节，但ISO 14229并不仅仅是为了CAN总线设计的，最大容量达到4095个字节。比如VIN码是17个字节，CAN总线必然需要传递3帧才能传完VIN码，那么如何科学、快捷、安全地将多个字节通过经典CAN来进行传输，就成了一个需要解决的问题。ISO 15765-2 协议由此诞生。

报文类型：4种类型帧

单帧SF

第一帧FF:描述传输的起始

流控制帧FC：传输过程中，报文流控制

连续帧CF: 传输数据

多帧报文传输：发送方 第一帧；接收方 流控制帧； 发送方 连续帧…

网络层时间参数：Timeout value

网络层协议数据单元 PDU 数据包 N_PDU:N_AI + N_PCI + N_DATA

参数名称缩写描述
寻址信息N_AI隐含源地址，目标地址和寻址方式信息
协议控制信息N_PCI用于标示N_PDU类型：单帧，第一帧，连续帧和流控制帧
数据N_DATA包含应用层协议控制信息A_PCI和数据A_DATA

举例： 7E0h 8 02 10 01 55 55 55 55 55

7E0h： 这是报文的目标地址，表示是发送给车辆主控制单元（ECU）的。

8： 这是报文的数据长度，指示后面有8个字节的数据。

02： 第一个字节的前4位用于表示帧类型，后4位用于表示数据长度。因此，02表示的是一个单帧请求，并且数据长度为2个字节。

10： 这是服务标识符（SID），表示这是一个Diagnostic Session Control的服务请求。

01 55 55 55 55 55： 这是服务参数，可能包含有关服务请求的更多信息或参数。55 55 55 55：这些是填充字节，通常在UDS消息中用于填充未使用的部分。填充字节的值通常被设置为55（十六进制），但实际上可以是任何值。

单帧最多可以传输数据量为7个字节的UDS报文，不足7个字节则用约定的数据进行填充；当要发送的报文的数据量大于7个字节时，就需要使用首帧、连续帧和流控帧了

CAN_IDByte1 SFByte 2-8
N_AIN_PCIN_DATA

网络层的ID直接从CAN_ID映射过来，所以只要确认CAN_ID就行，无需特别去确认网络层ID

CAN_ID 11位ID没有填充形式

N_PCI 4种类型帧

网络层：错误识别与处理… 比如SF_DL错误, FF_DL错误

=>可以认为在UDS报文中，网络层就是CAN Data中第一个字节

UDS服务列表和响应规范

参考：LINK

统一诊断服务UDS(ISO 14229-1) =>处于应用层了

诊断服务: 读故障信息/清除故障信息，请求下载/数据传输/退出传输…

服务标识符

服务标示服务类型定义文档
00-0FOBD服务请求ISO 15031-5
10-3EISO 14229-1服务请求ISO 14229-1
…
A0-B9服务请求汽车制造商定义
BA-BE服务请求系统供应商定义
…
C1-C2未应用ISO 14230 保留
…

UDS本质上是一系列服务的集合。UDS的服务包含6大类，共26种。每种服务都有自己独立的ID，即SID。

功能组SID(hex)服务
Diagnositc and communutcation management function unit 诊断和通信管理功能单元10Diagnostic Session Control
11ECU Reset
27Security Access
28
3ETester Present
83
84Secured Data Transmission
85Control DTC Setting
86
87
Data transmission functional unit 数据传输功能单元22Read Data By Identifier
23Read Memory By Address
24
2A
2C
2EWrite Data By Identifier
3D
Stored data transmission functional unit 传输存储的数据功能单元14Clear Diagnostic Information
19Read DTC Information
InputOutput control functional unit 输入输出控制单元2FInput Output Control By Identifier
Remote activation of routine functional unit 远程激活功能单元31Routine Control
Upload download functional unit 上传下载功能单元34Request Download
35Request Upload
36Transfer Data
37Request Transfer Exit

切换会话模式(0x10) => 安全验证(0x27) => 应用存储区擦除(0x31) => 传输块的首地址，数据的数目(0x34) => 传输数据(0x36) => 本块传输完毕检查(0x37)

一部分服务需要切换会话模式(0x10) ，刷写ECU安全性就更高了，进一步需要安全验证(0x27)

OTA功能，这已经大多数车辆都具备的功能了，没有OTA之前，原来对控制器的软件刷写需要线下进行，还得一个一个地刷写，对于OEM来说费时费力还不讨好，而现在OTA了，用户只需要同意更新，耐心等待就可以了。OTA功能的其中一环就需要使用UDS服务进行软件刷写，同样地，也使用到了10服务，27服务，31服务，34服务，36服务，37服务等。

否定响应服务标识符NR_SI 示例 0x7F 0x19 0xXX(错误代码)

肯定响应服务标识符SI，就各种各样

举例：

Name Dir DLC Data

782 Tx d 8 02 10 01 00 00 00 00 00 =>切换session

7C2 Rx d 8 06 50 01 00 32 01 F4 00 =>每个服务的Rx 序号也是规定好的

782 Tx d 8 02 10 03 00 00 00 00 00

7C2 Rx d 8 06 50 03 00 32 01 F4 00

782 Tx d 8 02 27 01 00 00 00 00 00 => 解锁

7C2 Rx d 8 04 67 01 AA 55 00 00 00

782 Tx d 8 02 27 02 00 00 00 00 00

7C2 Rx d 8 04 67 02 00 00 00 00 00

…

应用层(ISO 14229-1)补充

ISO 14229-1 对诊断的数据格式的规范

应用层服务：有确认的服务，无确认的服务，类似TCP与UDP的区别.

UDS诊断服务主要分6部分：

  1. 诊断和通信管理功能单元 0x10, 0x11,0x27,0x3E,0x85 …
  2. 数据传输功能单元 0x22,0x23,0x2E…
  3. 传输存储的数据功能单元
  4. 输入输出控制功能的单元
  5. 远程激活功能单元
  6. 上传下载功能单元

0x10 :用于服务器不同的诊断会话。许多子服务 => 默认会话模式,比如读取数据，没什么时间限制；非默认会话模式…

0x3E: 用于向服务器指示诊断仪仍然连接在网络上

0x22: 数据标识符DID(Data Identifier)，2字节参数，由制造商自己约定

0x2E:用于写入参数

0x19: 读取故障码服务，有很多子功能

DTC的全称是Diagnostic Trouble Code（诊断故障码），它是一种用于指示车辆发生故障或异常情况的标准化代码。当车辆的电子控制单元（ECU）检测到故障或问题时，会生成一个特定的DTC，以帮助车辆技术人员定位和修复问题。 DTC通常由一串数字或数字和字母组成，每个DTC对应一个特定的故障或问题。

ISO27145: 全球调和车载诊断系统/ 全球统一的重型发动机的车载诊断服务 WWH-OBD

AUTOSAR

AutoSar CP培训

Classic Platform AUTOSAR

1 序章与目录 20240610

软硬件工具：开发板，示波器，CAN卡…

软件：VS Code， CANOE…

MCU的基本结构

网络通信协议

C语言

2 AutoSar简介

标准分层
应用软件 ASW
运行时环境 RTE
基础服务层 BSWCommunication Services，IO Drivers, Memory Services…
微控制器抽象层 MCALMicrocontroller

根据ECU配置描述文件的配置生成代码，链接起来形成可执行文件

3 准备与认识软件工具

介绍了ISOLAR : 一家德国公司开发的Autosar配置IDE, 与Eclipse类似

可以完全从0构建一个AutoSar项目：由.c，.h，arxml等文件组成

4 从一个VCU需求开始AutoSar的工程

VCU在汽车领域中通常代表的是"Vehicle Control Unit"，即车辆控制单元。

SYS => BSW => ASW => RTE => MCAL => OS => intergration => 编译链接调试观测

工具：ISOLAR A/B,EB Tresos,RTAOS,S32DS，GHS,Trace32,CANOE

5 AutoSar如何描述一个系统

Software：System info，Signals And Signal Groups, Pdus, Frames, Ecus, Networks

用ISOLAR 先建立系统描述，是BSW的骨架

6 零起点的BSW配置

自动配置后，还需要大量的手动配置

7 从CAN网络学习Autosar通信 20240612

缩略词英文名称中文全称功能
CanCantroller Area Network Driver控制器局域网驱动CAN控制器驱动
CanIfCAN InterfaceCAN接口BSW与CAN驱动的接口，对CAN控制器的功能进行标准化与抽象后的模块
PduProtocol Data Unit协议数据单元用于各模块间数据交互的数据单元
I-PDUInteration Layer Protocol Data Unit交互层协议数据单元用于信号交互层的Pdu
PduRPDU RouterPDU路由器BSW中提供路由I-PDU的服务模块
COMCommunication通信栈BSW用于网络通信协议栈的模块

CAN => Communication Drivers: CAN Driver => Communication Hardware Abstraction: CAN interface => Communication Services: PDU Router => Autosar COM

=>以上是到BSW层为止，再上面是RTE

=>感觉每个ECU都有一个Autosar构架，相当于独立的一台服务器，所以ECU之间的CAN通信可以看成两台服务器间的通信

PDU Router是快递员

CAN Driver 触发一个中断

IDE：BSW Editor => 需要对各个模块层次都要配置(比如Com，PDUR，CanIf模块), 信号收发，数据大端小端等等

9 以太网通信

缩略词英文全称中文全称功能
ETHEthernet以太网通信或MCAL层以太网控制器
ETHIFEthernet InterfaceBSW与ETH驱动的接口，对ETH控制器的功能进行标准化与抽象后的模块
TCPIPTCPIP ModuleBSW层中实现TCP/IP协议的模块
SOADDoccket Adapter套接字转换BSW层中将以太网通信两点间的以太网报文转换为AutoSar IPDU的模块

PHY决定了以太网物理层的各种标准，比如双绞线，双工半工…

Autosar的以太网上面的协议：

IP : UDP : UDP-NM，DoIP, SOME/IP, Service Discovery, DHCP

IP : TCP: DoIP, SOME/IP

IP: ICMP

ARP

与CAN的应用层IPDU直接传到Layer2相较，车载以太网就有网络层，所以有IPDU经Socket转换的中间步骤。

IDE配置UDP接收报文：先配置COM，然后配置PDU，再配置SOAD，TCPIP模块，ETHIF，ETH Controller

=>从上往下逐次配置

10 网络管理

缩略词英文全称中文全称功能
NmNetwork Management负责ECU网络管理服务
CanNmCAN Network Management基于CAN通信进行的网络管理
CanSMCAN State Management处理CAN网络的启动和停止
ComMCommunication Management封装了对底层通信服务的控制

网络管理报文：应用层，对于CAN来说就是应用层直接到链路层

12 ECU的启动与休眠

Autosar框架下的EcuM模块： Ecu State Management

EcuM状态机：StartUp，RUN/UP, Sleep, ShutDown

MCU启动引导 => _START至Main函数 => 驱动初始化 => OS启动 => 服务初始化 => APP RUN => PreShutdown => Shutdown Target => OFF

=>应该是传说中的入口函数了，上述也是在IDE中进行配置

=>ISOLAR 好像不直接生成代码，而是生成arxml,dbc等配置文件,生成具体代码还要配合其他工具比如EB Tresos(可以以插件的形式集成到ISOLAR A/B中)

15 基于CAN的UDS诊断服务

缩略词英文名称中文名称功能
DCMDiagnostic Communication ManagerBSW层负责接收并响应诊断仪数据请求的模块
DEMDiagnostic Event ManagerBSW层用于处理诊断事件的信息和相关的数据的模块
CANTPCAN TransportationBSW层中实现标准CAN传输层协议的模块
SID
DTC
DID

AutoSar框架下的诊断流程

DIAG中DCM与DEM相互配合 => COM:PDUR => CAN: CANTP => CAN: CANIF => MCAL:CANDRV

DCM配置一定要对UDS充分了解后才能得心应手，需要配置各种SID,DID与之对应的函数等，其中的函数有可能需要后续手写。配置需要参照ECU具体诊断的需求

DEM实现了ODB，UDS等各种诊断事件，DTC的严重程度, 是最为复杂的模块

17 UDS ON IP 20240613

UDS在以太网上的实现，数据传输上速率会有提升

用CANOE来模拟

DCM/DEM => PDUR => DOIP => SOAD => TCPIP => ETHIF => ETHDRV

18 BSW配置

BSWM：Autosar BSW层中负责管理各模块状态协调管理与动作执行的模式管理中心，BSWM汇聚来自应用层与BSW层的模式信息，触发预定动作的执行，实现对软件的中心调度

动作执行的方式：

通过BSW层或ASW层服务函数

通过回调函数

Autosar BSW的工作配置结果

CAN通信LIN通信ETH通信网络管理ECU存储栈XCPUDS模式管理
CANLINETHNMECUMNVMXCPDCMBSWM
CANIFLINIFETHIFCANNMMEMIFDEMCOMM
PDURPDURTCPIPLINNMCANTPCANSM
COMCOMSOADCOMMDOIPETHM
PDURECUM
COMDCM

为配合以上模块的工作，工程还需要添加Autosar BSW层的其他模块(辅助模块)，比如CRC校验库

20 ASW配置

ASW要素：

  1. 数据类型
  2. 接口类型
  3. Software Components => SWC
  4. SWC的链接 => CPT

ASW层所有arxml组合起来描述了一个系统构架 =>基本设计的感觉

定义数据类型，定义计算方式，定义接口，定义infra，定义SWC原型，定义Compositions

与RTE进行数据交互

定义SWC原型：模块级工作内容

=>定义C语言的数据类型

=>Components好像是跟BSW一一对应的

22 OS与MCAL配置

OS: 系统复杂性任务调度与切换频繁 =>需要一个可配置的计算和存储资源管理角色

Autosar OS的历史：None OS => OSEK OS => Autosar OS

设计一个最小的Autosar OS

启动流程(单核)：加电启动=>C环境初始化=>时钟初始化=>中断向量表重定向=> OS启动

配置OS有专门的工具 RTA-OS的插件

MCAL:六大类驱动

  1. 微控制器驱动
  2. 存储设备驱动
  3. 加密设备驱动
  4. 无线通信设备驱动
  5. 通信设备驱动
  6. 输入输出驱动

Importer:Arxml文件导入来自于上层的需求

User Config: 根据功能需求添加

25 配置总结

系统定义：

  1. 系统定义arxml文件
  2. ECU相关arxml
  3. 通信网络arxml
  4. PDU描述相关arxml
  5. 诊断相关arxm
  6. DBC,LDF,ODX,CDD等文件

BSW设计：

  1. 各模块定义arxml文件
  2. 各模块动态代码.c.h
  3. 各模块静态代码.c.h
  4. 各模块集成代码.c.h

ASW设计：

  1. SWC定义arxml，包含数据，IF等
  2. 各SWC的C代码.c.h

RTE设计：

  1. RTE定义arxml
  2. SCHM代码.c.h
  3. RTE代码.c.h

OS设计：

  1. OS定义arxml文件
  2. OS代码.c.h.a
  3. ORTI文件

MCAL设计：

  1. 各MCAL模块定义XDM文件以及导出的arxml文件
  2. 各MCAL模块配置代码.c.h
  3. 各模块静态代码.c.h

启动引导文件：

  1. .s启动文件
  2. 系统初始化代码
  3. C环境初始化代码

编译与链接：

  1. 链接脚本文件

CANalyzer

CANoe/CANalyzer基础教程合集

LINK

新建工程 20240617

CANalyzer: CAN Analyzer

软件组成：

Database Tools: *.dbc(CANdb++ Editor), *.arxml(AutoSar Exploror)…

Panel Designer

CAPL Browser: *.can =>重要部分，做脚本编程，类c语言

Others like System Variable

功能组成:

Analysis Windows: Trace Window, Graphics Window, Data Window

Funtion Blocks: Event Filter Block, Channel Filter Block, Trigger Block, Programming Block

Data Logging: *.asc, *blf

Others like IG, Format Conversion

CANalyzer是Vector的第一款工具，CANoe是更新一代的工具，功能覆盖了CANalyzer

(大厂因为有自研的工具提供其他功能，所以反而是用功能更为少的CANalyzer)

=>CANoe可以看成是升级版的CANalyzer, 两者的GUI布局基本一样

CANoe是一个更为综合和全面的工具，不仅支持CANalyzer的网络分析和诊断功能，还包括了ECU功能开发、仿真、系统集成测试、通信协议测试等多种功能。CANoe适用于整车电子系统的开发、验证和测试，具有广泛的应用领域和功能覆盖

CANalyzer专注于网络分析和诊断工具，主要用于对CAN、LIN、FlexRay等通信网络进行详细分析、故障诊断、数据捕获和实时监测。它在深入分析和通信网络故障排查方面具有强大的能力，是工程师进行通信协议测试和问题排查的首选工具。

CANoe: CAN Open Environment

CANoe可以保存配置文件为cfg文件

用CANoe与实际的ECU进行硬件匹配，此时就可以接收ECU发过来的CAN信号了。也可以添加Database(dbc文件)，模拟ECU硬件.

=>CANalyzer就没有这个仿真功能

CANoe可以在使用仿真ECU的同时，也连接实际的ECU，从而在一个系统集成测试中同时涵盖虚拟和实际的硬件设备，以更全面地评估整个系统的性能和互操作性。

分析窗口

Trace Window ： 分析CAN报文信息

Graphic Window ： 分析信号和变量为主

State Tracker Window: 观察变量随时间的变化

Filter Function Blocks : 想起来了，各个大的灰色方块ECU之间有 蓝色小方块， 右击可以添加过滤器！你可以insert CAPL脚本来实现过滤功能。可以从同一个ECU分叉处多条分支，设置不同的过滤条件。

Logging Block: 设置什么时间点开始记录log，数据以何种格式保存,比如*.blf

Offline Mode: 可以载入 *.blf 文件进行回放

Import and Export: 强烈推荐blf格式， 比asc小

发送模块

CAN IG: insert CAN Interactive Generator, 就能添加一个IG模块到仿真窗口，可以配置CAN报文并发送，也可以发送数据库中的报文

Visual Sequence: 用于一系列报文重复发送，比IG灵活，又比CAPL简单

可以通过Simbol Panel手动改变一些变量信号的值，比如引擎转速

CAPL语言 20240618

CAPL是一种类似C的语言，文件尾缀为can

Simulation Setup

Measurement Setup ： 右击蓝色小方块，配置CAPL文件，用于数据过滤数据分析

Edit CAPL Program in CAPL browser

CAPL带有自带的CAN通信相关的函数，可以直接调用

CAPL features:

CAPL -> Communication Access Programming Language

A language similar to C

CAPL Browser as integrated development enviromment

CAN database and system can be accessed easily

Event driven =>不是顺序执行，就像API遇到某一条件时候执行某一部分代码

// CAPL示例程序1：简单的CAN消息发送

// 定义一个定时器，用于定时发送CAN消息
variables
{
  msTimer timer; // 定义一个毫秒级的定时器
}

// 系统初始化函数
on start
{
  // 设置定时器，每100毫秒触发一次
  setTimer(timer, 100);
}

// 定时器事件处理函数
on timer timer
{
  message canMsg; // 定义一个CAN消息变量

  // 设置CAN消息的ID和数据
  canMsg.id = 0x123; // CAN消息的标识符
  canMsg.dlc = 8;    // CAN消息的数据长度
  canMsg.byte(0) = 0xAA; // 数据字节1
  canMsg.byte(1) = 0xBB; // 数据字节2
  canMsg.byte(2) = 0xCC; // 数据字节3
  canMsg.byte(3) = 0xDD; // 数据字节4
  canMsg.byte(4) = 0xEE; // 数据字节5
  canMsg.byte(5) = 0xFF; // 数据字节6
  canMsg.byte(6) = 0x11; // 数据字节7
  canMsg.byte(7) = 0x22; // 数据字节8

  // 发送CAN消息
  output(canMsg);

  // 重新设置定时器，继续定时发送CAN消息
  setTimer(timer, 100);
}


// CAPL示例程序2：捕捉并处理接收到的CAN消息

// 定义一个CAN消息变量，用于存储接收到的消息
message receivedMsg;

// 系统初始化函数
on start
{
  // 订阅所有CAN消息
  subscribe * to *;
}

// CAN消息接收事件处理函数
on message *
{
  // 将接收到的CAN消息存储到变量receivedMsg中
  receivedMsg = this;

  // 打印接收到的CAN消息的ID和数据
  write("Received CAN message:");
  write("ID: 0x%X", receivedMsg.id); // 打印消息ID
  write("Data: %X %X %X %X %X %X %X %X", receivedMsg.byte(0), receivedMsg.byte(1), receivedMsg.byte(2), receivedMsg.byte(3),
                                        receivedMsg.byte(4), receivedMsg.byte(5), receivedMsg.byte(6), receivedMsg.byte(7));
}
watershed1993
关注
  • 4
    点赞
  • 踩
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
车载网络诊断测试攻略-专栏介绍
天赐好车的博客
01-28 371
本专栏通过建立标准和平台的思路去解决车载网络诊断这项测试内容。订阅此专栏的想看其他专栏的内容可以私信联系。
车载诊断新驱动——远程诊断
Soly_kun的博客
12-05 979
本文主要分享远程诊断的作用、解决方案、现状和趋势。
车载诊断协议栈简介
qq_37315601的博客
07-26 2045
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档 目录 前言 一、什么是诊断？ 二、什么是诊断协议栈？ 1.诊断协议 1.1 OBD II 1.2 UDS 1.3 J1939 2.诊断服务 3.故障码 4.诊断事件 5.DID 6.快照 三、诊断开发工具链 四、Autosar诊断模块 1.DCM(Diagnostoc Communication Manager) 2. DEM(Diagnostic Event Manager) 3. FIM(F...
汽车车载诊断基础知识
InfluxDataLogger的博客
04-25 2497
汽车都变得如同好莱坞奇幻电影"变形金刚 "中的汽车人一样，以我们可以明白的方式说话和行动，这似乎非常令人激动，但又非常的不真实。毫无疑问，我们这颗星球上的技术在以更快的速度运行，但会说话的汽车似乎仍然很遥远。然而我们技术的进步已经使我们能够更好地理解我们的车辆，虽然他们可能不会用我们的语言与我们交谈，但是汽车 "诊断系统 "并不亚于我们的语言，它可以帮助我们正确认识车辆的状况，比如 "OBD 车内诊断系统 "可以通过显示各种代码来诊断车辆和报告其状况。 车辆诊断有在线诊断（On-board）和离线诊断
3.车载网络诊断测试用例标准与示例（车载网络诊断测试平台）
天赐好车的博客
04-21 454
车载网络诊断测试用例标准与示例（车载网络诊断测试平台）
车载系统软件工程师如何处理车载系统的故障检测和诊断
最新发布
zhangzhechun的专栏
07-26 10
通过上述扩展示例，展示了一个基础的车载系统故障检测和诊断的实现。实际的车载系统会更加复杂，需要处理更多种类的故障、更加精细的故障检测算法、以及更复杂的ECU通信和协作。但这个例子展示了车载系统故障检测和诊断的基本流程和原理。在实际开发中，工程师需要使用专门的硬件和软件工具，如CANalyzer、Vector等，用于ECU开发、调试和验证。同时，确保系统的安全性和可靠性，是车载系统开发中至关重要的部分。阿里巴巴研究院开源的代码库有哪些github的检索功能BNF 语法描述c#的Cloo 库介绍。
车载诊断数据库ODX——初步了解ODX
Soly_kun的博客
12-17 1970
基于自身八年车载诊断经验（德企、互联网大厂造车、供应商、主机厂），对车载诊断数据库ODX类型，做一个详细描述（该专栏系列会包含）： ODX ISO规范定义； ODX具体组成部分； ODX企业规范定义什么内容； ODX常见解决方案等
车载基础软件——AUTOSAR CP
Soly_kun的博客
02-04 1662
V 模型是目前汽车电子软件开发过程中采用的主流开发模式，V 模型左侧统称为设计阶段，主要涵盖业务需求分析（Requirement Analysis）、系统设计（System Design）、架构设计（Architectural Design）、模块设计（Module Design）和编码（Coding）五个阶段。V 模型右侧统称为测试阶段，涵盖单元测试（Unit Testing）、集成测试（Integration Testing）、系统测试（System Testing）和验收测试（Acceptance T
车载软件架构-车载诊断软件框架
07-13
总之，车载软件架构中的诊断框架技术是确保功能安全的重要手段，它通过严谨的设计和管理，确保在故障发生时能够及时响应，避免潜在的危害，保障车辆的安全行驶。随着汽车电子技术的发展，车载诊断软件框架的复杂性和...
车载以太网诊断ISO13400_1-5部分
01-25
ISO13400的第一部分介绍了车载以太网诊断的基本原则和通用要求。它规定了诊断系统的设计、实现和验证的一系列准则，包括诊断服务、诊断会话管理和数据传输的标准化。这部分还涉及到错误处理机制，确保在出现故障时...
车载诊断培训-诊断框架和基本概念 2024.03.09.pdf
03-30
在这一背景下，车载诊断技术作为确保车辆安全运行的关键组成部分，其重要性日益凸显。 #### 二、车载诊断功能概述 车载诊断不仅仅局限于传统意义上的故障检测和维修，它还涵盖了车辆的各种功能模块，包括但不限于...
车载诊断标准ISO_15765(中文).zip
07-13
ISO 15765系列标准是汽车诊断通信的重要规范，尤其在UDS（统一诊断服务）框架下，它定义了车载网络系统与外部设备之间的数据交换格式和通信协议。这些标准对于理解和实现车辆的故障检测、维修以及性能监控至关重要。...
车载电子电器架构 - 国产基础软件生态简介
10-14
4. **操作系统**：操作系统是车载软件的核心，包括实时操作系统（RTOS）和基于POSIX接口的操作系统，如AUTOSAR OS和Linux，它们为不同层次的应用提供运行环境。 5. **信息安全**：随着汽车联网程度加深，信息安全...
vite5+vue3开发阅读APP实战笔记20240725
Python私教
07-25 495
修改src/page/home/index.vue，使用组件和API。注意，这里无论是组件还是API，都不需要我们手动引入，我们配置了自动导入以后，vite会帮我们自动导入。创建 src/page/home/index.vue。修改 vite.config.js。修改vite.config.js。修改 src/main.js。修改src/App.vue。
Golang学习笔记20240725，Go语言基础语法
Python私教
07-25 604
如果我们在遍历的时候，不想要key或者value，也可以用下划线替代，下划线叫做匿名变量。go语言里面的switch语句每个case天生就是独立的，不需要加break。指针可以直接对内存地址进行操作。使用*表示指针，使用&取地址。切片在go语言里面非常常用，因为其有动态扩展的特性。运行方式3：goland右键运行。使用加号可以对字符串进行拼接。
学习笔记-系统框图传递函数公式推导
weixin_45875994的博客
07-24 910
输出C(s)是前向路径（通过G(s)）的输出与反馈路径（通过H(s)）的输出之差（在负反馈系统中）。因此，我们可以写出以下关系式：这里，G(s)R(s)是前向路径的输出，而G(s)H(s)C(s)是反馈路径的输出（注意，反馈路径的输出先经过H(s)，再与前向路径的输出相减）。
Spring Security学习笔记（二）Spring Security认证和鉴权
飞！！！的博客
07-24 762
用户认证的基础Filter，只有UsernamePasswordAuthenticationFilter这一个实现类。...//主要方法//先校验请求url与表单校验提交的url是否一致，不一致执行下一个Filter//一致的话就执行认证逻辑，一般默认的表单提交url是"/login"if (!} else {try {//实现类执行具体的认证逻辑return;//由子类实现具体的验证逻辑...
SAP PP学习笔记31 - 计划运行的步骤2 - Scheduling(日程计算)，BOM Explosion(BOM展开）
shi_ly的专栏
07-24 832
本章主要讲Scheduling(日程计算),其中包括 外部调达中的调度，生产订单中的调度，修改需求日期(其实就是在物料中增加安全时间和BOM中的提前期偏置量)。另外还讲了BOM展开的内容，详细讲了BOM选择的各种方法，除了按数量选BOM之外，还有其他比如 按日期，按生产版本等，而其中按日期又分为按订单开始日期，订单终了日期等，越趋复杂。
基于ISO15765的车载CAN网络诊断软件设计
"这篇硕士论文主要探讨了基于ISO15765协议的车载CAN网络上位机诊断软件的设计，旨在理解和开发一个低成本、自主知识产权的诊断工具，以替代依赖国外高成本设备的情况。该研究以某具体车型的网络结构和诊断节点为对象...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值