SAFETY DEVICES AND SAFETY PROCEDURES

Description

[0001] The invention relates to safety devices and safety methods.

[0002] Safety engineering deals with personal protection and the prevention of accidents involving machinery. A safety device of this type uses one or more sensors to monitor a machine and its surroundings, and to bring it to a safe state in time if danger threatens. A typical conventional safety solution uses at least one sensor, such as a laser scanner, to monitor a protective field that operators must not enter while the machine is running. If the sensor detects an unauthorized intrusion into the protective field, such as an operator's leg, it triggers an emergency stop of the machine. Alternative protection concepts exist, such as speed and separation monitoring, which evaluates the distances and speeds of detected objects in the environment and reacts accordingly in case of danger.

[0003] InSafety technology demands exceptional reliability, and therefore stringent safety requirements must be met, such as the EN13849 standard for machine safety and the EN61496 standard for non-contact protective devices. Typical measures include reliable electronic evaluation through redundant, diverse electronics or various functional monitoring systems, such as monitoring the contamination of optical components, including a front lens. More generally, well-defined fault control measures must be demonstrated to prevent or control potential safety-critical errors along the signal chain, from the sensor through the evaluation to the initiation of the safety response.

[0004] Due to the high demands placed on hardware and software in safety engineering, monolithic architectures are primarily used to date, with specifically developed hardware that incorporates redundancy and functional monitoring through multi-channel capabilities and testing capabilities. Accordingly, proof of correct algorithms is provided, for example, according to IEC TS 62998 and IEC 61508-3, and the software development process is subject to continuous, rigorous testing and verification. An example of this is a safety laser scanner, such as the one first described in DE 43 40 756 A1, which, in its basic form, remains widely used today. This scanner integrates all evaluation functionality, including time-of-flight measurement for distance determination and object detection within configured protective fields.The result is a fully evaluated binary safety signal at a two-channel output (OSSD, Output Signal Switching Device) of the laser scanner, which stops the machine in the event of a breach of the protective field. Although this concept has proven effective, it remains inflexible, as modifications are practically only possible through the development of a new successor model of the laser scanner.

[0005] In some conventional safety applications, at least part of the evaluation from the sensor is offloaded to a programmable logic controller (PLC). However, this requires special safety controllers that themselves employ multi-channel structures and similar features for error prevention and detection. They are therefore expensive and offer comparatively little memory and processing power, which is completely overwhelmed by tasks such as 3D image processing.

[0006] While the use of standard controllers would be theoretically conceivable, provided they are integrated with the necessary functional monitoring, this is rarely used in industrial environments today due to the need for more complex architectures and expert knowledge. Furthermore, standard controllers or PLCs are only programmable using specific languages, some with very limited language ranges. Even relatively simple function blocks require considerable development effort and runtime resources, making their implementation in a standard controller, especially with safety measures such as redundancies, practically impossible in more complex applications.

[0007] The EP 3 709 106 A1 combines a safety controller with a standard controller in a single safety system. More complex calculations are handled by the standard controller, and its results are validated by the safety controller. However, the safety controller relies on existing safe data from a safe sensor, which limits the possible application scenarios and also requires expert knowledge to acquire and properly validate suitable safe data. Furthermore, the hardware architecture remains fixed, and the application is specifically implemented within it.

[0008] In many cases, it would be desirable to combine safety monitoring with an automation task. This would not only prevent accidents but also automate the machine's core function. Currently, however, completely different systems and sensors are typically used for this purpose. This is partly because a safety sensor for an automation task is far too expensive, and conversely, the complexity of a safety sensor should not be increased by additional functions. EP 2 053 538 B1 allows the definition of separate safety and automation areas for a 3D camera. However, this is only a first step, as although the same sensor is used for both safety and automation, these two tasks are still clearly separated both spatially and in terms of implementation.IEC 62998 enables the coexistence of safety and automation data, but as a standard it does not make any concrete implementation suggestions.

[0009] Outside of security technology, far more flexible architectures have long existed. The monolithic approach has been gradually replaced by more modern concepts. While the earlier traditional deployment model with fixed hardware, where an operating system coordinates individual applications, still has its place in standalone devices, it is no longer sufficient in a networked world. The fundamental idea behind this evolution has been the introduction of additional layers that increasingly abstract away from the specific hardware.

[0010] A first step involves so-called virtual machines, where the additional layer is referred to as a hypervisor or virtual machine monitor. Such approaches are now also being cautiously pursued in security technology. For example, EP 3 179 278 B1 offers a protected environment in a security sensor, allowing users to run their own program modules on the sensor.

[0011] However, such program components are carefully separated from the safety functionality and do not contribute to it.

[0012] A more advanced abstraction is based on so-called containers (container virtualization, containerizing). A container is essentially a small virtual capsule for a software application, providing a complete environment for its execution, including memory areas, libraries, and the like. The associated abstracting layer or runtime environment is called the container runtime. This allows the software application to be developed independently of virtually any hardware on which it will later run. Containers are frequently implemented using Docker.

[0013] In a modern IoT (Internet of Things, Industrial Internet of Things) architecture, a multitude of containers with diverse software applications are brought together. These containers must be properly coordinated, a process known as orchestration, for which an orchestration layer is added as a further abstraction. Kubernetes is increasingly becoming the standard for container orchestration; alternatives such as Docker Swarm (an extension of Docker), rkt, and LXC are also well-known.

[0014] The use of such modern, abstract architectures in safety engineering has so far been hampered by the high hurdles of safety standards and the correspondingly conservative approach in the field of functional safety. Container technologies are generally being pursued in industrial environments, and there are plans for the use of Kubernetes architectures in the automotive industry, for example, and the air force is also pursuing such approaches. However, none of this focuses on functional safety and therefore does not solve the aforementioned problems.

[0015] While high availability is desirable even in a typical IoT environment, this level of fault tolerance is far from comparable to what security standards require. For security engineers, edge or cloud applications are therefore currently inconceivable for achieving standards-compliant security. It contradicts the common approach of ensuring reproducible conditions and protecting against every conceivable malfunction under those conditions. Extensive abstraction or virtualization creates an additional uncertainty that, until now, has appeared incompatible with security requirements.

[0016] In digital industrial applications, there is always a tension between the multitude of available functionally unsafe solutions and functional safety. Cloud-native technologies could offer an approach to addressing this tension. Besides virtually unlimited computing power, cloud-native technologies also offer concepts like observability and resiliency, which are similar to the requirements of security solutions. These cloud-native concepts can be implemented using existing open-source frameworks and tools designed for large (non-functionally safe) applications. Combining these frameworks and tools with established security approaches can enable functional safety for cloud-native applications.

[0017] EP 4 040 034 A1 presents a safety device and a safety procedure for monitoring a machine, in which the safety functionality can be abstracted from the underlying hardware using the aforementioned container and orchestration technologies. Logic units are created, dissolved, or assigned to other hardware as needed. This enables variable levels of redundancy and flexible mutual monitoring of logic units. Special logic units configured as diagnostic units are proposed for testing and monitoring. However, EP 4 040 034 A1 does not explain how a specific safety task can be addressed.

[0018] EP 3 919 991 A2 discloses a distributed building management system with a virtual controller and an edge controller for controlling a building control device using distributed control logic that is distributed between the virtual controller and the edge controller. A programming tool displays a graphical representation of the distributed control logic and identifies which parts of the distributed control logic are considered critical and which are considered non-critical for the fail-safe operation of the building control device if the edge controller no longer receives control commands from the virtual controller. The parts of the distributed control logic identified as critical are assigned to the edge controller for execution, while the parts of the distributed control logic not identified as critical are assigned to the virtual controller for execution.

[0019] US 2022 / 404804 A1 discloses a software-defined (SD) process control system (SDCS) that includes a control container with content executable during the runtime of the process plant to control at least one area of ​​an industrial process. The SDCS also includes a security service connected to the control container, containing content that defines one or more security conditions. The security service runs via a container on a compute node of the SDCS to control access to and / or data flow from the control container based on the content of the security container.

[0020] The object of the invention is to provide devices and methods that can address specific safety tasks.

[0021] The problem is solved by a safety device having the features of claim 1 and a safety method having the features of claim 11.

[0022] A safety device according to the invention for monitoring at least one machine comprises at least one sensor for generating sensor data about the machine and a processing unit for the sensor data, which is at least indirectly connected to the sensor and the machine and is configured as an execution environment with at least one computing node and for running at least one logic unit on the computing node, wherein at least one logic unit comprises at least one safety function unit for safety-oriented evaluation of the sensor data in order to output a safety signal to the machine in the event of a safety-relevant event to trigger a safety reaction, wherein the processing unit is further configured to generate, modify, and / or resolve logic units based on a safety task;wherein the safety device further comprises a monitoring device configured to ensure compliance with safety coding guidelines, and / or to determine safety-related information, and / or to provide interfaces for each safety functional unit; wherein the safety device is further configured to dynamically create, add, or remove monitoring devices; and wherein the safety device is further configured to validate resources for safety-related tasks.

[0023] The unit trained to create, modify, and / or resolve logic units based on a security task can be called an "Automated resource orchestrator" (ARO) and is described in detail below.

[0024] For example, based on the security task, the container image can be changed without changing the content logic itself.

[0025] For example, simple monitoring of the distance between a person and a robot can be provided using a sensor. The logic (i.e., the evaluation to compare the distance to the robot with a threshold value) in Container Image A can be implemented using simple security mechanisms such as memory validation. Container Image B can be implemented using more advanced technologies, such as software-coded processing. The logic itself can remain the same, and the modification can be made based on the requirements of the security task.

[0026] In one configuration, the security task can be user-defined.

[0027] In various embodiments, the safety task can be determined during the running time of the safety device.

[0028] The logic units can be created, modified, and / or resolved based on the security task by an automated resource orchestrator provided within the execution environment or by an automated resource orchestrator provided outside the execution environment (22) (in other words, a "standalone" ARO).

[0029] The safety device may also include an interface for modeling a protection task as an atomic unit. This interface can be provided using a Domain Scoped Object (DSO) and is described in detail below.

[0030] The safety device also includes a monitoring device configured to ensure compliance with safety coding guidelines, and / or to identify safety-related information, and / or to provide interfaces for each safety functional unit. The monitoring device may be referred to as a "safety watcher" and is described in detail below.

[0031] The safety device is further configured to dynamically create, add, or remove monitoring devices. This can be accomplished by an initialization logical unit (LU-I) and is described in detail below.

[0032] The safety device is further equipped to validate resources for safety-related tasks. This can be accomplished by a logical validation unit (LU-V) and is described in detail below.

[0033] The machine to be monitored or secured is initially understood in general terms; for example, it could be a processing machine, a production line, a sorting system, a process plant, a robot, or a vehicle in its numerous variations, such as rail-bound or non-rail-bound, guided or driverless, and so on. At least one sensor provides sensor data about the machine, i.e., data about the machine itself, about what it interacts with, or about its environment. The sensor data is at least partially safety-relevant; additional non-safety-relevant sensor data for automation or convenience functions is conceivable. The sensors can be, but do not have to be, safety sensors; safety can be ensured downstream.

[0034] A processing unit functions as an execution environment (which can also be referred to as a "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 sensor and the machine. It therefore has access to the sensor data for processing, possibly indirectly via intermediary units, and can communicate with and, in particular, interact with the machine, preferably via the machine's control system. The processing unit or execution environment is a collective term for the hardware and software used to determine, based on the sensor data, the necessity and, preferably, the type of safety-related response from the machine.

[0035] The processing unit comprises at least one compute node. This is a digital computing device, or a hardware node or part thereof, that provides computing and storage capacity for executing a software function block. However, not every compute node necessarily has to be a separate hardware component; for example, multiple compute nodes can be implemented on the same device by using multiprocessors, and conversely, a single compute node can combine different hardware resources.

[0036] Several logic units run on the compute node or one of the compute nodes during the operation of the safety device. A logic unit (which can also be referred to as a "logic unit") generally denotes a software function block. A logic unit can, for example, be designed as a container running within Kubernetes. According to the invention, at least one logic unit is configured as a safety function unit that performs a safety-oriented evaluation of the sensor data. The aim of the safety-oriented evaluation is to protect people or prevent accidents by using the sensor data to determine whether a hazard is imminent or whether a safety-relevant event has been detected. This is the case, for example, when a person is detected too close to the machine or in a protective field. One or more logic units can be involved in the safety-oriented evaluation.In the event of a safety-related incident, a safety signal is preferably output to the machine to trigger a safety-related response that brings the machine into a safe state, eliminating the hazard or at least reducing it to an acceptable level. Furthermore, at least one logic unit is designed as a diagnostic unit. This monitors the function of other logic units, and in particular the at least one safety function unit, for errors.

[0037] The approach according to the invention is radically different from conventional methods in safety engineering. Up to now, a fixed hardware structure has been specified, usually developed specifically for this safety function, and the software functionality has been developed, permanently implemented, and tested for precisely this hardware structure. Subsequent changes to the software deployment are impossible, and this is even more true if the underlying hardware is changed. Conventionally, such modifications require at least a complex redesign by a safety expert, and usually a complete redevelopment. A consequence of the typical conservative approach in industry, and especially in safety engineering, is that even firmware or software updates for sensors and controllers are performed only very infrequently, and typically not at all.

[0038] This description repeatedly uses the terms "safety" or "secure." This is preferably to be understood in the sense of a safety standard. Accordingly, a safety standard is met, for example, for machine safety, non-contact protective devices, or accident prevention in personal protection. Alternatively, to put it somewhat differently, safety levels defined by standards are adhered to, meaning that errors are controlled up to a safety level specified in the safety standard or an analogous standard. Some examples of such safety standards are given at the beginning, where the safety levels are referred to, for example, as protection classes or performance levels. The invention is not limited to any specific of these safety standards, which may change regionally and over time in their specific numbering and wording, but not in their fundamental principles for creating safety.

[0039] Later, in some embodiments, the concept of safety is somewhat broadened to include context-related or situational safety.

[0040] The execution environment is preferably implemented in Kubernetes. There, the execution environment is referred to as the "control plane." A master coordinates the overall processes, or orchestration (or orchestration layer). Compute nodes in Kubernetes are called nodes, and they have at least one subnode or pod in which the logic units run in their respective containers. Kubernetes already has mechanisms for checking whether a logic unit is still running. However, this check does not meet any security-specific requirements and is essentially limited to occasionally receiving a sign of life and possibly restarting a container. There are no guarantees as to when the error will be detected and resolved.

[0041] The execution environment is preferably designed to create, resolve, and assign logic units to a compute node, or to move them between compute nodes. This preferably occurs not only once, but also dynamically during operation, and explicitly includes the safety-relevant logic units, i.e., the at least one safety function unit and / or the diagnostic unit. The connection between hardware and evaluation thus becomes seamless while maintaining functional safety. Traditionally, however, all safety functions are implemented rigidly and immutably on dedicated hardware. Any modification, even if feasible without redesign or redevelopment, would be considered completely incompatible with the underlying safety concept. This applies even to a one-time implementation and all the more so to dynamic changes at runtime.On the contrary, every effort has always been made, with considerable expense and numerous complex individual measures, to ensure that the safety function finds a well-defined and unchanged environment both initially and throughout its entire operating period.

[0042] The execution environment is preferably configured to modify the resources allocated to a logic unit. This can support faster processing for that logic unit, but also free up resources for other logic units. Specific ways to provide more resources include moving a logic unit to a different compute node or creating another instance or copy of the logic unit, with the latter preferably being configured for parallelizable execution.

[0043] The execution environment preferably stores configuration information or a configuration file about the logic units. This configuration information is used to keep track of the available logic units, specify which logic units should be executed, when they should be executed, which resources should be used, and how they might relate to each other.

[0044] The configuration information is preferably protected against manipulation using signatures or blockchain data records.

[0045] Such manipulation can be intentional or unintentional; in any case, the configuration of the logic files in a security application should never change unnoticed.

[0046] The execution environment preferably includes at least one master unit that communicates with and coordinates the compute nodes. For redundancy and / or distributed responsibility, the master unit may also have multiple subunits or be supported by node manager units of the compute nodes and be implemented on a dedicated compute node or on a compute node shared with logic units.

[0047] The at least one compute node preferably includes a node manager unit for communication with other compute nodes and the execution environment. This node manager unit is responsible for the management and coordinates of the associated compute node, in particular the logic units of this compute node, as well as for its interaction with the other compute nodes and the master unit. It can also assume tasks of the master unit in virtually any distribution.

[0048] Each compute node preferably has at least one subnode, and the logic units are assigned to a subnode. This further structures the compute nodes internally, grouping logic units within a single subnode. Kubernetes also follows this concept in the form of pods.

[0049] At least one logic unit is preferably implemented as a container. This encapsulates or containerizes the logic units, making them capable of running on virtually any hardware. The otherwise typical close relationship between safety functions and their implementation on fixed hardware is broken, significantly increasing flexibility and process stability. The execution environment coordinates or orchestrates the containers and their respective logic units. There are at least two abstraction layers: a container runtime and an orchestration layer of the execution environment.

[0050] The execution environment is preferably implemented on at least one sensor, a programmable logic controller (PLC), a machine controller, a computer device in a local network, an edge device, and / or in a cloud. In other words, the underlying hardware landscape is practically arbitrary, which is a major advantage of the approach according to the invention. The execution environment operates abstractly with computational nodes; the underlying hardware can be very heterogeneous. In particular, edge or cloud architectures become accessible to security technology without having to forgo the familiar evaluation hardware of (secure) sensors or controllers.

[0051] The execution environment is preferably designed to include and / or exclude compute nodes. The hardware environment may change, and the execution environment is capable of handling this change and creating new or adapted compute nodes. It is therefore possible to connect new hardware or replace existing hardware, particularly for replacement in case of (partial) failure, as well as for upgrades and the provision of additional computing and storage resources. The logic units can continue to operate on the compute nodes abstracted by the execution environment, even if the hardware configuration has changed drastically.

[0052] On the contrary, every effort is always made, with considerable expense and numerous complex individual measures, to ensure that the safety function finds a well-defined and unchanged environment both initially and throughout its entire operating period.

[0053] Advantageously, a safety function unit is designed to dynamically determine a required or achievable safety level for the safety device. Determining a required safety level can be done within the framework of a behavior-driven risk assessment (BDRA). In this approach, a safety device is no longer assigned a fixed safety level, but rather the required safety level is determined situationally. The safety function unit makes this decision based on sensor data and, if necessary, other data, such as an operating mode communicated by a machine controller. Conversely, it is also conceivable that the safety function unit determines the safety level that the safety device provides in its current configuration.This, of course, necessitates a safety-related response if the achievable safety level is lower than the required safety level, although this response may be less severe than an immediate emergency stop. With the achievable safety level, certain operating modes, such as slower robot movement or a vehicle creeping along, are still permissible, allowing at least a certain level of productivity to be maintained.

[0054] The execution environment is preferably designed to dynamically adjust the safety level of the safety device by at least one of the following measures: changing test cycles, changing redundancy, and / or changing diversity. The newly achieved safety level can be externally specified or dynamically determined as described in the preceding paragraph. There are various parameters for adjusting the safety level, namely, firstly, the length of test cycles after which tests are repeated, or more generally, the times at which a diagnostic unit tests or monitors a safety function unit; secondly, the redundancy multiplicity or the number of logic units responsible for executing a safety function; and / or thirdly, the diversity that arises from implementing logic units responsible for a safety function on the same or different subnodes or compute nodes.The safety level is changed by means of at least one of these adjustment parameters. Another conceivable adjustment parameter involves replacing logic modules responsible for specific tasks, for example, a simple safety function unit or diagnostic unit with a complex safety function unit or diagnostic unit, or vice versa.

[0055] Test cycles can be long or short. This is optionally determined by time intervals, such as a test every x milliseconds, or by the sensor's measurement cycles or the sensor data evaluation cycles. m test cycles can be defined for n measurement or evaluation cycles, and the ratio m:n, typically with m>n up to m=n=1, determines the desired frequency. A so-called pre-demand test is also conceivable, which operates less in regular cycles and more event-driven.

[0056] Redundancy may not be provided at all, or two or more copies or instances of safety-relevant logic units may be created. This effectively results in a corresponding multi-channel evaluation.

[0057] Diversity arises when redundant logic units, or even just a safety function unit and its associated diagnostic unit, are implemented on different subnodes or, preferably, different compute nodes. The diversity increases the more subnodes or compute nodes the logic units are distributed across. This is a special form of diversity that is primarily hardware-related. To be able to run on different hardware, the software naturally also differs, but according to the invention, these differences are abstracted or encapsulated from the actual logic unit and are supported by the execution environment, and in particular its container or orchestration layer. Nevertheless, such software differences can certainly contribute to useful diversity.Furthermore, even greater diversity could be achieved through different implementations or even algorithms within the logic units. While this can be advantageously combined with the invention, the execution environment itself cannot provide this; that responsibility lies with the individual programming of the logic units. A certain degree of additional diversity could be created by using different compilers and similar automatable variations.

[0058] The execution environment is preferably designed to set the safety level of the safety device to: Low: A safety function is implemented only once in one safety-related logic unit; a diagnosis is performed only with every nth sensor cycle or before a request. Medium: A safety function is implemented only once in one safety-related logic unit; a diagnosis is performed in short cycles, especially with each sensor cycle. High: A safety function is implemented redundantly in two safety-related logic units; a diagnosis is performed in short cycles, especially with each sensor cycle, and the diagnoses are compared. Very high: A safety function is implemented redundantly in at least three safety-related logic units; a diagnosis is performed in short cycles, especially with each sensor cycle, and the diagnoses are compared.

[0059] For low and medium security levels, redundancy is entirely omitted, and only the frequency or complexity of tests is adjusted. At high security levels, dual-channel redundancy with mutual diagnostics is added, and at very high security levels, even greater redundancy is implemented. Furthermore, diversity could be achieved by assigning tasks to different subnodes or compute nodes. This is just one example of how the three control parameters presented—test cycles, redundancy, and diversity—can be used to achieve different security levels. Finer, coarser, and other gradations of security levels are conceivable, particularly through different combinations of each control parameter. For example, high redundancy and / or diversity can certainly be combined with slow test cycles.

[0060] At least one logic unit is preferably configured as an automation unit, which generates information relevant to an automation task and / or a control command for the machine from the sensor data. Neither the information nor the control command is safety-relevant. The automation unit (which can also be referred to as an "automation unit") is a logic unit that executes an automation task. The execution environment thus supports another type of logic unit that provides additional, non-safety-relevant functions based on the sensor data. Such automation tasks do not concern personal safety or accident prevention, and therefore no safety standards need to be met in this respect. Typical automation tasks include quality and process controls, object recognition for gripping, sorting, or other processing steps, classifications, and the like.An automation unit also benefits when the execution environment allocates flexible resources to it and monitors whether it is still performing its task, for example, restarting the corresponding logic unit, moving it to another compute node, or creating a copy of the logic unit if necessary. This focuses on availability, avoiding downtime, and supporting proper processes, which are highly relevant for the machine operator but have nothing to do with safety. It is conceivable to integrate an automation unit into the condition and execution monitoring of the diagnostic unit, as reliable automation functions can also offer added value, even if this results in a level of safety that might be too high in this instance.

[0061] The at least one sensor is preferably an optoelectronic sensor, in particular a light barrier, light switch, light grid, laser scanner, FMCW LiDAR, or camera; an ultrasonic sensor, inertial sensor, capacitive sensor, magnetic sensor, inductive sensor, UWB sensor; or a process variable sensor, in particular a temperature, flow, level, or pressure sensor, wherein the safety device preferably comprises a plurality of identical or different sensors. These are some examples of sensors that can provide sensor data relevant to a safety application. The specific selection of the sensor or sensors depends on the respective safety application. The sensors themselves may already be designed as safety sensors.

[0062] However, the invention expressly provides an alternative approach of achieving safety downstream through testing, additional sensors, (diverse) redundancy, multi-channel capabilities, and the like, as well as combining safe and non-safe sensors of the same or different sensor principles. For example, a failed sensor would not provide any sensor data; this would be reflected in the status and execution messages of the safety function unit responsible for the sensor and thus detected by the diagnostic unit during status and execution monitoring.

[0063] The method according to the invention can be further developed in a similar manner and exhibits similar advantages. Such advantageous features are described by way of example, but not exhaustively, in the dependent claims following the independent claims.

[0064] The object of the invention is further achieved by a safety method for monitoring at least one machine, in which at least one sensor generates sensor data for the machine and a processing unit, at least indirectly connected to the sensor and the machine, runs at least one logic unit on a computing node as an execution environment for the sensor data, wherein at least one logic unit or at least one safety function unit evaluates the sensor data in a safety-oriented manner in order to output a safety signal to the machine to trigger a safety response in the event of a safety-relevant event, wherein logic units are generated, modified, and / or resolved based on a safety task; wherein compliance with safety coding guidelines is ensured, and / or safety-relevant information is determined, and / or interfaces are provided for each safety function unit;where monitoring devices are dynamically created, added, or removed; and where resources for safety-related tasks are validated.

[0065] Furthermore, a computer-readable storage medium can be provided which contains instructions which, when executed by a computer, cause it to perform the security procedure described herein.

[0066] An arrangement incorporating the safety device and the machine can also be provided.

[0067] Further advantageous embodiments of the methods according to the invention will become apparent from the dependent claims, the drawing and the description.

[0068] The invention is described below with reference to exemplary embodiments and the drawings. The drawings show, in schematic representations: Fig. 1 is an overview of a safety device; Fig. 2 is a schematic representation of an implementation environment of the safety device; Fig. 3 is a schematic representation of an implementation environment in an embodiment with a computing node; Fig. 4 is a schematic representation of a similar implementation environment. Figure 3 now with two compute nodes to create redundancy and diversity; Fig. 5 a schematic representation of an execution environment similar to Figure 3 with an additional automation unit; Fig. 6 a schematic representation of an execution environment similar to Figure 3in a specific embodiment using Kubernetes; Fig. 7 an illustration of secure Kubernetes according to one embodiment; Fig. 8 an illustration of secure Kubernetes according to one embodiment; Fig. 9 an illustration of a software architecture according to one embodiment; Fig. 10 an illustration of the interaction between the primary application and the sidecar according to one embodiment; and Fig. 11 an illustration of a hardware and software architecture according to one embodiment.

[0069] The safety devices and safety methods according to the invention are explained below using exemplary embodiments.

[0070] Figure 1Figure 10 shows an overview of a safety device. The terms safety, as well as safe and not safe, are to be understood as meaning that corresponding components, transmission paths and evaluations meet or do not meet the aforementioned criteria of safety standards.

[0071] The safety device 10 can be roughly divided into three blocks: one machine 12 to be monitored, one sensor 14 for generating sensor data from the monitored machine 12, and one hardware component 16 with computing and storage resources for the control and evaluation functionality to evaluate the sensor data and trigger any necessary safety-related response from the machine 12. Machine 12, sensor 14, and hardware component 16 are sometimes referred to in the singular and sometimes in the plural below, which is expressly intended to include the other embodiments with only one unit 12, 14, 16 or with several such units 12, 14, 16.

[0072] Examples of the three blocks are shown at the edges. The machine 12, preferably used in industry, is, for example, a processing machine, a production line, a sorting system, a process plant, a robot, or a vehicle that may or may not be rail-bound and, in particular, is driverless (AGC, Automated Guided Cart, AGV, Automated Guided Vehicle, AMR, Autonomous Mobile Robot).

[0073] Examples of optoelectronic sensors 14 include a laser scanner, a light grid, and a stereo camera. Other types of sensors include photoelectric sensors, light barriers, FMVW LiDAR, and cameras with any 2D or 3D detection capabilities, such as projection or time-of-flight methods. Further examples of sensors 14 (though not exhaustive) include UWB sensors, ultrasonic sensors, inertial sensors, capacitive, magnetic, or inductive sensors, and process sensors such as temperature, flow, level, or pressure sensors. These sensors 14 can be present in any number and combined in any way, depending on the safety device 10.

[0074] Possible hardware components 16 are controllers (PLC, Programmable Logic Controller or SPS, programmable logic controller), a computer in a local network, in particular an edge device or a cloud, and in general any hardware that provides resources for digital data processing.

[0075] Inside the Figure 1The three blocks are revisited here. The machine 12 is preferably connected to the safety device 10 via its machine control 18, where the machine control is a robot controller in the case of a robot, a vehicle controller in the case of a vehicle, a process controller in a process plant, and similarly for other machines 12. The sensors 14, grouped internally as block 20, not only generate sensor data but also have an interface (not shown individually) for outputting the sensor data in raw or (pre-)processed form, and generally their own control and evaluation unit, i.e., a separate hardware component for digital data processing.

[0076] An execution environment 22 is a collective term for a processing unit that, among other things, processes sensor data to generate control commands for the machine 12 or other safety-relevant and additional information. The execution environment 22 is implemented on the hardware components 16 and is described below with reference to the Figures 2 to 6This is explained in more detail below. According to the invention, it is not specified on which hardware the execution environment 22 is run. The above list of possible hardware components provides some examples that can be combined arbitrarily. Furthermore, the execution environment 22 is intentionally shown overlapping with the machine control 18 and the block 20 of the sensors 14, since internal computing and storage resources of the sensors 14 and / or the machine 12 can also be used by the execution environment 22, again in any combination, including the possibility that there are no additional hardware components 16 outside of the machine 12 and the sensors 14. In the following, it is assumed that the hardware components 16 provide the computing and storage resources; this implies the inclusion of internal hardware of the machine 12 and / or sensors 14.

[0077] The safety device 10, and in particular the execution environment 22, now provides safety functions and preferably also diagnostic functions. Later, with reference to… Figure 5 In contrast to safety functions, which are also referred to as safe automation functions, additional non-safe automation functions are introduced as a further option. Such a safety function receives the stream of temporally successive measurement and event information along with the sensor data and generates corresponding control signals and preferably also diagnostic or overview information.

[0078] The safety device 10 achieves high availability and robustness against unforeseen internal and external events by providing safety functions as a service of the hardware components 16. The flexible configuration of the hardware components 16, and preferably their networking in a local or non-local network or in a cloud, enables redundancy and performance elasticity, allowing for robust handling of interruptions, malfunctions, and peak loads. The safety device 10 detects when errors can no longer be caught and thus become safety-relevant, and then initiates a situation-appropriate response to bring the machine 12 into a safe state if necessary. This might involve, for example, stopping, slowing down, swerving, or operating the machine 12 in a safe mode.It should be clarified once again that there are two classes of events that trigger a safety-related response: firstly, an event classified as dangerous, resulting from the sensor data, and secondly, the detection of a safety-relevant fault.

[0079] Figure 2Figure 1 shows a schematic representation of the execution environment 22. The task of the execution environment 22 is ultimately to derive a control command from sensor data, in particular a safety signal that triggers a safety-related response from the machine 12. The execution environment 22 comprises a master 24 and at least one compute node 26. The necessary computing and storage capacity for the master 24 and the compute node 26 is provided by the hardware components 16. The execution environment 22 can transparently extend across a multitude of hardware components 16. A compute node 26 is to be understood as abstract or virtual; there is not necessarily a one-to-one relationship between a compute node 26 and a hardware component 16. Rather, a hardware component 16 can provide multiple compute nodes 26, or conversely, a compute node 26 can be distributed across multiple hardware components 16. This distribution applies analogously to the master 24.

[0080] A computing node 26 has one or more logic units 28. A logic unit 28 is a self-contained functional unit that receives information, combines, transforms, restructures, or generally processes it into new information and then makes it available to potential recipients for visualization, control commands, or further processing, in particular to other logic units 28 or a machine controller 12. For the purposes of this description, three main types of logic units 28 are to be distinguished, namely those relating to the Figure 3 introduced safety functional units and diagnostic units, as well as those relating to the Figure 5 introduced automation units.

[0081] The execution environment 22 activates the required logic units 28 and ensures their orderly operation. To this end, it allocates the necessary resources on the available compute nodes 26 or hardware components 26 to the respective logic units 28 and monitors the activity and resource requirements of all logic units 28. Preferably, the execution environment 22 detects when a logic unit 28 is no longer active or when interruptions to the execution environment 22 or the logic unit 28 have occurred. It then attempts to reactivate the logic unit 28 and, if this is not possible, creates a new copy of the logic unit 28 to maintain orderly operation.

[0082] Interruptions can be both foreseen and unforeseen. Examples of causes include infrastructure errors, such as those in the hardware components 16, their operating systems, or network connections; accidental misuse or manipulation; or the complete exhaustion of a hardware component's resources. If a logic unit 28 cannot process all required information, particularly safety-relevant information, or at least not quickly enough, the execution environment 22 can create additional copies of the affected logic unit 28 to ensure the continued processing of the information. In this way, the execution environment 22 ensures that the logic unit 28 performs its function with the expected quality and availability.

[0083] Figure 3Figure 1 shows a further, advantageously differentiated embodiment of the execution environment 22 of the safety device 10. The master 24 forms the management and communication center. It stores configuration information or a configuration file about the existing logic units 28, so that the master 24 has the necessary knowledge about the configuration, in particular which logic units 28 exist and are intended to exist, on which computing nodes 26 they are located, and the time sequence in which they receive resources and are called. The configuration file is preferably secured against intentional and unintentional manipulation by means of signatures, for example, using blockchain technologies. Here, safety technology advantageously coincides with data integrity (cybersecurity), because in this way attacks that could have unforeseeable consequences are prevented or at least detected.

[0084] The compute nodes 26 advantageously have their own substructure, whereby the units described below may only be partially present. First, compute nodes 26 can be further subdivided into subnodes 30. Logic units 28 are preferably created within the subnodes 30, not at the level of the compute nodes 26. Preferably, the logic units 28 are virtualized, i.e., containerized, within containers. Each subnode 30 thus has one or more containers, each preferably containing one logic unit 28. In the example of the Figure 3 There are two logic units 28, namely a safety function unit 32 and a diagnostic unit 34, each in its own container and also subnode 30. Alternatively, it would also be conceivable to assign the safety function unit 32 and diagnostic unit 34 to the same subnode 30.

[0085] A node manager unit 36 ​​of the compute node 26 coordinates its subnodes 30 and the logic units 28 assigned to this compute node 26. The node manager unit 36 ​​also communicates with the master 24 and other compute nodes 26. The management tasks of the execution environment 22 can be distributed between the master 24 and the node manager unit 36 ​​in virtually any way possible; the master can thus be considered to be implemented in a distributed manner. However, it is advantageous if the master handles the global tasks of the execution environment 22 and each node manager unit 36 ​​handles the local tasks of its respective compute node 26. Nevertheless, the master 24 can preferably be distributed across several hardware components 16 or be configured redundantly to increase its fault tolerance.

[0086] A safety functional unit 32 (which can also be referred to as a "safety functional unit") is an example of a special logic unit 28 for evaluating sensor data for a safety task with functional safety. Typical examples are distance monitoring (especially speed and separation), passage monitoring,

[0087] Protective field monitoring or collision avoidance with the aim of an appropriate safety-oriented response by the machine 12 in the event of danger. This is the core task of safety technology, whereby, depending on the sensor 14 and evaluation method, a wide variety of ways are conceivable to distinguish between a normal and a hazardous situation. For each safety application or group of safety applications, suitable safety function units 32 can be programmed or selected from a pool of existing safety function units 32.

[0088] A diagnostic unit 34 (which can also be referred to as a "diagnostic unit") is another example of a special logic unit 28 and is also safety-relevant. The diagnostic unit 34 can monitor one or more safety function units by performing diagnostic measures such as PSM (process safety management) or condition monitoring. The diagnostic unit 34 can be simple, for example as a watchdog, or perform tests and diagnoses of varying complexity. As a logic unit 28, it runs in the same execution environment 22 and is operated according to the same basic principles as a safety function unit 32. It is capable of at least partially replacing or supplementing the safe algorithms and self-monitoring measures of a safety function unit 32. To do this, the diagnostic unit 34 monitors and analyzes the activities of the safety function unit 32 for correctness, i.e.,The execution environment 22 checks whether the safety function unit 32 is performing its assigned activities in the specified sequence and within the given time frame. The execution environment 22 therefore only checks whether the safety function unit 32 is still active at all, while the diagnostic unit 34 specifically checks whether the sequences, time windows, times, and content of the activities are correct, thus detecting errors in the safety function unit 32. For this purpose, the diagnostic unit 34 has expectations regarding the output of the safety function unit 32 at specific times, either during its regular operation or in response to specific artificial sensor information fed in as a test.

[0089] By using the execution environment 22, it becomes possible to distribute safety-relevant logic units 28 virtually arbitrarily across even highly heterogeneous environments of hardware components 26, including edge networks or cloud environments. The execution environment 22 creates, terminates, or moves the required logic units 28 between compute nodes 26 and subnodes 30.

[0090] Figure 4 shows a further embodiment of the implementation environment 22 of the safety device 10. In addition to the embodiment according to Figure 3Copies of safety function unit 32 and diagnostic unit 34 are created here. In this example, an additional compute node 26 is also present, but this is not strictly necessary, as further logic units could also be created in the same compute node 26 or even subnode 30. The additional logic units 28 are not intended for additional functionality, although that would also be conceivable, but rather to create redundancies. A diagnostic unit 34 can be assigned to a safety function unit 32 of the same or a different compute node 26, as well as to the same or a different subnode 30. Furthermore, a diagnostic unit 34 can alternatively monitor a safety function unit 32 one-to-one, or a diagnostic unit 34 can be responsible for several safety function units 32, or conversely, several diagnostic units 34 can be responsible for the same safety function unit 32.Furthermore, multiple diagnostic units 34 can preferentially compare their diagnoses with each other.

[0091] The invention thus enables not only adaptation to a heterogeneous environment with virtually any hardware components 16, but also scaling of the safety level (e.g., Performance Class PC according to IEC / TS 62998, Performance Level according to ISO 13849, or Safety Integrity Level SIL according to IEC 61508). This is achieved through three adjustable parameters: the frequency of diagnostics, i.e., the test cycles with which a diagnostic unit 34 monitors a safety function unit 32; the redundancy multiplicity, i.e., how many copies of a safety function unit 32 and / or diagnostic unit 34 are active; and the diversity, i.e., how many computing nodes 26 or subnodes 30 the safety function units 32 and diagnostic units 34 are distributed across.

[0092] This would allow, for example, the following gradation of the security level to be achieved: Low security level: a security function unit 32 and a diagnostic unit 34 are each instantiated only once and run on the same hardware component 16, in particular a single computer, and the diagnostic unit 34 checks the processing results of the security function unit 32 only in every nth sensor cycle, in which the sensors 14 provide sensor data or this data is processed. The execution environment 22 executes the security function unit 32 n times and only then the diagnostic unit 34 once. This procedure is similar to a so-called pre-demand test.

[0093] Medium security level: there is still only one copy each of the safety function unit 32 and diagnostic unit 34. However, the frequency of the diagnosis is increased, up to a check of every sensor cycle, where the execution environment then calls the diagnostic unit 34 each time after the safety function unit 32.

[0094] High level of security: The execution environment 22 now generates two instances each of the safety function unit 32 and the diagnostic unit 34, which are assigned to different subnodes 30 or, even better, compute nodes 26 and preferably also to hardware components 16. This results in double redundancy and thus a dual-channel system, as well as potential diversity. The diagnostic units 34 have short test cycles, preferably the same cycle as the safety function units 32. It is conceivable to perform cross-testing or to repeatedly insert tests in which one diagnostic unit 34 monitors another copy of the safety function unit 32, or to compare the diagnoses of the diagnostic units 34 with each other.

[0095] Very high security level: Now, even more than two copies of the safety function unit 32 and / or the diagnostic unit 34 are generated. Depending on the specific configuration, this results in at least a three-channel system or, more generally, k-fold redundancy or diverse redundancy. Otherwise, the statements regarding the high security level also apply here.

[0096] The relevant requirements are communicated or recorded in the configuration file. This can be done externally to manually set a specific safety level or to request a specific safety level. Situational adjustment of the safety level is particularly advantageous. In this case, the safety device 10 determines, particularly by means of a suitable safety function unit 32, how the current hazard situation should be assessed based on the sensor data and, if applicable, further information, especially from the machine control 18, for example, regarding an upcoming work step. This situational or context-related risk assessment is referred to as "Behavior Driven Risk Assessment." There may be specific events that influence an appropriate safety level, such as the specific requirement of a safety function, the completion of a job, or a maintenance request.Through the described adjustments, the execution environment can then dynamically set the new security level and, if necessary, create, terminate, or move logic units 28 between compute nodes 26 or subnodes 30. Optimization based on boundary conditions, such as increased process or manufacturing efficiency, is also conceivable.

[0097] The latter applies in particular if the execution environment is not solely responsible for safety, but also uses the sensors 14 for non-safety-related automation tasks. A corresponding embodiment of the execution environment 22 is shown in the Figure 5 . There, another logic unit 28 is added, namely an automation unit 38. One or more automation units 38 can be combined with any number of components, in particular the Figures 3 and 4 The described embodiments can be combined, which Figure 5shows only a simple example with one computing node 26, one safety function unit 32, one diagnostic unit 34 and one automation unit 38.

[0098] An automation unit 38 is a logic unit 28 that monitors sensors 14 and machines 12 or parts thereof, generally actuators, and that controls (partial) processes or provides information about them based on this information. An automation unit 38 is treated by the execution environment in principle like any logic unit 28, and is therefore preferably also containerized. Examples of automation tasks include quality control, variant control, object recognition for gripping, sorting, or other processing steps, classifications, and the like. The distinction from the safety-related logic units 28 lies in the fact that an automation unit 38 does not contribute to accident prevention, i.e., the safety-related application. Accordingly, it also does not require a diagnostic unit 34.Reliable operation and a certain degree of monitoring by the execution environment 22 are still desirable, but this serves to increase availability and thus productivity and quality, not security.

[0099] The architecture of the execution environment 22 allows for a seamless integration of safety and automation, as safety-related logic units 32 and 34 and automation units 38 can be executed in the same environment and practically simultaneously, and treated similarly. In the event of a conflict, the execution environment 22 prioritizes the safety-related logic units 32 and 34, for example, in the case of scarce resources. Execution rules for the coexistence of safety-related logic units 32 and 34 and automation units 38 can be defined in the configuration file.

[0100] Figure 6Figure 1 shows a schematic representation of an execution environment 22 in an embodiment using Kubernetes. The execution environment 22 is referred to here as the control plane. Figure 6 is attached to Figure 3 based on, the further ones with reference to the Figures 3 to 5 The described implementations can be implemented analogously in Kubernetes. In Kubernetes, the master has a substructure. The (Kubernetes) master is still not responsible for executing containers or logic units itself, but rather handles the general processes or orchestration (orchestration layer). Accordingly, the configuration file is called the orchestration file. Furthermore, there is an etcd database for all relevant data of the Kubernetes environment, an API server as an interface to Kubernetes, and a scheduler and controller manager that performs the actual orchestration.

[0101] The existing hardware is divided into nodes, which are compute nodes 26. Within each node, there is one or more so-called pods as subnodes 30, and within these pods are the containers holding the actual microservices, in this case, the logic units 28 along with their associated container runtime, including all libraries and dependencies required for the logic unit 28 at runtime. Local management is handled by a now two-part node manager unit 36, consisting of a kubelet 36a and a proxy 36b. Kubelet 36a is an agent that manages the node's own pods and containers. Proxy 36b, in turn, contains the network rules for communication between nodes and with the master.

[0102] Kubernetes is a preferred, but by no means the only, implementation option for the execution environment 22. Docker Swarm could be mentioned as another alternative among several. Docker itself is not a direct alternative, but rather a tool for creating containers and thus can be combined with both Kubernetes and Docker Swarm, which then orchestrate the containers.

[0103] Various implementations provide a dynamic configuration (dynamic config) of secure Kubernetes.

[0104] Figure 7 Figure 700 shows a secure Kubernetes implementation according to one embodiment. An execution environment 702 runs a logic unit 704 (in other words, executes a logic unit 704). The logic unit 704 can have different characteristics (for example, an automation unit 706, a security unit 708, or a diagnostic unit 710).

[0105] Figure 8Figure 800 shows a secure Kubernetes implementation according to one embodiment. In an execution environment 802, a diagnostic unit 804 is provided. The diagnostic unit can monitor an automation unit 808, a security unit 810, and another automation unit 812. A request can be passed to the execution environment from an external source 806, such as a user. The automation unit 808, the security unit 810, and the other automation unit 812 provide a service, such as controlling an external device 814, for example, a robot.

[0106] According to various embodiments, devices and methods are provided to make security an integral part of the runtime environment by extending it and introducing a method for the automatic dynamic configuration of security applications.

[0107] A Kubernetes operator is a software extension to Kubernetes that simplifies the management and automation of deploying, scaling, and managing complex, stateful applications. An operator is a piece of code that can run inside or outside a Kubernetes cluster and extends the Kubernetes API to create, configure, and manage instances of a specific application or service. Operators use the Kubernetes API to monitor for events, such as the creation of a new resource, and then act on those events.

[0108] Operators can be implemented as a set of custom resource definitions (CRDs) installed in the Kubernetes cluster. These CRDs define the custom resources that the operator can manage. For example, a database operator can define a custom resource for a database cluster that contains information about the number of replicas, the database version, and other configuration options.

[0109] The operator itself can be implemented as a control loop running within a pod in the Kubernetes cluster. This control loop can monitor changes to the custom resources it manages and update the underlying systems accordingly. The operator can also monitor the health of the managed resources and take corrective action as needed. For example, if a pod running a database instance crashes, the operator might be able to automatically replace the pod to ensure the desired number of replicas is maintained.

[0110] Operators offer a higher level of abstraction than traditional Kubernetes manifests. Instead of managing individual pods, services, and configurations, an operator allows you to manage an entire application or service as a single entity. This can simplify the automation of deploying, scaling, and managing complex applications.

[0111] Figure 9 Illustration 900 shows a software architecture according to an embodiment with Kube API Server 902, Client-Watch 904, Informer 906, shared object cache 908, Handler 910, Work Queue 912 and Reconcile logic 914.

[0112] In Kubernetes, dynamic admission control is a feature that allows you to intercept and modify requests to the API server before they are permanently saved. This mechanism enables the enforcement of custom policies and dynamic modifications to resource objects that are created, updated, or deleted within the cluster. Two types of admission webhooks are commonly used for this purpose: validation admission webhooks and mutating admission webhooks. By leveraging dynamic admission control with validation and mutating admission webhooks, you can extend Kubernetes' default behavior and enforce custom policies and changes to the resources managed in your cluster.

[0113] Validating admission webhooks (also known as "logical units for validation") are used to validate and potentially reject requests to the API server. When a request is received by the API server, it is sent to the configured validating admission webhooks before the resource is retained. These webhooks can examine incoming requests and decide whether to allow or reject them based on predefined policies. If a validating webhook rejects a request, the API server returns an error response to the client, and the request is not retained.

[0114] The most common use cases for validation approval webhooks include: Enforcement of naming conventions: It can be ensured that resource names follow specific patterns or conventions. Enforcement of security policies: It can be verified that the request contains the required security annotations or labels. Enforcement of resource limits: Resource requests and limits, such as CPU and memory, can be validated to prevent excessive usage.

[0115] Mutating admission webhooks (also known as "logical units for initialization") can modify incoming requests before they are stored in the cluster. These webhooks receive the request, can modify the resource object, and then return it to the API server. The modified resource is stored in the cluster based on the changed version.

[0116] The most common use cases for mutating regulatory webhooks include: Inserting default values: Certain fields in the resource object can be automatically added or updated to provided default values ​​if they are missing. Enforcing policies: Additional labels, annotations, or other metadata can be added to the resource object based on predefined policies. Data transformation: The incoming request can be transformed to meet specific requirements or standards.

[0117] It's important to note that allow webhooks must be configured and deployed separately from the Kubernetes API server. They are typically implemented as HTTP endpoints that receive requests from the API server. The response from the webhook determines whether the request is allowed, modified, or denied.

[0118] Applications and services often require related functions such as monitoring, logging, configuration, and network services. These peripheral tasks can be implemented as separate components or services. Furthermore, application components can be deployed in a separate process or container to ensure isolation and encapsulation. This pattern can also enable the composition of applications from heterogeneous components and technologies.

[0119] This pattern is called "Sidecar" because it resembles a sidecar attached to a motorcycle. In this pattern, the Sidecar is attached to a parent application and provides supporting functionality for that application. The Sidecar can also have the same lifecycle as the parent application, being created and decommissioned along with it.

[0120] The advantages of using a sidecar pattern include: A sidecar is independent of its primary application in terms of runtime environment and programming language, eliminating the need to develop a separate sidecar for each language. For Safe Kubernetes, this facilitates cross-project use of the safety net within the team. The sidecar can access the same resources as the primary application. For example, a sidecar can monitor system resources used by both the sidecar and the primary application. Due to its proximity to the primary application, there is no significant latency in communication between the primary application and the sidecar. Even for applications that lack an extensibility mechanism, a sidecar can be used to extend functionality by attaching the sidecar as its own process in the same host or subcontainer as the primary application.

[0121] Figure 10 Figure 1000 shows the interaction between the primary application 1002 and the sidecar 1004 according to an embodiment that can, for example, run on a host. The primary application 1002 can provide the core functionality. The sidecar 1004 can provide peripheral applications such as platform abstraction, proxying to remote services, logging, and / or configuration.

[0122] Current solutions and products for safety-related functions are typically monolithic and tightly integrated with their hardware. As a result, these solutions function as a single unit and are difficult to (re)configure. Modularization and configuration are not possible with current tightly coupled security solutions.

[0123] A "safety program" can be understood as a sequence or series of safety units (which in Kubernetes, for example, can be defined as a user-defined resource).

[0124] An "Automated resource orchestrator" (ARO) can be understood as an operator according to the invention.

[0125] A "Domain Scoped Object" (DSO) can be a user-defined resource definition.

[0126] The runtime environment itself does not know any application-specific requirements, but merely offers general functions for provisioning and scaling workloads. However, security applications place strict and specific demands on their operation, scaling, and configuration. Therefore, security must be an integral part of the runtime environment, which is achieved according to the invention by embedding security knowledge into the system and combining one or more of the following four runtime environment functions to introduce dynamic configuration and management of security applications: 1. Domain-Specific Object, DSO (which can be a user-defined resource definition;) 2. Automated Resource Orchestrator, ARO (which can be an operator; ) 3. Logical unit for initialization (which can be a mutating allow webhook) and 4. Logical unit for validation (which can be a validating allow webhook).

[0127] In addition to these components, a sidecar (which can also be called a safety watcher) that interacts with the safety subsystem can be used.

[0128] Figure 11Figure 1100 shows a hardware and software architecture according to one embodiment. An external computer 1104 can be connected to a runtime environment 1102, which is configured to control a machine 1106, for example, an industrial robot. In the runtime environment 1102, an ARO 1108 can access a configuration 1110 and modify (1112) or validate (1114) sidecars 1118, 1120, 1122 (which in turn can access a diagnostic unit 1116). This provides a safety program 1124.

[0129] In general, a runtime environment can also be referred to as an execution environment.

[0130] A typical sidecar (which, for example, is not a native feature but a pattern in Kubernetes) can couple and externalize peripheral tasks, so that the application container does not have to deal with them.

[0131] The Safety Watcher according to the invention can ensure compliance with safety coding guidelines when interacting with the safety subsystem, collect and / or calculate safety-relevant information such as checksums or sequence numbers, and provide strict (e.g., certified) interfaces to the safety subsystem for each safety function in the safety program.

[0132] The Safety Watcher can largely perform the same functionality as a regular sidecar and encapsulate safety-relevant communication with the safety subsystem. Further details can be found in European patent application 22 216 057.4, which is incorporated herein in its entirety by reference for all purposes.

[0133] In one embodiment, the sidecar (and thus safety functions) can be added to or removed from functions during runtime, which would not be possible if the application container interacted directly with the safety subsystem.

[0134] Each safety function unit can have a safety monitor attached. This can be handled by the logic unit for initialization. The decision as to whether a safety monitor is required can be based on the properties of the logic unit (e.g., name or tag).

[0135] The Safety Watcher can monitor the safety function unit to which it is connected. The Safety Watcher can provide clearly defined interfaces that the safety function unit uses. All safety-related monitoring of the safety function unit can be performed through and based on these interfaces.

[0136] Surveillance and other security measures include, among other things: Monitoring of regular event reception, processing, and time windows; adding metadata to each type of message (e.g., hash sum, sequence number, timestamp, etc.); sending status and execution events to the security subsystem; ensuring that the security functional unit is not overwhelmed by the number of received messages by queuing them and forwarding only one message at a time to the logic unit; and adopting the configuration from the Automated Resource Orchestrator (ARO) and updating its behavior at runtime without redeployment or re-creation (i.e., without interruption), thereby achieving secure dynamic configuration changes at runtime; these new configurations can also be applied to the logic unit and monitored based on the new configuration.

[0137] DSO can provide an interface for modeling a complete security task as a single atomic unit, even if it spans more than one container. DSO can define multiple security-related properties or metadata (for example, graph invocations, time windows, hash sums, and / or hardware and software requirements). DSO can model a sequence of security-critical containers (logical units) that may be distributed across multiple (physical) nodes. DSO can be based on Kubernetes' Custom Resource Definition (CRD) concept, which allows extending Kubernetes with domain-specific resources. DSO can be used for similar security properties and configurations. DSO can describe a sequence of one or more pods that collectively perform a security task. DSO can (due to its specification) allow different logical units to be treated as a single entity.

[0138] The safety program is a domain-scoped object (DSO) and is modeled as an atomic unit to perform a protective task, such as preventing a collision between a human and a robot. While a safety program may consist of multiple logic units distributed across multiple physical nodes, it can also contain safety-related configurations.

[0139] The DSO security program extends the runtime environment and enables the runtime environment, together with the operator, to understand a security context and make security an integral part of the runtime environment itself.

[0140] The DSO security program may contain the following security-relevant content: 1. A list of all required safety-related logical units. This list may contain information about the required safety functional units and which diagnostic units the safety program needs. The latter allows only the necessary parts of the safety subsystem to be used and determines its scope within the safety program. and / or 2. Configuration for the safety program. This includes both general configurations and highly application-specific configurations that are unique to each safety program, as well as safety-specific configurations such as minimum response times or time windows. The application-specific configuration could, for example, be a threshold for the permissible distance between a human and a robot, or a more complex configuration.

[0141] The general configuration can contain at least a subset of the following information: 1. Dependencies between safety functional units (e.g., a call graph); 2. A process flow that can be monitored by program flow monitoring (further details can be found in European patent application 22 216 057.4, which is incorporated herein in its entirety by reference for all purposes); 3. Timeouts or time window configuration; 4. Requirements for the runtime environment (e.g., required hardware – two physical nodes with different architectures are required to set up a dual-channel system; if these are not met, the operator refuses to build the program); 5. The security program's requirements for the execution environment.The requirements can be application-specific and may affect both hardware and software requirements of the runtime environment, such as: the version of the runtime environment; the mode or deployment of the runtime environment—for example, air-gapped, with network connectivity, and / or high-availability mode; the hardware of the runtime environment—for example, the availability of dedicated GPU hardware, at least three physical nodes, and compute nodes with different architectures to establish multi-channel communication in the security domain. 6. A list of dependencies on which the security program relies to run properly and securely, but which are not hardware or software requirements, such as messaging infrastructure.

[0142] It is also possible to use more than one DSO. Other DSOs can, for example, influence the security DSO program by defining commands such as restart or pause.

[0143] CRDs can extend Kubernetes functionality (e.g., to define and manage CRDs tailored to specific application requirements). CRDs can provide declarative application configuration. CRDs can provide automation and abstraction, and manage the automation and administration of Kubernetes resources.

[0144] DSOs can provide security-tailored configurations that are managed by the runtime environment and security-specific information such as call graphs, time windows, or hash sums.

[0145] Data Storage Organizations (DSOs) can achieve high security because an expected state can be declared and the actual state can be verified against these security expectations. DSOs can extend the runtime environment's API, and the Advanced Runtime Environment (ARO) can manage them just like any other runtime resource.

[0146] ConfigMap (which is a Kubernetes feature) or external configuration stores (which can be provided by third-party solutions) are not suitable because: 1. Neither the Kubernetes Config Map nor third-party configuration stores allow the runtime environment to be extended with application-specific (security) knowledge. 2. Using an external / third-party configuration store increases complexity and requires additional resources, which are limited in an edge environment. Furthermore, since external stores are not fully managed by Kubernetes, efforts must be made to make them as resilient as the resources managed by Kubernetes. 3. Neither alternative allows security to be an integral part of Kubernetes; they only offer configurations like any other, which are unsuitable because security requires much stricter configurations.

[0147] The ARO can run as a logical unit within the runtime environment, but it can also run outside the execution environment and perform the same task as a standalone binary application. The latter deployment option can be important in cases where operational functionality is required for execution on specialized hardware, such as security-certified hardware that is not part of the runtime environment. It is therefore tightly coupled to and monitors the runtime environment. Any interaction with runtime resources is observed and processed by the ARO. Possible interactions include creating, updating, deleting, and resuming a resource, but these are not the only types of interactions.The question of whether handling an interaction is necessary, or how that handling should be implemented, is application-specific (for example, creating a second instance of a logic unit that compares distance values ​​between a human and a robot against a threshold). Depending on the application, this interaction can be denied or permitted. This can also be combined with arbitrary rules (for example, that the second instance must be scheduled on a different physical node).

[0148] The ARO makes it possible to treat the security program as a single atomic unit, even though it consists of multiple logical units that may be distributed across multiple physical nodes and also contains security-related configurations.

[0149] Therefore, the ARO enables a dynamics in the runtime environment that goes beyond the already existing undynamic capabilities of the runtime environment - especially as explained below.

[0150] Due to the ARO's operational knowledge of security programs, one or more security programs can be scaled, deployed and managed, thus creating one or more security applications in a cluster.

[0151] The ARO can introduce the automatic injection of the Safety Mesh Safety Watcher to enable logic units to interact with the safety subsystem, thus creating the basis for safe execution monitoring. Further details can be found in European patent application 22 216 057.4, which is incorporated herein in its entirety by reference for all purposes.

[0152] The ARO can both create (new) required resources and update existing ones. This applies not only to "software resources" such as logical units or security configurations, but also to physical and virtual compute nodes that are already connected to the runtime environment or that are manually connected. Furthermore, operations (creation, modification, deletion, etc.) on resources can be denied, which not only enables the enforcement of compliance policies but also adds security value, for example, allowing only government-certified hardware or logical units. This can be done by comparing the hash sums of a logical unit's image with its operational knowledge. This is not part of the runtime environment itself and cannot be part of a ready-to-use runtime environment, as it requires detailed knowledge of the application and its operation.

[0153] The Automated Resource Orchestrator (ARO) can be inspired by the Kubernetes operator pattern (i.e., codified operational knowledge for managing an application). The ARO can be used to monitor runtime environment resources. The ARO can focus on operating one or more security applications (i.e., security program DSOs), thus providing codified operational knowledge and therefore more than just creating, deleting, and updating DSOs, enabling dynamic configuration of logical units according to security requirements.

[0154] The ARO can deal with aspects of creating, deleting, and updating specific user-defined resources, but can also include other Kubernetes resources as well as operational knowledge codified by the operator's developer.

[0155] The ARO focuses on dynamically updating (security) configurations of logical units during runtime based on security requirements. The ARO can monitor runtime environment resources (not just the DSO). The ARO can run as a container within the runtime environment or outside the runtime environment as a container or standalone binary application.

[0156] A normal operator (which is not a native Kubernetes feature but a pattern) can manage complex, stateful applications in a Kubernetes cluster (which can be described as "coded operational knowledge"). The normal operator can typically be deployed as a container that runs within the cluster and uses the same hardware as the application containers. An operator manages an application (for example, a database operator provisions and manages a database).

[0157] Security involves strict and complex rules that must be checked and controlled both at runtime and during initialization, maintenance, or shutdown phases. Furthermore, the same stringent rules apply to scalable security applications. The ARO therefore not only manages and / or scales one or more security programs, but also enforces and fulfills security requirements. The ARO can also run as a container within the cluster and share the same hardware with the application containers. In addition, the ARO is also designed to run outside the runtime environment as a binary application (or as a container). Running it outside the runtime environment offers the following advantages: decoupling the development and operation of the operator from diagnostics (further details can be found in European Patent Application 22 216 057).4, which is incorporated herein in its entirety by reference for all purposes); and the possibility of deploying the operator externally on special security hardware. The development of the operator can also be decoupled when deployed within the cluster, since the diagnostic units (as shown, for example, in European patent application 22 216 057.4) and the operator can be different software artifacts in different containers.

[0158] One or more security programs can be run simultaneously, taking into account normative or regulatory security rules (e.g., only certified containers run in the cluster). To manage and isolate multiple security programs, a separate namespace can also be created for each one.

[0159] The logical unit for initialization (LU-I) can modify any incoming request before the action is executed. Specifically, the LU-I is used to: Standardize resource names (especially configuration names); integrate a security observer into a security functional unit. The decision to integrate a security observer into the security functional unit can be part of the operational configuration. Add resource constraints to containers. Each container has its own share of CPU and memory. These constraints are added by the LU-I, also taking into account the requirements of the security program. Add a simple default configuration if one is missing, e.g., protocol level.

[0160] The LU-I can be executed as a separate logical unit or as part of the ARO. Like the ARO, the logical unit can be executed for initialization inside or outside the runtime environment when executed as a separate logical unit.

[0161] Mutating allow webhooks can automatically modify or improve incoming resource configurations before they are admitted to the cluster.

[0162] The LU-I allows the Safety Watcher to be dynamically added to or removed from other containers when they are created, updated, or deleted. This also makes it possible to switch / apply different Safety Watchers based on any (security) criteria.

[0163] Alternatively, there are other ways to achieve the same result (e.g., manually adding the Safety Watcher to the application container deployment).

[0164] The logical unit for validation (LU-V) is executed after LU-I and is the final step before the resource is created in the runtime environment. It verifies the conformity of the resource being created or modified. This might involve, for example, checking whether the container image of a security functional unit has an expected hash sum that matches the hash sum of a version of the image certified by a notified body.

[0165] The validation logical unit (LU-V) can run as a separate logical unit or as part of the ARO. Like the ARO, the initialization logical unit can run inside or outside the runtime environment when run as a separate logical unit. Validation allow webhooks can enforce policies and validate resource configurations before they are deployed to the cluster. Validation allow webhooks ensure that resources comply with predefined rules and restrictions, thus helping to maintain consistency and security within the cluster. If the webhook fails to return a positive response, the resource is not deployed to Kubernetes.

[0166] The Logical Unit for Validation (LU-V) can validate deployments for security compliance before they are deployed to the runtime environment. Its primary purpose is to verify that the security program configuration matches the intended structure—for example, a single root node, no circular references, compliant / certified container images, etc.

[0167] In one embodiment, a resource interaction is first performed (for example, manually or by the ARO; for example, to create, delete, or modify resources). Then, if a change is requested (which can be done, for example, by LU-I, and which can include standardizing and inserting a sidecar and / or adding resource constraints and default settings), a validation is performed (which can be done by LU-V, and which can include validating the resource, for example, by checking versions and / or hash sums), before the change is propagated to the runtime environment.

[0168] According to various implementations, a dynamic configuration of existing security solutions can be provided at runtime.

[0169] According to various implementations, security knowledge can be directly embedded in the runtime environment, and it may still be possible to use the runtime environment as a normal runtime environment for non-security-related workloads. This can enable a fusion of security and automation.

[0170] The security programs DSO and ARO contain the application-specific knowledge.

[0171] In one embodiment, ARO can be used as part of a runtime risk assessment to enable elastic safety measures within the runtime environment. Reference symbol list

[0172] 10 Safety device 12 Machine 14 Sensor 16 Hardware component 18 Machine controller 20 Block of aggregated sensors 22 Execution environment 24 Master 26 Compute node 28 Logic unit 30 Subnode 32 Safety function unit 34 Diagnostic unit 36 ​​Node manager unit 38 Automation unit 40 Database 42 API server 44 Controller manager 700 Illustration of secure Kubernetes according to one embodiment 702 Execution environment 704 Logic unit 706 Automation unit 708 Safety unit 710 Diagnostic unit 800 Illustration of secure Kubernetes according to one embodiment 802 Execution environment 804 Diagnostic unit 806 External source 808 Automation unit 810 Safety unit 812 Automation unit 814 External device 900 Illustration of a software architecture according to one embodiment 902 Cube API Server 904 Client Watch 906 Informer 908 Object Cache 910 Handler 912 Work Queue 914 Reconcile Logic 1000 Illustration of the interaction between primary application and sidecar according to1002 Primary Application 1004 Sidecar 1100 Illustration of a hardware and software architecture according to an embodiment 1102 Runtime Environment 1104 External Computer 1106 Machine 1108 ARO 1100 Configuration 1112 Modify 1114 Validate 1116 Diagnostic Unit 1118 Sidecar 1120 Sidecar 1122 Sidecar 1124 Security Program

Claims

1. A safety device (10) for monitoring at least one machine (12), said safety device (10) having at least one sensor (14) for generating sensor data on the machine (12) and a processing unit for the sensor data that is connected at least indirectly to the sensor (14) and to the machine (12), that is configured as a performance environment (22) having at least one computing node (26), and that is configured to allow at least one logic unit (28) to run on the computing node (26), wherein at least one logic unit (28) comprises at least one safety function unit (32) for a safety-directed evaluation of the sensor data in order, in the case of a safety-related event, to output a safety signal to the machine (12) for triggering a safety response, wherein the processing unit is furthermore configured to generate, to modify and / or to resolve logic units (28) based on a safety task; wherein the safety device (10) further has a monitoring device configured to ensure compliance with safety coding guidelines and / or to determine safety-related information and / or to provide interfaces for each safety function unit (32); wherein the safety device (10) is furthermore configured to dynamically create, add or remove monitoring devices; and wherein the safety device (10) is furthermore configured to validate resources for safety-related tasks.

2. A safety device (10) according to claim 1, wherein the safety task is user-defined.

3. A safety device (10) according to claim 1, wherein the safety task is determined at the runtime of the safety device (10).

4. A safety device (10) according to any one of the preceding claims, wherein the logic units (28) are generated, modified and / or resolved based on the safety task by an automated resource orchestrator which is provided within the performance environment (22).

5. A safety device (10) according to any one of the claims 1 to 3, wherein the logic units (28) are generated, modified and / or resolved based on the safety task by an automated resource orchestrator which is provided outside the performance environment (22).

6. A safety device (10) according to any one of the preceding claims, further having: an interface for modeling a protection task as an atomic unit.

7. A safety device (10) according to any one of the preceding claims, wherein the performance environment (22) is implemented on at least one sensor (14), on a programmable logic controller, on a machine controller (18), on a computer device in a local network, an edge device and / or in a cloud; and / or wherein the performance environment (22) is configured to integrate and / or to preclude computing nodes (26).

8. A safety device (10) according to any one of the preceding claims, wherein at least one logic unit (28) is configured as an automation unit (38) which generates information relevant for an automation task and / or a control command for the machine (12) from the sensor data, wherein the information and the control command are not relevant to safety.

9. A safety device (10) according to any one of the preceding claims, wherein the at least one sensor (14) is configured as an optoelectronic sensor, in particular a light barrier, a light sensor, a light grid, a laser scanner, an FMCW LIDAR or a camera, as an ultrasound sensor, an inertia sensor, a capacitive sensor, a magnetic sensor, an inductive sensor, a UWB sensor, or as a process parameter sensor, in particular a temperature sensor, a throughflow sensor, a filling level sensor or a pressure sensor, and wherein the safety device (10) in particular has a plurality of the same or different sensors (14).

10. An arrangement having the safety device (10) according to any one of the preceding claims and the machine (12).

11. A safety method (10) for monitoring at least one machine (12) in which at least one sensor (14) generates sensor data on the machine (12) and a processing unit for the sensor data that is connected at least indirectly to the sensor (14) and to the machine (12) allows, as a performance environment (22), at least one logic unit (28) to run on the computing node (26), wherein at least one logic unit (28) comprises at least one safety function unit (32) which evaluates the sensor data in a safety-directed manner in order, in the case of a safety-related event, to output a safety signal to the machine (12) for triggering a safety response, wherein logic units (28) are generated, modified and / or resolved based on a safety task; wherein compliance with safety coding guidelines is ensured and / or safety-related information is determined and / or interfaces are provided for each safety function unit (32); wherein monitoring devices are dynamically created, added, or removed; and wherein resources for safety-related tasks are validated.

12. A computer readable storage medium comprising commands which, on execution by a computer, cause it to carry out the safety method according to claim 11.