统一信号网关：以同一套信号模型连接不同总线
BMCLI 的统一信号网关可以在不同总线之间交换具有工程含义的信号，完成解析、映射与重新编码。本篇以底盘 CAN 和研发用私有 CAN 之间的单向连接为例，介绍如何只用配置实现信号适配。
设想团队正在开发一款传感器 ECU：它需要底盘车速作为输入，但软件尚未稳定，暂时不适合直接接入底盘网络。底盘 CAN 提供 km/h 单位的车速，ECU 的私有 CAN 采用自己的 ID、布局和 m/s 单位。我们让分析仪的两个端口分别连接两侧，BMCLI 从底盘侧提取车速，在私有侧重新编码发送；工程中不配置从私有侧返回底盘的输出。
与直接转发整帧相比，这种方式只交换选定的信号，并能处理缩放、有效性、周期与目标保护字段。AI 根据两侧 DBC 和您的规则生成原生网关配置，稳定运行时无需额外脚本，也不需要 AI 会话持续在线。
两侧分别使用独立网络，底盘侧按项目要求接入，私有侧配置自己的供电和终端；所需的电气隔离能力按分析仪规格与接线方案选择。
图 12-1 两条独立 CAN 网络，只传递选定信号。工程关系示意。
给 AI 的输入：描述双 CAN 适配工程
Section titled “给 AI 的输入：描述双 CAN 适配工程”准备两侧 DBC、项目 Bench、源失效规则与目标保护规则。下面的任务限定为双 CAN 教学网关；正式产品 E2E 适配是换入项目规范后的另一项工作。
请使用 BMCLI 信号网关，为我的传感器生成双 CAN 车速适配工程。chassis 网络使用 chassis.dbc，sensor 网络使用 sensor.dbc，设备与速率按项目 Bench 配置。从 ChassisStatus.Speed 提取车速，换算成 m/s 后写入 SensorMotion.Speed，目标每 20 ms 发送。源超过 100 ms 未更新时输出约定的无效码并清除有效位，恢复后重新提供有效车速。目标 Counter 和 CRC 使用我提供的教学保护规则。两侧保持独立网络，只允许 chassis 到 sensor 的指定信号输出，不建立私有侧到 chassis 的发送关系；底盘侧接入模式按已确认的 Bench。本次用数据库和原生 .bmgw 配置完成映射，不增加自定义程序。请先生成工程并离线校验，再在我确认的隔离台架上采集两侧报文，核对正常、失效与恢复效果；交付工程、检查结果与 Linux 部署说明。
描述里最重要的是“哪个信号，从哪里到哪里，按什么规则表达”。信号位宽、字节序与缩放可以从 DBC 取得；对于缺少的周期、无效值含义和 E2E 算法，请补充相应项目资料。AI 不需要您先写好每一个 JSON 字段。
随文提供双 CAN 网关工程与两个 DBC。其中 .bmgw 是 BMCLI 原生工程格式，完整保存逻辑端口、信号与输出配置；本机序列号等连接信息仍由 Bench 管理。
成品与效果：给传感器一条它能理解的车速
Section titled “成品与效果：给传感器一条它能理解的车速”随文提供原生 .bmgw 工程与两个 DBC。下表展示配置定义的映射效果，后文介绍离线检查、台架运行与 Linux 部署。
先构造一个与实际接入相似、又便于观察的实验：
| 准备项 | 在实验中的作用 |
|---|---|
| 电脑，或运行匹配 Linux/ARM 软件包的树莓派 | 运行 BMCLI 与网关工程 |
| 至少两个合适的 BUSMUST CAN/CAN FD 端口 | 分别接底盘网络和传感器私有网络 |
| 底盘车速发送源与传感器接收端 | 独立练习可用测试节点代替 |
| 两侧 DBC、连接参数与保护规范 | 说明信号位置、单位、周期及有效性要求 |
两侧保持为不同的 CAN 网络，BMCLI 生成配置中需要的目标报文，让传感器直接取得所需信号。
本例源报文 0x100 的车速单位为 km/h，目标报文 0x200 使用 m/s，目标每 20 ms 发送一次。对应关系很直观：
| 底盘车速 | 传感器侧车速 | 目标状态 |
|---|---|---|
| 0 km/h | 0 m/s | 有效 |
| 36 km/h | 10 m/s | 有效 |
| 72 km/h | 20 m/s | 有效 |
| 108 km/h | 30 m/s | 有效 |
| 超过 100 ms 未收到源更新 | 无效编码 | Valid=0，目标保护字段继续正常生成 |
例如 72 km/h 的源 raw 为 7200，目标 raw 为 2000。变的是编码，保留的是同一个物理含义。源过期时，目标按约定表达“现在没有可靠车速”，而不是让旧值假装仍在更新。
实现解析：BMCLI 在成品中承担的工作
Section titled “实现解析：BMCLI 在成品中承担的工作”下面结合关键调用说明应用的实现方式。AI 生成的程序将这些调用组织成完整流程，并处理返回结果与任务收尾。
网关理解的是信号，而不只是报文
Section titled “网关理解的是信号，而不只是报文”整个过程可以概括为：
源报文 → 解码与有效性检查 → 信号状态 → 映射与变换 → 目标编码与保护 → 目标发送。
报文级路由适合转发既有帧；信号网关则可以只选择一个信号，把它放到另一种布局甚至另一种协议里。几个关键工作由 BMCLI 连续执行：
统一工程值。 源和目标分别使用各自的编解码规则（Codec）。中间保存类型、物理值、有效性与源观测时间，因此相同比特不必代表相同含义，重新计算也不会让过期数据“续命”。本例使用线性换算 y=x÷3.6。
独立安排输出。 源帧到达时更新状态，目标按自己的 20 ms 周期编码发送。需要随值变化更新的场景也可以采用相应策略；选择依据是目标协议要求，而非网页刷新频率。
照顾保护字段。 源检查和目标保护使用各自的上下文。目标报文重新编码后，再生成它自己的 Counter 和校验，而不是照抄源 CRC。随文只配置了目标教学 CRC/Counter；有源保护的项目还应配置对应检查。
AUTOSAR E2E 和厂商自定义规则可通过匹配的配置或插件接入。AI 根据项目算法规范、Data ID、字段布局和测试向量，选择 CRC/SUM 等保护算法并完成配置与验证，便于统一维护计数和校验规则。
离线检查已经可以运行：
# 离线校验原生信号网关配置，不打开设备或发送报文。bmcli gateway validate --file=sensor-speed.bmgw --format=json随文工程的检查结果为：
{"status":"ok","project":"sensor-speed","signals":2}在 daemon、Bench 和通道已经准备好的台架上，AI 再组织加载、启动与观察：
# 加载双 CAN 信号映射工程，准备运行实例。bmcli gateway load --file=sensor-speed.bmgw# 启动配置中的单向映射与目标周期发送。bmcli gateway start --instance=sensor-speed# 查看源信号、映射值及有效性，核对两侧工程含义。bmcli gateway signals --instance=sensor-speed --format=json# 查询网关实例状态与运行统计。bmcli gateway status --instance=sensor-speed --format=json# 停止该实例的映射输出，结束本次运行。bmcli gateway stop --instance=sensor-speed这些命令只说明关键环节。实际工具还会采集目标总线，核对单位、周期、无效状态与保护结果，并在停止完成后清理本次资源。结构校验通过说明配置可被理解，目标端的接收结果才说明适配是否达到了预期。
把网关放到树莓派上
Section titled “把网关放到树莓派上”这个案例不一定需要长期占用一台桌面电脑。使用匹配架构的 BMCLI/BMAPI 软件包，树莓派或紧凑 Linux 主机可以与分析仪一起放在实验台旁，运行同一份逻辑工程。更换的是本机 Bench 绑定；采用原生插件时，也一并准备对应 ARM/Linux 库。
可以请 AI 配置服务启动、日志轮转、状态监视与异常恢复，浏览器用于查看运行情况。稳定运行的映射由 BMCLI 执行，不需要 AI 会话一直在线，也无需云端逐帧作出决策。
专用 Linux 主机便于统一后台负载、部署环境和启动流程。部署时可按项目指标检查端到端延迟、抖动和过载表现，结合供电与环境要求选择适合长期运行的主机和分析仪。
进一步探索：统一模型还可以带来什么
Section titled “进一步探索：统一模型还可以带来什么”这个案例还可以继续完善，也可以延伸到更多工作中。您可以从感兴趣的一项出发，与 AI 讨论下一步的实现。
从双 CAN，扩展到不同协议
Section titled “从双 CAN，扩展到不同协议”BMCLI 的信号网关支持 CAN/CAN FD 与 Modbus 端点，既可以按 DBC 导入 CAN 定义，也可以配置 Modbus 资源。例如把温度采样输出到 CAN，或把 CAN 工况请求映射到 Modbus 继电器。
数值处理也不限于比例换算：阈值比较、固定数学函数和坐标变换可以组合到信号关系中；更复杂的非线性算法或厂商编码可由 AI 生成适配插件，并配套测试。本篇的双 CAN 映射只需数据库和 .bmgw 配置，无需额外程序，属于零代码应用。若增加自定义算法插件，则属于代码扩展；代码由 AI 生成，也依然是代码。
从连接设备，到组织一个信号系统
Section titled “从连接设备，到组织一个信号系统”如果每增加一种设备，都为它与现有设备分别开发转换程序，系统很快就会出现许多成对适配。统一模型提供了另一条思路：每种接入负责解释自己的数据，应用在共同的信号层组织关系，再由目标端表达为它需要的格式。
相同的测量含义，可以用于仪表显示、测试判断和另一条总线的输入；同一份业务关系，也可以随部署从桌面台架迁移到边缘主机。接入更多设备时，复用已有信号与应用逻辑，可以减少重复开发。
更换设备，而保留应用的含义
Section titled “更换设备，而保留应用的含义”假设温度最初来自 CAN 传感器，后来换成 Modbus 采集模块，上位机和测试逻辑是否也要重做？可以请 AI 在统一模型中保留温度名称、单位和有效性约定，只调整来源绑定及必要的换算。参考实现是先对照两种设备的量程、更新周期与无效值，再检查既有映射和页面是否仍满足要求。这个实验能帮助团队区分设备差异与业务规则，逐步形成可随硬件更换而复用的信号接口。
为多源计算定义可信的数据条件
Section titled “为多源计算定义可信的数据条件”高速 CAN 信号与较慢的 Modbus 采样参与同一次计算时，仅有两个数值还不够，还需要知道它们来自什么时候。可以让 AI 围绕统一信号状态，明确各输入的最大允许年龄、观测时间差，以及失效后的输出行为。内置变换适合的部分用配置表达，更复杂的融合逻辑通过插件实现，并用不同到达顺序和缺失输入检查结果。由此延伸出来的，是一套既表达“算出什么”，也表达“何时可以采用”的模型，为跨协议控制与分析提供更清楚的基础。
以下文档介绍本篇涉及的接口；具体参数可通过本机 JSON Help 查询。