从 CAN 总线到 AWS IoT：EC312 边缘计算网关实现 CAN 数据云端接入

随着工业物联网（IIoT）、智能制造、智能交通和智能运维的发展，大量设备正在通过 CAN（Controller Area Network）总线进行数据通信。

从车辆 ECU、发动机控制器，到发电机组、工程机械、工业设备以及电池管理系统，CAN 总线已经成为现场设备之间传输数据的重要方式。

但对于很多物联网项目来说，"设备能够产生 CAN 数据"并不意味着"这些数据能够直接被云平台使用"。

CAN 数据通常停留在现场总线上，上层云应用无法直接获取。传统网关虽然可以完成简单的数据转发，但在实际项目中还会面临 CAN 数据解析、边缘计算、协议转换、4G 网络接入以及云端安全认证等问题。

本文基于 InHand EC312 Edge Computing Gateway，介绍一种完整的 CAN-to-AWS 数据采集与转发方案：由 EC312 在边缘侧读取 CAN 数据，通过 Python 应用完成数据解析和标准化，再利用内部 MQTT 消息总线与 Device Supervisor（DSA）进行数据解耦，最终通过 MQTT + X.509 双向认证安全地将数据发送至 AWS IoT Core。

一、为什么需要 CAN 到云端的数据通道？

在传统工业现场中，设备的数据链路通常可以简单理解为：

传感器 / ECU → CAN 总线 → 本地控制系统

而当企业希望进一步实现云端数据分析、设备监控和远程运维时，链路就需要扩展为：

现场设备 → CAN → 边缘网关 → 蜂窝网络 / Ethernet → 云平台 → 数据分析与应用

这中间最大的挑战并不是简单地"把 CAN 数据发到互联网"，而是如何让现场的原始 CAN Frame 转换成云端能够理解和使用的结构化数据。

例如，一个差压传感器可能通过 CAN ID：

0x18FF0155

广播压力和温度数据。

对于 CAN 总线而言，这只是一个数据帧；但对于云端应用来说，更有价值的是：

复制代码

pressure = 3.27 bar
temperature = xx °C

因此，边缘网关需要承担的不只是通信功能，还需要完成：

CAN 数据实时采集
CAN Frame 过滤
数据解析
物理量转换
数据结构化
数据过滤和冗余数据处理
MQTT 消息转发
云端安全连接

EC312 的设计正是围绕这一类边缘数据处理场景展开的。

二、EC312 CAN-to-AWS 整体方案

该方案可以划分为四个主要层级：

复制代码

┌─────────────────────────────────────────┐
│          Cloud / Application            │
│ AWS IoT Core → Rules Engine →           │
│ Timestream / S3 / Lambda / Dashboard    │
└───────────────────▲─────────────────────┘
                    │ MQTT over TLS
┌───────────────────┴─────────────────────┐
│                Edge Layer               │
│ EC312                                   │
│ Python App → Internal MQTT → DSA        │
│ Virtual Controller                     │
└───────────────────▲─────────────────────┘
                    │ 4G/LTE / Ethernet
┌───────────────────┴─────────────────────┐
│               Network Layer             │
│ 4G/LTE Primary + Ethernet Backup        │
└───────────────────▲─────────────────────┘
                    │
┌───────────────────┴─────────────────────┐
│             Perception Layer            │
│ CAN Sensor / ECU / Controller           │
│ CAN 2.0A / CAN 2.0B / J1939 / OBD-II   │
└─────────────────────────────────────────┘

从整体架构来看，EC312 位于现场设备和 AWS 云平台之间，承担边缘数据采集、协议解析、数据处理以及云连接等任务。

这种架构最大的特点是：

CAN 数据首先在边缘侧完成处理，再上传到云端，而不是将大量原始 CAN Frame 直接传输到云端。

这样可以降低蜂窝网络流量，同时减少云端的数据解析压力。

三、CAN 数据是如何进入 EC312 的？

在该方案中，EC312 使用自身的 CAN 接口接收现场数据。

以文档中的差压传感器为例，传感器通过 CAN 总线广播数据：

复制代码

CAN ID：0x18FF0155
Interface：can2
Protocol：CAN 2.0B

EC312 的 Linux 系统可以通过 SocketCAN 访问 CAN 接口。

数据进入网关后，Python 应用通过 python-can 对 CAN Frame 进行读取和过滤。

整个过程可以理解为：

复制代码

CAN Sensor
    │
    │ CAN 2.0B
    ▼
EC312 can2
    │
    ▼
Python Application
    │
    ├── Filter CAN ID
    ├── Decode payload
    ├── Convert physical values
    └── Generate structured data

这种方式的优势在于，客户可以根据自己的 CAN 协议定义编写 Python 数据解析逻辑，而不需要为每一种设备重新开发完整的网关固件。

文档中也明确指出，EC312 提供 Linux + Python 3 环境，并支持 python-can 和 paho-mqtt 等组件。

四、为什么要在边缘侧解析 CAN 数据？

如果直接将原始 CAN Frame 全部上传到 AWS，那么云端还需要承担协议解析工作。

对于车辆、工程机械、工业设备等大量现场设备而言，这种方式可能产生大量重复或无意义的数据。

因此，该方案将数据处理放到了 EC312 边缘侧。

例如：

复制代码

Raw CAN Frame
      │
      ▼
CAN ID Filtering
      │
      ▼
Payload Decoding
      │
      ▼
Physical Value Conversion
      │
      ▼
Structured JSON

边缘侧可以完成：

1. 数据过滤

根据 arbitration_id 过滤需要的数据。

2. 数据解析

从 CAN Payload 中提取实际测量值。

3. 物理量转换

将原始数据转换为压力、温度、RPM 等实际物理量。

4. 数据标准化

将数据转换为统一的 JSON 数据结构。

5. 数据优化

根据需求过滤噪声以及丢弃冗余数据。

文档将这一过程定义为 Edge Processing，即在边缘侧完成物理量解析、数据过滤以及冗余帧处理。

五、Python + MQTT + DSA：EC312 内部的数据处理链路

EC312 的另一个重要设计是采用解耦的数据架构。

数据并不是：

复制代码

Python → AWS

而是：

复制代码

Python Application
       │
       ▼
Internal MQTT Broker
       │
       ▼
DSA Virtual Controller
       │
       ▼
AWS IoT Connector
       │
       ▼
AWS IoT Core

EC312 内部提供 MQTT 消息总线，地址为：

复制代码

127.0.0.1:9105

Python 应用完成 CAN 数据解析后，将结构化数据发布到 Device Supervisor 的内部 MQTT Broker。

对应的数据主题为：

复制代码

ds2/eventbus/south/read/{driverServiceId}

随后，DSA 中的 Virtual Controller 接收数据，并将测量结果存储为 Tag。

例如：

复制代码

pressure

这样一来，CAN 数据采集和 AWS 云连接之间实现了松耦合。

这种设计非常适合工业物联网项目。

如果未来现场设备从 CAN 变成 Modbus、OPC UA 或其他协议，只需要替换或者增加对应的数据解析应用，而后面的 MQTT → DSA → AWS 数据链路仍然可以继续使用。

六、从 CAN 数据到 AWS IoT Core 的完整数据流

整个数据流程可以总结为以下七个步骤：

Step 1：CAN 设备发送数据

现场传感器或 ECU 在 CAN 总线上广播数据。

Step 2：EC312 接收 CAN Frame

EC312 的 can2 接口接收 CAN 数据。

Python 应用通过 SocketCAN 获取数据。

Step 3：Python 进行数据解析

Python 应用根据 CAN ID 对数据进行过滤，并解析 Payload。

例如将原始数据转换成：

复制代码

pressure = 3.27 bar

Step 4：发布到内部 MQTT

Python 应用将结构化数据发布到 EC312 内部 MQTT Broker。

Step 5：DSA Virtual Controller 接收

Virtual Controller 获取测量数据，并将数据保存为对应 Tag。

Step 6：DSA 连接 AWS IoT Core

DSA 的 AWS IoT north-bound 将 Tag 数据通过 MQTT over TLS 发送至 AWS IoT Core。

Step 7：AWS IoT Core 进入云端应用

AWS IoT Core 可以进一步通过 Rules Engine 将数据发送至：

Amazon Timestream
Amazon S3
AWS Lambda
Dashboard

最终形成完整的数据分析与可视化链路。

七、结构化数据让 CAN 数据真正具备云端价值

完成边缘解析之后，CAN 数据不再只是原始 Frame，而可以转换为结构化数据。

文档中的示例数据采用如下结构：

复制代码

{
  "controllers": [
    {
      "name": "con1",
      "version": "d3b0c5fc05cb72e7759c95f346e29f8d",
      "health": 1,
      "timestamp": 1747800000,
      "measures": [
        {
          "name": "pressure",
          "health": 1,
          "timestamp": 1747800000,
          "timestampMsec": 1747800000123,
          "value": 3.27
        }
      ]
    }
  ]
}

相比直接上传 CAN Frame，这种结构更加适合后续云端数据处理。

云端应用可以直接获取：

复制代码

Controller
    ↓
Measure
    ↓
pressure
    ↓
value = 3.27

从而减少云端再次解析底层 CAN 协议的工作。

八、4G/LTE 让 CAN 数据从移动设备进入云端

对于车辆、工程机械、发电机组以及其他移动设备而言，Ethernet 并不是始终可用。

因此，该方案将 4G/LTE 作为主要上行网络，Ethernet 可以作为备用或替代连接方式。

典型链路为：

复制代码

CAN
 ↓
EC312
 ↓
4G/LTE
 ↓
Internet
 ↓
AWS IoT Core

这种设计尤其适合：

商用车
工程机械
发电机组
户外设备
远程工业设备

对于关键业务场景，还可以根据设备型号使用 Dual SIM，实现运营商冗余。

文档中将 4G/LTE 定位为车辆、移动资产和远程站点的主要连接方式，Ethernet 则适用于固定安装环境或作为备用连接。

九、为什么选择 EC312 作为 CAN 边缘计算网关？

在 CAN-to-AWS 场景中，EC312 的核心价值并不只是提供 CAN 接口，而是将：

CAN + Linux + Python + MQTT + DSA + Cellular + Cloud

整合到了一个边缘计算设备中。

主要体现在以下几个方面。

1. Native CAN

EC312 提供原生 CAN 接口，可以通过 Linux SocketCAN 直接访问 CAN 数据，不需要额外增加 USB CAN 转换器。

2. Linux + Python

开放的 Linux 环境提供 Python 3 运行环境，可以根据客户自己的 CAN 协议开发数据解析程序。

3. DSA 数据处理框架

Device Supervisor 提供工业协议和云连接框架，可以连接 Modbus、OPC UA、MQTT、AWS IoT、Azure IoT 等。

4. 蜂窝网络连接

针对车辆和远程设备，可以使用 4G/LTE 建立云端连接。

5. 远程设备运维

通过 InHand Device Manager，可以对部署在现场的 EC312 进行远程配置、诊断和固件升级。

这些能力共同构成了从现场 CAN 数据到云端应用的完整边缘计算链路。

十、安全连接：CAN 数据进入 AWS 也需要可靠的身份认证

工业设备连接公有云时，安全性是不可忽视的问题。

该方案使用：

TLS 1.2 + X.509 Mutual Authentication

建立 EC312 与 AWS IoT Core 之间的安全通信。

也就是说，设备与 AWS IoT Core 之间并不是简单的 MQTT 明文连接，而是通过证书进行身份认证，并通过 TLS 加密传输数据。

此外，AWS IoT Policy 可以限制设备访问属于自己的 MQTT Topic。

在本地管理侧，EC312 也提供用户名和密码保护的 Web 管理界面。

对于大规模部署，还可以通过 InHand Device Manager 进行远程升级和审计。

十一、从单台设备到大规模设备管理

对于物联网项目来说，真正的挑战往往不是让"一台设备"上线，而是让：

100 台、1000 台甚至更多设备稳定运行。

因此，CAN-to-AWS 方案除了关注数据传输，还需要考虑设备生命周期管理。

EC312 可以通过 InHand Device Manager 实现：

复制代码

设备部署
   ↓
远程配置
   ↓
设备监控
   ↓
远程诊断
   ↓
固件升级
   ↓
批量运维

这样可以避免设备部署到车辆、户外机柜或者偏远现场后，还需要工程师逐台到现场维护。

这也是该方案从"数据采集网关"进一步走向"可规模化部署的边缘计算节点"的重要原因。

十二、CAN-to-AWS 可以应用在哪些场景？

这种架构并不局限于某一种 CAN 设备。

根据方案文档，它可以用于多个工业和物联网场景。

商用车与车队管理

车辆 ECU、发动机、变速箱、制动系统和燃油系统等数据可以通过 CAN/J1939/OBD-II 进入云端。

工程机械

挖掘机、装载机、起重机以及农业拖拉机等设备可以利用 CAN 数据进行远程设备监控。

发电机组

柴油发电机控制器可以通过 CAN/J1939 将设备运行数据上传至 AWS。

工业设备

CNC、压力机、压缩机、泵以及基于 CAN 的 PLC Drive 都可以纳入该架构。

EV 与电池系统

BMS 和充电设备可以通过 CAN 将运行状态和测量数据发送到云端。

船舶与轨道车辆

Marine 和 Rail rolling-stock telemetry 同样可以使用该数据链路。

传感器集成

差压、振动、温度等 CAN 传感器可以通过 EC312 完成数据采集和云端转发。

十三、一个完整的 CAN-to-AWS 数据链路意味着什么？

从整个方案来看，EC312 并不是简单意义上的"CAN 转 4G 网关"。

它实际上构建了一条完整的边缘数据链路：

复制代码

现场设备
   │
   │ CAN
   ▼
┌───────────────┐
│     EC312     │
│               │
│ CAN Interface │
│      ↓        │
│ Python Parser │
│      ↓        │
│ Internal MQTT │
│      ↓        │
│ DSA Controller│
└───────┬───────┘
        │
        │ MQTT + TLS
        ▼
┌────────────────┐
│ AWS IoT Core   │
└───────┬────────┘
        │
        ▼
 Rules Engine
        │
 ┌──────┼────────┐
 ▼      ▼        ▼
S3  Timestream Lambda
        │
        ▼
   Data Analytics
   & Visualization

在这条链路中，EC312 完成了一个关键角色的转变：

它不仅负责"连接"，更负责"理解数据"。

CAN 数据在设备侧产生，在 EC312 边缘侧完成解析和标准化，然后再进入 AWS 云平台。

这种架构让现场设备、边缘计算和云服务形成了清晰的分工。

十四、总结：让 CAN 数据真正走向云端

对于大量使用 CAN 总线的工业和移动设备来说，数据本身并不缺乏，真正缺少的是一条可靠的数据通道。

传统架构中，CAN 数据往往停留在设备内部；而通过 EC312 + DSA + AWS IoT Core，可以将这条数据链路延伸到云端：

CAN 数据采集 → 边缘解析 → 数据标准化 → MQTT → AWS IoT Core → 云端存储与分析

其中：

EC312 负责现场 CAN 数据采集和边缘计算；
Python 提供灵活的数据解析能力；
Internal MQTT 实现应用之间的数据解耦；
DSA 负责数据管理和云连接；
4G/LTE 为移动及远程设备提供网络连接；
AWS IoT Core 提供云端设备接入能力；
TLS/X.509 保证设备与云端之间的安全通信；
InHand Device Manager 支持设备远程运维。

最终形成一套面向工业设备、车辆、工程机械、发电机组、EV/BMS 和其他 CAN 设备的边缘物联网架构。

对于希望将现有 CAN 设备接入 AWS 的项目而言，这种 "Edge Processing + Secure Cloud Connectivity" 的架构可以减少云端协议处理工作，同时降低网络传输压力，并为后续的数据分析、远程监控和设备运维提供统一的数据基础。