Product Manager Portfolio

软硬一体
设备平台
架构重构

企业财务共享 · IoT 平台产品化

把一个围绕单机型、单项目交付的设备系统,重构为支持多机型兼容、配置化交付、统一调度的平台底座——这是我在这个项目里做的事。

6
架构层次
4+1
硬件模型维度
↓80%
交付时间压缩
项目概览 核心问题 平台架构 关键判断 交付体系 演进路线
00

项目概览

角色、背景与核心产出

行业场景
企业财务共享中心
纸质单据集中扫描、暂存、归档、取件全流程自动化;设备侧处理物理流程,平台侧负责方案配置、任务调度与三方系统集成。
我的角色
产品经理 + 平台 Owner
负责需求管理、架构表达、平台边界梳理,以及多机型平台方向的产品设计和阶段性落地路线规划。
核心命题
项目型系统 → 平台型产品
把围绕单机型构建的项目型系统,重构为面向多设备型号的可复制平台底座。
核心产物
架构方案 + 平台迭代
平台架构方案 · 硬件抽象模型 · 统一调度能力设计 · 配置模板体系 · 标准化交付流程。
01

三个结构性问题

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

Problem 01
平台的主语是「某台设备」,不是「平台」
所有架构、配置、调度逻辑围绕单一机型设计,每接入一款新机型都是一次独立的定制工程,没有复用路径,新机型永远是「例外处理」。
Problem 02
硬件层单体化膨胀,所有机型的驱动逻辑共享同一个运行时。
每新增一款设备型号,驱动、参数和控制逻辑全部追加进同一套代码库,机型间逻辑相互缠绕,改动风险高、回归成本大、新机型适配周期长。
Problem 03
复杂业务逻辑分散,无法统一治理
归档任务和机器人协同各自实现了一套调度逻辑,任务冲突、状态不一致、挂起恢复策略混乱的问题随场景增加越来越突出。
我的判断:这个系统已经到了从「复杂项目」走向「平台产品」的拐点。如果不完成这次架构重构,后续每增加一个机型、一个客户、一种业务场景,成本都会线性增长。

重构前后对比

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

平台六层架构

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

Step 01 — 系统分层

每层只保留职责 + 关键节点。

L0 · Physical Device 物理设备层 执行终点

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

HW1扫描
HW2打印 / 小票
HW3机械手 / 运动轴 / 升降
HW4锁控 / 对接舱 / 退件口
HW5暂存 / 归档箱 / 传感器
HW6工控机 / 控制板 / 驱动板
L1 · 硬件层 Runtime 本地硬件控制层 能力封装

把底层硬件统一封装成可调用能力,向上暴露统一硬件控制 API,屏蔽硬件品牌差异。

S1零件 / 类型 / 模块建模
S2驱动加载与版本管理
S3硬件控制 API
S4自检与异常处理
S5仓位配置与校准
S6压测与动作验证
L2 · Device Client 设备客户端层 被动执行层

接收 L3 服务端下发的任务,调用 L1 硬件能力执行业务流程,并将执行结果、状态、异常回传平台。不持有任何主动调度逻辑,是纯被动执行层。

C1首页/页面/功能组件
C2交单流程引擎
C3取件 / 其他功能
C4设备管理 / 异常引导
C5机器人协作
C6本地配置同步与方案刷新
L3 · D6 Platform 平台服务层 发起方

平台的任务发起方。通过定时任务或三方 API 调用驱动 L2 执行,统一治理方案、配置、调度、监控和消息,同时消化 L4 入站事件并统一调度。

P1方案 / 配置中心
P2设备与硬件配置中心
P3驱动仓库与模板中心
P4归档任务与调度中心
P5设备监控 / 仓位记录 / 单据记录
P6通知与异常消息中心
L4 · Integration Layer 集成协同层 双向协议边界

负责对接外部业务系统、OCR、移动机器人以及文件消息类接口。主动和被动能力均有——出站由 L3 发起调用,入站事件统一交 L3 调度处理,不直接穿透到 L2。

I1三方业务系统接口
I2OCR / 初审能力
I3移动机器人接口
I4文件 / 报告 / 消息接口
L5 · Data Asset 数据资产层 服务端实现

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

D1设备配置数据
D2仓位与归档数据
D3单据 / 任务 / 状态数据
D4驱动 / 模板 / 方案数据
D5日志 / 异常 / 审计数据
D6影像 / 文件存储

Step 02 — 关键依赖流

控制流向(确认)
L3 服务端 ──[定时任务 / 三方 API]──► L2 客户端 ──► L1 硬件控制 ──► L0 物理设备
L3 是唯一任务发起方,L2 是纯被动执行层。L4 入站事件(移动机器人推送、三方回调)先到 L3 统一调度,再由 L3 驱动 L2 执行,不直接穿透到 L2。
Source

L0 物理设备层

扫描、打印、机械手、门锁、传感器等真实硬件能力。

驱动封装
Target

L1 本地硬件控制层

由 硬件层 统一接管硬件控制、自检、校准和驱动管理。

HW1S3扫描仪进入硬件控制 API
HW2S3打印机 / 小票机进入硬件控制 API
HW3S3夹爪 / 小车进入硬件控制 API
HW6S2工控机 / 控制板进入驱动管理
Source

L1 本地硬件控制层

对硬件动作、异常、自检和仓位校准形成统一能力封装。

流程支撑
Target

L2 设备客户端层

客户端接收 L3 任务后,调用 L1 能力执行业务流程。

S3C2硬件控制 API 支撑交单流程引擎
S3C3硬件控制 API 支撑取件流程
S4/S6C4自检与动作验证支撑异常引导
S5C6仓位配置与校准支撑配置刷新
Source · 唯一发起方

L3 平台服务层

通过定时任务或三方 API 主动发起任务,下发给设备客户端执行。

任务下发
Target · 被动执行层

L2 设备客户端层

接收平台下发的任务指令,调用 L1 执行,不持有调度逻辑。

P4C2/C3调度中心定时 / API 触发,下发归档与取件任务
P4C5机器人入站后由 P4 统一调度,下发协作锁定状态
P1/P3C6配置 / 模板变更后下发版本比对通知
Source

L2 设备客户端层

任务执行后,把状态、结果、配置差异和异常上报回平台。

数据上报
Target

L3 平台服务层

平台统一治理方案、配置、调度结果、监控和通知能力。

C6P1/P2/P3版本比对结果回接方案、硬件和模板中心
C2P4交单完成状态进入归档任务调度中心
C3P5取件结果回写监控与记录
C4P6异常事件进入平台消息治理链路
Source

L3 平台服务层

平台侧主动调用外部系统,由 L3 统一发起,不经过 L2。

外部调用
Target

L4 集成协同层

出站:连接三方业务系统、OCR 能力、移动机器人和文件消息接口。

P1/P4I1平台方案与调度中心连接业务系统
P4I2调度中心工作流步骤调用 OCR 识别
P4I3调度中心发起 机器人运单 / 取件任务
P6I4消息中心连接文件 / 报告 / 消息接口
Source · 外部入站

L4 集成协同层

机器人推送运单状态、三方系统回调、OCR 异步结果等入站事件。

入站汇聚
Target · 统一调度

L3 平台服务层

所有外部入站事件统一在 L3 消化,不直接穿透到 L2 客户端。

I3P4机器人推送运单 / 取件任务 → L3 统一调度
I1P1/P6三方系统回调 → 平台方案与消息中心处理
I2P4OCR 异步结果回写 → 调度中心继续流程
Source

L3 平台服务层

平台所有核心能力向下沉淀配置、任务、仓位、影像和日志等数据资产。

数据沉淀
Target · 服务端实现

L5 数据资产层

L3 的数据持久化层(同服务进程内读写),形成平台可追溯的数据底座。

P2D1设备配置中心沉淀设备配置数据
P4/P5D2/D3调度与监控沉淀仓位、任务、单据状态数据
P1/P3D4方案与模板中心沉淀配置资产
P6D5消息中心沉淀日志、异常和审计数据
C2D6交单流程上传扫描影像至影像 / 文件存储
03

三个关键产品判断

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

01
解决问题一:平台主体必须从「某台设备」切换到「设备型号族」
平台的主语决定了所有架构决策的默认假设。只要主语是「某台设备」,新机型就永远是补丁,配置、模板、调度逻辑都会在单机型假设下越堆越厚。切换到「设备型号族」之后,方案配置、硬件模板、调度能力的作用域都以型号为维度组织,新机型接入变成注册行为,而不是定制工程。这一步是后续所有平台化建设的基础前提。
02
解决问题二:硬件层必须按型号隔离,不能让所有机型共享同一个运行时
硬件层单体化的根本原因,是驱动、参数、控制逻辑没有按型号做边界隔离,全部混在一个运行时里。解法不是重构代码量,而是改变组织方式——硬件层按散件实例动态加载,每台设备只加载自身需要的驱动和参数,型号间彻底隔离。新机型接入不影响存量机型的稳定性,适配周期和回归成本同步下降。
03
解决问题三:归档任务和机器人协同必须进入统一调度框架
两套独立调度逻辑的问题,不能靠继续完善各自的流程来解决——因为根本矛盾在于没有统一的任务模型、资源模型和状态模型。把归档任务和机器人协同都纳入同一个调度框架后,任务优先级、资源预占、挂起恢复、超时补偿就有了统一的处理入口。新增一种协作模式,不需要再写一套新的流程控制逻辑,只需要在框架内注册新的任务类型。
04

交付体系设计

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

标准八步交付流程

STEP 01
设备注册
全局唯一编码,由平台统一分配管理
STEP 02
启用新版本硬件控制层
客户端初始化,连接本地硬件运行时
STEP 03
选择机型 · 匹配模板
自动匹配该机型可用的硬件轮廓模板列表
STEP 04
一键应用模板
驱动自动下载 · 零件配置自动应用 · 仓位初始值自动填充
STEP 05
仓位微调
每台设备存在物理个体差异,手机扫码辅助精确调试
STEP 06
全流程压测验证
存件 / 取件 / 归档 / 打印 / 暂存转移全覆盖
STEP 07
保存为硬件轮廓模板
当前配置沉淀为平台资产,供同型号后续设备复用
STEP 08
迁移至客户内网
配置包与驱动文件一键导出迁移

交付效率对比

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

三层模板体系

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

架构演进路线

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

Phase 1
三端解耦
已完成
硬件控制层标准化,多机型共享同一运行时
硬件控制层独立运行,驱动热插拔,工作流驱动硬件调用;多款设备型号完成适配。
Phase 2
人机协作
已完成
机器人协同上线,仓位三态模型落地
移动机器人与设备端协同功能上线,设备状态机升级,仓位预占 / 占用 / 空闲三态模型落地。
Phase 3
型号注册体系
已完成
新机型接入成本 ≤ 1 人天
设备型号注册中心建设,能力标签体系,配置和模板作用域与机型绑定。
Phase 4
硬件模型工程化
已完成
物理资源冲突控制自动化
四层参数结构工程落地,物理资源映射接入调度器,冲突从「人工约定」变为「系统自动检测」。
Phase 5
调度内核统一
已完成
所有任务类型进入统一调度框架
归档任务与机器人协同进入同一调度框架,任务优先级、挂起恢复、超时补偿统一管理。
Phase 6
平台产品化
已完成
实施人员独立交付率 ≥ 80%
交付门户、自助配置、模板市场建设,使非研发人员可以独立完成大多数交付场景。
06

这个项目体现了什么

平台视角的产品抽象
识别出「项目型系统 → 平台型产品」的拐点,并从产品层面推动了这次切换。
复杂系统建模能力
把硬件、状态机、调度框架、模板体系整理为一套统一的架构语言,让多个角色共享同一套理解框架。
软硬件协同理解
既考虑了业务闭环,也考虑了硬件资源管理、物理冲突控制和现场交付的实际约束。
0-1 方法论
先定义正确的平台结构,再定义可复制能力,再规划分阶段落地路径——不只是优化现有系统。

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