Monitoring of at least one machine

Abstract

To provide a safety device and a method for monitoring a machine.SOLUTION: A safety device 10 includes: a sensor 14 for generating sensor data on a machine 12; and a processing unit 16 for the sensor data, the unit being connected indirectly to the sensor and to the machine. The processing unit is configured as a performance environment 22 having a computing node 26. and configured to allow a plurality of logic units 28 to run on the computing node. The logic unit is configured as a safety function unit 32 for safety directed evaluation of the sensor data and the logic unit is configured as a diagnostic unit 34 for monitoring the safety function unit. The safety function unit is configured to transmit a status message 50 and a performance message 52 to the diagnostic unit. The diagnostic unit is configured to recognize a safety related malfunction of the safety device in a status monitoring 46 using a status from the status message and in a performance monitoring 48 using performance progress from the performance message.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a safety device and a method for monitoring at least one machine as set forth in the preambles of claims 1 and 15, respectively. [Background technology]

[0002] Safety technology is concerned with protecting people and avoiding accidents on machinery. This kind of safety device uses one or more sensors to monitor the machine or its surroundings and to switch the machine to a safe state early in case of imminent danger. In a typical conventional safety technology solution, at least one sensor (e.g. using a laser scanner) monitors a protected area that the operator must not enter while the machine is in operation. The sensor triggers an emergency stop of the machine if it detects an unauthorized intrusion into the protected area, such as the operator's legs. Alternative protection concepts, such as the so-called "Speed ​​and Separation Monitoring", evaluate the distance and speed of objects detected in the surroundings and react in case of danger.

[0003] Safety technology requires particular reliability and therefore high safety demands must be met, for example in the EN 13849 standard for the safety of machinery or the EN 61496 standard for non-contact protective devices (BWS). Some typical measures for this are reliable electronic evaluation by redundant and diverse electronics and monitoring of various functions (e.g. monitoring of optical components including the front panel for dirt). More generally, well-defined fault suppression measures can be mentioned to avoid or control possible safety-critical faults along the signal chain from the sensor through the evaluation to the triggering of the safety technical reaction.

[0004] Due to the high demands placed on hardware and software in safety technology, monolithic architectures are used above all with specially developed hardware that provides for redundancy and function monitoring by multiple channels and test means. Correspondingly, the proof of correct algorithms is carried out according to IEC TS 62998 or IEC-61508-3, for example, and the software development process is subjected to continuous rigorous testing and inspection. An example of this is the safety laser scanner, which was first known from, for example, US Pat. No. 5,399,413 and is widely used to this day in its fundamental features. In this scanner, the entire evaluation function is integrated, including the light flight time measurement for distance measurement and the object detection in the set protection zone. As a result, an evaluated binary protection signal appears at the dual-channel output of the laser scanner (OSSD, Output Signal Switching Device), which stops the machine in case of an intrusion into the protection zone. This concept has proven effective, but remains inflexible, since changes are practically only possible by new developments of successor models of the laser scanner.

[0005] In some conventional safety applications, at least part of the evaluation is transferred from the sensor to an external programmable control device (SPS: Speicherprogrammierbare Steuerung). However, this requires special safety control devices, which themselves have a multi-channel structure etc., for the avoidance and exposure of errors. They are therefore expensive and offer only relatively low storage and computing power, which is completely overloaded, for example, with 3D image processing.

[0006] Although the use of standard controllers is indeed fundamentally conceivable for embedding essential function monitoring devices, this is rarely used today in industrial environments, since it requires costly architectures and expertise. Standard controllers or SPSs can then only be programmed using specific languages, partly in a very limited language space. Even relatively simple function blocks already require significant development costs and runtime resources, so that their implementation in standard controllers is hardly feasible for more complex applications, especially with safety measures such as redundancy.

[0007] Patent document 2 combines a safety controller with a standard controller in a safety system. The more costly calculations are still left to the standard controller, whose results are validated by the safety controller. However, the safety controller uses existing safety data of safe sensors for this purpose, which limits possible application scenarios and still requires expertise to obtain the appropriate safety data and to use it for proper validation. In addition, the hardware configuration is still largely predetermined and the application is specifically and fixedly implemented for it.

[0008] In many cases, it would be desirable to combine safety monitoring with automation tasks, so that not only are accidents avoided, but the primary tasks of the machine are automatically supported as well. However, up to now, completely different systems and sensors have often been used for this purpose. This is especially because safety sensors are too expensive for automation tasks, and conversely, their complexity should not be overwhelmed by other functions. Patent document 3 allows a 3D camera to define the safety and automation areas separately. However, this is only a first step, because although indeed the same sensors are used anyway for the two worlds of safety and automation, these two tasks are still clearly separated spatially and in terms of implementation. Although IEC 62998 allows the coexistence of safety data and automation data, as a standard it never proposes a concrete implementation.

[0009] Outside safety technology there have long been many more flexible architectures. Monolithic approaches have long been many steps behind more modern concepts there. The old traditional deployment, using fixed hardware on top of which an operating system coordinates the individual applications, certainly still holds validity for stand-alone devices, but in the networked world it has long been no longer sufficient. The basic idea in the further development has been to insert additional layers that abstract more and more from the concrete hardware.

[0010] The first step is the so-called Virtual Machine, where an additional layer is called a Hypervisor or Virtual Machine Monitor. On the other hand, such an approach is also being pursued, albeit timidly, in safety technology. For example, in Patent Document 4, a protected environment is provided for a safety sensor, allowing the user to run his own program modules on the safety sensor. However, such program modules are carefully separated from the safety function and do not contribute to it in any way.

[0011] A further abstraction is based on so-called containers (Containervirtualisierung, Containering). A container is like a small virtual capsule for a software application, which provides a complete environment for the application's execution, including memory space, libraries, etc. The associated abstraction layer or runtime environment is called the container runtime. It allows hardware-independent development of software applications for almost any hardware that will later be run on it. Containers are often implemented with Docker.

[0012] Modern IoT architectures (Internet of Things, Industrial Internet of Things) combine many containers with different software applications. These containers must be properly coordinated, which is called orchestration in this context, and for this a so-called orchestration layer is added as a further abstraction. For container orchestration Kubernetes is becoming increasingly established, but other known alternatives include the Docker extension Docker Swarm, rkt or LXC.

[0013] The use of such modern abstract architectures in safety technology has so far failed due to the high bar of safety standards and the correspondingly conservative approach in functional safety applications. Container technology is generally being pursued well in industrial environments, for example the automotive industry has plans to use Kubernetes architectures, and the Air Force is also pursuing such an approach, but none of this is relevant for functional safety and therefore does not solve the problems listed above.

[0014] Although high availability is certainly desirable in the ordinary IoT world, this form of fault tolerance has long since become incomparable to what safety standards require. Therefore, for safety engineers, standard-compliant safety edge or cloud applications have been unthinkable up until now. Creating reproducible conditions and preparing for all possible possible functional errors under these conditions goes against the widely accepted idea. Any significant abstraction or virtualization creates additional uncertainties that were previously considered incompatible with safety requirements.

[0015] Patent document 5 presents a safety device and a security method for monitoring a machine, in which the above-mentioned container and orchestration technologies can be used to abstract safety functions from the underlying hardware. Logical units are created, deleted or assigned to other hardware as needed. This allows for flexible changes in redundancy and mutual monitoring of logical units. For testing and monitoring, a special logical unit configured as a diagnostic unit is proposed. However, Patent document 5 does not explain how the concept of a diagnostic unit can be used to actually successfully expose safety-related errors occurring in the entire system. [Prior art documents] [Patent documents]

[0016] [Patent Document 1] DE 43 40 756 A1 [Patent Document 2] EP 3 709 106 A1 [Patent Document 3] EP 2 053 538 B1 [Patent Document 4] EP 3 179 278 B1 [Patent Document 5] EP 4 040 034 A1 Summary of the Invention [Problem to be solved by the invention]

[0017] The object of the present invention is therefore to further improve the flexible safety concept just described for practical implementation. [Means for solving the problem]

[0018] This problem is solved by a safety device and a method for monitoring at least one machine as claimed in claims 1 and 15, respectively. The machine to be monitored or protected is to be understood broadly at first, for example processing machines, assembly lines, sorting plants, process plants, robots or numerous variants of vehicles (e.g. rail-bound or non-tethered, driven or self-propelled). At least one sensor supplies sensor data for the machine, i.e. data about the machine itself, data about the other with which the machine interacts or data about the machine's surroundings. At least part of the sensor data is safety-related, but additional sensor data for safety-unrelated automation or comfort functions are also conceivable. The sensor may be a safety sensor, but this is not essential, as safety can only be guaranteed at a later stage.

[0019] The processing unit functions as the execution 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 sensors and the machine. It can therefore access and process sensor data, possibly indirectly through other inter-connected units, as well as communicate with and act on the machine, preferably through the machine control device of the machine. The processing unit or execution environment as a collective concept refers to the hardware and software used to determine the requirements and preferably the type of machine reaction towards safety based on the sensor data.

[0020] A processing unit includes at least one computational node, which is a digital computing device or hardware node, or a portion thereof, that provides the computing power and storage capacity for executing the software functional blocks, although not all computational nodes need to be separate hardware modules; for example, multiple computational nodes may be implemented on the same device using multiprocessors, or conversely, one computational node may bundle various hardware resources.

[0021] On a single computing node or on one of the computing nodes, several logic units are operated during the operation of the safety device. A logic unit is therefore generally understood to mean a software function block. In the present invention, at least one logic unit is configured as a safety functional unit for evaluating sensor data for safety purposes. The purpose of the safety evaluation is to protect people or avoid accidents by determining on the basis of the sensor data whether a danger is imminent or whether a safety-relevant event has been recognized. This is the case, for example, when a person is detected too close to the machine or in a protection zone. One or several logic units can be involved in the safety evaluation. In the event of a safety-relevant event, a safety reaction is preferably triggered in the machine by outputting a safety signal to the machine, so that the machine is brought into a safe state in which the danger is eliminated or at least reduced to an acceptable level. Furthermore, at least one logic unit is configured as a diagnostic unit, whereby the function of the other logic units, in particular the function of the at least one safety functional unit, is monitored for errors.

[0022] The basic idea from which the invention starts is to carry out a state and execution monitoring of the logic unit by means of a diagnostic unit. For this purpose, the at least one safety functional unit sends status and execution messages to the diagnostic unit, which are evaluated in the diagnostic unit. The state or status of the at least one safety functional unit gives information on the operational readiness of the at least one safety functional unit and on possible constraints or errors in said unit. The execution messages relate to the execution of a safety function or the execution of a service performed by the at least one safety functional unit and provide information on the execution progress of the executed safety function or service. Together, these allow a system diagnosis that allows the recognition of safety-relevant functional errors in the safety device. The diagnostic unit does not need to have special knowledge of how or with what algorithms the safety functional unit works or which evaluation results it outputs, although the two could be used complementary to each other. In the event of an error, the safe functioning of the safety device cannot be guaranteed, which may result in, inter alia, the machine reacting in a manner that ensures safety in the same way as if a danger had been recognized by the safety functional module. Although a single logic module configured as a diagnostic unit is sufficient for system diagnostics, it is conceivable that status monitoring and performance monitoring could each be implemented in their own diagnostic unit, or alternatively, that the functions could be distributed across multiple logic modules.

[0023] The invention has the advantage that it allows for a flexible security architecture that can coordinate or orchestrate safety-relevant applications, especially in an industrial environment (Industrial Internet of Things: IIoT). In so doing, security and automation can be tightly meshed. Standard hardware is sufficient, no expensive dedicated security hardware is required. The invention is largely independent of the concrete hardware landscape, as long as sufficient memory and computational resources are available overall. Moreover, the logic units can be implemented on a variety of hardware and moved between computational nodes, which significantly increases robustness. In an important possible application case, the hardware landscape or a part of it can be a cloud. The invention thus connects the previously estranged worlds of cloud and security technology. Within the framework of cloud-native initiatives, there are existing open source frameworks and tools that also support applications built at scale, but so far they do not offer functional safety.

[0024] The approach according to the invention is fundamentally different from the conventional approach in safety technology. Up to now, a fixed, usually specifically developed hardware structure is given in advance, and software functions are developed for this very hardware structure, fixedly implemented in it and tested. Subsequent changes in the software distribution are out of the question, especially if they are due to changes in the underlying hardware. Such modifications would traditionally require at least a costly retrofit by safety experts and would usually amount to a complete new development. In industry, and even more so in safety technology, the typical conservative approach results in firmware or software updates of sensors and control devices only taking place in long cycles at best, and typically not at all.

[0025] In this document the concepts "safety" or "safe" are used repeatedly. This is to be understood in particular in the sense of the respective safety standards. Thus, for example, safety standards for the avoidance of accidents in machine safety, non-contact protective devices or personal protection are met or, in some other way, the safety level determined by the standard is observed, so that errors are reduced in each case to a safety level specified in the safety standard or similarly. At the beginning, some examples of such safety standards were given, where the safety level is called, for example, a protection class or a performance level. The invention is not limited to the specifics of these safety standards. They may vary in their specific numbering and wording from region to region and over time, but their basic principles for creating safety remain the same. Later, in some embodiments, the concept of safety is somewhat expanded to context-relevant or situation-specific safety.

[0026] The implementation of the execution environment is preferably done in Kubernetes. In Kubernetes, the execution environment is called the "Control Plane". The master coordinates the overall progress, i.e. orchestrates it (orchestration layer). A compute node, called a Node in Kubernetes, has at least one subnode or Pod, inside which each logical unit runs in its own container. Kubernetes already knows the mechanisms that can be used to check if a logical unit is still running. However, this check is never sufficient for the requirements of the safety specification, and is effectively limited to repeatedly receiving vital signs and possibly restarting the container. It also never guarantees when an error has been noticed and re-corrected.

[0027] The execution environment is preferably configured to create, delete, assign to one of the computing nodes or move between the computing nodes. This is preferably done dynamically during operation and not just once, and this also applies completely clearly to the safety-relevant logical units, i.e. the at least one safety function unit and / or the diagnostic unit. This makes the connection between the hardware and the evaluation fluid while maintaining the functional safety. In contrast, up until now, all safety functions are implemented fixedly and unchangeably on dedicated hardware. Changes, to the extent that they are conceivable without retrofitting or new developments, would be considered completely incompatible with the underlying safety concept. This already applies to one-off implementations, and even more so to dynamic changes at runtime. On the contrary, up until now, the greatest effort has always been made to place safety functions in a well-defined and unchanging environment from the very beginning and throughout the entire operation period, at great expense and with numerous complex individual measures.

[0028] The execution environment is preferably configured to change the resources allocated to the logical units, which may assist the logical units in performing faster processing, but may also free up resources for other logical units. Particular ways to provide more resources include moving the logical units to another computing node, or creating further instances or copies of the logical units, the latter preferably being configured for parallelizable execution.

[0029] The execution environment preferably stores and maintains configuration information or data regarding the logical units, and based on the configuration information, it is possible to record or pre-provision which logical units should be executed at what timing and with what resources with respect to the currently existing logical units, and in some cases how the logical units are related to each other.

[0030] It is particularly preferred that the configuration information is protected against modifications by signatures or block chain data sets, such modifications can be intentional or unintentional, but in any case logical data configuration should never be changed unnoticed in a secure application.

[0031] The execution environment preferably comprises at least one master unit that communicates with and coordinates each of the computing nodes, which may comprise multiple subordinate units for redundancy and / or distribution of responsibilities, and may be implemented on its own computing node or on a common computing node with the logical units, with assistance from the node management units of the computing nodes.

[0032] Preferably, said at least one computing node comprises a node management unit for communication with other computing nodes and with the execution environment, said node management unit being responsible for the management and coordination of the associated computing nodes, in particular their logical units, and for cooperation with other computing nodes and with a master unit, said unit being able to also assume the duties of a master unit in an almost arbitrary distribution.

[0033] Preferably, the at least one compute node has at least one subnode, and the logical units are assigned to the subnode. In this way, the compute node itself is structured once more to group multiple logical units into one subnode. This concept is also pursued by Kubernetes in the form of pods.

[0034] Preferably, the at least one logical unit is implemented as a container, whereby the logical unit is encapsulated or containerized and can run on almost any hardware. The usual tight relationship between safety features and their implementation on fixed hardware is broken, which allows for a lot more flexibility and process stability. The execution environment coordinates or orchestrates the containers with each other, including the logical units inside them. There are at least two abstraction layers: the respective container layer (container runtime) and the execution environment orchestration layer above it.

[0035] The execution environment is preferably implemented on at least one sensor, on a programmable logic controller, on a machine controller, on a computing device in a local network, on an edge device and / or in the cloud. In other words, the underlying hardware landscape is almost arbitrary, which is a very big advantage of the approach according to the invention. The execution environment works abstractly with computing nodes, and the underlying hardware can be configured in a very heterogeneous way. In particular, edge or cloud architectures also become available for safety technology, without having to abandon the familiar evaluation hardware of the (safety) sensor or controller.

[0036] The execution environment is preferably configured to include and / or exclude computational nodes, so that the hardware environment may change and the execution environment can react by creating new or adapted computational nodes. Thus, new hardware can be plugged in or hardware can be replaced, in particular for replacement in case of (partial) failure, as well as for expansion and provision of additional computational and storage resources. Logical units can continue to run on computational nodes abstracted by the execution environment, even if the hardware configuration is radically changed.

[0037] At least one logic unit is preferably configured as an automation unit which generates from the sensor data information related to the automation task and / or control instructions for the machine, which are not related to safety. The execution environment thus supports other types of logic units which provide additional functions not related to safety based on the sensor data. Such automation tasks do not concern the protection of people or the avoidance of accidents and therefore do not have to meet any safety standards in this respect. Typical automation tasks are quality and progress control, object recognition for picking, sorting or other work steps, classification, etc. It is also beneficial for the automation unit if the execution environment allocates flexible resources to it and monitors whether it is still performing its task, for example starting it anew, moving it to another computing node or calling and activating a copy of the logic unit, as the case may be. However, what is important in this case is to avoid stoppages and to support normal progress and maintain availability, which are very important for the machine operator but have no relation to safety. It is conceivable to integrate the automation unit into the status and performance monitoring of the diagnostic unit. This is because reliable automation functions can still bring added value, even if they adhere to a perhaps overly high level of safety here.

[0038] The diagnostic unit is preferably configured to check, depending on the situation, whether a function error is safety-relevant. The state or execution of the existing safety function units can be evaluated differently depending on the current environment. For example, a body part entering the robot's working area is considered exceptional and not dangerous if it is simultaneously ensured that the robot remains in a limited coordinate area that does not include the body part. Under such situation-dependent boundary conditions, it is even conceivable that the safety function units and the automation units dynamically exchange their roles.

[0039] The safety device preferably comprises a shut-off unit which is arranged to put the machine into a safe state on command of the diagnostic unit in case of a safety-relevant functional error or on command of the safety functional unit in case of recognition of a dangerous situation on the basis of the evaluated sensor data. The shut-off unit or shut-off service thus takes care that the machine is actually protected when the diagnostic unit or the safety functional unit requests the protection of the machine, preferably by sending an appropriate signal to the machine or to its machine control device. Depending on the situation, the safe state is achieved for example by slowing down, a special operating mode of the machine (for example limiting the freedom or variety of movements), avoidance or stopping. The shut-off unit can be implemented as a logic unit and incorporated into the diagnostics. Preferably, the shut-off unit regularly receives a signal from the diagnostic unit that everything is functioning correctly and, if this signal is lost, reacts with some protective measure as if there had been an explicit request for protection.

[0040] The execution environment preferably comprises a message system through which the at least one safety function unit transmits status and execution messages to the diagnostic unit. Particularly preferably, the message system is configured with two message channels for transmitting status and execution messages in parallel, whereby the two message flows make it possible to keep status monitoring and execution monitoring separated from each other.

[0041] The at least one safety function unit is preferably configured to transmit status messages regularly and / or to transmit execution messages on an event basis after each execution of the safety function of said unit. This results in a continuous monitoring of the state of the safety function unit with a fine granularity that is ultimately set by the desired safety level. "Regularly" can mean "periodically", but is slightly more flexible than that. It is sufficient that the state is known again at the latest after a given time has elapsed, but within this range the time interval between two status messages may fluctuate. The exchange of execution messages can be event-based, since execution messages provide new information each time something has been executed in the meantime. Since the safety functions are based on sensor data and the sensors themselves often provide their data periodically, evaluation events can occur periodically, so that the event-based sequence also ends up being periodic in this indirect way.

[0042] Status and / or execution messages preferably provide origin information relating to the safe functional unit from which they originated, a timestamp, a sequence and / or a checksum. This allows the state and execution to be attributed to the correct logical unit and sequenced in time. The sequence organizes the messages or their contents. The checksum or a comparable means allows to prove that the message contents were transmitted correctly.

[0043] The at least one secure functional unit is preferably configured to perform a self-diagnosis, which checks the agreement of its own data, programs, processing results and / or system time. From there, the secure functional unit can in particular ascertain its own status and report it in a status message. Deviations from the system time will result in discrepancies with the timestamps in the message, which may potentially lead to erroneous system diagnostics. Since the logic units themselves are not configured securely, self-diagnosis alone is not sufficient to guarantee safety as a whole, but it is one possible component of safety.

[0044] The diagnostic unit is preferably arranged for status monitoring to call up a predefined status prediction for the state of the at least one safety functional unit, in particular based on the previous states of the logic units, the work process and / or the work results, and to compare the status prediction with a current overall state derived from the state of each status message. In this way, the diagnostic unit has a status prediction for the error-free system, which can be configured, predefined elsewhere, programmed in a fixed manner or stored in a memory. The status prediction can be that status messages are received from all currently existing safety functional units in an essentially regular manner or that only certain states are reported that do not indicate an error. The status prediction can be adapted depending on the situation. Current status information is calculated from the received status messages, in particular by combining them into an overall state which is compared with the status prediction. Any deviations indicate a safety-relevant functional error. In this case, there may be tolerances and time tolerances for certain safety functions. Any deviations that cannot be explained by the tolerances, the current situation or other previously considered exceptions are preferably evaluated as a safety-relevant functional error and subsequently the machine is transferred to a safe state.

[0045] A status message preferably gives information about whether the safety function unit transmitting it exists, whether it has been initialized, whether all resources required by it are available, such as databases, codes, libraries, computational resources, connections to sensors, and / or whether it is ready to function. These are examples of the content of a status message or states derived from its content. A status message may end with a simple "OK" or even imply a message already by its mere arrival. A status message preferably also contains the general information listed above, such as originator, timestamp and checksum.

[0046] For the performance monitoring, the diagnostic unit is preferably arranged to call up a predefined performance prediction for the performance course of the at least one safety functional unit, to modify said performance prediction in particular based on the previous states, work courses and / or work results of the logic units, and to compare said performance prediction with the performance course derived from each execution message. In this way, the diagnostic unit has a performance prediction for the time and logical sequence of the execution of the at least one safety functional unit. This is compared with the actual execution sequence obtained from each execution message. Any deviations indicate a safety-relevant functional error. As already mentioned in the case of condition monitoring, not all deviations are necessarily functional errors and not all functional errors are necessarily safety-critical and result in a reaction towards securing the machine. A tolerance is preferably present in the comparison and, as already mentioned, a situation-dependent evaluation is optionally performed.

[0047] The diagnostic unit is preferably configured to take into account at least one of the following criteria when evaluating the comparison between the execution prediction and the execution progress derived from each execution message: execution order, non-occurrence of an execution, extra executions, deviation from the time raster of an execution, too short execution duration or too long execution duration. Deviation from the time raster can be understood as a particularly important special case of non-occurrence or extra executions. Many of these criteria do not yet necessarily lead to a safety-related lack of monitoring. However, they are indications that the system is in a state different from the design, and if the deviation is not foreseen in the safety concept and is certainly contained by said concept, the machine should be put into a safe state as a precaution.

[0048] The execution message preferably presents execution information about the respective last execution of the safety function, in particular including the start time and / or execution duration. The execution duration can of course also be conveyed indirectly, for example by the end time. Furthermore, general information such as the sender, the timestamp and / or the checksum of the message are preferably added. If a safety function unit executes several safety functions, the message can be supplemented with an identification number corresponding to the safety function. However, each safety function unit is preferably responsible for only one safety function, and if necessary, further safety function units are simply generated for further safety functions. The execution message can also contain the execution result, for example the execution result of a targeted test, which checks whether the input data entered for trial (sensor data, emulated sensor data, etc.) leads to the expected execution result. However, the concept of state monitoring and execution monitoring is preferably independent of the concrete content, while it is not excluded to carry out additional tests of this kind, in which case separate test diagnostic units and test messages can also be used.

[0049] Preferably, the execution environment comprises a collection unit logically arranged between the at least one safety function unit and the diagnostic unit, the collection unit being adapted to receive execution messages and to generate from the messages an execution history, including the order and / or duration of the execution of the safety functions of the at least one safety function unit. In this way, the collection unit takes over part of the task of performance monitoring, which can alternatively also be implemented in the diagnostic unit. After the collection, the individual execution messages are already combined to form an execution history. The collection unit preferably works in real time, which not only provides data with suggestions for bottlenecks etc. for later manual optimization, but also is part of the safety monitoring and thus accident avoidance.

[0050] It is preferred that the at least one sensor is configured as a photoelectric sensor, in particular a photointerceptor, photodetector, light grid, laser scanner, FMCW-LIDAR or camera, as an ultrasonic sensor, an inertial sensor, a capacitive sensor, a magnetic sensor, an inductive sensor, an UWB sensor, or as a process variable sensor, in particular a temperature sensor, a flow sensor, a level sensor or a pressure sensor, and that the safety device in particular comprises a large number of homogeneous or heterogeneous sensors. These are some examples of sensors that can provide important sensor data for a safety application. The specific selection of the sensor or sensors depends on the respective safety application. The sensors can already be configured as safety sensors themselves. However, the invention instead explicitly provides for achieving safety only at a later stage by means of tests, additional sensor systems or redundancy (with diversity) or multiple channels, etc., and for combining safe and non-safe sensors with the same or different sensor principles with each other. For example, a faulty sensor does not output sensor data, which is reflected in the status and performance messages of the safety function unit responsible for the sensor and is thus noticed by the diagnostic unit during status and performance monitoring.

[0051] The method according to the invention can be implemented in a similar manner and thus exhibits similar advantages, such advantageous features being exemplarily recited, for example but not exclusively, in the dependent claims following the independent claims of this application.

[0052] The invention, together with further characteristics and advantages thereof, will now be described in greater detail, exemplarily on the basis of embodiments, with reference to the accompanying drawings, in which: FIG. [Brief description of the drawings]

[0053] [Figure 1] Overview of the safety device. [Diagram 2] FIG. 2 is a schematic diagram of the execution environment of the safety device; [Diagram 3] Schematic diagram of an exemplary execution environment with two computing nodes. [Figure 4] 4 is a schematic diagram of an execution environment similar to that of FIG. 3 in a particular embodiment using Kubernetes. [Diagram 5] Schematic diagram of the dual message flow of status and execution messages to the system diagnostic unit. [Figure 6] Schematic diagram of status monitoring based on status messages. [Figure 7] Schematic diagram of execution monitoring based on execution messages. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0054] 1 shows a schematic diagram of a safety device 10. The concepts "safety" as well as "safe" and "unsafe" should still be understood to mean that the relevant components, transmission paths and evaluation parts either meet or do not meet the criteria of the safety standards mentioned at the beginning.

[0055] The safety device 10 is divided into three main blocks: a block including at least one machine 12 to be monitored, a block including at least one sensor 14 for generating sensor data of the monitored machine 12, and a block including at least one hardware part 16 having computational and storage resources for control and evaluation functions for evaluating the sensor data and possibly initiating some reaction of the machine 12 in a manner to ensure safety. The machine 12, the sensor 14 and the hardware part 16 are sometimes referred to in the singular and sometimes in the plural below, which explicitly includes alternative embodiments in which there is only one of each unit 12, 14, 16 or there are multiple of each unit 12, 14, 16.

[0056] Examples of the three blocks are depicted around the periphery. The machine 12, which is used in particular industrially, is, for example, a processing machine, an assembly line, a sorting facility, a process facility, a robot, or a vehicle, and the vehicle may be of a rail-bound or non-bound type, and in particular is a self-propelled type (AGC: Automated Guided Cart, AGV: Automated Guided Vehicle, AMR: Autonomous Mobile Robot).

[0057] Exemplary sensors 14 include photoelectric sensors such as laser scanners, light grids, and stereo cameras, as well as other sensors such as photodetectors, photointerceptors, FMVW-LIDAR, or cameras using 2D or 3D detection such as projection or time-of-flight, respectively. Some further examples of sensors 14 include, but are not limited to, UWB sensors, ultrasonic sensors, inertial sensors, capacitive, magnetic, or inductive sensors, or process variable sensors such as temperature, flow, level, or pressure sensors. These sensors 14 may be provided in any number and in any combination depending on the safety device 10.

[0058] Possible hardware components 16 are control devices (PLC: Programmable Logic Controller, or SPS: speicherprogrammierbare Steuerung), computers in a local network, in particular edge devices, or even a cloud operated by the company itself or by a third party, and quite generally any hardware that provides resources for digital data processing.

[0059] Within Fig. 1 three blocks are taken up again: the machine 12 is preferably connected to the safety device 10 via its machine control device 18, which in the case of a robot is a robot control device, in the case of a vehicle a vehicle control device, in the case of a process installation a process control device, and similarly for the other machines 12. Each sensor 14, internally grouped as a block 20, not only generates sensor data but also has a separate interface (not shown) for outputting the sensor data in raw or (pre)processed form, and also usually has its own control and evaluation unit, i.e. its own hardware components for data processing.

[0060] The execution environment 22 is a generic concept representing a processing unit that performs data processing, particularly on the sensor data, to obtain control commands for the machine 12 or other safety-related and other information therefrom. The execution environment 22 is implemented on the hardware components 16, which will be described in more detail below with reference to Figs. 2-4. The present invention does not prescribe on which hardware the execution environment 22 is executed. The above-listed possible hardware components are only a few examples, and they can be combined in any way. Furthermore, the execution environment 22 is intentionally depicted superimposed on the machine control device 18 and the sensor 14 block 20, since the computation and storage resources inside the sensor 14 and / or the machine 12 can also be used by the execution environment 22, while on the other hand it is also possible that in any combination there are no additional hardware components 16 at all outside the machine 12 and the sensor 14. In the following, it is assumed that the hardware components 16 provide computation and storage resources, which also means the addition of the hardware inside the machine 12 and / or the sensor 14.

[0061] The safety device 10 and in particular the execution environment 22 thus provide safety and diagnostic functions. The safety functions receive a time-series flow of measurement and event information together with the sensor data and generate corresponding evaluation results, in particular in the form of control signals for the machine 12. In addition, self-diagnosis information, diagnostic information of the sensors 14 or overview information can be obtained. These are to be distinguished from proper diagnostic functions, the latter being meant within the scope of this document as the monitoring of safety functions, as will be explained in more detail below with reference to figures 5 to 7. Besides these safety-related or safe automation functions, non-safety automation functions are also conceivable as further options.

[0062] The safety device 10 achieves high availability and robustness against unexpected internal and external events by providing safety functions as services or service executions of hardware components 16. The flexible assembly of the hardware components 16 and their connection to preferably local or non-local networks or clouds allows redundancy and performance flexibility, which results in a very robust handling of interruptions, disturbances and peaks in demand. The safety device 10 recognizes as soon as an error is no longer captured and thus becomes safety-relevant and initiates a reaction adapted to the situation, whereby, if necessary, the machine 12 is brought into a safe state, for example by stopping, slowing down, avoiding or operating in a non-hazardous mode. To clarify once again, there are two classes of events that can trigger a safety reaction: on the one hand, events assessed as dangerous from sensor data, and on the other hand, the exposure of a safety-relevant error.

[0063] 2 shows a schematic diagram of the execution environment 22. The task of the execution environment 22 is to finally derive control commands from the sensor data, in particular safety signals that trigger the reaction of the machine 12 towards safety. The execution environment 22 comprises a master 24 and at least one computing node 26. The computing power and storage capacity required for the master 24 and the computing node 26 are provided by the hardware components 16, and the execution environment 22 can be spread transparently across multiple hardware components 16. It should also be understood that the computing node 26 is abstract or virtual, and it is not essential that there is a one-to-one relationship between the computing node 26 and the hardware components 16, but rather that one hardware component 16 may provide multiple computing nodes 26 or, conversely, that one computing node 26 is distributed over multiple hardware components 16. This distribution also applies to the master 24.

[0064] The computational node 26 comprises one or more logic units 28. A logic unit 28 is a closed functional unit which receives information, combines, transforms, modifies and generally processes it into new information and then makes it available to possible recipients, in particular other logic units 28 or the machine control 12, for visualization, as control commands or for other processing. Within the framework of this document, a distinction is made between three main types of logic units 28: safety function units, diagnostic units and optional automation units, which, as already mentioned briefly, allow the integration of other automation tasks that do not contribute to safety into the overall application.

[0065] The execution environment 22 activates the required logical units 28 in each case and drives them systematically. In addition, the execution environment 22 allocates to each logical unit 28 the required resources on the available computation nodes 26 or hardware components 26 and monitors the activity and resource demands of all logical units 28. Preferably, the execution environment 22 recognizes when a logical unit 28 is no longer active or when the execution environment 22 or a logical unit 28 is interrupted. The execution environment then tries to reactivate the logical unit 28 and, if this is not possible, creates a new copy of the logical unit 28, thereby maintaining systematic driving. However, this is an insufficient mechanism for functional safety requirements and is only used in cases where the system diagnostics described below with reference to Figures 5 to 7 do not expose safety-relevant errors in advance or, for example, during initialization or restart when the machine 12 is still stopped anyway.

[0066] Interruptions may be predictable or unpredictable. Exemplary causes are errors in the infrastructure, i.e. the hardware component 16, its operating system or network connections, or even erroneous mishandling or modification, or the complete consumption of the resources of the hardware component 16. If a certain logical unit 28 is not able to process all the necessary information, in particular safety-related information, at all, or at least not fast enough, the execution environment 22 can ensure the continued processing of said information by creating an additional copy of the corresponding logical unit 28. In this way, the execution environment 22 ensures that the logical unit 28 provides its functionality with the expected quality and availability. Such recovery and correction measures are also not a substitute for system diagnostics, as mentioned in the previous paragraph and explained below.

[0067] Fig. 3 also shows another advantageously differentiated embodiment of the execution environment 22 of the safety device 10. The master 24 is the management and communication center. Since it contains configuration information or configuration data about the existing logical units 28, the master 24 has the necessary knowledge about the configuration, in particular which logical units 28 are or should be, which computation nodes 26 they should be on, and when they receive resources and are called. The configuration data is preferably protected against intentional or unintentional modifications by signatures, for example by blockchain technology. It is advantageous here to combine safety with data integrity ((Cyber-)Security), since in this way attacks that could result in unexpected accidents are prevented or at least recognized.

[0068] Advantageously, the computation node 26 has its own substructure, in which only a part of the units just described may be present. Firstly, the computation node 26 can be further divided into subnodes 30. In the figure, two computation nodes 26 each have two subnodes 30, but these numbers are merely exemplary, any number of computation nodes 26 may have any number of subnodes 30, and the number of subnodes 30 may vary across the computation nodes 26. The logical units 28 are preferably not created immediately at the level of the computation node 26, but first in the subnodes 30. Preferably, the logical units 28 are virtualized within a container, i.e., containerized. That is to say, each subnode 30 has one or more containers, each preferably having one logical unit 28. Instead of a general logical unit 28, FIG. 3 shows the three types of logical units 28 already mentioned, namely two safety function units 32, one diagnostic unit 34 and one automation unit 36. The types and numbers of logical units 28 are merely examples, in fact the system diagnosis, which will be further described with reference to figures 5 to 7, requires in particular only one diagnostic unit 34. The allocation of logical units 28 to subordinate nodes 30 and to computing nodes 26 is completely independent of the logical structure and cooperation of logical units 28. Therefore, in any case, nothing can be inferred about the content cooperation from the arrangement of logical units 28 shown exemplarily, and the distribution can be changed arbitrarily with exactly the same functionality, which the execution environment 22 provides.

[0069] A node management unit 38 of a computing node 26 coordinates the subordinate nodes 30 of the computing node 26 and the logical units 28 assigned to the computing node 26. The node management unit 38 further communicates with the master 24 and the other computing nodes 26. The responsibility for managing the execution environment 22 can be distributed between the master 24 and the node management unit 38 in a substantially arbitrary manner, i.e. the master can be considered to be implemented in a distributed manner. However, it is advantageous if the master is responsible for the global responsibility of the execution environment 22, while each node management unit 38 is involved in the local responsibility of each computing node 26. Nevertheless, the master 24 can be preferably distributed over multiple hardware components 16 and / or configured redundantly to increase its fault tolerance.

[0070] A typical example of a safety function of the safety function unit 32 is the evaluation of the sensor data of the sensors 14 for safety purposes. Considered here are, inter alia, distance monitoring (in particular speed and separation), passage monitoring, protection zone monitoring or collision avoidance in order to make the machine 12 react appropriately for safety purposes in case of danger. This is the core of safety technology and, depending on the sensors 14 and the evaluation method, a great variety of ways of distinguishing between normal and dangerous situations are possible. For each safety application or group of safety applications, a suitable safety function unit 32 can be programmed or selected from a pool of existing safety function units 32. If the operating environment 22 generates a safety function module 32, this in no way means that a safety function is created anew by it. Rather, suitable libraries or dedicated finished programs are used in a known manner, such as by using data media, storage devices or network connections. It is conceivable to assemble the safety functions semi-automatically or automatically, as if from a kit of ready-made program modules, and / or to configure them appropriately.

[0071] The diagnostic unit 34 can be understood in the sense described in the patent document 5 mentioned at the beginning and can either play the role of a watchdog or carry out tests and diagnostics of various complexity, thereby at least partially replacing and supplementing the safety algorithms and the self-monitoring means of the safety functional units 32. For this purpose, the diagnostic unit 34 has a prediction for the output of the safety functional units 32 at a certain point in time, which can be the output of the safety functional units 32 during normal operation or in response to certain artificial sensor information input as a test. In the present invention, a diagnostic unit 34 is used which does not test the individual safety functional units 32 or wait for certain evaluation results from them (although this is also possible as a complement), but rather carries out a system diagnosis of the safety functional modules 32 involved in the protection of the machine 12, as will be explained later with reference to the figures 5 to 7.

[0072] The automation unit 36 ​​is a logic unit 28 for non-safety related automation tasks, which monitors the sensors 14 and the machine 12 or parts of them (generally actuators) and controls (part of) the process based on this information or prepares information about them. The automation unit 36 ​​is in principle treated like each logic unit 28 by the execution environment and is therefore preferably containerized in the same way. Examples of automation tasks are quality inspection, variant control, object recognition for picking, sorting or other work steps, classification, etc. The distinction with the safety related logic units 28, i.e. the safety function units 32 or the diagnostic units 34, is that the automation unit 36 ​​does not contribute to accident prevention, i.e. safety technical applications. A reliable operation and a certain monitoring by the execution environment 22 is desirable, but this serves not to safety but to increase availability and thus productivity and quality. Of course, this reliability can also be created by the automation unit 36 ​​being carefully monitored like the safety function units 32, so it is possible but not absolutely necessary.

[0073] The execution environment 22 allows the logical units 28 for safety applications to be distributed almost arbitrarily over a very diverse environment of hardware components 16, including edge networks or clouds. The execution environment 22 takes care of all the required resources and framework conditions of the logical units 28. It invokes, terminates and migrates the required logical units 28 between the computation nodes 26 and subordinate nodes 30.

[0074] The architecture of the execution environment 22 further allows a seamless integration of safety and automation, since the safety functional units 32, the diagnostic units 34 and the automation units 36 can be executed almost simultaneously in the same environment and treated equally. In case of conflict, the execution environment 22 preferably gives priority to the safety functional units 32 and the diagnostic units 34, for example in case of resource crunch. In the configuration data, the execution rules for the coexistence of the three different types of logic units 28 can be taken into account.

[0075] FIG. 4 shows a schematic diagram of the execution environment 22 in an embodiment using Kubernetes. The execution environment 22 is called here the control plane. FIG. 4 is modeled after FIG. 3, but the compute nodes 26 are omitted for clarity, and now a general logical unit 28 is shown to represent the three possible types of unit. In Kubernetes, the master 24 has the substructure. This (Kubernetes) master 24 is also not responsible for the execution of the containers or logical units 28 itself, but takes care of the overall progression or orchestration (orchestration layer). The configuration data is therefore called the orchestration file. In addition, there is a database (etcd) 40 for all data related to the Kubernetes environment, an API server 42 as an interface to Kubernetes, and a schedule and control manager 44 that performs the actual orchestration.

[0076] The existing hardware is divided into nodes called compute nodes 26. Inside the nodes, on the other hand, there are one or more so-called pods called subnodes 30, in which the containers containing the actual microservices (in this case the logical units 28) exist, along with their associated container runtime and all libraries and dependencies required at runtime for the logical units 28. The local management is carried out by a node management unit 38, now divided into two parts, with the so-called Kubelet 38a and Proxy 38b. The Kubelet 38a is the agent that manages the node's own pods and containers. On the other hand, the Proxy 38b contains the network rules for communication between the nodes and with the master.

[0077] Kubernetes is the preferred implementation of the execution environment22, but not the only one. Among other alternatives there is Docker Swarm. Docker itself is not a direct alternative, but a container creation tool and therefore can be combined with either Kubernetes or Docker Swarm, in which case they will orchestrate the containers.

[0078] FIG. 5 is another schematic diagram of the execution environment 22, which is drawn to illustrate the system diagnosis by status monitoring and performance monitoring. This is handled by a system diagnosis unit 34, which is a special type of a diagnosis unit 34. Here, purely by way of example, three logic units 28 are considered to be monitored, which operate continuously to evaluate the data of the sensors 14. The invention is not limited to this, and any number of logic units 28 can be arbitrarily connected to each other and with or without their own connection to the sensors 14. The logic units 28 are preferably safety function units 32. Other diagnosis units 34 may also be provided, for example those which exclusively monitor or test specific safety function units 32, supplementing the system diagnosis. Furthermore, even if the automation unit 36 ​​does not need a safety monitoring per se for the avoidance of dangers or accidents, it is still possible to incorporate the automation unit 36 ​​into the system diagnosis. The specific form of the logic unit 28 is not important in the following, and therefore a generic logic unit 28 is depicted.

[0079] The system diagnostics unit 34 is responsible for status monitoring 46 and performance monitoring 48, from which a final decision on the safe state of the overall system can be derived. Status monitoring 46 is explained in more detail below with reference to Fig. 6, and performance monitoring 48 with reference to Fig. 7. Fig. 5 depicts only one system diagnostics unit 34, with its own blocks representing status monitoring 46 and performance monitoring 48. This is particularly helpful for understanding the concept, as it is also conceivable that status monitoring 46 and performance monitoring are part of the system diagnostics unit 34, or that the functionality is distributed in other ways.

[0080] The logic units 28 communicate with the system diagnostics unit 34 through a message system or message transmission system. The message system is part of the execution environment 22 or is implemented as an extension of it. There is a two-fold message flow: status or condition messages 50 of the status monitor 46, which inform about the internal state of the originating logic unit 28, and performance messages 52 of the performance monitor 52, which provide information about the service requests or service performance of the originating logic unit 28. The message system is therefore two-fold or consists of two communication channels. Each message 50, 52 preferably contains metadata that protects the message flow. This metadata includes, for example, originator information, timestamps, sequence information and / or checksums on the message content.

[0081] The system diagnostic unit 34 deduces the overall state of the safety device 10 based on the received status messages 50 and correspondingly derives overall information regarding the processing of the service request or the execution progress of the safety device 10 from the received execution messages 52. Comparison with corresponding expectations reveals errors in the safety device 10 and in case of errors appropriate reactions aimed at ensuring safety are initiated.

[0082] Not every discrepancy immediately indicates a safety-relevant error. Deviations can then be tolerated for a certain time depending on the safety level. Or recovery mechanisms are attempted in order to reach an error-free system state again. However, in this case, the safety concept specifies precisely within what time frame or other time frame errors should only be observed for the time being. Furthermore, it is possible to classify errors that require different drastic protective measures or to evaluate them under situation-dependent conditions. The latter would result in a subdivision of the concepts "safe" and "safe" taking into account the current situation. The failure of a safety-relevant component or the non-execution of a safety-relevant function may not yet necessarily indicate a dangerous system state under certain assumptions, i.e. in some situations. For example, the sensor 14 monitoring the collaborative area including the robot may fail, but on the other hand it is certain that the robot will not be present in this area, which can be guaranteed by the safe coordinate limits of the robot itself. However, the rules for such a situation-dependent evaluation of whether a safety-relevant reaction needs to be initiated must also be known by the system diagnostic unit 34, again in a manner consistent with the safety concept.

[0083] The reaction of the machine 12 towards safety is preferably triggered via a shutdown service 54, which may be a further safety function unit 32, which, contrary to the illustration, can preferably be included in the system monitoring. The shutdown service 54 preferably works in reverse, i.e. it waits for and transmits to the machine 12 a positive signal from the system diagnostic unit 34 allowing operation of the machine 12. This allows failures of the system diagnostic unit 34 or the shutdown service 54 to be caught automatically.

[0084] Despite the name, the machine is not necessarily shut off by the shutdown service 54, it is merely a drastic measure. Depending on the error, it may already be possible to reach a safer state by slowing down, limiting the speed and / or restricting the working space, etc., so that productivity is less affected. The shutdown service 54 can also be requested by one of the logic units 28 when it recognizes a dangerous situation after evaluating the sensor data. The corresponding arrows have been omitted in FIG. 5 for clarity.

[0085] 6 shows a schematic diagram of the status monitoring 46 based on status messages 50. Preferably, the status messages 50 are transmitted to the system diagnostics unit 34 continuously or regularly, in the sense that they must arrive at the latest after a predefined time (for example a few milliseconds) from each logic unit 28 to be monitored. In that case, it is conceivable, but not necessary, for the cycle or clock to be fixed, and time fluctuations within the predefined time frame are also conceivable.

[0086] Preferably, the logic unit 28 performs a self-diagnosis before sending the status message 50. This need not be the case in all embodiments, as the status message 50 may simply be a transfer of vital signs or internal states that have not been previously self-diagnosed, or the self-diagnosis may be performed less frequently than the sending of the status message 50. The self-diagnosis may, for example, check data and program parts stored in its memory, processing results, and system time. Correspondingly, the status message 50 contains information about the internal state of the logic unit 28, providing information about whether the logic unit 28 can correctly perform its task, for example whether the logic unit 28 has all the necessary data at hand in sufficient time. In addition, the status message 50 preferably contains the metadata listed above.

[0087] The system diagnostic unit 34 interprets the content of the status message 50 and assigns it to the respective logic unit 28. The individual states of the logic units 28 are combined from a safety point of view to an overall state of the safety device 10. The system diagnostic unit 34 has predefined expectations as to which overall state in which situation guarantees safety. If, by comparison with the current overall state, taking into account already considered tolerances and possibly situation-specific adaptations, it turns out that said expectations are not fulfilled, this is a safety-relevant error. By sending a corresponding message to the interruption service 54, it puts the machine 12 into the appropriate safe state for the error.

[0088] Fig. 7 shows a schematic diagram of the execution monitoring 48 based on execution messages 52. The first logical unit 28 inside the service generates a unique program sequence indicator (abbreviated as "sequence") that refers to all logical units 28 involved in the service during their execution. The sequence is communicated to the next logical unit 28 after each execution, so that it can associate itself with the sequence when creating the execution message 52. The execution message 52 preferably contains, in addition to the metadata listed above, the start time and duration of each execution. Other possible elements of the execution message 52 are a unique indicator of what was executed and the sequence. The execution message 52 is preferably event-based and is sent at the end of each complete execution. Indirectly, the flow of event-based messages can also be periodic or regular in the sense defined above, since it is often necessary to evaluate periodically prepared sensor data.

[0089] A counting unit 56 collects the execution messages 52 and places each execution into a logical and temporal sequence or execution history based on a unique program sequence indicator. This execution history thus describes the actual execution. The system diagnostic unit 34 on the other hand has access to an execution expectation 58, i.e. the expected execution history. This execution expectation 58 is typically a reference value set by a safety expert in relation to a safety concept, but can still be modified by the system diagnostic unit 34 in some embodiments. If the system diagnostic unit 34 did not have access to the execution expectation 58, it would in any case result in a safety-related error after a permissible time, as a result of which a shutdown service 54 is required to protect the machine 12. The counting unit 56 and the execution expectation 58 are depicted separately and are preferably implemented as such, but can alternatively be interpreted as part of the system diagnostic unit 34.

[0090] Within the framework of the execution monitoring 48, the system diagnostic unit 34 in turn compares the execution progress transmitted by the counting unit 56 with the execution forecast 58 in order to recognize temporal and logical errors during the processing of the service request. In the event of a discrepancy, stabilization steps can be initiated or, if the error is no longer clearly repressible, the machine 12 is immediately protected via a shutdown service 54.

[0091] Some examples of aspects checked by the performance monitor 48 are: an execution is not enough to completely fulfill a service, unexpected extra executions are reported (which may be unexpected multiple executions of logic units 28 involved in the service or executions of logic units 28 not involved in the service), execution times that are too short or too long (including quantification to determine if they are critical), elapsed time between executions of individual executions of a logic unit 28. Which of these discrepancies are safety-related, within what frames and in what circumstances they are still acceptable, and respectively which appropriate safety measures are initiated, are stored in the performance predictions 58 and / or the system diagnostic unit 34.

Claims

1. A safety device (10) for monitoring at least one machine (12), comprising at least one sensor (14) for generating sensor data for the machine (12), and a processing unit (16, 22) for the sensor data, connected at least indirectly to the sensor (14) and to the machine (12), the processing unit being configured as an execution environment (22) having at least one computing node (26) and configured to operate a number of logic units (28) on the at least one computing node (26), the at least one logic unit (28) being configured as a safety function unit (32) for evaluating the sensor data for safety purposes, the at least one logic unit (28) being configured as a diagnostic unit (34) for monitoring the safety function unit (32), The at least one safety function unit (32) is configured to transmit a status message (50) and an execution message (52) to the diagnostic unit (34), and the diagnostic unit (34) is configured to recognize a safety-related functional error in the safety device (10) based on a status from the status message (50) in a status monitoring (46) and on an execution progress from the execution message (52) in an execution monitoring (48). A safety device (10) characterized by:

2. 2. The safety device (10) according to claim 1, wherein the diagnostic unit (34) is adapted to contextually check whether a functional error is safety-related.

3. 2. The safety device (10) according to claim 1, further comprising a shut-off unit (54) configured to switch the machine (12) into a safe state upon command of the diagnostic unit (34) in the event of a safety-related functional error or upon command of a safety function unit (32) in the event of recognition of a dangerous situation on the basis of evaluated sensor data.

4. A safety device (10) according to any one of claims 1 to 3, wherein the execution environment (22) comprises a message system through which the at least one safety function unit (32) transmits status messages (50) and execution messages (52) to the diagnostic unit, in particular the message system being configured with two message channels for transmitting status messages (50) and execution messages (52) in parallel.

5. The safety device (10) according to any one of claims 1 to 3, wherein the at least one safety function unit (32) is configured to transmit a status message (50) regularly and / or to transmit an execution message (52) upon each execution of the safety function of the unit on an event basis.

6. The safety device (10) according to any one of claims 1 to 3, wherein the status message (50) and / or the execution message (52) present sender information, a timestamp, a sequence and / or a checksum relating to the safety function unit (32) from which the message originates.

7. The safety device (10) according to any one of claims 1 to 3, wherein the at least one safety function unit (32) is configured to perform a self-diagnosis to check the consistency of its own data, programs, processing results and / or system time.

8. 4. A safety device (10) according to claim 1, wherein the diagnostic unit (34) is configured for the status monitoring (46) to call up a predefined status prediction for the state of the at least one safety function unit (32), to modify said status prediction based in particular on the state of the logic unit (28) so far, on a work progress and / or on a work result, and to compare said status prediction with a current overall state derived from the state of each status message (50).

9. A safety device (10) according to any one of claims 1 to 3, wherein the status message (50) provides information about whether the safety function unit (32) transmitting the status message (50) is present, has been initialized, whether all resources required for the unit are available, and / or whether the unit is ready to function.

10. 4. A safety device (10) according to claim 1, wherein the diagnostic unit (34) is configured for the performance monitoring (48) to call up a predefined performance prediction (58) for the performance course of the at least one safety function unit (32), to modify the performance prediction (58) in particular based on a state, a work course and / or a work result of the logic unit (28) up to that point, and to compare the performance prediction (58) with the performance course derived from each performance message (52).

11. 11. The safety device (10) of claim 10, wherein the diagnostic unit (34) is configured to take into account at least one of the following criteria when evaluating the comparison between the execution prediction (58) and the execution progress derived from each execution message (52): execution order, non-occurrence of an execution, redundant executions, deviation of an execution from a time raster, too short execution duration, or too long execution duration.

12. A safety device (10) according to any one of claims 1 to 3, wherein the execution message (52) presents execution information relating to the respective last execution of a safety function of the at least one safety function unit (32), in particular execution information including a start time and / or execution duration.

13. A safety device (10) according to any one of claims 1 to 3, wherein the execution environment (22) comprises a collection unit (56) logically arranged between the at least one safety function unit (32) and the diagnostic unit (34), the collection unit being configured to receive the execution messages (52) and to generate from the messages an execution progress, in particular in real time, including the order and / or duration of the execution of the safety functions of the at least one safety function unit (32).

14. 4. The safety device (10) according to claim 1, wherein the at least one sensor (14) is configured as a photoelectric sensor, in particular a photointerceptor, photodetector, light grid, laser scanner, FMCW-LIDAR or camera, as an ultrasonic sensor, an inertial sensor, a capacitive sensor, a magnetic sensor, an inductive sensor, an UWB sensor or as a process variable sensor, in particular a temperature sensor, a flow sensor, a level sensor or a pressure sensor, and the safety device (10) in particular comprises a multitude of homogeneous or heterogeneous sensors (14).

15. A computer-implemented method for monitoring at least one machine (12), comprising: at least one sensor generating sensor data for the machine (12); a processing unit (16, 22) for the sensor data, at least indirectly connected to the sensor (14) and to the machine (12), running a number of logic units (28) on at least one computing node (26) as an execution environment (22), at least one logic unit (28) as a safety function unit (32) evaluating the sensor data for safety purposes; and at least one logic unit (28) as a diagnostic unit (34) monitoring the at least one safety function unit (32), The at least one safety function unit (32) transmits a status message (50) and an execution message (52) to the diagnostic unit (34), and the diagnostic unit (34) recognizes a safety-related function error based on a status from the status message (50) in a status monitoring (46) and on an execution progress from the execution message (52) in an execution monitoring (48). The method comprising:

Images