TPMS OE 号与车型数据治理
本文介绍 XSD Precision 如何治理 TPMS OE 号与车型应用记录，重点说明车型数据库的五级结构、版本更新、证据状态，以及 RFQ、测试和售后的闭环。
核心判断
在 TPMS 传感器业务中，数据库规模很容易被简单地理解为“收集了多少个 OE 号”或“列出了多少个车型”。但对轮胎店、进口商、分销商和 OEM/ODM 客户来说，真正有价值的不是一个越来越长的列表，而是：当客户提供一个 OE 号、车辆信息或原车传感器照片时，我们能否快速找到正确的应用范围，并清楚说明这条匹配记录的依据、版本和验证状态。
因此，我们把 2,000+ 个 OE 号和 10,000+ 个车型应用记录作为一个需要持续治理的产品数据系统，而不是静态宣传目录。数据库的目标，是支持 OE 替换传感器、可编程 TPMS 传感器和门店服务流程的准确决策。
主要数据结构
不同采购任务需要不同的数据入口。
对于 OE 替换传感器，客户通常已经知道原厂号码或能够提供原车传感器照片。我们重点核对 OE 号、车辆品牌、车型、年份、销售市场、频率、气门形式和车轮要求。
对于可编程传感器，不能只因为某个车型出现在列表中，就直接承诺“全部支持”。我们还要确认目标市场、315/433 MHz 要求、传感器类型、编程工具、软件或数据库版本，以及实际测试车辆。
这种分类避免了一个常见错误：把 OE 交叉参考数量直接等同于可编程覆盖范围。两者可以关联，但不能混为一谈。
标准化检查
我们的基本数据单元不是单独的 OE 号，而是一条带上下文的应用记录。典型字段包括：
- OE 号、替代号和传感器内部型号；
- 车辆品牌、车型、年份和销售市场；
- 315 MHz 或 433 MHz 频率信息；
- 橡胶气门或金属气门要求；
- 传感器路线：OE 替换或可编程；
- 所需编程工具和学习方式；
- 数据来源、采集日期和当前版本；
- 已验证、待验证、部分验证或不建议承诺的状态；
- 测试记录、照片、报告和异常说明。
这样管理的好处是，销售人员不会只看到一个“看起来相似”的号码，工程人员也能追溯这条匹配关系为什么成立、在哪个市场成立，以及还缺少什么证据。
证据状态
同一车型名称在不同年份、市场和配置下，可能对应不同的传感器协议、频率、气门结构或学习流程。因此，车型数据需要按多个维度拆分，而不是把所有年份合并成一行。
在录入和审核时，我们重点检查：
1. 车辆品牌、车型和年份是否完整；
2. 北美、欧洲或其他市场是否被错误合并；
3. 频率是否与车辆和目标传感器一致；
4. OE 号格式、前导字符和替代关系是否保留；
5. 编程工具和学习方式是否有实际依据；
6. 橡胶气门、金属气门和轮毂空间要求是否需要单独说明。
这些规则可以减少重复记录、错误合并和“车型名称相同所以一定兼容”的误判。
车型数据库的分级结构
数据库中的记录不会全部以同一种口径对外展示。我们按证据状态管理适配信息：
- 已验证：有明确车辆、工具、操作过程和测试结果；
- 资料匹配：有 OE 或车型资料支持，但尚未完成当前项目的实车验证；
- 待确认：存在候选匹配，但缺少频率、市场、工具或车辆信息；
- 部分验证：部分年份、配置或市场已验证，不能扩展到整组车型；
- 不建议承诺：冲突未解决、数据过期或存在较高误配风险。
对外报价或 RFQ 时，我们会把这些状态和客户需要补充的信息一起交给销售与工程团队。数据库规模不能替代证据，数量也不能自动转化为覆盖承诺。
版本化更新
这里的“分级”首先指车型数据库的结构分级，而不是简单给每条记录打一个可信度分数。我们把一条车型应用拆成相互关联的层级，避免把不同年份、市场和配置错误地合并在一起。
第一级：品牌与车型家族
记录车辆品牌、制造商和车型家族，例如同一品牌下的 SUV、轿车或轻型商用车系列。这个层级用于建立品牌索引、搜索入口和区域覆盖统计。
第二级：车系、车型和车身版本
进一步区分具体车系、车型、车身形式和动力版本。名称相近但平台、轮毂或 TPMS 配置不同的车型，不能只按品牌或车系合并。
第三级：年款、销售市场与配置
同一车型需要按 model year、北美或其他销售市场、配置差异和生产阶段拆分。频率、传感器协议、气门形式和学习方式，往往在这一层发生变化。
第四级：TPMS 应用关系
在具体年款和市场配置下，关联 TPMS 频率、传感器路线、编程工具、学习方式、橡胶或金属气门要求，以及测试和异常记录。
第五级：OE 号与传感器映射
最后，将 OE 号、替代号、自有传感器型号、可编程传感器方案和包装 SKU 与具体应用关联。一个 OE 号可能对应多个车型应用；一个可编程传感器也可能覆盖多个应用，但这些关系必须通过具体条件表达，不能做成无条件的一对一替换。
在这套结构中，维护人员可以从品牌逐层下钻到具体应用，也可以从 OE 号反向追溯到品牌、车系、年款和市场。数据审核状态仍会单独记录为初始录入、待复核、已批准、降级、暂停或关闭，但它不替代车型数据库本身的层级结构。
RFQ、测试与售后闭环
TPMS 数据不是一次导入后永久不变的文件。车型新增、市场变化、工具软件更新、传感器批次变化和现场反馈，都可能影响一条记录的有效性。
因此，每次重要更新都应留下版本、来源、变更字段和审核人。更新流程通常包括：
1. 收集 OE 资料、车辆信息或现场测试反馈；
2. 进行格式统一和重复记录检查；
3. 与现有车型、频率和传感器关系进行冲突检查；
4. 标记新增、修改、降级或关闭的记录；
5. 由产品、工程或质量负责人审核；
6. 更新对外可见的车型指南和内部 RFQ 数据；
7. 保留旧版本，确保销售和售后能够解释历史报价或测试结果。
对客户的意义
数据库的最终价值不在于“能搜索”，而在于帮助客户完成一次可追溯的项目。
当客户提交 OE 号、原车照片、车辆信息或目标车型清单时，系统应能引导其补充频率、气门、数量、包装和编程工具信息。对于不完整的请求，先标记缺口，而不是直接生成确定性报价。
当客户进入样品测试流程时，测试记录需要包含真实车辆、使用工具、安装过程、照片、反馈截止日期和结果。样品测试是资格验证，不是无条件免费赠送；测试结果也可能是成功、失败或无法下结论。
当现场出现问题时，售后记录应回写到车型、传感器、工具和操作流程关联中。这样，一次异常不只是一个被关闭的工单，而可能成为下一版数据和操作指南的改进依据。
工程结论
对于轮胎店和安装服务商，结构化数据库可以减少查找时间、误配和返工。
对于进口商和分销商，它可以帮助比较 SKU 覆盖、315/433 MHz 组合、库存复杂度、包装方案和区域需求。
对于 OEM/ODM 客户，它可以把目标车型、传感器路线、样品、小批量、MOQ 和量产节奏放进同一套项目判断中。
但数据库不应被理解为无条件的车型承诺。准确的 RFQ 仍然需要客户提供车型、年份、市场、OE 号或原车照片，并在必要时通过真实车辆和指定工具完成验证。
工程结论
2,000+ 个 OE 号和 10,000+ 个车型应用记录，只有在统一字段、版本控制、证据等级、工程审核和现场反馈闭环下，才能转化为可靠的业务能力。
我们希望建立的不是一张“看起来很大”的 TPMS 表格，而是一套能够持续回答四个问题的系统：这条记录适用于什么？依据是什么？当前是否已验证？如果出现异常，下一步怎么处理？
这也是 XSD Precision 管理 TPMS 数据库的基本原则：先明确应用，再核对证据；先标注边界，再提供方案；让每一次测试和 RFQ，都能让下一次匹配更准确。
—
工程结论
- 本文按项目提供的“2,000+ OE 号、10,000+ 车型应用记录”规模口径撰写；公开发布前，应由数据负责人导出当前去重统计并确认两个数字的定义。
- “已验证”不应覆盖所有数据库记录；公开页面应明确区分资料匹配、待确认、部分验证和实车验证。
- 文章没有承诺固定车型覆盖率、工具型号、MOQ、交期、价格、认证或全部车型兼容性。
- 建议发布前补充数据库版本号、统计日期和公开查询入口；如果暂无公开查询入口，应保留 RFQ 联系入口。
工程结论
- `deliverables/xsd-north-america-tpms-capability-pack-en-20260724.md`
- `versions/tpms-solution/XSD-OEM-MATCHING-GUIDE-v2026.07.18.3/manifest.json`
- `versions/tpms-sensors-support/XSD-TSS-SUPPORT-v2026.07.25.9-tpms-service-ecosystem-strategy-20260725/manifest.json`
- `versions/tpms-rfq-catalog/XSD-TPMS-RFQ-CATALOG-v2026.07.25.1-public-rfq-link-boundary-clean/manifest.json`
- `audits/coverage-page-residue-assessment-20260715.md`
提交 TPMS 车型、OE 号或应用匹配需求
对外应用判断以具体车辆、市场、频率、工具和验证状态为边界，数据库记录不替代项目级确认。
资料适用边界与项目输入
本模块用于帮助读者将公开资料转化为可评审的项目输入，同时明确官网公开信息与受控项目文件的管理边界。
适用对象
TPMS 采购、门店技师、渠道和工程团队：用于确认 OE 号、车型年款、市场频率、可编程传感器方案和车辆学习验证边界。
项目输入
OE 号、车型年款、目标市场、315MHz / 433MHz 频率、编程工具、传感器样品、激活读取结果和车辆学习条件。
输出边界
官网公开资料用于说明判断逻辑、输入清单、验证路径和协作边界；客户车型项目、测试记录、软件参数、质量记录和批准依据纳入 XSD Precision 工程文件与项目资料受控管理体系。