Virtual PLC system supporting third-party container security authentication and control method thereof

Abstract

According to the virtual PLC system supporting third-party container safety authentication and the control method of the virtual PLC system supporting third-party container safety authentication, each virtual controller is internally provided with an authentication center module, and when a third-party container is deployed to the virtual controller through a centralized management platform, the third-party container is authenticated; an equipment end container engine must initiate an authentication request to an authentication center module in the current virtual controller before being started; the authentication center module can receive an authentication request initiated by an equipment end container engine, safety authentication preset parameters are set in the authentication center module, and after the safety authentication actual parameters carried in the authentication request and the safety authentication preset parameters are correspondingly compared and verified and all verification is confirmed to be passed, the authentication request is sent to the equipment end container engine. Determining that the authentication request corresponding to the third-party container passes, and then returning an allowing instruction to allow the corresponding operation to be performed on the third-party container; a user is supported to deploy a non-standard third-party logic application container, personalized and intelligent control requirements are met, and flexible production line construction is assisted.

Description

Technical Field

[0001] This invention relates to the technical field of virtualization control technology in industrial automation control systems, specifically to a virtual PLC system and its control method that supports third-party container security authentication. Background Technology

[0002] With the development of intelligent manufacturing and the Industrial Internet, traditional PLC systems, due to their closed nature, fixed functions, and programming language limitations (such as the need to comply with standards like IEC61131-3 or IEC61499), are finding it difficult to meet the growing demands for customized, intelligent, and software-defined control. To address this, various virtual PLC solutions have been proposed in existing technologies, aiming to decouple PLC functions from dedicated hardware and achieve flexible deployment.

[0003] The current mainstream implementation of virtual PLCs is based on Hypervisor virtualization technology (such as VMware, KVM, etc.), running multiple PLC virtual machine instances on medium to large servers, and running a complete operating system and traditional PLC runtime environment in each virtual machine.

[0004] However, such solutions have the following significant drawbacks: 1) High resource consumption: Each virtual machine requires an independent operating system kernel, which consumes a lot of memory and CPU resources, making it impossible to deploy on resource-constrained edge devices (such as embedded PLCs and small gateways); 2) Functionality is closed: It only supports standard IEC61131-3 / 61499 control logic, and users cannot deploy non-standard control programs such as custom algorithms, AI models, and data analysis modules; 3) Lack of openness and scalability: It does not allow third-party developers to develop and integrate new control function components, which restricts the development of the ecosystem; 4) Significant security risks: Allowing external containers to be deployed at will may introduce malicious code or resource abuse, threatening the stability and security of the real-time control system.

[0005] Therefore, there is an urgent need to provide a new solution that can support lightweight deployment and achieve a secure and controllable access mechanism for third-party applications. Summary of the Invention

[0006] To address the deficiencies and shortcomings of the existing technology, this invention provides a virtual PLC system and its control method that support third-party container security authentication.

[0007] The specific solution provided by this invention is as follows: A virtual PLC system that supports third-party container security authentication, the system comprising: Multiple PLC devices, each of which has real-time processing capability, and each of which is equipped with a preset real-time container environment; Each PLC device is equipped with a corresponding virtual controller, and the virtual controllers all run in an operating environment that meets preset requirements; Its features are: Each of the aforementioned virtual controllers is equipped with an authentication center module. When a third-party container is deployed to the virtual controller through a centralized management platform, the container engine on the device must initiate an authentication request to the authentication center module inside the current virtual controller before starting. The authentication center module can accept authentication requests initiated by the device-side container engine. The authentication center module has preset security authentication parameters. By comparing and verifying the actual security authentication parameters in the authentication request with the preset security authentication parameters and confirming that all verifications are passed, the authentication request corresponding to the third-party container is deemed to be passed, and then an allow instruction is returned to allow the corresponding operation to be performed on the third-party container.

[0008] As a further preferred embodiment of the present invention, each of the PLC devices is equipped with an ECS real-time container environment.

[0009] As a further preferred embodiment of the present invention, the operating environment that meets the preset requirements includes an operating environment that meets the preset standards.

[0010] As a further preferred embodiment of the present invention, the security authentication preset parameters include at least the following: List of third-party containers allowed to run on the PLC device where the authentication center module is located; The maximum number of third-party containers that can be deployed on the PLC device where the authentication center module is located, and the number of third-party containers that are currently deployed; A list of valid tokens required to maintain container deployment and their corresponding validity periods; List of valid interfaces for authentication and verification.

[0011] As a further preferred embodiment of the present invention, the actual security authentication parameters include at least the following: The image identifier of the third-party container that initiated the authentication request; The token information held by the third-party container that initiated the authentication request; The user's identity information from the third-party container that initiated the authentication request.

[0012] As a further preferred embodiment of the present invention, when comparing and verifying the actual security authentication parameters carried in the authentication request with the preset security authentication parameters: sep1: Determine whether the token held by the third-party container that initiated the authentication request is in the list of valid tokens required to maintain container deployment; if the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. sep2: Determine whether the validity period of the token held by the third-party container that initiated the authentication request has not exceeded its corresponding validity period range; if the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. sep3: Determine whether the third-party container is in the list of allowed third-party containers of the PLC device where the authentication center module is located; if the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. sep4: Determine whether the number of currently running third-party containers has not reached the maximum number of third-party containers allowed to be deployed on the PLC device where the authentication center module is located; if the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. sep5: Determine whether the interface required by the third-party container is in the list of valid interfaces for authentication and verification; if the result is yes, then all verifications are considered to have passed; otherwise, the verification is considered to have failed and the request is rejected.

[0013] As a further preferred embodiment of the present invention, if the authentication request corresponding to the third-party container is deemed to be successful, then the corresponding operations performed on the third-party container are allowed to include at least the operations of pulling, creating and running the third-party container.

[0014] As a further preferred embodiment of the present invention, the authentication center module can remotely update the list of valid tokens, adjust the upper limit of the number of third-party containers allowed to be deployed on the PLC device, and modify the list of third-party containers allowed to run on the PLC device through its built-in security management interface.

[0015] As a further preferred embodiment of the present invention, the token is selected as a one-time token, a time-limited token, or an encrypted token.

[0016] Furthermore, the present invention also provides a control method for a virtual PLC system that supports third-party container security authentication, characterized by comprising the following steps: S100: When deploying a third-party container to a virtual controller through a centralized management platform, the container engine on the device side initiates an authentication request to the authentication center module inside the current virtual controller before starting. S200: The authentication center module accepts authentication requests initiated by the container engine on the device side and compares and verifies the actual security authentication parameters in the authentication request with the preset security authentication parameters. S201: Determine whether the token held by the third-party container that initiated the authentication request is in the list of valid tokens required to maintain container deployment; if the result is yes, proceed to the next determination process; otherwise, the verification is deemed to have failed and the request is rejected. S202: Determine whether the validity period of the token held by the third-party container that initiated the authentication request has not exceeded its corresponding validity period range; if the determination result is yes, proceed to the next determination process; otherwise, the verification is deemed to have failed and the request is rejected. S203: Determine whether the third-party container is in the list of allowed third-party containers of the PLC device where the authentication center module is located; if the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. S204: Determine whether the number of currently running third-party containers has not reached the maximum number of third-party containers allowed to be deployed on the PLC device where the authentication center module is located; if the determination result is yes, proceed to the next determination process; otherwise, the verification is deemed to have failed and the request is rejected. S205: Determine whether the interface required by the third-party container is in the list of valid interfaces for authentication and verification; if the result is yes, then all verifications are considered to have passed; otherwise, the verification is considered to have failed and the request is rejected. S300: After confirming that all verifications have passed, the authentication request corresponding to the third-party container is deemed to have passed, and an allow instruction is returned to allow the corresponding operation to be performed on the third-party container.

[0017] Compared with existing technologies, the technical effects that this invention can achieve include: 1) This invention provides a virtual PLC system and its control method that support third-party container security authentication, and enhances the functional expansion capabilities of the PLC system: it supports users to deploy third-party logic application containers (such as Python scripts, AI inference services, data preprocessing modules, etc.) that are not IEC61131-3 or IEC61499 standards, to meet personalized and intelligent control needs and help build flexible production lines.

[0018] 2) This invention provides a virtual PLC system and its control method that support secure authentication of third-party containers, enhancing system security: Each virtual controller is equipped with an authentication center module, which performs authentication verification on third-party container deployment requests before they are made. Through a local authentication mechanism, unauthorized application access is prevented, and risks of malicious code, virus propagation, and resource contention are mitigated. At the same time, a token-based access control policy is used to prevent unauthorized container injection, ensuring system security. In addition, the token mechanism allows for setting differentiated application deployment permissions for different departments, projects, or production lines, facilitating unified management and policy control.

[0019] 3) This invention provides a virtual PLC system and control method that supports third-party container security authentication, reducing deployment threshold and resource consumption: Based on a lightweight container architecture, it provides a virtual PLC implementation method based on lightweight real-time containers (rather than virtual machines), reducing resource overhead, adapting to edge devices, and enabling the operation of virtual PLC and third-party applications without large servers, making it suitable for a wide range of edge scenarios.

[0020] 4) This invention provides a virtual PLC system and its control method that support third-party container security authentication, provides standardized access interfaces for third-party developers, promotes the prosperity of the industrial APP ecosystem, supports the construction of an open ecosystem, and builds the foundation for a next-generation industrial control platform that supports the combination of software definition and security controllability. It can drive the evolution of PLCs to software-defined industrial control platforms and lay a secure foundation for the future integration of advanced functions such as AI inference, digital twin agents, and adaptive control. Attached Figure Description

[0021] Figure 1 The diagram shown is a logical structure diagram of the system provided by the present invention.

[0022] Figure 2 The diagram shown is a flowchart of the steps of the method provided by the present invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] In the description of this invention, it should be noted that the terms "upper," "lower," "inner," "outer," "front end," "rear end," "both ends," "one end," and "the other end," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0025] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installed," "equipped with," "connected," etc., should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0026] [First Embodiment] like Figure 1 As shown, the first embodiment of the present invention provides a virtual PLC system supporting secure authentication of third-party containers. The third-party container is distinct from the container environment deployed in the current PLC device and the container environments deployed in other PLC devices that may interact with it. The system includes: Multiple PLC devices, each with real-time processing capabilities, and each PLC device is equipped with a pre-defined real-time container environment; reducing deployment barriers and resource consumption: based on a lightweight container architecture, it provides a virtual PLC implementation method based on lightweight real-time containers (rather than virtual machines), reducing resource overhead, adapting to edge devices, and enabling the operation of virtual PLCs and third-party applications without the need for large servers, making it suitable for a wide range of edge scenarios.

[0027] In this embodiment, each PLC device is equipped with an ECS real-time container environment.

[0028] ECS (Edge Container Stack) is a lightweight real-time container designed for mission-critical cloud-native architectures. The container engine requires approximately 1MB of disk space and consumes about 6MB of memory, with a startup time of <50ms. Unlike Docker, ECS is a lightweight container built on the SylixOS hard real-time operating system. Real-time task response within the container can reach the microsecond level, and interrupt response can reach the nanosecond level.

[0029] ECS and the SylixOS kernel have a strongly bound, deeply integrated relationship, rather than an application software and operating system relationship. Through kernel-level modifications, a secure and isolated runtime environment is achieved, and the ECS runtime and container image package specifications are implemented in accordance with OCI standards.

[0030] PLC devices typically occupy relatively small and limited resources. Using ECS ​​real-time containers can create an isolated operating environment for such resource-constrained devices, allowing multiple PLC devices to operate independently of each other, ensuring the safety and reliability of the equipment, and also providing software-defined capabilities.

[0031] Each PLC device is equipped with a corresponding virtual controller, and the virtual controllers all run in an operating environment that meets preset requirements; in this embodiment, the operating environment that meets preset requirements includes an operating environment that meets preset standards.

[0032] In this embodiment, the preset standard should at least include IEC 61131-3 or IEC 61499. Wherein, The IEC 61131-3 standard is a core international standard in the field of industrial automation regarding the programming language and software architecture for programmable logic controllers (PLCs). Different manufacturers can refer to this standard to implement different operating environments. However, in terms of development methods, it can achieve a unified language, standardized structure, modular design, and support for multi-language mixed programming. The integrated IEC 61131-3 standard used in this embodiment provides a runtime environment that conforms to IEC 61131-3 and can support the operation of PLC applications written according to the IEC 61131-3 specification.

[0033] The IEC 61499 standard is a revolutionary standard in the field of industrial automation, considered a modern evolution of IEC 61131-3, and specifically designed for distributed, modular, and reconfigurable industrial control systems. Compared to the IEC 61131-3 standard, the IEC 61499 standard has advantages such as distributed architecture, event-driven operation, and high portability. The IEC 61499 standard used in this embodiment provides a compliant runtime environment that supports the operation of PLC applications written according to the IEC 61499 specification.

[0034] By integrating virtual controllers to run in an environment that meets preset standards, the smooth execution of PLC logic applications is ensured.

[0035] The improvement of this embodiment compared to the prior art is as follows: Each virtual controller has an authentication center module. When a third-party container is deployed to the virtual controller through a centralized management platform, the container engine on the device must send an authentication request to the authentication center module inside the current virtual controller before starting. The authentication center module can accept authentication requests initiated by the container engine on the device side. Internally, the module contains preset security authentication parameters. By comparing and verifying the actual security authentication parameters in the authentication request with the preset parameters, and confirming that all verifications pass, the authentication request corresponding to the third-party container is deemed successful. A permission instruction is then returned to allow corresponding operations on the third-party container. In this embodiment, the successful authentication request and the permitted operations on the third-party container include at least pulling, creating, and running the third-party container.

[0036] System security is enhanced by incorporating an authentication center module within each virtual controller. Before any deployment request for a third-party container is submitted, authentication is performed. This local authentication mechanism prevents unauthorized application access and mitigates risks such as malicious code, virus propagation, and resource contention. Furthermore, a token-based access control policy prevents unauthorized container injection, ensuring system security. Additionally, the token mechanism allows for setting differentiated application deployment permissions for different departments, projects, or production lines, facilitating unified management and policy control.

[0037] In this embodiment, the security authentication preset parameters include at least the following: List of third-party containers allowed to run on the PLC device where the authentication center module is located; The maximum number of third-party containers that can be deployed on the PLC device where the authentication center module is located, and the number of third-party containers that are currently deployed; The list of valid tokens required to maintain container deployment and their corresponding validity periods; and List of valid interfaces for authentication and verification.

[0038] The actual parameters for security authentication include at least the following: The image identifier of the third-party container that initiated the authentication request; the image identifier includes at least the name of the third-party container, the number of containers, and the interface information required by the container, so as to be used in the subsequent judgment process for corresponding judgment; The token information held by the third-party container that initiated the authentication request; the token information includes at least the token name and the token validity period, so as to be used in the subsequent judgment process for corresponding judgment; The user's identity information from the third-party container that initiated the authentication request.

[0039] When comparing and verifying the actual security authentication parameters in the authentication request with the preset security authentication parameters: sep1: Determine whether the token held by the third-party container that initiated the authentication request is in the list of valid tokens required to maintain container deployment; if the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected; determining whether the token is in the list of valid tokens required to maintain container deployment is the core step of the comparison and verification. Through this step, it is possible to directly determine whether the token held by the third-party container is valid. When the evaluation result is invalid, the subsequent comparison and verification process of token-related parameters (such as token validity period) can be directly avoided, saving verification procedures and verification time; sep2: Determine whether the validity period of the token held by the third-party container that initiated the authentication request has not exceeded its corresponding validity period range; if the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected; by introducing the validity period setting for the token held by the third-party container, on the one hand, the verification accuracy of the third-party container can be improved by further verifying the validity period of the token on the basis of the verification process of whether the token is in the list of valid tokens; on the other hand, by introducing the validity period for the token held by the third-party container, the total number of third-party containers that can pass the verification within a certain period of time can be limited, avoiding the concentrated congestion of the verification process in a single popular period of time; Sep3: Determine whether the third-party container is in the list of allowed third-party containers of the PLC device where the authentication center module is located; if the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected; due to the difference between each PLC device, the types of third-party containers allowed to run on each PLC device will also be different. Therefore, even after determining whether the token is in the list of valid tokens required for maintaining container deployment and whether the token's validity period has not exceeded its corresponding validity period range, this judgment step is still required to ensure that the third-party container holding a valid token and within the validity period range belongs to the type of third-party container allowed to run on the current PLC device. Sep 4: Determine if the number of currently running third-party containers has not reached the maximum number of third-party containers allowed to be deployed on the PLC device where the authentication center module is located. If the result is yes, proceed to the next determination process; otherwise, the verification is deemed to have failed and the request is rejected. Correspondingly, due to the differences between each PLC device, the number of third-party containers allowed to run on each PLC device will also be different. Therefore, even after determining that the third-party container belongs to the list of third-party containers allowed to run on the current PLC device, this determination step is still required to ensure that the total number of containers does not exceed the number of third-party containers allowed to run on the current PLC device. It is worth noting that if the determination of whether the number of third-party containers has not reached the maximum number of third-party containers allowed to be deployed on the PLC device is performed first, then if the result is no, it is still necessary to determine whether the third-party container is in the list of third-party containers allowed to run on the PLC device where the authentication center module is located. Therefore, the determination of whether the third-party container is in the list of third-party containers allowed to run on the PLC device where the authentication center module is located needs to be placed before this step. sep5: Determine whether the interface required by the third-party container is in the list of valid interfaces for authentication verification; if the result is yes, the verification is considered to have passed; otherwise, the verification is considered to have failed and the request is rejected; this step is performed after the token validity, validity period, container type and container quantity are determined to determine the interface required by the third-party container in order to ensure efficient data interaction, so the verification order is placed last.

[0040] It is worth noting that, in this embodiment, the authentication center module can remotely update the list of valid tokens, adjust the maximum number of third-party containers allowed to be deployed on the PLC device, and modify the list of third-party containers allowed to run on the PLC device through its built-in security management interface. This facilitates flexible configuration of security policies according to production needs, thereby meeting the corresponding requirements in different authentication and verification scenarios and effectively expanding the scope of application.

[0041] In this embodiment, the token can be selected as a one-time token, a time-limited token, or an encrypted token according to actual needs. One-time tokens can be dynamically generated, with random dynamic token information generated in real time, ensuring that each authentication is different, effectively preventing token information from being stolen or repeatedly attacked, significantly improving verification security, and the token information does not require complex memorization, supporting use anytime and anywhere. Time-limited tokens can ensure high security of token information within a specific time interval. Encrypted tokens further improve security on the basis of added passwords or keys, reducing the risk of leakage.

[0042] For example, in a particular embodiment, The system includes multiple ARM processor-based edge PLC devices A, B, and C, each running an ECS real-time container environment; Each device is equipped with a virtual controller, which contains a VSOA authentication center module. The authentication center module is configured to allow a maximum of 2 third-party containers to run, maintain the list of valid tokens required for container deployment including ai-inspect:v1.0 and data-proxy:v2.1, and the token information held by the third-party container that initiates the authentication request is plc-token-abc123; A user attempts to deploy an AI vision inspection container through the centralized management platform ECSM, with the token information being ai-inspect:v1.0; After receiving the deployment instruction, the container engine on the device sends an authentication request to the authentication center module. The authentication request carries user identity information, token information and image identifier. After the authentication center module compares and verifies the data and confirms that all verifications have passed, it determines that the authentication request corresponding to the third-party container has passed and then returns an authorization instruction to allow the corresponding operation to be performed on the third-party container. The centralized management platform pulls the image and starts the container. The AI ​​module runs successfully and works logically with the virtual controller.

[0043] [Second Embodiment] The second embodiment of the present invention also provides a control method for a virtual PLC system supporting third-party container security authentication mentioned in the first embodiment, comprising the following steps: S100: When deploying a third-party container to a virtual controller through a centralized management platform, the container engine on the device side initiates an authentication request to the authentication center module inside the current virtual controller before starting. S200: The authentication center module accepts authentication requests initiated by the container engine on the device side and compares and verifies the actual security authentication parameters in the authentication request with the preset security authentication parameters. S201: Determine whether the token held by the third-party container that initiated the authentication request is in the list of valid tokens required to maintain container deployment; if the result is yes, proceed to the next determination process; otherwise, the verification is deemed to have failed and the request is rejected. S202: Determine whether the validity period of the token held by the third-party container that initiated the authentication request has not exceeded its corresponding validity period range; if the determination result is yes, proceed to the next determination process; otherwise, the verification is deemed to have failed and the request is rejected. S203: Determine whether the third-party container is in the list of allowed third-party containers of the PLC device where the authentication center module is located; if the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. S204: Determine whether the number of currently running third-party containers has not reached the maximum number of third-party containers allowed to be deployed on the PLC device where the authentication center module is located; if the determination result is yes, proceed to the next determination process; otherwise, the verification is deemed to have failed and the request is rejected. S205: Determine whether the interface required by the third-party container is in the list of valid interfaces for authentication and verification; if the result is yes, then all verifications are considered to have passed; otherwise, the verification is considered to have failed and the request is rejected. S300: After confirming that all verifications have passed, the authentication request corresponding to the third-party container is deemed to have passed, and an allow instruction is returned to allow the corresponding operation to be performed on the third-party container.

[0044] 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.

Claims

1. A virtual PLC system supporting third-party container security authentication, the system comprising: Multiple PLC devices, each of which has real-time processing capability, and each of which is equipped with a preset real-time container environment; Each PLC device is equipped with a corresponding virtual controller, and the virtual controllers all run in an operating environment that meets preset requirements; Its features are: Each of the aforementioned virtual controllers is equipped with an authentication center module. When a third-party container is deployed to the virtual controller through a centralized management platform, the container engine on the device must initiate an authentication request to the authentication center module inside the current virtual controller before starting. The authentication center module can accept authentication requests initiated by the container engine on the device side. The authentication center module has preset security authentication parameters. By comparing and verifying the actual security authentication parameters in the authentication request with the preset security authentication parameters and confirming that all verifications are passed, the authentication request corresponding to the third-party container is deemed to be passed, and then an allow instruction is returned to allow the corresponding operation to be performed on the third-party container.

2. The virtual PLC system supporting third-party container security authentication according to claim 1, characterized in that: Each of the aforementioned PLC devices is equipped with an ECS real-time container environment.

3. The virtual PLC system supporting third-party container security authentication according to claim 1, characterized in that: The operating environment that meets the preset requirements includes an operating environment that meets the preset standards.

4. The virtual PLC system supporting third-party container security authentication according to claim 1, characterized in that: The security authentication preset parameters include at least the following: List of third-party containers allowed to run on the PLC device where the authentication center module is located; The maximum number of third-party containers that can be deployed on the PLC device where the authentication center module is located, and the number of third-party containers that are currently deployed; A list of valid tokens required to maintain container deployment and their corresponding validity periods; List of valid interfaces for authentication and verification.

5. The virtual PLC system supporting third-party container security authentication according to claim 4, characterized in that: The actual parameters for security authentication include at least the following: The image identifier of the third-party container that initiated the authentication request; The token information held by the third-party container that initiated the authentication request; The user's identity information from the third-party container that initiated the authentication request.

6. The virtual PLC system supporting third-party container security authentication according to claim 5, characterized in that: When comparing and verifying the actual security authentication parameters in the authentication request with the preset security authentication parameters: sep1: Determine whether the token held by the third-party container that initiated the authentication request is in the list of valid tokens required to maintain container deployment; If the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. sep2: Determine whether the validity period of the token held by the third-party container that initiated the authentication request has not exceeded its corresponding validity period range; if the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. sep3: Determine whether the third-party container is in the list of allowed third-party containers of the PLC device where the authentication center module is located; If the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. sep4: Determine whether the number of currently running third-party containers has not reached the maximum number of third-party containers allowed to be deployed on the PLC device where the authentication center module is located; If the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. sep5: Determine whether the interface required by the third-party container is in the list of valid interfaces for authentication and verification; If the result is yes, the verification is considered to have passed; otherwise, the verification is considered to have failed and the request is rejected.

7. The virtual PLC system supporting third-party container security authentication according to claim 1, characterized in that: If the authentication request corresponding to the third-party container is deemed successful, then the corresponding operations allowed for the third-party container include at least the operations of pulling, creating, and running the third-party container.

8. The virtual PLC system supporting third-party container security authentication according to claim 1, characterized in that: The authentication center module can remotely update the list of valid tokens, adjust the maximum number of third-party containers allowed to be deployed on the PLC device, and modify the list of third-party containers allowed to run on the PLC device through its built-in security management interface.

9. The virtual PLC system supporting third-party container security authentication according to claim 4, characterized in that: The token may be a one-time token, a time-limited token, or an encrypted token.

10. The control method for a virtual PLC system supporting third-party container security authentication according to any one of claims 1-9, characterized in that: Includes the following steps: S100: When deploying a third-party container to a virtual controller through a centralized management platform, the container engine on the device side initiates an authentication request to the authentication center module inside the current virtual controller before starting. S200: The authentication center module accepts authentication requests initiated by the container engine on the device side and compares and verifies the actual security authentication parameters in the authentication request with the preset security authentication parameters. S201: Determine whether the token held by the third-party container that initiated the authentication request is in the list of valid tokens required to maintain container deployment; If the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. S202: Determine whether the validity period of the token held by the third-party container that initiated the authentication request has not exceeded its corresponding validity period range; if the determination result is yes, proceed to the next determination process; otherwise, the verification is deemed to have failed and the request is rejected. S203: Determine whether the third-party container is in the list of allowed third-party containers of the PLC device where the authentication center module is located; If the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. S204: Determine whether the number of currently running third-party containers has not reached the maximum number of third-party containers allowed to be deployed on the PLC device where the authentication center module is located; If the result is yes, proceed to the next judgment process; otherwise, the verification is deemed to have failed and the request is rejected. S205: Determine whether the interface required by the third-party container is in the list of valid interfaces for authentication verification; if the result is yes, then all verifications are considered to have passed; otherwise, the verification is considered to have failed and the request is rejected. S300: After confirming that all verifications have passed, the authentication request corresponding to the third-party container is deemed to have passed, and an allow instruction is returned to allow the corresponding operation to be performed on the third-party container.

Images