什么是 CAN Bus?
CAN(Control Area Network)Bus 是一种串行通信协议,可能让设施之间牢靠而高效地传输数据。它广泛应用于车辆畛域,像神经系统一样连贯车辆外部的各个电子管制单元。
CAN Bus 最后由博世公司在 20 世纪 80 年代为汽车利用而设计。它是一种多主、多从、半双工、具备容错能力的协定,非常适合汽车畛域的需要。它简略、低成本、牢靠,可能在顽劣的环境中工作。CAN Bus 为车辆中所有电子管制单元提供了一个对立的接入点,不便进行连贯和诊断。
CAN Bus 数据可能反映连贯设施的性能和状态。然而,因为数据量大、带宽无限以及网络不稳固等因素,收集和解决 CAN Bus 数据可能面临一些挑战。
为了应答这些挑战,能够利用 MQTT 协定,确保在网络状况不佳的状况下及时将车辆数据传输到云端。EMQX 是一款开源的 MQTT Broker,可能搭建牢靠且可扩大的 MQTT 基础设施,用来收集 CAN Bus 数据。
CAN Bus 的倒退简史
CAN Bus 由德国跨国工程技术巨头博世在 20 世纪 80 年代初开发,旨在为汽车利用提供一种高效的通信零碎,次要目标是简化车辆外部线束的复杂程度。
1986 年,博世公布了首个 CAN 协定,因为其可靠性和健壮性,很快受到了汽车制造商的青眼。1993 年,它成为 ISO-11898 国际标准。该协定演进过程大抵如下:
- 1991 年:梅赛德斯 - 飞驰在其 W140 S 级车型中采纳了 CAN Bus,成为最早采纳 CAN Bus 的汽车制造商之一。
- 2004 年:推出了 CAN FD,相比传统 CAN 网络,提供了更高的数据速率和更大的有效载荷。
- 2015 年:应用 ISO-16845:2015 作为一致性测试的测试计划,用于对实现了经典 CAN 以及 CAN FD 协定的设施进行一致性测试。
除了汽车畛域外,CAN Bus 协定还逐步利用于其它行业,例如工业自动化零碎(CANopen)和船用电子设备(NMEA 2000)。它的广泛应用次要得益于它可能在顽劣的条件下稳固运行,并且施行老本较低。
CAN Bus 的工作原理
CAN Bus 是一种分布式的通信协议。它的分布式特点使它非常适合对可靠性和实时性有较高要求的利用,如汽车和工业零碎。
在 CAN 网络中,所有的节点都通过双绞线或光纤相连。每个节点都有本人的微控制器,负责解决收到的音讯和发送的音讯。数据由节点在共享总线上播送,所有其它节点都能收到。通信过程的几个要害阶段包含:
- 仲裁:为了防止多个节点同时发送数据产生抵触,CAN 采纳了一种基于音讯优先级的仲裁过程。音讯的标识符值越小,优先级越高。
- 谬误检测:内置的谬误检测机制保障了 CAN 网络中数据的完整性。这些机制包含循环冗余校验(CRC)、帧校验序列(FCS)以及接管节点确认位。
- 故障界定:如果节点在传输过程中检测到谬误或故障,它会进入“被动谬误”状态,直到问题解决。这种机制能够避免故障对整个零碎性能造成烦扰。
这些个性相互配合,使得 CAN Bus 可能高效运行,确保车辆或工厂自动化设施等简单零碎中各个组件之间的牢靠通信。
CAN 协定的音讯构造
在 CAN Bus 零碎中,音讯构造对于设施间的高效通信十分重要。该协定的数据帧格局由以下几个字段组成:标识符、管制字段、数据字段和谬误检测机制。
- 标识符 (CAN ID):这是一个惟一的值,用于确定网络上每条音讯的优先级。规范的 11 位标识符(CAN 2.0A)提供了多达 2048 种不同的优先级。扩大的 29 位标识符(CAN 2.0B)提供了更多的抉择,有超过五亿个优先级。
- 数据长度码(DLC):位于管制字段中,用于指定数据字段所蕴含的字节数,取值范畴 0 – 8 个字节。
- 数据字段:蕴含了理论要在节点间传输的信息,以字节为单位。
- 循环冗余校验(CRC):一种内置的谬误检测机制,通过检测传输谬误并在必要时申请重传来保障通信的可靠性。
- 确认槽:一个独自的位,用于接管节点向发送节点发送确认信息,示意胜利接管音讯或须要进行谬误重传。
- 谬误帧:CAN 音讯的一个可选局部,用于节点在检测到本人发送或者接管到的音讯有问题时发出信号。
CAN 的品种
CAN 次要包含三种类型:
低速 CAN
低速 CAN,也叫做容错 CAN 或 ISO 11898-3,最高传输速度为 125 kbps。它实用于像车身管制模块、门锁、窗户管制等不太重要的零碎,这些系统对数据传输速度的要求不高。它的次要特点是即便总线中的一根线断了,也能持续失常工作。
高速 CAN
高速 CAN,或 ISO 11898-2,传输速度最高可达 1 Mbps。因为它比低速网络有更快的数据传输速度,因而适宜须要及时响应的利用,如发动机管理系统和电子制动零碎。然而,它没有低速网络的容错能力。
CAN FD
CAN FD 由博世在 2012 年推出,是高速网络的扩大版,具备更高的数据传输速度,最高可达 5 Mbps,同时向后兼容现有高速设施。这项技术的次要劣势在于它比传统的 CAN 能更无效地传输更大的载荷,使其非常适合古代车辆日益简单的电子系统。
CAN Bus 的劣势和挑战
CAN Bus 有哪些次要劣势?
CAN Bus 数据能够反映车辆的性能、健康状况和行为特色。把 CAN Bus 数据收集到云端是一种利用车辆数据后劲的无效办法,能够通过大数据分析来发现数据价值。通过将机器学习、人工智能或其它剖析工具利用于从车辆收集的大量数据,车辆制造商能够取得有价值的信息,并利用它们优化车辆性能。
- 检测、打消、预测故障:通过剖析 CAN Bus 数据,能够辨认设施和传感器收回的异样或谬误信号。这有助于诊断问题的根本原因,并在它导致更大损失或带来平安问题之前修复它。制造商还能够利用收集的数据来训练机器学习模型,从而实现故障的预测。
- 可视化车辆数据:用户能够利用收集的数据构建一个零碎,将综合数据展现在仪表板上,实现对不同车辆和指标的过滤、排序和比拟。该仪表板还能基于数据分析提供警报和倡议,帮忙用户全面理解性能状况。
- 车路协同:将收集的数据与路线基础设施数据联合,能够建设车路协同零碎。
在人工智能时代,数据是最有价值的资产。通过将车辆的数据收集到云端,而后将其散发到各种数据基础设施,如数据库和数据湖,用户能够利用数据实现各种类型的利用。
实时数据收集面临哪些挑战?
只管在车辆本地收集 CAN Bus 数据曾经相当成熟,但因为高数据速率、低带宽和不稳固的网络环境,导致收集、解决和实时传输 CAN Bus 数据到云端面临着微小的挑战。将所有 CAN Bus 数据都传输到云端进行解决是不切实际的。所以,能够在边缘端本地收集和解决 CAN Bus 数据,以缩小数据量,而后将处理结果实时传输到云端。
咱们至多须要两个组件来构建这样的解决方案:
- 边缘计算引擎:边缘计算引擎能够只收集所需的 CAN Bus 信号,灵便地解决它们,并实时触发 MQTT 传输动作。LF Edge eKuiper 是一款开源的边缘计算引擎,能够帮忙您实时处理和剖析 CAN Bus 数据。
- 云端的 MQTT Broker:利用 MQTT Broker,能够实现将解决过的 CAN Bus 数据实时传输到云端。EMQX 是一款开源的 MQTT Broker,可能搭建牢靠且可扩大的 MQTT 基础设施,用来收集 CAN Bus 数据。
接下来,咱们将具体介绍联合 EMQX 和 eKuiper 的整体解决方案。
解决 CAN Bus 数据本地解决挑战
eKuiper 是一款开源的边缘计算引擎,能够帮忙您实时处理和剖析 CAN Bus 数据。eKuiper 是为边缘流解决而设计的,适宜对 CAN Bus 产生的典型流数据进行实时处理。eKuiper 能够应答以下挑战:
- 具备高效实时处理 CAN Bus 大容量、高速度数据的能力。可能灵便过滤、解决和抉择感兴趣的信号,从而升高传输数据所需的带宽。
- 可能将二进制的 CAN 帧解析为有意义的信号,以进行规定解决和触发动作。它反对动静加载 DBC 文件,使用户可能灵便地更改 DBC 文件,无需重启引擎即可适配不同的 CAN Bus 设施。同时,它还确保 DBC 文件的私密性和安全性,无需裸露给开发团队。
- 可能灵便地组合来自不同 CAN 帧的信号,能够通过规定构建残缺的音讯供应用程序应用。用户还能够自在地批改规定,以适应不同的用户场景或需要变动,并反对热加载。
教程:应用 eKuiper 实现 CAN Bus 数据本地解决
第 1 步:连贯到 CAN Bus
eKuiper 应用 CAN 源插件来连贯 CAN Bus 并接管 CAN 帧。它反对两种连贯 CAN Bus 的模式,如下图所示。
- 通过 socketCan 间接连贯到 CAN Bus。SocketCAN 应用 Berkeley socket API、Linux 网络协议栈,并将 CAN 设施驱动程序实现为网络接口。一旦将 CAN Bus 连贯到 Linux 零碎,用户就能够取得 CAN 网络接口。在 eKuiper 中,用户能够通过指定 CAN 网络接口 和 DBC 文件门路 来创立 CAN 流。而后,能够对 CAN 流利用任何规定来解决 CAN Bus 数据。
- 利用 TCP/UDP 通过网关连贯到 CAN Bus。网关能够是一个 CAN 适配器,它将多个 CAN 帧组合成一个数据包,并通过 TCP 或 UDP 批量发送进来。留神,网关发送的数据包格局没有标准化,因而可能须要批改插件来适应它。在 eKuiper 中,用户能够通过指定 TCP/UDP 地址 和 DBC 文件门路 来创立 CAN 流。而后,能够对 CAN 流利用任何规定来解决 CAN Bus 数据。
第 2 步:解码 CAN Bus 数据
CAN Bus 数据是二进制数据并且以帧为单位,CAN 帧由多个字段组成。CAN 协定有多个版本,包含 CAN 2.0A、CAN 2.0B 和 CAN FD。不同版本的 CAN 帧格局略有不同。下图显示了 CAN 2.0A 的帧格局。
其中,有两个字段对解码 CAN Bus 数据很重要:
- ID 字段:ID 字段用于标识 CAN 帧。CAN 2.0A 的 ID 字段是 11 位,CAN 2.0B 和 CANFD 是 29 位。
- 数据字段:数据字段是有效载荷,用于携带理论数据。CAN 2.0A 和 CAN 2.0B 是 0-8 字节,CAN FD 是 0-64 字节。
在有效载荷中,数据由一系列的信号组成,每个信号都有本人的名称、长度和地位。DBC 文件是一个文本文件,其中蕴含将原始 CAN Bus 数据解码为“物理值”的相干信息。该文件定义了信号的名称、长度、地位以及将原始数据转换为物理值所应用的转换公式。
在 eKuiper 中,用户能够在解析 CAN Bus 数据时指定要应用的 DBC 文件门路。在 eKuiper 中配置 DBC 非常灵活和平安。
- 多个 DBC 文件:用户能够抉择一个目录作为 DBC 门路,目录中的 DBC 文件将按字母程序一一加载并失效。这种形式能够让用户通过独自的 DBC 文件来增量增加或还原信号。
- 动静 DBC 文件加载:DBC 文件在运行时加载,无需在开发时部署。这能够帮忙用户放弃 DBC 文件的私密性和安全性。
- 热加载:用户无需重新启动引擎即可随时更改 DBC 文件,以适应不同的 CAN Bus 设施。
配置完 eKuiper CAN 源后,用户能够创立一个流来接管并解析 CAN Bus 数据,从中提取有意义的物理信号。例如,CAN 有效载荷 0x0000000000000000
能够解析为以下信号:
{
"signal1": 0,
"signal2": 0,
"signal3": 0,
"signal4": 0,
"signal5": 0,
"signal6": 0,
"signal7": 0,
"signal8": 0
}
接下来,用户能够像从 MQTT 接收数据一样,利用 eKuiper 弱小的流解决能力,对解析后的数据进行灵活处理。
第 3 步:解决 CAN Bus 数据
在失去解析过的数据后,咱们能够利用 eKuiper 对它进行各种操作。为了节俭传输数据的带宽,咱们能够只筛选感兴趣的信号。比方,能够仅抉择 signal1
和 signal2
这两个信号。
{
"signal1": 0,
"signal2": 0
}
用 eKuiper SQL 语句能够很容易实现这一点:
SELECT signal1, signal2 FROM canStream
因为 CAN 帧的大小无限,咱们可能须要从多个 CAN 帧中提取所需的信号。因而,咱们能够依据须要应用算法灵便地组合不同 CAN 帧中的信号,以构建残缺的音讯供应用程序应用。您能够在数据合并的示例中理解更多详细信息。这里,咱们用 signal1 作为次要条件来筛选数据。
SELECT signal1, latest(signal2) as signal2 FROM canStream WHERE isNull(signal1) = false
另一个示例是只在特定事件产生时才收集数据,这样能够显著缩小带宽的耗费。举个例子,咱们能够只在 signal1 超过 100 时才进行数据收集。
SELECT signal1, signal2 FROM canStream WHERE signal1 > 100
此外,这些解决规定非常灵活,能够随时进行批改。即便在最后阶段没有确定所需的信号,也无需放心,您能够依据需要的变动随时调整规定,并实现热加载。
除了数据采集这一常见用处,eKuiper 还能够利用于其它场景,例如:
- 车载端实时灵便的规定引擎:能够依据特定条件触发相应动作。比方,当车速超过 70 英里 / 小时时,主动敞开车窗。
- 灵便的智能剖析:能够在零编码或不连贯云端的状况下,对数据和 AI 模型(目前是 TF Lite)进行组合。这个性能能够实现实时数据分析,比方依据速度、轮胎压力等数据预测和倡议驾驶模式(即便没有网络连接)。
- 边缘计算:能够缩小传输带宽,升高云端计算压力,还能解析、重组和转换数据,比方计算一段时间内的平均速度并保留。
- 异构数据整合:能够解析来自不同协定(TCP、UDP、HTTP、MQTT)和不同格局(CAN、JSON、CSV 等)的数据,并通过灵便的规定进行合并。
- 音讯路由:能够决定哪些数据发送到云端,哪些数据保留在本地供其它车载利用应用。比方,依据 GDPR 或某些白名单来确定路由。
利用 MQTT 采集 CAN Bus 数据
应用 EMQX 这类 MQTT Broker 收集 CAN Bus 数据有以下几个劣势:
- 升高网络开销:MQTT 采纳二进制格局和极简的头部对音讯进行编码,能够节俭网络带宽,晋升数据传输效率。
- 晋升扩展性:单个 MQTT Broker 可能反对上千个并发连贯和每秒上百万条音讯。这使得能够从多个 CAN Bus 设施进行大规模数据收集,而不会影响性能或可靠性。
- 加强安全性:MQTT 反对多种平安机制,比方 TLS/SSL 加密、用户名 / 明码认证、访问控制列表(ACL),以避免未经受权的数据拜访或篡改。
- 改善互操作性:MQTT 基于凋谢规范,被各种平台和语言广泛支持。这有利于将 CAN Bus 数据与其它零碎或利用进行集成。
除此之外,EMQX 还提供了许多其它性能,并可能与 eKuiper 协同工作,从而帮忙用户在传输 CAN Bus 数据时节俭带宽、缩小提早、进步可靠性。
节俭带宽
在通过 MQTT 传输 CAN Bus 数据时,咱们通常须要在带宽受限的弱网络环境下进行传输。因而,咱们须要尽量减小数据的大小。
在 eKuiper sink 中,咱们能够应用 format
选项来指定数据格式。默认格局是 JSON
。咱们能够将其改为 protobuf
,将数据序列化为二进制格局,以显著缩小数据大小。另外,咱们能够应用 compress
选项来通过 gzip
或其它压缩办法来压缩数据。通过这些形式咱们能够让数据的大小比原来的 JSON 数据小很多。在咱们的一个测试用例中,在批量发送数据时数据的大小能够缩小 90% 以上。
实时数据
对于云端利用而言,某些数据具备工夫敏感性,例如用于车辆事变诊断的数据。在这种状况下,升高提早十分重要。在 eKuiper 规定中,咱们能够用 MQTT sink 把数据疾速发送到 EMQX,以满足高效的数据传输需要。
为了在实时场景中节俭带宽,咱们能够像前文介绍的那样,在 eKuiper MQTT sink 中设置序列化格局和压缩办法。EMQX 提供了规定引擎,能够解压缩和反序列化数据,这样云端利用不必编写代码就能够实时地解决数据。
将数据批量存入文件
对于不急于解决的数据,咱们能够保留在文件或本地数据库里,而后批量发送到云端。这样能够达到更高的压缩比,进而节俭更多的带宽。在 eKuiper 规定中,咱们能够应用文件 sink 来本地保留和压缩数据。文件 sink 反对设置文件滚动策略,例如每 10 分钟滚动一次,这样咱们能够将数据批量保留在文件中。EMQX 正在开发一个新性能,实现用 MQTT 传输文件。等这个性能实现后,保留的文件就能够用 MQTT 传输了。目前,用户能够用其它工具把文件传输到云端。
结语
本文介绍了如何利用 eKuiper 和 EMQX 从车辆收集、解决、传输 CAN Bus 数据到云端。在接下来的文章中,咱们将对每个步骤进行更具体地解说。
版权申明:本文为 EMQ 原创,转载请注明出处。
原文链接:https://www.emqx.com/zh/blog/can-bus-how-it-works-pros-and-cons