3. 信号表的基本结构与字段定义

信号表是TCMS设备接口文档中最核心的一张“数据字典”。它把车辆各子系统之间、子系统与TCMS中央控制单元之间交换的每一个变量，用统一的列字段固定下来。接口文档之所以能作为联调、测试、诊断和后期维护的依据，关键就在于信号表的字段定义足够完整、填写足够规范。本节围绕信号表的典型列字段展开，说明每个字段“是什么、为什么要有、应该怎么填”。

一、信号表为什么需要统一字段

在TCMS中，一个信号往往要跨越多个环节：现场传感器采集、子系统控制器打包、MVB/以太网传输、TCMS中央单元解析、司机室显示屏显示。如果信号名称各写各的、数据类型不一致、方向标注含糊，联调时就会出现“发的是16位整数、收的是布尔量”“源和目的写反”“周期对不上导致丢帧”等典型问题。信号表的字段规范，本质上是把这些跨设备约定提前固化，让接口双方在编码之前就对同一份契约达成一致。

因此，信号表不是简单的变量清单，而是一份带有约束的接口契约。每个字段都承担一项约束职责：名称解决“叫什么”，ID解决“唯一标识”，数据类型解决“怎么解释二进制”，方向解决“谁发谁收”，源/目的解决“谁负责”，地址解决“在哪里”，周期解决“多久一次”，量纲解决“物理意义”，默认值解决“异常时怎么办”。

二、典型列字段逐项解析

信号名称：面向人的可读标识，应体现设备、功能与状态，例如“车门1关闭状态”“牵引逆变器故障字”。填写规范要求同一信号在信号表、协议文档、HMI画面中名称一致，避免使用“信号1”“状态A”这类无语义命名。名称中建议包含所属子系统前缀，便于检索。

信号ID：面向系统的唯一标识，通常为数字编号或“子系统缩写+序号”形式，如“DOOR_001”“TCMS_TRQ_012”。ID一经发布不应随意变更，因为测试用例、日志解析脚本、诊断数据库往往直接引用ID。若信号废弃，宜保留ID并标注“停用”，而不是删除后复用。

数据类型：定义信号的二进制解释方式，常见有布尔（BOOL）、无符号整数（UINT8/16/32）、有符号整数（INT16/32）、浮点（FLOAT/REAL）、枚举（ENUM）、位域（BITFIELD）。填写时必须与源设备实际打包格式一致，并注明字节序（大端/小端）与位宽。例如一个16位无符号整数信号，应写明“UINT16，大端，2字节”。

方向：标明信号流向，通常用“发送/接收”或“源→目的”表示。方向必须相对于某一参考设备来写，全文需统一参照系。常见做法是以TCMS中央单元为参照：中央单元发出的标“下行/发送”，中央单元接收的标“上行/接收”。若以子系统为参照，则需在表头明确说明，避免同一张表内参照系混用。

源设备/目的设备：明确信号的产生方与消费方。源设备是数据的打包发送者，目的设备是解析使用者。一对多广播信号应列出全部目的设备，或注明“广播至所有MVB节点”。这两个字段是联调时定位问题的第一依据：通信不通时，先确认源是否真的在发、目的是否真的在收。

地址：指信号在通信报文中的位置，包括端口号、偏移字节、起始位、位长度，或以太网场景下的报文标识与偏移。地址必须与协议帧结构严格对应，填写时应精确到“第几字节第几位起、占几位”，避免只写“在状态字中”这类模糊描述。

周期：信号刷新或发送的时间间隔，单位毫秒。周期决定了实时性与总线负载。填写时需区分“发送周期”与“超时判定时间”，后者通常为周期的若干倍，用于判断通信是否中断。例如周期100ms、超时判定300ms，表示连续3个周期未更新即报通信故障。

量纲：说明信号数值的物理单位与换算关系，如“km/h”“0.1℃/bit”“1=闭合，0=断开”。对于带比例因子的信号，应写明“物理值=原始值×0.1”。量纲缺失是信号表最常见的缺陷之一，会导致显示值与实际值差一个数量级。

默认值：定义信号在无效、未初始化或通信中断时的取值。默认值不是随便填0，而应结合安全策略：故障状态字默认值宜取“故障”而非“正常”，模拟量默认值宜取一个可识别的无效值（如0xFFFF）。默认值字段直接关系到故障导向安全的设计。

三、字段之间的约束关系

这些字段并非彼此独立，而是存在联动约束。数据类型决定地址占用的位宽；周期与超时判定共同决定通信健康判断；方向与源/目的必须自洽，不能出现“方向为接收、源设备却是本机”的矛盾；量纲与数据类型共同决定显示换算是否正确。填写信号表时，应把一行当作一个整体校验，而不是逐列孤立填写。

四、填写规范与常见错误

实际编写信号表时，建议遵循几条硬性规范。第一，先定参照系再填方向，整张表统一以TCMS中央单元为参照，并在表头注明。第二，数据类型与地址必须成对校验，填完位宽后立即核对偏移与位长度是否越界、是否与相邻信号重叠。第三，周期与超时判定成组填写，不允许只写周期不写超时。第四，量纲必须给出换算公式或枚举含义，模拟量尤其不能只写单位不写比例。第五，默认值要经过安全评审，故障类状态字不得默认取“正常”。

常见错误包括：方向与源/目的矛盾；同一信号在不同文档中名称不一致；地址只写到字节不写到具体位，导致位域信号无法解析；周期单位混用毫秒与秒；量纲缺失比例因子，显示值放大或缩小十倍；默认值一律填0，使通信中断被误判为正常状态。这些错误在单机调试阶段往往不暴露，一到多子系统联调就会集中爆发，排查成本很高。

五、从字段到可执行检查

为了让字段规范真正落地，可以把上述要求转化为一张逐行检查表，在信号表评审时逐项打勾。检查项应覆盖：名称与ID是否唯一且语义清晰；数据类型、字节序、位宽是否与协议帧一致；方向参照系是否全文统一；源与目的设备是否完整；地址是否精确到字节与位；周期与超时判定是否成组且单位统一；量纲是否给出换算或枚举；默认值是否符合安全策略。评审时以行为单位逐条核对，比通读整表更容易发现字段间的矛盾。

掌握这些字段的含义与约束后，信号表就不再是一堆并列的列，而是一份可以被解析、被校验、被测试直接引用的接口契约。后续无论是做通信矩阵配置、编写解析脚本，还是设计联调用例，都可以直接从这些字段中提取输入与判断依据。