Process Groups and Access
In a large plant, each operator should see only the values and alarms of the area they are responsible for. 2WinScada does this with process groups: records are collected in process groups, process groups are bound to roles, and roles are given to users through user groups.
The definition steps are on the Process Groups, Task Centers and User and Group Management pages.
Process Group
A process group is defined as one of two types. The type is selected in the Type field of the process group definition:
| Type | In the selection list | Contents | On the dashboard |
|---|---|---|---|
| Process Group | ProcessGroup | Task centers and their devices; all tags of those devices | Process group → task centers → devices → tags |
| Tag Group | TagGroup | Individual tags selected from different devices | Process group → tag list |
- A device is in at most one task center, and therefore in at most one group of the Process Group type.
- A tag can be added to more than one Tag Group. The same tag can belong to a Process Group through its device and also to a Tag Group.
Changes to process groups, task centers or tag groups reach live monitoring immediately with the ReInitialize Process Groups button. If the button is not used, the changes are loaded automatically about one minute after the last change. Users with the Editor or UserAdministrator role can use this button.
Users, Groups and Roles
Authorization is built on four concepts:
- Every user is a member of a user group. The group is mandatory in the user definition.
- One or more roles (Role in the interface) are given to the user group. A user's roles are the roles of their group.
- Built-in roles grant function permissions: making definitions, writing to tags, acknowledging alarms and so on.
- Process groups and pages are bound to roles to limit their visibility.
Built-in Roles
Built-in roles come with the installation and appear in the interface with their English names:
| Role | Covers |
|---|---|
| Editor | Engineering definitions (tags, logs, alarms, process groups, pages). Writing values to tags and alarm actions. Sees all process groups. From 2.11, cannot add or change event code on pages; sees the code and can delete it (see Who can add event code). |
| Operate | Operation: writing values to tags, acknowledging, locking and resetting alarms, restarting device communication. |
| Monitor | Monitoring. |
| UserAdministrator | Managing users, user groups, roles and API keys. Alarm actions. |
| AlarmManagement | Alarm definitions and notifications. Alarm actions. |
| ReportManagement | Reports and report groups. |
| LogManagement | Log (archive) definitions. |
| RecipeManagement | Recipe definitions. |
| RecipeApplier | Applying recipes. |
Alarm actions (acknowledge, lock, reset) require the UserAdministrator, Operate, Editor or AlarmManagement role. Writing a value to a tag requires the Operate or Editor role.
Custom Roles
Newly defined roles are of the Custom type. A custom role does not grant any function permission on its own; it is used to limit the visibility of process groups and pages. For a custom role to take effect, it must also be added to a user group.
A custom role cannot be given the name of a built-in role (case-insensitive).
Built-in User Groups
| Group | Description |
|---|---|
| SystemAdmin | The system integrator's group; managed by the integrator (see SystemAdmin Account). |
| Administrators | The customer's administrator group. On a new installation all built-in roles are given to this group. |
| Operators | The operator group that comes with a new installation; it does not have the Editor role. It can apply recipes, but cannot define or change them. |
| Recipe Managers | Comes with new installations from 2.10 on. Defines, changes and applies recipes (Operate, Monitor, RecipeManagement, RecipeApplier). |
| Monitors | The monitoring group that comes with a new installation; it has only the Monitor role. |
SystemAdmin and Administrators cannot be changed. Operators, Monitors and Recipe Managers can be edited; their roles may have been changed after installation. Installations upgraded from earlier versions do not have the Recipe Managers group, and Operators can manage recipes; see Upgrading.
How Access to Data Is Limited
In terms of process group scope, users fall into two kinds:
- Full-scope users: Users with the Editor role and accounts in the SystemAdmin group. They see all process groups and the records that belong to no process group. On a new installation the Administrators group has the Editor role, so it is full-scope.
- Scoped users: All other users. They see only the process groups opened to them.
Whether a scoped user sees a process group depends on whether roles are assigned to the process group:
| Process group permission | Scoped user | Full-scope user |
|---|---|---|
| No role assigned | Sees it | Sees it |
| Roles assigned and the user's group has one of them | Sees it | Sees it |
| Roles assigned and the user's group has none of them | Does not see it | Sees it |
A process group without a role is open to everyone
If no role is assigned to a process group, every user sees it. To restrict an area, assign at least one role to its process group.
The scope is applied in these places:
- The Dashboard and live values: the user sees only the process groups, task centers, devices and tags in their scope.
- Live alarms and alarm actions: the user receives, acknowledges, locks and resets only the alarms they can see (see Alarms).
- Tag, device and definition selection lists, and the department list.
- Pulse and Rising edge commands (see Tag Write Scope).
The visibility of pages is also limited by the roles assigned to the page (see Page Management and Authorization). Process group scope does not grant permission to write values to tags; writing also requires the Operate or Editor role.
Tag Write Scope
Writing a value to a tag always requires the Operate or Editor role. For tags with the Pulse or Rising edge command behavior (see EtherNet/IP), the user must also see the tag within their process group scope. The rule is the same as the rule that decides who receives an alarm:
- The tag's Tag Groups and the process group of its device's task center count. If the user sees one of them, they can write; a user who sees the tag group can write even without seeing the device's process group.
- If the tag is in none of them, Genel counts. If no role is assigned to Genel, every user with the Operate or Editor role can write. If a role is assigned, only users with that role and full-scope users can write; they also need the Operate or Editor role. A role assigned to Genel also limits who sees the tags in Genel (see The Genel Process Group).
Because a tag that belongs to no other group falls into Genel, every tag belongs to at least one process group; there is no tag that is on a page but belongs to no process group. Only during the short time while the process groups are reloaded can the scope still be out of date. During that time only full-scope users can write to a tag whose group is not yet determined. A write to a tag that was just added to a new group can be rejected for everyone, full-scope users included, until the reload has finished; try again when it has finished.
Being able to open a page does not grant permission to write to the tags on it: page access is decided by the roles assigned to the page, the write scope by the process groups. If a user does not see the process group of a tag on a page they can open, they cannot send a command to that tag. A write outside the scope is rejected with a permission error (see Write Result).
User Without Process Group Permission
If none of the roles of the user's group is assigned to a process group, the user sees only the process groups without assigned roles. If roles are assigned to all process groups, such a user sees no process group on the dashboard and receives no alarms that belong to process groups.
The Genel Process Group
A tag belongs to no process group when both of these conditions hold:
- The tag's device is not bound to a task center in a process group (there is no task center, it was deleted, or the task center's process group was deleted).
- The tag is in no Tag Group.
From 2.10 on, these tags are collected automatically in the system's Genel process group. When the tag is added to a Tag Group or its device is bound to a task center in a process group, it leaves Genel automatically. Genel contains only tags that are really unassigned: tags whose device is bound to a task center in a process group are not in Genel. This rule also applies to the Genel card on the Dashboard, to live data and to access to device pages.
- Who sees it: If no role is assigned to Genel, everyone, including users limited by process group, sees the values, alarms and logs of these tags. If a role is assigned to Genel, only users with that role and full-scope users see them. To show these records only to engineers, as in earlier versions, assign only the engineering role to Genel.
- What it allows: Genel grants the right to see its tags and to acknowledge their alarms. Users with the Operate or Editor role can also send Pulse and Rising edge commands to the tags in Genel (see Tag Write Scope). Users limited by process group cannot restart the devices in Genel.
- What cannot be done: Genel cannot be deleted, its type cannot be changed, and tags or task centers cannot be added to it by hand. It can be renamed and roles can be assigned to it. It appears with the System badge on the definition page; when selected, its tags are listed read-only.
- Deleting: When a task center or process group is deleted, the confirmation dialog shows how many devices and tags will fall into Genel.
Alarms That Belong to No Process Group
Thanks to the Genel group, in 2.10 every alarm belongs to at least one process group; if its tag belongs to no other group, the alarm belongs to Genel and is delivered to users who can see Genel.
Full-scope users see the Alarms in the Genel group warning on the Alarm Definitions and System Information pages. The warning shows the number of alarms that fell into Genel and lists the first ten (with description, device and tag name); if there are no such alarms, it is not shown. To make sure every alarm reaches a responsible operator, add the alarm's tag to a Tag Group or bind the tag's device to a task center.
SystemAdmin Account
Accounts in the SystemAdmin group belong to the integrator who set up the system. What administrators need to know:
- SystemAdmin accounts see all process groups.
- From 2.11, event code is added to or changed in pages and templates only with SystemAdmin accounts; the Editor role does not give this permission. For changes that need event code, contact your system integrator (see Who can add event code).
- SystemAdmin accounts are managed by the system integrator. Customer administrators (Administrators or the UserAdministrator role) cannot edit these accounts, reset their passwords, create API keys in their name, or change the roles of the SystemAdmin group.
- If the SystemAdmin integrity warning appears on the System Information page, contact your system integrator.
- The configuration backup does not contain SystemAdmin accounts. A restore cannot create new SystemAdmin accounts and does not delete existing ones (see Backup and Restore).