在制造业数字化转型的语境中，“场景”已经成为一个高频词汇。政策文件在讨论典型场景，软件厂商强调面向场景，企业也在梳理自身业务场景。然而，一旦进一步追问：什么是工业场景？答案往往并不一致。

在实际工程与应用语境中，所谓“场景”的指代并不稳定：既可以指三维车间模型，也可以指一段业务流程，亦可能被用于描述一组传感器配置，或跨车间协同的整体方案。同一术语对应多类对象，其结果并非概念扩展，而是语义失稳，进而导致系统难以统一建模与处理。

这背后反映的，并不是理解能力不足，而是一个长期存在的问题：工业场景尚未形成可被工程系统直接使用的结构化表达方式。

一、问题不在“是否理解场景”，而在“能否结构化表达场景”

过去几十年，工业界与学术界均尝试对“场景”进行界定。

• 部分研究将其视为交互序列，强调事件之间的时间关系；

• 部分方法将其作为设计阶段的描述对象，用于表达系统预期行为；

• 在自动驾驶等领域，也形成了从抽象场景到具体场景的分层建模方法。

这些方法在各自语境下均具备价值，但存在一个共同局限，它们可以在一定程度上描述场景，但并未回答一个更基础的问题：场景究竟由哪些要素构成，从而也无法形成可被人机共同理解的结构化表达。

因此，场景可以被叙述，但难以被系统消费；可以用于沟通，但难以用于执行；可以支持项目交付，但难以沉淀为可复用能力。

工业软件长期依赖项目交付，这一模式本身正是场景难以结构化与能力难以复用的重要原因之一。同时，这种依赖关系又反过来进一步固化了场景无法标准化表达的问题，形成了一个典型的负面循环。

二、工业场景难以定义的三个原因

从工程角度看，这一问题主要源于三个方面。

1. 工业系统缺乏极简表达

场景必然发生在某个工业系统之中。但工业系统本身高度复杂：设备、产线、车间与工厂之间存在多层结构，不同行业在运行机理上差异显著。如果系统本体无法被统一表达，场景就缺乏稳定的语义承载基础。

2. 系统与场景长期混用

在实践中，两者往往未被严格区分。

系统回答的是：

• 有哪些对象

• 对象如何组织

• 会发生哪些事件

• 遵循什么规则

• 可以执行哪些流程

场景回答的是：

• 在什么条件下发生

• 为何发生

• 由谁负责

• 人与系统如何分工

• 如何完成一次闭环

系统描述“存在”，场景描述“运行”。这里的“存在”并非静态状态，而是指系统所具备的结构与能力边界；“运行”则指在特定工作域与条件下的一次具体执行实例。

3. 业务语义长期隐式存在

在多数工业系统中，以下信息未被显式表达：

• 目标（为何执行）

• 角色（定义责任的结构性分配）

• 自治（定义人类与系统之间的决策权分配）

这些信息往往分散在流程设计或实现逻辑中，能够被人理解，但难以被工程系统识别。

三、用SECP 表达工业系统

要定义场景，必须先定义系统。需要说明的是，SECP并非工业系统本身，而是对工业系统进行抽象与表达的统一语义模型，它所描述的是工业系统的“结构形态”，而非其具体实例。

工业系统在语义层可以被压缩为四类要素：

• S（Structure）结构：实体及其关系

• E（Event）事件：状态变化

• C（Configuration）配置：规则与约束

• P（Process）流程：执行路径

四者构成一个最小闭环：S → E → C → P

这一表达不是执行顺序，而是结构依赖关系的抽象表达。

四、系统与场景的范畴分离

基于SECP，可以明确区分：系统是能力结构，场景是运行实例。系统定义能力边界，场景描述一次具体执行过程。

需要进一步说明的是，这里的“能力边界”并非黑盒意义上的输入输出封装，而是通过结构（S）、规则（C）与流程（P）显式表达的能力范围；而“执行过程”也并非黑盒运行，而是基于该结构展开的一次具体运行实例。

五、一个必须先明确的前提：工作域（Working Domain）

在给出场景结构定义之前，必须先引入一个前提条件：工作域（Working Domain）——场景发生的物理与组织边界。

需要说明的是，这里的“边界”指的是场景发生的空间与组织范围，而非系统所具备的能力边界。前者回答“在哪里发生”，后者回答“能做什么”，二者属于不同层面的约束。

没有工作域，场景就缺乏坐标系：

• S（结构）的边界无法确定 

• E（事件）的触发范围无法界定 

• P（流程）的执行路径无法落地 

因此必须明确：工作域不是第8个维度，而是七维结构成立的前提条件。

六、显式引入G / R / A

在SECP基础上，场景还必须引入三个维度：

• G（Goal）目标：定义成功标准

• R（Role）角色：定义责任分配

• A（Autonomy）自治：定义人机决策边界

G用于判定场景是否完成，必须具备可度量性与可验证性（例如“缺陷率 < 0.8%”，而非“提升质量”）。

R定义责任的结构性分配，而非简单的岗位或权限划分，其关注的是责任绑定关系，而不是权限配置。

A定义人类与系统之间的决策边界，从而形成不同的人机协作模式（*注：通常可表示为从 L1（人工执行）到 L5（完全自主）的分级体系，此处为类比表达，并不对应自动驾驶等行业的具体标准）。

七、工业场景的结构化定义

由此得到：Scenario = ⟨S, E, C, P, G, R, A⟩

其中各维度构成结构化要素集合，其排列顺序仅为表达约定，不表示执行顺序或因果依赖关系。七个维度形成一个最小完备集，即去掉任何一个维度，场景定义都不再成立。

八、一个极简案例（用于理解结构）

以“压铸机模温超限预警”为例：

• S：压铸机、模具 

• E：模具温度超限 

• C：温度范围 

• P：检测 → 预警 → 处理 

• G：缺陷率 < 0.8% 

• R：系统与操作员责任分配 

• A：L2（人决策） 

该示例仅用于说明结构映射关系，并不替代完整的场景定义。基于工作域的层级划分，场景可在设备级、产线级、车间级与工厂级等不同尺度上被定义，从而形成跨层级的一致结构表达。

九、场景的三态：定义态、实例态、运行态

在工程实践中，仅有结构定义仍然不够，还需要区分场景的三种状态：

• SDS（Scenario Definition Schema，定义态）→ 描述场景的标准结构（七维定义）

• SIP（Scenario Instance Profile，实例态）→ 在具体工作域中绑定设备、人员与配置

• SRP（Scenario Runtime Parameter，运行态）→ 在运行过程中，对实例中的要素赋予具体数值与状态（即参数化结果）

需要说明的是，前文所称“场景是运行实例”，是在与“系统”进行范畴区分时的表达；而这里的三态划分，则是针对同一场景在工程实现过程中的不同状态描述，场景三态中真正强调的是定义可复用，实例可部署，运行可演化。
 

十、人因与人机工效约束

至此，场景的结构表达（含工作域与三态）已经完整。但要使该结构在真实工业AI系统中稳定运行，还必须补充一层常被忽略的约束。

场景始终与人相关，但“人”不等同于“角色”。角色刻画责任分配，而执行质量与认知可行性属于人因与人机工效（Human Factors and Ergonomics）范畴。

需要特别强调的是：角色定义的是“谁负责”，而人因关注的是“能否胜任”。

七维结构保证场景定义完整，人因约束保证场景具备工程可运行性。是否能够理解系统输出，并在具体情境下做出正确使用与判断，是决定场景能否稳定运行的关键。

点击下方链接阅读全文：
陈刚直言｜到底什么是工业场景？