Patent ID: 12260252

FIG.1shows an overview representation of a safety device10. The terms safety and safe and unsafe are still to be understood such that corresponding components, transmission paths, and evaluations satisfy or do not satisfy the criteria of safety standards named in the introduction.

The safety device10can roughly be divided into three blocks having at least one machine12to be monitored, at least one sensor14for generating sensor data of the monitored machine12, and at least one hardware component16with computing and memory resources for the control and evaluation functionality for evaluating the sensor data and triggering any safety relevant response of the machine12. The machine12, sensor14, and hardware component16are sometimes addressed in the singular and sometimes in the plural in the following, which should explicitly include the respective other embodiments with only one respective unit12,14,16or a plurality of such units12,14,16.

Respective examples for the three blocks are shown at the margins. The preferably industrially used machine12is, for example, a processing machine, a production line, a sorting station, a process plant, a robot, or a vehicle that can be rail-bound or not and is in particular driverless (AGC, automated guided cart; AGV, automated guided vehicle; AMR, autonomous mobile robot).

A laser scanner, a light grid, and a stereo camera as representatives of optoelectronic sensors are shown as exemplary sensors14which include further sensors such as laser scanners, light barriers, FMCW LIDAR, or cameras having any 2D or 3D detection such as projection processes or time of flight processes. Some examples for sensors14that are still not exclusive are UWB sensors, ultrasound sensors, inertial sensors, capacitive, magnetic, or inductive sensors, or process parameter sensors such as temperature sensors, throughflow sensors, filling level sensors, or pressure sensors. These sensors14can be present in any desired number and can be combined with one another in any desired manner depending on the safety device10.

Conceivable hardware components16include controllers (PLCs, programmable logic controllers) a computer in a local network, in particular an edge device or also a cloud, and very generally any hardware that provides resources for digital data processing.

The three blocks are captured again in the interior ofFIG.1. The machine12is preferably connected to the safety device10via its machine controller18, with the machine controller being 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 similar for other machines12. The sensors14combined in the interior as a block20not only generate sensor data, but also have an interface, not shown individually, to output the sensor data in a raw or (pre)processed form and as a rule have their own control and evaluation unit, that is their own separate hardware component for digital data processing.

A runtime environment22is a summarizing term for a processing unit that inter alia performs the data processing of the sensor data to acquire control commands to the machine13or other safety relevant and further information. The runtime environment22is implemented on the hardware components16and will be explained in more detail in the following with reference toFIGS.2to6. Which hardware the runtime environment22will be executed on is not fixed in accordance with the invention. The above list of possible hardware components names some examples that can be combined as desired. The runtime environment22is furthermore intentionally drawn with an overlap to the machine controller18and to the block20of the sensors14since internal computing and memory resources of the sensors14and/or of the machine12can be also be used by the runtime environment22, again in any desired combination, including the possibility that there are no additional hardware components16at all outside the machine12and the sensors14. It is assumed in the following that the hardware components16provide the computing and memory resources so that an inclusion of internal hardware of the machine12and/or sensors14is then also meant.

The safety device10and in particular the runtime environment22now provides safety functions and preferably also diagnostic functions. Additional non-safe automation functions will be introduced as a further option later with reference toFIG.5delineated from safety functions that can also be called safe automation functions. Such a safety function receives the flow of measurement and event information with the sensor data following one another in time and generates corresponding control signals and preferably also diagnostic or overview information.

The safety device10achieves a high availability and robustness with respect to unforeseen internal and external events in that safety functions are performed as a service of the hardware components16. The flexible composition of the hardware components16and preferably their networking in the local or non-local network or in a cloud enable a redundancy and a performance elasticity so that interruptions, disturbances, and demand peaks can be dealt with very robustly. The safety device10recognizes as soon as errors can no longer be intercepted and thus become safety relevant and then initiates an appropriate response by which the machine12is moved into a safe state as required. For this purpose, the machine12is, for example, stopped, slowed down, it evades, or works in a non-hazardous mode. It must again be made clear that there are two classes of events that trigger a safety relevant response: on the one hand, an event that is classified as hazardous and that results from the sensor data, and, on the other hand, the revealing of a safety relevant error.

FIG.2shows a schematic representation of the runtime environment22. It is ultimately the object of the runtime environment22to derive a control command from sensor data, in particular a safety signal that triggers a safety relevant response of the machine12. The runtime environment22has a master24and at least one computing node26. The hardware components26provide the required computing and memory capacity for the master24and computing nodes26; the runtime environment22can extend transparently over a plurality of hardware components16. A computing node26is here to be understood abstractly or virtually; there is not necessarily a 1:1 relationship between a computing node26and a hardware component16, but a hardware component16can rather provide a plurality of computing nodes26or, conversely, a computing node26can be deployed over a plurality of hardware components16. The deployment applies analogously to the master24.

A computing node26has one or more logic units28. A logic unit28is a functional unit that is closed per se, that accepts information, collates it, transforms it, recasts it, or generally processes it into new information and then makes it available to possible recipients as a control command or for further processing, in particular to further logic units28or to a machine controller12. Three types of logic units28must primarily be distinguished within the framework of this description, namely the safety functional units and diagnostic units introduced with respect toFIG.3and the automation units introduced with reference toFIG.5.

The runtime environment22activates the respective required logic units28and provides for their proper operation. For this purpose, it assigns the required resources on the available computing nodes26or hardware components26to the respective logic units28and monitors the activity and the resource requirement of all the logic units28. The runtime environment22preferably recognizes when a logic unit28is no longer active or when interruptions to the runtime environment22or the logic unit28occurred. It then attempts to reactivate the logic unit28and generates a new copy of the logic unit28if this is not possible to thus maintain proper operation.

Interruptions can be foreseen or unforeseen. Exemplary causes are errors in the infrastructure, that is in the hardware components16, their operating system, or the network connections; furthermore accidental incorrect operations or manipulations or the complete consumption of the resources of a hardware component16. If a logic unit28cannot process all the required, in particular safety relevant, information or at least cannot process it fast enough, the runtime environment22can prepare additional copies of the respective logic unit28to thus further ensure the processing of the information. The runtime environment22in this manner provides that the logic unit28produces its function at an expected quality and availability.

FIG.3again shows a further advantageously fully differentiated embodiment of the runtime environment22of the safety device10. The master24forms the management and communication center. Configuration information or a configuration file on the logic units28present is stored therein so that the master24has the required knowledge of the configuration, in particular which logic units28there are and should be, on which computing nodes26they can be found, and at which time interval they receive resources and are invoked. The configuration file is preferably secured via signatures against intentional and unintentional manipulations, for example via blockchain technologies. Safety engineering (safety) here advantageously joins forces with the data integrity ((cyber) security) since attacks are repulsed or at least recognized in this manner that could result in unforeseeable accident consequences.

The computing nodes26advantageously have their own sub-structure, with the now described units also only being able to be present in part. Initially, computing nodes26can again be divided into sub-nodes30. Logic units28are preferably only generated within the sub-nodes30, not already on the level of computing nodes26; logic units28are preferably virtualized within containers, that is are containerized. Each sub-node30therefore has one or more containers, with preferably one logic unit28each. There are two logic units28in the example ofFIG.3, namely a safety functional unit32and a diagnostic unit24, each in their own container and also sub-nodes30. Differing from this, it would equally be conceivable to assign the safety functional unit32and diagnostic unit34to the same sub-node30.

A node manager unit36of the computing node30coordinates its sub-nodes30and the logic units28assigned to this computing node26. The node manager unit36furthermore communicates with the master24and with further computing nodes26. The management work of the runtime environment22can be deployed practically as desired on the master24and the node manager unit36; the maser can therefore be considered as implemented in a deployed manner. It is, however, advantageous if the master looks after the global work of the runtime environment22and each node manager unit36looks after the local work of the respective computing node26. The master24can nevertheless preferably be formed on a plurality of hardware components16in a deployed or redundant manner to increase its fail-safeness.

A securing unit or safety functional unit32is an example for a special logic unit28for evaluating sensor data for securing work with functional safety. Typical examples are distance monitoring systems (specifically speed and separation), passage monitoring, protected field monitoring, or collision avoidance with the aim of an appropriate safety relevant response of the machine12in a hazardous case. This is the core task of safety engineering, with the most varied paths being possible of distinguishing between a normal situation and a dangerous one in dependence on the sensor14and the evaluation process. Suitable safety functional units32can be programmed for every safety application or group of safety applications or can be selected from a pool of existing safety functional units32.

A diagnostic unit34is a further example for a special logic unit28and is likewise safety relevant. The diagnostic unit34can be simple, for instance as a watchdog or can carry out tests and diagnoses of different complexity. As a logic unit28, it runs in the same runtime environment22and is operated according to its same basic principles, just like a safety functional unit32. It is able to replace safe algorithms and self-monitoring measures of a safety functional unit32at least in part or to complement them. For this purpose, however, the diagnostic unit34monitors the activities of the functional safety unit22for their correctness in an analyzed manner, i.e. whether this functional safety unit32carries out the activities intended for it in the fixed order and in the temporal conditions. The runtime environment22therefore only checks whether a functional safety unit32is still active at all; the diagnostic unit34in contrast specifically checks whether orders, time widows, points in time, and contents of the activities are correct and thus reveals errors of the safety functional unit32. For this purpose, the diagnostic unit34has expectations for the output of the safety functional unit32at specific times, either in its regular operation or in response to specific artificial information fed in as a test.

It becomes possible by the use of the runtime environment22to deploy safety relevant logic units28in practically any desired manner over an environment, also a very heterogeneous environment, of the hardware components26, including an edge network or a cloud. The runtime environment22initiates the required logic units28, ends them or displaces them between the computing nodes26and the sub-nodes30.

FIG.4shows a further embodiment of the runtime environment22of the safety device10. Complementing the embodiment in accordance withFIG.3, copies of the safety functional unit32and of the diagnostic unit24are produced here. A further computing node26is also present in this example for this purpose, but this would not be compulsory since further logic units could also be applied in the same computing node26or even in sub-nodes30. The additional logic units28are not provided for additional functionality even though this would also be conceivable, but rather to generate redundancies. A diagnostic unit34can in this respect be respectively associated with a safety functional unit32of the same or of a different computing node26, equally to the same or to a different sub-node30. In addition, a diagnostic unit34can alternatively monitor a safety functional unit32one-to-one, or a diagnostic unit34is responsible for a plurality of safety functional units32or, conversely, a plurality of diagnostic units34are responsible for the same safety functional unit32. A plurality of diagnostic units34can additionally preferably compare their diagnoses with one another.

The invention thus makes possible a scaling of the safety level (for instance performance class PC in accordance with IEC/TS 62998, performance level in accordance with ISO 13849, or safety integrity level, SIL, in accordance with IEC 61508) via an adaptation to a heterogeneous environment with almost any desired hardware components16. There are three adjustable screws for this purpose: The frequency of the diagnosis, that is the test cycles by which a diagnostic unit34monitors a safety functional unit32, the multiplicity of the redundancy, that is how many copies of a safety functional unit32and/or diagnostic unit34are active and the diversity, that is on how many computing nodes26or sub-nodes30the safety functional unit32and diagnostic units34are deployed.

The following gradation of the safety level could be achieved by way of example:

Low safety level: a safety functional unit32and a diagnostic unit34are each instanced only once and run on the same hardware component16, in particular on a single computer, and the diagnostic unit34checks the processing results of the safety functional unit32only in every nth sensor cycle by which the sensors14provide sensor data or in which they are processed. The runtime environment22for this purpose in particular carries out the safety functional unit32n times and only then the diagnostic unit34. This procedure is similar to a so-called test before demand.

Medium safety level: there is still only one respective copy of the safety functional unit32and of the diagnostic unit34. However, the frequency of the diagnosis is increased up to a check of every sensor cycle, where then the runtime environment invokes the diagnostic unit34every time after the safety functional unit32.

High safety level: two respective instances of the safety functional unit32and of the diagnostic unit34are now generated by the runtime environment that are assigned to different sub-nodes30or even better computing nodes26, and preferably thus also hardware modules16. This produces a twofold redundancy and thus a two-channel system and simultaneously a possible diversity. The diagnostic units34have short test cycles, preferably the same cycle as the safety functional units32. It is conceivable to carry out or to frequently intersperse cross-testing in which a diagnostic unit34monitors a different copy of the safety functional unit32or to compare the diagnoses of the diagnostic units34with one another.

Very high safety level :now, even more than two copies of the safety functional unit42and/or of the diagnostic unit34are generated. Depending on the specific embodiment, an at least three-channel system or generally a k-fold redundancy or diverse redundancy is thus produced. Otherwise, the same statements on the high safety level: also apply here.

The corresponding demands are communicated in the configuration file or are held there. This can take place directly from the outside to set a specific safety level by hand or on a separate demand. A situational adaptation of the safety level is particularly advantageous. In this respect, the safety device10determines, in particular by means of a suitable safety functional unit32, how the current hazard position is to be evaluated with reference to the sensor data and optionally to further information, in particular from the machine controller18, for example on a forthcoming workstep. This situational or context-related risk estimate is called a “behavior driven risk assessment”. There can be special events that have an influence on an appropriate safety level such as the special demand of a safety function, the closing of a job, or a maintenance demand. The runtime environment can then respectively set, even dynamically set, the new safety level via the described adaptations and can, where necessary, initiate logic units28, end them, or displace them between computing nodes26or sub-nodes30. An optimization using conditions such as an increased process efficiency or production efficiency is also conceivable.

The latter in particular applies when the runtime environment is not solely responsible for safety, but rather also uses the sensors14for non-safety relevant automation work.FIG.5shows a corresponding embodiment of the runtime environment22. A further logic unit26is added there, namely an automation unit38. In this respect, individual or several automation units38having any desired embodiments, in particular as explained with reference toFIGS.3and4, can be combined;FIG.5only shows a simple example respectively having a computing node26, a safety functional unit32, a diagnostic unit34, and an automation unit38.

An automation unit38is a logic unit28that monitors sensors14and machines12or parts thereof, generally actuators, and that controls (partial) routines on the basis of this information or provides information thereon. An automation unit38is in principle treated by the runtime environment like every logic unit23and is thus preferably likewise containerized. Examples for automation work include a quality check, variant control, object recognition for gripping, sorting, or for other processing steps, classifications, and the like. The delineation from the safety relevant logic units28consist of an automation unit38not contributing to accident prevention, i.e. to the safety relevant application. It accordingly also does not require any diagnostic unit34. A reliable working and a certain monitoring by the runtime environment22is nevertheless desired, but this serves an increase of the availability and thus of the productivity and quality, but not safety.

The architecture of the runtime environment22permits a seamless merging of safety and automation since safety relevant logic units32,34and automation units38can be performed in the same environment and practically simultaneously and can be treated in the same manner. In the event of a conflict, the runtime environment22preferably gives priority to the safety relevant logic units32,34, for instance in the event of scarce resources. Performance rules for the coexistence of safety relevant logic units32,34and automation units38can be taken into account in the configuration file.

FIG.6shows a schematic representation of a runtime environment22in an embodiment using Kubernetes. The runtime environment22is called a control plane here.FIG.6is based onFIG.3; the further embodiments explained with reference toFIGS.3to5can be implemented analogously in Kubernetes. The master24has a sub-structure in Kubernetes. The (Kubernetes) master24is still not itself responsible for the execution of containers or logic units28, but rather takes care of the general routines or the orchestration (orchestration layer). The configuration file is accordingly called an orchestration file. A database etcd40for all the relevant data of the Kubernetes environment, an API server24as an interface to Kubernetes, and a schedule and controller manager44that carries out the actual orchestration are furthermore present.

The hardware present is divided into nodes as computing nodes26. There are in turn one or more so-called pods as sub-nodes30in the nodes and the container having the actual micro-services are therein, in this case the logic units20together with the associated container runtime and thus all the libraries and dependences required for the logic unit28on the runtime. The local management performs a node manager unit38now divided into two with a so-called Kubelet36aand a proxy36b.The Kubelet36ais an agent that manages the separate pods and containers of the nodes. The proxy36bin turn includes the network rules for the communication between the nodes and with the master.

Kubernetes is a preferred, but by no means the only implementation option for the runtime environment22. Docker swarm could be named as one further alternative among many. Docker itself is not a direct alternative, but rather a tool for producing containers and thus combinable with Kubernetes and Docker swarm that then orchestrate the containers.