Patent Description:
With an increasing strain from the market, enterprises within the process industry are competing for profitable operations, trying at the same time to overcome challenges due to fluctuating demands, reduced time-to-market and shortened product life cycles. Modular automation is an emerging technology within the process automation industry, e.g. the chemical and pharmaceutical sectors, that promises to address some of these challenges. For example, in <CIT>, a manufacturing process is broken down into a series of smaller tasks, each defined by a separate ladder logic control program. The overall process is defined by a function chart specifying the order in which these tasks are to be performed and thereby the execution sequence of the corresponding ladder logic control program.

Modular automation provides a manufacturing environment with flexibility e.g. in order to go from laboratory experiments into production with low cost and effort, the ability to scale production volumes up and down based on market demands, and to tailor products to customer specific requirements. The technique to enable modular automation is based on standardised autonomous modules, e.g. described as Module Type Packages (MTPs), that carry out specific tasks, e.g., a heater or distiller. These MTPs can be dynamically combined and recombined to perform different collaborative operations with a minimum engineering effort. Thus, the different modules within the modular automation system are typically highly heterogeneous and dynamic, with the ability to autonomously fulfill specific tasks, requiring only high level engineering to combine and re-combine the modules to execute a complete or overall production scheme. This allows a high level of customization and re-use of modules.

In this dynamic and flexible systems where communication paths are not pre-defined, and where production schemes are everchanging, it becomes difficult to detect malicious behavior. At the same time, the attack surface and complexity of the system is increasing, raising the risk of a legitimate module/device being compromised within such systems. A compromised module/device, controlled by a malicious actor, may cause a significant damage, not only economic for the factory owner, but also physical on e.g., humans, machinery and the environment. The impact may be direct, e.g., the opening of a valve may overfill a tank or turning on heating in an empty reactor may cause a fire. Impact could also be indirect, e.g., changing ratios of materials used to produce a medicine may render it harmful. The direct causes are usually mitigated by implementations of secondary safety measures, while indirect causes may be more difficult to detect and mitigate.

There is thus a need in the industry for applying a strict and specific access control to the modules in a modular automation system.

An object of the present invention is to overcome at least some of the above problems, and to provide an access control policy within a modular automation system which, at least to some extent, is improved compared to prior art solutions. This, and other objectives, which will become apparent in the following are accomplished by means of a method for managing access control within a modular automation system, and an automation security system for a modular automation system.

According to a first aspect of the present invention, a method for managing access control within a modular automation system in accordance with claim <NUM> is provided. The modular automation system includes at least two automation modules, wherein each automation module is associated with an operation or a set of operations for carrying out a specific task, the method comprising, inter alia:.

Hereby, each automation module is strictly controlled by an associated processing step, and thus actions outside of the active schema is prohibited. Based on the present access control policy (i.e. the rules of privileges), it is possible to grant only those privileges prescribed by the processing needs. In other words, access to operations or data is only allowed to privileged entities, and a restricted access control policy is provided. This enables reduced harm caused by a malicious actor in the system, as access to modules/devices/operations or data is only allowed to privileged entities, i.e. based on the privileged associations. Moreover, such restricted access control policy increases the visibility of an malicious actor, as denied access control requests are typically monitored e.g. using a Security Information and Event Monitoring (SIEM) system.

By using the processing steps of the modular automation system as basis for the access control policy to the automation modules, the risk, and associated impact, of a control takeover by a malicious actor can be reduced.

According to at least one example embodiment, the automation modules are simply referred to as modules within the modular automation system. Thus, modules and automation modules are used interchangeably throughout the application text. The term "automation" in the automation modules, is referring to the fact that each module has the ability to fulfill specific associated tasks, possibly independently of other modules in the automation modular system. The automation modules may e.g. a standardised autonomous modules, described e.g. as Module Type Packages, MTPs. An automation module may comprise one or more devices, and any auxiliary equipment needed for the device(s) to perform the operation, or set of operations, associated with the specific task of the particular automation module. In other words, each automation module is adapted to carry out the operation, or set of operations, associated with the corresponding specific task.

It should be understood that the at least two automation modules, when put together in the modular automation system, may operate together such that the specific tasks of the automation modules co-operate to provide the common process, (or overall process or overall sub-process). Such common process is typically defined or described by the various processing steps, wherein each processing step comprises one or more of the specific tasks of the automation modules. The order of such processing steps may be summarized in a schema (which may be referred to as a workflow description, protocol or recipe). Stated differently, the execution of a workflow in modular automation system is described by the schema, with different processing steps comprising a set of specific tasks that one or more modules are configured to perform. Moreover, as more thorough described below but briefly mentioned here, the common process may be a sub-process, and part of an overall process of the modular automation system, wherein such overall process comprises a plurality of common processes carried out by various automation modules according to corresponding schemas. Furthermore, each automation module may be configured to carry out more than one specific task, i.e. the associated operation or a set of operations may be for carrying out a plurality of specific tasks.

According to the invention, the privilege associations are generated privileges between each processing step and one or more of the automation modules. In other words, privileges, or rights to perform actions or access data, are generated by associations between each processing step and one or more of the automation modules needed to carry out the particular processing step. Moreover, by basing the privilege associations on the processing steps, control of the automation modules beyond the schema is not possible. The steps of generating privilege associations, and generating an access control policy based on the privilege associations, may be referred to an automatic generation of an access control policy. Typically, if a schema is updated, the privilege associations associated with the updated schema are updated together with an update of the access control policy.

According to the invention, the privilege associations comprise the specific task of the automation module in the corresponding processing step. Thus, each privilege association is built up by the particular processing step, the automation module(s) to be used during the processing step, and any associated specific task needed to fulfil the processing step. Alternatively, or stated differently, the generation of the access control policy comprises generating privilege associations between the processing steps and corresponding automation module by the corresponding specific task(s).

According to at least one example embodiment, the access control policy may be described as a set of rules or directions related to privileges, governing access control models.

According to at least one example embodiment, the modular automation system comprises a central operating unit configured to communicate with each one of the automation modules, wherein the method further comprises the step of.

Hereby, an efficient way of controlling the operation of the automation modular system is provided.

According to at least one example embodiment, the access control to the automation modules by the central operating unit is limited by the access control policy.

According to at least one example embodiment, the central operating unit is an orchestrator.

According to at least one example embodiment, the modular automation system comprises a plurality of interconnected automated modules, or a plurality of interconnected sub-sets of automated modules (e.g. each sub-set having at least two automated modules co-operating as previously described). Alternatively, or additionality, the modular automation system comprises a plurality of central operating units (or orchestrators), wherein each central operating unit is configured to executing the particular schema associated with corresponding automation modules in accordance with the generated access control policy. Hereby, the automated modules may be directed to perform their specific tasks at any given time.

Thus, a modular automation system may be comprised of a number of interconnected automation modules on a physical layer performing the actual processing, and a number of central operating units directing the automation modules on the specific tasks to perform at any given time. The actions to perform are thus described by the schema. The modular automation system may be operated according to a plurality of schemas. The activity of formulating a schema may be allocated to integration engineering, typically executed by an expert on the specific process described by the schema. Formulating the schema does not need direct access to a specific physical function of a module. The task of schema activation is allocated to operational engineering, typically being performed by an operator. This task includes designating which modules (and possibly the central operating unit) that will actually be used for production in the modular automation system.

According to at least one example embodiment, the same automation modules are configured to be operated by at least two different schemas. According to such embodiments, each automation module can typically only be operated according to one schema at a time.

According to at least one example embodiment, the access control policy for the automation modules is implemented into a policy data unit. According to such embodiments, the method may further comprise the step of accessing the access control policy of the policy data unit, and implementing it by the central operating unit during the step of executing the schema.

According to at least one example embodiment, the step of executing the schema by the central operating unit comprises applying the principle of least privilege in the access control for the automation modules.

Hereby, the operation is controlled such that only the particular automation module(s) necessary at the time (i.e. at a certain point in the schema) for carrying out the particular processing step is allowed to be accessed. That is, the central operating unit is only allowed to perform a certain specific task when fulfilling the access control policy.

According to at least one example embodiment, the access control policy is based on an attribute-based access control, ABAC.

Hereby, the access control policy, and the privilege associations, are based on attributes, which is well suited for privileging connecting the automation modules with the processing steps. In other words, the model used for access control is ABAC. As an alternative to the attribute-based access control, other types of identifiers can be assigned to the processing steps and/or automation modules, for example based on roles or access control lists, ACL.

According to at least one example embodiment, the method further comprises:.

wherein the step of generating privilege associations for each processing step comprises privileging each specific task with a first type attribute and a second type attribute.

By assigning attributes to the articles (automation modules and processing steps), the privilege associations can easily be set up based on the attributes. In other words, privileges to execute operations are modeled as associations between attributes of the first and second types. For example, the first type association may be a subject association, and the second type association may be an object association.

According to at least one example embodiment, the principle of least privilege is embodied by utilizing said attributes.

According to at least one example embodiment, the step of generating privilege associations, comprises associating a respective first type attribute with a second type attribute by the specific task needed to carry out the particular processing step. Naturally, more than one automation modules, and more than one specific task, may be included to carry out a processing step. Moreover, more than one specific task may be included in one privilege association.

According to at least one example embodiment, the method further comprising assigning each attribute with a policy class.

By assigning each attribute to a specific policy class, a grant for a privilege, for example a grant for performing a specific task of a particular automation module (first type attribute) in a certain processing step (second type attribute), may be given only if the attributes are assigned to the same policy class.

According to at least one example embodiment, the schema is a sequential function chart, SFC.

This provides a well defined and suitable set-up for describing, and discretizing, the various processing steps. For such embodiments, the automation modules typically comprise programmable logic controllers, PLC, based on the SFC or another programmable component configured to execute the schema. The PLC or programmable component may be configured to communicate to, and control, other assets within the automation modular system.

According to at least one example embodiment, the method further comprises the steps of:.

Hereby, the grant of privilege associations based on an inactive schemas are avoided, which further strengthens the access control policy. According to at least one example embodiment, a previous deactivated schema can be re-activated, whereby a new generation of privilege associations need to be performed.

According to at least one example embodiment, the generated access control policy is based on next generation access control, NGAC or eXtensible Access Control Markup Language, XACML.

This provides a well defined and suitable set-up for describing, and presenting, the access control policy. Thus, according to at least one example embodiment, the method according to present invention may be formalized by an SFC model as input and with an NGAC graph with access privilege information as the resulting output.

According to at least one example embodiment, the automation modules may be re-arranged in order to perform different common processes.

Stated differently, at least the step of generating an access control policy may be based on re-arrangeable automation modules.

According to at least one example embodiment, said common process is a first common process and said schema is a first schema, and the at least two automation modules are operable according to a second common process corresponding to a second schema different to said first schema, wherein the method further comprises:.

Thus, the method provides a dynamic and adaptable means for generating and managing an access control policy. Note that the specific tasks of each automation module may be the same in the first and second common process.

According to at least one example alternative embodiment, the same generated access control policy is used for the first and the second common process. For such example embodiment, as the access control policy is based on the privilege associations for each processing steps, the order of the processing steps may be varied without the need to change the access control policy. Thus, a versatile means for managing and generating access control is provided.

According to at least one example embodiment, as mentioned previously, each automation module may be a standardized autonomous module, e.g. MTPs. The MTPs can be dynamically combined and recombined to perform different collaborate operations, i.e. different common processes.

According to at least one example embodiment, each automation module is associated to a respective network pathway to access, or provide access to, the central operating unit. Thus, the automation units may be configured to communicate and cooperate with other network device(s) across the network.

According to one example embodiment, the method is a method for facilitating automation security for a modular automation system to mitigate unwanted intrusions or attacks from an associated network that may affect the automation modules.

According to at least a second aspect of the present invention, an automation security system for a modular automation system including at least two automation modules, wherein each automation module is associated with an operation or a set of operations for carrying out a specific task, in accordance with claim <NUM> is provided. The automation security system comprising, inter
alia:.

Effects and features of this second aspect of the invention are largely analogous to those described above in connection with the first aspect of the invention. Embodiments mentioned in relation to the first aspect of the invention are largely compatible with the second aspect of the invention, of which some are exemplified below, but for which the advantageous effects are not repeated again.

For example, the system further comprises.

wherein the central operating unit is adapted to execute the schema in accordance with access control policy.

According to at least one example embodiment, the access control to the automation modules is based on an attribute-based access control, ABAC.

According to at least one example embodiment, the schema is a sequential function chart, SFC, and the central operating unit is configured execute the SFC, and/or wherein the access control policy is based on next generation access control, NGAC or eXtensible Access Control Markup Language, XACML.

According to at least one example embodiment, the system is configured to upon deactivation of a schema, remove the privilege associations related to the deactivated schema.

According to at least one example embodiment, the central operating unit is adapted to execute the schema while utilizing the principle of least privilege in the access control for the automation modules.

According to at least one example embodiment, the system is configured for automation modules which may be re-arranged in order to perform different common processes.

According to at least one example embodiment, said common process is a first common process and said schema is a first schema, and the at least two automation modules are operable according to a second common process corresponding to a second schema different to said first schema, and wherein the data unit is adapted to generate updated privilege associations for each processing step with one or more automation modules based on the second schema, and to generate an updated access control policy for the automation modules based on the updated privilege associations.

According to at least one example embodiment, the system is configured to carry out the method according to the first aspect of the invention.

Any standard or non-standard languages or policies mentioned in the present application are to be based on instructions valid on the date of priority of the present application.

These and other aspects of the present inventive concept will now be described in more detail, with reference to the appended drawings showing an example embodiment of the inventive concept, wherein:.

In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular components, interfaces, techniques, etc. in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well known devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail.

<FIG> schematically shows an access control architecture applicable to the present invention. In addition to the generation of access control model policies, policy enforcement is an important characteristic of an access control structure. <FIG> depicts a typical architecture <NUM> that describes the entities involved in an access control enforcement architecture. The architecture <NUM> in <FIG> comprises a subject <NUM>, an administrator <NUM>, a policy enforcement point, PEP, <NUM>, a policy decision point, PDP, <NUM>, a policy information point, PIP, <NUM> and a policy administration point, PAP, <NUM>. Moreover, in <FIG>, policy data <NUM> and a resource <NUM> are shown. The policy data <NUM> may e.g. be comprised in a policy data unit as described below, and the resource <NUM> may e.g. be one of the automation modules, also described below.

For the present access control mechanism to work properly, the only way for the subject <NUM> to access the resource <NUM> is through the policy enforcement point <NUM>. Therefore, the policy enforcement point <NUM> is preferably kept physically close to the resource <NUM>, typically implemented on a device/unit in the resource <NUM>. In general, a privilege request is initiated by e.g. the subject <NUM> and thereafter the policy enforcement point <NUM>, asks the policy decision point <NUM> for a decision defining whether the request shall be granted or not. To answer the request, the policy decision point <NUM> queries policy data <NUM> through the policy information point <NUM>. Policy data <NUM> is administered through the policy administration point <NUM> by the administrator <NUM>. The actual placement and implementation of these policy interaction points <NUM>, <NUM>, <NUM>, <NUM> are known to a skilled person, as it influences how well the access control mechanism functions and scales. Moreover, in the architecture <NUM> of <FIG>, a prerequisite for a secure access control is that identities of all involved entities can be trusted. Secure authentication of entities can be achieved using a number of methods known to the skilled person, including utilizing x. <NUM> certificates.

<FIG> schematically illustrates an automation security system <NUM> for a modular automation system <NUM>. The modular automation system <NUM> in <FIG> comprises a first automation module <NUM> and as second automation module <NUM>, wherein each one of the first and second automation modules <NUM>, <NUM> is configured to carry out a specific task. Each specific task may in turn be built up by an operation, or a set of operations, performed by a device or devices within the respective module <NUM>, <NUM>. For example, the first automation module <NUM> may be configured to carry out a first specific task. In order to perform the first specific task, the first automation module <NUM> comprises a first device configured to carry out a first set of operations in order to fulfil the first specific task. Correspondingly, the second automation module <NUM> is configured to a carry out a second specific task. Each one of the first and second automation module <NUM>, <NUM> may be configured to carry out more than one specific task. The modular automation system <NUM> is configured to carry out a common process in which the first and second automation modules <NUM>, <NUM> cooperates. Such common process typically comprises a plurality of processing steps, here a first processing step <NUM> and a second processing step <NUM> wherein each of the first and second processing steps <NUM>, <NUM> comprises one or more of the specific tasks, here the first and second specific tasks, respectively. At least the order of the processing steps <NUM>, <NUM> can be described in a workflow process scheme <NUM>, here referred to as a schema <NUM> being a sequential function chart, SFC. In <FIG>, the first processing step <NUM> is comprised of the first specific task, indicated by dashed line <NUM>, carried out by the first automation module <NUM>. However, it should be noted that the first processing step <NUM> may comprise more specific task, e.g. carried out by another automation module. Moreover, the second processing step <NUM> is comprised of the second specific task, indicated by dashed line <NUM>, carried out by the second automation module <NUM>. Correspondingly, it should be noted that the second processing step <NUM> may comprise more specific task, e.g. carried out by another automation module. In <FIG>, the first processing step <NUM> is carried out prior to the second processing step <NUM>.

The automation security system <NUM> comprises a central operating unit <NUM> configured to communicate with each one of the first and second automation modules <NUM>, <NUM>. Moreover, the central operating unit <NUM> is configured to execute the schema <NUM> of the common process of the modular automation system <NUM>, as previously described, and thus configured to execute the SFC. The automation security system <NUM> further comprises a data unit <NUM> or data unit arrangement <NUM> configured to generate privilege associations for each processing step <NUM>, <NUM> with the automation modules <NUM>, <NUM>, based on the schema <NUM>, and to generate an access control policy for the automation modules <NUM>, <NUM> based on these privilege associations (described in further detail in <FIG> and <FIG>). The data unit <NUM> or data unit arrangement <NUM> typically comprises a data policy unit comprising at least the generated access control policy. The central operating unit <NUM> is adapted execute the schema <NUM> by accessing the automation modules <NUM>, <NUM>, in accordance with the access control policy of the data unit <NUM>. Note that the data unit <NUM> may include one or more of the PEP <NUM>, PDP <NUM>, PIP <NUM> and PAP <NUM> of <FIG>. Alternatively, the automation modules <NUM>, <NUM> may communicate with the PEP and further to verify that an action requested by the central operating unit <NUM> falls within the access control policy.

According to at least one example embodiment, the first processing step <NUM> and the first specific task <NUM> is performed prior to the second processing step <NUM> and the second specific task <NUM>, according to a first schema <NUM>. Thus, the first automation module <NUM> is activated prior to the second automation module <NUM>. However, the order of the processing steps <NUM>, <NUM> may be changed, and the second processing step <NUM> may be carried out prior to the first processing step <NUM>, according to a second schema. For such embodiments, the central operating unit <NUM> is configured to execute the first schema prior and is configured to execute the second schema. Typically, when a new schema is introduced in the system, here the second schema, the access control policies is automatically updated based on the new schema. For some cases, the same access control policy can be used when executing both the first schema and the second schema.

The number of automation modules, and processing steps, shown is exemplifying. It should be realized that there may be more automation modules in the automation module system, as well as more processing steps (but also fewer). However, all automation modules in the automation module system are members of a common collaborative group, i.e. a group collaborating in performing the common process, such as e.g. for producing a product.

In <FIG>, schematically illustrates another embodiment of the invention. In <FIG>, an access control policy <NUM> and the modular automation system <NUM> are described as an NGAC policy using attributes, e.g. ABAC, assigned to the different entities. Hence, the access control to the automation modules <NUM>, <NUM>, <NUM>, <NUM> in <FIG> is based on an attribute-based access control, and the access control policy is based on NGAC.

The access control policy <NUM> of <FIG> are described with reference to an example of a modular automation system <NUM> for producing a specific product. In more detail, the automation modular system <NUM> comprises a first automation module <NUM>, here being a reactor, a second automation module <NUM>, here being a distiller, a third automation module <NUM>, here being a filter, and a fourth automation module <NUM>, here being a packaging unit. The common process, or here overall process, of the modular automation system <NUM> can be described according to the following schema:.

The above schema can be executed by a central operating unit <NUM> in a corresponding manner as described with reference to <FIG>.

The above schema can be described using SFC, as shown in <FIG>, together with refence to the automation modules in <FIG>. An SFC typically comprises processing steps and transitions. Each processing step in the schema describes the specific task(s) or operations relevant to perform in that particular processing step. Moreover, each processing step contains zero or more outward directed transitions, shown in <FIG> as arcs describing the conditions for continuing to the next processing step(s). That is, the arc represents a transition point to one or more subsequent processing steps. In the case of more than one processing step, the following processing steps are executed in parallel as soon as the condition annotated on the transition enabling that processing step is fulfilled. To join a parallel execution, two (or more) edges point to the same processing step. In such join-cases, conditions for all edges pointing at the same processing step must be fulfilled for it to be triggered. It should be noted that an SFC may contain loops (not shown in <FIG>).

The SFC begins with a simple start operation in which no operation is active. Subsequently, the reactor <NUM> is filled according to first processing step in the above schema, here represented by step <NUM>'. Next, as the condition of filling the reactor is met, the reactor <NUM> mixes and heats the mixture according to the second processing step in the above schema, here represented by step <NUM>'. Correspondingly, when the condition for step <NUM>' is met, the process continues with emptying the reactor <NUM> and begin with distillation according to the third processing step in the above schema, here represented by step <NUM>'. When the distillation is completed (i.e. condition for step <NUM>' fulfilled), the two subsequent processing steps in the schema above, i.e. the fourth and fifth processing steps, here represented by the step <NUM>' (filtration) and step <NUM>' (packaging), respectively, can be carried out in parallel. In more detail, in step <NUM>', the filter <NUM> filters the distillate from step <NUM>', and in step <NUM>', the packaging unit <NUM> packages the final product. Thus, it should be understood that step <NUM>' and step <NUM>' can be executed in parallel, i.e., the packaging <NUM>' can start as soon as there is a sufficient amount of the final product available. The SFC ends with and end operation in which no operation is active.

Returning to <FIG>, each of the automation modules <NUM>, <NUM>, <NUM>, <NUM>, commonly gathered in box <NUM>, are assigned with a module attribute <NUM>. In more detail, the reactor <NUM> is assigned a reactor attribute <NUM>, the distiller <NUM> is assigned a distiller attribute <NUM>, the filter <NUM> is assigned a filter attribute <NUM> and the packaging unit <NUM> is assigned a packaging unit attribute <NUM>.

Correspondingly, each of the processing steps in the schema <NUM>, here referring to the processing steps <NUM>', <NUM>', <NUM>', <NUM>', <NUM>' described with reference to <FIG>, is assigned with a processing step attribute. In more detail, the processing step <NUM>' is assigned with first processing step attribute <NUM>, the processing step <NUM>' is assigned with second processing step attribute <NUM>, the processing step <NUM>' is assigned with third processing step attribute <NUM>, the processing step <NUM>' is assigned with fourth processing step attribute <NUM>, and the processing step <NUM>' is assigned with fifth processing step attribute <NUM>. Also the central operating unit <NUM> is assigned a central operating unit attribute <NUM>.

Moreover, specific tasks, or operations, of the automation modules <NUM>, <NUM>, <NUM>, <NUM> which are carried out to perform the processing steps <NUM>', <NUM>,, <NUM>', <NUM>', <NUM>' are indicated by dashed lines connecting the processing step attributes, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> with the module attributes <NUM>, <NUM>, <NUM>, <NUM>. In more detail, the first processing step attribute <NUM> is connected to the reactor attribute <NUM> by the specific task of filling <NUM> the reactor <NUM>, the second processing step attribute <NUM> is connected to the reactor attribute <NUM> by the specific task of mixing and heating the mixture <NUM> in the reactor <NUM>, the third processing step attribute <NUM> is connected to the reactor attribute <NUM> by the specific task of emptying <NUM> the reactor <NUM>, and is connected to the distiller attribute <NUM> by the specific task of distilling <NUM> in the distiller <NUM>, the fourth processing step attribute <NUM> is connected to the distiller attribute <NUM> by the specific task of emptying <NUM> the distiller <NUM>, and is connected to the filter attribute <NUM> by the specific task of filtering <NUM> by the filter <NUM>, the fifth processing step attribute <NUM> is connected to the packaging unit attribute <NUM> by the specific task of packaging <NUM> by the packaging unit <NUM> (e.g. filling bottles with the final product).

Each combination of processing step attribute, module attribute and interconnected specific task or operation as present above may be described as a privilege association in the access control policy. For example, a first privilege association of the first processing step attribute <NUM> and the reactor attribute <NUM> by the specific task of filling <NUM> the reactor <NUM>, may be comprised in the access control policy. Another example is a second privilege association of the second processing step attribute <NUM> and the reactor attribute <NUM> by the specific task of mixing and heating the mixture <NUM> in the reactor <NUM>. Further privilege associations can be described based on each combination of processing step attribute, module attribute and interconnected specific task or operation.

It should be noted that instead of using NGAC, the access control policy may be based on another standard or language, e.g. extensible Access Control Markup Language, XACML.

The invention will now be described with reference to the flow chart in <FIG>. The flow chart schematically illustrates the steps of a method for managing access control within a modular automation system, as the modular automation system <NUM> in <FIG> or modular automation system <NUM> in <FIG>. Thus, the modular automation system comprises at least two automation modules, wherein each automation module is associated with an operation or a set of operations for carrying out a specific task.

In step <NUM>, a schema of a common process comprising at least the order of processing steps of the modular automation system is received. The schema may e.g. be the schema <NUM> of <FIG>, or schema <NUM> of <FIG> (representing the SFC described with reference to <FIG>). Thus, each processing step comprises one or more of the specific tasks of the automation modules, <NUM>. Preferably, the schema is a sequential function chart, SFC. The step <NUM> may be implemented by any suitable means, e.g. comprised in data unit <NUM> or data unit arrangement <NUM> of <FIG>.

In step <NUM>, privilege associations for each processing step with one or more automation modules, based on said schema, are generated. The privilege associations may e.g. be generated as described with reference to <FIG>.

In step <NUM>, an access control policy for the automation modules based on the privilege associations are generated. The access control policy may e.g. be similar to the access control policy <NUM> of <FIG>. Such access control policy may be comprised in the policy data <NUM> of <FIG> and stored in a data unit <NUM> shown in <FIG>. Hence, the generated access control policy may be based on next generation access control, NGAC.

For embodiments in which a central operating unit is configured to communicate with each one of the automation modules, such as central operating unit <NUM>, <NUM> (in <FIG> and <FIG>) the method may comprise the step <NUM> of executing the schema received in step <NUM> by the central operating unit in accordance with the generated access control policy of step <NUM>.

According to at least one example embodiment, the step <NUM> comprises applying the principle of least privilege in the access control for the automation modules. In other words, the execution of the common process is controlled such that only the particular automation module attribute(s) necessary at the time for fulfilling the specific task in the particular processing step (i.e. at a certain point in the schema) is allowed to be accessed. That is, the central operating unit is only allowed to perform a certain specific task at a time in accordance with the schema, when fulfilling the access control policy. The principle of least privilege may be implemented in the access control policy. Thus, for the embodiments shown in <FIG> and <FIG>, the central operating units <NUM>, <NUM> are operated based on the principle of least privilege in the access control for the automation modules during execution of the schema <NUM>, <NUM>.

Step <NUM> and/or step <NUM> may be carried out by utilizing an attribute-based access control, ABAC, as described with reference to <FIG>, and may be generated by the data unit <NUM> of <FIG>. Thus, the method may comprise the step 502A of assigning each processing step with an attribute of a first type, i.e. a processing step attribute (as attributes <NUM>, <NUM>, <NUM>, <NUM>, <NUM> in <FIG>), and step 502B of assigning each automation module with an attribute of a second type, i.e. a module attribute (as attributes <NUM>, <NUM>, <NUM>, <NUM> in <FIG>). Hereby, the step <NUM> may comprise privileging each specific task with a first type attribute and a second type attribute.

Optionally, the method of <FIG> comprises the step <NUM> of deactivating a schema, and step <NUM> of removing the privilege associations for the deactivated schema (i.e. the privilege associations generated in step <NUM>). Thus, for the embodiments shown in <FIG> and <FIG>, the central operating units <NUM>, <NUM> are configured to upon deactivation of a schema, remove the privilege associations related to the deactivated schema.

Optionally, the method in <FIG> is applied to an automation module system in which the automation modules is re-arrangeable in order to perform different common processes, as described with reference to <FIG>. Thus, the common process may be referred to as a first common process, and the schema may be referred to as a first schema, and the at least two automation modules may operable according to a second common process corresponding to a second schema different to the first schema. Thus, the method may comprise the step 507A of executing the first schema, and the step 507B of executing the second schema. For the second schema, the steps <NUM>, <NUM> and <NUM> are typically repeated to generate an updated access control policy for the second schema. Such update may be carried out by utilizing data unit <NUM>.

It should be understood that the method described with reference to <FIG>, or at least some of the steps of the method, may be implemented in one or more control units of an automation security system or modular automation system, such as e.g. data unit <NUM>.

The above mentioned functionality of the entities be implemented using hardware and software resources known to the skilled person, e.g. associated hardware resources such as e.g. processing units being provided in the form of one or more processors together with process software including computer program memory including computer program code for performing its function. As an alternative it may be provided in the form of an Application Specific Integrated Circuit (ASIC) or Field-Programmable Gate Array (FPGA). This computer program code may also be provided on one or more data carriers which perform the functionality of the entities when the program code thereon is being loaded in a processing entity. One such data carrier with computer program code, is in the form of a CD ROM disc. Such computer program may as an alternative be provided on a server and downloaded therefrom into the processing entity in question.

Claim 1:
A method for managing access control within a modular automation system including at least two automation modules, wherein each automation module is associated with an operation or a set of operations for carrying out a specific task, the method comprising:
- receiving a schema of a common process comprising at least the order of processing steps of the modular automation system, each processing step comprising one or more of the specific tasks of the automation modules;
- generating privilege associations for each processing step with one or more automation modules, based on said schema, each privilege association being built up by the particular processing step, the automation module or modules to be used during the processing step, and any associated specific one or more tasks needed to fulfil the processing step;
- generating an access control policy for the automation modules based on the privilege associations such that access is only allowed based on the privileged associations,
wherein the privilege associations are generated privileges between each processing step and one or more of the automation modules.