集成化定制需求下多地总装作业过程敏捷协同管控系统

莫超雄，刘建军，陈庆新，毛 宁，胡常伟

(广东工业大学 广东省计算机集成制造系统重点实验室，广东 广州 510006)

1 问题的描述

近年来，制造业服务化转型升级逐渐呈现出蓬勃发展的势头，高级服务化的制造企业仅聚焦于自营核心业务，通过集成外包的非核心业务向客户提供定制化服务[1]。例如，主要集中分布于广东省及长江三角洲等制造业发达地区的装备制造业，逐渐从单机装备制造商转变为集成化定制服务商(以下简称集成商)。

集成商面向特定行业与领域，基于定制需求集成工业机器人等自动化、智能化装备，交付非标自动化产线，提供“交钥匙工程”或EPC(engineering procurement construction)总包服务。集成商主要服务内容包括制造系统一体化设计、系列非标零部件/设备加工组装、零件/部件/设备构件及系统控制器的客户现场集成总装，最后进行全要素调试的全流程服务。如汽车零部件、3C产品和医护产品的非标自动化生产线，由集成商根据客户软硬条件以及对构件的型号、价格等个性化需求设计生产线解决方案，制造组装或外包生产控制器、机器人、伺服电机、传感器等相关中小型构件，运送到客户地并进行集成化总装。由于智能工厂的盛行和用工成本的增加，这种需要集成各种自动化、数字化与智能化中小型装备的非标定制需求，即集成化定制需求，也随之攀升。

智能制造浪潮中，集成商迅速发展，成为智能工厂重要的建设力量，然而竞争同质化严重，缺乏具有差异化的核心竞争力。目前，客户定制需求和波动大的市场需求使交付周期越来紧迫，以至于交付周期成为集成商占领市场的关键。例如新冠疫情下不同类型口罩的生产线集成化定制需求，能够快速响应并完成生产线交付的集成商可短时间内获得大批客户，把握市场主动权。在定制化方案设计能力相对成熟或确定的情况下，客户现场集成装配环节在整个交付周期的比重最大，因此能否精细化管控装配作业，以避免不必要的浪费并提高作业效率，成为当前定制化项目交付周期长短的决定性因素。

集成化定制装配作业是以手工装配为主的离散型装配，集成商根据客户需求定制工艺方案，从不同供应商订购物料到各个客户地，并调配装配人员进行异地装配，具有多地的特点(如图1)，因此称集成装配作业过程为多地总装作业。

多地总装作业过程包括物料订购、供应商协商和装配调配等多个业务流程，具有多地、多流程和多参与者的特点，而集成商这类中小企业在运营模式上随市场变动且不断发展，使业务流程具有一定的动态性。因此，在复杂的业务流程中协同客户、供应商和集成商三方的交货期需求、物料齐套协商以及装配组调配，满足集成商对管控系统的可维护性需求，实现对多地总装作业精细化管控，成为集成商亟待解决的问题之一。

国内外学者针对离散型装配过程管控问题，在物料管控、车间现场监控、生产计划和调度控制以及管控系统的质量属性方面进行了大量研究。

(1)物料管控 结合生产需求对物料进行精细化管理，以提高生产效率。杨晓英等[2]以供应链物流总成本最小为优化目标，以准时与齐套配送等为约束条件，提出由混流生产计划驱动、由物料配送期量标准及其计划控制智能决策构成的供应链物流协同策略，解决了供应链物流协同智能制造混流生产需求问题；ZHEN等[3]基于条码技术构建了物流控制系统，确保物料交付物的及时性和有效性，解决了物料库存管理和生产需求脱节的问题；刘检华等[4-6]针对复杂产品装配过程中的物料管控问题，研究了物料跟踪与管理技术、采购物料生产过程协同管理系统、物料精细化管控系统，实现了对物料的精细化管控，最终达到提高装配作业效率的目的。

(2)车间现场监控 基于生产作业流程，利用互联网、物联网相关技术，设计信息采集和监控架构或系统，通过提高车间现场信息透明度确保车间生产过程的管理效率。叶剑辉等[7]提出基于日作业计划的车间现场数据管理模型并建立基于装配工艺流程的车间现场监控模型，通过复杂产品装配车间监控看板系统实现了复杂产品装配车间现场的精细化监控；YIN等[8]提出一种用于复杂产品装配车间的智能制造模型，构建了智能制造技术体系结构及其运行模式、精益物流管理和装配过程控制；QIAN等[9]针对车间管理信息不透明的问题，提出基于系统运行模式的可视化架构和数据采集与处理的方法框架，开发能够全面详实展示车间工作状态的实时监控系统，从而提高生产过程透明度和管理效率，降低生产成本。

(3)生产计划和调度控制 结合作业流程特点与调度算法，实现对作业过程的精细化管控。刘检华等[10]针对航天装配型制造企业的单件小批量离散生产特点，提出一种基于工作流的装配车间生产过程计划和控制方法，有效描述了装配数据和装配过程间的动态交互行为，为车间制造执行提供了一条新的研究途径；万峰等[11]基于复杂产品装配调度的实际需求，通过对装配过程的可视化监控、动态调度以及对调度信息的有效管理，实现了装配计划的快速、动态调整，并保证了生产调度信息的可追溯性。

(4)管控系统质量属性 主要关注可集成、可重构和可扩展等，较少考虑因业务需求和市场环境而变更和发展所需要的系统可维护性[12]。李亚杰等[13]基于车间层对制造执行系统(Manufacturing Execution System，MES)流程的重构需求，提出一种可重构流程模型驱动的流程进化实施技术；靳国杰等[14]研究具有完整功能粒度的应用级构件的构造标准和配置机制,以及相关的组装和集成方法,作为提升构件重用能力的原理基础；王军强等[12]从系统架构设计与软件实现角度提出基于工厂方法模式的可扩展MES体系结构，建立了面向航空制造业典型离散制造车间的可扩展MES。

上述研究在装配作业过程管控问题上提供了思路和解决方案，但多地总装作业是多客户项目并行、多供应商协同异地装配的生产方式，在工艺、物料、装配人员和运营模式方面的特点使得目前研究成果虽有一定参考价值，但难以适用。表1所示为集成化定制需求下的多地总装作业与航天器、运输飞机、武器系统等为代表的典型离散型复杂产品装配作业特点的对比。

表1 集成化定制需求下的多地总装作业与典型的复杂产品装配作业的特点对比

续表1

(1)工艺 基于市场导向的定制化需求，如交货期变更、交货期承诺，会直接影响客户服务水平高低，甚至能够决定客户项目的成败。

(2)物料 以单机设备等中小型构件为主，然而客户地装配现场往往没有相关设备的保养人员，以及足够大的、单机设备专用的仓库。物料过早到达客户地，会导致物料堆积，而客户地存储容量有限，且存储条件不支持长期存储，因此对物料齐套提出了准时性要求。另外，物料主要是多品种、少批量外包生产或订购，没有长期大量供货的供应商，以至于提前期不稳定，物料到达时间随预定日期的接近渐进确定。

(3)装配人员 为了有效利用装配人员资源，采用多项目并行执行的方式，共享高级装配人员，普通装配人员驻厂，使得高级装配人员的装配任务都带有前置时间，即差旅时间。高级装配人员以装配组为单位，由于人员流动和集成商业务扩展等客观因素，装配组之间的装配技术资质和熟练度各不相同，主要区别体现在装配任务类型对资质的要求和装配工时的快慢。

(4)运营模式 集成商会因客户和市场需求的不同而采用不同的运营模式，如总承包与分包交付方式、以租代购交易方式或售卖产线生产能力的合作方式。集成商的主要业务均为订购物料、协商物料和派遣装配员，但不同运营模式会导致具体业务内容有所偏差。如有些物料一般为一次性使用，而在以租代购交易运营方式下，物料是多个客户重复使用；装配员一般由集成商派遣，而在分包交付运营模式下，装配员可能由客户方/物料供应商派遣。

针对集成商对多地总装作业过程的管控问题，本文从作业过程和系统质量属性两方面分析需求，设计基于领域驱动设计的微服务系统架构，以降低系统复杂性。在此基础上，提出基于云计算的三阶管控机制，实现对总装作业多用户的协同管控和对作业现场实况的敏捷响应，并基于SpringCloud微服务技术框架开发具有稳定性、可维护性以及低成本特点的管控系统，实现对用户赋能的目的。

2 多地总装作业过程分析

以广东佛山几家典型自动化喷釉生产线集成商为例，多地总装作业一般由工程部主办，以按需分配资源的管理方式为主，分为需求确定与定制化设计、物料订购、异地装配和客户验收4部分，如图2所示。

(1)需求确定与定制化设计 装配工艺流程是以任务节点为基本单位，由串/并联混合而成的装配工序链构成的工作流组成。任务节点属于各个客户项目，每个项目具有里程碑式交货期，具有多阶段和动态的特点。而当前的手工管理方式无法根据项目交货期的紧迫程度分配装配资源，使得客户交货期相关需求难以满足。

(2)物料订购 为了使物料能够尽早齐套，当前物料订购的做法是基于装配工艺流程图一次性订购全部所需物料，然而有限的装配能力会导致物料堆积。另外，因为物料提前期较长(一般为1个月左右)，而且装配工时不稳定性导致物料需求时间具有动态性，所以仍存在齐套准时性差的情况。

(3)异地装配 工程部以按需调配的方式派遣装配组，即当装配任务满足紧前任务逻辑约束且物料齐套时，通过人工计划和邮件/电话通知的方式派遣高级装配小组到现场装配。这种实时性差的方式容易导致装配组处在忙碌和空闲两个极端，对有限装配资源的利用效率较低。

(4)客户验收 当装配进度执行到交付任务节点时，需要联系客户方进行验收，另外安排质检也需要提前期。由于不能预知任务完成时间，导致项目会因等待质检而停滞。

分析可知，现行的多地总装作业管理方式无法响应客户交货期需求，存在物料齐套准时性差的问题，而且高级装配组调度困难并有等待浪费现象，可将问题归结为作业过程信息化问题和计划控制问题，一方面需要通过动态的有限能力计划，对物料和装配组进行精细化管控，以响应客户交货期需求；另一方面需要规范和信息化作业过程，使集成商能够敏捷反应现场情况并下发作业指令，确保对装配现场计划和调度控制的有效性。

3 集成商管控系统需求分析

通过对珠三角地区的集成商调研得知，当前的集成商普遍具有一定的信息化基础。例如，在企业资源计划(Enterprise Resource Planning, ERP)系统中实现客户需求设计及其具体集成装配设计、客户信息、供应商信息等进销存业务。然而，在装配制造执行环节按需分配装配资源，沿用“电话—邮件—会议”的传统手工管理方式，存在客户服务水平低、等待浪费严重和作业过程不透明的现象。

IEC/ISO 62264系列国际标准对企业制造执行过程给出了MES参考解决方案，通过生产、质量、维护和库存4方面运行模块解决执行管控问题，具有较强的归纳性和普遍性。然而由于多地总装作业过程业务场景的特殊性，需要更强的具有针对性和可操作性的智能化MES。

多地总装作业过程包括物料订购、协调物料到达时间、装配人员调度派遣、客户验收等多个业务流程，使管控比较困难。其中涉及多个客户的交货期需求、多个供应商的物料供应以及多个装配组的调配，有跨企业、跨部门多用户协同的特点，而且客户、供应商和集成商自身往往也有业务管理系统。另外，集成商以中小企业居多，在经营模式上会随市场需求而变动，例如虽以项目总承包为主业，但也会承担分包业务，使得业务管控需求具有一定的动态性。因此，多地总装作业过程管控系统不仅需要在设计上优化管理多个业务流程，敏捷响应装配现场状况，提高执行效率，还要在开发实现上考虑系统的成本和可维护性。

当前制造执行管控系统的开发以单体架构和面向服务的架构(Service Oriented Architecture，SOA)为主[14]，难以满足集成商对系统的要求，如业务流程的变更、算法能力的优化提升或集成其他系统。由于单体架构的强耦合性和SOA中企业服务总线(Enterprise Service Bus，ESB)方式的维护复杂性，使得系统维护困难、成本高、时间长，以至于集成商这类中小型企业虽然知道信息化能够提高效率，但是难以承担风险而选择沿用手工方式。

集成商的运营模式日新月异，带来了诸多管控难题，而互联网、物联网等技术迅速发展，为解决难题带来了多种解决方法。为满足软件系统用户的服务集成和多样化系统需求，衍生出了拥有独立进程和部署能力的、基于SOA的微服务技术。LEWIS等[15]在2014年首次提出微服务一词，将微服务架构定义为一种构造方式，将一套小型服务(微服务)组合构造成单个应用程序。其中，微服务的特点是在进程上相互独立，在交互上使用轻量级通信机制。虽然学术界对微服务架构的研究仍处于早期阶段[16]，但是在工业界已经有许多成功应用，如微信和优步。此外，微服务的业界应用还有丰富的微服务开源解决方案，如能够构建一套完整微服务架构技术生态链的SpringCloud框架、阿里巴巴电商平台探索开发的Dubbo框架以及微软专门针对模块化微服务架构设计的.NET Core框架等。

与单体架构相比，微服务架构的逻辑单元清晰、开发迭代速度快、维护方便、伸缩性好、容错性好[17]；与传统SOA相比，微服务架构采用表述性状态传递(Representational State Transfer，REST)更加轻量级的通信机制，代替了SOA的简单对象访问协议(Simple Object Access Protocol，SOAP)机制，具有服务定义粒度细、服务边界划分清晰的优势。

作为当前软件体系结构的新趋势，微服务强调高度可维护和可扩展性，能够快速响应个性化的开发需求，具有可集成性[18]。因此，考虑集成商业务流程的复杂性及其发展所带来的动态性特点，采用微服务架构能够很好地降低业务逻辑开发的复杂性和成本，满足可维护性的需求。

4 微服务系统总体架构

通过分析多地总装作业过程可知，集成商在业务管控上有敏捷响应和多用户协同的需求，在系统技术实现上需要降低复杂度和成本，并具备可维护性。对此，本文基于领域驱动设计的分层方法，构建了基于微服务架构的多地总装作业过程敏捷—协同管控系统。

4.1 分层设计

传统的分层设计主要分为表现层、业务逻辑层和数据访问层3层架构，缺少对基础服务的划分，如请求网关、服务治理相关服务，对微服务这类新兴架构不够友好；另外，过于强调数据访问层，使得业务逻辑层和数据访问层之间存在依赖关系。即使业务发生小变更，系统开发人员也不得不首先关注数据表设计，无疑增大了系统维护成本。

因此，基于领域驱动设计(Domain-Driven Design, DDD)的分层结构设计方法[19]，本文将微服务架构系统从上层到底层依次设计为用户接口层、应用服务层、领域服务层和基础设施层，明确了层级职能(如表2)和协作方式。

表2 基于领域驱动设计的微服务系统分层

4.2 层间协作

各层之间保持高内聚低耦合，即上层只依赖于其下方的层，下层向上层只能通过通信中间件通信，层间协作实现了系统的数据输入、数据处理和数据输出。

(1)数据输入 由用户接口层从外部接口/移动/PC/Web端获取数据，如ERP系统或人工输入的装配工艺流程、装配组/供应商信息及装配现场数据等，输入到应用服务层，然后调用基础措施层的数据持久化服务和领域服务层的数据处理相关服务。

(2)数据处理 由应用服务层驱动并传输必要的数据到领域服务层的服务体进行逻辑运算，再将处理结果返回给应用服务层。即应用服务层依赖于领域服务层，领域服务层通过应用层间接地进行数据持久化。

(3)数据输出 基于业务需求，应用服务层根据前端用户需求，对领域服务层的一个或多个服务体返回的数据做出必要的数据转换处理，并通过用户接口层输出展示。

4.3 总体架构设计

基于上述理念，系统架构设计如图3所示。系统架构将业务流部分抽象到应用服务层，将数据处理功能抽象到领域服务层并与业务流和数据流解耦，使得业务流程变动不直接影响数据处理功能，同时数据处理功能的优化升级或变更也不直接依赖于持久化数据库。这种架构设计方式使管控系统的数据输入输出、业务逻辑、算法处理及数据持久化各部分不但界限划分清晰，而且内聚化、低耦合，降低了系统多业务流程、多用户所带来的技术实现复杂度，提高了系统的可维护性。

5 基于云计算的三阶段管控机制

多地总装作业包括需求确定与定制化设计、物料订购、供应商协商、装配员调配和客户验收多个业务流程，存在客户交货期需求变更、物料齐套时间渐进确定和装配工时不稳定等装配现场多变的情况，涉及物料管理员、供应商、普通/高级装配组和客户多个参与者，为解决其中作业过程信息化问题和计划控制问题，本文提出一种能够协同多用户多流程、敏捷响应装配现场的基于云计算的三阶段管控机制，如图4所示。

5.1 管控机制相关对象说明

三阶段管控机制针对集成商行业中具体的业务场景而设计，涉及较多行业相关的名词对象，其中重复出现对象采用[#1,#2,#3，…]序号区别。以图4为例，具体说明如下：

(1)装配工艺流程图由串/并行工作节点组成，每个节点代表一个工作流，即装配任务，包括任务名称、标准工时、装配任务类型和里程碑式交货期，同时对应以中小型构件为主的物料清单，如图5所示。其中装配任务类型(如执行模块、辅助模块等)限定了装配组的资质。实际工时取决于标准工时和装配组的熟练度。另外，每个工艺流程图均对应客户项目，具有相关的项目文档，包括装配地点、客户等级和具体技术工艺。

(2)装配任务池装配工艺流程图通过业务规则计算处理后，得到多个与实际装配任务/工作节点/工作流一一映射的对象实体，该实体包括装配任务的所有属性和状态，存放在装配任务池中，可将每个装配任务视作Agent个体。

(3)装配任务的生命周期有3种状态，即未订购物料、距离物料齐套时间大于一个星期、距离物料齐套时间小于等于一个星期，将其划分为#1，#2，#3共3个装配任务列表，分别对应管控机制的3个阶段。

(4)云端算法集群共有3个算法集群，均部署到云端。输入为装配任务和实况约束，即当装配任务和实况约束更新时会驱动算法；输出为基于有限能力的总装计划。数据运算处理采用分层多目标的方式，即根据其所在阶段的目的和特征而采用不同的算法和优化目标，如表3所示。优化目标中，min{E/T惩罚}指最小化提前/延期惩罚，追求项目完工的准时性；3个时间一致指总装计划的最早开始时间、物料齐套时间和装配组齐套时间趋于一致，追求减少互相等待浪费；min{差旅时间}为最小化差旅时间，追求减少无效差旅带来的装配组资源浪费。另外，算法应用部分并非固定为本文所述的算法，可引用其他已验证调度优化有效的算法。

(5)总装计划由算法集群计算而得，基于总装计划，通过业务规则计算出订购计划、需求时间表和作业计划。总装计划包括5个时间：最早开始时间取决于该任务的紧前任务的结束时间；物料齐套时间指装配任务物料清单都到达的时间；装配组齐套时间指任务所需要的装配组全部到齐的时间；计划开始时间指前面3个时间中最大的时间；计划结束时间指计划开始时间加标准装配工时与装配组熟练度的乘积。总装计划示例如图6所示。

表3 分层多目标

(6)实况约束指实时装配资源的占用情况，是算法优化计算有限能力总装计划的基础。整个机制有3种，均由装配任务实际开始时间、实际完工时间和物料预计到达时间组成。实况约束#3由装配组和物料供应商实时反馈，经过下达阶段的总装计划占用装配组资源后更新#3得到#2，同理得到#1。上述实况反馈方式能够确保排程约束的实时性，进而使得每个阶段的算法排程得到的计划是基于当前集成商的有限能力。

(7)业务规则指根据实际业务场景得到的对数据进行逻辑处理的规则，管控机制中有#1，#2，#3，#4，#5共5个业务规则，具体内容配置示例如表4所示。业务规则并非一成不变，当业务场景或集成商的运营策略发生变更时，业务规则随之变更。

表4 业务规则说明

5.2 管控机制运行步骤

管控机制以装配任务为主要对象，采用云端算法集群、分层多目标优化以及辅助人工审核管控的运作方式，具体运行步骤如下：

步骤1在任务输入阶段，客户提出的定制化需求、质检后返工返修工单和交货期相关需求(如交货期推迟/提前)，由集成商的其他部门处理，得到的最终结果均以装配工艺流程图的形式保存。本文以ERP系统应用程序接口(Application Programming Interface, API)方式获取工艺流程图，将通过规则处理得到的装配任务池作为三阶段管控机制的数据输入口。

步骤2在队列阶段，主要目的是确定订购物料时间。在装配任务池中，未订购物料的装配任务会在此阶段排程。基于实况约束，通过云端算法集群进行集中式调度排程得到总装计划，再经过业务规则处理得到物料订购计划，由物料管理员审核/修改后形成订购指令下发给物料供应商。其中总装计划、订购计划等计划是动态的，会随算法输入的更新而不断刷新变动，只有当人工审核/修改变成指令后才停止变动，确定为作业执行依据。

步骤3缓存阶段，该阶段以协调物料到达时间为目的。在装配任务池中，已订购物料但距离物料到达时间超过1个星期的装配任务会在此阶段排程，类似于队列阶段的处理流程。由于装配现场的动态性以及要求物料齐套的准时性要求，物料需求时间会随资源约束的变化而变更。该时间在发生变更时通知物料供应商，由供应商自主做出变更预计到达时间的反馈，必要时物料管理员会通过线下协商方式(如电话/邮件)进一步确定时间或催料。

步骤4下达阶段，该阶段以装配组调配为目的。在装配任务池中，已订购物料且物料预计到达时间小于1个星期的装配任务会在此阶段排程。经过算法、规则处理后得到装配作业指令来指导装配组执行任务，开始或完成一项任务时会反馈相关时间。其中，基于总装作业过程多地的特点，装配员使用的APP具有实时定位功能，当装配员到达客户地后会直接反馈装配任务的开始时间并计算装配工时，能够预警提醒装配员反馈完工时间。这种方式解决了以人为主的手工装配所带来的监控困难和报工不准确问题。

步骤5质检交付，该阶段以反馈实况约束和质检交付为目的。监听物料供应商和装配组反馈的开工/完工时间与物料预计到达时间，计算得到的实况约束作为上3个阶段调度排程和质检交付的依据。其中，质检交付在项目中以里程碑的形式存在，由客户执行。质检后，移除装配任务池中相关的装配任务，若需要返修返工则转步骤1，重新进入装配任务池中。同理，装配任务需求变更会在任务池中进行。

5.3 管控机制的优势

通过上述分析说明，相对于第2章和第3章的现行手工管理方式，本文提出的管控机制具有滚动优化、整体联动(如图7)和云端计算的优势。

(1)滚动优化 随着装配任务的状态变更而采用不同的优化方法，当装配任务持续输入时形成滚动优化的方式。该方式得到的总装计划，分别在不同阶段协同客户、供应商和集成商完成物料订购、物料到达时间协商、装配组调配和质检交付，即能在多业务流程的情况下协同多用户优化装配相关计划，相比于传统手工管理方式，实现了对多地总装作业过程的精细化协同管控。

(2)整体联动 集成商传统管理方式中也曾存在过人工/机器编排生产计划，之所以舍弃这种方式并采用按需调配装配组，是因为原先生产计划存在计划可执行性差的问题。对此，本文管控机制计算出的计划均基于集成商的有限能力/资源等约束，即能够敏捷响应装配现场中的客户、供应商和装配车间约束，实时更新计划以确保计划的可执行性。

(3)云端算法 管控机制的滚动优化、整体联动特点虽然带来了协同管控、敏捷响应的优势，但也对运作机制的算力提出更高要求，需要整个机制持续不断地进行实时运算。集成商多为追求低成本、高计算性能的中小型企业，而服务器的购买成本和维护成本高昂，因此机制中最消耗算力的算法处理部分采用云端算法集群的方式。基于云计算中的基础设施即服务(Infrastructure as a Service，IaaS)计算服务，将多个算法以容器化的微服务集群部署到云端。每个算法集群包含多个重复/非重复的优化算法，并规定了优化目标和输入输出。当更新输入数据时，将自动调用云算法集群，以RESTful API(representational state transfer fulAPI)方式传送约束和任务的JavaScript对象表示法(JavaScript Object Notation, JSON)数据包到云端算法集群，以轮询为默认方式进行计算，不断将结果用json返回总装计划，直至轮询完所有算法。其中，项目管理员不仅可以手动选择算法计算，还可以在不影响机制运作的情况下对集群中的算法进行优化升级或删减处理。

6 微服务系统开发实现

集成商作业管控数字化转型的关键阻力之一是成本问题，市面上的管控系统成本普遍需要数十或上百万人民币，甚至超过集成商的年收益，而且集成商对管控系统需求具有动态性，导致系统应用效果难以保证，具有高额成本风险，使得集成商望而止步。因此，系统非常有必要从开发、上线发布以及后续维护的各个环节尽可能降低成本风险。

相对于传统管控系统的单体架构、SOA架构，微服务系统更适用于逻辑和需求复杂的业务场景，其不仅具有可扩展、可集成、可维护等系统质量属性方面的优势，同时，采用微服务架构开发方式能够缩短开发周期，降低开发和维护成本。因此，在作业管控系统方面，作为中小型企业的集成商应用微服务架构进行开发实现是目前比较合适的选择。

系统的微服务化也带来了诸多挑战，尤其是与服务治理相关的服务注册与发现、配置管理、负载均衡、服务通信等，是开发实现微服务系统的必经之路。工业界对微服务已经有了大量实践经验，并开源了多个微服务框架，帮助系统开发人员实现微服务系统。主流微服务开源框架有Dubbo，SpringCloud，Istio，如表5所示。相对于互联网企业软件来说，制造企业的业务系统主要关注系统的维护性和成本问题，对高并发、多线程等性能方面要求较低。因此，由对比可知SpringCloud稳定、成本低、开发速度快的特点更加切合集成商对实现管控系统的要求。

表5 主流微服务开源技术框架对比

续表5

6.1 基于SpringCloud的系统实现技术

针对构建分布式系统容易出错和技术复杂的难题，SpringCloud为最常见的分布式系统，例如微服务系统提供了一种简单且可读性高的编程模型，帮助系统开发人员构建弹性的、可靠的、协调的应用程序。SpringCloud构建于SpringBoot之上，其提供了能够一键启动部署的一站式微服务系统架构解决方案(如图8)，开发者容易入手并将其快速应用于生产。下面给出主要运行步骤，由于体系庞大，此处仅展示说明关键部分示例，可通过Spring官网(https://spring.io/)查看全部组件说明。

步骤1外部请求统一先到达SpringCloud Gateway的API网关，基于从注册中心(Eureka)获取的可用服务信息，由Ribbon进行负载均衡，重定向到对应的内部服务。

步骤2微服务之间通过Feign进行通信和处理业务，并通过组件进行服务治理，以确保微服务系统的稳定性。相关的服务治理组件有配置中心(Config)、熔断器(Hystrix)、监控系统(ELK)等，其中各个组件都属于SpringCloud技术框架，均支持SpringBoot开发风格的一键启动和部署。

6.1.1 管控系统技术架构

考虑集成商成本低、可维护的系统质量需求和管控机制滚动优化协同多用户、敏捷响应装配现场扰动的特点，通过分析微服务系统的实现技术框架，设计了基于SpringCloud的管控系统技术架构，如图9所示，其中黑色加粗的线框表示系统的前端和后端。

6.1.2 关键开发技术说明

基于SpringCloud的技术框架解决了管控系统开发需求和开发实现中遇到的主要问题，包括前后端分离、安全认证与鉴权、数据存储、负载均衡、云端部署和系统可用性。

(1)前后端分离 因为部分客户/供应商有管控系统以及集成商本身的EPR系统，需要以OpenAPI集成的方式对接，同时为了满足用户使用便利的需求，需配备Web，OpenAPI，PC，APP多种应用端口，另外第4章的总体架构图将前端单独列为用户接口层以对前端展示和业务处理之间进行解耦，以确保系统可维护，所以采用前后端分离的开发方式，前端基于VUE.js和Node.js技术框架开发，其服务器采用Nginx，存放超文本标记语言(Hyper Text Markup Language，HTML)、层叠样式表(Cascading Style Sheets，CSS)、JS(Java Script)等静态资源，负责控制页面引用、路由和跳转。用户端发送请求时会直达前端的HTML页面，以AJAX(asynchronous Javascript and XML)异步的方式调用后端的RESTfulAPI接口，并采用JSON数据进行交互，达到前后端分离解耦的目的。只要通过部分代码重构，就能大量复用API接口，从而提高多端应用的开发效率。

(2)安全认证与鉴权 管控系统涉及多用户，尤其是来自企业外部的用户，如客户和供应商，需要限制不同用户的不同访问权限等级以保障信息安全。另外，微服务架构中的每个微服务相当于个体，访问调用也需要鉴权，传统单体架构采用的session认证方式使得微服务被调用时占用大量内存，而且每个微服务都要进行一次鉴权，导致代码冗余。对此，采用SpringCloud Gateway和JWT(JSON Web Token)规范解决，首先用户通过网关和后台的用户管理微服务初步验证登录账号密码，成功后签发JWTToken信息给用户，用户后续的访问都会携带TOKEN，由SpringCloud Gateway网关进行过滤鉴权，判断是否有权限，有则放行，无则返回未认证错误，最终完成单点登录。

(3)数据存储 数据存储是管控系统运行的基础保障，可将管控系统产生的数据分为文件数据、缓存数据和持久化数据3类。文件数据指Word/Excel或图片等小文件，例如装配工艺文档采用FASTDFS存储，以实现对文件的存储、同步、访问等管理功能；缓存数据指系统中算法部分所持续产生的、动态的总装计划，采用Redis高性能数据库，以满足数据频繁增删查改所带来的性能需求；持久化数据指系统中由人工审核修改后的指令、装配进度数据等，采用体积小、速度快、总体拥有成本低的开源数据库MySQL。

(4)负载均衡 负载均衡的方式是分别以单个微服务部署到云端形成算法集群，以轮询方式进行调用。对此，采用Ribbon组件，该组件的轮询策略能够对各个微服务进行逐个调用；重试机制能够识别并跳过无法使用的微服务而调用集群内的其他微服务。这种云端算法集群方式，不仅能够使用多种算法运算来提高优化程度，还能在不停止管控系统运行的前提下对算法进行优化升级或者增删算法。

(5)云端部署 为降低集成商在系统所需服务器方面的硬件和管理成本，将最消耗算力的算法部分部署到云端。对此，在云端部署方面，采用的是弹性计算服务器(Elastic Compute Service，ECS)，ECS相当于一台虚拟服务器的实例，包含操作系统或软件的镜像、高性能低时延的块存储等，具有性能高、稳定可靠且能弹性扩展的特点。发展成熟的云计算服务使得ECS的部署变得简单高效，首先配置云服务器相关的安全组规则、密钥以及微服务相关的运行环境，然后将微服务打包成Java归档(Java Archive，JAR)上传到云端部署启动即可完成部署。

(6)系统可用性 管控系统由多个微服务组成，服务间的互相调用使其之间存在耦合，若某个微服务宕机，则易产生雪崩效应。对此，采用RabbitMQ消息队列对需要频繁传输数据的微服务进行解耦，采用Hystrix熔断器服务降级模式避免雪崩效应，以提高系统的可用性。

6.1.3 系统质量优势

系统质量的优劣直接影响系统应用效果，是系统最终落地应用的关键因素。因此，本文系统设计方面，考虑了开发效率、稳定性和可维护性3方面的系统质量属性。

(1)开发效率 系统基于SpringCloud技术框架开发，可直接使用该框架的原生组件进行微服务治理，并结合SpringBoot开发风格进一步提高开发速度。例如，本文管控系统中的SpringCloud Hystrix熔断器使用非常简便，能够大大降低开发人员的工作量，其创建代码如下：

@SpringBootApplication

@EnableCircuitBreaker

public classHystrixMSCApplication {

public static void main(String[]args){

new SpringApplicationBuilder(HystrixMSCApplication.class).web(true).run(args);

}

}

同时，由于SpringCloud微服务为主流技术栈，国内具备相关技术的程序员数量充足，集成商后续对系统进行迭代更新和运维的人力成本不高。另外，将比较耗算力的算法部分部署到云端，降低了服务器成本。

(2)稳定性 微服务架构将单体应用拆分为多个微服务，在拥有能够解耦、易于开发维护、可伸缩性高等优势的同时，对服务治理形成了挑战。SpringCloud来源于Spring，经过Netflix网站的实践，在质量、持续性、项目社区活跃度、文档成熟度等方面都可以得到保证。本文采用其熔断器、消息队列、负载均衡等服务治理技术来确保系统的可用性，出现故障时也能够利用其成熟的社区文档来解决，因此稳定性较高。

(3)可维护性 基于第4章的分层设计，其将业务逻辑、持久化数据库与算法处理解耦，并以单个微服务的形式存在。发展集成商运营模式而导致的业务逻辑变更或对算法处理部分的优化升级，均能够在不影响系统运行的情况下进行，直接修改相对应的微服务即可，因此具有可维护性。

6.2 装配现场监控

与普通的装配作业不同，多地总装作业是需要协同客户和供应商、以手工为主的异地装配。一方面手工装配的装配作业监控对象是人，现行的监控方式是靠人工主动报工，存在报工工作量大、数据完整性和实时性差的问题；另一方面，装配现场情况包括与客户需求相关的装配任务和供应商的物料供应，具有跨企业的特点。对此，管控系统通过API方式连接集成商的ERP系统，实时监听并响应客户需求，取代了传统邮件、会议等时效性差的方式；考虑到客户和供应商自身也存在信息系统，提供Web和API接口两种方式对接，实现了跨企业协同；采用手机APP定位方式自动采集装配员的作业信息和预警报工，使报工具有便利性和实时性，最终完成对装配现场情况的数据采集。

管控系统虽然能够基于实时采集的数据自动生成计划排程，但是由于整个装配作业过程的复杂性，最终的执行指令仍需由管理员进行人工审核，审核修改的依据为管理员自身的管理经验以及装配现场情况。对此，设计了基于“绩效—计划—排程”的数据可视化大屏，如图10所示。其中：绩效指过去已经发生的作业；计划指在绩效的基础上，叠加已被管理员审核通过的计划部分，旨在预测即将发生的装配作业情况；排程指当前算法排程的结果，旨在反映当前装配资源是否充足。考虑到总装作业多地的特点和管理员查看数据的便利性，设计了以地图形式展示各个客户地，可直接点击地点查看作业情况。

7 系统应用分析

7.1 系统使用流程

管控系统采用多种终端实现了对多地总装作业过程的敏捷—协同管控。系统尽可能地将业务逻辑处理、算法处理等过程封装在系统内部，用户仅需在系统所生成计划的基础上审核修改即可作为作业指令，通过终端指导和预警用户执行任务，从而提高管控效率，达到对用户赋能的目的。以广东佛山某喷釉产线集成商的应用为例，系统使用流程统一建模语言(Unified Modeling Language，UML)时序图如图11所示，作业过程相关人员只需审核修改系统生成的计划指令、执行指令和反馈报工，尽可能地简化用户的操作流程，以减少系统实施成本。同时，用户端也追求极简化，使用界面以装配员APP为例，仅展示作业情况、报工和通信3种必要的页面，如图12所示。

7.2 系统优势

相比于传统手工管理方式和市面上普通的MES系统，管控系统应用在集成商作业过程的优势如表6所示。系统通过多端应用和可视化大屏提高管控信息传达效率，使装配作业情况透明化；基于云计算的三阶管控机制能够敏捷响应装配作业现场中的客户需求，以及供应商的物料供应和装配员的作业进度情况，以分层多目标和云端算法的方式实时排程出有限能力计划，并结合人工审核方式实现多用户跨企业协同；基于领域驱动设计的分层思想和SpringCloud微服务技术框架，开发具有可维护性、成本低的管控系统，满足集成商对系统质量属性的要求。

表6 管控系统优势

8 结束语

本文针对集成商的作业管控特点和现状，分析了作业过程存在的问题和系统质量属性需求，设计并开发了多地总装作业敏捷—协同管控系统替代传统手工管理模式，提高了作业管控效率。在架构方面，基于领域驱动设计的分层方法设计了高内聚低耦合的微服务系统架构；在运行机制方面，提出基于云计算的三阶管控机制，实现了敏捷响应装配现场和跨企业协同多用户的精细化管控；在开发实现方面，基于SpringCloud技术框架，运用前后端分离、安全认证与鉴权、云端部署等技术，使系统具有稳定性、可维护性和低成本的特点。最后，以广东佛山某喷釉产线集成商的应用为例，阐述了使用流程，并对比分析了系统优势。

管控系统虽然初步满足了集成商对作业过程信息化、生产计划控制及系统质量属性方面的需求，但仍存在计划排程结果优度一般、疲于应付多种运营模式的问题。未来的研究将集中在：①对云端算法部分进行升级，提高优化效果；②收集归纳各种常用的运营模式，抽象出一个可二次开发的标准化业务逻辑，减少运行模式变更带来的工作量；③微服务之间仍然存在依赖，后续可运用ServiceMesh架构对微服务之间继续解耦，进一步提高系统的可维护性；④航空制造业中某些企业在装配作业环节也采用异地装配模式，具有“多地”的特点，后续可针对航空领域特点，研究本文管控系统的二次开发和应用。