Flexible pluggable production line digital service integrated framework system

Abstract

The invention relates to the technical field of industrial software and system integration, in particular to a flexible pluggable production line digital service integration framework system, comprising an access layer comprising a data acquisition gateway for acquiring original data of equipment and a protocol adapter cluster for converting the original data of the equipment into structured data; the middle layer comprises a data integration engine used for processing the structured data into a standardized data object, a service orchestration engine used for performing service orchestration on the standardized data object to generate business data, and a message bus and communication module used for transmitting the business data to a target system; the application layer comprises an open API gateway used for providing an API interface for the message bus and the communication module; and packaging the function module into an independent Docker container, deploying an OSGi framework on an application layer, and realizing hot plugging of the Docker container through the OSGi framework. According to the invention, the expandability, availability and maintenance efficiency of the system are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of industrial software and system integration, and in particular to a flexible pluggable production line digital service integration architecture system. Background Art

[0002] Driven by the wave of digitalization, digitalizing an enterprise's production line has become a key means of improving production efficiency, optimizing product quality, and enhancing corporate competitiveness. As the core support system for achieving digitalization, the production line digital service integration framework aims to organically integrate various equipment, systems, and software on the production line, enabling data circulation and sharing, and thus providing enterprises with comprehensive, accurate, and real-time digital services.

[0003] The production line digital service integration architecture usually covers multiple levels and functional modules. From the data acquisition level, it needs to connect with various types of equipment on the production line. These devices may come from different manufacturers and use different communication protocols and data formats. It is responsible for obtaining raw data from these devices, such as the equipment's operating status, production parameters, quality inspection data, etc. At the data processing level, the collected raw data needs to go through a series of processing processes such as cleaning, conversion, and analysis to extract valuable information. At the service provision level, based on the processed data, various digital services are provided to enterprises. These services can help enterprise management understand the operation of the production line in real time and make scientific and reasonable decisions; provide production personnel with an intuitive operating interface and guidance information to improve the accuracy and efficiency of production operations.

[0004] However, the existing production line digital service integration architecture technology still has the following main problems:

[0005] 1) Poor system scalability. With the continuous development of the business and the upgrading and transformation of production lines, new equipment and systems need to be continuously integrated. However, existing integrated architectures often adopt a tightly coupled design approach, with close dependencies between modules. When adding new equipment or systems, the entire system needs to be modified and debugged on a large scale. This not only increases development costs and time, but also easily leads to system failures, affecting normal production operations.

[0006] 2) Poor usability. With the continuous advancement of technology, the integrated architecture of digital production line services needs to be constantly upgraded to introduce new features and technologies. However, the upgrade process of the existing integrated architecture is complex, which may affect the stability and normal operation of the existing system. This makes companies hesitant to upgrade and thus miss opportunities for technological development.

[0007] 3) Low maintenance efficiency. Due to the complex system architecture and high coupling between modules, problems with a module are difficult to quickly locate and resolve. Furthermore, compatibility issues between different devices and systems increase the difficulty of maintenance, requiring specialized technicians for maintenance and management, and requiring significant investment in both human and material resources.

[0008] Therefore, a new technical solution is urgently needed to solve these problems, improve the performance and efficiency of the production line digital service integration architecture, and promote the rapid development of production line digitalization. Summary of the Invention

[0009] In view of the above-mentioned deficiencies of the existing technology, the technical problem to be solved by the present invention is: how to provide a flexible pluggable production line digital service integration architecture system, encapsulate functional modules into independent Docker containers and deploy the OSGi framework at the application layer to achieve hot plugging, thereby improving the system's scalability, availability and maintenance efficiency.

[0010] In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0011] A flexible pluggable production line digital service integration architecture system, including:

[0012] The access layer includes a data collection gateway for collecting raw data from devices and a protocol adapter cluster for converting raw data from devices into structured data.

[0013] The middle layer includes a data integration engine for processing structured data into standardized data objects, a service orchestration engine for performing service orchestration on standardized data objects to generate business data, and a message bus and communication module for transmitting business data to the target system;

[0014] The application layer includes an open API gateway that provides API interfaces for the message bus and communication modules;

[0015] Among them, the functional modules in the access layer, middle layer and application layer are encapsulated as independent Docker containers, and the OSGi framework is deployed in the application layer to realize hot plugging of Docker containers through the OSGi framework.

[0016] Preferably, the steps of encapsulating the functional modules in the access layer, the middle layer, and the application layer into independent Docker containers include:

[0017] S01: Split the access layer, middle layer and application layer into multiple independent functional modules;

[0018] S02: Define the dependency relationships between functional modules and obtain a functional module list and dependency diagram;

[0019] S03: Create an independent Docker image for each functional module in the functional module list;

[0020] S04: Encapsulate the services that the functional modules depend on into Docker containers based on the dependency graph;

[0021] S05: Run the Docker image of the functional module to generate a Docker container instance, define the relationship between the Docker container instance of the functional module and the Docker container of the dependent service through Docker Compose, and obtain the Docker Compose configuration file.

[0022] Preferably, the steps of deploying the OSGi framework at the application layer include:

[0023] S11: Package the code, configuration files and dependent libraries of each functional module into an OSGi Bundle;

[0024] S12: Configure the startup parameters of the OSGi framework;

[0025] S13: Run the Docker image of the functional module to generate a Docker container instance, start the OSGi framework in the Docker container instance of the functional module and load the corresponding OSGi Bundle;

[0026] S14: Each functional module registers the services it provides through ZooKeeper and discovers the dependent services to obtain the integrated containerized OSGi runtime environment.

[0027] Preferably, in the integrated containerized OSGi runtime environment, hot swapping includes:

[0028] 1) Module uninstallation: Use the command line tool of the OSGi framework to stop and uninstall the old version of the module bundle;

[0029] 2) Module installation and startup: Load the new version of the module bundle and start the module through the OSGi framework; after the new module is started, re-register the service with ZooKeeper;

[0030] 3) Dependency re-establishment: Other modules that depend on a certain module perceive the service update through ZooKeeper and automatically rebind to the new version of the service.

[0031] Preferably, the integrated containerized OSGi runtime environment includes:

[0032] 1) Error detection: The OSGi framework monitors the module startup status. If a module fails to start, it is marked as FAILED. ZooKeeper monitors the service registration status. If a service registration fails, it notifies the dependent module to retry discovering the service.

[0033] 2) Automatic rollback: If the new module fails to start, the OSGi framework automatically rolls back to the old version of the module bundle and restores the old service;

[0034] 3) Error log: records error information during dynamic hot swapping.

[0035] Preferably, in the data integration engine of the middle layer, the processing steps of predefining the industry standard data model and implementing zero-code data integration include:

[0036] S21: Design basic data models according to industry standards;

[0037] S22: Store the basic data model in the metadata center, supporting model version management and field description;

[0038] S23: matching the corresponding target model based on the received JSON data transmitted by the access layer;

[0039] S24: Map the JSON data to the target model field through the mapping rule library to obtain a standardized data object;

[0040] S25: Verify the standardized data object to ensure that it complies with the field constraints of the target model;

[0041] S26: Writing the standardized data object into the target storage.

[0042] Preferably, in step S21, the basic data model is extended by defining a model through the following steps:

[0043] S211: Submit extension requirements through the metadata center;

[0044] S212: The metadata center supports online model editing. New fields require definition of field name, type, constraints, and business meaning.

[0045] S213: The metadata center automatically generates a new version of the model and checks whether the extended fields are compatible with the existing data to obtain the extended data model.

[0046] Preferably, in step S24, the mapping rule library uses a visual mapping tool to support mapping JSON data to target model fields by dragging and dropping.

[0047] Preferably, in the service orchestration engine of the middle layer, a drag-and-drop process designer based on the BPMN2.0 standard supports self-defined business logic.

[0048] Preferably, it also includes:

[0049] Edge nodes, which run the protocol adapters of the access layer and the lightweight data integration engine of the middle layer;

[0050] Real-time data is transmitted directly to edge nodes via the MQTT protocol and uploaded to the cloud on demand after processing;

[0051] The cloud-based middle platform runs a complete data integration engine, service orchestration engine, and metadata center;

[0052] Non-real-time data is synchronized to the cloud data lake regularly via FTP / SFTP.

[0053] Compared with the existing technology, the flexible pluggable production line digital service integrated architecture system of the present invention has the following advantages:

[0054] The present invention encapsulates functional modules into independent Docker containers, thereby achieving resource isolation. Each Docker container has an independent operating environment and resource allocation, thereby avoiding resource conflicts and interference between different functional modules. Moreover, the Docker container can dynamically adjust resource allocation according to actual needs to achieve efficient resource utilization. When the load of a functional module increases, more resources can be quickly allocated to the container; when the load decreases, excess resources can be released, thereby avoiding waste of resources and reducing the operating costs of the system. At the same time, since the functional modules are encapsulated as independent Docker containers, the deployment process becomes simple and fast. The functional modules can be quickly started by simply deploying the corresponding Docker images to the server, enabling the system to quickly respond to changes in business needs and launch new functions or services in a timely manner. In addition, when the system load increases or new functions are required, the system can be expanded by increasing the number of Docker containers. This flexible expansion method enables the system to adapt to business needs of different scales and improve the scalability of the system.

[0055] The present invention deploys an OSGi framework at the application layer and implements hot-swapping of Docker containers through the OSGi framework, allowing for dynamic addition, deletion, or update of Docker containers without stopping the entire system. When a functional module needs to be upgraded or maintained, the old Docker container can be directly replaced with a new one without affecting the normal operation of other functional modules, thereby improving system availability and maintenance efficiency. Furthermore, if a Docker container fails, the OSGi framework can quickly detect the failure and automatically remove the container from the system. A new Docker container can then be quickly started to replace the failed container, achieving rapid recovery from the failure. This ensures high system availability and reduces service interruption time caused by the failure. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to make the purpose, technical solutions and advantages of the invention more clear, the present invention will be further described in detail below with reference to the accompanying drawings, in which:

[0057] Figure 1 A logical block diagram of the system for integrating pluggable production line digital services.

[0058] Figure 2 Workflow diagram for the custom adapter generation tool.

[0059] Figure 3 This is a processing flow chart of the data integration engine.

[0060] Figure 4 Design flow chart for the service orchestration engine process. DETAILED DESCRIPTION

[0061] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. The components of the embodiments of the present invention generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the invention claimed for protection, but only represents selected embodiments of the present invention. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0062] It should be noted that similar reference numerals and letters denote similar items in the following figures. Therefore, once an item is defined in one figure, it does not require further definition or explanation in subsequent figures. In the description of the present invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer" indicate positions or relationships based on the positions or relationships shown in the figures, or the positions or relationships in which the inventive product is typically placed when in use. These terms are intended solely to facilitate the description of the present invention and simplify the description. They do not indicate or imply that the devices or components referred to must have a specific orientation, be constructed, or operate in a specific orientation, and are therefore not to be construed as limiting the present invention. Furthermore, the terms "first," "second," and "third," etc., are used solely to distinguish descriptions and are not to be construed as indicating or implying relative importance. Furthermore, terms such as "horizontal" and "vertical" do not imply that a component is absolutely horizontal or overhanging, but rather may be slightly tilted. For example, "horizontal" simply means that its direction is more horizontal than "vertical," and does not mean that the structure must be completely horizontal, but rather may be slightly tilted. In the description of the present invention, it should also be noted that, unless otherwise expressly specified or limited, the terms "disposed," "installed," "connected," and "connected" should be understood in a broad sense. For example, they may refer to fixed connections, detachable connections, or integral connections; they may refer to mechanical connections or electrical connections; they may refer to direct connections or indirect connections through an intermediate medium; and they may refer to internal communication between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on the specific circumstances.

[0063] The following is a further detailed description through specific implementation methods:

[0064] Example:

[0065] This embodiment discloses a flexible pluggable production line digital service integration architecture system.

[0066] like Figure 1 As shown in the figure, the flexible pluggable production line digital service integration architecture system includes:

[0067] The access layer includes a data acquisition gateway for collecting raw device data and a protocol adapter cluster for dynamically loading protocol parsing libraries (such as the jModbus library loaded by the Modbus adapter) based on the device type to convert the device raw data (such as a hexadecimal byte stream) into a unified JSON format (including device ID, timestamp, and data fields).

[0068] The middle layer includes a data integration engine for receiving JSON data transmitted by the access layer and processing the JSON data into standardized data objects, a service orchestration engine for performing service orchestration on standardized data objects to generate business data, and a message bus and communication (mechanism) module for transmitting business data to the target system (ERP, MES, SCADA, etc.);

[0069] The application layer includes an open API gateway that provides API interfaces for the message bus and communication (mechanism) modules, as well as a visualization platform;

[0070] Among them, the functional modules in the access layer, middle layer and application layer are encapsulated as independent Docker containers, and the OSGi framework is deployed in the application layer to realize hot plugging of Docker containers through the OSGi framework.

[0071] In this embodiment, the Docker container is a lightweight virtualization technology used to package applications (functional modules) and their dependencies into independently executable images. Docker containers share the host kernel, enabling fast startup, minimal resource usage, and rapid deployment and migration, making them widely used in microservice architectures. The OSGi framework is a dynamic modular system for Java that splits applications into independent modules (Bundles). Each module can be independently developed, deployed, and upgraded. Inter-module communication is achieved through the service layer, supporting dynamic loading, unloading, and updating.

[0072] The present invention encapsulates functional modules into independent Docker containers, thereby achieving resource isolation. Each Docker container has an independent operating environment and resource allocation, thereby avoiding resource conflicts and interference between different functional modules. Moreover, the Docker container can dynamically adjust resource allocation according to actual needs to achieve efficient resource utilization. When the load of a functional module increases, more resources can be quickly allocated to the container; when the load decreases, excess resources can be released, thereby avoiding waste of resources and reducing the operating costs of the system. At the same time, since the functional modules are encapsulated as independent Docker containers, the deployment process becomes simple and fast. The functional modules can be quickly started by simply deploying the corresponding Docker images to the server, enabling the system to quickly respond to changes in business needs and launch new functions or services in a timely manner. In addition, when the system load increases or new functions are required, the system can be expanded by increasing the number of Docker containers. This flexible expansion method enables the system to adapt to business needs of different scales and improve the scalability of the system.

[0073] The present invention deploys an OSGi framework at the application layer and implements hot-swapping of Docker containers through the OSGi framework, allowing for dynamic addition, deletion, or update of Docker containers without stopping the entire system. When a functional module needs to be upgraded or maintained, the old Docker container can be directly replaced with a new one without affecting the normal operation of other functional modules, thereby improving system availability and maintenance efficiency. Furthermore, if a Docker container fails, the OSGi framework can quickly detect the failure and automatically remove the container from the system. A new Docker container can then be quickly started to replace the failed container, achieving rapid recovery from the failure. This ensures high system availability and reduces service interruption time caused by the failure.

[0074] In order to better introduce the technical solution of the present invention, this embodiment is described through the following parts.

[0075] 1. Access Layer

[0076] 1. Protocol Adapter Cluster

[0077] Basic adapters (20+ pre-integrated): support industrial / IT protocols such as Modbus TCP / RTU, OPC UA, MQTT, SQL (MySQL / Oracle), and RESTful API. Each adapter is encapsulated as an independent Docker container (image size ≤ 200MB).

[0078] Custom Adapter Generation Tool: Provides a visual protocol parsing configuration interface, allowing users to define field mapping rules (such as Figure 2 As shown, Modbus address 0x0001 is mapped to the "Device Temperature" field) and the adapter code is automatically generated (developed based on Java / Node.js and supports hot loading).

[0079] 2. Data Collection Gateway

[0080] Deployed on edge nodes (industrial-grade IPCs or ARM servers), connected to the device layer via the RJ45 / RS485 interface, and communicated with the middle-tier message bus via HTTPS / WebSocket.

[0081] Here’s how it works:

[0082] Multi-protocol data acquisition: The adapter dynamically loads the protocol parsing library according to the device type (such as the Modbus adapter loading the jModbus library), and converts the device's raw data (such as a hexadecimal byte stream) into a unified format of JSON data (including device ID, timestamp, and data fields).

[0083] Dynamic device discovery: supports IP scanning (supporting network segment 192.168.1.0 / 24) or manual entry of device information, automatically generates device metadata (including communication parameters, data point list) and registers it to the middle-tier metadata center.

[0084] 2. Middle Platform

[0085] 1. Data Integration Engine

[0086] Technical composition:

[0087] Rule Engine: Based on the Drools open source framework, it supports configuring data transformation rules through a visual interface (such as Figure 3 As shown in the example, configure "Generate an alert message when the temperature is greater than 80°C"). This rule supports over 20 rule types, including regular expressions, mathematical operations, and conditional judgments.

[0088] Metadata Center: Predefined industry standard data models (e.g., automotive manufacturing includes 15+ basic models such as "work order" [work order ID, process route, equipment requirements], "equipment status" [OEE, energy consumption, fault code]), and supports user-defined extended model fields.

[0089] Processing flow:

[0090] 1) Receive access layer JSON data and match the corresponding industry data model based on device metadata;

[0091] 2) Use the rule engine to perform data cleaning (removing invalid values), format conversion (such as converting device timestamps to ISO8601 format), and business rule verification (such as the number of work orders must be ≥1);

[0092] 3) Output standardized data objects (compliant with ISO22400 industrial data standards) to the message bus or storage engine.

[0093] 2. Service Orchestration Engine

[0094] Technical implementation:

[0095] Develop a visual orchestration tool based on the BPMN2.0 standard, provide 50+ process nodes (such as service calls, conditional branches, parallel tasks, timers), support the definition of business processes by dragging and dropping (such as Figure 4 As shown in the figure, the order issuance process includes four nodes: "ERP order acquisition → work order splitting → equipment capacity verification → MES work order creation").

[0096] Built-in intelligent recommendation engine: Based on historical orchestration records (stored in the process knowledge base, supporting storage of millions of process instances), it automatically recommends similar process templates (recommendation accuracy ≥ 85%) to reduce duplicate configurations.

[0097] Implementation Mechanism:

[0098] The process definition is compiled into executable Java bytecode and run through the Camunda process engine, supporting transaction compensation (such as automatically rolling back the work order creation operation when the device scheduling fails).

[0099] Supports real-time monitoring of process instance status (running / pause / abnormal) and provides process performance analysis (node ​​time consumption, resource usage) function.

[0100] 3. Message bus and communication mechanism

[0101] Technology selection:

[0102] Using Kafka distributed message queue (supporting 3-copy fault tolerance mechanism), the message throughput reaches 100,000 messages / second, meeting the high-frequency data interaction needs of the production line (such as equipment status collection frequency of 100ms / time).

[0103] Communication Mode:

[0104] Asynchronous decoupling: Device data collection is separated from business processing. For example, SCADA collects data and sends it to the Kafka topic "device_data". The MES system obtains real-time data by subscribing to this topic, avoiding interface call blocking.

[0105] Service routing: Dynamic routing of service addresses is implemented through NginxAPIGateway, supporting load balancing (polling / minimum number of connections algorithm) and circuit breaker mechanism (such as automatic circuit breaker if 5 consecutive calls fail, and retry after 5 minutes).

[0106] In the middle-tier service orchestration engine, the drag-and-drop process designer based on the BPMN2.0 standard supports non-technical personnel to independently define business logic, shortening the process configuration cycle from weeks to hours.

[0107] 3. Application Layer

[0108] 1. Visual configuration platform

[0109] Functional modules:

[0110] Adapter configuration interface: displays a list of connected systems, supports protocol parameter modification (such as Modbus slave address, TCP timeout), and monitors the adapter's operating status (CPU / memory usage, data throughput) in real time.

[0111] Data Mapping Workbench: Displays the mapping relationship between source system fields and target model fields in a table format.

[0112] Process orchestration canvas: supports unlimited canvas scaling, and the execution order is indicated by arrow lines between nodes. The right-click menu can be used to configure node parameters (such as service call address, timeout period, and number of retries).

[0113] 2. Open API Gateway

[0114] Technical features:

[0115] Provides RESTful API interface documentation (based on Swagger 3.0), including 30+ standard interfaces (such as getting equipment list / api / equipment, triggering process instance / api / process / start).

[0116] Supports OAuth2.0 authentication and JWT token verification, API call frequency limit (default 100 times / minute, customizable) to ensure system security.

[0117] 4. Dynamic Hot Swapping Mechanism

[0118] In this embodiment, the steps of encapsulating the functional modules in the access layer, the middle layer, and the application layer into independent Docker containers include:

[0119] S01: Split the access layer, middle layer, and application layer into multiple independent functional modules, each with a single responsibility (such as ERP adapter, MES interface plug-in, data integration engine, etc.);

[0120] S02: Define the dependencies between functional modules (e.g., the data integration engine depends on the MySQL database, the ERP adapter depends on the external ERP system interface), and obtain a list of functional modules and a dependency diagram;

[0121] S03: Create a separate Docker image for each functional module in the functional module list. The Docker image contains the module's binary files, configuration files, and runtime dependencies (such as the Java runtime environment). For example, the image of the ERP adapter module contains the adapter code, configuration files, and necessary Java libraries.

[0122] S04: Based on the dependency graph, encapsulate the services that the functional modules depend on (such as MySQL database and ZooKeeper service registration center) into Docker containers; for example, the MySQL container contains the initial database data, and the ZooKeeper container provides service registration and discovery functions.

[0123] S05: Run the Docker image of the functional module to generate a Docker container instance. Use Docker Compose to define the relationship between the Docker container instance of the functional module and the Docker container of its dependent services (for example, the data integration engine container specifies that it depends on the MySQL container through depends_on). At the same time, configure the network and storage volumes to ensure communication between containers and data persistence, and obtain the Docker Compose configuration file.

[0124] Specifically, the steps for deploying the OSGi framework at the application layer include:

[0125] S11: Package the code, configuration files and dependent libraries of each functional module into an OSGi Bundle;

[0126] S12: Configure the startup parameters of the OSGi framework (such as Apache Felix, Eclipse Equinox), specify the bundle loading path, service registry (ZooKeeper) address, etc., and obtain the OSGi framework configuration file, which is used to describe the bundle loading order, service registry configuration, etc.

[0127] S13: Run the Docker image of the functional module to generate a Docker container instance, start the OSGi framework in the Docker container instance of the functional module and load the corresponding OSGi Bundle;

[0128] S14: Each functional module registers the services it provides through ZooKeeper and discovers the dependent services to obtain the integrated containerized OSGi runtime environment.

[0129] Specifically, in the integrated containerized OSGi runtime environment, hot swapping includes:

[0130] 1) Module uninstallation: Stop and uninstall the old version of the module bundle through the OSGi framework command line tools (such as stop, uninstall) or REST API;

[0131] 2) Module installation and startup: Load the new version of the module bundle (such as erp-adapter-bundle-v2.jar) and start the module through the OSGi framework. After the new module is started, re-register the service with ZooKeeper. The service information may include the version number or updated metadata.

[0132] 3) Dependency re-establishment: Other modules that depend on this module (such as the data integration engine) perceive the service update through ZooKeeper and automatically rebind to the new version of the service.

[0133] Specifically, the integrated containerized OSGi runtime environment includes:

[0134] 1) Error Detection: The OSGi framework monitors the startup status of modules. If a module fails to start (e.g., a bundle dependency is missing), it is marked as FAILED. ZooKeeper monitors the service registration status. If service registration fails, it notifies the dependent modules to retry service discovery.

[0135] 2) Automatic rollback: If the new module fails to start, the OSGi framework automatically rolls back to the old version of the module bundle and restores the old service;

[0136] 3) Error log: records error information during the dynamic hot swap process (such as reasons for module uninstallation failure and service registration timeout) for operation and maintenance personnel to troubleshoot problems.

[0137] Specifically, the hot update process is as follows:

[0138] Update preparation: The user uploads the new module image (.tar.gz format) through the configuration platform, and the system verifies the image signature (SHA-256 hash value matches);

[0139] Traffic switching: Dynamically modify the load balancing configuration through Nginx, add the new module container to the cluster, and the old module stops receiving new requests;

[0140] Graceful shutdown: The old module automatically shuts down after processing existing requests, and the new module seamlessly takes over (the downtime interval is ≤ 500ms, meeting the real-time requirements of the production line);

[0141] State migration: The module's running status is cached in Redis, and configuration parameters (such as configured mapping rules and process instance progress) are automatically restored after updates.

[0142] 5. Metadata-driven integration

[0143] In the middle-tier data integration engine, the processing steps for pre-defining industry-standard data models and implementing zero-code data integration include:

[0144] S21: Design (predefine) basic data models according to industry standards (such as ISO22400 equipment effectiveness indicators and GB / T34044 production data classification);

[0145] S22: Store the basic data model in a metadata center (such as a database or a dedicated metadata management system), supporting model version management and field description;

[0146] S23: matching the corresponding target model based on the received JSON data transmitted by the access layer;

[0147] S24: Mapping the JSON data to the target model fields through the mapping rule library, and performing necessary data conversion to obtain standardized data objects; the mapping rule library uses a visual mapping tool to support (users) to map the JSON data to the target model fields by dragging and dropping.

[0148] S25: Validate the standardized data object to ensure that it complies with the field constraints of the target model (such as field type, length, and uniqueness);

[0149] S26: Write standardized data objects to the target storage (such as databases and data lakes), supporting batch writes and incremental updates.

[0150] Specifically, define the model extension for the basic data model through the following steps:

[0151] S211: (User) submits extension request through (interface of) metadata center;

[0152] S212: The metadata center supports online model editing. When adding new fields, the field name, type, constraints, and business meaning must be defined.

[0153] S213: The metadata center automatically generates a new version of the model and checks whether the extended fields are compatible with the existing data to obtain the extended data model.

[0154] This invention provides a unified specification for data integration by pre-defining industry standard data models, greatly improving the consistency and accuracy of data and avoiding misunderstandings and processing errors caused by differences in data formats. On this basis, zero-code data integration is achieved, which greatly lowers the technical threshold. Business personnel can complete data docking without professional programming knowledge, saving development costs and time. At the same time, this model enables the system to quickly adapt to the integration needs of different industries and different data sources, improves the flexibility and scalability of the system, and helps enterprises use data more efficiently and accelerate business decision-making and innovation.

[0155] 6. Cloud-Edge Collaborative Deployment Solution

[0156] The flexible pluggable production line digital service integration architecture system also includes:

[0157] Edge nodes are used to run the access layer's protocol adapters and the middle layer's lightweight data integration engine (handling real-time data filtering and cleaning, with a data retention period of 72 hours). Configuration requirements: CPU ≥ 4 cores, memory ≥ 8GB, storage ≥ 256GB SSD.

[0158] Real-time data (such as equipment status and quality inspection results) is directly transmitted to the edge node via the MQTT protocol and uploaded to the cloud on demand after processing (e.g., abnormal data is uploaded in seconds, and normal data is uploaded in minutes).

[0159] The cloud-based middle platform runs a complete data integration engine, service orchestration engine, and metadata center, and supports elastic expansion (through automatic expansion of the K8s cluster, with a peak processing capacity of 100,000 TPS);

[0160] Non-real-time data (such as work order history and equipment maintenance records) is regularly synchronized to the cloud data lake via FTP / SFTP, supporting offline analysis (such as OEE trend analysis through Spark clusters).

[0161] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit the technical solutions. Those skilled in the art should understand that modifications or equivalent replacements of the technical solutions of the present invention that do not depart from the purpose and scope of the technical solutions of the present invention should be included in the scope of the claims of the present invention.

Claims

1. A flexible pluggable production line digital service integration architecture system, characterized by: include: The access layer includes a data collection gateway for collecting raw data from devices and a protocol adapter cluster for converting raw data from devices into structured data. The middle layer includes a data integration engine for processing structured data into standardized data objects, a service orchestration engine for performing service orchestration on standardized data objects to generate business data, and a message bus and communication module for transmitting business data to the target system; The application layer includes an open API gateway that provides API interfaces for the message bus and communication modules; Among them, the functional modules in the access layer, middle layer and application layer are encapsulated as independent Docker containers, and the OSGi framework is deployed in the application layer to realize hot plugging of Docker containers through the OSGi framework.

2. The pluggable production line digital service integration architecture system according to claim 1, characterized in that: The steps to encapsulate the functional modules in the access layer, middle layer, and application layer into independent Docker containers include: S01: Split the access layer, middle layer and application layer into multiple independent functional modules; S02: Define the dependency relationships between functional modules and obtain a functional module list and dependency diagram; S03: Create an independent Docker image for each functional module in the functional module list; S04: Encapsulate the services that the functional modules depend on into Docker containers based on the dependency graph; S05: Run the Docker image of the functional module to generate a Docker container instance, define the relationship between the Docker container instance of the functional module and the Docker container of the dependent service through Docker Compose, and obtain the Docker Compose configuration file.

3. The pluggable production line digital service integration architecture system according to claim 2, characterized in that: The process of deploying the OSGi framework at the application layer includes: S11: Package the code, configuration files and dependent libraries of each functional module into an OSGi Bundle; S12: Configure the startup parameters of the OSGi framework; S13: Run the Docker image of the functional module to generate a Docker container instance, start the OSGi framework in the Docker container instance of the functional module and load the corresponding OSGi Bundle; S14: Each functional module registers the services it provides through ZooKeeper and discovers the dependent services to obtain the integrated containerized OSGi runtime environment.

4. The pluggable production line digital service integration architecture system according to claim 3, characterized in that: In the integrated containerized OSGi runtime environment, hot swapping includes: 1) Module uninstallation: Use the command line tool of the OSGi framework to stop and uninstall the old version of the module bundle; 2) Module installation and startup: Load the new version of the module bundle and start the module through the OSGi framework; after the new module is started, re-register the service with ZooKeeper; 3) Dependency re-establishment: Other modules that depend on a certain module perceive the service update through ZooKeeper and automatically rebind to the new version of the service.

5. The pluggable production line digital service integration architecture system according to claim 3, characterized in that: The integrated containerized OSGi runtime environment includes: 1) Error detection: The OSGi framework monitors the module startup status. If a module fails to start, it is marked as FAILED. ZooKeeper monitors the service registration status. If a service registration fails, it notifies the dependent module to retry discovering the service. 2) Automatic rollback: If the new module fails to start, the OSGi framework automatically rolls back to the old version of the module bundle and restores the old service; 3) Error log: records error information during dynamic hot swapping.

6. The pluggable production line digital service integration architecture system according to claim 1, characterized in that: In the middle-tier data integration engine, the processing steps for pre-defining industry-standard data models and implementing zero-code data integration include: S21: Design basic data models according to industry standards; S22: Store the basic data model in the metadata center, supporting model version management and field description; S23: matching the corresponding target model based on the received JSON data transmitted by the access layer; S24: Map the JSON data to the target model field through the mapping rule library to obtain a standardized data object; S25: Verify the standardized data object to ensure that it complies with the field constraints of the target model; S26: Writing the standardized data object into the target storage.

7. The pluggable production line digital service integration architecture system according to claim 6, characterized in that: In step S21, the basic data model is extended by defining a model through the following steps: S211: Submit extension requirements through the metadata center; S212: The metadata center supports online model editing. New fields require definition of field name, type, constraints, and business meaning. S213: The metadata center automatically generates a new version of the model and checks whether the extended fields are compatible with the existing data to obtain the extended data model.

8. The pluggable production line digital service integration architecture system according to claim 6, characterized in that: In step S24, the mapping rule library uses a visual mapping tool to support mapping JSON data to target model fields by dragging and dropping.

9. The pluggable production line digital service integration architecture system according to claim 1, characterized in that: In the middle-tier service orchestration engine, the drag-and-drop process designer based on the BPMN2.0 standard supports independent definition of business logic.

10. The pluggable production line digital service integration architecture system according to claim 1, characterized in that: Also includes: Edge nodes, which run the protocol adapters of the access layer and the lightweight data integration engine of the middle layer; Real-time data is transmitted directly to edge nodes via the MQTT protocol and uploaded to the cloud on demand after processing; The cloud-based middle platform runs a complete data integration engine, service orchestration engine, and metadata center; Non-real-time data is synchronized to the cloud data lake regularly via FTP / SFTP.

Images