3. 报警数据模型与标准化
综合监控系统（ISCS）接入的报警来源非常杂：电力监控（PSCADA）的断路器跳闸、火灾报警（FAS）的探测器火警、环境与设备监控（BAS）的风机故障、信号（SIG）的轨道区段占用、门禁（ACS）的非法开门等。各子系统由不同厂家建设，报警字段的命名、编码、时间基准、等级划分各不相同。如果报警中心直接把这些"原生态"报文存下来，就会出现同一类事件在不同表里字段名不同、同一设备在不同系统里ID不同、同一时刻的时间戳相差几十秒的情况，后续的统计、检索和联动都无从谈起。因此，报警管理的第一项工程任务不是"收报警"，而是建立统一的报警数据模型，并设计一套把多源报警映射到该模型上的标准化方法。
一、报警字段定义：一条报警记录应包含什么
报警数据模型的核心是一张"报警事实表"，它描述"什么设备、在什么时间、什么位置、发生了哪一类、什么等级的事件，以及当前处于什么状态"。工程上通常定义以下关键字段：
- 报警ID（alarm_id）：全局唯一标识，建议采用"站点码+子系统码+时间序列+序号"的复合编码，保证跨系统不冲突，也便于按时间范围分片存储。
- 设备ID（device_id）：指向设备台账的唯一编码，是报警与设备关联的锚点。标准化时必须把各子系统的本地设备地址映射到统一设备ID。
- 时间戳（occur_time / clear_time）：报警发生时间与恢复时间，统一采用带时区的标准时间（如UTC+8），并保留毫秒精度，用于计算持续时长和做时序分析。
- 报警等级（level）：通常分为紧急、重要、一般、提示四级，对应不同的声光提示和处置时限。
- 报警类型（type）：如越限、跳闸、通信中断、火警、故障、非法操作等，用于分类统计和联动策略匹配。
- 位置（location）：车站、楼层、房间或区间里程，支持按空间维度聚合。
- 状态（status）：活动/已确认/已恢复/已屏蔽，反映报警的生命周期。
此外还应包含报警描述、源系统标识、原始报文引用等辅助字段，便于追溯。需要强调的是，报警ID与设备ID是两条不同的主线：前者标识"这一次事件"，后者标识"发生事件的实体"，二者不能混用。
二、数据字典设计：让字段"有据可依"
字段定义只是骨架，真正让数据可交换的是数据字典。数据字典对每个字段规定名称、数据类型、长度、取值范围、枚举含义和是否必填。以报警等级为例，字典中应明确"1=紧急、2=重要、3=一般、4=提示"，并规定各子系统上报时必须映射到这四个值，不允许出现"高/中/低"等自由文本。报警类型同样需要枚举化，例如把"断路器变位""保护动作""通信中断"分别编码，避免同一含义出现多种写法。
字典设计的一个实用原则是码值稳定、含义可扩展：已发布的码值不轻易修改，新增类型通过追加编码实现，而不是改变既有含义。这样历史数据在字典升级后仍可正确解读。
三、多源报警标准化映射方法
标准化映射的本质是建立"源字段→目标字段"的转换规则。工程上通常分三步走：第一步做字段级映射，把各子系统的原始字段名对应到模型字段，例如把PSCADA的"发生时刻"、FAS的"报警时间"统一映射到occur_time；第二步做码值级映射，通过映射表把源系统的等级、类型码转换为标准码值；第三步做实体级映射，用设备台账把源系统的本地设备地址解析为统一device_id，并补全位置信息。
下面是一段映射配置的示例（属于教学示例，非实测配置），用一张映射表描述某子系统到标准模型的转换关系：
{
"source": "PSCADA",
"field_map": {
"alarm_no": "alarm_id",
"dev_addr": "device_id",
"occur_t": "occur_time",
"alarm_lvl": "level",
"alarm_kind": "type",
"station": "location"
},
"value_map": {
"level": {"1":"1", "2":"2", "3":"3", "9":"4"},
"type": {"CB_TRIP":"跳闸", "COMM_LOSS":"通信中断"}
}
}映射执行时，先按field_map重命名字段，再按value_map替换码值，最后用设备台账补全device_id与location。若某条报警在台账中找不到对应设备，应标记为"未匹配"并进入待处理队列，而不是直接丢弃——这类记录往往暴露台账缺失或地址配置错误，是数据治理的重要线索。
四、数据质量校验规则
标准化之后还需要一道"质检关"，否则脏数据会污染整个报警中心。常用的校验规则包括：完整性校验（必填字段非空，如alarm_id、device_id、occur_time不能缺失）；唯一性校验（alarm_id不得重复，防止重复上报导致重复计数）；时效性校验（occur_time不得晚于当前时间，且与接收时间的偏差应在合理范围内，用于发现时钟不同步）；一致性校验（level、type必须落在字典枚举内，clear_time不得早于occur_time）；关联性校验（device_id必须存在于设备台账）。
校验结果一般分为通过、告警、拒绝三级：通过的直接入库；告警的（如时间偏差略大）入库但打标，供后续核查；拒绝的（如缺少主键、码值非法）进入隔离区并记录原因。下图展示了从多源报警接入、字段与码值映射、实体解析到质量校验与入库的完整数据流，以及各环节的判定分支。
从图中可以看出，标准化不是一次性的转换动作，而是一条带分支的数据流水线：字段、码值、实体三层映射依次完成语义统一，质量校验再按规则把数据分流到入库、打标和隔离三个出口。其中"台账未匹配"这条虚线分支尤其值得重视，它把报警数据问题反向传导到设备台账治理，形成闭环。
五、落地要点
在实际工程中，建议把映射规则和校验规则都做成可配置的字典表，而不是写死在代码里。这样当新增子系统或厂家升级报文格式时，只需维护映射表即可，无需改动程序。同时应保留原始报文引用字段，一旦标准化结果出现争议，可以回溯到源数据核对。对于时间戳，务必在接入端统一做时钟校准，否则后续的持续时长统计和时序关联都会失真。最后，质量校验的拒绝率、告警率应作为日常运维指标持续观察，异常升高往往意味着某个子系统的配置或台账出现了问题，这正是报警数据治理的切入点。