时至今日，从互联网转到制造业领域已经一年半了，去年我写过一篇对当时业务流程闭环的思考：制造业领域，我是如何被逼到做顶级架构设计的，也在这半年的SOP中，慢慢将缺失不足的环节给填上。
其间通过这一年半的前端基建，也总结了一套前端在制造业领域做产品设计的方案，将其中架构设计部分已开源gbeata-admin，也欢迎大家指点和共建~
回到生存这个话题，想要将互联网思维带到制造业，其实有很多好玩且很大的发展空间，但回归到本质，制造业面向的用户群体偏保守，很多激进的做法和产品力，客户其实并不买单，他们想要的是稳定且可靠的产品。这对于研发的要求，更该从极致化轻量交付为目标去做设计。
下面，我将围绕着在机器人交付过程中的每个环节，来讲解前端如何做好玩且实用的架构设计。
机器人作业流程解析
这是一台标准无人化搬运机器人作业的完整流程，下面介绍几个关键的应用系统来理解整个流程是如何串联起来使能。
🕐 第一步：采集数据-地图编辑器
使用 C++ 编写的一个可视化客户端，其目的就是将场内CAD文件转换成上层应用系统可使用的数据，当然，精确的坐标还需要依托于机器人的slam导航或者是反光板导航来录入精准定位。当然车辆在真正行驶过程，如何规划路径，防止碰撞，偏移调整之类的，这个在地图编辑器阶段并不能完全控制，更多的时候，我们会在车辆在试运行过程中，不断去设置偏移值，来达到与场内各参数吻合。
到这里，车辆与地图编辑器之间，他们就需要一个能实时同步的机制，这些都是依赖于车载中的RCS调度系统将感应器雷达采集的数据通过MQ实时与地图编辑器同步数据。
这个环节，前端目前没法直接干涉到流程，在整个流程闭环中，仓库编辑器更多的是采集数据的角色。
🕑 第二步：RCS导入坐标系数据
实时查看场内机器人运行状态与布局，通过加载地图编辑器中生成的zar文件，导入在地图编辑器中的数据。这样，我们就可以在rcs调度系统中，实时给车辆下发点到点的任务，当然具体的车辆行驶路径，则由规划团队通过调度算法去控制车辆的行走。
从这一端开始，前端就真正开始介入流程中的控制与设计，监控平台用到的技术栈主要是图表类插件与konvas.js实现。 在设计上采用微前端作为基座设计，将整体界面拆分成基座主应用与监控、管理系统两个字应用，为了更好的方便将监控平台作为大屏展示拆分出来。
从这里，就已经可以开始做架构设计了，首先组件层面，包含可视化（echarts-for-react、konva.js）、动画（react-spring/web）、表单表格（formik-mui、material-react-table），系统设计采用qiankun作为微前端设计。将整套RCS产品各端所需要用到的基础功能组件先做封装。
开源框架使用的是国内更容易被接受的antd作为基础组件，所以并没有将mui系列的设计迁移出来。若感兴趣的小伙伴，随时欢迎加我交流
RCS在整个流程闭环过程中，重要的一点，就是它使地图编辑器中的数据转换成我们在web端能加载的数据，同时拿到车辆的实时状态与执行任务的结果。为后续的系统对接做铺垫。
🕒 第三步：坐标系同步
rcs系统会将生成的点位数据，同步到其他系统，用于作为基础数据源处理，例如，wms仓库管理系统会将库位、巷道、区域以及货架与rcs中的坐标点关联，这样，在场内的工作人员，即可根据库位的状态，来决定是否调度车辆来执行任务，有主动通知也有被动通知， WCS会监测场内的设备，由设备产生的通知指令，决定是否下发任务。
以下为库位编辑器的操作，其目的就是基于RCS的点位，绘制库位与巷道，将点位与具体的实体关联起来。
不难看出两套系统都有可视化需求，且他们都有一定的共性。都是基于同一份数据，且需要动态展示并且编辑可视化内容。
此时，就可以在封装的功能型
konva.js组件的基础上做扩展，封装为业务型组件，为跨端系统提供统一的业务支撑。
🕓 第四步：下发任务
通过WMS pad端下发的任务，最终会经过WCS系统的任务处理，拆解成RCS能执行的任务组合，再下发给RCS调度系统。
🕕 第六步：执行任务
RCS调度系统通过拆解后的任务组，通知车辆执行点到点任务一个任务由多个子任务组成，同时车辆的执行结果，会通过特定的通讯机制（TCP...），实时将结果反馈给RCS调度系统，变更状态，这样我们就可以在RCS监控大屏实时查看到车辆的运动轨迹和状态。
思考
到此，一条完整的业务主线，就已经完成，当然还有一个反向的流程，也就是结果反馈上报，但这属于业务流程，实际上还是通过这几套系统来完成，从最上面的流程图也能看出来。
几套系统之间，他们之间始终都贯穿着地图坐标数据流，所以，在monorepo设计上，我们可以将api与store从系统中抽离，分别单独使用两个包作为管理，围绕着数据流与状态去做业务型组件设计，最终你会发现，系统层只是将各包组件组装起来而已。
项目的公共基础配置， 如layout、公共组件、统一样式token、国际化等等，完全可以在独立于系统之外的包作为统一管理和配置。
当然
我们已经讲完公共功能组件设计、业务组件设计、系统共用模块的封装与抽离，我们依然可以在系统级做封装，比如我们可以使用plop或者是自己封装CLI来统一管理系统模板，方便在产品线上，能快速的启动包含了公共配置的模板来开发～
好了，今天的分享就到这吧～ 因为是特定行业，围绕着业务去讲架构设计，对于大部分来说不是那么好理解。O(∩_∩)O哈哈~