ISA-95的工作请求与回应：四类资源要求为何还要另有Actual资料

OPC UA for ISA-95 Part4的v2.00.0概述，将Job Order定义为请求执行一个工作单位，通常是work schedule中最低层的排定对象。Work Schedule则定义为满足一项生产请求所要完成的全部活动，它包含一个或多个Work Requests，每个Work Request又包含一个或多个Job Orders。[1] 这里的层次按所覆盖活动展开，不是把同一份单据简单复制三个名称。

原文用一百万瓶的包装请求作文字例：整个请求可分成四个、各二十五万瓶的Work Requests；Job Orders再定义某个work center里的工作，例如一条包装线或生产线。这几个数用于说明请求如何分层，Work Request所覆盖的一部分仍可由多个更低层对象表达，并没有被定义成必须一对一对应单个Job Order。

Job Order还会识别要使用的Work Master。概述把后者解释为要遵循的procedure，并另外说Job Order带有该项工作的可变信息。因此，过程名称与这一次工作所含的变量没有合并：识别相同procedure，不能自动补出每次请求相同的具体资料。本文不采用标签内容、生产参数或设备下发示例作为操作指引。

第4.2节进一步限定模型范围。所列Job Order模型是ISA95 Part4 Edition2的子集，面向不需要嵌套资源要求和外部链接的情形。这项子集说明决定了对象清单应怎样阅读：没有列出嵌套要求，并不等于ISA95的全部资料结构从来没有这一层；此处采用的是概述明确划定的范围。

附加Job Order Parameters用name/value pairs表达，四类资源要求则有各自对象。Personnel Requirement对应人员要求；Equipment Requirement可以涉及equipment class或equipment；Physical Asset Requirement可以涉及physical asset class或具体asset。类与具体对象都在文字定义中出现，并非所有要求都必须压成一个设备编号。

Material Requirement列得更细，涉及material class、material definition、material lot或material sublot。它与前面人员、设备和物理资产并列，却有自己的身份层次；把所有资源一律写成“某个物料”会丢掉这份列表原来分开的对象。这里解释模型所命名的资料，不判断真实人员资格或物料是否可投用。

Job Response的起点是报告针对Job Order已完成的工作。其附加Job Response Data同样以name/value pairs表示，另有Personnel Actual、Equipment Actual、Physical Asset Actual和Material Actual四类。它们对应报告中的实际资料，而不是把前述Requirement改名后自动视为要求全部实现。请求说明要什么，回应说明报告了什么，二者的资料角色不同。

回应模型也明确是Edition2的子集，适用于不需要嵌套resource actuals和外部链接的情形。这个范围与请求模型的嵌套requirements相呼应，但限定的是实际资料一侧。只知道有一份Job Response，并不能由模型名称替报告的真实性、完整性或现实产品是否合格作保证。

本篇依据第4.1至4.3节连续文字与邻接，没有看图、读取Annex、运行设备接口或执行生产；版本号不是首次公开日期。