DEVICE FOR THE SECURE PROCESSING OF DATA

Description

[0001] The invention relates to a device for use in an industrial environment, in particular an industrial machine, for the secure processing of data within a software container environment, as well as a security method and a computer-readable storage medium.

[0002] Developing security-critical applications places high demands on adherence to strict security and reliability standards. These requirements become even more complex when the application is to be run in a modern, containerized environment like Kubernetes. Kubernetes, as application-agnostic orchestration software, offers numerous advantages in terms of scalability, flexibility, and container management. However, Kubernetes lacks specific mechanisms to support the security-critical requirements of applications. This presents developers with the challenge of ensuring that their applications can run not only functionally, but also securely and reliably in a Kubernetes infrastructure.Secure orchestration platforms, such as those described in patent applications EP4390577A1, EP24176635A1 or EP24176655A1 as secure Kubernetes, which are incorporated herein in their entirety by reference for all purposes, go beyond the basic security features of Kubernetes and offer additional security mechanisms to support safety-critical applications and workloads.

[0003] For an application to leverage the security infrastructure of a secure orchestration platform, it is essential to consider the specific requirements of such services early in the application development process. Retrofitting an application to the security infrastructure of such services requires significant changes to the existing program code, leading to increased costs and delays.

[0004] EP 2 648 104 B1 discloses an operational safety maintenance device for ensuring the reliability of a target system or application system, wherein so-called reliability description data are added and / or modified by means of a change adaptation cycle execution device, the reliability description data specifying the reliability of the target system. EP 4 390 577 A1 discloses a safety device for monitoring at least one machine with several logic units, wherein one logic unit is configured as a safety function unit for the safety-oriented evaluation of sensor data and one logic unit is configured as a diagnostic unit for monitoring the safety function unit.EP 4 108 393 A1 refers to an optical functional safety system in which a digital twin of an automation system is replicated in real time to adapt point cloud data measured by a ToF sensor using the digital twin.

[0005] It is therefore a task of the present invention to address this problem and to provide a device for use in industrial environments which offers increased flexibility in the development of applications.

[0006] This task is solved by the subject matter of the independent claims.

[0007] A first aspect of the invention relates to a device for use in an industrial environment, in particular an industrial machine, for the secure processing of data within a software container environment, comprising: a data generation unit for generating application data, a data processing unit for processing the application data provided by the data generation unit within the software container environment, wherein the data processing unit is configured as an execution environment to run multiple logic modules on the data processing unit, the logic modules comprising: at least one application module for executing at least one application using the application data, wherein the application module is configured to generate state data belonging to the application, the state data indicating whether an application is executing without errors or whether a faulty state exists which requires the execution of a safety function; an adaptation module configured to receive the state data from the application module and convert the state data into a format processable by a safety monitoring module; and the safety monitoring module configured to receive the converted state data from the adaptation module and to determine, based on the converted state data, whether a fault state exists, wherein the safety monitoring module performs a safety-oriented evaluation of the converted state data; and wherein the application moduleThe adaptation module and the safety monitoring module are designed as part of an application component, in particular a standalone one.

[0008] In other words, the adaptation module provides an interface between the application module and the safety monitoring module, translating the status data sent by the application module into a format that the safety monitoring module can process. This is particularly advantageous when the status data is in a format that the safety monitoring module cannot process. With the help of the adaptation module, any application can thus be adapted to the requirements of the safety monitoring module, even retroactively.

[0009] The term "software container environment" refers to an environment that allows software applications to run in isolation and portability within containers. Containers are lightweight, self-contained packages containing everything necessary to run the software, including the software code, runtime, libraries, and settings. This environment offers several advantages, including isolation, consistency, and efficiency in application deployment and management. Container environments such as Docker are well-known. Container orchestration systems like Kubernetes are typically used to manage and operate multiple containers. However, such systems generally lack security monitoring implementations designed to ensure the secure operation of container orchestration in security-critical or highly regulated environments.However, a given container orchestration system can be extended with diagnostic units or additional security monitoring mechanisms, as shown, for example, in EP4390577A1, to become a secure orchestration platform. In particular, such security monitoring implementations include measures taken to ensure the safety, reliability, and regulatory compliance of the orchestration software.

[0010] The invention enables an application to be adapted to the requirements of the security monitoring module in such environments, particularly even retroactively, using the adaptation module, in order to take advantage of secure orchestration platforms. For example, the security monitoring module is implemented according to the requirements of the respective secure orchestration platform, so that the status data is adapted to these requirements by the adaptation module. This eliminates the need for complex code modifications to the application module or early consideration of the predefined requirements of the security monitoring module or its security infrastructure.

[0011] Although the term "industrial machine" is used below to describe the invention, the corresponding descriptions also refer to a device for use in an industrial environment. The industrial machine can be designed for use in industrial production processes. For example, the industrial machine is designed to perform tasks such as manufacturing, processing, assembly, transport, packaging, or quality assurance. Furthermore, the industrial machine can be operated manually, fully automatically, or semi-automatically. An industrial machine can, in particular, comprise a robot, e.g., an AMR (Autonomous Mobile Robot) or AGV (Automated Guided Vehicle), an edge computing device, a storage system (especially an automated one), a conveyor system, a production plant, and the like.

[0012] The processing unit acts as the execution environment (also known as the "runtime environment"). The processing unit is thus the structural element, and the execution environment its function. The processing unit is at least indirectly connected to the data generation unit. It therefore has access to the application data for processing, possibly indirectly via intermediary units, and can, for example, interact with the industrial machine's control system or directly with the industrial machine itself.

[0013] During the operation of an industrial machine, several logic modules run on the data processing unit. The data processing unit can include at least a computing device and a memory. For example, the data processing device could be a computer, such as a host computer, a microcontroller, a cloud computing platform, or the like. A logic module generally refers to a software function block. Software function blocks are, in particular, self-contained units within a software program that implement a specific function or group of functions. A logic module can, for example, be implemented as a container running within Kubernetes.

[0014] The application module, the adaptation module, and / or the safety monitoring module can be implemented in individual containers or in a shared container. Advantageously, the adaptation module can be easily integrated into existing software applications by implementing it at an interface between the application module and the safety monitoring module. In particular, integration into an existing system can also be performed retroactively, allowing the adaptation module to be adapted to the software technologies used by the industrial machine. The applications themselves can also be purely software applications aimed at processing, converting, or preparing data. However, these applications are specifically coupled with other applications, meaning...Applications exchange data with each other in such a way that they are part of a complete application that has an effect detectable in the industrial machine and the real world.

[0015] According to the invention, one of the logic modules is designed as a safety monitoring module, which in particular performs a safety-oriented evaluation of the status data. The aim of the safety-oriented evaluation is the detection of a fault condition, i.e., a safety-relevant event or condition. In the event of a fault condition, a safety signal is preferably output to trigger a safety-oriented response of the industrial machine, which brings the machine into a safe state that eliminates a potential hazard or at least reduces it to an acceptable level.

[0016] An industrial machine is, for example, a robot that uses the ROS framework (Robot Operating System) for developing robot software. Different applications of the robot can be implemented in different software containers (hereinafter referred to simply as "containers"). However, an industrial machine can also be a vehicle, a camera system, or any other machine that processes application data to execute an application within a software container environment.

[0017] The application data, i.e., user data, is generated by a data generation unit. Such a data generation unit could be, for example, a camera, a sensor, or any other device capable of generating data. In the case of a virtual application, the data generation unit can be a virtual data generation unit. For example, the data generation unit could be a virtual sensor.

[0018] The application data provided is used by the application module to execute an application. An application is understood to be any type of computer-executable application. For example, an application can be any application that can be executed using a data processing unit on which software code is implemented. An application can also be a sub-application, representing only a part of a larger application, provided that the larger application has a direct impact on the real world. In particular, this refers to applications where the associated software code is modularized within software containers. Examples of such applications include data filtering, sensor data processing, image recognition, person recognition, and similar applications.

[0019] In particular, the application can be any AI application, including a neural network, generative AI, or an AI microservice such as NIM (Nvidia Inference Microservices).

[0020] When the application is executed, the application module also generates state data associated with the application. This state data can reflect the application's current state. For example, it can indicate whether the application is running without errors or whether a faulty state exists that requires the execution of a safety function. The application module is specifically capable of transmitting data, such as state data, via any messaging system and / or technology, such as DDS, HTTP, socket, or similar.

[0021] The adaptation module receives this state data. However, since the safety monitoring module typically has predefined requirements for the input data format, the state data must be converted into a format that the safety monitoring module can process. The adaptation module performs this conversion and transmits the converted state data to the safety monitoring module. For example, the adaptation module accepts state data that conforms to a predefined input format and outputs converted state data that conforms to a predefined output format. The adaptation module can accept and process a wide variety of different input formats.

[0022] Further embodiments of the invention can be found in the claims, the description and the drawings.

[0023] As described, the application module, the adaptation module, and the security monitoring module are designed as part of a single, independent application component. Specifically, the application module, the adaptation module, and / or the security monitoring module access the same resources. Independent in this context means, for example, that each application component is an isolated unit with its own environment and resources. An application component can, for instance, comprise one or more containers that exchange data and interact with each other to implement a specific application. Containers of one application component can communicate with containers of another application component, for example, via interfaces between the application components.

[0024] In particular, the application module, the adaptation module, and / or the security monitoring module access the same network and storage. For example, the application module, the adaptation module, and / or the security monitoring module run on the same host. If the application module, the adaptation module, and the security monitoring module are configured as part of a Kubernetes ecosystem, an application component could be, for example, a Kubernetes pod, which is often used to host tightly coupled containers that need to work together. A Kubernetes pod is the smallest and simplest unit in the Kubernetes ecosystem. All containers in a Kubernetes pod share, for example, storage, an IP address, port assignments, and can communicate with each other over the same host.

[0025] In one embodiment, the application module and the adaptation module are implemented on the same container, and both use the same software technologies. For example, the application module and the adaptation module use the same framework, system, programming library or paradigm, and / or the same data structures and types.

[0026] According to one embodiment, the application module and the adaptation module are implemented on different containers, with the adaptation module being adapted to the application module, and in particular to the software technologies used by the application module, by means of adaptation mechanisms. For example, the adaptation module is adapted to the software technologies used by the application module by means of RPC (Remote Procedure Call) mechanisms. RPC mechanisms are, in particular, methods that allow a program to execute a process or a function in a different address space, i.e., in an environment in which, for example, a different software technology is used. RPCs can abstract network communication and provide a simple interface for distributed application development.

[0027] This variant offers the advantage of increased resilience if multiple application modules use the same adaptation module or exchange data with the same adaptation module. Furthermore, this variant can be implemented with less overhead and lower latency. As previously described, the software technologies can relate to a software framework, system, programming library or paradigm, and / or data structures and types.

[0028] According to one embodiment, the adaptation module communicates with a multitude of different application modules and / or is used for a multitude of different applications. For example, the adaptation module can be used for a multitude of applications as long as the applications are implemented according to the same technology platform, in particular the same technology framework or software framework. This is because, for example, the adaptation module is adapted to the specific requirements of a technology platform. The adaptation module can, for example, process predefined data types and / or formats used within the technology platform.The adaptation module can thus communicate with several application modules that follow the rules and requirements of the technology platform, and convert state data of a respective application module into a format that can be processed, i.e., readable, by the security monitoring module.

[0029] If the industrial machine is, for example, a robot that uses the ROS framework, the adaptation module can be tailored to the ROS framework used by the robot and, in particular, can only be used in combination with the ROS framework. For use within other frameworks, the adapter can be adapted accordingly.

[0030] According to one embodiment, the state data comprises state data packets. A state data packet can include at least one of the following: a state data packet ID, an application label, a state data packet creation time, a verification character, a sequence number, a state data packet type, a state data packet status, or a state data packet attribute. The state data can be transmitted, for example, in the form of state data packets, also known as "heartbeats," which indicate the state of the application, particularly at a specific point in time.

[0031] The state data packet ID, for example, is a unique identification number or character that can be used to identify the state data packet.

[0032] The application name is, for example, a human-readable name for the application or a component of the application to which the state data packet belongs. For instance, the state data packet might only specify the state of a component of the application, such as a sub-function within the application.

[0033] The creation time of the state data package specifically indicates the time at which the application created the state data package.

[0034] The verification mark can be used to determine the correctness of the state data packet. For example, it can be used to verify whether the data contained in the state data packet is plausible and / or conforms to a specific format. The verification mark can be, for example, a hash value or a checksum generated from the data contained in the state data packet, or at least a portion thereof. The verification mark can be determined, for example, using a function or formula that takes the data contained in the state data packet as input values. Algorithms and / or functions such as MD5, SHA-1, or SHA-256 can be used for this purpose.

[0035] The sequence number, for example, is a sequential number that indicates the creation order of the generated status data packets. Based on the sequence number, the status data packets can thus be processed in chronological order by the adaptation module and / or safety monitoring module.

[0036] The type of state data package, for example, is a specification that further defines the state data package. This is particularly helpful in cases where different types of state data packages exist. The type can, for instance, indicate which stage of a test the state data package can be assigned to. Furthermore, the state data package type can specify for which parameter the state data package indicates a state.

[0037] The status of the state data packet can also indicate whether the action associated with the state data packet was successful or not. For example, the status can take two different values, where the first value indicates a successful action, while the second value indicates a failed action. The status can thus be "failed" or "successful." For example, the status can take a Boolean value, where "true" indicates a successful action and "false" indicates a failed action. In particular, the security monitoring module can be configured to determine whether an application error has occurred based on the status of the state data packet.

[0038] The state data package can also include one or more attributes or attribute fields containing additional useful data. For example, an attribute can include a list of key / value pairs with application-specific attributes that describe the state data package in more detail. Such an attribute could be, for instance, a status code that describes the processing result even more precisely.

[0039] According to one embodiment, the application module is configured to generate state data packets cyclically, with a predefined number of state data packets being generated within each cycle. State data packets within the same cycle share the same sequence number. In other words, the state data packets can be generated at fixed, regular intervals. This allows for regular monitoring of the application's state, enabling the rapid detection of faulty states. The frequency can vary depending on the requirements. For example, in systems with very high real-time demands, state data packets can be transmitted at intervals of a few milliseconds, such as less than 100 ms, 50 ms, 10 ms, or 5 ms. In other systems with lower demands, the intervals between state data packets can be several seconds.For example, the time interval can be less than 30 s, 10 s or 1 s.

[0040] According to another embodiment, the application module is configured to generate at least two state data packets within a cycle, wherein at least one state data packet is of type "Processing started" and at least one state data packet is of type "Processing completed". In particular, the application module generates a state data packet of type "Processing completed" immediately following a state data packet of type "Processing started". A state data packet of type "Processing started" thus initiates a new cycle, with each state data packet of type "Processing started" also assigning a new sequence number. However, other state data packet types can also be included within a cycle, which, for example, represent an intermediate step of processing or an intermediate result.

[0041] According to one embodiment, the adaptation module is configured to arrange the status data packets in a queue in an order corresponding to their chronological arrival. The status data packets can thus be processed chronologically based on their position in the queue. For example, the status data packets can remain in the queue until further processing is required or possible. In particular, the safety monitoring module can determine when further processing of the status data packets should occur. It is also possible to place particularly safety-relevant status data packets at the top of the queue so that they are processed with priority and before the other status data packets.In an embodiment where the adaptation module is used for multiple applications, the state data packets of the different applications can be arranged chronologically in a single queue.

[0042] According to one embodiment, the adaptation module is configured to check, in response to an action signal received from the safety monitoring module (which includes a processing ID, a sequence number, and / or a verification character), the state data packets belonging to the sequence number stored in the action signal. The action signal thus triggers the processing of one or more related state data packets. Specifically, the action signal only includes the processing ID, the sequence number, and / or the verification character; no further metadata is contained within the action signal. However, the additional metadata for the state data packets can be stored in the safety monitoring module.Based on the data contained in the action signal, the associated state data packets can be uniquely identified and selected from the queue in the adaptation module to start the state data packet check.

[0043] According to one embodiment, the verification includes a preliminary check, wherein the preliminary check comprises: a first completeness check, wherein the completeness check is positive if a predetermined number of associated state data packets are present for the sequence number, and negative if fewer than the predetermined number of state data packets are present for the sequence number, wherein, in the case of a positive first completeness check, an evaluation of the state data packets is performed, wherein, in the case of a negative first completeness check, a predefined time period is waited before a second completeness check is performed, wherein, in the case of a positive second completeness check, an evaluation of the state data packets is performed, wherein, in the case of a negative second completeness check, the adaptation module is configured to send an error signal to the safety monitoring module in a format readable by the safety monitoring module.

[0044] For example, comparing the actual number of state data packets selected from the queue based on the sequence number with the predefined number can determine whether the state data packets associated with the sequence number are complete. In other words, it can be determined whether any state data packets are missing. The predefined number is derived, for example, from the number of state data packets that are created, or should be created, during a cycle. If no state data packets are missing, they can be evaluated in the next step. However, if state data packets are missing, a predefined time period is allowed before a second completeness check is performed.Additionally, the adaptation module can transmit a standby signal to the safety monitoring module. This standby signal indicates that the heartbeats corresponding to the sequence number specified in the action signal have not yet been fully processed. The safety monitoring module is thus informed that processing for the corresponding action signal is incomplete, so no safety action is triggered for the time being. For example, after the first completeness check, a predefined number of action signals or cycles are waited before the second completeness check is performed. If the result of the second completeness check is also negative, i.e., if state data packets are still missing, an error signal in a format readable by the safety monitoring module is sent to it.If the result of the second completeness check is positive, the status data packets can be evaluated in a next step.

[0045] As an alternative to the above embodiment, the preliminary check can also be designed such that an error signal is sent to the safety monitoring module as soon as the first completeness check fails. In such a case, no second completeness check is performed. This may be the preferred embodiment for particularly safety-critical applications where only a small margin of tolerance exists.

[0046] According to one embodiment, the verification of the state data includes an evaluation, wherein the evaluation comprises: a plausibility check of at least one of the state data packets and / or a status check of at least one of the state data packets, wherein the adaptation module is configured to send an evaluation data packet to the safety monitoring module in a format readable by the safety monitoring module if the plausibility check and / or the status check fails, the evaluation data packet indicating an error state. If, on the other hand, the plausibility check and the status check are successful, i.e., do not fail, the adaptation module is configured to send an evaluation data packet to the safety monitoring module in a format readable by the safety monitoring module, the evaluation data packet indicating that no error state exists.The plausibility check can, for example, verify whether the data in the state data packets falls within a range typical for that type of data. Furthermore, a predefined number of possible values ​​can be specified for at least one data field in the state data packets. If the actual field value does not match one of the predefined values, the plausibility check for that particular state data packet may fail.

[0047] According to one embodiment, the plausibility check of at least one of the state data packets includes the following checks: Verification of the verification mark of the state data package, which includes determining a comparison verification mark for the state data package using the data of the state data package and comparing the determined comparison verification mark with the verification mark of the state data package; verification of the plausibility of the creation time of the state data package and / or verification of whether the number of state data packages exceeds or falls below a predetermined number, whereby the plausibility check is considered to have failed if at least one of the checks included in the plausibility check fails for at least one of the state data packages.

[0048] The verification check verifies the correctness of the verification mark stored in the state data packet, which, as previously described, can be a hash value or a checksum. Specifically, this check verifies whether the data in the state data packet sent by the application module matches the data in the state data packet received by the adaptation module. The verification mark is generated based on all the data contained in the state data packet. For this purpose, a hash function can be used, which takes all the data in the state data packet, except for the verification mark, as input values ​​and outputs a checksum or a hash value as the verification mark. Therefore, any change to a data field in the state data packet would also result in a change to the verification mark.Since the comparison verification mark is calculated or determined according to the same rules as the verification mark, a comparison of the two marks can determine whether the transmitted data of the status data packet matches the received data of the status data packet, or whether the corresponding data has been manipulated, for example, in the form of data corruption. If the determined comparison verification mark and the verification mark do not match, this represents an error condition, and the verification is considered to have failed.

[0049] Furthermore, a plausibility check of the creation time of the state data packet can be performed. Such a check includes, for example, verifying the consistency of the creation time or the timestamp of the state data packet. Specifically, it is checked whether the creation time does not contain a negative value and / or whether the time base of the creation time matches that of the adaptation module. Should the plausibility check of the creation time fail, this constitutes an error state, and the check is considered to have failed.

[0050] The plausibility check can further include a verification process to determine whether the number of state data packets exceeds or falls below a predefined number. Specifically, it checks whether the number of state data packets exceeds a predefined number, as the case of a shortfall is preferably already checked in the preliminary check. However, it is also conceivable that the case of a shortfall is checked again in the plausibility check to create a degree of redundancy, which increases the system's security. If the result of the check is that the number of state data packets exceeds or falls below a predefined number, this represents an error condition, and the check is considered to have failed.

[0051] According to one embodiment, the status check comprises checking the status of all state data packets belonging to the sequence number, wherein the status check is deemed to have failed if at least one of the state data packets has a "failed" status. The status indicates, for example, whether the action associated with the state data packet was executed "successfully" or whether the action associated with the state data packet was "failed." In other words, the status check is deemed "successful" if all state data packets have "successful" statuses, i.e., none of the state data packets has a "failed" status.

[0052] In particular, if a plausibility check and a status check are successful, an evaluation data packet is sent to the safety monitoring module indicating a fault-free state. The evaluation data packet can include at least one of the following: a sender ID, a processing ID, a sequence number, an evaluation result, or a verification character. The sender ID, for example, is an identification character, such as a human-readable name, for the adaptation module and / or the application for which the adaptation module is used. The processing ID and sequence number correspond, for example, to the processing ID and sequence number contained in the action signal transmitted by the safety monitoring module. The evaluation result indicates whether the state data packets associated with the sequence number show a fault-free state or whether a fault state exists.For example, the evaluation result can be specified as a Boolean value, where "true" indicates a healthy state of the state data packets and "false" indicates an error state. The verification character of the evaluation data packet can be determined based on the data contained within the evaluation data packet, with the exception of the verification character itself. The preceding explanations regarding the verification character of the state data packets apply accordingly.

[0053] Another aspect of the invention relates to security methods for the secure processing of data within a software container environment, wherein the method comprises that: Application data is generated by a data generation unit; several logic modules run on a data processing unit within the software container environment to process the application data provided by the data generation unit; the logic modules include an application module, an adaptation module, and a safety monitoring module; state data is generated by the application module and belongs to an application; the state data indicates whether an application is running without errors or whether a faulty state exists that requires the execution of a safety function; the state data is received by the adaptation module and converted into a format processable by a safety monitoring module.wherein the converted state data is received by the safety monitoring module and, based on the converted state data, it is determined whether a fault condition exists, wherein the safety monitoring module performs a safety-oriented evaluation of the converted state data, wherein the application module, the adaptation module and the safety monitoring module are designed as part of an application component, in particular a standalone one.

[0054] Another aspect of the invention relates to a computer-readable storage medium comprising instructions which, when executed by a computer, cause it to execute the security procedure according to one of the preceding embodiments.

[0055] The above statements regarding the industrial machine apply accordingly to the safety procedure and to the computer-readable storage medium, particularly with regard to advantages and embodiments.

[0056] Furthermore, any combination of the above embodiments is possible unless explicitly excluded.

[0057] The invention is described below by way of example only, with reference to the drawings. The drawings show: Fig. 1 an industrial machine according to one embodiment, Fig. 2 a flowchart illustrating the operation of one embodiment, Fig. 3a, or embodiments of the invention, Fig. 4 a structure of a heartbeat, and Fig. 5 a flowchart illustrating an embodiment of the invention within a ROS application.

[0058] Fig. 1Figure 12 shows an industrial machine 12, for example a robot, for the secure processing of data within a software container environment. The industrial machine 12 comprises a data generation unit 14 for generating application data and a data processing unit 16 for processing the application data provided by the data generation unit 14 within the software container environment. The data generation unit 14 is connected to the data processing unit 16 via a connection 17 to transmit the application data to the data processing device 16. The data processing unit 16 is configured as an execution environment for running several logic modules 18-22 on the data processing unit.The logic modules 18-22 comprise an application module 18 for executing at least one application using the application data, wherein the application module 18 is configured to generate state data belonging to the application, an adaptation module 20 configured to receive the state data from the application module 18 and convert the state data into a format processable by a safety monitoring module 22, and the safety monitoring module 22 configured to receive the converted state data from the adaptation module 20 and to determine, based on the converted state data, whether an error condition exists.In response to the detection of a fault condition, the safety monitoring module 22 transmits a safety signal 39 to a control module (not shown) of the data processing device 16 or to a controller (not shown) of the industrial machine 12, which executes a safety action in response to the received safety signal 39. For example, the safety action may include returning the industrial machine 12 to a safe state. If the industrial machine 12 is, for example, a robot, the safety action may include: stopping the robot, restricting the robot's range of motion, and / or issuing a safety signal 39, e.g., an audible or visual safety signal 39.

[0059] Fig. 2 shows a flowchart illustrating the functionality of one embodiment. The previously described explanations regarding Fig. 1 still apply, whereby Fig. 2describes the data processing process in more detail.

[0060] The in Fig. 2The described processing process begins with the processing of state data packets by an adaptation module 20. These packets are generated cyclically, i.e., at fixed, regular intervals, by the application module 18. The state data packets contain data indicating the state of an associated application and are suitable for determining whether the application is in a potentially safety-critical error state. These state data packets are referred to as Heartbeats 24 and 26. The adaptation module 20 receives two types of Heartbeats 24 and 26: "Processing started" Heartbeat 24 and "Processing completed" Heartbeat 26. These two Heartbeat types are generated by the application module 18 and sent to the adaptation module 20 within a cycle, with each cycle containing exactly one Heartbeat 24 of the "Processing started" type and one Heartbeat 26 of the "Processing completed" type.

[0061] Each heartbeat 24,26 comprises respective data fields corresponding to a heartbeat ID 70, an application name 71, a creation time 72 of the heartbeat 24,26, a verification mark 73, a sequence number 74, a type 75 of the heartbeat 24,26, a status 76 of the heartbeat 24,26, or an attribute 77 of the heartbeat 24,26, as in Fig. 4 As shown, heartbeats 24 and 26 of the same cycle are assigned the same sequence number 74. These heartbeats are received by the adaptation module 20 and stored in a queue 28. In queue 28, heartbeats 24 and 26 are stored chronologically, i.e., according to their arrival time. Specific heartbeats 24 and 28 can also be accessed using their sequence number 74. Heartbeats 24 and 26 are not processed immediately; instead, they are first collected and organized in queue 28.

[0062] The next step involves the security monitoring module 22, which sends an action signal 30 to the adaptation module 20 via a previously opened interface. This action signal 30 contains a processing ID and a sequence number 75, which the adaptation module 20 uses to select the corresponding heartbeats 24 and 26 from queue 28. Subsequently, a check 34 of the heartbeats 24 and 26 is performed. This check 34 includes a preliminary verification of the completeness of the heartbeats 24 and 26 that correspond to the sequence number 74 contained in the action signal 30. Three possible scenarios are considered here: 1. All heartbeats corresponding to the sequence number are available:Since it is already known that each cycle comprises exactly two heartbeat types 75, i.e., a "processing started" heartbeat 24 and a "processing finished" heartbeat 26, two heartbeats 24 and 26 must be present for each sequence number 74. If two heartbeats 24 and 26 are present for a given sequence number 74, the adaptation module 20 can directly start an evaluation of the heartbeats 24 and 26 and send the evaluation result, along with the processing ID and sequence number 74, in an evaluation data packet 32 ​​to the security monitoring module 22. 2. No heartbeat is present:If no heartbeat 24,26 is present for sequence number 74, the adaptation module 20 waits a predefined time period or a predefined number of cycles, stores the corresponding metadata in a buffer, and sends a standby signal to the safety monitoring module 22. This standby signal indicates that the heartbeats 24,26, which belong to sequence number 74 specified in the action signal 30, have not yet been fully processed. If the heartbeats 24,26 arrive within the tolerated time period or cycles, the evaluation is carried out "normally"; otherwise, the adaptation module 20 identifies the processing as failed and sends a corresponding signal to the safety monitoring module 22. 3. Not all heartbeats are available:The procedure in such a case largely corresponds to the procedure in the case where no Heartbeat 24,26 is present, except that, in contrast, the existing Heartbeat 24,26 and the metadata are stored in the buffer.

[0063] When the adaptation module 20 receives the action signal 30 from the safety monitoring module 22 and it has been determined that all expected heartbeats 24,26 are present, the evaluation begins.

[0064] The evaluation of Heartbeats 24,26 includes the following tests: Plausibility check of the heartbeats:Here, adaptation module 20 checks the correctness of heartbeats 24 and 26. First, the checksum of heartbeat 24 and 26 is verified. For this purpose, a comparison checksum for heartbeat 24 and 26 is calculated using the data from heartbeat 24 and 26. This comparison checksum is generated according to the same rules as the checksum stored in heartbeat 24 and 26. The calculated comparison checksum is then compared with the checksum stored in heartbeat 24 and 26. The plausibility check is considered to have failed if the comparison checksum and the stored checksum do not match. Furthermore, the plausibility of the creation time 72 of heartbeat 24 and 26 is checked. This check includes verifying the consistency of the creation time 72, or the timestamp of the state data packet.Specifically, the system checks whether creation time 72 has a non-negative value and / or whether its time base matches the time base used by adaptation module 20. If the plausibility check of creation time 72 fails, i.e., if creation time 72 has a negative value and / or its time base does not match the time base used by adaptation module 20, this constitutes an error condition and the plausibility check is considered to have failed. Finally, the system checks whether the number of heartbeats (24,26) corresponds to the specified number of heartbeats (24,26) within a cycle, or whether the number of heartbeats (24,26) exceeds the specified number. The plausibility check is considered to have failed if the number of heartbeats (24,26) exceeds the specified number.If at least one of the above checks fails, the plausibility check is considered to have failed. Checking the status of heartbeats 24,26: Adaptation module 20 is configured to analyze field 76 of heartbeats 24 and 26, which represents the health of the transmitter or application module 18, respectively. Status 76 indicates either "true" (positive) or "false" (negative). All status 76 values ​​of heartbeats 24 and 26 are combined using a logical AND operation to obtain the final evaluation result for the given sequence number 74. That is, the evaluation result is positive if all status 76 values ​​of heartbeats 24 and 26 are "true," and negative if any of the status 76 values ​​of heartbeats 24 and 26 is "false." Additionally, depending on the application, the data contained in attribute 77 of heartbeats 24 and 26 can be used for evaluation, for example, specific status codes used by application module 18.

[0065] After evaluation, the evaluation result, along with a safety header, is converted into an evaluation data package 32 in a format that the safety monitoring module 22 can "understand" and process. This data is then sent to the safety monitoring module 22 via the provided interfaces, which integrates it into the safety infrastructure 60 of the container orchestration execution environment. This process ensures that the heartbeats 24 and 26 are evaluated correctly and reliably and that appropriate measures can be taken in the event of errors. For example, in response to the identification of an error condition, a safety signal 39 is transmitted from the safety monitoring module 22 to a controller to initiate a safety action.For example, the security infrastructure 60 of the container orchestration execution environment represents a specialized infrastructure or architecture that ensures security and compliance requirements in distributed systems.

[0066] Figs. 3a and 3b Figure 1 shows two different embodiments of the invention. The application module 18, the adaptation module 20, and the safety monitoring module 22 are shown in Figs. 3a and 3b are formed within the Kubernetes ecosystem as part of a Kubernetes pod 36, i.e. as part of an application component.

[0067] In Fig. 3aHowever, application module 18 and adaptation module 20 are implemented on the same container 38, and both use the same software technologies. For example, application module 18 and adaptation module 20 use the same framework, system, programming library or paradigm, and / or the same data structures and types. This approach has the advantage that no complex adaptation mechanisms are required between adaptation module 20 and application module 18, since both modules are already implemented on the same container 38 and therefore share the same underlying software technologies.

[0068] On the other hand, there are the application module 18 and the adaptation module 20. Fig. 3bThe adaptation module 20 is implemented on different containers 38, with adaptation mechanisms such as RPC (Remote Procedure Call) being adapted to the software technologies used by the application module 18. This variant offers the advantage of increased resilience when multiple application modules 18 use the same adaptation module 20 or exchange data with the same adaptation module 20. Furthermore, this variant can be implemented with less overhead and lower latency.

[0069] Fig. 4Figure 24,26 illustrates the structure of a Heartbeat, where the Heartbeat comprises the following data fields: a Heartbeat ID 70 of data type string, an application label 71 of data type string, a creation time 72 of the Heartbeat 24,26 of data type Int, a verification character 73 of data type string, a sequence number 74 of data type Int, a type 75 of the Heartbeat 24,26 of data type string, a status 76 of the Heartbeat 24,26 of data type Boolean, or an attribute 77 of the Heartbeat 24,26 of data type List.

[0070] Fig. 5 Figure 40 shows a flowchart illustrating an embodiment of the invention within a ROS application.

[0071] This system uses a ROS-based approach for processing and analyzing image data, which in this case is provided by a SICK safeVisionary2 camera (sV2). The system consists of several ROS nodes that work together to detect and count people within a defined area. The ROS nodes correspond, for example, to the modules described above and are independent programs or processes within a ROS system. These ROS nodes are deployed as Kubernetes pods in Kubernetes containers, and all messages within the ROS system are managed via an internal ROS messaging system. ROS is used specifically for connecting the sV2 camera, defining messages, and distributing messages within the ROS environment.

[0072] The processing chain in the system begins with a sensor port pod 44, which collects data from the sV2 camera. The collected sensor data is made available via ROS topics 46 and is thus accessible throughout the entire ROS ecosystem. ROS topics 46 are communication channels in a ROS network that enable the exchange of messages between ROS nodes. In a ROS system, different nodes can communicate with each other by publishing or subscribing to messages on these ROS topics 46. The raw data filter pod 48 is responsible for filtering the incoming raw data before it is processed further. Subsequently, person detection is performed via the object detection pod 50, and the number of people in a defined area is determined.

[0073] Each Kubernetes pod 36 comprises a ROS application node 52, a ROS adaptation node 54, and a Safety Watcher 56 (i.e., a safety monitoring node), with each Kubernetes pod 36 deployed as a container 38. Furthermore, the Safety Watcher 56 is implemented in a separate container 38. The adaptation module 20 is itself a ROS node, namely the ROS application node 52, which seamlessly interacts with ROS messages and their formats.

[0074] The following describes the processing workflow of a Kubernetes pod 36 using the raw data filter pod 48 as a purely exemplary example, although the explanations are applicable to other Kubernetes pods. The terms ROS application node 52, ROS adaptation node 54, and Safety Watcher 56 therefore refer to the respective nodes of the raw data filter pod 48, unless otherwise stated in the description.

[0075] The ROS application node 52 receives messages 58 from the preceding ROS application node 52, i.e., the preceding pod, via the internal ROS messaging system. Upon receiving a message 58, the ROS application node 52 begins processing and sends a "Processing started" heartbeat 24 and a "Processing finished" heartbeat 26 to the corresponding ROS adaptation node 54, i.e., the raw data filter adaptation node. Since the adaptation node is also a ROS node and heartbeats 24 and 26 are defined as ROS message types, it is able to receive and process these heartbeats 24 and 26. The heartbeats 24 and 26 can, for example, represent a Fig. 4 exhibit the structure shown.

[0076] The ROS adaptation node 54 receives heartbeats 24 and 26 and stores them in a map that serves as queue 28. This map has the structure Map<Sequenznummer, List[Heartbeat]>This allows heartbeats 24 and 26 to be sorted according to their sequence number 74 and retrieved selectively as needed. This ensures that heartbeats 24 and 26 are processed chronologically and correctly.

[0077] In parallel to the processing by the ROS adaptation node 54, processing also occurs via a safety infrastructure 60 of the container orchestration execution environment. The safety watcher 56 of the preceding pod sends a safety watcher signal in the form of a safety header via the safety infrastructure 60. This header is received by the safety watcher 56 of the current pod and forwarded to the ROS adaptation node 54. This safety header contains a sequence number 74, a processing ID, and a checksum calculated in the preceding ROS adaptation node 54 against a data payload, i.e., the user data. For example, this could be an application-specific payload consisting of the general description of the data. The transfer of the safety header occurs, for example, via a gRPC streaming connection that was opened during the initialization of the ROS adaptation node 54.

[0078] The ROS adaptation node 54 receives the signal from the Safety Watcher 56 and accesses the corresponding heartbeats 24 and 26 stored in queue 28, based on sequence number 74. The following checks are then performed: First, it is verified whether all expected heartbeats 24 and 26 are present. For this purpose, a completeness check, as previously described, is performed. If heartbeats 24 and 26 are missing, this leads directly to a negative evaluation; that is, no tolerance period is provided for missing heartbeats 24 and 26. Next, the ROS adaptation node 54 compares the checksum sent by the Safety Watcher 56 signal with the checksum contained in the "Processing started" heartbeat 24. The checksum can, for example, be stored in an attribute field 77 of heartbeat 24 and 26.In addition, the status 76 of heartbeats 24,26 is checked, whereby a positive status 76 can be signaled by a status value 'HEALTH_OK'.

[0079] If any of the listed checks fail, the ROS adaptation node 54 immediately sends a negative evaluation message, i.e., an evaluation data packet 32 ​​indicating an error state, to the Safety Watcher 56. This marks the point at which the ROS system is exited and the regular monitoring and / or safety mechanisms of the security infrastructure 60 of the container orchestration execution environment are applied. Overall, this approach ensures the safety and reliability of system processing by enabling precise monitoring and validation of the heartbeats 24, 26, as well as an accurate response to security incidents. Reference symbol list

[0080] 12 Industrial Machine 14 Data Generation Unit 16 Data Processing Unit 17 Connection 18 Application Module 20 Adaptation Module 22 Safety Monitoring Module 24 "Processing started" - Heartbeat 26 "Processing finished" - Heartbeat 28 Queue 30 Action Signal 32 Evaluation Data Packet 34 Verification 36 Kubernetes Pod 38 Container 39 Safety Signal 40 ROS Application 42 safeVisionary2 Camera 44 Sensor Port Pod 46 ROS Topics 48 Raw Data Filter Pod 50 Object Detection Pod 52 ROS Application Node 54 ROS Adaptation Node 56 Safety Watcher 58 Message 60 Safety Infrastructure 70 Heartbeat ID 71 Application Label 72 Creation Time 73 Verification Sign 74 Sequence Number 75 Type 76 Status 77 Attribute

Claims

1. An apparatus for use in an industrial environment, in particular an industrial machine (12), for the secure processing of data within a software container environment, comprising: a data generation unit (14) for generating application data, a data processing unit (16) for processing the application data provided by the data generation unit (14) within the software container environment, wherein the data processing unit (16) is designed as an execution environment to allow a plurality of logic modules to run on the data processing device, wherein the logic modules comprise: at least one application module (18) for executing at least one application using the application data, wherein the application module (18) is configured to generate state data associated with the application, wherein the state data indicate whether an application is executed without error or whether a faulty state exists that requires the execution of a safety function, an adaptation module (20) which is configured to receive the state data from the application module (18) and to convert the state data into a format processable by a safety monitoring module (22), the safety monitoring module (22) which is configured to receive the converted state data from the adaptation module (20) and to determine, based on the converted state data, whether a fault condition exists, wherein the safety monitoring module (22) performs a safety-oriented evaluation of the converted state data, wherein the application module (18), the adaptation module (20) and the safety monitoring module (22) are designed as part of an application component, in particular a standalone one.

2. An apparatus according to claim 1, wherein the application module (18), the adaptation module (20) and / or the safety monitoring module (22) accesses / access the same resources.

3. An apparatus according to claim 1 or 2, wherein the application module (18) and the adaptation module (20) are implemented on the same container (38), wherein the adaptation module (20) and the application module (18) use the same software technologies.

4. An apparatus according to any one of the preceding claims, wherein the application module (18) and the adaptation module (20) are implemented on different containers (38), wherein the adaptation module (20) is adapted to the application module (18), in particular to the software technologies used by the application module (18), by means of adaptation mechanisms.

5. An apparatus according to any one of the preceding claims, wherein the adaptation module (20) communicates with a plurality of different application modules (18) and / or is used for a plurality of different applications.

6. An apparatus according to any one of the preceding claims, wherein the state data comprise state data packets, wherein a state data packet comprises at least one of the following: a state data packet ID, an application designation (71), a creation time (72) of the state data packet, a verification token (73), a sequence number (74), a type (75) of the state data packet, a status (76) of the state data packet or an attribute (77) of the state data packet.

7. An apparatus according to claim 6, wherein the application module (18) is configured to generate the state data packets cyclically, wherein a predefined number of state data packets is generated within a cycle, wherein the state data packets of the same cycle have the same sequence number (74).

8. An apparatus according to any one of the claims 5 to 7, wherein the adaptation module (20) is configured to arrange the state data packets in a queue (28) in an order corresponding to the chronological arrival of the state data packets.

9. An apparatus according to any one of the claims 5 to 8, wherein the adaptation module (20) is configured, in response to an action signal (30) which is received from the safety monitoring module (22) and which comprises a processing ID, a sequence number (74) and / or a verification token (73), to verify the state data packets which are associated with the sequence number (74) stored in the action signal (30).

10. An apparatus according to claim 9, wherein the verification (34) comprises a preliminary check, wherein the preliminary check comprises: a first completeness check, wherein the completeness check is positive if a predetermined number of associated state data packets are present for the sequence number (74), and negative if fewer than the predetermined number of state data packets are present for the sequence number (74), wherein, if the first completeness check is positive, an evaluation of the state data packets is performed, wherein, if the first completeness check is negative, a predefined time interval is waited out until a second completeness check is performed, wherein, if the second completeness check is positive, an evaluation of the state data packets is performed, wherein, if the second completeness check is negative, the adaptation module (20) is configured to send an error signal in a format readable by the safety monitoring module (22) to the safety monitoring module (22).

11. An apparatus according to one of the claims 9 or 10, wherein the verification (34) of the state data comprises an evaluation, wherein the evaluation comprises: a plausibility check of at least one of the state data packets and / or a status check of at least one of the state data packets, wherein the adaptation module (20) is configured to send, in the event of a failed plausibility check and / or a failed status check, an evaluation data packet (32) in a format readable by the safety monitoring module (22) to the safety monitoring module (22), wherein the evaluation data packet (32) indicates a fault condition.

12. An apparatus according to claim 11, wherein the plausibility check of at least one of the state data packets comprises the following checks: verification (34) of the verification token (73) of the state data packet, which comprises determining a comparison verification token for a state data packet using the data of a state data packet and comparing the determined comparison verification token with the verification token (73) of the state data packet, verification (34) of a plausibility of the creation time (72) of the state data packet and / or verification (34) whether the number of state data packets exceeds or falls short of a predetermined number, wherein the plausibility check is deemed to have failed if at least one of the checks included in the plausibility check fails for at least one of the state data packets.

13. An apparatus according to claim 11 or 12, wherein the status check comprises: checking the status (76) of the state data packets, wherein the status check is deemed to have failed if at least one of the state data packets has a status (76) of "failed".

14. A safety method for securely processing data within a software container environment, wherein the method comprises that: application data are generated by a data generation unit (14), on a data processing unit (16) for processing the application data provided by the data generation unit (14) within the software container environment, a plurality of logic modules run on the data processing device, wherein the logic modules comprise an application module (18), an adaptation module (20) and a safety monitoring module (22), state data associated with an application are generated by the application module (18), wherein the state data indicate whether an application is executed without error or whether a faulty state exists that requires the execution of a safety function, the state data are received by the adaptation module (20) and the state data are converted into a format processable by a safety monitoring module (22), wherein the converted state data are received by the safety monitoring module (22) and, based on the converted state data, it is determined whether a fault condition exists, wherein the safety monitoring module (22) performs a safety-oriented evaluation of the converted state data, wherein the application module (18), the adaptation module (20) and the safety monitoring module (22) are designed as part of an application component, in particular a standalone one.

15. A computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to perform the safety method according to claim 14.