Automation Component Configuration

The invention refers to a method to facilitate providing au tomation component configurations for automation components of an industrial automation project. The method especially focuses on security aspects of automation projects.

The present invention further relates to an engineering sys tem for engineering, programming and/or configuring industri al automation components and particularly engineering, pro gramming and/or configuring security related features of au tomation components in automation projects. The invention further relates to automation components, automation compo nent databases and receiving tools. A computer program and a data carrier signal are further provided.

Industrial engineering systems, also known as project engi neering tools for industrial application, may be used for so lution-design and -implementation, as well as later operation and/or management processes. Solutions are to be understood as industrial solutions for process and or discrete indus tries .

The engineering of an automation project (e.g. for a plant) usually comprises one or more of the following: determining the required functionality in the project, determining what components are needed to offer this functionality, allocating functionality and an actual physical position to the compo nents in the plant, allocate communication structures to the components (e.g. what components are allowed to communicate with what other components and how they communicate, what ac tually is the purpose of the component), etc.

An automation project correlates with a real project for e.g. setting up a new production/manufacturing line in a new or existing industrial plant or a new or existing process plant. Some of many examples in which such automation projects are set up, are the manufacturing of vehicles in the automotive industry, producing electronics, producing food and beverage products and many more.

In these applications the engineering system is used for gen erating one or more automation component configurations in the context of an industrial automation project. The indus trial automation project can be e.g. factory automation pro jects, process-industry automation projects and any further automation projects in an industrial context.

An automation component in this application can be a hardware component and/or a software component or a combination of both for use in the above automation project. Automation com ponents include but are not limited to: programmable logic controllers (PLCs) , I/O modules, industrial communication de vices, industrial networking components, sensors, actors, drives and other industrial devices commonly used in the pro cess or automation industry. Software components which share hardware with other components are also configurable by the method and/or the engineering system.

In industrial environments, e.g., industrial automation con trol, SCADA, or energy automation, automation solutions are typically composed of a heterogeneous range of system compo nents (e.g., embedded devices, controllers, network equip ment, standard-OS systems and applications) . Also, such solu tions are divided in several zones that are separated into multiple sub-networks at the network (logical) level or through physical separation like several buildings. When such solutions are designed, implemented and taken into operation, properties of the deployed solution components can be de scribed in standardized formats (e.g., DIN EN 61360, see the database under Database: http://std.iec.ch/iec61360, or the ECl@ss object format. However these formats focus just on hardware properties of the components. The problem to be solved with this invention is to facilitate the implementation of security parameter settings in an engi neering project. In particular high and solution wide securi ty settings in an engineering project may be achieved.

To solve this problem a method to provide automation compo nent configurations for automation components of an industri al automation project, is proposed. The method comprising a first step of determining automation component description data comprising one or more functionality parameters for con figuring functionality of the one or more automation compo nents and one or more security parameters for configuring se curity functions of the one or more automation components.

The method comprising a second step of determining based on the industrial automation project, a functionality parameter setting for the one or more functionality parameters and a security parameter setting for the one or more security pa rameters .

The invention simplifies the automated implementation and verification of one or more security measures in an automa tion project to reduce the risk of misconfiguration and the resulting security vulnerabilities significantly and ensures the consequent enhancement of functionality data with securi ty data. It should be understood that the first and the sec ond step of determining may be performed in the order as pre sented above or may be performed either in parallel or simul taneously to one another. Also, it should be understood that the first and the second step of determining may be performed in a coordinated manner such as to form a single coordinated step .

The method is very effective when multiple automation compo nent configurations are provided for multiple automation com ponents. In an automation project, in particular of an indus trial scale, usually there are multiple automation components that have to be configured. The method proposed can be car- ried out by an engineering system or a group of components that form an engineering system. The automation component configurations are used to configure actual components and devices that interact with the physical world. The method is also applicable when every component has to be configured with security parameter settings.

One or more functionality parameters may define one or more functionalities of an automation component, preferably all of the functionalities of an automation component. One or more functionality parameter settings may configure the respective one or more functionalities. The functionality parameters can include but are not limited to: control functions, 10 map pings, startup definitions, error handling, monitoring func tionality, condition monitoring, controlling, and further functions, that are common in industrial automation projects. The required functionality of one or more automation compo nents in an automation project depends on their actual task and their surrounding (including neighboring components with which they are supposed to cooperate and/or interact), commu nication capabilities and the like. A functionality can in clude one or more programs that are to be executed on one or more automation components.

One or more security parameters may define a security func tion of an automation component, whereas one or more security parameter settings configure the security functions, prefera bly all of the security functions of an automation component. The one or more security parameters may thus describe one or more security functions and can include but are not limited to: supported or active TCP/UDP communication ports, communi cation protocols, configured accounts for users (system or user accounts, operating system accounts, web server ac counts, database accounts, etc.), supported security func tions (logging of critical events, separation of zones imple mented in the solution, etc.) as well as applied hardening measures for the components and any further security

measures. Security parameters can also be defined as a „no security features available" parameter - which later on can be evaluated to show a project or system level security meas ure or even disqualify a certain automation component for a certain higher security task.

Generally, one or more parameters and their settings may be represented by configuration data which is applicable to the automation components in automation project. An automation component may have a limited number of parameter settings available, e.g. below 50. Parameter setting can be binary configuration selections of functions, such as enabling or disabling a certain functionality of the component.

Automation component description data can be an existing de scription of the component, which e.g. is part of a component library in an engineering system, mostly available from the manufacturer of the components or the provider of the engi neering system. The automation component description data can already comprise a basic set of pre-defined parameter set tings. Automation component description data can be in the form of a digital model of the automation component, in cur rent development digital twins of the automation component are provided more and more. Automation component description data can also be a model of one or more automation components that are used in an automation project, e.g. a digital model or a digital twin of an automation component with a prede fined default configuration (default parameter settings) . A default configuration can be a set of parameter settings that can be applied to a plurality of different automation pro jects. Parameters generally can be preconfigured building blocks for standard use cases and also can be empty templates that are completely manually configurable e.g. in a later stage of the automation project.

A data exchange between the entity generating the project level security data and/or automation component configura tions and receiving tools/components or other devices prefer ably bases on one or more standardized data formats. For functionality such data formats and/or databases are e.g. known form IEC 61360 or ECl@ss. Hence, such a data format and/or a database can be enhanced by security data according to an aspect of the current invention.

The one or more functionality parameter settings and/or one or more security parameter settings are generated based on the automation project. This can be achieved by linking the information stored and/or directly entered in the automation project to the one or more functionality parameters and one or more security parameters actually used in the one or more automation components.

The invention therefore allows strict generation of one or more automation component configurations with the use of au tomation component description data in combination with secu rity-related data, including security parameter settings, from early stages of the automation project on. When the au tomation project is set up, the security parameters may auto matically provided for each component that is added to the automation project. The one or more security parameters can be implemented in one or more automation projects and fur thermore they can be verified and analyzed for vulnerabili ties in the solution by further components. Possible applica tion of the security parameters are: input for the actual se curity configuration of automation components, security test ing and security threat and/or risk analysis.

In general it is possible to provide security parameter set tings for security parameters that are not directly applied to automation component itself. This can be the case for low- level automation components, which do not implement any secu rity features themselves, but need to be classified according to a security level or a security zone. This allows extending security features onto components that do not support securi ty features themselves. In a further embodiment the method comprises a third step of providing one or more automation component configurations comprising the determined functionality parameter settings and the determined security parameter settings. Providing can comprise one or more of saving the configurations to a data base, forwarding the configurations to a receiving tool, di rectly configuring automation components, and further steps.

In a further embodiment the first step further comprises re trieving one or more default functionality parameter settings and/or one or more default security parameter settings and the second step of determining further being based on the one or more default functionality parameter settings and/or the default one or more security parameter settings. Default se curity parameter settings can be default security settings, such as enabling standard encryption for communication, ac cess control settings or the deactivation of certain unsecure ports in communication by default. Default functionality pa rameter settings can be preconfigured building blocks for standard use cases, e.g. the control of a motor, reading in sensors, establishing connections between different compo nents. It is possible to retrieve the default functionality parameter settings and/or the default security parameter set tings from an automation component database. Additionally or alternatively a generation component in the engineering sys tem or elsewhere could generate default functionality parame ters and/or default security parameters. The engineering sys tem then could choose to generate certain parameters itself and retrieve them from the generation component or retrieve the default parameters from the automation component data base. Using or even enforcing default security settings greatly improves the security of the whole automation system, in combination with default functionality settings improving the productivity of the overall engineering process.

Retrieving default parameter settings can be implemented by an engineering system generating default settings according to definable criteria. The default parameter settings can further be stored in a central or decentral automation data base, which also can be allocated in a remote storage, such as a cloud platform, such as MindSphere from SIEMENS AG, from where said default parameter settings may be retrieved. Parts of the automation database can be stored or buffered in the engineering system for higher-performance access. Retrieving comprises passively receiving or actively polling data.

The default parameter settings can be used unaltered or can be adjusted according to and/or based on the automation pro ject and the further use of the component or components which will be configured with the automation component configura tions .

Some parameters will have impact on both: functionality con figuration and security configuration, therefore some parame ters can occur as a security parameter as well as a function ality parameter in an automation component configuration.

Such dependencies can be managed, visualized and/or used much more efficiently with the proposed structure. An example for such a dependency can be a communication protocol with real time properties. Usually, a communication protocol with real time requirements may not achieve a security level as high as a communication protocol without real-time requirements.

Thus, a real-time communication protocol may have a security level that due to its real time properties is lower than a security level of a communication protocol without real-time requirements. This security level then can be included in the engineering of the zone containing the lower security commu nication in the automation system. Those functionality param eters with inherent security properties can then be dealt with by additional security features, if needed, in those cases .

The engineering system can provide the generated functionali ty and security parameter settings via (e.g. encapsulated in) one or more automation component configurations to further components . In a further embodiment the determined security parameters are combined to a set of project-level security data for the respective automation project. Certain project data and/or functionality parameters can be included in the project-level security data for further analysis or optimization. The set of project-level security data provides security data at a solution level, such as attributes for a network used in the whole solution or physical zones with different security at tributes, which may influence security attributes in the sys tem level as well. An example is a solution wide protection level that defines specific security attributes that must be met by the single automation components or single groups of automation components. The project level security data can be arranged intelligently in a structured manner to further car ry out optimization processes, such as reducing the number of high-security components or enhancing security by providing a limited number of more secure components. Components can have configurable security classes and may be used in different security zones.

In a further embodiment the automation component configura tions and/or the project-level security data are provided to a receiving tool, preferably a configuration tool, a verifi cation tool and/or a monitoring tool. The receiving tool can be a component, a standalone hardware device, a tool in a shared device that is configured and/or operative to receive and further process the automation component configurations and/or the project level security data.

Configuration tools are operative to configure the automation components with the provided automation component configura tions. It can be a part of the engineering system or a standalone solution.

Verification tools are tools that are operative to verify a correct implementation and operation of security functions and features. The engineering system providing the automation component configurations to a verification tool enables a more efficient approach to the necessary verifications of the security requirements of automation projects. In a more strict approach only verified automation component configura tions are allowed to be provided to the automation component directly. The verification tool can be a part of a bigger en gineering environment or can be integrated into the engineer ing system as a module. The verification tool can be a secu rity only verification tool or a security and functionality verification tool in combination. Later on the verification tool can send back configuration or verification results to the engineering system to allow further optimization of secu rity data or automated reporting of verification results and detected deviations (e.g. deactivated security features in a high security zone) .

Monitoring tools are operative to money toward the provided data/configurations and to report and or signal changes that are required in the configurations because of external is sues, like security breaches, update requirements or near ze ro day exploits or internal issues because of change of pro duction or change of optimization and/or security require ments. All of the above receiving tools can be implemented together on a single system or be combined in a way that is most suitable for the automation project.

Alternatively or additionally the automation component con figurations can be provided directly to the automation compo nents. This way a separate configuration tool is not neces sary anymore and could be seen as part of an engineering sys tem or superior entity. Nevertheless the automation component configurations provided by the engineering system can be sep arately used in a configuration tool anyways. This allows a high amount of flexibility in an automation project.

According to a further embodiment an automation component configuration is provided for each automation component or each group of related automation components, preferably each component in the automation project is provided with a compo nent configuration enhanced with security parameters accord ing to this invention. This way it is assured that all the automation components in the automation project are provided with a suitable automation component configuration in an ef ficient manner. The configuration directly affects the way the automation system interacts with the physical world. It is guaranteed that each of the one or more automation compo nent configurations is provided with one or more security pa rameter settings and/or security information about the secu rity parameter settings. This approach allows implementing a higher level of security, while allowing an efficient tracea bility, monitoring and verification of security.

According to a further embodiment each of the one or more au tomation component configurations are determined based on se curity parameters in combination with at least one default security parameter. This step ensures that at least a basic security level can be achieved and no automation component can be engineered without security parameter settings. The possibility to declare components as not security relevant can be configured for certain components. Consequently for those components even a basic security configuration is not necessary. This can be the case in very low security zones or for components of very low importance. Nevertheless this con figuration information of non security relevance still can be included in a project level security data, so it is known which components do not have a security configuration and therefore are not to be used in higher security zones, unless correctly configured with a higher security standard. Addi tionally or alternatively components without security config uration can only be used with another component that takes over security for the further component - e.g. a firewall, a networking device with packet filtering to protect the low security device from malicious packets and further security devices and or components. In another embodiment the method comprises the step of evalu ating the set of project-level security data of the automa tion project according to definable security criteria. Evalu ating the project security data can result in reporting the current configuration and/or verification results back to the project tool (e.g. the engineering system) to allow further optimization of solution security configuration data. Depend ing on the general security requirements of the automation project those evaluations can be enhanced with further measures .

In a further embodiment, the method comprises the step of op timizing the set of project-level security data according to a definable project security level and/or definable security zones. Optimizing the project level security data can be re alized by e.g. comparing the different parameter settings and identifying deviations from single automation components from the majority of automation components or from the global se curity level, which is set for this respective zone or this automation project. As a measure the identified deviations and can be reported or directly and/or automatically correct ed by the engineering system. Another possibility is that different encryption standards are used and for the sake of efficiency a currently optimal (a reasonable compromise re garding speed and security) encryption standard for the auto mation project is chosen to ensure smooth operation of the automation components.

In a further embodiment, the method comprises structuring the automation component description data are according to a for mat comprising at least functionality data and security data. The advantage of such standardized component description data is the further applicability of the data and the compatibil ity among different components. Optimization processes are also simplified. An example of such data could be a database like known from IEC 61360 that is enhanced with security data according to the described invention. In a further embodiment, the method comprises enriching the automation component description data with at least parts of the automation component configurations. This ensures that the configurations and the knowledge that was used to engi neer a project can further be used in future projects or in other parts of the current project as a continuous improve ment. This way the efficiency rises with further use of the proposed method. Additionally or alternatively the knowledge can be shared across an automation platform in bigger enter prises or even among conglomerates or standardization groups.

The problem is further solved by an engineering system for providing one or more automation component configurations for an industrial automation project by a method according to any one of the preceding claims, the engineering system being configured and/or operative to:

- in a first step determine automation component description data comprising one or more functionality parameters for con figuring functionality of the one or more automation compo nents and one or more security parameters for configuring se curity functions of the one or more automation components and

- in a second step determine, based on the industrial automa tion project, a functionality parameter setting for the one or more functionality parameters and a security parameter setting for the one or more security parameters. Such an en gineering system can be provided on a PC, a central server infrastructure for all enterprise, as a web-based application and so on. The engineering system can comprise interfaces to contact and/or connect the automation components. The engi neering system according to the invention simplifies a per sistent configuration of automation components in a secure way. The engineering system further simplifies verification and configuration of the components. The engineering system can carry out or initiate any of the steps and embodiments of the method described in this invention.

The problem is further solved by an automation component be ing configured and/or operative to receive and/or retrieve automation component configurations and to apply functionali ty parameter settings and security parameter settings from the received automation component configuration. For these purposes the automation component can comprise an interface and a memory and further can be operative/configured to re ceive automation component configurations via the interface and apply them to the memory, further the possibility, that a CPU which can be part of the automation component or shared with other automation components executes the parameter set tings received from the automation component configurations.

The automation component can be configured to notice by it self, that a new configuration is required and retrieves the configuration by itself. Once configured with the suitable automation component configuration, the automation component can be deployed in the factory or the process plant that is intended to be used in. Later on, when security measures have changed and/or have to be upgraded, the automation component configurations can be updated. This can be done by a push service in the automation network, e.g. initiated by the en gineering system or any of the receiving tools.

The problem is further solved by an automation component da tabase providing at least one or more of automation component description data and/or default functionality parameters and/or default security parameters according to the method described herein. Such a database can be part of or incorpo rate a component library stored locally, central or decentral e.g. in a cloud server system.

The problem is further solved by a receiving tool operative to receive and/or retrieve automation component configura tions and/or project-level security data provided by a method according to the invention described herein, and to process the automation component configurations and/or project-level security data. The processing of the project-level security data can comprise evaluating single points of parameter set tings and comparing them with security policies for certain security zones and security levels. Furthermore big scale se curity analysis with artificial intelligence is also possible when combining project-level security data of larger projects or multiple data for analysis purposes. Optimization can also take place, e.g. combining certain security features of low er-level automation devices in a higher-level automation de vice, with enough computation power to ensure an efficient infrastructure for security purposes.

In a preferred embodiment the receiving tool is operative to provide a result of processing one or more of the automation component configurations and/or project-level security data to the engineering system. When providing the results of pro cessing the project level security data back to the engineer ing system future projects can be greatly simplified opti mized and overall improved regarding security as well as functionality, projects that are already in place can be im proved and optimized regarding security, or even secured against threats, that were unknown during the period of engi neering .

According to the invention a computer program comprising in structions which, when the program is executed by a computer, cause the computer to provide automation component configura tions for automation components of an industrial automation project, and further to carry out the method according to the invention is provided. A data carrier signal carrying the computer program described herein is also covered by this in vention. All forms of data carrier signals according to the invention, such as downloads from the internet, intranet, USB drives, SD cards, and further known and future data carriers are covered by this invention.

Embodiments of the invention are now described, by way of ex ample only, with reference to the accompanying drawings, of which :

FIG 1 shows the general concept of the invention; FIG 2 shows an engineering system;

FIG 3 shows an automation component;

FIG 4 shows an automation project in relation with an in dustrial facility;

FIG 5 shows an industrial facility with its security zones;

FIG 6 shows an automation component database in interaction with an engineering system and

FIG 7 shows a further embodiment of an automation component database and the data it is providing

FIG 8 shows a further embodiment of an automation component database and the data it is providing

FIG 9 shows three steps of an embodiment of the method ac cording to the invention.

FIG 1 shows the general concept of the invention, which al lows strictly applying security parameters and parameter set tings during engineering. Automation component description data CDD is shown on the left for three solution components, in this case for automation components Cl, C2 and Cn . The au tomation component description data CDD comprises least func tionality parameters FP and security parameters SP. The auto mation component description data CDD therefore is enhanced according to the invention with security parameters SP, that can be configured with security parameter settings Sl,...,Sn (not shown) . The automation component Cl also comprises func tionality parameters FP and their functionality parameter settings Fl,...,Fn, that are not shown here for the sake of clarity. The available parameters and their settings are all data which are further useable or processable with a project tool, e.g. an engineering system ES as shown. The engineering system ES currently shows an automation project to be edited or engineered. The engineering system ES can create or re trieve, manage and/or optimize the security parameters SP and the security parameter settings Sl,...,Sn respectively while using automation component description data CDD. As shown on the far right the automation component Cl is to be provided with an automation component configuration ACC1 further com prising security parameter setting SI and functionality pa- rameter setting FI . For the sake of clarity for automation components C2 and Cn their automation component configura tions ACC2 and ACC3 are not shown but can be also created or engineered by the engineering system ES as described for the automation component configuration ACC1 for automation compo nents Cl .

As mentioned above, the automation project PRJ is currently loaded in the engineering system ES to generate automation component configuration ACC for three automation components Cl, C2, Cn . The engineering system ES further can not only be used for a current automation project PRJ but to manage and optimize already created projects and their security parame ter settings Sl,...,Sn and functionality parameter settings Fl,...,Fn to optimize future automation projects PRJ or to im prove automation projects PRJ that are already in place. Fur thermore the automation project shows project level security data PRJSEC, which comprises security information, e.g. parts of or complete security parameters SP and their settings Sl,...,Sn, and further data related to security of the project PRJ, possibly including security data of all automation com ponents Cl,...,Cn to be used in the automation project PRJ.

The engineering system ES can also be linked to an exploit database where current security breaches are published, the engineering system ES being able to check all of its automa tion projects PRJ and their project level security data

PRJSEC for necessary steps and apply measures to the automa tion projects PRJ accordingly. The applicable measures then can be verified in a verification tool VT or directly applied via a configuration tool CT or directly via the engineering system ES.

According to an embodiment, that is compatible with all other embodiments, including or removing features of the current invention and in more detail there can be the following steps, each respective to the small letters a-g: Referring to (a) : the automation component description data CDD used for project engineering and in project engineering systems ES are extended with security related data, security parameters SP required as input for security configurations, security testing, and/or security threat and risk analysis. Moreover the security parameters SP are automatically provid ed for and into the project tooling, in this case the engi neering system ES. One possible implementation of the inven tion extends existing automation component description data formats and databases (e.g., DIN EN 61360 or ECl@ss) with se curity configuration data. This includes for example communi cation ports that are open by default and those that are sup ported in general .

Referring to (b) : the engineering system ES not only provides configuration data in form of functionality parameters FP, but also combines and optimizes the component description da ta CDD in an intelligent way to generate project-level secu rity data PRJSEC and descriptions from the automation compo nent description data CDD by combining the security parame ters SP relevant to the automation project to a set of pro ject (or system) level security data PRJSEC. This ensures that security data at a solution level is available for fur ther measures. As depicted here at an automation project PRJ level, attributes, such as parameters for network or physical zones, may influence security attributes in the system level as well. This accumulation of security attributes, data or parameters is shown as project level security data PRJSEC. An example is a solution-wide protection level, or multiple dif ferent security zones, that define specific security attrib utes that must be met by single systems. The security zones are exemplary defined according to the IEC62443 security standards framework ( IEC62443-3-3 and IEC62443-3-2 ) . As an example the project engineering tool, the engineering system ES, aggregates active ports and the configured IP addresses of the components, the automation components Cl,...,Cn, in the solution, and can optimize the resulting list of data, e.g., by identifying communication relations and reducing the over- all list's complexity. Those communication relations can then be enriched with security relevant data (encryption, security zones, ...) and be automatically be generated as communication graphs and shown on HMI systems to simplify security analysis and monitoring.

The tool can further optimize the data, for instance, by breaking it down to the several configured solution zones (these can be, for example, "security zones" defined accord ing to the IEC62443 security standards framework - e.g.

IEC62443-3-3 and IEC62443-3-2 ) .

Furthermore, optimization can take into account the configu ration of components that control the zone boundaries, like firewalls, and that allow communication (based on IP address es and ports) only when allowed by the configured firewall rules. For component security data that comprise security tests (descriptions of specific security tests to be per formed on components) , the optimization can be that the test cases are aggregated and chosen based on a security level or protection level assigned to the solution, zone, or component itself. This allows to optimize the overall set of security tests (e.g., those that have to be performed later on during acceptance testing, or scheduled solution security verifica tion during operation) to meet one or more given security levels. These steps can be performed by the engineering sys tem ES itself, or any of the receiving tools VT, CT, MT .

Referring to (c) : The provided security attributes, descrip tions and/or automation component configurations ACC1 , ACCn can then be provided to receiving tools VT, CT, MT such as configuration tools CT, verification tools VT, or monitoring tools MT, preferably through standardized communication ex changes and data formats to allow more efficient and secure configuration, monitoring and verification of the configura tion, especially the security configuration, of the solution. For example the engineering system ES sends the generated se curity data SD for the automation project PRJ to a receiving tool VT, CT, MT that uses them. The receiving tools VT, CT,

MT also could be configured to retrieve data from the engi neering system in predefined intervals, to verify security, to monitor changes and further relevant information. Exchange of the data can also be based on the extended standardized component description formats as described above, or can use other data formats.

Referring to (d) : The security data can be rolled out to the solution components, the automation components Cl,...,Cn, by the configuration tool CT, e.g. after they were verified and/or monitored by the verification tool VT and/or monitor ing tool MT . The configuration tool CT can be part of the en gineering system ES or its functionality can be integrated into the engineering system ES. The receiving tool VT, CT, MT could be, for instance, a verification tool VT that loads the security data per security zone or for the whole system, and verifies the correct implementation (i.e., whether the list of actually scanned/audited open ports in each zone of the solution is equal to the security data received from the pro ject tool) .

An alternative or addition to (d) could be that the receiving tool VT, CT, MT is a configuration tool CT that performs se cure configuration of solution components, in this case the automation components Cl,...,Cn, based on the security parame ters SP and their settings Sl,...,Sn received from the project tool, the engineering system ES. For example, the receiving tool VT, CT, MT interprets the security data SD received and converts it into SNMP MIB formatted data to exchange security data with individual components (e.g., to deactivate unneeded communication ports and network functions) . Alternatives to SNMP MIB include security data SD exchange based on OPC-UA, or the Constrained Application Protocol (CoAP) .

The receiving tool VT, CT, MT could be a monitoring tool MT that transfers the received information, e.g., into COAP, to observer resources on the solution components according to RFC7641.

Referring to (e) : The receiving tools VT, CT, MT can create and provide reports on configuration, verification or verifi cation results back to the project tool ES to allow further optimization of solution security configuration data

ACC1 , ACCn and their security parameter settings Sl,...,Sn and/or the automation component description data CDD. This allows an even deeper integration of security data SP and Sl,...,Sn into the engineering of automation projects PRJ. In a later step, the receiving tool VT, CT, MT can provide config uration or verification results to the engineering system ES, to allow further optimization of security data SD or automat ed reporting of verification results and detected deviations.

Referring to (f) : the dashed arrow f indicates possible fur ther embodiments that allow the engineering system ES to di rectly communicate with the automation components Cl,...,Cn.

The arrow tips are directed in both directions to show that the engineering system ES can directly configure the automa tion components. If necessary the automation components

Cl,...,Cn also can directly communicate with the engineering system ES and for example request updates for functionality as well as security or the like. Using standardized data for mats according to the current invention including security parameters SP simplifies the communication and enriches the automation system with a higher security.

Referring to (g) : the dashed arrow g indicates possible fur ther embodiments, which allow the receiving tools VT, CT, MT to directly access the automation component description data CDD. This includes but is not limited to retrieve security and/or functionality parameters SP, FP, verify the engineer ing system ES results created and/or received under (c) and/or the receiving tools VT, CT, MT providing additional data to enhance the automation component description data CDD. A verification tool VT for example can provide verifica- tion results of predefined configurations and store them in the automation component description data, so that similar or identical configurations do not have to be verified again. A configuration tool CT could provide data about how often and to what extent certain automation component configurations ACC1 have been provided and if they were successfully de ployed in the field. A monitoring tool MT can provide data from live automation systems, possible failures, running times, maintenance requirements and more to enrich the auto mation component description data CDD.

An implementation example of the above can be the allowed TCP/UDP communication ports in an automation project PRJ. A typical part of security configuration is the configuration of communication protocols per component (i.e., open TCP or UDP ports at given IP addresses of network components) such that only allowed ports are open and can be reached via the network. These configurations can be represented in security parameters SP and their respective security parameter set tings SI , ..., Sn .

FIG 2 shows an engineering system ES in greater detail. In this embodiment the engineering system ES comprises a proces sor CPU and a communication interface COM as well as a memory MEM. The memory MEM is divided into multiple parts and can be realized is a physical data carrier such a hard disk drive or solid-state drive or also could be a central or decentral server infrastructure. The memory could also be implemented in the form of RAM. Indicated by solid horizontal lines, the memory MEM is divided into multiple parts that can be sepa rated from each other on a physical or virtual level. As an example the memory contains two automation projects PRJ. The upper automation project PRJ could be an older project that is still stored in the memory MEM of the engineering system ES .

Indicated by the shown contents, the lower automation project PRJ is currently loaded and contains project level security data PRJSEC as well as models of two automation components Cl, C2. The processor CPU is designed to execute code to pro vide automation component configurations ACC1 , ACCn (not shown in this FIG) for the automation components C1,C2 of the currently loaded industrial automation project PRJ. The code can be provided as a computer program product comprising com puter program code for executing the method according the current invention. The processor CPU can be a single proces sor of a standalone PC, a multi-processor platform, a pro grammable logic controller, a virtual processor in a server processing farm and other processors or computing infrastruc tures capable of executing the code.

FIG 3 shows an automation component Cl . The automation compo nent Cl comprises a processor CPU, a communication interface COM and a memory MEM and N is an example for a hardware-based automation component. Automation components include but are not limited to: programmable logic controllers (PLCs) , I/O modules, industrial communication devices, industrial net working components, sensors, actors, drives and other indus trial devices commonly used in the process or automation in dustry. Software components which share hardware with other components are also configurable by the method according to the invention and/or the engineering system ES and/or a con figuration tool CT . Usually an automation project comprises a PLC, a number of I/O modules that can communicate with the PLC over an industrial communication standard, some sensors and some actors that communicate with each other and/or the PLC. All or some of them can be provided with automation com ponent configurations ACC1 , ACCn via the method according to the invention that is proposed herein. This list is not ex haustive and can be amended by adding or removing automation components Cl,...,Cn respectively.

FIG 4 shows an automation project PRJ in relation with an in dustrial facility FAC. The industrial facility FAC to the right displays a very much simplified example of an automa tion project limited to a single industrial facility FAC and its to automation components Cl, C2. On the left an automa- tion project PRJ can be seen, comprising virtual representa tions of the industrial facility VFAC, models of the automa tion components Cl, C2, including pre-engineered automation component configurations ACC1, ACC2, and a facility level se curity data FESEC. In this case the facility level security data FESEC can be equal to a project level security data PRJSEC because only this one facility FAC has to be config ured/provided with automation component configurations ACC1, ACC2. Facility level security data FESEC can be provided with the same method additional or alternative according to the current invention and enables the same benefits on the facil ity level as the security data does on a project level.

The automation component configurations ACC1, ACC2 each can be provided by a method according to the invention, e.g. by an engineering system ES not shown here. They comprise func tionality and security parameters FP, SP including their set tings FI, F2, SI, S2. In the automation components Cl, C2 em ployed in the industrial facility FAC the settings are de picted each in the respective component. For example the au tomation components Cl can be a PLC that has a simple motion program as a functionality parameter FI with a number of se curity parameters, such as an internal encryption of the data processed by the PLC. This encryption for example could be the security parameter setting SI. The automation component C2 could be a motor integrated drive controller that is con trolled by the PLC Cl, which as a functionality parameter FP can rotate and its functionality parameter setting FI is con figured to rotate upon a signal by the PLC. In this case the security parameter setting S2 could be the presence of a cer tificate, allowing encrypted communication between the auto mation components Cl and C2. The two security parameter set tings SI, S2 are also depicted in the facility level security data FASEC where they can be monitored, verified and if need ed also be provided in a newer version to the actual facility FAC and its automation components Cl, C2 as an update for se curity parameters SP. FIG 5 shows an industrial facility FAC, comprising eight dif ferent automation components C1,...,C8 that are divided into multiple security zones Zl, Z2, Z3. The security zones Zl,

Z2, Z3 are defined by the need for security measures in a certain area in the automation system. In this example there the three security zones Zl, Z2, Z3 each corresponding to a security level required. Security zone Zl could be a low se curity zone which includes access for logistics companies and other contractors. This low security zone Zl therefore should not contain any sensitive data, sensitive machines or pro cesses.

The medium security zone Z2 could comprise a certain amount of little sensitive data or processes which is regularly the case in production facilities.

The third and high-security zone Z3 could then comprise strictly confidential information such as the certification processes for electronic products or the recipes for chemical or other process industry products. In such a high level se curity zone Z3 secret keys for certificates could be deployed to automation devices.

FIG 6 shows an automation component database DB in interac tion with an engineering system ES. Automation component da tabases DB can be provided in the form of automation compo nent libraries as known form of functionality parameters from current engineering systems ES. The invention now enhances the automation component description data CDD with security parameters SP for and preferably will for all automation com ponents Cl,...,Cn. Also according to a further embodiment of the invention default security parameter settings defS are also provided as default functionality parameters defF.

Referring to (h) : the engineering system ES can retrieve or receive automation component data CDD for automation compo nents Cl,...,Cn that are to be used in the automation project. The engineering system ES can also enhance the automation component data CDD that it receives from the automation com ponent database DB itself or by user input. This is especial ly helpful when automation components Cl,...,Cn have to be con figured that are very similar to each other and automation component data CDD is available only for a similar component.

Referring to (j) : the automation component database DB fur ther provides default security parameter settings defS. The engineering system ES can automatically receive or retrieve the default security parameter settings defS. This can happen initiated by a manual input or automatically, e.g. by an au tomated security wizard provided by the engineering system ES to ensure a high level of security automatically when engi neering automation projects PRJ. At least parts of the de fault security parameter settings defS can be part of the au tomation component description data CDD. Providing default security parameter settings defS improves the level of secu rity achieved significantly when rolling out a security con cept in an automation project PRJ. Furthermore it is possible that automation components Cl,...,Cn that have not been provid ed with a security parameter setting Sl,...,Sn yet are high lighted in the engineering system ES and default security pa rameter settings are proposed to the user or even automati cally applied.

Referring to (k) : the automation component database DB fur ther provides default functionality parameter settings defF. The default functionality parameter settings defF can be functions of automation components Cl,...,Cn that are often used and therefore are easily deployable, when default compo nents are used. Examples are standard movement patterns for motion controllers, sensors evaluation components and further control (open and closed loop) components. It is possible that certain functionality parameter Fl,...,Fn settings are in some cases always linked with a default security parameter setting defS. Such a default security parameter setting defS can be proposed to the user or automatically implemented by the engineering system to ensure security where it is needed. FIG 7 shows an automation component database DB similar to the one of FIG 6. It shows default security parameter set tings defS and default functionality parameter settings defF as part of the automation component description data CDD.

This can be the case for automation component related but not automation component specific data. For example basic certif icates can be provided for all automation components.

Referring to (m) : the default parameter settings defF, defS can be provided by the automation database DB combined with the automation component description data CDD for components usually required in an automation project PRj . The engineer ing system ES could also initiate a request for certain auto mation components with certain default settings defF, defS already applied.

FIG 8 shows another automation component database DB similar to the ones of FIG 6 and 7. In this case a set of default se curity parameter settings defS and default functionality pa rameter settings defF is provided by the automation component database DB for an automation component Cl . For example a memory encryption can be enabled by standard as a default se curity parameter setting defS. Certain automation components, such as so called edge devices, that have a connection to an internal network as well as an external network - such as the internet - may have a wide set of default security parameter settings. For example all http access can be blocked and an https access could be enforced. Also certain data pack ets/telegrams may be filtered and/or blocked completely.

Those settings can be provided as default parameter settings defS or can be part of engineering the automation project PRJ.

Referring to (n) : In this embodiment a completely preconfig ured standardized building block for a certain device - in this case the automation component Cl - can be requested by the engineering system ES or provided by the automation data- base DB to the engineering system. This ensures a simple con figuration for standard use cases, such as securely control ling a process or a drive system - while ensuring a high lev el of security for the whole automation project PRJ.

All the variants shown in FIG 6, 7 and 8 can be combined with each other in any way, with the possibility to combine de fault security parameter settings defS and/or default func tionality parameter settings defF in any one or more of the positions shown in the FIG 6, 7 and 8. For example the de fault security parameter settings can be provided in the au tomation component database DB as well as in the automation component description data CDD and additionally for each of the components Cl, C2, Cn .

FIG 9 shows three steps of an embodiment of the method ac cording to the invention. This includes:

• a first step SI of determining automation component de scription data CDD comprising one or more functionality parameters FP for configuring functionality of the one or more automation components Cl,...,Cn and one or more security parameters SP for configuring security func tions of the one or more automation components Cl,...,Cn;

• followed by a second step S2 of determining, based on the industrial automation project PRJ, one or more func tionality parameter settings Fl,...,Fn for the one or more functionality parameters FP and one or more security pa rameter settings Sl,...,Sn for the one or more security parameters SP and

• optionally (indicated by dashed lines) followed by a third step of providing S3 one or more automation compo nent configurations ACC1 , ACCn comprising the deter mined functionality parameter settings Fl,...,Fn and the determined security parameter settings Sl,...,Sn.

Furthermore step S3 may be based on steps SI and/or S2. Hence according to another aspect the method may only consist of step S3. Although the present invention has been described in detail with reference to the preferred embodiment, it is to be un derstood that the present invention is not limited by the disclosed examples, and that numerous additional modifica tions and variations could be made thereto by a person skilled in the art without departing from the scope of the invention .