1 制造与工业互联网方案要回答什么
零售订单 API 接到订单后，通常要保存订单、返回受理结果，并让顾客查询履约进度。当商品需要生产或包装时，这条业务链会延伸到工厂：订单关联工单，工单进入产线，设备报告完成数量，生产结果再回到订单页面。这里出现了新的约束。订单页面短暂显示旧进度可能还能补偿，设备在错误时刻执行动作却可能损坏物料，甚至危及人员。架构方案必须先说明每类行为由谁负责，不能把整条链都当成普通网页请求。
本课延续零售订单 API 案例，假设某零售业务销售可按单组合的商品，工厂负责组装与包装。订单服务承诺可靠受理，生产系统负责排产与工单，现场控制系统负责设备动作。我们要设计的是订单与生产之间的协作和状态回传，不重新设计机器的安全控制。生产是否可以离线继续、完成事件多久出现在查询结果中、断网后怎样补齐记录，都会影响方案选择与验收。
需求访谈应从可观察的结果开始。业务人员关心订单何时能显示“已包装”，现场人员关心网络故障时机器是否还能按既定工单运行，运维人员关心积压怎样发现和恢复。把“实时上云”拆成具体问题：数据从哪里产生，允许多旧，丢失是否可接受，动作最迟何时完成。相同的“实时”可能分别指 10 ms 内完成本地动作、5 s 内更新生产看板、60 s 内更新订单进度，不能共用模糊承诺。这些数值只是需求示例，实际期限必须由工艺与业务共同确认。
初步需求表至少应记录对象、期限、失败后果和责任人。例如，订单受理由订单服务负责；工单执行前置条件由生产系统和现场共同确认；设备安全停止由合适的本地安全机制负责；生产状态回传由边缘与云端数据链负责。画清这些边界后，才讨论部署位置、网络线路和服务数量。否则方案图虽然连通，故障时却找不到能作出决定的人。
2 OT/IT 融合与时延
OT 通常指用于监测和控制物理过程的运行技术，IT 通常指处理业务信息的信息技术。它们不是按“老设备”和“新软件”划分，而是关注的对象不同。生产控制面对温度、位置、速度和设备状态，订单系统面对订单、库存和履约承诺。融合意味着有边界地交换信息，让订单知道生产进展，让生产获得已确认的业务任务，并不意味着把所有控制逻辑搬到订单服务中。
理解时延时，要同时看期限与波动。平均 20 ms 的链路，如果偶尔需要 2 s，就不能据此承诺每次都满足 100 ms 的要求。对于具有严格动作期限的环节，需要由适当的控制系统和工程验证保证行为；本课不展开控制算法与实时调度。对于进度上报，可以采用允许短暂延迟的异步方式，用事件时间和状态新鲜度解释结果。不要因为界面上每秒刷新，就认为底层数据每秒都完成了可靠采集。
把端到端等待拆开，会发现它不只等于网络传输时间。设备可能要等待下一次采样，协议网关可能排队，边缘可能批量发送，云端可能等待消费，订单查询还可能读取尚未更新的进度视图。方案应分别注明采集周期、各段处理时间和允许积压。只有各段边界明确，才能判断是需要提高采集频率、减少批量等待，还是接受订单侧稍旧的数据。
时间字段也要区分含义。设备事件时间表示现场发生时刻，边缘接收时间表示接入侧看到数据的时刻，云端保存时间表示记录已进入远端持久存储。设备时钟可能漂移，旧设备也可能根本不提供可靠时间。此时可以保留边缘采集时间，并附上时间来源和质量标记，不能把接收时刻伪装成精确的发生时刻。跨设备比较时间前，应先确认时钟同步条件；诊断单段耗时时，优先使用该段可靠的耗时测量。
对零售订单 API 来说，返回“已受理”只说明订单已经按约定保存，并不代表产线已经启动。查询响应可以包含生产阶段、最近事件时间、更新时间和过期标记。超过约定的新鲜度阈值时，明确显示“进度待同步”，避免把没有新事件解释为生产停止，也避免把旧的“运行中”当作现场实时状态。这样做把数据链的可用性与生产本身的运行状态区分开来。
3 采集、边缘与回传
典型路径从设备状态开始，经协议采集进入边缘节点，再通过工厂出口回传云端。边缘节点位于现场附近，承担设备适配、数据校验、必要的格式转换和断网缓存。它不因名字叫“边缘”就自动拥有实时性，也不天然适合接管安全控制。是否能够部署某项功能，应由它的期限、资源、故障影响和维护条件决定，而不是由部署位置的名称决定。
采集首先应约定数据语义。某个寄存器中的 125 可能代表 12.5 ℃，也可能表示累计件数；“完成”可能指加工结束，也可能指包装完成。应记录设备标识、字段含义、单位、缩放规则、质量状态与采集方式。面向订单的完成事件还需要工单号和批次等业务关联。不能只凭设备当前值突然增加，就直接认定某个订单已经完成，因为换班、重置计数器和工单切换都可能改变解释。
边缘缓存需要明确写入与确认边界。较容易解释的约定是：事件先进入本地持久缓存，再发送；云端确认事件已持久化后，边缘才按保留策略释放相应空间。传输失败可以重试，因此云端可能收到重复事件。设备标识与稳定事件序号可以组成事件身份，云端据此去重，再更新订单进度。重试时必须沿用原事件身份，不能每次重新生成身份，否则重复记录会被误认为新的生产成果。
还要处理重启、乱序和补传。边缘重启后应能找到未确认事件；旧事件补传到达时，不能把订单从“已包装”退回“加工中”。进度更新需要依据工单、阶段规则和事件顺序判断，必要时保存原始事件供追溯。若设备只提供瞬时状态，断线期间发生的短暂变化可能永远无法补采，因此“有本地缓存”并不等于“任何数据都不会丢”。应明确缓存起点之前是否存在不可恢复的采集缺口。
回传容量也不是越大越好。诊断波形、普通状态和订单完成事件的价值不同，可以采用不同采集频率、保留期限与发送优先级。减少无业务价值的高频原始数据，通常比无条件扩容更有效，但涉及质量追溯的关键记录必须按实际要求保留。方案应说明哪些数据可以聚合，哪些事件必须逐条保存，以及缓存接近满载时由谁决定限制采集、扩容或进入受控运行状态。
4 动手：画一条产线数据路径
现在用纸或绘图工具画出订单与包装线之间的数据路径。先写下具体需求：订单已经可靠受理后，由生产系统形成工单；现场按已确认工单作业；正常情况下，包装完成事件在 60 s 内可供订单查询；外部网络中断 4 小时时，已确认任务能否继续由现场运行规程决定，同时事件应在约定容量内保存。这些是假设条件，不能把它们理解为任何工厂都适用的默认指标。
图上放置设备、本地控制器、协议采集、边缘缓存、工厂出口、云端接入、事件保存、进度处理与订单 API。将本地控制回路单独圈出，再画状态回传箭头。工单下发使用另一种线型，并标明审核、确认和权限边界。订单 API 不应直接写设备寄存器；如果业务需要远程改变生产任务，应经过生产系统与现场授权流程，执行结果也应另行确认，不能把网络发送成功当成设备执行成功。
接着为每条箭头补充 4 项信息：传什么、多久传、失败怎样处理、谁负责恢复。设备到采集侧可能是周期读取，也可能是设备主动报告；边缘到云端通常需要认证、加密与受控出口；事件保存到进度处理需要说明重试和去重。协议名称可以先写成“设备协议，待现场确认”，但不能把未知协议默认为支持并发、可靠时间戳或事件回放。把未知项显式列出，比画出未经验证的能力更有用。
再做容量草算。假设每秒 500 条事件，每条平均 1 KB，断网 4 小时产生 7200000 条事件，原始数据约 7.2 GB。若暂按 1.5 的预留系数规划，则需要约 10.8 GB 缓存空间。这里采用十进制单位，只计算事件数据；索引、日志、文件系统、存储寿命和异常增长还要另行评估。不要把磁盘标称容量全部承诺给业务缓存，也不要忽略现场可维护的剩余空间。
恢复后的上传能力必须覆盖新数据和历史积压。如果总能力是每秒 1000 条，而新事件仍为每秒 500 条，净清空能力只有每秒 500 条，清空上述积压还需约 4 小时。总能力等于新事件速率时，积压不会减少。用滑块改变断网时间和上传能力，观察恢复窗口如何变化，再把估算中的事件大小与速率换成现场测量值。这个练习的产物应是带假设的数据路径图与容量表，而不是孤立的网络拓扑。
最后在图旁写出可验证的问题：边缘断电后事件是否仍在，重复补传是否会重复增加完成数量，工单切换时如何关联，旧事件会不会覆盖新进度。每个问题都应落到某个节点和某位负责人。只要还有箭头没有失败处理说明，方案就仍缺少运行条件，不能仅以“接口已打通”作为验收结果。
5 实时控制与云弹性取舍
云端适合承担跨产线汇总、历史分析、订单查询和可弹性扩展的事件处理。活动期间订单查询增加，可以扩展查询服务；恢复补传造成事件流量上涨，也可以在合理限制内增加处理能力。然而，扩展云端实例不能消除设备采样等待，也不能保证跨外网链路在每次请求中满足严格动作期限。部署选项必须对准真正的瓶颈和失败后果。
可以比较 2 个选项。选项 A 让云端参与每次设备动作判断，集中管理容易理解，但每次动作都依赖往返链路与远端服务，需要额外解决失联时的执行与安全问题。选项 B 让本地控制器执行已确认任务，边缘异步回传事件，云端处理订单与分析。对于本课的订单进度场景，选项 B 更符合职责边界，但会增加现场缓存、软件维护和补传治理的工作。选择必须同时写出收益和代价。
架构决策记录，简称 ADR，可以按问题、备选、决定、理由、代价和复审条件组织。这里的决定可以写为：生产动作由本地控制系统执行，订单进度采用异步事件同步；外网中断期间，订单侧显示最后已知进度与过期提示；能否继续生产按现场批准的条件判断。理由是动作期限和失联后果不适合依赖订单 API 的可用性。代价包括边缘设备、现场运维、事件一致性治理以及恢复演练。
成本比较应覆盖整个使用周期。除了云端计算与存储，还要计算网关购置和备件、现场安装、网络线路、证书维护、协议适配、升级窗口、磁盘更换与故障到场。较低的云端账单，可能对应较高的现场人工费用；更高频的采集，也可能同时增加设备负载、回传量和保存费用。没有现场报价时，应列出成本项、计量单位与待确认范围，不应编造精确总价来支持某个选择。
高可用也必须逐段讨论。云端服务跨故障域部署，只改善对应服务的故障承受能力；共用电源、交换机或协议网关仍可能中断整条路径。边缘做双机时，还要确认设备是否允许并发读取、谁持有采集责任、切换后序号如何延续。入口上增加 2 台网关，不等于自动获得端到端高可用。无法消除的单点应写出恢复时间、备件和人工操作办法，而不是在图中隐藏。
6 常见坑：办公网策略套到产线
办公网通常优先服务人员与通用终端，更新、重启和访问方式比较灵活。产线设备可能长期运行，使用特定协议，并受工艺窗口、供应商维护条件和设备认证约束。把办公终端的统一策略直接推给现场，可能导致设备连接中断、网关意外重启，或者让高频扫描影响资源有限的控制设备。问题不在于要不要安全措施，而在于措施是否经过现场评估，能否在合适窗口实施并验证恢复。
网络分区应围绕职责与必要通信设计。订单服务不应因为需要生产进度，就获得访问所有设备的权限。可以在现场网络与业务网络之间设置受控接入区域，由经过授权的边缘节点发起必要连接，明确源、目的、协议、方向和管理责任。具体分区方式要结合现场情况，不能照搬办公网地址表。远程维护入口也应单独管理，使用可审计身份、限定有效期并保留操作记录，避免共享账号长期开放。
补丁与证书同样需要运行安排。长期不更新会积累风险，未经验证立即更新也可能破坏协议兼容性。方案应写明测试环境、维护窗口、回滚条件和现场联系人。证书到期可能只影响云端回传，随后引发缓存持续增长；若没有新鲜度与容量告警，业务人员可能很久后才发现订单进度停留在旧状态。安全配置的生命周期应进入运维计划，而不能只在上线当天检查是否成功连接。
观测指标要能区分故障位置。设备侧关注连接状态、采集缺口和事件序号，边缘侧关注缓存深度、最老待发事件年龄与磁盘余量，云端关注拒绝数、保存延迟、重复量和处理积压，订单侧关注关联失败与进度新鲜度。日志使用设备号、工单号和事件身份关联，避免无条件收集与业务无关的敏感信息。单独看到 CPU 使用率低，不能证明数据路径健康。
另一个常见误区是把“断网可运行”扩大为“任何故障都能运行”。外网中断、本地网络故障、边缘断电和控制器故障的影响不同。设计应逐类描述依赖与降级条件。比如外网中断时保存事件，边缘不可用时是否暂停接收新工单，由现场规程决定；涉及安全联锁的故障必须交给适当的安全机制。不能用订单系统的自动重试逻辑替代现场处置，也不能让恢复脚本自行重复执行物理动作。
7 案例：协议转换引入不确定时延
假设包装线接入共享协议转换网关后，订单页面偶尔晚很久才显示完成。最初的解释是“云端慢”，但现场观察到机器已经完成包装，边缘回传队列也没有持续增长。这个现象只能说明迟延需要分段定位，不能据此立即认定任何组件无故障。排查先确认本地产线运行是否安全，再沿同一完成事件检查采集、转换、发送、保存和进度处理证据。
在这个合成教学案例中，低负载时，采集等待 80 ms、转换队列等待 15 ms、转换处理 5 ms、回传与保存 60 ms，合计 160 ms。增加诊断读取后，转换队列等待升到 450 ms，合计 595 ms；某次设备读取超时触发重试，队列等待达到 1800 ms，合计 1945 ms。这些是特定路径的示例测量，不代表协议标准的固定性能，也不包括订单投影尚未测量的等待。
原因可能藏在转换网关的工作方式中：多个设备共享串行访问资源，慢设备的超时占住处理机会，诊断读取与关键状态读取进入同一队列，协议转换还要等待完整响应才能继续。换成更快的云端实例并不能释放这段排队。排查时应核对并发限制、超时配置、轮询表与诊断任务的执行时间，先解释等待发生在哪里，再决定是否调整架构。
可以考虑限制非关键读取频率，为关键状态安排明确的读取预算，将诊断任务移到维护窗口，或在现场条件允许时拆分共享资源。任何拆分都要确认设备连接限制与协议语义，不能假定多开连接一定更快。对于需要可靠捕获的完成事件，还应确认设备是否支持保持事件或提供历史记录；只提高轮询频率，既可能增加负载，也未必能捕获短暂状态变化。
修复后的验证应覆盖正常负载、峰值读取、慢设备超时和断网补传。记录分段分布、最长观察等待和测试持续时间，同时检查采集完整性与设备负载。某次实验没有超时，并不能证明以后永不超时。若关键动作期限仍无法获得所需保证，就应把该动作留在合适的本地控制边界内。订单 API 则继续显示事件时间和新鲜度，使业务能够正确解释晚到数据。
8 把工业约束写进方案
方案中的工业约束应可以追溯到来源。将每项需求赋予编号，写明提出者、适用产线、运行条件、测量位置与验收方法。例如，“正常链路下完成事件在 60 s 内进入订单查询”要定义完成事件从何时起算、查询读到哪里，以及超时比例如何统计；“断网 4 小时保留事件”要定义起始缓存余量、事件峰值和断网前是否存在积压。缺少这些条件，指标看似精确，验收时仍会产生歧义。
数据恢复目标也要按对象区分。订单已经受理的记录、边缘尚未确认的生产事件、云端可重建的查询视图，具有不同的丢失后果与恢复路径。恢复时间目标表示服务恢复允许多久，恢复点目标表示可接受的数据损失范围。对于生产事件，应说明承诺从哪次持久化开始生效；如果设备到边缘之间存在不可补采的窗口，就必须承认这个边界，不能笼统写成全链路零丢失。
风险清单要包含可行动的处置。协议语义未核实的风险，处置是现场采样与对照设备文档；边缘磁盘耗尽的风险，处置是容量阈值、保留策略与升级路径；工单关联错误的风险，处置是显式映射、异常隔离和人工核对。每项都应指定负责人、触发条件与剩余风险。把风险写成“注意网络安全”或“保证高可用”，无法指导实施，也无法判断何时需要升级处理。
验收演练应在获准且不影响人员与设备安全的环境中进行。先用模拟事件或测试线验证断网缓存、重启恢复、重复发送和旧事件补传，再按现场安排开展受控验证。观察订单是否重复累计数量、是否回退进度、是否正确标记过期，以及恢复流量是否挤压实时事件。对物理动作的验证由合适的现场人员按规程执行，教学中的消息重放不能直接变成对真实设备重复发指令。
最终交付应包含架构图、接口与数据语义、ADR、容量假设、成本项、风险清单和运行手册。手册至少说明如何发现积压、如何判断缓存剩余可承受时间、谁能暂停非关键采集、何时转交现场处置。扩产、增加设备协议、改变采集频率或新增远程动作能力时，需要复审原决定，因为这些变化可能改变共享资源负载和失败后果。文档的价值在于支持下一次判断，而不只是证明项目曾经上线。
9 从制造与工业互联网走向零售与汽车方案（P28）
本课把同一个零售订单 API 延伸到了生产现场。订单受理、工单确认、设备执行和状态回传分别具有自己的完成条件。通过这些边界，业务可以在网络中断时解释进度，现场可以依据已批准的条件判断是否继续作业，运维可以沿事件身份找到积压位置。架构的核心成果是让不同时间尺度的系统协作，并让失败行为可以被理解和验证。
进入零售与汽车方案时，仍可复用需求到选项、ADR、成本、风险和高可用的推导顺序。订单 API 的业务身份与受理语义保持一致，但周边系统会变化：门店可能离线，车辆可能移动，连接质量与数据产生位置也可能改变。不要把本课的设备协议、采集周期或缓存容量直接复制过去，应重新确认现场条件。可以迁移的是提出问题的方法，以及把部署选择连接到失败后果的习惯。
尤其需要保留“事件发生”和“远端知道”之间的区别。工厂完成包装后，订单端可能尚未收到事件；门店完成交付后，中心系统也可能暂时未知。面对晚到、重复与乱序信息，业务状态更新都需要明确规则。不同领域对风险的容忍度不同，涉及人身安全或受监管行为时，更要由适当的专业流程确认控制边界，不能仅凭通用互联网经验决定执行方式。
复盘这张产线数据路径图，可以用 3 个问题检查理解：外网断开时，哪些行为仍有本地依据；队列积压时，哪项指标能说明最老事件等了多久；完成事件重复到达时，怎样避免重复增加订单完成数量。若能指出对应组件、记录和责任人，就具备了进入 P28 的基础。更深入的工业协议内部实现、实时调度与控制理论，留给专门课程；这里先确保方案能够把需求转成可运行、可验收的边界。
放进方案里
在零售订单 API 方案中增加“生产协作与工业约束”条目：订单服务负责可靠受理与进度查询，生产系统负责工单关联，本地控制系统负责设备动作，边缘负责状态采集与持久缓存。顾客看到“已受理”时不承诺设备已经启动；查询同时返回最近生产事件时间与新鲜度，过期时提示等待同步。工单执行条件和外网失联后的运行权限由现场确认。
ADR 选择本地控制加异步回传，备选是让云端参与每次动作判断。选择理由是避免动作期限依赖外部链路，并允许订单侧接受有说明的进度延迟；代价是现场设备维护、缓存容量、去重与补传治理。示例容量按每秒 500 条、每条 1 KB、断网 4 小时估算，原始积压为 7.2 GB，暂按 1.5 预留系数规划 10.8 GB，实际值以现场测量为准。成本表还要包含备件、安装、线路、升级窗口和恢复演练。
高可用按设备、网关、电源、网络与云服务分别列出，说明共享故障点和恢复负责人。风险重点记录协议转换排队、时钟质量、工单错配、证书到期及缓存耗尽，并为每项设置观测证据与处置条件。验收覆盖断网、边缘重启、重复事件、乱序补传和恢复限流，检查数量不重复、进度不回退、状态过期可见。动作验证必须遵守现场安全规程。
交付物保留需求编号到 ADR、指标、测试结果和运行手册的对应关系。上线后监测最老待发事件年龄、缓存余量、云端处理积压及订单进度新鲜度，提前约定告警接收人与升级路径。扩产或新增远程动作时复审原方案，避免把原本只服务状态查询的数据链，未经评估就变成生产控制链。
10 小结：下一步零售与汽车方案（P28）
制造场景要求方案同时解释业务进度与物理过程的边界。先明确期限和失败后果，再选择本地或云端职责；先定义事件语义与确认边界，再估算缓存和恢复能力。边缘、弹性和高可用都需要具体条件，不能仅靠组件名称作出承诺。
带着订单 API 的受理语义、事件身份、新鲜度和恢复规则进入 P28，再根据零售与汽车场景重新评估连接、部署、成本与风险。读者应能说明自己的选择为何成立，以及哪些条件变化后必须重新作出决定。