WO2017121928A1

WO2017121928A1 - Executing operation to service in industrial automation system

Info

Publication number: WO2017121928A1
Application number: PCT/FI2017/050014
Authority: WO
Inventors: Ale Borg; Henry Haverinen; Jyrki Yli-Nokari
Original assignee: Valmet Automation Oy
Priority date: 2016-01-13
Filing date: 2017-01-12
Publication date: 2017-07-20
Also published as: FI20165019A

Abstract

There is provided an industrial automation system and a method, where services provided by components of the industrial automation system are defined. Roles for a client to execute operations to the services are defined. A role includes one or more constraints and permissions for accessing the services. Valid constraints for the client are determined. Roles that have valid constraints are determined as active roles. At least one operation directed to at least one resource of a service is executed, when at least one of the active roles has permissions required by the at least one resource.

Description

EXECUTING OPERATION TO SERVICE IN INDUSTRIAL AUTOMATION SYSTEM

FIELD

The present invention relates to executing an operation to a service in an industrial automation system and particularly to authorization of the operation.

BACKGROUND

An industrial automation system requires very specific and flexible access control. The same automation platform for industrial automation systems needs to work in very heterogeneous environments across industries and across customers. Permissions granted to a user of the industrial automation system may depend for example on the location of the user. In one example of the location, when the user's location is in a control room, the user may have higher permissions than, when the user is outside the control room. In one industrial automation system the location of the user can be determined based on the Internet Protocol (IP) address of the user's device. However, in another industrial automation system, users have IP addresses allocated dynamically from the same pool of addresses regardless of the user's location, whereby the IP-based location of the user does not serve for granting permissions in the industrial automation system, since the IP-address of the user can not be identified to be specific to any particular location in the deployment area of the industrial automation system.

Role-based access control (RBAC) is a concept for controlling access to resources. Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. (July 2000); "The NIST Model for Role Based Access Control: Toward a Unified Standard"; 5th ACM Workshop Role-Based Access Control, pp. 47-63; discloses a unified model for RBAC. BRAC promotes security administration at a business enterprise level. The basic principle is to establish permission based on the functional roles in the enterprise, and then appropriately assign users to a role or a set of roles. In RBAC access decisions are based on the roles individual users have as part of an enterprise. The roles could present the task, responsibilities and qualifications associated with an enterprise. Accordingly, in BRAC the main principle is that permissions are assigned to roles rather than directly to users. It is possible to apply restrictive rules known as constraints in the role activation to implement finer grained policies such as separation of duties. For example, a constraint may prevent the user from having a role that allows creating a login account and simultaneously another role to authorize the account creation.

However, factors used for determining which permissions are applied to a user in one industrial automation system cannot be directly applied to another industrial automation system. The number of factors to be considered in assigning permissions to users is high, when heterogeneous environments and customer needs are supported. However, due to the high number of factors, the automation platform becomes easily very complex.

BRIEF DESCRIPTION

An object of the present invention is to alleviate at least part of the above disadvantages. The present invention is characterized by the features of the independent claims. Preferred embodiments of the invention are disclosed in the dependent claims.

An advantage of the present invention is that role activation of user sessions is flexible. Almost arbitrary customer requirements can be met by the system by implementing a customer-specific constraint service.

Another benefit of the present invention is that definition of roles and constraints can be distributed between different parts of the industrial automation system, such as the platform level and application level. Thus, the roles and constraints may be implemented for instance in such a manner that no changes are required to the automation platform in order to add support for new kinds of access control features. This makes it possible for the automation projects to extend access control. The constraint services can be implemented with corresponding Human Machine Interface (HMI) pages, so that rights can be observed, requested, grabbed etc.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following embodiments of the invention are described with reference to the attached drawings in which,

Figure 1 shows an example of an industrial automation system platform according to an embodiment; Figure 2 illustrates operating an industrial automation system, according to an embodiment;

Figure 3 illustrates a method for authorizing operations directed to a service of the industrial automation system, according to an embodiment;

Figure 4 illustrates implementation of the field devices as software objects in an industrial automation system according to an embodiment;

Figures 5, 6 and 7 illustrate examples of software objects for providing components as services in an industrial automation system; and

Figure 8 illustrates an example of user interface for editing user groups in an industrial automation system.

DETAILED DESCRIPTION

An industrial automation system may be used for controlling industrial processes such as manufacturing, production, power generation, fabrication, and refining processes. An industrial process may run in continuous, batch, repetitive, or discrete modes. An industrial automation system may be distributed to several layers or levels, such as automation platform level and automation application level.

Automation platform is typically generic and it can be used similarly in many deployments. Automation platform may consist of engineering and configuration tools by which an engineer can design automation applications. Automation platform tools may comprise at least one of the following: a Function Block Diagram design tool, a structured text programming tool and a user interface design tool. On the other hand, an automation platform may also comprise runtime components such as PLC, Process Control Station, and Human-Machine Interface that can be used to execute the automation application and visualize it to the user.

Automation application, on the other hand, may comprise a configuration that has been created using the tools of the automation platform. Automation application can comprise at least one of the following: a function block diagram, a structured text program, and a user interface design. Depending on the embodiment, an automation application can be unique and completely specific to a customer deployment, or it may also be possible to reuse an automation application across customers and deployments. Components of the industrial automation system may comprise user interface components, process components and components that support both of the previous. The components may implement services that may be accessible to other components and/or services in the industrial automation system. A component or a part of the component may be implemented as software object that may have an operational interface for providing the component as a service to other components in the industrial automation system. The software objects may be distributed and hierarchical object- oriented entities. The operational interface may also be capable of receiving services from one or more other components. The services comprise one or more resources that are specific to the type of the service. In one example, a process component may be implemented as a service comprising process data as a resource. The resources of the services may be accessed by other services of the industrial automation system via the operational interface. The operational interface may provide access to a service in response to a direct request for the service and/or a subscription to the service. A component subscribed to a service may be sent updates of the subscribed service without dedicated requests.

The implementation of the components may follow a client-server operation model, where components acting as clients, in short clients, may issue requests to components acting as servers, in short servers. A server may process a request for a service received from a client. The processing may comprise authorizing the request and/or executing an operation directed to a service. The operation may be executed if the request is authorized, but the operation may not be executed if the request is not authorized. An example of the client-server operation model is provided by operation model followed by a Hyper Text Transfer Protocol (HTTP) client and a HTTP server for requests from the HTTP client and responses from the HTTP server. The HTTP client and HTTP server may have a REpresentational State Transfer (REST) Application Protocol Interface (API) for operations such as reading, writing, removing and adding various types of resources. The HTTP client may issue a request for an operation using the REST API at the HTTP client and the HTTP server may receive the request and process the request using the REST API at the HTTP server.

A user interface component may refer to a functional entity in the industrial automation system that is capable of displaying a graphical user interface to a user. A process component may refer to a functional entity in the industrial automation system that is capable of controlling the industrial process and/or generating data from the industrial process. Components may be categorized user interface components if they are not process components. Examples of the process components comprise field devices such as actuators, valves, pumps and sensors.

Services and resources that are represented by the services may be implemented by the software objects in the industrial automation system. These services and resources may be published as names that can be referred to by other services and clients. Naming of the services may follow a custom naming convention, naming convention of the supplier of the automation system and/or a naming convention defined by administrator of the industrial automation system. The services may be provided using the client- server operation model, where the resources of the services may be accessed by using names of the resources. The naming of the resources may use a hierarchical model, analogously to the names of files in a hierarchical directory tree. The naming of the resources may also provide dynamic auto-discovery or browsing of the available resources by name. For example, a client may be able to dynamically discover whether any service has published names in a specific name hierarchy.

Clients, for example user interface components or services implemented by components of the industrial automation system, may be capable of executing operations directed to services in the industrial automation system. The operations may include, but not limited to:

- READ: return the value of a resource

- WRITE: update a resource

- CREATE: create a new resource. The name of the new resource can be provided either by the client or by the service

- REMOVE: remove a resource or a service

- SUBSCRIBE: constantly read the value of a resource or a service (keep track of the changes). The service may constantly update the client about the current value of the resource.

Additional query parameters can be added to the operations. For example, a READ operation may include parameters that request the service to filter the returned results to only include specific items. A client may execute an operation, e.g. READ, by referring to the name of the service. An example of the process component in an industrial automation system is an actuator. The actuator may be implemented as a service and the name of the actuator may be published such that one or more resources of the actuator may be accessed by the name of the actuator. The resources of the actuator may comprise measurements and settings, for example.

Figure 1 shows components of an industrial automation system according to an embodiment. The industrial automation system may comprise user interface components and process components. The user interface components may comprise an End-User Device (EUD) 102. The process components of the industrial automation network may comprise one or more process controllers 109a, 109b (PCs), for example referred to as Process Control Stations (PCSs). The EUD may serve as a user interface for initiating a user session in the industrial automation system and for executing operations directed to a component of the industrial automation system. For authorizing operations directed to a component of the industrial automation system based on active roles of the user, the industrial automation system may comprise components for supporting the user interface components and process components. The supporting components may comprise a session service 106, a user authentication service 110, a user and policy management (UPM) 114 and a constraint service 108.

The components of the automation system may be operatively connected by one or more communications networks 105 and communications protocols for transfer of data between the components. The communications networks may comprise a user network for connecting the EUD 102 to other components of the industrial automation system and an industrial automation network for communications and control of the industrial process served by the industrial automation system. The networks may be based on the standard Internet Protocol over Ethernet technology. The components may be implemented as software objects for providing services as described above. The components may follow the client-server operation model for data transfer between the components. In the client-server operation model a request from the client may cause a response from the server. The request and/or response may carry data between the client and the server and the components may be accessed by names of the resources hosted by the components.

The user network may be the network under whose service area the EUD may be located and where the industrial automation system, for example a human machine interface (HMI) server connected to the industrial automation system, may be discoverable to the EUD. The user network may be a public network such as the Internet. A telecommunications service provider, i.e. an operator, may sell subscriptions for users to obtain access to the user network.

The industrial automation network may be a private network. Compared to the public network, access to the industrial automation network may not be available to the public, but the access may be granted to personnel that have a direct role in the industrial automation system.

The End-User Device (EUD) 102 may be capable of displaying a graphical user interface to a user. The EUD may be for example a computing device connected to a display or having an integrated display. The display may form a part of the user interface of the computing device. The user interface may include, in addition to the display, input means that allow user to enter commands to the computing device. Examples of the input means include a keyboard, a touch screen, a button and a computer mouse. The touch screen may serve for both input means and as the display. The graphical user interface may be provided by one or more applications executed on the EUD and cause displaying the user interface. The applications may comprise a web browser, for example the Internet Explorer, Safari or Mozilla Firefox. Also further applications may be executed independently or as plugins to provide additional features to the applications such as the web browser. The applications may be executed on an operating system running on the EUD. Examples of the operating systems include Windows operating systems, Linux and OSX.

The EUD may be capable of connecting to the industrial automation system for example via the HMI server 104. When the EUD is connected to the HMI, the HMI may provide the EUD a graphical HMI user interface to the industrial automation system. The EUD and HMI may communicate using a client - server communications scheme, whereby one or more requests from the EUD may cause the HMI server to send data to the EUD such that the graphical HMI user interface is displayed in the EUD. Preferably the HMI server is a WebHMI server capable of providing the EUD the graphical user interface on a web browser executed in the EUD. The HMI server may store software components that may be delivered to the EUD for displaying the graphical user interface on the EUD. The software components may comprise one or more files that are executed separately or as components of one or more applications executed on the EUD such that the user interface may be displayed on the EUD.

The session service 106 may be capable of managing users' sessions. The session service may be responsible for keeping track of active sessions and determining the user's currently active roles. The session service may maintain information about a user's session, including for example the user's active roles per user's location, and expiration times of the role assignments. The roles may depend on dynamic constraints, and some of the dynamic constraints may be implemented using customer-specific services. A large automation system may include several instances of the session service. The session service may be hosted on the same server as the HMI server, but it should be appreciated that the session service may also be hosted on a separate server.

A user's membership to a role may be valid only when a certain constraint is true. Constraints may be applied by the session service before active roles are communicated by the session service to other services of the industrial automation system.

Constraints may comprise so called default constraints that may be implemented in an automation platform, and customer-specific constraints that may also be called custom constraints. In some embodiments, constraints may be complex and customer specific. Customer specific constraints may be referred to as custom constraints. Custom constraints may, thus, comprise customer-specific implementations of constraints, whereas implementations of default constraints may be built in to the automation platform. In some embodiments, however, a part of the custom constraints may be implemented in the automation platform as well. The custom constraints may enable almost arbitrarily complex customer-specific rules for determining the user's active roles.

The constraint service 108 may capable of exposing one or more dynamic attributes to the sessions. The constraint service may maintain information of one or more constraints and sessions subscribed to the constraint service. The constraints may comprise default constraints and custom constraints. The default constraints may be general constraints defined by the automation system supplier. The custom constraints may be identified on the basis of a specific naming convention applied to the customer constraints. The naming convention may provide that the custom constraints may be named after the customer name or a portion of the customer name, whereby the custom constraints may be identified from the default constraints. Alternatively, a specific prefix in the name hierarchy may be conventionally reserved for constraints. Accordingly, a session may be subscribed to one or more constraints of the constraint service. An update may be sent to the sessions that are subscribed to a specific constraint, when a state of the constraint is changed. The dynamic constrain service may be referred to from authorization related policies. On the other hand the constraint service may provide operations including, READ, WRITE, CREATE, REMOVE and/or additional queries to the constraints.

According to an embodiment, an automation platform may use names instead of addresses, such as IP addresses or another protocol or machine identifier addresses, for referring to application implementations. Instances of customer-specific automation application implementations can be referred to by a name in the runtime environment.

According to an embodiment, an automation platform may define interfaces to automation applications by name. Interfaces may define the names and data types of inputs and outputs. The interfaces may be defined as schemas or compound data types. The interfaces may have names by which they can be referred to. There may be multiple implementations that implement a given interface.

According to an embodiment, customer-specific constraints may be implemented as an automation application that can be referred to by a name.

According to an embodiment, a constraint implementation may be designed to have a single, global instance. According to an embodiment, the value of the constraint may, for instance, depend on the time of day or date. In such an embodiment a single instance is sufficient. In this case, an automation platform may refer to the custom constraint implementation by a name to read the value of the custom constraint. The data type of the constraint output can be a Boolean value that denotes whether the constraint is valid or not.

According to another embodiment, a constraint implementation can be designed to have multiple instances. In such an embodiment, for instance, there can be a separate constraint instance for each user session or for each user. According to an embodiment comprising a multiple instance constraint, the inputs of the constraint may comprise details of the user or user session. The value (output) of the constraint may in such an embodiment be a Boolean value that denotes whether the constraint is valid. In an embodiment, where a function block diagram is used, the inputs may comprise inputs to the function block diagram. According to an embodiment, where structured text is used, the inputs may comprise input variables to the structured text function block.

According to an embodiment, user session specific constraints may be based on for example whether an HTTPS client authentication was done.

According to an embodiment the custom constraint may comprise a multiple-instance custom constraint. In such an embodiment, the automation platform may then create new instances of the constraint by the name of the interface, and refer to the created instance of the constraint when evaluating the constraints for a certain user session. During runtime, the automation platform may then set the inputs of the custom constraint instance according to the user session or user details.

According to an embodiment, a custom constraint may be implement as a function block diagram, using a vendor diagram language or a standard function block diagram language, such as IEC 61131 -3. According to another embodiment, a custom constraint may be implemented using a Structured text application.

Examples of the constraints comprise at least one of a time of day, work shift information of the user, connection type of the client, location of the user, communications device type, operating responsibility of the user, authorization of the communications device, web browser type, and authentication information of the user.

The industrial automation system may comprise one or more user services for managing user accounts, managing account permissions and/or authentication of users. Examples of the user services comprise a user authentication service 110 and user and policy management (UPM) 114. The user authentication service 110, may be responsible for authenticating users. The authentication service may be connected to an external system such as Microsoft Active Directory. The user and policy management (UPM) 114 service may manage user accounts and permission, for example creating, removing and updating users, user groups, roles, permissions etc. In the UPM and the industrial automation system a single user may be represented by a user account. The user account may be assigned to a user group, whereby the user becomes a member of the group. A single user group may have one, two, three or practically any number of members. The user service may provide user accounts as a service to other services in the industrial automation system. Accordingly, in the industrial automation system services may issue operations on the user accounts using the client-server operation model subject to authorization of access to the user accounts.

A persistent storage service may be connected to the industrial automation network. The persistent storage service may be a general automation platform service that may be used by the services, e.g. the user services, to store persistent data about the users and the policies to be applied to users and/or user groups.

One or more services in the industrial automation network may be responsible for authorizing operations based on the user's active roles for the service's authorization area, and authorization policies.

The PCs connect field devices (FDs) to the industrial automation system. The PCs may be capable of serving data from the industrial process to the components, for example user interface components, of the industrial automation system. Field devices (FDs) may be connected to the PCs via field buses. Examples of the field devices comprise actuators, valves, pumps and sensors. Examples of field bus types include Foundation Fieldbus, Profibus and HART. One example of such a decentralized automation system is Valmet DNA (DNA, Dynamic Network of Applications) delivered by Valmet Corporation serve data from the industrial process to the user interface components.

Authorizing operations directed to a component of the industrial automation system based on active roles of the user may be facilitated by a global authorization policy. The global authorization policy may be distributed to all components of the Industrial automation system. The global authorization policy may specify permissions of each role to operate services and/or their resources in the Industrial automation system. The authorization policy to be applied to a specific user and session may depend on the physical location of the user. The user may be located for example in a certain control room, a process area, zone or communications network. The communications network may be a user network or an industrial automation network. The process area may refer to a segment of the industrial automation system, where the functions inside the segment are closely related in terms of the process. A zone may refer to a segment of the industrial automation system, where communications is restricted to one or more other zones of the industrial automation system.

Figure 2 illustrates operating an industrial automation system, according to an embodiment. The industrial automation system is illustrated with reference to components of the industrial automation system described with reference to Figure 1 above. A user may be connected to the industrial automation system by an EUD 102. The EUD may be a client of the HMI server such that the HMI may provide a graphical user interface to the industrial automation system by client-server communications between the EUD and the HMI server. The user interface may allow the user to enter commands directed to one or more services represented by graphical objects on the user interface. The client may be a web browser that may be served by a WebHMI server 104. Accordingly, the user interface may be provided on the web browser. The web browser may be executed on the EUD of the user. A session service 106 may manage a user's session and subscriptions of the session. The management of the sessions may comprise at least maintaining information for identifying sessions and details of the sessions. The information identifying the sessions may comprise session identifiers. The user's session may be subscribed 202 to the constraint service 108. The subscription to the constraint service may cause the session service to receive an update from the constraint service, when a state of a constraint in the user's session is changed. In this way changes in states of the constraints may be reflected to the user's session and authorization of operations in the user's session, whereby the session service may provide information for authorizing operations to a specific service and/or a resource in the industrial automation system.

The constraint service 108 may send an update 206 to the session service when a state of the constraint is changed. The update 206 may be sent after the constraint service has determined 204 a change in the state of the constraint. The sessions subscribed to the changed constraint may be determined in the session service such that the changed state of the constraint may be reflected to all the user sessions that have subscribed to the constraint service. In this way a single update from the constraint service may be sufficient for all the user sessions. The states of the constraint may include a valid and invalid constraint. The states may be expressed as bit values using the number of bits necessary for representing the states of the constraint. In one example of a location constraint, the state of the location constraint may be changed on the basis of the location of the user. In one example of changing a state of a location constraint, the constraint service may read the location of the user from the WebHMI or the constraint service may be subscribed to receive updates from the WebHMI for the location of the user, when the location of the user is changed. Depending on the type of the constraint, other factors than the location may be used instead or additionally to determine the state of the constraint as is apparent from the examples of constraints in Table 1 below.

The session service may receive the update 206 from the constraint service and apply 208 the update to the session. The applying may comprise storing information received in the update or storing information generated in response to the update, to the session. In this way sessions may be updated on the basis of the changed states of the constraint. The updated information may be used for managing the sessions in the session service. Examples of the information received in the update or information generated in response to the update may comprise a state of the constraint.

The user may operate 210 a service and one or more resources of the service in the industrial automation system via a graphical user interface on the web browser. Operating the service and its resources may comprise the user entering a command of the user on the user interface, for example. The command may be for example a mouse click targeted to the service or a resource of the service represented by one or more graphical objects on the user interface.

The WebHMI may determine 212 on the basis of the operation of user on the graphical user interface that the operation is directed to a specific service and/or a resource of the service in the industrial automation system. The operation directed to the specific service and/or resource may be referred to as an operation request. Examples of the resources comprise a user account, a measurement value and a setting of a component.

In response to the operation of the user on the graphical user interface, the WebHMI may send 214 information for identifying the user's session to the session service. In this way the WebHMI may consult the session service for obtaining a possible outcome of authorization of the operation towards the specific service and/or resource prior to issuing an operation request to the specific service and/or resource.

The infornnation for identifying the user's session to the session service may be sent 214 in an operation request. The session service may use the information obtained from the WebHMI to perform a lookup 216 for identifying the user's session. The lookup may produce details of the user's session that may be sent 218 to the WebHMI. The details of the user's session may comprise one or more from information identifying the user, information identifying one or more active roles of the user and a location of the user. The active roles may be defined per area, for example a process area. On the other hand the information sent to the WebHMI may additionally or alternatively comprise a possible outcome of authorization of the operation towards the specific service and/or resource.

The WebHMI may execute 220 the operation directed to the service and/or a resource of the service. The execution of the operation may comprise sending information indicating active roles of the user obtained from the session service to the operated service. The active roles may include active roles of the user per area. The operation may be executed using permissions of the active roles. The permissions for the roles may be defined by the global authorization policy. Since the permissions are defined for the roles, the definitions of the permissions may be re-used to groups of users. Depending on the permissions of the active roles, the operation directed to the service and/or its resources may be authorized and the user session may have access to the service and/or its resources, whereby the execution of the operation may be successful. However, if there are insufficient permissions, the operation may not be authorized and access is not granted to the user session, whereby the execution of the operation is unsuccessful. The permissions of the active roles may be sufficient for authorizing the operation, when the permissions required by the operated service and/or resources of the service are included in the permissions of the active roles of the user session.

In an embodiment, the execution of the operation may be conditional on the information received 218 from the session service indicating authorization of the operation. If the operation indicates that the operation would not be authorized, the execution of the operation may be omitted.

In an alternative embodiment of Figure 2, the WebHMI does not consult the session service in response to determining 212 the operation request, but it only includes an identification of the user's session in the operation request that it sends to the operated service and/or resource, i.e. the target service and/or resource. The target service and/or resource may send in response to the operation request a session lookup request to the session service, including the identification of the user's session. The target service and/or resource may receive the list of currently active roles per area from the session service. This embodiment may be advantageous as it prevents a compromised WebHMI component from indicating false information about the active roles of the user's session. In yet another alternative embodiment, the session service may protect the information about the user's active roles per area using cryptographic means. For example, the session service may digitally sign this information, yielding cryptographically protected credentials. In this embodiment, the WebHMI may consult the session service to look up the session's credentials before sending the operation request to the target service. Upon receipt of the operation request, the target service may independently verify that the credentials are valid and not modified by a compromised WebHMI component.

According to an embodiment, at least one role, preferably two or more roles may be determined in an automation platform, in other words on automation platform level. These roles may thus be generic roles and comprise functional roles determining permissions. According to an embodiment, roles may also be defined in an automation application, in other words on automation application level.

Different types of permissions in an industrial automation system may be defined based on these roles determined in an automation platform and/or in an automation application, not based on individual users. According to an embodiment, these roles may be related to tasks to be carried out in connection with the industrial automation system, responsibilities related to the industrial automation system and or qualifications related to the industrial automation system and/or an enterprise utilizing the industrial automation system, for example.

According to an embodiment, constraints may comprise different types of restrictive rules that may be used for selecting and activating roles for a user, an instance, a session or similar. According to an embodiment, at least one constraint, preferably multiple constraints, may be determined in an automation application. According to an embodiment, constraints may also be determined in an automation platform.

In such embodiments, thus general type of roles with permissions may be implemented in the automation platform and constraints further defining activation of the roles may be implemented in the automation application. This enables building flexible customer-specific and industrial automation system specific permissions based on the generic roles defined on the automation platform. The automation platform may, thus, provide the tools for defining permissions and in some cases some general constraints, while the automation application(s) provide flexibility for defining constraints and in some cases even custom roles based on the specific need of the customer/end user of the industrial automation system.

Figure 3 illustrates a method for authorizing operations directed to a service of the industrial automation system, according to an embodiment. The method or portions of the method may be performed by one or more services of the industrial automation system of Figure 1 . In one example the method may be performed to authorize an operation in the embodiment illustrates in Figure 2.

The method may start 302, when the industrial automation system is deployed and has accessible services that may be operated by an authorized user.

Services provided by components in the industrial automation system may be defined 304. The services may be published as names between the software objects. The services may include a constraint service, where constraints are identified by names. The services may be configured by an administrator of the industrial automation system.

Role assignments for a client to execute operations to the services may be defined. A role may include one or more permissions for accessing the defined 306 services. The roles may be defined by an administrator of the industrial automation system. The definitions of the roles may be maintained in a session service. A role assignment may comprise a role and one or more constraints.

Valid constraints may be determined 308 for the client. The constraint service may determine valid constraints from defined constraints on the basis of a time of day, work shift information, connection type of the client, location of the user, communications device type, operating responsibility of the user, authorization of the communications device, web browser type and/or authentication information of the user. The defined constraints may comprise constraints corresponding to a time of day, work shift information, connection type of the client, location of the user, communications device type, operating responsibility of the user, authorization of the communications device, web browser type and authentication information of the user.

Table 1 illustrates on each row a constraint defined by its name, description of conditions for the constraint to be valid, i.e. true, and operation of the constraint service for determining whether the constraint is valid or invalid.

Table 1 Examples of constraints

Constraint Description Operation

names

At Night The constraint is true at night time. The constraint service uses the current time of day and its information about daylight saving.

On duty The constraint is true if the user is The constraint currently on duty (based on service needs to information from an external work know the user shift system). identifier (ID) and be connected to a system that provides information about work shifts.

Not remote The constraint is true if the user is The constraint not accessing the system over a service may remote connection, such as a VPN determine remote gateway. users for example based on whether the user's IP Constraint Description Operation

names address is from a range that is allocated to the Virtual Private Network gateway.

In control room The constraint is true if the user is The constraint A present in a specific control room A service may base the decision on the user's IP address, the WebHMI server instance or the WebHMI network interface

identification

Has The constraint is true if the user The constraint

Responsibility has operating responsibility for the service needs to target area. implement a concept of responsibility areas, and keep track of the responsible users per area. Separate User Interface pages can be provided to manage the areas and the responsible users.

Responsibilities can be requested, granted, grabbed and revoked. Constraint Description Operation

names

Mobile user The constraint is true if the user is The constraint using a mobile device. service can detect mobile usage for example based on the User-Agent string of the user's browser.

Inside a The constraint is true if the user is The geographical geographical inside a specific geographical area. area is configured to area the constraint service. The user's location can be determined for instance based on HTML5 geolocation support.

Authorized The constraint is true if the user's Authorization can be device device is authorized. detected for example based on whether TLS client authentication was performed with a valid client certificate.

Supported The constraint is true if the user is The browser can be browser using a supported browser. detected based on the User-Agent string.

In the The constraint is true if the user is The user's network automation present in the automation network location can be Constraint Description Operation

names network (rather than for example the office determined based network) on the user's IP address.

Re- The constraint is true as long as Re-authentication authenticated the user re-authenticates. requires deeper integration with the user interface, so this constraint cannot be implemented with a separate constraint service.

In an example, valid constraints may be determined on the basis of the location of the user. User's locations may preferably comprise the locations that are relevant for authorization of access to the services and/or their resources in the industrial automation system. The locations could be defined as simply as "remote" and "local", or they can be very granular and track the location down to a specific control room. Examples of the user's location comprise a control room, a process area, a zone or communications network.

A WebHMI server may detect various properties of the connection to the user's EUD. Examples of the properties comprise the WebHMI server instance identifying server's IP address, and the IP address of the EUD. Based on these properties and preconfigured rules, it is possible to detect the user's location. For example, if a user is connected to the WebHMI via a specific Virtual Private Network (VPN) gateway that allocates client Internet Protocol (IP) addresses from a certain range of IP addresses, then the user may be determined to be a remote user based on the user's IP address belonging to the said range of IP addresses. The WebHMI server instance and the IP address of the EUD may be read from the WebHMI.

In one example valid constraints may be determined by the constraint service on the basis of a name of the constraint. The name may for example "room 1 ". The name "room 1 " may indicate the constraint service that the location of the user may be determined in a specific room in the industrial automation system. However, it maybe that the location of the user cannot be determined in the industrial automation system, or in the specific room, whereby such constraint may not be valid, i.e. the constraint may be determined invalid.

Roles that are included in in role assignments that have valid constraints may be determined 310 as active roles. If a role has several constraints, all the constraints should be valid for activating the role. In one example, the session service may determine active roles for the client. The session service may determine the active roles on the basis of the information indicating or including the valid constraints determined 308 for the client and obtained from the constraint service. The roles of the client may have a flag that may be set to indicate that the role is active. The flag may be unset, when the role is inactive. The flag may be a character having two values, for example 'S' for set and 'IT for unset. On the other hand also bit values of '1 ' and '0' could be used for indicating respectively an active and an inactive role.

At least one operation directed to a service and/or resources of the service may be executed 312 using an active role that has permissions for accessing the service and/or resources of the service. The operation may be executed using permissions of the active role. The permissions may comprise one or more object permissions and one or more property permissions. Preferably, the operation may be executed only, when the user session has all the permissions required by the operated service and/or resources of the service. The permissions may be defined by the UPM. Services participating in the execution of the operation may obtain the required permissions for the service and/or resource of the service from the UPM service by utilizing e.g. the READ and SUBSCRIBE operations. In this way, the operated service may check the permissions of the client for determining authorization of the operation. The execution may be caused by the WebHMI similar to explained in step 220 in Figure 2.

In an embodiment, permissions required by the operated service and/or resources of the service may be determined on the basis of a comparison of the permissions of the active roles of the user sessions to the permissions required by the operated service and/or resources of the service. In an embodiment, permissions may comprise one or more object permissions and one or more property permissions. The permissions may be assigned to roles and/or services. An object permission may define permissions on an object level and a property permission may define permissions on the level of properties of the object. The object level may refer to implementation of the operated service by a software object, whereby the property permissions may refer to the properties of the software object implementing the operated service. The property permissions for the role may be defined from a set of all permissions on the basis of a level of the role. There may a plurality of levels, e.g. two, three, four, levels, for the roles. Each level may have defined permissions from the set of property permissions. Examples of the property permissions are described in Table 3. Different roles may have different object permissions and different property permissions. Object permissions may be user defined and system specific or well-known. For example, referring to the object permissions in Table 2, the Elevated object permission may be well-known and used to indicate resources that require privilege elevation. Similarly, the Maintenance object permission can be well- known and used to indicate resources that are currently being maintained. Examples of the object permissions are illustrated in Table 2.

Table 2 illustrates examples of object permissions for implementing the described embodiments.

Object Description

permissions

Normal Default object permission

Elevated Level for more critical resource instances

Maintenance Object permission for resource instances that are temporarily being maintained

Table 3 illustrates examples of property permissions implementing the described embodiments.

Property permissions Description Property permissions Description

Mode change Change the control mode (auto, manual, cascade)

Basic operating normal operating actions such as starting and stopping, changing set

points etc.

Alarm acknowledgement Acknowledge, mask, shelf, and compress alarms

Reading process data Read any data from controllers or info.

Adjust Alarm Limit Change alarm limits

Configuration Configuration changes such as wiring, inversion of inputs

Application Change Make changes in the automation application

Tuning Change tuning parameters

Change Permissions Change the required permissions of all objects in the system.

Reading process data Read any data from controllers or info.

Read user data Read data about other users

In an embodiment permissions of active roles may be determined for authorizing an operation directed to a service or one or more resources of the service in an industrial automation system. The permissions may be determined after there exists active roles for the user session, for example after roles that have valid constraints have been activated 310. The permissions of the roles may be defined by the UPM service, for example. The permissions of the active roles may be checked for determining one or more roles that have sufficient permissions for executing the operation. When at least one role is determined to have sufficient permissions, the operation may be authorized for execution 312. Depending on the permissions of the active roles, the operation directed to the service and/or resources of the service may be authorized and the user session may have access to the service and resources of the service, whereby the execution of the operation may be successful. However, if there are insufficient permissions, the operation may not be authorized and access is not granted to the user session, whereby the execution of the operation is unsuccessful.

In an embodiment, an operation directed to a software object may be authorized, when active roles of the client's session include both the object permissions and property permissions required by the at least one resource of a service.

In an embodiment, at least one resource of a service may require multiple object permissions, whereby the operation directed to the software object may be authorized, when the active roles of the user session includes all the object permissions and the property permission required by the at least one resource.

In an embodiment, the required object permissions of at least one resource of a service may be changed during the operation of the system. The object permissions may be changed by an administrator of the industrial automation system. Services participating in the execution of the operation may obtain the required permissions for the service and/or resource of the service from the UPM service by utilizing e.g. the READ and SUBSCRIBE operations, whereby the changes to the object permissions may be reflected to the authorization of the operations.

In an embodiment, a possible outcome of authorization of a future operation towards the at least one resource of the service prior to issuing an operation request to said service. The possible outcome may be provided to the client, for example as visual information on the user interface.

The method may 314 end after execution of the operation.

Examples of roles of user sessions in an industrial automation system are described in Table 4. Each row identifies a role and describes permissions granted to the role.

Table 4 Examples of roles of user sessions in an industrial automation system according to an embodiment

Role Description Role Description

Administrator Rights to configure users and user rights

Automation Rights to operate automation asset manager. Rights to maintenance operate objects that are being maintained.

Engineer

Data entry Rights to enter data, view reports, limited access

Operator Rights to operate automation equipment

Elevated Rights for critical operations

Operator

Engineering Rights to use engineering tools to make changes in automation

applications

Field Rights to operate field asset manager tool

maintenance

engineer

Financial Permission to view financial data

reporting

Viewer Monitoring-only access, no operating rights

Reporting Right to design reports

System expert Rights for system configuration (critical)

DNA Access to Valmet DNA via gateway

System X Access 3rd party system X via a gateway

Performance Rights to access asset management tools, view process monitoring pages

Bypass Special super user role with all object and property permissions An example of determining permissions of a role in a user session is now described with reference to the roles, object permissions and property permissions described in the tables 2, 5 and 6.

The Operator role may be granted the following property permissions for objects with the Normal object permission: Ack alarms, Basic operating, Mode change. For the other object permissions, the Operator may not be granted any permissions. On the other hand the Elevated operator role could be granted the Ack alarms, Basic operating and Mode change permissions for both Normal and Elevated object permissions. In this example, the user can do basic daily operations to resources that require the Normal object permissions, in other words that are of normal criticality, if the user has the Operator role. However, if the target requires the Elevated Object Permission, then the Operator role is no sufficient but the user should have the Elevated operator role in order to operate the target.

An example of applying constraints in authorizing an operation in a user session in an industrial automation system is now described with reference to Table 5 that describes an example of a user group definition. In one example of a user group definition, in Table 5 the first two columns may define a user group. Accordingly the user groups in Table 5 may be Paper Machine 1 Operators, Paper Machine 2 Operators, Power Plant Operators, Paper Machine 1 Elevated Operators, Paper Machine 1 Viewer, Paper Machine 2 Viewer. In another example, the roles, areas and constraints in Table 5 may define roles assigned to a user group.

An administrator of the industrial automation system may configure user accounts and access control rules. The configuration may be performed using an UPM in the industrial automation system, for example in Figure 1 . In an embodiment, the users may be assigned to groups. The administrator may create groups based on the work division, for example for Paper Machine 1 operators, Paper Machine 2 operators, Boiler operators, Paper Machine 1 Viewers, Management, Sales etc. In the example of Table 5, the administrator has defined the roles, areas and constraints for Paper Machine 2 operators user group. Table 5 An example of a user group definition with granted roles and constraints in an industrial automation system.

Table 5 describes in each row a role and a constraint for the role as well as the area wherein the resources that the role may be applied to reside. As Table 5 defines the user group for Paper Machine 1 operators, the users are obviously granted the Operator role for resources within the Paper Machine 1 area. In this example, the Paper Machine 1 operators user group has been granted the Operator role also for other areas, however with different constraints. A user may be a member of a several user groups that are defined by other tables similar to Table 5. For each group, the administrator can assign one or more roles for specific areas and on specific constraints. If several constraints are given, then all the constraints must be true in order for the role to be activated.

Figure 8 illustrates an example of user interface for editing user groups in an industrial automation system. The user interface may be referred as an administration user interface and used by an administrator of the industrial automation system. The administration user interface may be provided to the administrator on an EUD by way of interaction between HMI and UPM in the industrial automation system. In one example the administration user interface may a web page. The administration user interface may be used to assign one or more roles to a user group. In this way the roles may be used for authorizing operations of user belonging to the group in a user session.

The administration user interface may identify any system-specific custom constraints based on a name of the resource. It is also possible to automatically discover the available constraint services, if a specific convention such as a using a certain part of the name hierarchy is used to name the constraint services. Advantageously, this enables the administrator to configure user groups with a user interface view that dynamically presents the available constraints

In Figure 8, roles 802 assigned to a user group are displayed. Each role may have one or more constraints 806 for the role as well as the area 804, for example a process area, wherein the resources that the role may be applied are located. The role may be defined for a plurality of areas, where the constraints may be the same or different constraints may assigned to the role. Available roles and areas may be selectable in drop-down menus. The constraints assigned to roles may be listed in an area next to the role and area. Further roles may be assigned to the user group by selecting an item in the user interface, which causes a new row comprising the drop-down menus for the available roles and areas as well the area for the constraints to appear below the previously assigned roles.

Following the example of Table 5, the Paper Machine 1 user group may be assigned the Operator and Viewer roles. The role assignments in Table 5 may provide that members of the Paper Machine 1 group can always view information about Paper Machine 1 and Paper Machine 2 areas, as they have the Viewer roles for both areas assigned without any constraints. Operating requires presence in the Paper Machine 1 control room. The operators who are present in the control room can always operate Paper Machine 1 . During night shifts, they can also operate Paper Machine 2 and Power Plant. Furthermore, if re-authentication is performed, the members of this group are also granted the Elevated Operator role for the Paper Machine 1 area. Alternatively to groups, it may also be possible to assign roles directly to users, with specific constraints and for specific areas.

Figure 4 illustrates implementation of the field devices as software objects in an industrial automation system according to an embodiment. The industrial automation system comprises a Process Control Station 409 for controlling and three field devices MOTOR1 , MOTOR2 and MOTOR3 connected to the PCS. The Process Control Station 409 may implement a software service, where the motor devices MOTOR1 , MOTOR2 and MOTOR3 are represented as software resources, in the form of software objects 411 a, 411 b and 411 c, respectively. In this way the motor devices may be provided as service to other components in the industrial automation system. A user may operate a graphical user interface provided to an EUD 402 of the user by a HMI server 404. In this way the user may operate a specific service and/or a resource of the service. Further details of the EUD, the WebHMI and the industrial automation system are described for example in Figure 1 .

Figures 5, 6 and 7 illustrate examples of software objects for providing components as services in an industrial automation system. The software objects in Figures 5, 6, and 7 refer to software objects 411 a, 411 b and 411 c in Figure 4. The software objects may have three properties 504, 604, 704: area, a list of object permissions and a Boolean isRunning property, which may determine whether the motor is running or stopped. For each resource of the object, a table of required property permissions 502, 602, 702 may be included. So for instance, the software service running in the PCS 409 may be configured to require the Normal object permission for software object 411 a, both the Normal and Maintenance object permissions for software object 411 b and the Elevated object permission for software object 411 c. Furthermore, all software objects 411 a, 411 b and 411 c are defined to reside in the Paper Machine 1 Area.

In the light of the examples above, user that is a member of the Paper Machine 1 operators group and who is present in the Paper Machine 1 control room would be able to change the isRunning property of the software resource 411 a, since according to Table 5 the user has the Operator role for the Paper Machine 1 Area, and the Operator role has been granted the required Basic Operating property permission. However, the same user is not authorized to change the isRunning property of the software resource 411 b, since none of the user's active roles have the Maintenance object permission. In this example, the software resource 411 b may have been configured during runtime to also require the Maintenance object permission, for example in order to limit the authorized users to the automation maintenance engineers group during the maintenance of MOTOR2. A user who is a member of the Paper Machine 1 operators group, as defined in Table 5, is authorized to operate the software resource 411 c that corresponds to MOTOR3 only when the two constraints "Present in PM1 control room" and "re-authenticated" are valid. The re-authentication constraint is normally not activated, but the user can activate this constraint and elevate himself or herself as an Elevated Operator by performing a re-authentication.

The software service running in PCS 409 may indicate the reason for unsuccessful authorization by including the Area, required object permissions and the required property permission in a response to an operation request. Accordingly, the reason may indicate a mismatch between required Area, required property permissions, required object permissions the operated object and/or resource of the object and the user session's permissions. Advantageously, this may enable the HMI application 404 to determine that authorization would be successful if the user re-authenticated. As the Elevated object permission is well-known, the HMI application 404 can automatically provide the user with suitable interactions for re-authentication. Accordingly, the reason for unsuccessful authorization may be used by the client's user interface to enable the user to influence the role activation constraints of the user's current session. Similarly, as the object permission for Maintenance can be well-known, the HMI application 404 may indicate the maintenance state of the target resource with a maintenance user interface symbol.

It may not be necessary for the user to attempt an operation in order to find out whether the operation is authorized. Instead, the software service running in PCS 409 may provide means for the HMI application 404 to request the authorization of potential future operations in advance. This allows the user interface to change the representation of the user interface, for example to grey out user interface components that the user is not allowed to operate, or to use a specific graphical symbol for indicating maintenance. The representation may be changed depending on the reason for denied authorization. The reason for unsuccessful authorization may be obtained from the indication for the reason for unsuccessful authorization from the PCS. The request for the expected authorization result is advantageously a continuous SUBSCRIBE operation. The user interface may also enable specific interactions, such as re-authentication, based on such in-advance request for authorization.

It should be appreciated that regular automation programming means such as function blocks or structured text, or using a programming language such as JavaScript or Python may be used in implementing the various embodiments described herein.

In an embodiment, at least one processor, a memory and a computer program code form an embodiment of processing means for carrying out an embodiment. Embodiments may be implemented in a cloud computing service, a computer and/or a mobile device.

An EUD in various embodiments described herein may be a mobile phone, smart phone or equivalent. A component in various embodiments may be a process controller or a computer or equivalent. Combinations of hardware, software and/or firmware may be used to implement components of the industrial automation system. Apparatuses such as EUDs and components may have operating systems for execution of applications that cause carrying out one or more functions of an embodiment.

In various embodiments, the processor may be a computer processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and/or any other hardware component that has been programmed in such a way to carry out one or more functions of an embodiment.

In various embodiments the memory may include volatile and/or non- volatile memory and typically stores content, data, or the like. For example, the memory may store computer program code such as software applications or operating systems, information, data, content, templates or the like for the processor to perform steps associated with operation of the apparatus in accordance with embodiments. In the illustrated embodiment, the memory may be, for example, random access memory (RAM), a hard drive, or other fixed data memory or storage device. Further, the memory, or part of it, may be removable memory detachably connected to the control unit. The optical code may be visible on a display, paper, sticker or any surface capable of being printed on. According to an embodiment there is provided a computer program embodied on a computer -readable storage medium, the computer program comprising program to execute an embodiment.

Embodiments as described may also be carried out in the form of a computer process defined by a computer program. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example.

In an embodiment there is provided a computer program product for a computer, comprising program code means, for example software code portions, for performing one or more functions or steps of an embodiment.

It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.

Claims

1 . A method comprising:

defining (304) services provided by components of an industrial automation system;

defining (306) role assignments for a client to execute operations to the services, wherein a role assignment comprises a role and one or more constraints and wherein a role includes one or more permissions for accessing the services;

determining (308) valid constraints for the client;

determining (310) roles that have valid constraints as active roles; defining permissions of the active roles;

comparing permissions of active roles to permissions required by the at least one resource;

determining permissions required by the service for the at least one operation;

authorizing the operation, when the active roles of the user session have the permissions required by the at least one resource;

executing (312) at least one operation directed to at least one resource of a service, when at least one of the active roles has permissions required by the at least one resource;

wherein the constraints comprise custom constraints and default constraints.

2. A method according to claim 1 , wherein the valid constraints are determined by a constraint service on the basis of the name of the constraint.

3. A method according to claim 1 or 2, wherein a constraint comprises at least one of a time of day, work shift information, connection type, location, communications device type, operating responsibility of the user, authorization of the communications device, web browser type, authentication information of the user.

4. A method according to any one of claims 1 - 3, wherein the services in the industrial automation system are implemented by distributed and hierarchical software objects, and the permissions comprise object permissions and property permissions.

5. A method according to claim 4, wherein an operation is authorized, when the active roles of the client's session include both the object permissions and property permissions required by the at least one resource of a service.

6. A method according to claim 4 or 5, wherein at least one resource of a service requires multiple object permissions and authorizing the operation, when the active roles of the user session include all the object permissions and the property permission required by the at least one resource.

7. A method according to claim 4, 5 or 6 wherein the required object permissions of at least one resource of a service are changed during the operation of the system.

8. A method according to any of the preceding claims, wherein the client is able to retrieve a possible outcome of authorization of a future operation towards the at least one resource of the service prior to issuing an operation request to said service.

9. A method according to any of the preceding claims, wherein the service indicates a reason for denied authorization with at least one of the following: required area of a resource, required object permissions of a resource or required property permission of a resource.

10. A method according to claim 9, wherein the representation of the resource in client's user interface changes depending on the reason for denied authorization.

11 . A method according to claim 10, wherein the required area of the resource is used by the client's user interface to enable the user to influence the role activation constraints of the user's current session.

12. A method according to claim 10, wherein the required object permission of the resource is used by the client's user interface to enable the user to influence the role activation constraints of the user's current session.

13. A method according to any of the preceding claims, wherein the active roles are cryptographically protected and a service verifies the cryptographic protection of the active roles and authorizes an operation towards a resource of a service only if the cryptographic protection of the active roles is valid.

14. A method according to any one of the preceding claims, wherein the industrial automation system comprises at least one automation platform and at least one automation application, and wherein the method further comprises

determining at least one role in the automation platform.

15. A method according to any one of the preceding claims, wherein the industrial automation system comprises at least one automation platform and at least one automation application, and wherein the method further comprises

determining at least one constraint in the automation application.

16. An industrial automation system comprising:

components for providing services in the industrial automation system;

a user and policy management entity (114) for defining role assignments for a client to execute operations to the services, wherein a role assignment comprises a role and one or more constraints and wherein a role includes one or more permissions for accessing the services, wherein the components are connected to the user and policy management entity to cause:

determining valid constraints for the client;

determining roles that have valid constraints as active roles;

defining permissions of the active roles;

determining permissions required by the service for the at least one operation; authorizing the operation, when the active roles of the user session have the permissions required by the at least one resource;

executing at least one operation directed to at least one resource of a service, when at least one of the active roles has permissions required by the at least one resource;

wherein the constraints comprise custom constraints and default constraints.

17. An industrial automation system according to claim 16, wherein the valid constraints are determined by a constraint service (108) on the basis of the name of the constraint.

18. An industrial automation system according to claim 16 or 17, wherein the system is caused to execute a method according to any one of claims 1 to 15.

19. An industrial automation system according to claim 16, 17 or 18, wherein operations to services are executed by the client on a user interface provided by a Web Human Machine Interface server (104) in a user session managed by a session service (106) on the basis of constraints and permissions of active roles of the client.

20. An industrial automation system according to any one of claims 16-19, wherein the industrial automation system comprises at least one automation platform and at least one automation application, and wherein at least one role is determined in the automation platform.

21 . An industrial automation system according to any one of claims 16-20, wherein the industrial automation system comprises at least one automation platform and at least one automation application, and wherein at least one constraint is determined in an automation application.