整理版概览来源 03

科杰起重标准电气系统:项目框架与子系统拆分

本文档用于把“科杰起重 拟建新规下标准电气系统”从原始需求材料整理成可落地的项目框架,服务于内部产品与项目规划。

更新时间:2026/03/26 07:47标签:项目框架 / 子系统 / 阶段路线

科杰起重标准电气系统(项目框架与子系统拆分)

1. 文档定位

本文档用于把“科杰起重-拟建新规下标准电气系统”从原始需求材料整理成可落地的项目框架,服务于内部产品与项目规划。

本文档不等同于最终技术方案,也不等同于对外合同文本,而是用于明确:

  • 项目背景与目标;
  • 项目范围边界;
  • 应拆分为哪些子系统;
  • 哪些内容适合独立推进;
  • 哪些内容只做预留,不在首期深度开发。

2. 项目背景

福建科杰当前的核心诉求,不只是做一套“能用”的控制系统,而是围绕新规、标准化和可复制交付,重建一套底层体系。

根据原始材料,项目背景主要包括:

  1. 新规适配压力

    • 面向 2026 年 5 月 1 日新规,设备全生命周期管理和一机一档要求将更受重视;
    • 企业现有通用型、套图式做法难以支撑后续合规化要求。
  2. 标准化电控体系缺口

    • 现有图纸、设计和程序能满足部分交付,但在标准化、规范性、可追溯性、批量复制方面不足;
    • 缺少成体系的底层设计文件和标准版本管理能力。
  3. 国产化与兼容性诉求并存

    • 倾向国产化优先;
    • 同时要兼容主流进口品牌接口和使用习惯,避免未来替换困难。
  4. 未来扩展需求已明确,但成熟方案未定

    • 锂电/市电双模式是明确升级方向;
    • IoT、远程升级、全平台监管对接也是明确方向;
    • 但首期不宜全面铺开,更适合做架构预留。
  5. 需要借助外部团队补足标准设计能力

    • 企业具备现场调试、售后与实际工程经验;
    • 但在标准设计、规范图纸、底层架构、课题化组织方面,希望借助高校或专业团队完成体系化建设。

3. 项目总体目标

本项目建议定义为:围绕起重机械主力机型,建设一套可直接用于生产交付的标准化电控底层设计与合规支撑体系,并为后续数字化、一机一档、远程能力扩展预留统一接口。

总体目标可拆成五个层面:

3.1 电控底座标准化

形成统一的:

  • 电气原理图;
  • 接线图;
  • 柜内布局图;
  • 线束规范;
  • BOM 采购清单;
  • PLC 标准版本。

3.2 主力机型可复用

优先覆盖:

  • LD;
  • LH;
  • QD;
  • 门吊;
  • 半门吊。

目标是形成“多吨位、多功率可参数化复用”的标准方案,而不是每个项目重新起草一套。

3.3 合规资料与一机一档衔接

不仅要完成设备控制层设计,也要让设备交付资料、检验资料、运行维保资料能逐步归集成完整档案。

3.4 扩展接口预留

对以下方向先做架构预留:

  • 锂电/市电双模式;
  • 物联网采集;
  • 远程升级;
  • 对外平台数据接口。

3.5 项目边界可控

避免一开始把“标准电气系统”做成无限放大的平台项目。首期要清楚区分:

  • 必须交付的核心子系统;
  • 可半独立推进的业务子系统;
  • 只做预留、不做深度开发的扩展层。

4. 项目范围拆分逻辑

建议把第三份材料理解为“一个大项目 + 多个子系统”的组合,而不是单一系统。这样更利于拆排期、拆团队、拆合作边界。

项目范围建议拆为 7 个子系统。

5. 子系统拆分建议

子系统 A:标准电控底层设计子系统

定位

  • 这是整个项目的底座;
  • 也是最适合与高校/专业团队合作完成的核心模块。

范围

  • 主回路与控制回路原理图;
  • 标准接线图;
  • 柜内布局规范;
  • 线号、端子、线束规则;
  • 元器件选型规范;
  • BOM 清单;
  • PLC 标准程序版本框架。

产出

  • 可直接用于生产的标准图纸包;
  • 标准元件库;
  • 标准 BOM 版本;
  • 程序和图纸版本管理规则。

建设特点

  • 必须严谨;
  • 强依赖专业电控设计能力;
  • 与后续所有子系统存在主从关系。

子系统 B:设备全生命周期档案 / 一机一档子系统

定位

  • 负责建立设备数字主档;
  • 是连接电控交付、检验资料、维保记录和后续平台对接的中台层。

范围

  • 设备主档;
  • 随机资料归档;
  • 出厂资料归档;
  • 安装、检验、登记资料归档;
  • 设备身份、版本、变更记录;
  • 档案完整度与状态标记。

产出

  • 一机一档结构;
  • 档案字段体系;
  • 附件分类规则;
  • 对外数据接口基础。

建设特点

  • 既服务内部,也服务未来监管与校方平台对接;
  • 应与子系统 A 的设备身份体系打通。

子系统 C:安全检查维保台账子系统

定位

  • 即第二份文档对应的业务系统;
  • 是可独立开发、可先行落地、也可后续接入平台的半独立子系统。

范围

  • 日检;
  • 月检;
  • 维保;
  • 年度自检;
  • 到期提醒;
  • 风险状态;
  • 整改闭环;
  • 资料导出。

产出

  • 轻量台账系统;
  • 电子归档与资料包导出能力;
  • 设备日常管理闭环。

建设特点

  • 最贴近业务落地;
  • 可以先作为 Web 系统单独实施;
  • 后续自然汇入一机一档平台。

子系统 D:合规资料与交付包管理子系统

定位

  • 解决“资料成套交付”和“后续检验、抽查、报检时资料难找”的问题。

范围

  • 出厂资料包;
  • 项目交付资料包;
  • 检验前资料归集;
  • 资料缺失提醒;
  • 按设备导出完整交付包。

产出

  • 标准资料清单;
  • 交付包模板;
  • 归档与导出规则。

建设特点

  • 与子系统 B 紧密相连;
  • 有助于把企业的“随机资料”能力标准化。

子系统 E:IoT / 远程能力预留子系统

定位

  • 首期不做重开发,只做架构预留;
  • 保证后续接入模块时,不需要推翻现有底层设计。

范围

  • 通讯接口预留;
  • 数据采集点定义;
  • 柜体安装位预留;
  • 后续远程升级所需的软件接口与硬件位置预留。

产出

  • 接口点位清单;
  • 预留说明;
  • 后续接入规范。

建设特点

  • 必须在子系统 A 设计时同步考虑;
  • 但当前不要求完成完整云平台或远控平台。

子系统 F:锂电 / 市电双模式预留子系统

定位

  • 明确是产品升级方向;
  • 首期主要完成底层电气架构和保护逻辑预留。

范围

  • 双模式切换的电气架构预留;
  • 保护逻辑预留;
  • 布线空间与柜体空间预留;
  • 后续加装硬件所需接口预留。

产出

  • 双模式扩展架构说明;
  • 关键接口和保护点说明;
  • 对图纸和柜体布局的预留要求。

建设特点

  • 当前无成熟方案,因此更适合作为“前置设计约束”,而非一期完整交付内容。

子系统 G:外部平台对接子系统

定位

  • 负责未来与校方平台、行业平台或监管平台做数据衔接;
  • 首期不宜做深,只定义边界和接口基础。

范围

  • 一机一档数据映射;
  • 基础字段标准;
  • 资料上传/同步接口预留;
  • 状态字段兼容设计。

产出

  • 接口清单草案;
  • 字段映射草案;
  • 对接前置条件。

建设特点

  • 依赖子系统 B 和 C 的数据结构成熟度;
  • 更像平台化延伸模块。

6. 子系统之间的关系

建议用以下关系理解整个项目:

  • A 标准电控底层设计:底座层;
  • B 一机一档:设备数字主档层;
  • C 台账系统:日常运营与维保闭环层;
  • D 合规资料与交付包:合规输出层;
  • E/F/G:未来扩展与对接层。

其中:

  • A 决定设备标准化交付能力;
  • B 决定设备身份与资料沉淀能力;
  • C 决定设备运行后的日常管理能力;
  • D 决定资料是否能在交付、检验、抽查时形成完整输出;
  • E/F/G 决定系统未来升级空间。

7. 第二份文档在本项目中的位置

需要明确:“起重机械安全检查维保台账系统”不是附属附件,而是本项目中的核心业务子系统之一。

建议在项目内部定义为:

  • 子系统 C;
  • 可半独立开发;
  • 可先行上线验证业务价值;
  • 后续与 B、D、G 打通。

这样既能避免第三份项目过大、过虚,也能让第二份具备独立推进和快速落地的价值。

8. 分阶段建设建议

第一阶段:先把底座与主档搭起来

建议优先推进:

  • 子系统 A:标准电控底层设计;
  • 子系统 B:设备主档 / 一机一档基础结构;
  • 子系统 C:先做轻量 MVP。

第一阶段目标是让“标准化交付”和“基础数字归档”站住。

第二阶段:把日常闭环与资料输出做完整

推进:

  • 子系统 C 完整版;
  • 子系统 D 合规资料与交付包。

第二阶段目标是让设备从交付到维保、检验准备形成可用闭环。

第三阶段:做预留能力的工程化落地

推进:

  • 子系统 E:IoT / 远程能力预留细化;
  • 子系统 F:锂电 / 市电双模式预留细化;
  • 子系统 G:外部平台对接准备。

第三阶段目标是让平台具备长期扩展能力,而不是首期即承载全部复杂度。

9. 合作边界建议

9.1 更适合高校/专业团队承接的部分

建议优先外部合作:

  • 标准电控底层体系;
  • 图纸规范;
  • 柜体和线束规范;
  • 元器件选型与 BOM 标准;
  • PLC 标准版本体系;
  • 对外接口标准与数据结构规范。

这些工作要求专业设计深度、标准化方法和工程归纳能力,适合形成横向课题或专项合作。

9.2 更适合企业内部或软件团队推进的部分

建议内部牵头:

  • 台账系统;
  • 一机一档平台的业务流程;
  • 权限和日常使用场景;
  • 资料归档策略;
  • 项目实施、培训、后续运营。

这些工作更依赖现场经验、客户场景和持续迭代能力。

10. 对产品研发的直接要求

从软件产品角度,本项目至少应同步输出以下内容:

  1. 子系统边界图;
  2. 设备主档字段模型;
  3. 台账子系统数据模型;
  4. 资料分类与导出规则;
  5. 对外接口预留规则;
  6. 状态体系与风险体系;
  7. 分阶段开发路线图。

否则项目容易停留在“图纸课题”和“平台愿景”之间,难以形成真正可落地的产品结构。

11. 可继续细化的下一层文档

在本项目框架明确后,后续可以继续拆出:

  • 标准电控底层设计交付清单;
  • 设备主档与一机一档数据字典;
  • 台账子系统详细 PRD;
  • 合规资料包模板清单;
  • 外部平台接口草案;
  • 合作课题范围、周期与报价区间说明。

12. 结论

“科杰起重标准电气系统”不应被理解为单一的电气图纸项目,而应被视作一个由标准电控底座、设备主档、一机一档、台账管理、资料输出和未来扩展接口共同构成的体系化项目。

在这个体系里:

  • 子系统 A 决定工程标准化能力;
  • 子系统 B 决定设备数字主档能力;
  • 子系统 C 决定业务落地能力;
  • 子系统 D 决定合规资料输出能力;
  • 子系统 E/F/G 决定中长期升级空间。

而第二份“台账系统”应被明确纳入其中,作为重要、半独立、可先行实施的核心子系统。