Control unit with a secure software component

Abstract

The invention relates to a control unit with a safe software component (12a) and a hardware component (14) for performing control and / or monitoring functions for safety-critical applications in automation technology, wherein the hardware component (14) is configured to output functional and diagnostic information.The hardware component (14) is not safe, in particular not certified or tested, wherein the safe software component (12a) has a safe interface (16) and safe function blocks (FBs) to communicate with the non-safe hardware component (14) and to read the function and diagnostic information, wherein the safe function blocks (FBs) are configured to use the diagnostic information to check the function information for errors and to output safety-related function information in order to form a safety controller (15a) for the safe execution of the control and / or monitoring functions.

Description

[0001] The invention relates to a control unit with a secure software component according to the preamble of claim 1.

[0002] Current technology in the field of safety controllers typically consists of a combination of hardware and software components that are jointly certified or type-tested to meet the required safety standards. A key challenge is that any change to the hardware or software usually requires recertification or type testing.

[0003] Known safety controllers can now only differ in the type and number of peripheral devices, such as I / O and communication interfaces, and represent different hardware derivatives. However, each hardware derivative requires separate certification or type testing, even if the different hardware derivatives share a common functional core. This can entail additional testing and validation effort.

[0004] The object of the invention relates to the provision of a control unit which, while avoiding the disadvantages known in the prior art, enables a more flexible use of a safety controller, in particular without recertifications.

[0005] The problem is solved using the features of claim 1.

[0006] Advantageous embodiments of the invention are specified in the dependent claims.

[0007] According to the invention, a control unit is claimed comprising a safe software component and a hardware component for performing control and / or monitoring functions for safety-critical applications in automation technology, in particular for machine and / or plant control, wherein the hardware component is designed to output functional and diagnostic information.The control unit includes a non-safe hardware component, which is not certified or tested, while the safe software component has a safe interface and safe function blocks to communicate with the non-safe hardware component and to read the function and diagnostic information, and the safe function blocks are designed to use the diagnostic information to check the function information for errors and to output safety-related function information in order to form a safety controller for the safe execution of the control and / or monitoring functions.

[0008] The invention offers the advantage that, when the hardware component is modified or replaced, recertification or type testing is advantageously unnecessary. This significantly reduces the costs and effort associated with testing procedures. Nevertheless, the safe operation of the control unit can be ensured by means of the safe software component, thus enabling the implementation of a safety controller. Specifically, the safe function blocks guarantee the safe execution of the control and monitoring functions by checking the functional information for errors. Advantageously, this allows for safe operation even with different hardware components using the same safe software component.

[0009] Preferably, the hardware component is qualified for safe operation but has not undergone certification and / or type testing. In particular, a portion of the hardware component may provide monitoring functions, especially for a CPU or power supply, which is considered suitable for safe operation. In other words, the hardware component is preferably qualified for safe operation. More preferably, the hardware component may have digital and / or analog inputs, especially connections for sensors and / or actuators. The functional and / or diagnostic information may consist of current and / or voltage signals, particularly from devices connected to the inputs. Alternatively or additionally, protocol information, such as fieldbus telegrams, may also be acquired by the hardware component.The hardware component provides an arbitrary input signal, from which the secure software component derives functional information and checks for errors accordingly.

[0010] Safe function blocks can be understood as software function blocks and / or function blocks according to the IEC 61131-3 standard. Preferably, the software component uses these safe function blocks to perform a check to identify valid or erroneous functional information. In particular, it can be checked whether the functional information behaves in the same way or in the opposite way to the diagnostic information. For example, the diagnostic information may change, but the functional information may not. As soon as a predefined large deviation is detected, an error can be inferred. As a result of the check, safety-related functional information can be output. This information, in particular, is information that, in the event of an error, causes the control unit to be brought into a safe state.In particular, the software initiates the deactivation of further function blocks arranged in a software chain, which in turn leads to the deactivation of the hardware component. If the function information can be successfully validated, it can be identified as safe and passed to further function blocks for the safe operation of the control unit.

[0011] According to a preferred embodiment, the hardware component is selected from a predefined hardware group with several hardware derivatives, wherein the derivatives of the hardware group have a common functional core and a defined non-safety hardware interface, and wherein the safe interface of the safe software component is preferably designed to read all hardware derivatives.

[0012] Using a predefined hardware group has the advantage that the software component can already be certified with regard to possible hardware derivatives. This simplifies certification or EC type examination for platform-based derivatives.

[0013] According to a preferred embodiment, the secure interface is designed as a secure hardware abstraction layer with safe function blocks to safely read the non-safety-related functional and diagnostic information of the hardware component and, in particular, to convert it into safety-related functional information. The hardware component itself has a non-safety-related hardware abstraction layer. The secure hardware abstraction layer preferably enables secure communication with the non-safety-related hardware component and the conversion of the functional and diagnostic information. This can increase the flexibility and safety of the control unit, as the secure interface ensures the integrity of the transmitted data.

[0014] In this context, it may be preferable for the secure hardware abstraction layer to be designed in such a way that it implements a defined interface that covers the possible hardware functions of the hardware component and possible derivatives of the hardware component.

[0015] Preferably, the control unit has predefined description files, where a hardware description file specifies the assignment and properties of signal lines and / or diagnostic lines of the hardware component. In particular, the hardware description file can, for example, specify which inputs are used and / or their number and properties.

[0016] For different hardware components, a derivative-specific hardware description file can preferentially specify which functionalities of a secure hardware abstraction layer can be used. Depending on the derivative, only a subset of the total available functionalities of the secure hardware abstraction layer may be used.

[0017] Preferably, a product device description file can specify which signal lines and / or diagnostic lines can be used by the secure software component. This particularly improves the adaptability and compatibility of the control unit with different hardware derivatives and applications.

[0018] Preferably, the hardware description file and / or the product description file are further provided for in an encrypted form. This increases the security of the control unit by preventing unauthorized access to and manipulation of the configuration data.

[0019] Preferably, the description files contain information about the software version for compatibility testing. Preferably, the files can be protected against corruption, in particular by means of suitable CRC checks or cyclic redundancy checks.

[0020] Preferably, the control unit may include an additional non-safety software component with non-safety function blocks to form a standard controller in conjunction with the hardware component for performing independent and non-safety control and / or monitoring functions, wherein resources of the hardware component, in particular inputs, outputs, memory, interfaces and / or LEDs, are assigned either to the standard controller or the safety controller.

[0021] Non-safe function blocks preferentially convert non-safe hardware information into non-safe software information. Optionally, non-safe hardware information can also be used for non-safe diagnostics. In an application, a preferential response to a non-safe diagnosis can be configured so that a transition to a safe state does not occur. An example would be the visual indication of a break in a signal line without terminating the associated function.

[0022] Preferably, the allocation of resources can be selected by an operator or is selectable by an operator. Particularly preferably, a predefined partition of the hardware component's memory can be selected and allocated.

[0023] In this context, it is preferred that the hardware description file specifies how functional information provided by the hardware component is evaluated and processed by the safe function blocks. This, in particular, ensures independent operation of the safe and non-safe software components.

[0024] It is particularly preferred that the safe and non-safe software components are implemented using separate operating systems and separate CPUs or separate CPU cores, which can be operated independently of each other. In particular, the operating systems can be operated independently of each other in terms of time and location. "Independent of each other" in this context means that the non-safe software component can read parameters of the safety controller without affecting the safe software component. Specifically, the non-safe part of the control unit has no influence on the safe operation, a safe state, or any effect on the execution of the safe software component.

[0025] Preferably, the secure and the non-secure operating systems can be based on a common secure RTOS (Real Time Operating System), with both operating systems using the same RTOS interfaces.

[0026] Furthermore, the invention also relates to a method for performing safe control and / or monitoring functions by means of a previously mentioned control unit, wherein preferably non-safe functional information and diagnostic information of the hardware component are checked for errors in order to implement control tasks safely.

[0027] According to a preferred embodiment of the method, resources of the hardware component, in particular inputs, outputs, memory, interfaces, and / or LEDs, can be assigned by an operator to either the safety controller or the standard controller, preferably with a predefined allocation selected for memory. In other words, the resources of the safety or standard controller are not permanently assigned but can be divided and allocated to one of the controllers by a user. Advantageously, the safety controller and the standard controller can be operated independently of each other with individual applications.

[0028] Furthermore, the invention preferably also relates to a system with a aforementioned control unit, which has a predefined hardware group, each of which can be read and controlled by the safe software component in order to form a safety controller.

[0029] The invention will now be explained in more detail using exemplary embodiments and with reference to the drawings.

[0030] They show schematically: Fig. 1: Block diagram of a control unit with software components and hardware components, Fig. 2: Block diagram of a resource allocation for a hardware component.

[0031] In the following description of preferred embodiments, identical reference numerals denote identical or comparable components.

[0032] The Fig. Figure 1 shows a control unit 10 with a non-safety hardware component 14, which interacts with a safe software component 12a to form a safety controller 15a. The separation between software and hardware is schematically represented by a horizontal dashed line. The hardware component has a non-safety hardware abstraction layer HAL-n to transmit functional and diagnostic information to a safe interface 16, specifically a safe hardware abstraction layer HAL-s of the software component 12a. The non-safety functional and diagnostic information is read and checked for errors by safe function blocks (FB-s). For example, the functional and diagnostic information can be compared, with discrepancies between the information indicating an error.The verified information can subsequently be converted into safety-related function information and used by further function blocks for safe control or in safety-related logic for the execution of safety functions. If errors are detected, the safe software component 12a switches to a safe state.

[0033] The hardware component 14 can preferably be selected from a predefined group of different hardware derivatives, wherein the hardware derivatives may share a common functional core 18. Hardware device requirements define the interfaces of the non-safety hardware derivatives that are available to a software side via the non-safety hardware abstraction layer. These requirements are encoded in a hardware description file and preferably include the assignment and properties of the functional signal lines and diagnostic lines provided by the hardware. Example of a hardware device requirement (physical description): Digital input − IO4 − 0 to 5 volts − 100 mA Imax − Function AD converter − AD2 − 0 to 10 volts − fixed 3 volts − Diagnostic Vsys − V7 − 3.3 volts − Function

[0034] Preferably, product-device requirements can define how the software component handles functional and diagnostic information provided by the hardware component. These requirements can be encoded in a product-device description file. Example of a product-device requirement (logical description): Digital input− IO4 − Monitor IO7− Fail− Channel offAD converter− AD2− 2 Volts<4 Volts − Channel offVsys− UV 3 Volts−OV 4 Volts − System off

[0035] Preferably, the control unit 10, in addition to the safe software component 12a, which forms a safety controller 15a with the non-safe hardware component 14, also includes a non-safe software component 12b, which forms a non-safe standard controller 15b with the non-safe hardware component 14. Preferably, the two software components 12a and 12b are operated independently of each other in terms of time and location. In other words, the non-safe software component 12b is separated from the safe software component 12a without any feedback effect, as illustrated by the dividing line T, in order to prevent any influence on the safety-critical functions of the safe software component 12a.

[0036] Preferably, the product device description file specifies how to handle functional and diagnostic information that is processed by one of the safe function blocks (FBs).

[0037] Preferably, the non-safe software component 12b includes non-safe function blocks FB-n for processing non-safe function information, wherein a non-safe function block FB-n also interacts with the safe hardware abstraction layer HAL-s.

[0038] A secure operating system OS-s of the secure software component 12a and a non-secure operating system OS-n of the non-secure software component 12b are preferably built on a common RTOS.

[0039] The Fig.Figure 2 shows an exemplary result of allocating resources of the hardware component 14 for use on the safety controller 15a (safe) or the standard controller 15b (non-safe). Preferably, manual resource allocation is enabled, in particular by selecting predefined options. Inputs and / or outputs (I / Os) of the hardware component 14, especially I / Os, LEDs, or memory, can be allocated as resources. While a free allocation of memory to the controllers is conceivable, it is preferable to select from a predefined allocation. In particular, a predefined allocation with predefined memory sizes can already be assigned to the different controllers. Reference symbol list 10 Control unit 12a,b secure software component 14 Hardware components 15a,b Safety control and standard control 16 secure interfaces 18 Functional core of the derivatives of a hardware group OS-s, OS-n secure and insecure operating system HAL's secure Hardware Abstraction Layer HAL-n non-safe Hardware Abstraction Layer FB-s secure function block FB-n unsafe function block T non-reactive separation Separation between software and hardware components

Images