Permission model
YTCC has one account that designs and administers, root, and project users who operate. Each project has its own users, and user login can be on or off for each project separately.
When user login is off
If user login is off for a project, there is no sign-in: everyone who opens the interface has every permission in that
project. Commands are still recorded, with the user anonymous.
With user login off, anyone who can reach the interface can send commands to the field and change the project. Turn user login on for every project that controls a real plant.
Profiles and permissions
A profile is a named set of permissions. Each user has one or more profiles, and the permissions of all of them add up: a user can do something if any of their profiles allows it. A new profile starts with every permission off, and every user must keep at least one profile.
Permissions are grouped as follows:
Operation
| Permission | Allows |
|---|---|
| Field writes | Sending values and commands to the field from runtime screens |
| Acknowledge alarm | Acknowledging, commenting on, shelving and unshelving alarms |
| Signal run mode | Putting signals into Manual [SCADA] or Simulated mode |
| Take over control | Taking control of an area of responsibility without the owner's consent |
| Communication control | Starting, stopping and restarting driver communication from the runtime screen |
| Approve commands (four eyes) | Approving a critical command as the second user, with their own user name and password |
| Override electrical interlock | Forcing a command through an electrical interlock that allows it, with their own password and a reason; the override is written to the event list |
| Tag out devices | Hanging a tag on an electrical device and removing their own tag; no command goes to a tagged device |
Engineering
| Permission | Allows |
|---|---|
| Editor access | Editing screens and the project |
| Configuration editing | Applying changes in the configuration editor |
| DNP3 administration | DNP3 special actions, file transfer and the virtual terminal |
| AI access (MCP) | Creating their own MCP access key and connecting an AI assistant for screen design and configuration |
Administration
| Permission | Allows |
|---|---|
| Project phase | Putting the project into the Engineering or Commissioned phase |
| System stop | Stopping all processes of the project from the runtime screen, and starting, stopping and restarting the project from the home page |
| User management | Managing profiles, users and policies; equivalent to an administrator |
Profiles also limit where a user works, with View areas and Control areas. An empty list means all areas.
Editor access, Configuration editing, DNP3 administration, AI access (MCP), Project phase and User management belong to root while the server has the root account. A project user's profiles decide what they may do on the runtime screen and whether they may start and stop the project.
Checks are made on the server
The YTCC server checks the permissions of every command, acknowledgement, configuration change and user administration request, using the user's current profiles. Hiding or disabling a button in the interface is only a convenience; a request that the user is not allowed to make is refused by the server. Because the check uses the current profiles, a change to a user's profiles applies within 10 seconds.
Root and project users
Root is the system administrator of the server and the designer of its projects. It is a server account, created in the first-run setup, and not a user of any project. Root has every permission in every project with user login: it creates, imports, copies and deletes projects, works in the screen editor and the configuration editor, manages the users of each project and can do everything on the runtime screen. It also does the actions that belong to the whole server, such as collections, ports, shared images, map packages and the electrical symbol library.
Project users operate: they work on the runtime screen with the permissions of their profiles and, with System stop, start and stop the project. Each action is recorded under the name of the user who did it, root included. See Root, the system administrator.