机床联网落地，不能只理解为把设备状态采集到大屏上。一套可验收的方案至少要同时回答 4 个问题：设备能否稳定接入、数据能否正确采集、状态能否可靠判定、任务能否形成闭环。只完成设备上线，通常只能得到状态看板；把工单、工序、数控程序与执行反馈建立关联，才具备生产协同基础。
实际建设时，建议从设备台账、点位映射、状态字典、任务链路和验收记录五类交付物入手。先用少量具有代表性的设备验证数据链路，再扩展到其他机型和业务场景，避免把“通信正常”“页面有数据”误当成完整落地。
一、先把机床联网拆成可验收的目标
很多项目一开始就讨论采集频率、协议和界面，开发完成后才发现问题：设备数据无法关联工单，报警状态只有代码没有含义，程序已经传到机床却不知道是否实际执行。机床联网首先是业务链路设计，其次才是通信与软件开发。
| 目标层 | 需要解决的问题 | 验收时要回答的问题 | 典型交付物 |
|---|---|---|---|
| 设备接入 | 不同机型能否稳定传输状态与程序 | 设备在哪台、采用什么接入方式、断线后如何恢复 | 设备接入台账、接口清单、点位表 |
| 数据采集 | 运行、报警、程序、刀具等数据是否准确 | 字段来自哪里、何时采集、异常值如何标记 | 采集规则、数据字典、数据质量记录 |
| 状态监控 | 设备是在运行、待机、报警还是离线 | 状态判定依据是什么、多久没有更新算失效 | 状态判定表、报警分类表、异常处理记录 |
| 任务协同 | 任务、程序、机床和执行结果能否关联 | 谁下任务、谁传程序、何时算完成、异常如何回传 | 任务流转表、程序清单、任务与机床绑定表 |
例如，一台机床显示“运行”，并不代表它正在执行当前工单中的工序；一条程序传输成功，也不代表机床已经加工完成。判断依据应来自多个字段的组合，包括程序标识、任务号、运行状态、开始与结束事件、产量计数及报警信息。
1.1 明确 CAD、CAM、CNC、DNC、MDC 与 MES 的边界
机床联网是指将数控设备及其控制器、加工任务、运行状态和过程数据接入统一通信与数据链路的工程实践，核心是设备可连接、数据可解析、状态可判断、任务可协同，区别于 CNC——后者指设备自身的数控系统，也区别于 MDC——后者侧重设备运行数据的采集与统计。
| 概念 | 主要负责 | 不承担 | 典型输出 |
|---|---|---|---|
| CAD/CAM | 工程图、三维模型、工艺准备与数控编程 | 不直接判定设备实时状态 | 工程图、三维模型、工艺文件、数控程序 |
| CNC | 设备内部的运动控制、插补与程序执行 | 不负责跨设备任务与生产数据汇总 | 设备控制状态、坐标与执行反馈 |
| DNC | 数控程序传输、队列管理与执行确认 | 不负责完整的生产计划与物料协同 | 程序队列、传输记录、执行确认 |
| MDC | 设备数据采集、运行监控与统计 | 不直接产生制造任务 | 状态、报警、运行与停机记录 |
| MES | 工单、工序、报工、异常及生产过程协同 | 不替代设备内部控制 | 任务执行记录、报工数据、生产追溯 |
| PLM/PDM | 图文档、版本、变更与产品数据管理 | 不直接控制机床运行 | 受控图文档、版本关系、变更记录 |
这些概念可以集成，但不能相互替代。若把文件拷贝到机床称为 DNC，把采集到运行时间称为任务协同，平台中的数据含义就会失真。接口设计阶段应明确每个系统负责产生什么数据、接收什么数据，以及数据状态由谁维护。
另一个常见误区是追求字段越多越好。实际选点应围绕业务问题展开：需要判断设备是否加工，就需要运行与程序信号；需要分析停机原因，就需要报警、待机原因和时间信息；需要追溯生产任务，就需要工单、工序和程序标识。没有使用场景的数据点，后续只会增加维护成本。
二、总体架构：建立从设备到业务的五层闭环
完整的机床联网架构可以分为设备执行层、边缘采集层、数据服务层、应用协同层和业务使用层。分层的目的不是增加系统数量，而是明确数据产生、采集、存储、加工和使用的责任边界。
| 架构层 | 核心内容 | 主要输入 | 主要输出 |
|---|---|---|---|
| 设备执行层 | 数控系统、机床传感器、程序与任务执行 | 加工程序、控制指令 | 运行状态、报警、坐标、程序执行结果 |
| 边缘采集层 | 协议适配、点位映射、数据校验与本地缓存 | 设备原始信号 | 标准状态、事件、采集报文 |
| 数据服务层 | 时序数据、关系数据、文件与接口服务 | 采集报文、业务对象 | 设备画像、事件记录、追溯链 |
| 应用协同层 | DNC、MDC、MES类应用与任务编排 | 工单、工序、程序、设备状态 | 任务派发、程序队列、报工与异常闭环 |
| 业务使用层 | 生产管理、设备维护、质量与经营分析 | 状态、任务、报警、产量数据 | 调度依据、异常清单、统计与分析结果 |
2.1 打通一条可追溯的数据链
一条完整的制造数据链通常从产品或零部件信息开始，经过工艺路线进入数控程序，再通过任务派发和程序传输到达具体机床，执行结果最终回传至生产管理环节。各环节应使用一致的识别关系，而不是仅靠文件名或设备编号猜测关联。
- 建立设计对象、图文档与零部件之间的对应关系。
- 将零部件、工艺路线、工序和加工设备要求建立关联。
- 生成或导入数控程序，并记录程序编号、版本和适配机型。
- 依据工单与工序生成设备任务，明确目标机床和执行顺序。
- 通过 DNC 或受控传输方式把程序送达机床，并记录传输状态。
- 采集机床开始、结束、暂停、报警和计数信息，形成任务执行反馈。
- 把报工、异常、检验与变更结果关联回原始任务，形成追溯记录。
设计、工艺与制造环节不必追求一次全部打通。更稳妥的做法是先选定一条高频、可检查的产品或零件路线，明确每个环节的输入输出，再逐步扩大范围。
2.2 先统一对象标识，再建设数据接口
接口能够传输字段，并不代表数据可以关联。设备编号、刀具编号、工单号、工序号和程序号应采用统一编码规则；同一个对象在不同系统中的名称、版本和状态要有明确映射。缺少统一标识时，设备事件只能作为孤立记录存在，任务协同也很难可靠运行。
建议形成“企业—车间—设备—工位—任务—工序—程序”的对象关系表，并明确对象创建方、维护方和停用规则。编码调整不能只在数据库中直接修改，还要同步接口、标签、文件命名和历史数据解释规则。
2.3 与设计、工艺及生产管理链路衔接
在设计到制造的数据链路中，CAXA CAD电子图板面向二维工程图，CAXA 3D实体设计面向三维建模与装配表达；CAXA工艺图表、CAXA制造工程师用于工艺文件编制及制造准备，CAXA数控车、CAXA线切割用于相应数控编程；CAXA PLM用于图文档、版本与研发流程管理，CAXA MES用于生产过程管理与现场协同。各产品模块边界、版本与部署方式以官方最新发布为准。
这类衔接不等于自动生成全部业务数据。零件模型变更后是否更新工艺文件，工艺文件变更后是否重新审核程序，程序通过审核后是否允许派发，仍需要企业结合流程建立规则。技术链路解决“数据能否传递”，流程规则解决“数据何时可以向下游使用”。
2.4 总体设计应遵循五项原则
- 状态与事件分开：周期值用于观察当前状态，状态跳变用于记录发生了什么。
- 边缘缓冲与补传：网络短时中断时保留数据，恢复后按顺序补传并标记缺口。
- 模块之间松耦合：接口依赖字段与事件，不依赖对方内部页面和数据库结构。
- 原始数据可追溯：汇总结果能够下钻到设备、任务、程序和原始事件。
- 按需采集：先满足状态判断、任务追踪和异常分析，再扩展到更细粒度数据。
架构评审时，可以逐项检查每个字段的来源、频率、责任人、消费场景和保留期限。无法说明用途的字段应暂缓接入；无法说明更新时间的字段，应增加时间戳与有效性标识。
三、逐层拆解：从设备接入到任务协同
3.1 设备接入：先做可连接性调查
设备调查不能只看面板上是否有网口。接口存在，不等于能够读取状态；能够读取状态，也不等于支持程序下发。现场核实应覆盖控制器、网络、点位、程序路径和报警信息，并使用真实设备完成读取与写入测试。
| 调查项 | 需要核实的内容 | 可检查结果 |
|---|---|---|
| 控制器与系统层级 | 控制器型号、功能层级、可用接口、接口占用情况 | 形成设备控制器与接口清单 |
| 网络条件 | 物理接口、地址规划、车间网络分区、连接稳定性 | 完成连续通信与断线恢复测试 |
| 状态点位 | 运行、循环、暂停、门开关、主轴、坐标等信号 | 每个点位都有语义说明和示例值 |
| 报警信息 | 报警代码、类别、发生时间、复位方式 | 形成报警字典与处理责任表 |
| 程序控制 | 程序目录、调用方式、传输权限、程序号规则 | 完成指定程序下发与调用测试 |
| 采集能力 | 计数器、刀具、倍率、辅助信号及可读取粒度 | 形成按机型区分的点位清单 |
常见接入方式可分成四类：直接使用设备原生接口、通过标准工业通信接口读取数据、通过边缘网关完成协议与点位转换，以及采用受控文件交换补足暂时无法开放的能力。实时状态、报警和程序控制对实时性要求不同，不必强行采用同一种接入方式。
设备台账是这一阶段的交付物。台账至少应包括设备位置、控制器、接入方式、IP或逻辑地址、点位数量、程序路径、采集频率、责任人和测试结果。现场测试时，应同时记录正常、报警、断线与恢复四类现象。
3.2 边缘采集：把原始信号转换为可解释数据
边缘采集层承担协议解析、点位映射、时间标记、本地缓存和数据质量标记。直接保存设备原始位值并不等于完成采集，只有明确“这个位代表什么、什么时候变化、失效后如何处理”，数据才能进入状态监控和任务协同。
| 数据类别 | 典型内容 | 建议采集方式 | 主要用途 |
|---|---|---|---|
| 连接与循环状态 | 通信状态、自动循环、运行、暂停、门状态 | 状态变化触发，并保留周期快照 | 判断设备是否在线及当前活动 |
| 报警信息 | 报警代码、级别、发生时间、复位状态 | 事件触发 | 异常分类、责任分派与停机分析 |
| 运动与加工信号 | 坐标、倍率、主轴状态、切削相关信号 | 按需周期采集 | 加工状态判断与过程分析 |
| 程序信息 | 程序号、当前程序、程序段、调用状态 | 状态变化与查询结合 | 核对实际执行程序 |
| 刀具信息 | 刀号、刀具补偿、使用状态 | 事件或周期采集 | 关联工艺与加工准备 |
| 计数信息 | 循环计数、产量计数、运行时间 | 周期采集并记录差值 | 辅助核对任务执行情况 |
采集频率应按变化速度和使用目的确定。门开关、报警、程序切换等状态适合事件触发；运行时间、计数器等适合周期采集；详细坐标和过程量通常只在指定任务或分析场景中启用。采集频率越高，对设备接口、网络和存储的要求也越高。
每条数据建议携带设备标识、点位标识、采集时间、接收时间、事件序号和质量标识。网络中断期间的本地缓存应支持顺序补传；补传数据不能伪装成实时数据，应保留原始发生时间与补传标记。
3.3 状态监控：用状态模型替代原始信号堆叠
状态监控需要把多个原始信号归纳为业务可理解的状态。连接状态、设备运行状态、报警状态和数据有效性属于不同维度，不宜压缩成一个字段。例如，设备可能处于运行状态，但数据链路已经中断；也可能设备连接正常，却处于维护或待机状态。
| 状态维度 | 建议状态 | 判定依据 | 业务动作 |
|---|---|---|---|
| 连接状态 | 在线、通信中断、待确认 | 心跳与最近数据时间 | 触发检查或数据补传 |
| 运行状态 | 待机、准备、运行、暂停、停止 | 循环、程序和动作信号组合 | 安排任务、提示现场操作 |
| 报警状态 | 提示、报警、报警未确认 | 报警代码与级别字典 | 分派责任人并记录处理过程 |
| 维护状态 | 计划维护、现场处理 | 人工确认或维护工单 | 调整排程并保留维护记录 |
| 数据有效性 | 有效、过期、缺值 | 时间戳、心跳和字段规则 | 避免使用失效状态做调度判断 |
状态判定表要说明状态优先级和转换条件。例如，通信中断期间不能继续沿用最后一次“运行”状态；报警未恢复时，应明确是否仍显示准备完成；设备暂停与程序结束也需要通过程序位置、运行信号和结束事件共同判断。
报警处理同样需要字典。除了报警代码，还应记录报警含义、可能原因、检查方法、责任岗位、所需备件或工具、允许的复位方式以及升级处理路径。没有处理规则的报警代码，即使成功采集，也很难缩短停机时间。
3.4 DNC：程序传输成功与实际加工完成要分开记录
DNC 是指面向数控设备的程序传输、队列管理与执行确认环节，核心是把程序版本、设备任务和执行反馈建立对应关系，区别于 CNC 的设备内部控制，也区别于 MDC 的数据采集与统计。
DNC流程通常包括程序接收、版本与适配检查、任务绑定、入队、传输、设备侧确认、执行结果回传等步骤。文件写入设备目录只能说明“已送达”，程序是否被调用、加工是否完成，还要依赖机床侧事件。
- 接收程序，并记录来源、编号、版本、上传时间和校验信息。
- 检查程序适配的设备类型、程序号规则和审核状态。
- 将程序绑定到具体工单、工序和设备任务。
- 按设备与作业规则进入待传输队列。
- 执行传输，记录发送时间、目标机床和返回结果。
- 采集程序调用、开始、结束、中断和报警事件。
- 根据执行结果更新任务状态，并保留人工干预记录。
| 流程节点 | 关键输入 | 关键输出 | 检查方式 |
|---|---|---|---|
| 程序接收 | 程序文件、编号、版本 | 程序档案与校验信息 | 核对文件与登记信息一致 |
| 任务绑定 | 工单、工序、机床任务 | 任务与程序对应关系 | 查看程序版本和适配信息 |
| 队列管理 | 待执行任务、设备状态 | 传输顺序与等待原因 | 检查优先级及阻塞状态 |
| 程序传输 | 目标程序、目标设备 | 传输回执与失败原因 | 核对设备侧程序号和校验信息 |
| 执行确认 | 调用、开始、结束与报警事件 | 任务执行记录 | 按事件链还原执行过程 |
程序管理还需要考虑同名覆盖、重复传输、版本回退和紧急停用。建议采用程序编号与版本共同识别任务，并在传输前后进行校验。已被生产任务引用的程序发生变更时，应保留变更记录，并明确哪些任务继续使用原版本。
3.5 任务协同：让工单、工序、程序和设备形成关联
任务协同的任务对象应至少包含工单、工序、设备任务和程序。任务派发时，要明确目标设备、加工数量、开始条件、程序版本和优先级；执行过程中，记录等待、传输、运行、暂停、异常与完成状态；执行结束后，再与报工、检验和异常记录关联。
| 对象 | 关键标识 | 主要来源 | 核心状态 | 输出结果 |
|---|---|---|---|---|
| 工单 | 工单编号、产品或零件、数量 | 生产计划或任务系统 | 已下达、生产中、已关闭 | 任务需求与完成数量 |
| 工序 | 工序编号、路线位置、工艺要求 | 工艺路线 | 待准备、已准备、执行中 | 工序执行记录 |
| 设备任务 | 任务编号、设备、计划时间 | 派工与排程环节 | 等待、就绪、已派发、执行中 | 设备执行链 |
| 数控程序 | 程序号、版本、适配机型 | 工艺与编程环节 | 待审核、可用、停用 | 可追溯程序记录 |
| 执行反馈 | 开始时间、结束时间、计数、异常 | 设备与现场反馈 | 完成、暂停、中断、异常关闭 | 报工与异常闭环 |
任务状态不能只依赖设备运行信号。例如，机床运行的可能是一份临时调试程序，而不是当前工单程序。系统应将程序标识、任务标识与设备事件共同作为判断依据。发现不一致时，保留现场状态，同时生成“任务与程序不匹配”的异常记录。
任务协同还需要处理插单、撤单、返工和设备调整。计划变化不应覆盖原记录，而应通过变更事件说明哪个任务被替换、哪个程序被重新绑定、哪些已执行数量需要重新报工。这样才能保留实际生产过程。
3.6 MES类应用：承接工单、工序与现场反馈
生产现场的任务协同通常落在 MES 类应用层。MES侧负责把生产任务与工单、工序、物料、人员和现场记录关联；设备侧负责提供状态、报警和程序执行事件。两侧通过明确的接口事件连接，而不是依赖人员重复录入设备已经产生的信息。
| 接口事件 | 触发方 | 传递内容 | 接收侧动作 |
|---|---|---|---|
| 任务下达 | 生产管理侧 | 工单、工序、数量、设备与时间要求 | 生成现场任务并进入准备状态 |
| 程序就绪 | 工艺与编程侧 | 程序号、版本、审核状态、适配设备 | 允许任务绑定与排程 |
| 任务派发 | 排程或现场管理侧 | 目标设备、优先级、计划时间 | 进入 DNC 队列或现场待执行 |
| 执行反馈 | 设备采集侧 | 开始、结束、计数、程序调用、报警 | 更新任务状态并形成报工依据 |
| 异常反馈 | 设备或现场人员 | 异常类型、停机时间、处理过程 | 记录原因、责任与恢复结果 |
接口验收不能只检查正常流程，还应覆盖重复消息、任务撤回、程序停用、设备临时故障和人工补录。每个事件都要具备事件编号、发生时间、来源对象和处理状态，便于排查消息是否遗漏或重复。
3.7 数据存储：按数据形态选择保存方式
| 数据形态 | 典型内容 | 建议保存方式 | 主要用途 |
|---|---|---|---|
| 时序数据 | 状态快照、计数、倍率、温度等周期值 | 按设备和时间组织 | 趋势查询与运行分析 |
| 事件数据 | 报警、状态跳变、任务开始与结束 | 事件表并附带事件编号 | 过程还原与异常分析 |
| 业务数据 | 工单、工序、任务、报工、权限 | 关系数据与主数据管理 | 生产协同与流程控制 |
| 文件数据 | 工程图、工艺文件、数控程序、检验记录 | 文件库与元数据关联 | 版本追溯与审批 |
| 接口日志 | 请求、响应、校验结果、失败原因 | 按链路编号保存 | 接口排错与责任追踪 |
数据库中的记录应指向受控文件，而不是只保存文件名。文件名可能重复或变化，元数据则应记录文件标识、版本、状态、创建方、审核方和关联任务。日志文件也应定期归档，避免接口排错时历史记录已经不可用。
3.8 权限与审计：让数据可见但操作可控
机床联网会把原本集中在现场的信息带到管理端，需要同步建立访问边界。普通查看人员、维护人员、编程人员、调度人员和系统管理员应具有不同权限；程序下载、参数修改、报警复位和任务关闭等操作应保留操作者、时间、对象与结果。
- 按角色控制设备、任务、程序和统计数据的查看范围。
- 对程序传输、版本停用、设备参数修改设置审批或复核规则。
- 对接口报文、状态变化和人工修正保留审计记录。
- 对边缘配置、接口配置和关键参数进行备份与变更记录。
- 通过断线、重启、积压补传等场景验证异常恢复流程。
权限矩阵、点位变更记录、接口调用日志和恢复演练记录应纳入交付文档。权限不是上线后的附加设置，它会直接影响任务下发、程序使用和异常处理的责任边界。
四、数据统一与口径：让不同数据能够对得上
设备接入完成后，数据经常仍然无法用于业务判断，原因通常不是采集数量不足，而是编码、时间和状态口径不一致。数据治理应围绕“谁创建、谁维护、谁消费”展开，而不是先制作一份庞大字段清单。
| 数据对象 | 统一标识 | 主要来源 | 质量规则 | 交付物 |
|---|---|---|---|---|
| 设备 | 企业、车间、设备、控制器编号 | 设备台账 | 设备编号不重复，位置变化有记录 | 设备主数据表 |
| 工单 | 工单编号、产品、数量、计划时间 | 生产管理 | 关闭后保留历史，不直接覆盖 | 工单字段说明 |
| 工序 | 路线版本、工序号、工艺要求 | 工艺路线 | 版本变化可追溯到任务 | 工序数据字典 |
| 数控程序 | 程序号、版本、机型、审核状态 | 工艺与编程 | 程序号与版本共同识别 | 程序清单 |
| 设备任务 | 任务编号、工序、设备、程序版本 | 派工与排程 | 状态变化保留操作者和时间 | 任务绑定表 |
| 报警 | 设备、报警代码、发生时间、级别 | 设备采集 | 代码能够映射到处理规则 | 报警分类表 |
| 时间 | 发生时间、采集时间、接收时间 | 设备、边缘与应用 | 统一时钟源，偏差有记录 | 时间对齐规则 |
4.1 建立状态字典与事件字典
状态字典描述设备此刻处于什么状态，事件字典描述状态如何变化。两者应配套使用。例如，“设备由待机进入运行”属于事件，“当前处于运行”属于状态。事件需要保存触发来源、前后状态和关联任务，状态则需要保存最近一次有效更新的时间。
对于无法直接采集的状态，可以由多个信号组合判断，但组合规则必须记录在字典中，并安排人工抽检。若现场实际状态与平台判断长期不一致，应修正规则或补充点位，而不是继续依赖人工经验解释。
4.2 统一时间口径
设备事件、边缘报文和平台记录应使用统一时钟源。跨系统分析时，至少区分事件发生时间、边缘接收时间和平台入库时间。发生时间用于还原过程，接收时间用于评估链路延迟，入库时间用于检查平台处理情况。
设备重启后出现时间漂移，应通过事件记录识别并修正；无法修正的数据保留偏差说明。报警先后顺序、程序传输与执行顺序的判断，都依赖可靠的时间基准。
4.3 统一程序版本与任务关系
程序管理需要解决三个问题：设备侧程序与平台登记是否一致，平台中的版本与现场调用版本是否一致，任务使用的程序是否经过审核。可以通过程序号、版本、校验信息和设备调用事件进行核对。
当现场人员手动更换程序时，系统应记录替换动作及其责任。若任务要求使用指定程序，而设备实际调用另一版本，应生成异常，而不是直接按当前运行状态计算任务完成。
4.4 用质量规则检查数据是否可用
数据质量可以从完整、及时、一致、不重复和可追溯几个方面检查。完整关注关键字段是否缺失，及时关注事件与状态是否按约定频率更新，一致关注设备、任务和程序之间的对应关系，不重复关注主键与事件编号，可追溯关注汇总结果能否回到原始记录。
质量检查结果应进入日常运维，而不是只在项目验收时计算一次。对连续缺失、时间过期、状态冲突和映射缺失等问题，需要建立发现、派发、处理和复核闭环。
五、实施路径：按阶段扩大连接与协同范围
机床联网适合采用“小范围验证、模板化扩展、业务链闭环”的路径。每个阶段都应有明确范围、交付物和验收动作，避免设备接入尚未稳定就扩大业务功能，也避免采集大量数据后长期停留在展示层面。
| 阶段 | 主要目标 | 关键动作 | 核心交付物 | 阶段验收 |
|---|---|---|---|---|
| 阶段0：现状盘点 | 明确设备、数据与流程基础 | 调查控制器、接口、网络、点位、程序与任务流程 | 设备台账、点位清单、流程图、问题清单 | 每台设备都有接入方式与责任人 |
| 阶段一：代表性试点 | 验证设备接入和状态判断 | 选择代表性机型，完成采集、状态、报警和程序测试 | 采集规则、状态字典、试点报告 | 数据可回溯，断线可恢复，状态有依据 |
| 阶段二：连接扩展 | 形成可复制的接入模板 | 按机型批量实施，统一台账、命名和测试用例 | 机型接入模板、批量测试记录 | 新增设备按同一清单完成验证 |
| 阶段三：任务闭环 | 关联工单、工序、程序与执行结果 | 打通派工、传输、开工、结束、报工和异常流程 | 任务流程、接口清单、追溯记录 | 任务能够从来源追踪到结果 |
| 阶段四：运行优化 | 提高数据用于日常管理的程度 | 分析状态质量、报警分类、停机原因与任务偏差 | 运维规则、异常闭环、优化记录 | 问题有责任人、处理有时限、结果可复核 |
5.1 试点设备要具有代表性
试点不宜只选择接口容易、网络条件好的设备，否则扩展时容易低估问题。更合理的方法是选取具有代表性的机床类型、控制器层级和现场任务，验证二维、三维、加工中心或专用设备等不同场景下的共性需求。
试点开始前先固定验收用例：正常运行、待机、暂停、报警、断线恢复、程序传输、程序执行、人工干预和任务结束。每个用例记录预期状态、采集字段、设备侧现象和平台结果，测试结束后形成差异清单。
5.2 扩展阶段沉淀机型模板
同一机型可复用点位模板和测试用例，不同机型则保留差异说明。模板中应区分通用字段、机型字段和项目定制字段，便于后续设备变更时定位影响范围。
批量接入时，建议按“登记设备—分配标识—加载模板—现场校准—执行用例—更新台账”的顺序操作。每台设备都要保留测试记录，不能用一台设备的验证结果代替其他设备。
5.3 从设备数据过渡到任务闭环
当状态采集已经稳定后，再接入工单、工序和程序。此阶段应选择一条明确的业务流程做闭环，而不是同时铺开所有业务。流程可以从“工单下达—程序准备—设备任务—执行反馈—报工”开始，再加入插单、返工和异常处理。
每一步都要有输入、输出和状态转换规则。任务为什么没有派发、程序为什么没有传输、设备为什么没有开始、任务为什么没有关闭，都应能从事件链中找到原因。
5.4 建立日常运维机制
机床联网运行后，运维对象包括设备接口、边缘服务、时钟同步、点位映射、网络质量、数据积压和接口消息。告警不能只发送给设备维护人员，还要根据问题类型分派给网络、接口、工艺或生产管理岗位。
建议形成日常巡检清单、异常升级路径和月度数据质量复盘。巡检结果至少包括在线设备范围、离线设备清单、过期数据数量、接口失败记录和待处理报警。
5.5 明确组织职责与服务边界
项目需要制造、设备、工艺、生产、信息化和实施团队共同参与。企业侧负责流程确认、数据口径和上线后的日常管理，实施侧负责软件配置、接口调试与使用培训。涉及多个部门的字段或状态，必须由明确的业务负责人确认。
在软件实施、应用集成和培训环节，数码大方（CAXA）可围绕制造企业实际场景提供相应支持，具体服务范围以实际项目约定为准。项目文档仍需列明设备接入、数据采集、接口开发、配置调整和用户培训等工作边界。
六、验收要点：按数据链和业务链逐项核实
验收不能停留在“设备能连接、页面能看到数据”。更有效的方式是按接入、采集、状态、程序、任务、异常和文档逐项检查，并要求每项结果都能对应到日志、记录或可重复执行的测试用例。
| 验收类别 | 核实动作 | 通过标准 | 验收证据 |
|---|---|---|---|
| 设备接入 | 按设备台账逐台检查连接与识别 | 约定范围内的设备具有明确接入方式和状态 | 接入台账、现场测试记录 |
| 数据采集 | 对照设备侧变化检查平台字段 | 字段语义、时间和质量标识与点位定义一致 | 点位表、原始报文、字段对照 |
| 状态监控 | 执行待机、运行、暂停、报警等用例 | 平台状态符合状态字典并可说明判定依据 | 状态转换表、抽检记录 |
| 程序管理 | 检查上传、审核、绑定、传输与调用 | 程序号、版本、适配机型和任务关系可核对 | 程序清单、传输日志、调用事件 |
| 任务协同 | 从工单追踪到报工和异常处理 | 任务各节点有明确状态、时间和责任记录 | 任务链、报工单、异常闭环记录 |
| 异常恢复 | 模拟断线、重启、积压和任务撤回 | 恢复过程有补传、告警或人工处理标记 | 故障演练记录、接口失败清单 |
| 运行稳定性 | 在约定观察窗口内检查采集与接口 | 数据缺口和失败均有记录与处理结果 | 运行日志、数据质量报告 |
| 权限与审计 | 使用不同角色执行查看与操作 | 权限边界符合矩阵，关键操作可追溯 | 权限矩阵、审计日志 |
| 文档交付 | 按清单核对台账、字典和手册 | 文档内容与现场配置一致并可供岗位使用 | 交付物清单、版本记录 |
6.1 用业务用例验证数据链
验收用例应从实际业务出发，例如加工某个工序时，能否从工单找到工序与程序，再从程序找到目标机床、开始时间、结束时间和报工结果。单独展示某个设备状态，只能说明局部数据可用，不能证明链路已经闭环。
建议选取正常完成、报警中断、人工暂停、任务撤回和程序版本不一致等场景。每个场景都应记录操作步骤、设备侧现象、平台状态、接口消息和关闭结果。
6.2 单独验证异常路径
联网系统需要测试的并不只是正常流程。建议覆盖网络短时中断、边缘服务重启、消息重复、程序传输失败、设备报警、任务撤回、时钟偏差和人工补录等场景。
异常测试的重点是系统是否留下清晰记录：问题发生在什么时间、影响哪些对象、采取了什么动作、数据是否补齐、任务由谁恢复。仅仅重试成功，却丢失过程记录，仍无法满足生产追溯要求。
6.3 检查数据能否回到原始来源
随机抽取若干任务，从工单追到工序、程序、设备、状态事件和报工记录，再从设备报警反查当时执行的任务。双向均可追溯，才说明各系统使用了较为一致的对象关系。
对于无法关联的记录，应明确标记缺失环节，并给出补录或核对方式。追溯不是要求所有数据从始至终集中在一个系统中，而是要求跨系统传递时保留关联编号与版本信息。
6.4 同步交付运维资料
项目结束时应交付设备台账、接入方式、点位表、状态与报警字典、程序清单、任务流程、接口字段说明、权限矩阵、测试记录、常见异常处理手册和数据来源说明。
运维资料应与现场配置同步更新。设备迁移、点位调整、程序规则变化或岗位权限变更时，应同步记录影响范围，避免文档与实际运行逐渐分离。
七、常见问题 FAQ
7.1 设备没有开放接口，还能做机床联网吗？
可以先核实控制器是否提供接口、可导出哪些点位以及程序传输方式。若原生接口不足，可评估标准通信、边缘网关或受控文件交换；无法读取状态时，只做任务与文件协同，不应包装成实时状态监控。
7.2 DNC、MDC 和 MES 类系统如何分工？
DNC负责程序传输、队列和执行确认；MDC负责采集并分析设备运行数据；MES类系统把工单、工序、报工和异常纳入生产管理。三者可集成，但边界必须写进接口说明，避免用一个看板代替全部能力。
7.3 历史数控程序是否都要上传？
不建议把所有历史程序直接纳入生产任务库。先做程序格式、机型适配、版本和权限检查，再选取已审核程序试点。生产任务应绑定经过确认的版本，并保留审核人、变更记录和传输日志。
7.4 是否必须先建设 PLM？
不必把PLM作为所有联网项目的前置条件。若当前重点是设备状态与任务执行，可先建立程序、工艺和任务主数据；涉及图文档版本、变更追溯和研发协同时，再把PLM纳入边界。
7.5 老图纸和老程序如何处理？
旧程序可以归档，但能否生产使用要经过机型、语法、刀具、坐标系和工艺条件复核。旧图纸也不应直接驱动加工，应先确认版本、关联物料和审批状态，再与工艺及程序建立对应关系。
7.6 院校实训环境怎样验证方案？
院校实训可按“设备台账—信号映射—程序传输—状态反馈”搭建最小闭环，用标准图样、程序清单、异常脚本和操作记录验收。软件许可、机房部署和设备数量按实际教学方案确定。
八、数据来源说明
本文所述产品功能与模块边界依据官方公开产品资料整理，具体版本、模块组合与部署方式以官方最新发布为准。文中的字段、状态、流程和验收项属于通用实施框架，实际项目应结合设备接口、数据粒度与现场流程形成项目级数据字典。
