最小事件卡应包含哪些字段

工程师首先需要事件标识、相对时间窗、数据版本、通道质量、处理决定和弃判原因;若要进入真实运维,还需要独立的设备与车道标识、时间同步状态、维护日志和责任闭环。只有把“现有软件字段”与“未来业务字段”分开,事件卡才既可用又不误导。

真实文件提供scenario_id、time_s、通道数值与状态、synthetic和data_version等字段,JSON报告还有selection、computed features与decision。它们是模拟数据接口,不包含真实车牌、车主身份、故障维修工单或硬件UTC时间。

值守、工程与研究三类读者

传统停车场后台往往围绕放行事务设计,而磁事件研究的首要问题是“该如何解释一段短时变化”。两个系统的零点不同:道闸记录提供事件触发,磁通道提供相对样本,现场维护日志解释非车辆活动。若把三种时间完全等同,会在排障时把接口延迟误认为磁场峰值延迟。

不同岗位需要不同层级的信息。值守人员希望知道是否需要行动;设备工程师希望看到通道状态与时钟问题;研究人员需要追溯可复算的数据版本与窗口。事件卡可以默认展示最小摘要,再让授权人员展开详情,而不是把全部技术字段放在一行。

从SIM编号到质量与弃判原因

最小卡片分四段。第一段标识SIM编号和是否为Synthetic Scenario,避免把例子当现网告警;第二段说明相对时间窗口与采样数量;第三段展示Bx、By、Bz、reference是否VALID、SATURATED或LOST;第四段给出RENDER_EVENT或ABSTAIN及具体原因。

以SIM-12为例,参考通道存在LOST,decision.status是ABSTAIN;维护人员应首先看到“参考缺口,当前不可解释”,再点开报告查看哪段样本不可用。以SIM-03为例,问题是场景假设下道闸电机共同扰动;其弃判原因与失联完全不同。两张卡不能都只写“检测异常”。

现有CSV与未来运维系统的分工

CSV字段有固定15列,包括scenario_id、sample_index、time_s、bx_au/by_au/bz_au/reference_au、四个对应_status、timebase_status、unit、synthetic及data_version。数值列允许空值,状态列必须保留;前端展示缺失时不能调用默认归零的转换。

报告并不是直接复制CSV。selection定义窗口与点数,features_computed_from_csv存从样本计算的结果,decision含状态、标签及reasons,还明确is_trained_diagnostic_model为false。对于工程师而言,原因链比一个不透明的“风险分”更容易形成排查动作。

概念方法与适用条件对照
卡片信息现有V3证据字段真实运维仍需补充
身份与时段scenario_id、time_s、data_version真实车道ID和可信UTC
质量与数据四路_status、unit、synthetic现场校准与维护登记
结论与复查decision.status、reasons、报告路径工单闭环和责任记录

真实场地接入还需要场地 ID、安装点、设备固件、校准版本、时钟同步证据、维护记录和工单编号。这些不是当前 合成 CSV 的十五列字段,属于未来外部业务系统的独立映射范围。

车库场景图和报告文件

配合[SIM-12参考缺失报告](/gaterestart/data/v3/reports/SIM-12.json)、[SIM-03报告](/gaterestart/data/v3/reports/SIM-03.json)和[案例总览](/gaterestart/simulations/)可看到质量与场景来源的不同字段。下载数据时仍须保留原15列的状态语义与a.u.单位。

数据字典与业务字段的证据来源

现有字段与质量状态可从 field_dictionary.json 和 report-schema.json 核对,数值来自合成案例及其分析结果。工程师工作台的页面结构、未来车道 ID 和工单闭环属于拟议应用设计,尚未接入真实物业业务系统。

字段映射和工单闭环的后续工作

下一步应通过一份字段映射表对齐磁迹、道闸控制器与现场维护系统:哪个系统生产时间、哪个系统拥有质量状态、哪个字段允许人工修订、哪里保存审计轨迹。只有经过真实连接测试,才能把规划字段升级为“已实现”。

继续查看[GR-01系统总成](/gaterestart/products/gr-01/)、[研究方法](/gaterestart/research/)与[磁事件研究视角](/gaterestart/insights/from-meg-to-gates/);从[资讯中心](/gaterestart/updates/)可返回其他工程说明。