📚 课程目录第3章 MES中的工位资源数据模型

3. MES中的工位资源数据模型

工位资源数据模型是MES排产、派工与冲突治理的地基。如果模型只把工位当成一张“工位表”，那么一旦遇到多工位协同、设备能力差异、班次切换、临时停机或工位替代，系统就会被迫在业务代码里打补丁。合理的做法是把工位资源拆成五个相互关联的维度：资源树表达层级归属，资源能力表达能做什么，资源日历表达什么时候可用，资源状态表达此刻能不能用，资源关系表达与谁协同或互斥。五者共同决定一个工位在某一时刻是否可被分配给某道工序。

资源树：用层级表达“归属”与“汇总”

资源树解决的是“这个工位属于谁、由谁汇总”的问题。典型层级为：工厂 → 车间 → 产线 → 工位 → 子资源（设备、工装、人员）。数据库常用parent_id自关联实现，配合path字段（如/F01/S02/L03/W04）加速子树查询。资源树不只是组织架构，它决定了能力继承、日历继承和状态传播：父节点停机时，子节点默认不可用，除非显式覆盖。

resource (
  resource_id      VARCHAR(32) PRIMARY KEY,
  resource_code    VARCHAR(64) UNIQUE,
  resource_name    VARCHAR(128),
  resource_type    ENUM('FACTORY','WORKSHOP','LINE','STATION','DEVICE','TOOL'),
  parent_id        VARCHAR(32),
  path             VARCHAR(255),
  inherit_capability BOOLEAN DEFAULT TRUE,
  inherit_calendar   BOOLEAN DEFAULT TRUE,
  status           VARCHAR(16)
)

资源能力：把“能做什么”结构化

能力不能只写一句“可加工A产品”。工程上应拆成能力类型 + 能力参数 + 能力等级。例如某装配工位能力记录为：能力类型ASSEMBLY，参数torque_max=25N·m、product_family=GX，等级A。排产时用“工序需求能力”与“资源能力”做匹配，匹配失败即产生能力冲突。能力可继承：产线级能力自动下发给工位，工位可追加但不能删除继承项，只能通过override标记覆盖参数。

资源日历：把“可用时间”变成可计算区间

日历的本质是时间区间集合。推荐用“班次模板 + 例外日历”两层设计：模板定义每周循环（如早班08:00–16:00、中班16:00–24:00），例外表记录节假日、加班、检修。计算可用性时，先展开模板得到基础区间，再用例外做并集或差集。关键字段包括calendar_id、shift_pattern、valid_from、valid_to、exception_type（ADD/REMOVE）。

资源状态：区分“静态属性”与“动态占用”

状态分两类：生命周期状态（启用、停用、报废）和实时可用状态（空闲、运行、待机、故障、保养、被占用）。前者变化慢，存于资源主表；后者变化快，建议单独建resource_state_log表，记录resource_id、state、start_ts、end_ts、reason_code。排产判断“某时刻是否可用”时，必须同时满足：生命周期为启用、日历区间覆盖、实时状态为空闲或可抢占。

资源关系：协同、替代与互斥

关系表是冲突治理的核心。常见关系类型：REQUIRES（工位必须搭配某工装）、ALTERNATIVE（可替代工位，带优先级）、MUTEX（互斥，不能同时占用）、SYNC（需同步启停）。用resource_relation(from_id, to_id, relation_type, priority, effective_from, effective_to)统一表达。替代关系让排产在冲突时自动降级到次优工位；互斥关系则直接阻止非法组合。

对象模型与数据库落地要点

把上述五维映射到对象模型时，建议采用“主表 + 扩展表”结构：resource主表存树与生命周期；resource_capability、resource_calendar、resource_state_log、resource_relation分别承载能力、日历、状态与关系。所有扩展表都带resource_id外键和effective_from/effective_to，保证历史可追溯。查询某工位在T时刻的可用性，可用一条视图或存储过程串联四张表，避免业务层反复拼装。

设计时先问三个问题：能力是否可继承？日历是否按产线统一？状态变化是否需要留痕？这三个答案直接决定表结构是“扁平”还是“分层”。

常见误区：把实时状态直接写在资源主表上。这样虽然查询快，但无法回溯“为什么当时不可用”，冲突复盘时缺少证据链。建议主表只存生命周期状态，实时状态走日志表。

最后，资源关系表要设置有效期和优先级。替代工位的优先级决定冲突时先降级到谁；互斥关系则要在排产前做组合校验，而不是等到派工才发现。模型设计完成后，用一组边界用例验证：父节点停机、日历例外叠加、状态日志跨班次、替代链长度为3时，系统是否仍能给出唯一且可解释的分配结果。能通过这组验证，工位资源模型才算真正支撑起后续的冲突治理。