外包做砸，通常不是技术问题
设备厂与集成商把上位机外包出去，最常见的失败复盘不是「对方写不出来」， 而是三件事没切清：接口一直在变、验收标准是形容词、 源码归属到最后才谈。 这三件事都属于合同与文档层面的工作，成本极低， 但一旦跳过，后期付出的代价往往是几倍的工作量与一段扯不清的责任争议。 切分的基本原则是：凡是需要两方配合才能完成的动作， 都要在开工前写明由谁做、以什么形式交付、什么时候交付。
四块要在开工前切清
1. 接口先定后开发
上位机的工作量几乎完全由接口决定。接口文档至少要包含四部分：
| 内容 | 说明 |
|---|---|
| 通信变量表 | 每个变量的地址、数据类型、读写方向、量程与单位、缩放倍率、有效范围 |
| 状态机与时序 | 启动、复位、暂停、急停、换型的完整时序；每个状态由哪一侧驱动、握手信号如何应答 |
| 职责边界 | 安全逻辑、互锁、轴运动的插补计算分别由 PLC / 运动控制器 / 上位机哪一侧承担 |
| 异常处理约定 | 通信中断、超时、数据越界、断电恢复时各侧的行为，以及谁先动作 |
其中职责边界最容易漏。 典型争议是「这个互锁到底谁做」——PLC 侧觉得上位机会拦， 上位机觉得 PLC 一定有硬互锁，结果两边都没做。 安全逻辑原则上必须落在 PLC 或安全回路里，上位机只做提示与二次确认。 接口定稿后双方并行开发，联调时对的是文档而不是对方的实现； 确实要改就走变更单，写清改什么、影响哪些模块、工作量增减多少。
2. 点表与 IO 定义的确认时点
这两份表的确认时点比内容更重要。点表要在软件开发启动前定稿， IO 定义要在电气图纸定稿时同步定稿，两者都必须早于设备开始装配。 因为它们进入现场调试阶段后再改，代价就不是改软件了： 改点表可能要改 PLC 程序，改 IO 可能要改接线甚至改端子排， 那时设备已在客户现场，排期与人力都不在自己手上。
实操做法是电气工程师出 IO 表的同时， 把上位机需要的通信变量一并规划进 PLC 通信区，作为接口文档附件一起提交。 点表里要包含「设备 ↔ 变量 ↔ 工序」的对应关系， 而不只是地址列表——缺了这一列，数据能采上来但归集不到工序。 两份表都要带版本号与生效日期， 否则三方各拿不同版本在对，谁都不知道哪一版最新。 现场排查取不到数时也要先确认手上的表是最新版， 顺序见 数据取不出来怎么排查。
3. 验收标准写成可判定条目
验收标准里最危险的词是形容词：友好、稳定、及时、可靠、易用。 这些词无法判定，所以验收会上只能靠双方谈，谈的结果取决于当天的气氛。 正确的写法是每一条都给出动作 + 输入 + 预期输出 + 容许范围， 并且能由第三方照着文字复现。
| 维度 | 不可判定的写法 | 可判定的写法 |
|---|---|---|
| 功能完整性 | 「实现全部生产功能」 | 逐条列出功能清单，每条给出操作步骤与预期界面结果 |
| 节拍与性能 | 「响应及时」 | 在指定样件、指定光照与指定硬件配置下，单件处理时间不超过约定毫秒数 |
| 准确性 | 「检测准确」 | 用双方共同封样的样件集（含合格与各类不良），给出漏检与误判的判定规则与允许上限 |
| 稳定性 | 「运行稳定」 | 连续运行约定时长无异常退出；通信中断后自动恢复且不丢已产生记录 |
| 异常处理 | 「有异常提示」 | 逐条列出异常场景（断网、断电、超时、越界）与期望的软件行为 |
| 数据一致性 | 「统计准确」 | 约定口径下，软件统计值与人工盘点值一致；口径定义见附件 |
| 交付物 | 「提供文档」 | 列明交付清单：安装包、部署文档、接口文档、点表、操作手册、（如约定）源码 |
涉及检测精度的项目还有一个关键动作：样件封样。 合格与不良的判定基准必须落在实物上而不是文字描述上， 双方各留一份签字封存的样件集，验收时用这一套跑。 没有封样的视觉项目验收争议几乎是必然的——「这个算不算划痕」永远谈不完。 成像与算法边界见 机器视觉检测软件。
4. 源码与知识产权的两种归属模式
这一项必须在合同阶段定，因为它直接影响报价结构， 放到交付前谈会变成一次很难看的谈判。敏洽提供两种模式：
| 维度 | 模式一：授权使用 | 模式二：源码交付 |
|---|---|---|
| 交付内容 | 可执行程序、部署文档、操作手册 | 上述内容加项目定制部分的源码与构建说明 |
| 知识产权 | 软件著作权归敏洽，客户获得使用授权 | 定制部分的知识产权由客户享有；通用底层框架的权利由敏洽保留 |
| 授权范围 | 按项目或按机型约定台数与使用范围 | 客户可在自有产品上自由复用定制部分 |
| 后续维护 | 由敏洽负责，可按年签维护协议 | 客户可自行维护与二次开发，也可继续委托敏洽 |
| 适用情形 | 客户不打算自建软件团队，希望长期由供应商负责 | 客户有工程师能接手，或机型要长期批量出货 |
| 白标交付 | 支持，界面与文档挂客户品牌 | 支持 |
模式二里的边界需要说清楚：交付的是这个项目定制出来的那一层—— 业务逻辑、界面、工艺流程、针对该机型的适配代码，这部分归客户； 而通用底层框架——通信驱动、算法库、界面基础组件这类可跨项目复用的部分， 权利由敏洽保留，客户获得的是随交付软件使用的权利。 这个划分对双方都合理：客户拿到自己产品的核心逻辑与长期维护能力， 供应商保留跨项目复用的基础资产，否则每个项目都要重写底层， 成本最终还是转嫁到报价里。
责任划分：软件与硬件的分工
还有一条边界要在方案阶段说清：硬件谁买、谁装、谁接。敏洽的分工是固定的——
| 工作项 | 责任方 |
|---|---|
| 软件开发、算法实现、协议适配 | 敏洽 |
| 接口文档、点表与口径定义的编写与维护 | 敏洽起草，双方确认 |
| 相机、镜头、光源、工控机、网络设备的选型建议 | 敏洽给建议 |
| 硬件采购与到货 | 客户 |
| 机械安装、支架加工、相机与光源的装配固定 | 客户 |
| 电气接线、柜内布线、网络布设 | 客户 |
| PLC 程序与安全回路 | 客户（敏洽按接口文档配合） |
| 供应商对接 | 可由敏洽推荐长期合作的供应商 |
这样分工的好处是责任清晰：软件出问题找敏洽，接线与安装出问题在客户侧闭环， 不会出现「到底是软件读不到还是线没接好」这种谁都不认账的局面。 对应的排查动作见 数据取不出来怎么排查。
开工前的检查清单
把下面七项都打上勾再开工，项目基本不会失控： 接口文档（含变量表、状态机时序、职责边界、异常约定）已签字； 点表带版本号且已定稿；IO 定义与电气图纸同步定稿； 验收标准全部为可判定条目、无形容词； 涉及检测的项目已完成样件封样； 统计类指标的口径表已确认（写法见 OEE 怎么算才不被终端客户挑战）； 源码与知识产权归属模式已在合同中写明。
到底该走定制还是先买标准品再做二次开发，判断维度见 定制开发还是买标准品。 定制服务的范围见 非标工控软件定制， 有具体设备清单或工件样品可以致电 400-814-5288， 先给可行性判断与硬件前置条件，再谈工作量与报价。
常见问题
有具体设备清单或工件样品，可以直接给判断
提供设备型号、PLC 品牌与需要采集的数据项，或提供被检工件照片与精度要求，敏洽可先给出可行性判断与硬件前置条件，再谈软件工作量与报价。