Control unit having a secure software component

Abstract

The invention relates to a control unit having a secure software component (12a) and a hardware component (14) for carrying out control and / or monitoring functions for security-critical applications in automation technology, wherein the hardware component (14) is designed to output functional and diagnostic information. The hardware component (14) is not secure, in particular is not certified or checked, wherein the secure software component (12a) has a secure interface (16) and secure functional modules (FB-s) in order to communicate with the non-secure hardware component (14) and to read out the functional and diagnostic information, wherein the secure functional modules (FB-s) are designed to check the functional information for errors using the diagnostic information and to output security-related functional information in order to form a security controller (15a) for securely carrying out the control and / or monitoring functions.

Description

[0001] Control unit with a secure software component

[0002] The invention relates to a control unit with a secure software component according to the preamble of claim 1. Furthermore, the invention relates to a system with a control unit and a method.

[0003] 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 necessitates recertification or type testing.

[0004] Known safety controllers may only differ in the type and number of peripheral units for connecting sensors and / or actuators, such as I / O and communication interfaces, and thus 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.

[0005] Document DE 10 2018 120 347 A1 discloses a control system that proposes a safe runtime environment as a software layer on a potentially non-safe computing unit, such as a standard PC, to which a functionally safe peripheral module is connected. Two diverse user programs are used to detect errors in software processing, and their results are compared within the safe runtime environment. The system architecture is based on a clear separation between the process interface and the non-safe computing unit. The interface to the safety-critical process relies exclusively on the fail-safe peripheral module. Thus, input and output signals are already provided as fail-safe by this dedicated, safe, and qualified hardware.One disadvantage of this known control system is the high cost of providing two diverse user programs, as well as the need for a fail-safe peripheral assembly, which limits the flexibility in selecting and adapting peripheral components. Furthermore, EP 2 813 949 B1 discloses a system for error detection in multi-core processors, although this document addresses the problem of the processor's own internal fail-safety.

[0006] The object of the invention relates to the provision of a control unit, a system, and a method which, while avoiding the disadvantages known in the prior art, enables a more flexible use of a safety controller with an interchangeable peripheral unit, in particular without recertifications.

[0007] The problem is solved with the features of claim 1, with regard to the system with the features of claim 13 and with regard to the method with the features of claim 14.

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

[0009] According to the invention, a control unit comprising a safe software component and a hardware component for performing control and / or monitoring functions for safety-critical automation applications, particularly for machine and / or plant control, is claimed. The control unit includes a non-safe hardware component that comprises or is connected to a non-safe peripheral unit for connecting sensors and / or actuators. Preferably, the hardware component with the peripheral unit is neither certified nor tested.The non-safe peripheral unit is configured to output functional information and preferably diagnostic information, wherein the safe software component has a safe interface and safe function blocks to communicate with the non-safe hardware component and to read the functional information and preferably the diagnostic information provided by the non-safe peripheral unit, wherein the safe function blocks are configured to use the diagnostic information provided by and / or associated with the non-safe peripheral unit to check the functional information for errors and to output safety-related functional information in order to form a safety controller for the safe execution of the control and / or monitoring functions.Preferably, the peripheral unit is configured as at least one non-secure input and / or output, and / or one non-secure communication interface.

[0010] In this context, it is preferred that the hardware component is connected to the non-secure peripheral unit or provides an interface to it. This can include both integrated and externally connected peripheral units.

[0011] Preferably, non-safety sensors and / or actuators are connected to the peripheral unit as peripheral devices.

[0012] Preferably, the diagnostic information is read directly from the peripheral unit and provided by it.

[0013] Alternatively, or preferably additionally, the diagnostic information can be assigned to the peripheral unit. In particular, the control unit can have a configuration file containing the diagnostic information to verify the functional information.

[0014] Preferably, the configuration file can define the mapping and properties of the functional information and diagnostic information from the peripheral unit, in particular for the diagnostic information provided by the peripheral unit.

[0015] In other words, the invention preferably relates to a control unit configured for integrated plausibility checks to detect as an error any deviation between the state of the function signal and an expected state based on the diagnostic signal or associated diagnostic information. The safe software component is preferably configured as the sole or exclusive component for implementing the safety logic, and safe operation can be achieved without comparing the results of diverse user programs.

[0016] The invention offers the advantage that, in the event of changes to the hardware component, a replacement of the hardware component, or a further development of the hardware component with peripheral unit, recertification or type testing is advantageously not required. In particular, this reduces the costs and effort associated with testing procedures. Nevertheless, safe operation of the control unit can be ensured by means of the safe software component, and a safety controller can be implemented. Specifically, the safe function blocks guarantee the safe execution of the control and monitoring functions by checking the functional information for errors. Advantageously, this also enables safe operation for different hardware components using the same safe software component.

[0017] 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 results in the deactivation of the hardware component with its peripheral unit. 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.

[0018] The hardware component with peripheral unit can preferably have digital and / or analog inputs, in particular connections for sensors and / or actuators. The functional and / or diagnostic information can be current and / or voltage signals, especially from devices connected to the inputs of the peripheral unit. Alternatively or additionally, protocol information can also be acquired by the hardware component with a fieldbus communication interface, for example, fieldbus telegrams. The hardware component preferably provides any input signal, from which the safety software component derives functional information and checks for errors accordingly.

[0019] According to a preferred embodiment, the functional information originates from at least one first signal line of the non-safety peripheral device, and the diagnostic information originates from at least one second signal line of the peripheral device, distinct from the first. The verification process includes a software-based comparison of the functional signal with the diagnostic signal to monitor the integrity of the non-safety peripheral device. In other words, the integrity of the functional signal line of the connected non-safety peripheral device or the non-safety peripheral device itself is verified by an independent, separate diagnostic signal.

[0020] Preferably, the functional and diagnostic information can originate from a single external non-safety peripheral device, in particular a non-safety sensor, which is connected to both the first and second signal lines of the peripheral unit. Alternatively or additionally, the functional information can originate from a first external peripheral device connected to the first signal line of the peripheral unit, and the diagnostic information can originate from at least one second, separate external non-safety peripheral device connected to the second signal line of the peripheral unit.

[0021] A peripheral device is preferably understood to be a non-safety-sensitive sensor and / or actuator.

[0022] In other words, for example, a sensor can be connected via two cables, or multiple sensors can be connected: one provides the actual operating signal, while the other provides an additional control signal that confirms the plausibility of the operating signal or the correctness of the transmission. The safety software component reads both signals and compares them to detect, in particular, the integrity of the path from the external terminal of the peripheral unit to the CPU input within the hardware component.Preferably, the control unit has a predefined configuration file containing information readable by the control unit that identifies which of the signals provided by the non-safety peripheral unit are to be identified as functional information and which as diagnostic information, in order to adapt the safety software component to different versions of the non-safety peripheral unit. This has the advantage that the control unit can be operated for different non-safety peripheral units and their flexible interchangeability is enabled without recertification of the software component. Advantageously, this allows adaptation to different embodiments in the number and / or type of the at least one input and / or output and / or the communication interface of the peripheral unit.

[0023] Preferably, the configuration files may include a hardware description file that specifies the electrical characteristics of the first and second signal lines of the non-safe peripheral unit.

[0024] The configuration files are preferably divided into two main types, each describing different aspects of the peripheral unit, and their interaction forms the basis for flexible customization:

[0025] 1. Hardware description file (physical description):

[0026] This file describes the physical and electrical characteristics of the signal lines and / or diagnostic lines provided by the non-safety hardware component. It contains technical specifications relevant for the correct control and reading of the hardware.

[0027] • Example of a Hardware Device Requirement (Physical Description): o Digital Input - IO4 - 0 to 5 Volts - 100 mA Imax - Function: This specification defines a specific digital input channel of the hardware component, identified as IO4. It specifies physical properties such as the expected voltage range (0 to 5 volts) and the maximum permissible current (100 mA). A signal will be present at this physical pin, which can later be interpreted as a function signal. o A / D Converter - AD2 - 0 to 10 Volts - fixed 3 volts - Diagnostics: This specification describes an analog-to-digital converter (AD2) of the hardware component. It indicates that this converter is designed for an input voltage range of 0 to 10 volts. The note "fixed 3 volts" could describe an internal reference voltage or a specific measurement characteristic of the converter that is relevant at the hardware level.The signal at the A / D converter can be used as a function or diagnostic signal. Vsys - V7 - 3.3 Volts - Function: This specification defines a physical monitoring channel V7, which measures the system supply voltage (Vsys) and specifies its nominal value (3.3 volts).

[0028] 2. Product Device Description File (Logical Description):

[0029] This file specifies how the signals provided by the hardware component with the non-safety peripheral are interpreted and processed by the safe software component to generate functional and diagnostic information. It defines the logical role and linking of the signals, as well as the rules for plausibility checks. It enables the safe software to identify which of the signals supplied by the non-safety peripheral are functional information and which are diagnostic information.

[0030] • Example of a product-device requirement (logical description): o Digital input - IO4 - Monitor IO7 - Fail - Channel off (Variant 1: Digital function with digital diagnostics): This line instructs the safety software component to consider the signal from physical channel IO4 as the primary function signal. The signal from the separate physical channel IO7 is defined as a diagnostic signal for IO4, which checks its integrity (e.g., for a broken wire or short circuit). Preferably, a different physical channel is used for this purpose. If the safety software component detects an inconsistency between the function signal from IO4 and the diagnostic signal from IO7, a fault is recognized and the channel is safely switched off.Digital Input - 104 (Function) / AD2 (Analog Diagnostics) - Fail - Channel off (Variant 2: Digital Function with Analog Diagnostics): Additionally or alternatively, an analog signal can be configured as diagnostic information for a digital input. For example, the signal from physical channel 104 continues to serve as the digital function signal. A separate analog signal, acquired via an analog-to-digital converter (ADC) (e.g., AD2), serves as diagnostic information for 104. This analog diagnostic signal could, for example, measure the supply voltage of the sensor at the digital input, an ambient temperature, or another physical parameter whose value provides a plausibility statement about the state of digital input 104. In this case, the configuration file specifies that 104 is the function information and the analog signal from AD2 represents the corresponding diagnostic information.The safety software component then checks the consistency between the digital state of 104 and the analog diagnostic signal from AD2 to ensure the integrity of the digital input and the connected device. AD converter - AD2 - 2 volts < fixed < 4 volts - Channel off (Variant 3: Analog function with derived diagnostics): Here, the signal from physical channel AD2 is defined as the function signal (e.g., a measured value). The configuration file defines a plausibility range for this (e.g., between 2 volts and 4 volts), which serves as a criterion for generating the diagnostic information. The safety software component is instructed to check whether the value supplied by the AD converter is physically within this plausibility range. If the value is outside this predefined diagnostic information range, this deviation is interpreted as an error in accordance with the diagnostic information, whereupon the channel is safely switched off.This plausibility range represents a form of diagnostic information generated from the evaluation of the functional signal itself. It is therefore diagnostic information assigned to the peripheral unit. Additional limit values ​​or diagnostic procedures can be applied as a preferred additional safeguard, particularly in addition to safeguards provided by the peripheral unit itself. o Vsys - V7 - UV 3 Volts - OV 4 Volts - System off: This line defines the system supply voltage (Vsys), acquired via physical channel V7, as the functional signal. The diagnostic information here consists of status parameters (undervoltage and overvoltage thresholds) at 3 volts and 4 volts, respectively. If the measured system voltage falls below 3 volts or rises above 4 volts, a fault condition is detected. As a response, the entire system is safely shut down.Alternatively or additionally, this signal can also be used for diagnosis.

[0031] These examples illustrate how the configuration file plays a crucial role in communicating the precise design of the peripheral unit to the secure software component, thus enabling intelligent, software-based security logic. It should be emphasized that the aforementioned examples of using diagnostic information can also be combined.

[0032] Further implementation examples for the peripheral unit:

[0033] Sensor with multiple signal lines and comparison of multiple sensors: A non-safety peripheral unit can include a sensor connected via two separate physical cables to two different non-safety inputs of the hardware component. The configuration file preferably specifies that one of the signals is the primary function signal and the other is a redundant or supplementary control signal (diagnostic signal) of the same sensor. The safety software component reads both signals, performs a software-based comparison, and detects falsification if the signals are inconsistent. This enables verification of the entire signal path from the external terminal of the peripheral unit to the CPU input. Furthermore, the invention can also enable the comparison of function signals from several different sensors that measure the same physical quantity (e.g.,(Two temperature sensors at different positions, which should deliver similar values). The safety function blocks can compare these signals and detect a fault in case of deviations, thus providing an additional layer of safety.

[0034] Actuator with diagnostics and function (initial example): A control unit can also control an actuator via the non-safety-related peripheral unit. The function signal here would be the control command to the actuator (e.g., "Motor on," "Valve open"). Additionally, the actuator can send back diagnostic signals via one or more lines, describing its actual state or response (e.g., "Motor running," "Valve open," motor current draw). The configuration file instructs the safety-related software component to link these function and diagnostic signals. If the safety-related software component determines that the control command does not match the reported actuator response, an error is detected and a safe response is initiated.

[0035] Communication interface (fieldbus) with function and diagnostic data: A non-safety-based communication interface, such as a fieldbus like EtherCAT or PROFINET, can be integrated into the peripheral unit. The fieldbus transmits both the actual process data (function signals, e.g., sensor values, actuator commands) and fieldbus-specific diagnostic data (diagnostic signals, e.g., communication errors, device status, CRC errors). The configuration file defines which areas or fields of the received fieldbus telegrams are to be interpreted as function signals and which as diagnostic signals. The safety-related software component extracts this data and performs a software-based plausibility check. This allows, for example, the detection of whether a received sensor value is plausible even if the fieldbus telegram reports a communication error.This enables the safe use of standard, non-safety-related fieldbus components for safety-critical communication tasks, as the safety check is performed by software.

[0036] Alternatively, or preferably additionally, the control unit may have a predefined configuration file associated with the peripheral unit, which includes one of the following as diagnostic information, preferably in addition to the diagnostic information provided by the peripheral unit itself:

[0037] - a plausibility range for the function signal, wherein the verification includes detecting a deviation of the function signal outside this plausibility range; and / or

[0038] - a status parameter of the peripheral unit, where the check compares the consistency of the function signal with the status parameter.

[0039] A plausibility range for the function signal: In this case, the function signal itself is checked against a predefined, expected value range. The diagnostic information consists of knowing this range, which is assigned to the peripheral unit and is preferably accessible via a configuration file using the control unit. The check by the safety function blocks then includes detecting a deviation of the function signal outside this plausibility range. An example of this is the monitoring of an analog signal, which must lie within physically meaningful limits (e.g., 2V to 4V for a specific measured quantity). Exceeding or falling below this range is interpreted as an error.

[0040] A status parameter of the peripheral device: Here, the consistency of the function signal is compared with an internal status parameter of the peripheral unit. An example is monitoring the system supply voltage of the hardware component itself. The configuration file defines limits for undervoltage and overvoltage; if the system voltage falls outside these parameters, this is considered a critical fault that may require a safe system shutdown.

[0041] According to a preferred embodiment, the hardware component is selected from a predefined hardware group with several hardware derivatives, which include at least partially different peripheral units. The derivatives of the hardware group share a common functional core and a defined non-safety hardware interface, and the safe interface of the safe software component is preferably configured to read all hardware derivatives. The use of a predefined hardware group has the advantage that the software component can already be certified with respect to the possible hardware derivatives. This simplifies certification or EC type examination for platform-based derivatives.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

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

[0047] Preferably, the hardware description file and / or the product description file are encoded, in particular encrypted. This increases the security of the control unit by preventing unauthorized access to and manipulation of the configuration data. Preferably, the description files contain information about the software version for compatibility checks. Preferably, the files can be protected against corruption, in particular by means of suitable CRC checks or cyclic redundancy checks.

[0048] Preferably, the control unit may include an additional non-safety software component with non-safety function blocks to form a standard controller for performing independent and non-safety control and / or monitoring functions in conjunction with the hardware component, 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.

[0049] 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 preferred 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.

[0050] 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.

[0051] In this context, it is preferably intended that the hardware-

[0052] The 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.

[0053] 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.

[0054] 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.

[0055] Furthermore, the invention also relates to a system comprising a previously described control unit and a predefined hardware group with several hardware derivatives, which have at least partially different peripheral units, in particular different types and / or numbers of non-safe inputs and / or outputs and / or non-safe communication interfaces, wherein the derivatives of the hardware group have a common functional core and a defined non-safe hardware interface, wherein a safe interface of the safe software component of the control unit is designed for reading the functional and diagnostic information of all hardware derivatives.

[0056] Using a predefined hardware group has the advantage that the software component can already be certified with regard to the possible hardware derivatives.

[0057] In particular, the control unit has a configuration file and is designed to read it in order to enable flexible adaptation to the various hardware derivatives without requiring recertification of the secure software component.

[0058] 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.

[0059] Preferably the method comprises the following steps in a preferred order:

[0060] Providing a secure software component and a hardware component with a non-secure peripheral unit;

[0061] Configuring the secure software component using a configuration file, wherein the configuration file defines the mapping and properties of the functional information and diagnostic information from the peripheral unit;

[0062] Reading signals from the non-safe peripheral unit, which can be interpreted as functional and diagnostic information according to the configuration, and / or diagnostic information assigned to the peripheral unit and derived from the configuration file, by the safe software component. Preferably, this step relates to the reading by the safe software component of the signals provided by the peripheral unit, which are interpreted as functional and diagnostic information according to the configuration;

[0063] Performing a plausibility check of the functional information for errors using the diagnostic information via safe function blocks (FBs) of the safe software component to monitor the integrity of the non-safe peripheral unit; and

[0064] Generating and outputting safety-related functional information to form a safety controller for the safe execution of control and / or monitoring functions, particularly based solely on the result of the plausibility check. 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 by a user and allocated to one of the controllers. Advantageously, the safety controller and the standard controller can be operated independently of each other with individual applications.

[0065] 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.

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

[0067] They show schematically:

[0068] Fig. 1: Block diagram of a control unit with software-

[0069] Components and hardware components,

[0070] Fig. 2: Block diagram of a resource allocation of a

[0071] Hardware component.

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

[0073] 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, in particular 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.

[0074] Alternatively or additionally, the diagnostic information can be read from a configuration file assigned to the peripheral unit to check the functional information.

[0075] The hardware component 14 can preferably be selected from a predefined group of different hardware derivatives, wherein the hardware derivatives may have a common functional core 18. The hardware component 14 further comprises a non-safety peripheral unit 17, which preferably has a function line 19a and a diagnostic line 19b, which serve as connections for sensors and / or actuators and can provide the corresponding functional and diagnostic information. For example, a sensor can be connected with a first cable to a first input as function line 19a and with a second cable to a second input as diagnostic line 19b, wherein the signals of the function line 19a and the diagnostic line 19b are compared for verification.

[0076] Hardware device requirements define the interfaces of 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 mapping and properties of the functional signal lines and diagnostic lines provided by the hardware.

[0077] Preferably, product-devices can define requirements for the software component regarding how it handles functional and diagnostic information provided by the hardware component. These requirements can be encoded in a product-device description file.

[0078] 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.

[0079] 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).

[0080] 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.

[0081] 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.

[0082] 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, particularly by selecting predefined options. Inputs and / or outputs (IOs) of the hardware component 14, especially IOs, 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.

[0083] Reference symbol list

[0084] 10 Control unit

[0085] 12a, b secure software component

[0086] 14 Hardware components

[0087] 15a,b Safety control and standard control

[0088] 16 secure interfaces

[0089] 17 Peripheral unit

[0090] 18 Functional core of the derivatives of a hardware group

[0091] 19a, 19b Functional and diagnostic management

[0092] OS-s, OS-n secure and insecure operating system

[0093] HAL's secure Hardware Abstraction Layer

[0094] HAL-n non-safe Hardware Abstraction Layer

[0095] FB-s secure function block

[0096] FB-n unsafe function block

[0097] T non-reactive separation

[0098] Separation between software and hardware components

Claims

Patent claims 1. Control unit with a safe software component (12a) and a hardware component (14) for performing control and / or monitoring functions for safety-critical automation applications, characterized in that the control unit (10) has a non-safe hardware component (14) which is in particular not certified or tested; wherein the hardware component (14) comprises or is connected to a non-safe peripheral unit (17) for connecting sensors and / or actuators, wherein this peripheral unit (17) in particular has at least one non-safe input and / or output and / or a non-safe communication interface; wherein the non-safe peripheral unit (17) is configured to output functional information and preferably diagnostic information;wherein the safe software component (12a) has a safe interface (16) and safe function blocks (FBs) for communicating with the non-safe hardware component (14) and for reading the functional information and preferably the diagnostic information provided by the non-safe peripheral unit (17); and wherein the safe function blocks (FBs) are configured to check the functional information for errors using diagnostic information provided by and / or associated with the non-safe peripheral unit (17) and to output safety-related functional information in order to form a safety controller (15a) for the safe execution of the control and / or monitoring functions.

2. Control unit according to claim 1, characterized in that, that the functional information is derived from at least one first signal line (19a) of the peripheral unit (17) and the diagnostic information is derived from at least one second signal line (19b) of the peripheral unit (17), different from the first, and that the verification includes a software-based comparison of the functional signal with the diagnostic signal to monitor the integrity of the non-safety hardware component (14).

3. Control unit according to claim 2, characterized in that the functional information and the diagnostic information originate from a single external non-safe peripheral device, in particular a non-safe sensor, which is connected to both the first signal line (19a) and the second signal line (19b) of the peripheral unit (17); and / or the functional information originates from a first external peripheral device which is connected to the first signal line (19a) of the peripheral unit (17), and the diagnostic information originates from at least one second, separate external non-safe peripheral device which is connected to the second signal line (19b) of the peripheral unit (17).

4. Control unit according to one of claims 1 to 3, characterized in that the control unit (10) has a predefined configuration file which contains information readable by means of the control unit (10) which of the signals provided by the non-safe peripheral unit (17) are to be identified as functional information and which as diagnostic information in order to adapt the safe software component (12a) to different configurations of the non-safe peripheral unit (17).

5. Control unit according to one of claims 1 to 4, characterized in that, that the control unit (10) has a predefined configuration file that is assigned to the peripheral unit (17) and includes, as diagnostic information, preferably in addition to the diagnostic information provided by the peripheral unit (17) itself, one of the following: - a plausibility range for the function signal, wherein the verification includes detecting a deviation of the function signal outside this plausibility range; and / or - a status parameter of the peripheral unit (17), wherein the check compares the consistency of the function signal with the status parameter.

6. Control unit according to one of claims 1 to 5, characterized in that the safe interface (16) is designed as a safe hardware abstraction layer (HAL-s) with safe function blocks (FB-s) to safely read and convert the non-safe functional and diagnostic information of the hardware component (14), wherein the hardware component (14) has a non-safe hardware abstraction layer (HAL-n).

7. Control unit according to one of claims 1 to 6, characterized in that the control unit (10) has predefined description files, wherein a hardware description file specifies an assignment and properties of functional signal lines and / or diagnostic lines of the non-safe peripheral unit (17), wherein a product device description file specifies which of the signal lines and / or diagnostic lines can be used by the safe software component (12a).

8. Control unit according to claim 7, characterized in that the hardware description file and / or the product description file are encoded, in particular encrypted.

9. Control unit according to one of claims 1 to 8, characterized in that the control unit (10) comprises an additional non-safety software component (12b) with non-safety function blocks (FB-n) to form a standard controller (15b) in conjunction with the hardware component (14) for performing independent and non-safety control and / or monitoring functions, wherein the resources of the hardware component (14) are assigned either to the standard controller (15b) or to the safety controller (15a).

10. Control unit according to claims 7 and 9, characterized in that the hardware description file specifies how functionalities provided by the hardware component (14) are evaluated, which are handled by safe function blocks (FBs).

11. Control unit according to claim 9 or 10, characterized in that the safe and the non-safe software components (12a,b) are designed by means of separate operating systems (OS-s, OS-n) and separate CPUs or separate CPU cores which can be operated or are operated without interference with each other.

12. Control unit according to claim 11, characterized in that the secure and the non-secure operating system (OS-s, OS-n) are based on a common secure RTOS (Real Time Operating System) and wherein both operating systems (OS-s, OS-n) use the same RTOS interfaces.

13. System comprising a control unit (10) according to one of claims 1 to 12, and a predefined hardware group with several hardware derivatives, which have at least partially different peripheral units (17), in particular different types and / or numbers of non- safe inputs and / or outputs and / or non-safe communication interfaces, wherein the derivatives of the hardware group have a common functional core (18) and a defined non-safe hardware interface (HAL-n), wherein a safe interface (16) of the safe software component (12a) of the control unit (10) is designed for reading the functional and diagnostic information of all hardware derivatives.

14. Method for performing safe control and / or monitoring functions by means of a control unit (10) according to any one of claims 1 to 12, comprising the steps: - Providing a secure software component (12a) and a hardware component (14) with a non-secure peripheral unit (17); - Configuring the secure software component (12a) using a configuration file, wherein the configuration file defines the mapping and properties of the functional information and diagnostic information of the peripheral unit (17); - Reading by the safe software component (12a) of signals from the non-safe peripheral unit (17) which can be interpreted as functional information and diagnostic information according to the configuration, and / or of diagnostic information that is assigned to the peripheral unit (17) and originates from the configuration file; - Performing a plausibility check of the functional information for errors using the diagnostic information provided by and / or assigned to the peripheral unit (17) by means of safe function blocks (FBs) of the safe software component (12a) to monitor the integrity of the non-safe peripheral unit (17); and - Generating and outputting safety-related functional information to train a safety controller (15a) for the safe execution of the control and / or monitoring functions.

Images