李洋 · 软硬一体设备平台作品集

00

项目概览

角色、背景与核心产出

行业场景

企业财务共享中心

纸质单据集中扫描、暂存、归档、取件全流程自动化；设备侧处理物理流程，平台侧负责方案配置、任务调度与三方系统集成。

我的角色

产品经理 + 平台 Owner

负责业务建模、平台边界定义、架构方向判断；与硬件、客户端、服务端三类技术负责人协作，共同完成方案落地与平台演进。

核心命题

项目型系统 → 平台型产品

把围绕单机型构建的项目型系统，重构为面向多设备型号的可复制平台底座。

核心产物

业务架构 + 平台演进路线

业务架构方案 · 硬件抽象模型 · 统一调度业务建模 · 配置模板体系 · 标准化交付流程。

技术栈与领域

工业自动化外设矩阵 · 信创双栈适配

覆盖 运动控制（雷赛 PLC + CAN 总线）、机器视觉（海康 SDK）、数据采集（扫码 / 读卡 / IC 卡）、输出（票据打印 / 装订 / 全幅扫描）、数字 IO（继电器）、移动机器人（视觉路径识别）等多类工业外设接入；完成 Windows + 麒麟 Linux 信创双栈适配；三端通信基于 WebSocket 实现实时双向协同。

01

三个结构性问题

这些不是功能缺陷,而是系统从「项目」走向「平台」必须解决的架构问题

PROBLEM 01

平台的主语是「某台设备」,不是「平台」

所有架构、配置、调度逻辑围绕单一机型设计,每接入一款新机型都是一次独立的定制工程,没有复用路径,新机型永远是「例外处理」。

PROBLEM 02

硬件层单体化膨胀,所有机型共享同一运行时

每新增一款设备型号,驱动、参数和控制逻辑全部追加进同一套代码库,机型间逻辑相互缠绕,改动风险高、回归成本大、新机型适配周期长。

PROBLEM 03

复杂业务逻辑分散,无法统一治理

平台同时承载三类异构任务源——用户业务流(交单 / 取件)、平台调度(归档 / 巡检)、外部入站(机器人推送 / ERP 回调)——但各自实现了一套调度逻辑,任务冲突、状态不一致、资源争抢的问题随场景叠加越来越突出。

我的判断:这个系统已经到了从「复杂项目」走向「平台产品」的拐点。如果不完成这次架构重构,后续每增加一个机型、一个客户、一种业务场景,成本都会线性增长。

重构前后对比

维度	重构前(项目型)	重构后(平台型)
平台主体	某款旗舰机型的功能后台	面向多机型的设备平台底座
机型适配	每款新机型独立定制,从零开始	注册到统一设备型号模型,配置化适配
配置管理	针对单一机型的配置项	按机型 × 能力标签多维管理,作用域清晰
硬件模型	模块 / 类型 / 零件的概念描述	实例 + 驱动绑定 + 资源映射 + 行为参数的运行模型
调度能力	各业务流程独立实现调度逻辑	统一任务模型 + 统一调度内核
交付方式	依赖实施工程师经验,每台重新配置	硬件轮廓模板 + 标准流程 + 压测验证,可复制

02

平台六层架构

先看分层职责,再看控制流向与关键依赖链路

Step 01 · 系统分层

每层只保留职责与关键能力节点。

L0 · PHYSICAL DEVICE 物理设备层 执行终点

承载所有真实物理设备,是动作执行与状态感知的最底层载体。所有控制指令最终在此层落地执行。

HW1扫描 / 数据采集(扫码枪 + 读卡器 + 影像)

HW2输出(票据打印 + 装订 + 全幅扫描)

HW3运动控制(机械手 + 运动轴 + 升降,雷赛 PLC + CAN)

HW4锁控 / 对接舱(继电器 + 退件口)

HW5暂存 / 归档箱 / 仓位传感器

HW6工控机 / 控制板(Windows + 麒麟双栈)

L1 · HARDWARE RUNTIME 本地硬件控制层 能力封装

把底层硬件统一封装成可调用能力,向上暴露统一硬件控制 API,屏蔽硬件品牌差异。该层的具体驱动实现由硬件技术负责人主导;我作为产品负责人,与之协作完成的是能力边界定义、对上 API 的语义抽象原则、配置化模型设计。

S1零件 / 类型 / 模块建模

S2驱动加载与版本管理

S3硬件控制 API

S4自检与异常处理

S5仓位配置与校准

S6压测与动作验证

L2 · DEVICE CLIENT 设备客户端层 业务执行入口

业务流程的执行入口。响应用户操作驱动业务流程(交单 / 取件等),也接收 L3 平台下发的调度任务(归档 / 巡检等)。无论入口是哪种,L2 都主动调用 L1 硬件能力完成物理动作,并将结果、状态、异常回传平台。L2 不持有跨设备的全局调度逻辑——这部分属于 L3。

C1首页 / 页面 / 功能组件

C2交单流程引擎

C3取件 / 其他功能

C4设备管理 / 异常引导

C5机器人协作

C6本地配置同步与方案刷新

L3 · D6 PLATFORM 平台服务层 发起方

平台侧任务发起方,也是三类任务源的汇聚与治理中心:平台调度任务由 L3 主动发起;外部入站事件经 L4 进入 L3 后统一调度;用户业务流由 L2 直接发起,但执行结果与状态变更回流 L3。L3 统一治理方案、配置、调度、监控和消息,确保跨设备、跨任务源的一致性。

P1方案 / 配置中心

P2设备与硬件配置中心

P3驱动仓库与模板中心

P4归档任务与调度中心

P5设备监控 / 仓位记录 / 单据记录

P6通知与异常消息中心

L4 · INTEGRATION 集成协同层 外部协议边界

负责对接外部业务系统、OCR、移动机器人以及文件消息类接口。主动和被动能力均有——出站由 L3 发起调用,入站事件统一交 L3 调度处理,不直接穿透到 L2。本层提供插件 + 拦截器扩展机制,客户特有的对接逻辑(如 ERP 字段映射、权限映射、单据状态回写规则)在扩展点内实现,不污染主线。

I1三方业务系统接口

I2OCR / 初审能力

I3移动机器人接口

I4文件 / 报告 / 消息接口

I5插件 / 拦截器扩展点

L5 · DATA ASSET 数据资产层 服务端实现

由服务端(L3)实现,是 L3 的数据持久化层,读写均为服务端内部访问。沉淀配置、仓位、任务、状态、日志和审计数据。

D1设备配置数据

D2仓位与归档数据

D3单据 / 任务 / 状态数据

D4驱动 / 模板 / 方案数据

D5日志 / 异常 / 审计数据

D6影像 / 文件存储

Step 02 · 控制流向

用户操作 / L3 调度 / L4 入站 ─[ 三类业务源 ]─► L2 客户端 ─[ 主动调用 ]─► L1 硬件控制 ─► L0 物理设备

业务任务有三类发起源:用户操作(交单 / 取件等 C 端流程,L2 直接发起)、平台调度(归档 / 巡检任务,L3 主动下发)、外部入站(机器人推送、ERP 回调,统一汇入 L3 后下发)。无论哪种来源,最终都由 L2 主动调用 L1 硬件能力执行——L1 不感知业务来源,L2 不感知跨设备调度,各层职责清晰。

Step 03 · 关键依赖流

L0 → L1 物理设备 / 硬件层

驱动封装

HW1→S3扫描仪进入硬件控制 API
HW2→S3打印 / 小票机进入硬件控制 API
HW3→S3运动控制(夹爪 / 升降轴)进入硬件 API
HW6→S2工控机 / 控制板进入驱动管理

L1 → L2 硬件层 / 客户端

流程支撑

S3→C2硬件控制 API 支撑交单流程引擎
S3→C3硬件控制 API 支撑取件流程
S4/S6→C4自检与动作验证支撑异常引导
S5→C6仓位配置与校准支撑配置刷新

用户 → L2 客户端发起

用户业务流程(C 端)

USER→C2用户提交单据触发交单流程,客户端调用硬件层完成轴运动 / 夹取 / 暂存
USER→C3用户取件触发取件流程,客户端调度硬件完成定位 / 取出 / 出件
USER→C4用户报障触发设备管理与异常引导流程

L3 → L2 服务端 / 客户端

平台调度任务下发

P4→C2/C3调度中心定时 / API 触发归档、取件等平台任务
P4→C5外部机器人入站事件经 P4 统一调度,下发协作指令
P1/P3→C6配置 / 模板变更下发版本比对通知

L2 → L3 客户端 / 服务端

数据上报

C6→P1/P2/P3版本比对结果回接方案 / 硬件 / 模板中心
C2→P4交单完成状态进入归档调度中心
C3→P5取件结果回写监控与记录
C4→P6异常事件进入消息治理链路

L3 → L4 服务端 / 集成层

外部出站调用

P1/P4→I1方案与调度中心连接业务系统
P4→I2调度中心调用 OCR 识别
P4→I3调度中心发起机器人运单 / 取件
P6→I4消息中心连接文件 / 报告 / 消息接口

L4 → L3 集成层 / 服务端

外部入站汇聚

I3→P4机器人推送运单 → L3 统一调度
I1→P1/P6三方系统回调 → 方案与消息中心处理
I2→P4OCR 异步结果回写 → 调度中心继续流程

03

三个关键产品判断

这些判断决定了方案的方向,而不只是实现细节

01

解决问题一:平台主体必须从「某台设备」切换到「设备型号族」

平台的主语决定了所有架构决策的默认假设。只要主语是「某台设备」,新机型就永远是补丁,配置、模板、调度逻辑都会在单机型假设下越堆越厚。切换到「设备型号族」之后,方案配置、硬件模板、调度能力的作用域都以型号为维度组织,新机型接入变成注册行为,而不是定制工程。这一步是后续所有平台化建设的基础前提。

02

解决问题二:硬件层必须按型号隔离,不能让所有机型共享同一运行时

硬件层单体化的根本原因,是驱动、参数、控制逻辑没有按型号做边界隔离,全部混在一个运行时里。解法不是重构代码量,而是改变组织方式——硬件层按散件实例动态加载,每台设备只加载自身需要的驱动和参数,型号间彻底隔离。新机型接入不影响存量机型的稳定性,适配周期和回归成本同步下降。

03

解决问题三:三类异构任务源必须汇聚到同一个调度框架

用户业务流(L2 主动发起)、平台调度任务(L3 主动下发)、外部入站事件(L4 → L3 汇聚)——三类任务源各自独立实现一套调度,根本矛盾在于没有统一的任务模型、资源模型和状态模型。把三类任务源都纳入同一个调度框架,任务优先级、资源预占、挂起恢复、超时补偿就有了统一的处理入口。新增一种任务类型(无论来自哪类源),都不需要再写一套新的流程控制逻辑,只需要在框架内注册新的任务类型与执行策略。这一步是平台从「项目堆砌」走向「框架支撑」的关键。

04

底层方法论

支撑这次重构的,是一套可迁移到任何平台型产品的方法论

METHOD 01

DDD 领域驱动建模

把每一层都按业务实体拆解到最小粒度,三端共享同一套领域语言:

设备层:按硬件零件 / 模块 / 能力建模
客户端:按页面 / 区块 / 原子组件分解
服务端:按聚合根 / 领域服务 / 配置中心组织

避免「软件团队和硬件团队对不上话」,让多个角色共享同一套理解框架。

METHOD 02

配置化工作流编排

组件化之后,按实际业务流程动态组合形成完整工作流:

组件:最小可复用业务单元
流程:组件 + 顺序 + 跳转条件
规则:配置项约束 + 仓位状态机

让 80% 的业务变更通过纯配置完成;剩余 20%(主要是三方接口对接)通过插件 + 拦截器扩展点承接,不动主线代码。实施工程师独立交付率 ≥ 80%。

METHOD 03

三层承接模型

防止个性化需求侵蚀主产品,每个需求进来必须先回答「属于哪一层」:

核心产品能力:平台沉淀,所有客户共用
配置化能力:通过模板和参数差异化
项目方案能力:客户专属,不进主线

是「平台主体」与「客户环境适配边界」之间的清晰约束。

这套方法论不局限于本项目——它适用于任何「项目制 → 平台化」的 ToB 产品场景,也是低代码 / 业务中台 / 工业 SaaS 类产品的底层范式。

05

交付体系设计

把实施工程师的经验转化为平台资产,实现可复制交付

标准八步交付流程

STEP 01

设备注册

全局唯一编码,由平台统一分配管理

STEP 02

启用新版本硬件控制层

客户端初始化,连接本地硬件运行时

STEP 03

选择机型 · 匹配模板

自动匹配该机型可用的硬件轮廓模板列表

STEP 04

一键应用模板

驱动自动下载 · 零件配置自动应用 · 仓位初始值自动填充

STEP 05

仓位微调

每台设备存在物理个体差异,手机扫码辅助精确调试

STEP 06

全流程压测验证

存件 / 取件 / 归档 / 打印 / 暂存转移全覆盖

STEP 07

保存为硬件轮廓模板

当前配置沉淀为平台资产,供同型号后续设备复用

STEP 08

迁移至客户内网

配置包与驱动文件一键导出迁移

交付效率对比

环节	重构前	重构后	变化
同型号新设备配置	2–4 小时人工	30 分钟内	↓80%
新客户差异化交付	研发介入,主线代码拉分支	配置中心建租户 + 插件扩展点	低代码
驱动版本升级	全量重新部署	客户端自动比对	静默升级
硬件故障定位	人工逐层排查	精确到具体零件实例	精准定位

三层模板体系

层级	内容	复用场景
机型模板	绑定机型通用能力配置	同机型不同客户
硬件轮廓模板	零件组合 + 驱动绑定	同机型不同批次
运行参数模板	物理资源参数微调	同批次细微差异

协作分工说明:上述交付效率提升的实现,依赖于硬件层、客户端、服务端三方技术负责人共同推进。我作为产品负责人,核心贡献是定义模板抽象层级、设计配置作用域规则、规划八步流程的产品边界。

06

架构演进路线

从三端解耦到平台产品化的分阶段落地路径

PHASE 01

三端解耦

已完成

硬件控制层标准化,多机型共享同一运行时

硬件控制层独立运行,驱动热插拔,工作流驱动硬件调用;多款设备型号完成适配。

PHASE 02

人机协作

已完成

机器人协同上线,仓位三态模型落地

移动机器人与设备端协同功能上线,设备状态机升级,仓位预占 / 占用 / 空闲三态模型落地。

PHASE 03

型号注册体系

已完成

新机型接入成本 ≤ 1 人天

设备型号注册中心建设,能力标签体系,配置和模板作用域与机型绑定。

PHASE 04

硬件模型工程化

已完成

物理资源冲突控制自动化

四层参数结构工程落地,物理资源映射接入调度器,冲突从「人工约定」变为「系统自动检测」。

PHASE 05

调度内核统一

已完成

所有任务类型进入统一调度框架

归档任务与机器人协同进入同一调度框架,任务优先级、挂起恢复、超时补偿统一管理。

PHASE 06

平台产品化

已完成

实施人员独立交付率 ≥ 80%

交付门户、自助配置、模板市场建设,使非研发人员可以独立完成大多数交付场景。

07

这个项目体现了什么

可迁移到任何 ToB 平台型产品的产品能力组合

DDD 领域建模实战

将设备、客户端、服务端按业务实体最小粒度拆分,通过限界上下文和聚合根识别,建立跨三端一致的领域模型。

低代码工作流编排

Web 端拆解到原子组件级,按业务流程动态组合形成完整工作流;80% 业务变更通过纯配置完成,20% 三方对接通过插件 + 拦截器扩展承接,主线代码不动。让「实施工程师独立交付」成为可能。

工业领域 know-how

覆盖运动控制(雷赛 PLC + CAN)、运动轴、数据采集、数字 IO、移动机器人等完整工业外设;完成 Windows + 麒麟 Linux 信创双栈适配。

跨技术栈协同推进

作为产品 Owner,与硬件、客户端、服务端三类技术负责人协作,保持产品视角与技术决策的清晰分工,推动平台分阶段演进。

本文档已做脱敏处理,隐去具体设备型号、技术参数、内部系统名称及驱动实现细节

软硬一体设备平台平台化产品建设