SAFE TECHNICAL MODULE

Description

[0001] The invention relates to a module for generating operation, monitoring, and / or automation through a control system for a technical plant. The invention also relates to a control system for a technical plant, in particular a process or manufacturing plant. Furthermore, the invention relates to a technical module comprising a plurality of technical devices and a computer-implemented module inventory, which technical module is configured for integration into a control system for a technical plant, in particular a process or manufacturing plant.

[0002] Particularly in the pharmaceutical and specialty chemicals industries, operators of technical plants face high demands for the ability to react quickly to changing market requirements. Modular plants enable plant operators to significantly shorten the so-called "time-to-market" and to respond quickly to changing market conditions through cost-effective plant modifications. Plant operators can build up a pool of modular units (e.g., process units) with which they can assemble a specific plant using a process called orchestration. If the plant needs to be modified, individual modules or package units are removed and replaced with others, for example, more powerful modules or package units.

[0003] In this context, a technical module or package unit is understood to be a part of a technical plant that can be integrated as a self-contained unit into the central engineering of a control system for that plant. Modules are more comprehensive than individual measuring points or technical devices. A module can also encompass a sub-plant with a complete process engineering structure, including several technical devices (e.g., tanks), which in turn contain several measuring points (e.g., valves, monitors, controllers, motors, etc.).

[0004] Document WO 2016 / 074730 A1 describes a method for creating a modular technical system using self-description information from the modules. This method is based on online self-description information for the individual modules.

[0005] EP 3 851 924 A1 discloses a control system for a technical plant, in particular a manufacturing or process plant, which is designed and intended to initiate the issuance and revocation of certificates for components of the technical plant within the framework of certificate management.

[0006] The "black box" approach of technical modules means that the internal structure with the installed technical equipment remains hidden from the user - interaction with the module is limited - in the case of a module for a process plant - to the process connections and the interface for orchestration.

[0007] Within the module and for all necessary external interactions, it is recommended to use secure communication (for example, using OPC UA). This means that each installed device requires the appropriate certificates. According to current security recommendations, these certificates should be issued and signed by a trusted Certificate Authority (CA) and not be self-signed (i.e., issued and signed by the individual devices themselves).

[0008] Due to the "black box" approach, the user is generally unable to verify the identity and originality of the technical devices installed in the module. Therefore, for example, they cannot be certain that a module does not contain a manipulated device that could cause damage when the module is operating in the environment.

[0009] If the manufacturer of the technical module, using its trusted certification authority, has issued and assigned the certificates required for secure communication to the installed devices, the (recommended for security reasons) regular renewal of these certificates during the module's operation by the user can only be carried out using the same certification authority and thus only with the manufacturer's involvement. Similarly, when replacing a device, the replacement should be equipped with the necessary certificates for secure communication after appropriate testing. In most cases, however, there is no connection between the operating environment and the manufacturer.

[0010] The devices installed in a technical module (such as industrial PCs, PLCs, sensors, actuators, HMIs, and peripherals) often have secure digital identities in the form of so-called "Initial Device Identifiers" (IDevIDs), which are transferred to the devices by the manufacturer during the module's production. According to the IEEE 802.1AR standard, such an Initial Device Identifier comprises a private key (secret key) securely stored within the device. It also includes the associated IDevID certificate (represented by an X.509 certificate, which contains, among other things, the corresponding public key) and the associated certificate chain. The certificate chain, acting as the manufacturer's trust anchor, includes the certificate of the Certification Authority (CA) that issued the IDevID certificate and the certificates of all higher-level intermediate certification authorities.Intermediate CAs) up to the root certification authority (Root CA).

[0011] By validating a secure digital identity (often referred to as proof of originality), it is possible to verify, using an appropriate procedure (in the simplest case, for example, the TLS handshake), whether the device in question is an original device whose ID and public key correspond to the private key securely stored in the device, as well as to its other data in the IDevID certificate.

[0012] Even assuming that the manufacturer producing a technical module has verified the identity / originality of individual devices using their IDevIDs, there is still a risk of undetected and unauthorized exchange or manipulation of the automation devices within the technical module, both during transport to the actual place of use of the technical module, during commissioning / integration at the user's site, and during operation at the user's site.

[0013] This problem is exacerbated by the fact that users generally do not know exactly which devices are installed within the technical module. For example, if devices belonging to a specific manufacturer's product family are recalled (e.g., due to a root CA compromise), the user does not necessarily connect this information with a technical module they operate that contains such a device.

[0014] According to the current state of the art, it is possible for the manufacturer / OEM who produces a technical module and integrates various devices into it to have the necessary application-specific certificates (which are particularly required for OPC UA communication) issued by a manufacturer / OEM PKI (including the so-called issuing CA) and deploy them to the devices. This ensures that secure communication between the integrated devices is possible using these certificates. Since the validity period of these certificates (which, according to current recommendations, is preferably a maximum of two months) can expire before commissioning or during operation of the technical module in the respective operating environment, there should be a way to renew the certificates (for example, two weeks before their expiry date).

[0015] The invention is based on the objective of providing a simple yet safer method for generating an operating and monitoring system for a technical plant by incorporating a technical module.

[0016] This problem is solved by a method for generating operation and monitoring and / or automation through a control system for a technical plant, in particular a manufacturing or process plant, according to claim 1. Furthermore, the problem is solved by a control system for a technical plant, in particular a process or manufacturing plant, according to claim 6. In addition, the problem is solved by a technical module comprising a plurality of technical devices and a computer-implemented module inventory, which technical module is configured for integration into a control system for a technical plant, in particular a process or manufacturing plant, according to claim 7.

[0017] An inventive method for generating operation and monitoring and / or automation by means of a control system for a technical plant, in particular a manufacturing or process plant, wherein the control system comprises an operator station server and an operator station client, comprises the following method steps: a) Integration of a technical module, which constitutes a self-contained technical unit, into the control system acting as a higher-level control system, wherein the technical module comprises a plurality of technical devices, a computer-implemented module inventory, and an interface, in particular designed as OPC UA, wherein, as part of the integration, the control system retrieves information from the computer-implemented module inventory of the technical module via the interface and stores it in a computer-implemented control system inventory of the control system, implemented separately from the technical module, which information is designed for the identification of the technical devices of the technical module by the control system, and which information comprises certificates by means of which the identification of the respective technical device can be carried out, b) Generation of operation and monitoring,and / or the automation of the technical system, taking into account the information of the technical module stored in the computer-implemented control system inventory.

[0018] A technical module is understood to be a self-contained technical unit that can be integrated into a higher-level control system. Such a technical module could, for example, be a group of several measuring points or a larger component of an industrial plant. However, the technical module does not necessarily have to originate from the field of industrial plants; it could also be, for example, an engine module of a car, a ship, or the like.

[0019] In this context, a control system is understood to be a computer-aided, technical system that includes functionalities for operating, monitoring, and controlling a technical manufacturing or production plant. In this case, the control system comprises sensors for acquiring measured values ​​and various actuators. Furthermore, the control system includes so-called process- or production-related components that serve to control the actuators and sensors. In addition, the control system includes, among other things, means for visualizing the technical plant and for engineering purposes. The term "control system" also encompasses additional computing units for more complex control systems and systems for data storage and processing.

[0020] Automation refers to the independent (automated) acquisition and manipulation of physical quantities using technical means within a control system. This typically enables machines, systems, or other equipment to operate autonomously. Automation includes at least the parameterization of the system's components and the interaction of these components with one another.

[0021] According to the invention, the computer-implemented module inventory contains information designed to identify the technical devices of the technical module. During the integration of the technical module into the control system, this information is read from the module inventory of the technical module by the control system via a suitable interface, for example, an OPC UA server implemented on the technical module, and transferred to a control system inventory. Using the retrieved information, the control system generates the operating and monitoring visualizations that an operator can use to operate and monitor the technical system, and in particular the technical module.Alternatively or (usually) additionally, the control system also generates automation for the technical system, taking into account the information received regarding the individual technical devices of the technical module.

[0022] According to the invention, the information includes certificates that can be used to identify and verify the authenticity or identity of the respective device. This identity or authenticity verification can be performed in interaction with the respective technical device. The control system can automatically evaluate the validity of these certificates and, if one of the certificates is invalid, exclude the technical module from operation, monitoring, or automation within the technical system.

[0023] The certificates may have been issued by a certification body of the manufacturer of the technical module. However, it is also possible that the technical module has its own certification body, which has issued the identity-verifying certificates for the individual technical devices.

[0024] Preferably, the information includes certificate chains for the technical devices, each containing a certificate from the certification authority that issued the respective certificate for the respective technical device, as well as all higher-level certification authorities. If the certificates of the technical module were issued by an internal certification authority, the corresponding certificate chain can be transmitted to the control system to enable it to perform certificate validation according to RFC 5280.

[0025] In this preferred scenario, the certificates for the devices integrated into the technical module are obtained via a suitable interface from a certification authority of the control system or the technical installation. In this case, the effort required for the integrity-protected transmission of the so-called "Root CA" certificate to communication partners of the technical module is eliminated, as they all use the same certification authority.

[0026] The information preferably includes a specific firmware version, a serial number, a need for an operating software update, a manufacturer's name, a device family, an IP address, a MAC address, a time of an authenticity check and / or a time of a manually performed identification of the respective technical device.

[0027] The task is also solved by a control system for a technical plant, in particular a process or manufacturing plant, which is designed to carry out a procedure as previously explained.

[0028] Furthermore, the task is solved by a technical module comprising a plurality of technical devices, an interface (specifically OPC UA), and a computer-implemented module inventory. This technical module is designed for integration into a control system, as previously described, for a technical plant, particularly a process or manufacturing plant. The computer-implemented module inventory of the technical module contains information that allows the control system to identify the technical devices within the module by retrieving this information via the interface. This information includes certificates that enable the identification of each individual technical device.

[0029] The information includes certificates, which (and their associated private key, securely stored in the respective technical device, or secret key corresponding to the public key contained in the certificate) allow for the identification of the respective device. Identity / authenticity verification is generally not performed solely through certificate verification. It typically includes an additional step in which the device proves that it knows the private key corresponding to the public key contained in the certificate. The control system can automatically evaluate the validity of these certificates and, if a certificate is invalid, disable the technical module from operation, monitoring, or automation of the technical system.

[0030] The certificates may have been issued by a certification body of the manufacturer of the technical module. However, it is also possible that the technical module has its own certification body, which has issued the identity-verifying certificates for the individual technical devices.

[0031] The information particularly preferably includes certificate chains for the technical devices, each comprising a certificate from the certification body that issued the respective certificate for the respective technical device, as well as all higher-level certification bodies.

[0032] Preferably, the information includes so-called certificate revocation lists (CRLs) for the technical devices, each issued by the certification authority that issued the respective certificate for that technical device. These CRLs contain certificates that have been revoked, i.e., declared invalid, by the respective certification authority.

[0033] As part of a preferred further development of the technical module, the information fulfills the structural and content requirements of VDI / VDE / NAMUR Guideline 2658 as amended at the time of filing of the present patent application. This means, among other things, that in addition to the identification information regarding the technical devices installed in the technical module, the information includes the following components: Plant diagrams (in a standardized format) provided by the control system for operating and monitoring the technical equipment contained in the technical module, and visualized by an operator station client of the control system; an interface description of the technical module for operating, monitoring, and automating the technical module in conjunction with other plant components, which may include process values, alarms, and services; a structural description of the technical module, for example, various process engineering areas such as a buffer tank, a reactor, a mixer, and the like. The plant diagrams and interfaces are then mapped accordingly to the structural description—for example, a signal to control the mixer is offered to the operator via a plant diagram of the mixer.

[0034] This structure, already known as "Module Type Package" according to VDI / VDE / NAMUR guideline 2658, is extended in the present invention to include identity-indicating information. This information can include the following: Manufacturer (e.g., Siemens) Device family (e.g., S7-1500 CPU) Device ID, e.g., serial number (e.g., XYZ) Hardware version (e.g., 10007) Firmware version (e.g., R29.44.53_00.00.00.00) IP address (e.g., 172.27.232.44) MAC address (e.g., 28:63:36:8D:C4:2A) IDevID certificate (if available) (e.g., stored as a CER / DER file) LDevID certificates (if available), such as the device-specific LDevID generic certificate or various application-specific LDevID app certificates, which were issued for the device in the operating environment (more precisely, by the Public Key Infrastructure (PKI) operated within the module or within the operating environment, i.e., the technical system) or by a comparable service for various purposes and are automatically (e.g., using a standardized mechanism such as OPC UA GDS Push / Pull or a protocol such as Certificate Management Protocol (CMP) ) or were manually applied to the device.The individual PKI components (e.g., a registration authority or a local registration service, whose role can be assumed by the OPC UA Global Discovery Server, for example) can be located within and / or outside the technical module and can be operated by the plant operator / an appropriate service provider. "Proof of Originality," abbreviated "PoO" (e.g., 08:32, 28.12.2022), refers to the point in time of the so-called originality check, which typically includes the validation of the device's IDevID certificate and thus its identity / originality. This check can be performed with or without user support and is, for example, a mandatory step in the Secure Device Onboarding process. "Identification" (e.g., 09:33, 28.12.2022) as the point in time for device identification, which can be carried out, for example, by scanning the QR code printed on the device's casing (performed, for instance, by an authorized user). During this process, the device data can be read and displayed to the user, who can then compare it with the available information. It is important to note that while a device can assert its identity during identification, it cannot prove it (as with the Proof of Originality explained above). Therefore, this option is considered less robust from a cybersecurity perspective. For existing or legacy devices, it is highly recommended from a security standpoint to at least enable, or even enforce, user-assisted identification.

[0035] Preferably, the technical module includes a computer-implemented registration service which is designed to determine information regarding the technical equipment within the technical module, either upon manual request or automatically at specific times or in response to events, and to store this information in the computer-implemented module inventory.

[0036] In addition to the aforementioned identity verification, the computer-implemented registration service can include further appropriate, potentially configurable verification steps. For example, specific comparisons of the device's technical data / characteristics with a reference device can be performed both during commissioning and during device replacement. The registration process can be triggered either automatically (for example, by the installed devices finding the registration service, perhaps using a suitable discovery method such as mDNS or using pre-configured address data) or by a user.

[0037] The registration service can also determine information regarding the technical devices, perform an identity or originality check of the devices, and store the information regarding the technical devices, including a status of the identity / originality check and / or a corresponding flag, in the computer-implemented module inventory, either based on a manual request, due to the replacement of one of the technical devices, or automatically at specific times or event-driven within the technical module.

[0038] The registration service is specifically designed to be triggered by the replacement of any technical device within the technical module. This triggers the service to retrieve information about the device and store it in the computer-implemented module inventory. A trigger for calling the registration service can therefore be a detected and reported device replacement during the operation of the technical module or system, in which case the replacement device installed in the module should be registered. If it is determined that a device installed (for example, during initial commissioning or a device replacement) has an invalid and / or expired IDevID certificate, the user is informed accordingly, or a corresponding policy is taken into account when triggering another appropriate action.If the identity verification using the IDevID certificates of the installed devices is successful, all devices along with their verified certificates will be included in the module inventory.

[0039] The properties, features, and advantages of this invention described above, as well as the manner in which they are achieved, will become clearer and more readily understandable in connection with the following description of exemplary embodiments, which are explained in more detail in conjunction with the drawings. The drawings show: FIG 1 a technical module according to the invention in a schematic representation; FIG 2 an object model of the technical module; and FIG 3 a guidance system according to the invention in a schematic representation.

[0040] In FIG 1 Technical module 1 is shown, comprising a server 2, a visualization device 3, an automation device 4, peripheral devices 5a, 5b, 5c, and a number of sensors and actuators 6. Furthermore, technical module 1 has connections 7a, 7b for connection (e.g., in process engineering) to other technical modules or to components of a technical system, such as a process plant. Technical module 1 also has an interface 8.

[0041] The technical module 1 can be connected to a higher-level control system such as a control system via interface 8 (see...). FIG 3 ) can be connected. Interface 8 can, for example, include an OPC UA server, which can be used for the software integration of the technical module 1 into the control system.

[0042] In technical module 1, for example in server 2, a module inventory 9 is implemented in a computer system. This module inventory 9 of technical module 1 contains information that allows the control system to identify the technical devices 2, 3, 4, 5a, 5b, and 6 of technical module 1.

[0043] The information fulfills the structural and content requirements of VDI / VDE / NAMUR Guideline 2658 as amended at the time of filing of the present patent application. An object model of the information relating to technical module 1 is provided in FIG 2 As shown in the VDI / VDE / NAMUR 2658 guideline, the description 10 of the technical module 1 includes plant diagrams 11, interfaces 12 and a rough structural outline 13 of the technical module 1.

[0044] Additionally, the description includes an inventory 14 of the technical equipment 2, 3, 4, 5a, 5b, 6 of technical module 1. The inventory 14 includes a list 15 of all equipment 2, 3, 4, 5a, 5b, 6 contained in technical module 1, which list 15 enables a control system connected to technical module 1 to identify the technical equipment 2, 3, 4, 5a, 5b, 6 of technical module 1.

[0045] In FIG 3 Figure 16 schematically depicts a control system 16 for the operation and monitoring of a technical plant designed as a process plant. The control system 16 comprises an operator station server 17 and an operator station client 18. The operator station server 17 and the operator station client 18 are connected to each other via a terminal bus 19 and optionally to other components of the control system 16 (not shown), such as an archive server.

[0046] For the purpose of operation and monitoring, a user or operator can access the Operator Station Server 17 via the Terminal Bus 19 using the Operator Station Client 18. The Terminal Bus 19 can be configured as, for example, Industrial Ethernet, but is not limited to this.

[0047] The Operator Station Server 17 has a device interface 20 and an OPC UA server 21, which is connected to a plant bus 22. Via the device interface 20, the Operator Station Server 17 is connected to an automation device 23 and to other components of the process plant, such as peripheral devices 24, and can communicate with them. These other components are located outside the technical module 1. The technical module 1 is connected to the other components 24 of the technical plant via the process connection 7b (removable). The plant bus 22 can be configured as, for example, Industrial Ethernet, but is not limited to this.

[0048] The Operator Station Server 17 also includes a visualization service 25, a process image 26, an orchestration service 27, and a certificate monitoring service 28. The process image 26 contains a snapshot of the (signal) states of the connected devices 24 and / or applications. The orchestration service 27 is configured for the (software-based) integration of the technical module 1 into the operation, monitoring, and automation of the technical plant. In other words, the orchestration service 27 performs the orchestration, i.e., the control of the technical module 1 and its coordination with the technical (process engineering) plant. For orchestration, the process values ​​and services of the technical module 1 are read and written by the orchestration service 27 via the process image 26 of the Operator Station Server 17 and the OPC UA Server 21.The operator controls and monitors the system via the Operator Station Client 18, which visualizes the necessary system images for operation and monitoring, both for Technical Module 1 and for the remaining parts of the (process) plant. The Certificate Monitoring Service 28 monitors the validity of the certificates for the technical devices 2, 3, 4, 5a, 5b, 5c, and 6 of Technical Module 1, which will be discussed in more detail later. The plant also includes a Certification Authority 29 and a Control System Inventory 30.

[0049] The visualization service 25 integrated in the Operator Station Server 17 initiates a transmission of visualization information to the Operator Station Client 18. The Operator Station Client 18, in turn, is designed to display a visualization, i.e., a graphical representation, in particular of plant images and hierarchies, for operating and monitoring the process plant.

[0050] As previously explained, a module inventory 9 is computer-implemented in technical module 1. This module inventory 9 contains information that enables the control system to identify the technical devices 2, 3, 4, 5a, 5b, and 6 of technical module 1. Technical module 1 also includes a computer-implemented registration service 31, a certificate management service 32, a monitoring service 33, and a module certification authority 34 integrated within the technical module.

[0051] Registration service 31 is designed to determine, verify, and validate the identity of the technical devices 2, 3, 4, 5a, 5b, and 6 present in the technical module. This is done, for example, using their DevID certificates. These can be, for instance, the IDevID Manufacturer certificates issued by the manufacturer of technical module 1 or the LDevID OEM certificates issued by the OEM. The identities of the technical devices 2, 3, 4, 5a, 5b, and 6, along with their certificates, are stored by registration service 31 in the module inventory 9. In addition to the aforementioned identity verification, the registration service can perform further appropriate, and potentially configurable, verification steps. For example, during commissioning and during device replacement at runtime, certain comparisons of the technical data / properties of the technical devices 2, 3, 4, 5a, 5b, and 6 with a reference device can be carried out.When replacing a device during operation, the role of the reference device is taken over, for example, by the originally installed device that is to be replaced.

[0052] The registration process can be triggered automatically. This occurs, for example, when the installed devices detect the registration service 31, using a suitable discovery method such as mDNS or pre-configured address data, and transmit the identification data to it. Alternatively, the process can also be triggered by a user or by another process.

[0053] Another trigger for calling the registration service 31 can be a device replacement detected and reported by the monitoring service 33 during the runtime of technical module 1, in which the replacement device integrated into technical module 1 is to be registered. If it is determined that a technical device 2, 3, 4, 5a, 5b, 5c, 6 installed (for example, during initial commissioning or device replacement) has an invalid and / or expired IDevID certificate, the user is informed accordingly, or a corresponding policy is taken into account when triggering another appropriate action. If the identity verification using the IDevID certificates of the installed technical devices 2, 3, 4, 5a, 5b, 5c, 6 is successful, all technical devices 2, 3, 4, 5a, 5b, 5c, 6, along with their verified certificates, are added to the module inventory 9.

[0054] Module Inventory 9 represents an overview of the technical devices 2, 3, 4, 5a, 5b, 5c, 6 installed in Technical Module 1, including their IDevID and LDevID certificates (where the LDevID certificates can include both device-specific LDevID Generic certificates and application-specific LDevID App certificates). After its initial creation, Module Inventory 9 is continuously updated throughout the entire lifecycle of Technical Module 1 with the certificates (issued by the OEM during package unit assembly and by the user during commissioning / orchestration). In addition to device-specific data and certificates, Module Inventory 9 also records the status of the last identity verification. For example, the identity verification performed by the OEM is listed as "Proof of Initial Device Identity," and the verification performed by the user is listed as "Proof of Initial Device Identity."The test performed in the user's operating environment as part of the orchestration is referred to as "Proof of Locally-Significant OEM Device Identity".

[0055] Certificate Management Service 32 is primarily responsible for deploying a module-specific or deployment environment-specific LDevID Generic certificate. This certificate is requested either from the internal certification authority 34 integrated into the technical module or from the certification authority 29 of the technical system into which the technical module 1 is integrated. Furthermore, this service is also responsible for initiating certificate renewal or revocation for technical devices 2, 3, 4, 5a, 5b, 5c, and 6, based on the monitoring status reported by Monitoring Service 33, and for reporting the renewed / revoked certificates to Module Inventory 9.

[0056] To enable the deployment of device-specific and application-specific certificates, the technical module 1 provides the certification authority 34 (possibly with associated certification services) and a suitable interface, the OPC UA interface 8, through which the technical module 1 can be integrated into the respective deployment environment (and, in particular, into the public key infrastructure operated within that environment). Ideally, the aforementioned interface 8 is activated by establishing a certificate-based trust relationship between the registration service 31 and the certification authority 29 of the user's deployment environment. Establishing this trust relationship can be performed by the user during the orchestration of the technical module 1.It is important to note that each technical module 1 typically has at least one certificate-based communication relationship with devices outside of technical module 1.

[0057] If the certificate used to secure this communication relationship of technical module 1 was issued by the internal certification authority 34, the corresponding certificate chain including the integrity-protected root CA certificate should be transmitted to the communication partners of technical module 1 to enable them to perform certificate validation according to RFC5280.

[0058] Alternatively, the certificates for the technical devices 2, 3, 4, 5a, 5b, 5c, 6 installed in the technical module are obtained from the user's certification authority 29 via the interface 8 described above. In this case, the effort required for the integrity-protected transmission of the root CA certificate to the communication partners is eliminated, as they use the same public key infrastructure.

[0059] Following a successful identity verification of the individual installed technical devices 2, 3, 4, 5a, 5b, 5c, 6 by the registration service 31, the technical module 1 can be issued a module-specific IDevID or LDevID certificate by the manufacturer / OEM who assembled and successfully tested them (more precisely, by their securely operated issuing CA). This certificate is requested using the certificate management service 32, taking into account the entries in the module inventory 9 and the status recorded by the monitoring service 33.

[0060] As soon as the monitoring service 33 reports an unacceptable change that negatively affects the trustworthiness of technical module 1 according to the existing policies, the aforementioned module-specific IDevID or LDevID certificate will be revoked – if necessary, in consultation with the user. When other devices installed in the respective operating environment communicate with technical module 1, the aforementioned module-specific certificate will be checked as part of an additional audit. In this way, it can be prevented (if necessary, with immediate effect) that a technical module 1 that has proven to be untrustworthy communicates with the other devices in the technical system and potentially causes damage.

[0061] The private key for the aforementioned module-specific IDevID or LDevID certificate is stored in a hardware or software secure element of a technical device 2, 3, 4, 5a, 5b, 5c, 6 installed in technical module 1. The same secure element already used by the individual technical device 2, 3, 4, 5a, 5b, 5c, 6, in which the private key is stored, is also used by the entire technical module 1 for the secure storage of the private key. In this case, if a device is replaced during operation and the checks performed by the registration service 31 are successful, a new key pair is generated and a certificate is requested not only for the respective technical device 2, 3, 4, 5a, 5b, 5c, 6, but also for the entire technical module 1. Alternatively, the aforementioned private key can be stored in a separate and securely installed hardware or software secure element within technical module 1.

[0062] The described services 31, 32, and 33 of technical module 1 are located on suitable components / devices (such as an IoT device). While it is possible to use existing technical devices 2, 3, 4, 5a, 5b, 5c, and 6, which are used for other purposes, as a platform for the aforementioned services 31, 32, and 33, it proves particularly advantageous, especially with regard to cybersecurity and availability, to use a dedicated device as the platform for these services 31, 32, and 33. This device should be integrated into technical module 1 or made available in the respective operating environment via one or more suitable interfaces.

Claims

1. Method for generating an operator control and monitoring and / or an automation by way of a control system (16) for a technical installation, in particular a manufacturing or process installation, wherein the control system (16) has an operator station server (17) and an operator station client (18), the method comprising: a) integrating a technical module (1), which represents a self-contained technical unit, into the control system (16) functioning as a higher-level control level, wherein the technical module (1) has a plurality of technical devices (2, 3, 4, 5a, 5b, 5c, 6), a computer-implemented module inventory (9) and an interface (8), which in particular is designed in the form of OPCC UA, wherein the control system (16), in the course of the integration, retrieves information from the computer-implemented module inventory (9) of the technical module (1) via the interface (8) and stores said information in a computer-implemented control system inventory (30) of the control system (16) realised separately from the technical module (1), said information being designed to identify the technical devices (2, 3, 4, 5a, 5b, 5c, 6) of the technical module (1) by way of the control system (16), and said information comprising certificates, on the basis of which the identification of the respective technical device (2, 3, 4, 5a, 5b, 5c, 6) can be carried out, b) generating the operator control and monitoring and / or the automation for the technical installation taking into consideration the information, stored in the computer-implemented control system inventory (30), in relation to the technical module (1).

2. Method according to claim 1, in which the control system (16) automatically evaluates a validity of the certificates and if one of the certificates is invalid excludes the technical module (1) from the operator control and monitoring, or the automation for the technical installation.

3. Method according to claim 1 or 2, wherein the certificates were issued by a certification authority of a manufacturer of the technical module (1).

4. Method according to one of claims 2 or 3, in which the information includes certificate chains for the technical devices (2, 3, 4, 5a, 5b, 5c, 6), which in each case include a certificate from the certification authority (29, 34) which issued the respective certificate for the respective technical device (2, 3, 4, 5a, 5b, 5c, 6), as well as from all higher-level certification authorities (29, 34).

5. Method according to one of the preceding claims, in which the information includes a respective firmware version, a serial number, a need for updating of operating software, a manufacturer's name, a device family, an IP address, a MAC address, a time of an originality check and / or a time of a manually performed identification of the respective technical device (2, 3, 4, 5a, 5b, 5c, 6).

6. Control system (16) for a technical installation, in particular a process or manufacturing installation, which is designed to perform a method in accordance with one of the preceding claims.

7. Technical module (1), having a plurality of technical devices (2, 3, 4, 5a, 5b, 5c, 6), an interface (8), which in particular is designed in the form of OPCC UA, and a computer-implemented module inventory (9), said technical module (1) being designed to be integrated into a control system (16) according to claim 6 for a technical installation, in particular a process or manufacturing installation, wherein information is stored in the computer-implemented module inventory (9) of the technical module (1) and is designed for identification of the technical devices (2, 3, 4, 5a, 5b, 5c, 6) of the technical module (1) by retrieving the information via the interface (8) by way of the control system (16), and said information comprises certificates, on the basis of which the identification of the respective technical device (2, 3, 4, 5a, 5b, 5c, 6) can be carried out.

8. Technical module (1) according to claim 7, in which the certificates were issued by a certification authority (29, 34) of a manufacturer of the technical module (1).

9. Technical module (1) according to claim 7 or 8, in which the information includes certificate chains for the technical devices (2, 3, 4, 5a, 5b, 5c, 6), which in each case include a certificate from the certification authority (29, 34) which issued the respective certificate for the respective technical device (2, 3, 4, 5a, 5b, 5c, 6), as well as from all higher-level certification authorities.

10. Technical module (1) according to one of claims 7 to 9, in which the information includes a respective firmware version, a serial number, a need for updating of operating software, a manufacturer's name, a device family, an IP address, a MAC address, a time of an originality check and / or a time of a manually performed identification of the respective technical device (2, 3, 4, 5a, 5b, 5c, 6).

11. Technical module (1) according to one of claims 7 to 10, in which the information meets the structural and substantive requirements of the VDI / VDE / NAMUR guideline 2658 as of the filing date of the present patent application.

12. Technical module (1) according to one of claims 7 to 11, which has a computer-implemented registration service (31) which is designed to determine, on the basis of a manual request or automatically at particular times, within the technical module (1) the information in respect of the technical devices (2, 3, 4, 5a, 5b, 5c, 6) and to store it in the computer-implemented module inventory (9).

13. Technical module (1) according to claim 12, in which the registration service (31) is designed to be triggered when one of the technical devices (2, 3, 4, 5a, 5b, 5c, 6) in the technical module (1) is replaced, to determine the information in respect of the technical devices (2, 3, 4, 5a, 5b, 5c, 6) and to store it in the computer-implemented module inventory (9).