Pack artificial station management method and system based on workflow and extensible mode

Abstract

The application discloses a PACK artificial station management method and system based on a work flow and an extensible mode, and the method comprises the following steps: establishing process route configuration data of a three-level management structure on a server, wherein each working step is a pluggable module inherited from a preset working step base class, and the behavior of the working step is defined through a three-stage life cycle method including an initialization stage, an execution stage and a recovery stage; saving the hardware resource information of each station in the form of measuring points in a database in a unified and abstract manner; pulling the process route configuration data from the server and sequentially loading each working step when the client starts, and the working step can be selectively suspended and save the execution context in the execution stage, and the working step is recovered from the breakpoint to resume the execution in the recovery stage in response to an external signal; decoupling communication between the working step execution state and the UI display layer is realized through the event bus publishing field events; and the process progress data is associated with the product code and written into a trace information table. The application significantly reduces the development and maintenance cost of the PACK production line artificial station.

Description

Technical Field

[0001] This invention belongs to the field of intelligent manufacturing and industrial automation technology, specifically relating to a PACK manual station management method and system based on workflow and scalable mode. Background Technology

[0002] A PACK production line is a production line that achieves intelligent and automated production of battery packs. It connects automated equipment in upstream and downstream processes to automate battery production. Key processes are completed by automated equipment, and programs monitor the battery status during production to ensure battery pack quality and improve production efficiency. In the PACK production line, manual stations handle critical processes such as barcode scanning, weighing, tightening, and release. The flexibility of the management system directly impacts the production line's delivery efficiency and maintenance costs.

[0003] However, existing PACK manual station management systems generally suffer from the following technical problems: deep coupling between process logic and code, requiring modification of source code and recompilation and deployment when adding or modifying processes, making them unable to adapt to frequent changes in process routes under specific scenarios; intertwined MES API calls, data storage, and interface rendering, where any minor change may affect multiple modules of the system, resulting in high maintenance costs and significant upgrade risks; the various brands of barcode scanners, tightening guns, weighing instruments, and other equipment used on production lines, requiring existing systems to develop dedicated communication code for each brand, leading to a large workload for hardware adaptation; the need to write interface code from scratch for each new production line due to different MES vendors, resulting in poor universality; and the inability to accurately recover from breakpoints after power outages, network fluctuations, or other interruptions during process execution, leading to duplicate operations or data loss.

[0004] In summary, the existing PACK manual station management system has many technical problems, such as hard-coded processes, tightly coupled architecture, high hardware adaptation costs, strong dependence on MES, and difficulty in interrupt recovery. Summary of the Invention

[0005] The purpose of this invention is to provide a PACK manual station management method and system based on workflow and scalable mode, which aims to solve the technical problems existing in the prior art, such as the inflexibility of hard-coded processes, high hardware adaptation costs, difficulty in switching MES systems, and inability to accurately recover after process interruption.

[0006] To achieve the above objectives, a specific embodiment of the present invention provides a PACK manual station management method based on workflow and scalable mode, the method comprising the following steps: S1. Establish process route configuration data with a three-level control structure on the server side. The three-level control structure includes process route, process, and process step. The process route defines the complete processing sequence of the product and is composed of multiple processes connected in series or in parallel. Each process corresponds to one or more workstations. Each process step is a pluggable module that inherits from a preset process step base class and defines its behavior through a three-stage lifecycle method, which includes an initialization stage, an execution stage, and a recovery stage. S2. The hardware resource information of each workstation is uniformly abstracted and stored in the database in the form of measurement points; S3. When the client starts, it pulls the process route configuration data corresponding to the current workstation from the server and loads each process step in sequence according to the process order. When each process step is executed, the three-stage lifecycle method is called in sequence. During the execution phase, the current process step can be selectively suspended and the execution context can be saved. During the recovery phase, execution can be resumed from the interruption point in response to external signals. S4. Publish domain events through the event bus to achieve decoupled communication between the process execution state and the UI display layer; S5. Link process progress data with product codes and write them into the traceability information table to support querying completed tasks and rework operations.

[0007] In one or more embodiments of the present invention, the hardware resources mentioned in step S2, which are uniformly abstracted in the form of measurement points, specifically include: Define a standardized measurement point structure for each hardware device, the measurement point structure including device identifier, data type and communication protocol; The same type of hardware devices from different brands use the same measurement point abstract interface, so there is no need to modify the process business logic when changing hardware devices or communication methods.

[0008] In one or more embodiments of the present invention, the method further includes a factory MES hot-plugging step: Define an abstract MES adapter interface layer, through which general processes interact with the MES system; Develop corresponding adapter implementation classes for the MES systems of different factories, and dynamically inject the corresponding MES adapter instance for the current factory at runtime through dependency injection; When switching MES systems, only the adapter injection configuration in the configuration file needs to be modified and the client needs to be restarted; the process logic code does not need to be modified.

[0009] In one or more embodiments of the present invention, suspending the current process step and saving the execution context in step S3 specifically includes: The current execution context is serialized into data and stored in the traceability information table. The execution context includes product code, workstation information, and a list of completed steps. A version identifier is written into the serialized data, and the corresponding deserialization strategy is selected based on the version identifier during deserialization. When an external signal is received, the execution context is restored by deserializing from the traceability information table, and execution continues precisely from the point of interruption.

[0010] In one or more embodiments of the present invention, the step S4 of publishing domain events via the event bus specifically includes: Publish an entry notification event when a work step is started, a rule loading completion event when the rules and historical progress are loaded, an execution completion event when the work step is completed, and a suspension notification event when the work step is suspended. The event bus adopts a publish-subscribe model. The Fun plugin decouples itself from the UI layer by publishing domain events, and the UI layer responds to changes in the process state by subscribing to the corresponding event types.

[0011] In one or more embodiments of the present invention, the method further includes a step type extension step: When adding a new work step type, inherit the work step base class and implement the three-stage lifecycle method, and define a unique identifier; Register the new step type in the dependency injection container, and establish a mapping from the unique identifier to the runtime type through a descriptor; When the process is issued, the engine matches the corresponding work step implementation class according to the coding field in the process definition and dynamically instantiates it; Adding a new work step type does not require modifying the core code of the work step process engine.

[0012] In one or more embodiments of the present invention, the method further includes an enterprise customization extension step: To meet the customized needs of specific vendors, create independent enterprise package assemblies, which include at least one of customized process implementations, customized MES adapters, and customized business rules; The enterprise package is integrated into the core system through an assembly loading mechanism, and the core system interacts with the enterprise package through a predefined interface.

[0013] In one or more embodiments of the present invention, the server uses an entity-attribute-value data model to store the dynamic attribute data of the workstation; When adding a new workstation attribute, only a new key-value pair record is added to the attribute table; there is no need to modify the database table structure.

[0014] In one or more embodiments of the present invention, the method further includes a workstation task dynamic transfer step: When a workstation is unable to complete its task due to a malfunction, the system will assign the task to other available workstations for execution. After the task is transferred, the association between the process progress data and the product code remains unchanged.

[0015] In another aspect of the invention, a PACK manual station management system based on workflow and scalable mode is provided, characterized in that it includes: The server side includes: The process route configuration module is used to establish and manage process route configuration data in a three-level control structure of "process route - operation - step". The workstation management module is used to bind workstation information and hardware resource information, wherein the hardware resources are uniformly abstracted in the form of measurement points; The traceability information module is used to store and manage process progress data associated with product codes; The client, deployed at each workstation terminal, includes: The process flow engine is used to load and execute each process step sequentially according to the process route configuration data. Each process step is a pluggable module that inherits from the process step base class. Its behavior is defined by a three-stage lifecycle method of initialization phase, execution phase and recovery phase. In the execution phase, the current process step can be selectively suspended and the execution context can be saved. In the recovery phase, execution can be resumed from the interruption point in response to external signals. The hardware communication abstraction layer is used to communicate with the underlying hardware devices through standardized measurement point interfaces, shielding the differences between hardware from different brands. The event bus module is used to publish and subscribe to domain events, enabling decoupled communication between the process execution status and the UI display layer; The MES abstract interface layer is used to interact with the factory MES system through an abstract MES adapter interface.

[0016] Compared with existing technologies, the workflow-based and scalable PACK manual station management method of the present invention has the following significant advantages: This invention, through a three-tiered management structure and a configurable process engine, enables visualized configuration of process steps. New production line deployment achieves zero-code development, requiring only installation and debugging to complete production. Process adjustments to the production line require no development intervention, completely eliminating the traditional on-the-job training phase. A single new production line can save 30 to 60 man-days of development investment. Process routes, procedures, and steps all have independent visualized configuration interfaces, allowing ordinary process engineers to independently complete production line configuration without programming experience, significantly reducing reliance on software developers and achieving the technical effect of configuration-driven zero-code implementation.

[0017] This invention unifies and abstracts hardware resources into measurement points, enabling peripherals such as tightening guns, barcode scanners, and weighing instruments to achieve brand-independent communication interfaces. Changing hardware devices or communication methods requires no modification to any process logic, reducing hardware adaptation time from days to hours. Simultaneously, by defining an abstract MES adapter interface layer, this invention ensures that general processes do not directly depend on specific factory MES implementations. Switching MES systems only requires modifying configuration files and restarting the client; the process logic code remains unchanged, achieving hot-swappable factory MES systems.

[0018] This invention allows third parties to develop non-standard work steps through a plug-in work step package mechanism, and integrates customized requirements through an enterprise package assembly mechanism without affecting the stability of the core system. Standard work step packages can be reused across projects, continuously reducing marginal development costs. Simultaneously, this invention employs a breakpoint saving and recovery mechanism during work step execution, serializing the execution context and storing it in a traceability information table. When an external signal is received, execution resumes precisely from the breakpoint, avoiding repetitive operations and data loss, and solving the problem of state recovery in long-process, cross-shift execution. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart of a PACK manual station management method based on workflow and scalable mode according to an embodiment of the present invention. Figure 2 This is a flowchart of the system initialization configuration of the present invention; Figure 3 A flowchart illustrating the process route configuration of the system of this invention; Figure 4 This is a schematic diagram of the process route configuration interface of the MES standardization platform of the present invention; Figure 5 This is a flowchart of the PACK production line for the present invention; Figure 6 This is a block diagram of the PACK manual station management device based on workflow and scalable mode according to the present invention. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0022] In response to the problems in the background technology, such as Figure 1 As shown, this invention provides a PACK manual station management method based on workflow and scalable mode, including the following steps: S1. Establish process route configuration data with a three-level control structure on the server side. The three-level control structure includes process route, process, and process step. The process route defines the complete processing sequence of the product and is composed of multiple processes connected in series or in parallel. Each process corresponds to one or more workstations. Each process step is a pluggable module that inherits from a preset process step base class and defines its behavior through a three-stage lifecycle method, which includes an initialization stage, an execution stage, and a recovery stage. S2. The hardware resource information of each workstation is uniformly abstracted and stored in the database in the form of measurement points; S3. When the client starts, it pulls the process route configuration data corresponding to the current workstation from the server and loads each process step in sequence according to the process order. When each process step is executed, the three-stage lifecycle method is called in sequence. During the execution phase, the current process step can be selectively suspended and the execution context can be saved. During the recovery phase, execution can be resumed from the interruption point in response to external signals. S4. Publish domain events through the event bus to achieve decoupled communication between the process execution state and the UI display layer; S5. Link process progress data with product codes and write them into the traceability information table to support querying completed tasks and rework operations.

[0023] On the server side, specific tasks and matching rules are configured under specific procedures. On the client side, each client acts as a workstation, executing tasks sequentially in a streaming manner. Each task on the backend undergoes three stages: SetUpAsync, ExecuteAsync, and ResumeAsync. The data results from each step are recorded in the procs table under the TraceInfo table, facilitating subsequent data traceability on the server side.

[0024] In a further embodiment, refer to Figure 2The complete process of system initialization configuration is as follows: First, create a client API key, with each client corresponding to a workstation; then create workstation resources, binding workstation information with hardware resources (barcode scanners, tightening guns, weighing instruments, etc.) and saving them in the database; next, create products, with each product representing a blueprint and having an independent process route; then create the process route, using a three-level control structure of "process route - operation - step" to define the complete processing sequence of the product; finally, create the process progress to track the task execution status of each product code.

[0025] In a further embodiment, the server employs the EAV (Entity-Attribute-Value) design pattern to implement dynamic attribute expansion. Specifically, workstation information is stored through the EAV data model, with workstation attributes stored as key-value pairs in an attribute table. When a new workstation attribute needs to be added, only the new key-value pair record is added to the attribute table, without modifying the database table structure. The server uses Refit technology to achieve data interaction between the client and server, ensuring data consistency between the client and the web page. In terms of database design, the Refit HTTP API interface is used to implement data interaction between the client and server, including AddProcItem (adding a process progress record) and FindByPin (querying traceability records by product code). The implementation of the EAV design pattern solves the problem of dynamic attribute expansion, eliminating the need to modify the database table structure every time an attribute is added.

[0026] In a further embodiment, the client adopts a layered architecture design, including three layers: a presentation layer (XAML files construct the interface, and ViewModel handles data responses), a plugin layer (Fun handles events and executes them sequentially, and the MediatR event bus enables communication between modules), and a core layer (IFun interface / FunExecutionContext execution context, and ITraceInfoApi calls the server-side interface). The server also adopts a layered architecture, including a WebClient frontend (TypeScript / React, responsible for routing and page rendering), a business layer (Biz business logic), a repository layer (Repo repository management), a controller layer (REST API for the Controller to interact with the frontend), and a PostgreSQL database.

[0027] This invention is based on FunBase's extensible abstract pluggable process engine (FunFlows), employing a three-level control model of "process route - operation - process step". The process route defines the complete processing sequence of the product, consisting of multiple operations connected in series or in parallel; the operation, such as OP010, OP020, OP030, etc., can be executed in a single workstation or multiple workstations; the process step (Fun) is the smallest execution unit within the operation, and each process step is a pluggable module inherited from FunBase, whose behavior is defined by a three-stage lifecycle method (SetUpAsync / ExecuteAsync / ResumeAsync).

[0028] In a further embodiment, refer to Figure 4 Configure process routes within the MES standardized platform. Each blueprint represents a product, and each product has its own process route, which is transferred through process flow. For example... Figure 4 As shown, the process route for product PN BX4 includes three processes: OP010, OP020, and OP030. These processes are connected by lines to indicate a series relationship. Each process corresponds to one or more workstations, and each process contains its own set of steps.

[0029] In a further embodiment, refer to Figure 3 The complete process for configuring a process route is as follows: after creating a product, configure the process route; add processes within the process route; and configure tasks for each process (processes and tasks can be added and configured repeatedly), ultimately forming a complete process route. In the client-side, tasks are completed at workstations.

[0030] In a further embodiment, each process includes one or more steps (tasks). Tasks within a process can be added, edited, and deleted in the task configuration interface. Process OP010 includes the following tasks: scan Pack code, scan employee card, scan shipment code, weigh, tighten (illustrated), precision tracking, and release. Each task has a sequence number, task type, task name, and details name. The system supports independent configuration of parameters for each task.

[0031] In a further embodiment, for tightening tasks, the system provides a visual configuration interface. Process engineers can upload product images, mark the locations and numbers of tightening points on the images (e.g., points 1 to 25), and configure the tightening gun parameters. They can configure tightening gun #1 (starting number 1, tightening count 10) and tightening gun #2 (starting number 11, tightening count 10), and set process parameters such as torque range and angle range. Each tightening task allows selection of which tightening guns to use, along with their corresponding starting numbers and tightening counts, achieving visual configuration of the tightening process.

[0032] In a further embodiment, the present invention achieves a unified abstraction of hardware communication through a channel measurement point management mechanism. The hardware communication abstraction layer shields the influence of different underlying hardware, such as the differences between the tightening gun direct connection mode and the PLC relay mode, and the differences between the remote IO direct connection mode and the PLC relay mode. The system has built-in drivers for common standard hardware such as serial port barcode scanners and weighing instruments, and provides standard expansion methods for a small number of non-standard hardware devices.

[0033] The measurement point management interface organizes measurement point resources in a tree structure. The top layer consists of channels (such as S7-1, ZLan-1, Hjz-1, COM-1#, COM-2#, COM-3#, etc.), and the next layer consists of measurement point groups (such as tightening gun measurement point groups hjzk, loBox, barcode scanner measurement point groups, weighing instrument measurement point groups, etc.). Each measurement point group contains input measurement points and output measurement points. For example, the tightening gun measurement point group contains input measurement point blocks and output measurement point blocks, the barcode scanner measurement point group contains multiple barcode scanning points (measurement point-1#, measurement point-2#), and the weighing instrument measurement point group contains weighing measurement points.

[0034] In this embodiment, all work steps only declare the tasks to be completed, without directly relying on peripherals. For example, a certain work step may specify which screws to tighten with a #1 bolt gun, the required torque and angle, but not the communication method, thus masking the difference between the direct connection mode and the PLC relay mode. All peripheral configurations are stored as workstation resources on the server and dynamically loaded by the client at runtime, facilitating batch deployment and overall line management. The front-end webpage imports measurement point data in a specific format and saves it to the database. When the client starts, it pulls the latest measurement point data and automatically monitors changes in the measurement points. As long as the client does not interrupt the process, there is an interface to detect changes in hardware data. When the hardware and software communicate, the software reflects the data changes to the client in real time using a specific method.

[0035] This invention enables hot-swapping of factory MES through an abstract interface layer. General processes do not directly depend on specific factory MES implementations; instead, they call the abstract interface layer to achieve hot-swapping between different factory MES systems. The system defines an abstract MES adapter interface layer (IMesAdapter), through which general processes interact with the MES system.

[0036] For different factory MES systems, corresponding adapter implementation classes are developed. A dependency injection (DI) container dynamically injects the corresponding MES adapter instance at runtime. The MES configuration interface allows configuration of parameters such as MES URL, timeout, username, password, site, operation, and resource group (DcGroup). The system includes various built-in MES interface methods (such as DataCollectForMoudleTest, DataCollectForResourceInspect, GetParametricValue, MiAssembleAndCollectDataForSfc, MiCheckInventoryAttributes, MiCheckSFCStatusEx, MiFindCustomAndSfcData, CheckBOMInventory, etc.), allowing common work steps to call these abstract interfaces without directly depending on the specific MES implementation.

[0037] When switching MES systems, only the following steps need to be performed: (1) Inject the new IMesAdapter implementation into the DI container; (2) Modify the adapter injection configuration in the configuration file to point to the new MES system; (3) Restart the client to make the configuration take effect; (4) Zero modification to the process logic. This design reduces the process of changing MES systems from several weeks of development work to hours of configuration work.

[0038] The process step engine of this invention is based on the extensible abstraction FunBase. Each process step manages its own state through three lifecycle hooks (SetUpAsync, ExecuteAsync, ResumeAsync) and drives the process forward through Next(). FunBase defines the algorithm skeleton (SetUp to Execute to Next), and subclasses implement specific business logic to ensure process consistency. Each Fun node encapsulates its own state, and Suspend / Resume implements state persistence and recovery, supporting long processes to be executed across shifts.

[0039] Taking the ScanInputFun step as an example, its execution flow is as follows: In the SetUpAsync phase, the service is called to load the rules and historical progress corresponding to the current step identifier and process key. If it has been completed, a skip flag is set, and a RuleAndProgressLoaded event is published to drive the UI to display the completed scan record; In the ExecuteAsync phase, it is checked whether it has been completed. If it has been completed, Next() is called to enter the next step. Otherwise, Suspend() is called to suspend the current step and wait for the scan signal; In the ResumeAsync phase, after receiving the signal, rule verification (matching the gun number rule with the encoding rule), uniqueness verification (preventing duplicate scans), and data submission (writing the scan result to the traceability information table) are performed. After the verification is passed, Next() is called to enter the next step.

[0040] The Suspend operation serializes the current execution context into JSON format data and stores it in the TraceProcItem.Value field. The serialized execution context includes the product code (PIN), station information, account information, completed steps list, and timestamp. A SchemaVersion field is also written into the serialized data as a version identifier. During deserialization, the appropriate deserialization strategy is selected based on the SchemaVersion version number to ensure version compatibility. Only necessary context fields are restored, avoiding the restoration of unnecessary states and reducing serialization and deserialization overhead.

[0041] The Resume operation deserializes and restores the execution context from TraceProcItem.Value. If breakpoint data exists, execution resumes precisely from the breakpoint; otherwise, execution starts from the beginning. The process also involves a complete exception handling state machine: when a step is in the Idle state, it triggers a start command and enters the SetUp state; after configuration, it enters the Ready state; in the Ready state, it enters the Executing state, during which Suspend() can be called to enter the Suspended state (at which point the Context is saved to TraceProcItem); in the Suspended state, it can respond to the Resume command to enter the Resuming state, resuming execution from the breakpoint data. If recovery fails (timeout or failure), an error log is recorded, and the cause of the exception and a solution are thrown for manual repair; in the Executing state, if a hardware failure or timeout occurs, it can directly enter the exception termination path. Upon normal completion, it enters the Completed state and then proceeds to the next task flow.

[0042] This invention uses the MediatR event bus to decouple the Fun plugin from the UI layer. The Fun plugin does not depend on a specific UI implementation; it only needs to publish domain events. The UI layer subscribes to these events via SignalR to respond to state changes. The event bus adopts a publish-subscribe pattern, and the main event types include: (1) FunEnteredNotification: Published when Fun enters, notifying the UI to update the current Fun status, including product code (PIN), station, Fun identifier and Fun display name (DisplayName).

[0043] (2) ScanInputFun_RuleAndProgressLoaded: After the rule and progress are loaded, it is published and drives the UI to display the completed scanning records, including the gun number rule (GunRule), the encoding rule (CodeRule), the list of completed records (CompletedRecords) and the progress percentage (ProgressPercent).

[0044] (3) FunCompletedNotification: Released when Fun is completed, triggering the next step of the process. It includes product code, activity code, gun number rules, coding rules, completed records and progress percentage.

[0045] (4) FunSuspendedNotification: Published when Fun is suspended, notifying MES of the current process status. The UI layer subscribes to the above events through SignalR Hub, and updates the interface display when the event occurs, thus achieving complete decoupling between the Fun plugin and the UI layer.

[0046] This invention follows the Open / Closed Principle (OCP), being open for extension but closed for modification. Adding a new Fun type does not require modification of the FunFlows engine's core code. The extension steps are as follows: The first step is to inherit from FunBase and implement its three lifecycle methods (SetUpAsync, ExecuteAsync, and ResumeAsync), defining a unique identifier and display name. Taking the extended QR code input as an example, a new class ScanInputFunEx inherits from FunBase, with the identifier set to "QR code input D". In SetUpAsync, it extends support for both QR code and barcode modes; in ExecuteAsync, it implements the dual-mode matching logic; and in ResumeAsync, it implements the breakpoint recovery logic.

[0047] The second step involves registering the newly added Fun type in the dependency injection container (ServiceCollection) and establishing a mapping between the unique identifier and the runtime type through FunDescriptor. The key design element is that the FunDescriptor registry maintains a mapping between the Identifier and FunBase subclasses, which the engine dynamically instantiates using Activator.CreateInstance, eliminating the need to recompile the engine when adding a new Fun type.

[0048] Third, when the MES system issues the process definition, the Code field in the process definition (such as "scan code to enter D") corresponds to the Fun identifier. The engine automatically matches and instantiates the corresponding Fun implementation class based on the Code field. This convention-over-configuration design ensures that adding a new step type does not modify the core code of the step process engine at all.

[0049] To address the customized needs of specific vendors, this invention provides an enterprise package (Assembly) mechanism. An independent enterprise package assembly is created, containing at least one of the following: customized process implementations, customized MES adapters, and customized business rules. The enterprise package is integrated into the core system through an assembly loading mechanism. The core system interacts with the enterprise package through predefined interfaces without modifying existing product code. This design allows standard process packages to be reused across projects, continuously reducing marginal development costs, while also allowing third parties to develop non-standard processes without affecting the stability of the core system.

[0050] In the client-side assembly demonstration system, each step is executed sequentially. Taking the screw-driving process as an example: the left side displays the task list for the current process (scanning employee cards, scanning shipping codes, weighing, screwing, releasing, etc.), the middle area displays a product assembly diagram and tightening point markings (e.g., points 1 to 25), and the right-side log area displays the system operation log in real time. The system status bar displays the current device ID, operator, vehicle number, remote IO status, alarm status, and release status.

[0051] Reference Figure 5 The complete process of the PACK production line is as follows: scan the Pack code to identify the product → load the process route task for the product → execute task 1, task 2, etc. in sequence → finally release the product. The result data of each task execution is recorded in the procs table under the TraceInfo table, which facilitates data traceability on the server side later.

[0052] In actual production, a workstation may become unable to complete its tasks due to a malfunction. In this case, the system supports reassigning the tasks at that workstation to other workstations. After the task transfer, the association between the process progress data and the product code remains unchanged, ensuring the continuity of traceability information. The system also supports rework operations, allowing users to view which tasks have been completed for each product code and to rework processes that have failed inspection.

[0053] like Figure 6 As shown, this invention also provides a PACK manual station management system based on workflow and scalable mode, including a server and a client. The server includes: a process route configuration module, used to establish and manage process route configuration data of a three-level control structure of "process route - operation - step"; a workstation management module, used to bind workstation information and hardware resource information, wherein the hardware resources are uniformly abstracted in the form of measurement points; and a traceability information module, used to store and manage operation progress data associated with product codes.

[0054] The client is deployed at each workstation terminal and includes: a process flow engine, used to load and execute each process step sequentially according to the process route configuration data. Each process step is a pluggable module that inherits from the process step base class. Its behavior is defined through a three-stage lifecycle method of initialization, execution, and recovery. During the execution phase, the current process step can be selectively suspended and the execution context can be saved. During the recovery phase, execution can be resumed from the interruption point in response to external signals. A hardware communication abstraction layer is used to communicate with the underlying hardware devices through standardized measurement point interfaces, shielding the differences between hardware from different brands. An event bus module is used to publish and subscribe to domain events, realizing decoupled communication between the process step execution status and the UI display layer. A MES abstract interface layer is used to interact with the factory MES system through an abstract MES adapter interface.

[0055] For concurrent processing of hardware devices, each gun or hardware device has an independent measuring point structure corresponding to it, and the devices are isolated from each other and do not affect each other. Regardless of how many guns are needed in a process step, they are processed in parallel and independently.

[0056] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0057] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A system that specifies functions in one or more boxes.

[0058] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction set implemented in a process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0059] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0060] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0061] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A PACK manual station management method based on workflow and scalable mode, characterized in that, Includes the following steps: S1. Establish process route configuration data with a three-level control structure on the server side. The three-level control structure includes process route, process, and process step. The process route defines the complete processing sequence of the product and is composed of multiple processes connected in series or in parallel. Each process corresponds to one or more workstations. Each process step is a pluggable module that inherits from a preset process step base class and defines its behavior through a three-stage lifecycle method, which includes an initialization stage, an execution stage, and a recovery stage. S2. The hardware resource information of each workstation is uniformly abstracted and stored in the database in the form of measurement points; S3. When the client starts, it pulls the process route configuration data corresponding to the current workstation from the server and loads each process step in sequence according to the process order. When each process step is executed, the three-stage lifecycle method is called in sequence. During the execution phase, the current process step can be selectively suspended and the execution context can be saved. During the recovery phase, execution can be resumed from the interruption point in response to external signals. S4. Publish domain events through the event bus to achieve decoupled communication between the process execution state and the UI display layer; S5. Link process progress data with product codes and write them into the traceability information table to support querying completed tasks and rework operations.

2. The PACK manual station management method based on workflow and scalable mode according to claim 1, characterized in that, The hardware resources mentioned in step S2, which are uniformly abstracted in the form of measurement points, specifically include: Define a standardized measurement point structure for each hardware device, the measurement point structure including device identifier, data type and communication protocol; The same type of hardware devices from different brands use the same measurement point abstract interface, so there is no need to modify the process business logic when changing hardware devices or communication methods.

3. The PACK manual station management method based on workflow and scalable mode according to claim 1, characterized in that, The method also includes a factory MES hot-plugging step: Define an abstract MES adapter interface layer, through which common processes interact with the MES system; Develop corresponding adapter implementation classes for the MES systems of different factories, and dynamically inject the corresponding MES adapter instance for the current factory at runtime through dependency injection; When switching MES systems, only the adapter injection configuration in the configuration file needs to be modified and the client needs to be restarted; the process logic code does not need to be modified.

4. The PACK manual station management method based on workflow and scalable mode according to claim 1, characterized in that, The step S3, which involves suspending the current process step and saving the execution context, specifically includes: The current execution context is serialized into data and stored in the traceability information table. The execution context includes product code, workstation information, and a list of completed steps. A version identifier is written into the serialized data, and the corresponding deserialization strategy is selected based on the version identifier during deserialization. When an external signal is received, the execution context is restored by deserializing from the traceability information table, and execution continues precisely from the point of interruption.

5. The PACK manual station management method based on workflow and scalable mode according to claim 1, characterized in that, The specific steps in step S4, including publishing domain events via the event bus, include: Publish an entry notification event when a work step is started, publish a rule loading completion event after the rules and historical progress are loaded, publish an execution completion event when the work step is completed, and publish a suspension notification event when the work step is suspended. The event bus adopts a publish-subscribe model. The Fun plugin decouples itself from the UI layer by publishing domain events, and the UI layer responds to changes in the process state by subscribing to the corresponding event types.

6. The PACK manual station management method based on workflow and scalable mode according to claim 1, characterized in that, The method also includes a step type extension step: When adding a new work step type, inherit the work step base class and implement the three-stage lifecycle method, and define a unique identifier; Register the new step type in the dependency injection container, and establish a mapping from the unique identifier to the runtime type through a descriptor; When the process is issued, the engine matches the corresponding work step implementation class according to the coding field in the process definition and dynamically instantiates it; Adding a new work step type does not require modifying the core code of the work step process engine.

7. The PACK manual station management method based on workflow and scalable mode according to claim 6, characterized in that, The method also includes enterprise-customized extension steps: To meet the customized needs of specific vendors, create independent enterprise package assemblies, which include at least one of customized process implementations, customized MES adapters, and customized business rules; The enterprise package is integrated into the core system through an assembly loading mechanism, and the core system interacts with the enterprise package through a predefined interface.

8. The PACK manual station management method based on workflow and scalable mode according to claim 1, characterized in that, The server uses an entity-attribute-value data model to store the dynamic attribute data of the workstation; When adding a new workstation attribute, only a new key-value pair record is added to the attribute table; there is no need to modify the database table structure.

9. The PACK manual station management method based on workflow and scalable mode according to claim 1, characterized in that, The method also includes a dynamic task transfer step at the workstation: When a workstation is unable to complete its task due to a malfunction, the system will assign the task to other available workstations for execution. After the task is transferred, the association between the process progress data and the product code remains unchanged.

10. A PACK manual station management system based on workflow and scalable mode, characterized in that, include: The server side includes: The process route configuration module is used to establish and manage process route configuration data in a three-level control structure of "process route - operation - step". The workstation management module is used to bind workstation information and hardware resource information, wherein the hardware resources are uniformly abstracted in the form of measurement points; The traceability information module is used to store and manage process progress data associated with product codes; The client, deployed at each workstation terminal, includes: The process flow engine is used to load and execute each process step sequentially according to the process route configuration data. Each process step is a pluggable module that inherits from the process step base class. Its behavior is defined by a three-stage lifecycle method of initialization phase, execution phase and recovery phase. In the execution phase, the current process step can be selectively suspended and the execution context can be saved. In the recovery phase, execution can be resumed from the interruption point in response to external signals. The hardware communication abstraction layer is used to communicate with the underlying hardware devices through standardized measurement point interfaces, shielding the differences between hardware from different brands. The event bus module is used to publish and subscribe to domain events, enabling decoupled communication between the process execution status and the UI display layer; The MES abstract interface layer is used to interact with the factory MES system through an abstract MES adapter interface.

Images