Introduction

System requirements

Operating system:

TwinCAT version:

Introduction 1:

Reliable protection only when using the latest TwinCAT 3 version

For reliable protection (e.g. secure encryption), always use the latest TwinCAT 3 version. This provides the maximum security.

Use at least TwinCAT 3.1 Build 4024.x.
For security reasons, do not use an older version!

Introduction 2:

Download link: Planning table for group rights and Object Protection Level

An Excel table for the simple planning of group rights and access rights group sets (Object Protection Level) can be downloaded here.

TwinCAT user access rights

Note: For a better overview, it is recommended not to assign groups to another group, but to assign rights to the group completely independently.

Rights are divided into two main categories in the TwinCAT 3 Engineering:

  1. General rights in the project (e.g. the right to sign files). These are assigned to user groups individually because they always apply to the entire project.
  2. Component-specific rights ("View", "Delete", "Modify", and "Add/Remove Children").
    Because these can vary for different components of a project depending on the group membership, they are organized into a "rights set" that summarizes the individual rights of all groups under one designation.

Introduction 3:

Rights grayed out in the above illustration are provided "for future use" in the current version and are not yet implemented.

Such a rights set is called an "Object Protection Level" and represents a matrix of the existing groups and their rights for an object. With an Object Protection Level, individual project components can be conveniently provided with prefabricated rights sets for each group at once, and these do not have to be assigned in groups to each project component.

If the objects of a project are not different in terms of the set of access rights (the simplest use case), the definition and use of a single Object Protection Level is sufficient. This is then assigned to all objects in the project.

In the example above, the Developer group is allowed to do everything except make changes to the database, the Administrator group is only allowed to make changes to the database, and the Guest group is not allowed to do anything (not even load the project).

Keep in mind the membership of groups in other groups!

Sample 1

In the following sample, a new group called "GRP_OEMService" is to be added.

(The creation of a new group and the assignment of rights is described here).

The new group is allowed to see everything, but not change anything, and may activate the project.

In order to view the project, the group must have the "Decrypt Project Files" right (otherwise Visual Studio will not be able to load the encrypted parts of the project).

Introduction 4:

To activate the project it is necessary, in addition to the "Activate Configuration" right, to be able to modify the project file (because certain information is saved there when activated), as well as to save these changes in encrypted form. Therefore, the "Change Project File" and "Encrypt Project Files" rights are additionally required.

For component-specific rights, only "View" is necessary.

A new Object Protection Level does not need to be created, because this rights set should always apply to the entire project.

Sample 2

In the next sample, the "GRP_OEMService" group should only be able to view defined components of the project.

This requires the creation of a new group rights set, i.e. a new Object Protection Level (OPL), in order to be able to differentiate the respective rights assignment for a specific project component. We call the new OPL "OPL_OEMService".

(The creation of a new Object Protection Level is described here).

The viewing right for the GRP_OEMService group is now removed from the "OPL_OEMDev" and added to the new "OPL_OEMService":

Introduction 5:

Since the group "GRP_OEMDev" is also allowed to do everything in the new "OPL_OEMService", all rights (View, Modify, ...) were also entered there for this group.

Sample 3

In the next sample, the group GRP_OEMService is additionally to be allowed to make changes to certain project components. (However, it may (still) not delete or add project components).

For this, another new Object Protection Level (OPL) must be created. We call it "OPL_OEMServiceEdit":

Introduction 6:

Compared to OPL_OEMService, only the "Modify" right is added here, the rest is identical.

Project components assigned to OPL_OEMServiceEdit can now also be changed by users of the GRP_OEMService group.

Assignment of the Object Protection Levels in the project

Now we only need to assign the OPLs created in the previous samples to the project components. (How exactly the assignment of the OPL takes place in the TwinCAT Engineering is described here).

Introduction 7:

Introduction 8:

OPL is inherited

The OPL assigned to the root of the PLC project is inherited into the underlying nodes. Only the nodes that require a setting other than the PLC project root must be individually configured with the required OPL.

Sample 4

The following sample considers the case where the service employee is allowed to activate a project but not view it.

Since a special rights configuration is only required for the root of the PLC project here, we need our own Object Protection Level. We call it "OPL_OEMServAct":

Introduction 9:

Unlike in sample 2, the "GRP_OEMService" group has only modifying rights, but no viewing rights. "View" is not included in "Modify".

Visual Studio requires the "Modify" right for the project file, because changes must be made there when it is enabled.

When assigning the OPLs, the project root is now provided with the "OPL_OEMServAct".

Introduction 10:

However, since this property is passed on to the project components located below the root (unless explicit individual settings have been made there), the project components located below the root may have to be manually switched to another OPL individually. The convenient inheritance function of the PLC root properties cannot then be used in this case.

Related documents