Glossary
The documentation uses these terms with one meaning each. Interface labels are written in bold where the term appears as a label. Where the interface uses another word for the same thing, for example Tag for a signal, the entry says so.
Signals and communication
| Term | Meaning | See |
|---|---|---|
| Signal | A named value in a project: a measurement, a state, a setpoint or a command. Some interface labels call it Tag. | Signals |
| Signal name | A path of segments separated by dots, for example Line1.Pump1.Status. | Signals |
| Reserved roots | System, Alarms and Session: root names that hold the signals YTCC fills in itself. | System, alarm and session signals |
| Internal signal | A signal that YTCC keeps or calculates itself, without a device. | Internal signals |
| Signal type, instance | A signal type describes the signals of one kind of equipment; an instance is a folder created from it. | Signal types and instances |
| Old name | The name a signal had before a rename. Screens and scripts that use it keep working until it is removed. | Signals |
| Driver | One communication process that talks one protocol to its devices. Each driver runs as a separate program. | Add drivers and devices |
| Device | A field device that a driver communicates with, such as a PLC, an RTU or a relay. | Communication state and communication alarms |
| Quality | Whether a value can be trusted, as reported by the driver: Good, Uncertain, Bad and others. Quality describes communication, not the age of a value. | Quality |
| Device time, arrival time | When the device stamped a value, and when the value reached YTCC. | Time stamps and time zones |
| Operating mode | Where a signal's value comes from: Auto, Manual [Field], Manual [SCADA] or Simulated. | Operating mode |
| Manual value | A value entered by a user in place of the field value (Manual [SCADA]). | Enter a manual value |
| Live data | The live values shown in the signal list of the configuration editor. | Live data in the configuration editor |
Screens
| Term | Meaning | See |
|---|---|---|
| Project | Everything one plant or system needs: screens, signal and driver configuration, users. | Project model |
| Page | A screen of a project, with its own objects and layers. | Project model |
| Object | Anything placed on a page: a shape, a text, a tank, a gauge, a button. Some interface labels call it a widget. | Project model |
| Layer | A named group of objects on one page. | Project model |
| Symbol | A reusable drawing with parameters, placed on pages as often as needed. | Symbols |
| Popup | A small window with its own objects, opened from a page. The editor's explorer lists popups under Modals. | Popups |
| Layout | Objects shown together with pages, such as a header or a menu bar. | Layouts |
| State table | The table that turns the values of a signal into texts, colors or images on an object. | State tables |
| Screen package | A zip file or folder with pages, symbols, popups, layouts and images, imported into a project. | Import a screen package |
Work areas
| Term | Meaning | See |
|---|---|---|
| Home page | The first page of the interface, with the projects, processes and settings. | Work areas |
| Screen editor | Where you draw pages, symbols, popups and layouts. | Work areas |
| Test run | Run in the screen editor: the page works as at runtime, inside the editor. | Work areas |
| Configuration editor | Where you define drivers, devices, signals, alarms, history, zones, server scripts and users. Its browser tab is titled YTCC Studio. | Work areas |
| Runtime screen | The screens as operators use them, with live values, alarms and commands. The project list menu calls it Runtime. | Work areas |
Alarms, history and commands
| Term | Meaning | See |
|---|---|---|
| Alarm | A signal state that needs the operator's attention, with a priority and a state. | How alarms work |
| Alarm level | One limit of an alarm, such as HH, H, L or LL. | Define alarms |
| Alarm area | A branch of the area tree that signals and devices belong to; alarm lists and counters can be limited to it. | Alarm areas |
| Alarm class, alarm group | A class sets the priority and acknowledge mode of alarms; a group collects alarms by rules. | Alarm classes and groups |
| Acknowledge | Confirm that you have seen an alarm. | Acknowledge alarms |
| Shelve | Hide an alarm for a limited time, with a reason. | Shelve alarms |
| Communication alarm | The one alarm per device or driver that YTCC raises when communication is lost. | Communication state and communication alarms |
| History | The recorded values of signals, kept in the history database of the project. | How history is recorded |
| Archive table | Decides which signals are recorded, how and for how long. | Archive tables and assignments |
| Event list | One time-ordered list of signal changes, alarms, commands and operator actions. | What the event list records |
| Trend | A chart of the history and live values of up to 8 signals. | Use the trend |
| Command | A value that YTCC writes to a field device. | Commands and confirmation |
| Command confirmation | The Command confirmation window that asks before a value goes to the field. | Commands and confirmation |
| Four eyes | A second user approves a critical command or an interlock override. | Commands and confirmation |
Electrical diagrams
| Term | Meaning | See |
|---|---|---|
| Single-line diagram | A page with electrical symbols connected by wires, colored live from the network topology. | How the live single-line diagram works |
| Topological interlocking | The check that refuses a switching command whose result would break a rule, for example closing onto earth. | Topological interlocking |
| Interlock override | Sending one command although an Unlockable rule blocks it, with a reason and usually a second user. | Topological interlocking |
| Switching program | A prepared sequence of switching operations, approved and then run by the server. | Switching programs |
Security and administration
| Term | Meaning | See |
|---|---|---|
| Authentication | User login for a project. A new project starts with it off. | Turn on authentication |
| Profile | A set of permissions given to users. Some interface texts call it a role. | Permission model |
| Permission | The right to do one kind of action, such as Field writes. | Permissions and default profiles |
| Responsibility zone | A part of the project that profiles may view or control; with exclusive control, only one operator controls it at a time. | Responsibility zones |
| Root, server administrator | The system administrator of the server and the designer of its projects: it may do everything in every project, and the actions that belong to the whole server. A server account created in the first-run setup, or with the password root when an earlier version is upgraded. The session menu calls it Server administrator. | Root, the system administrator |
| Project user | A user defined in one project. While the server has the root account, project users only operate: they work on the runtime screen with the permissions of their profiles and, with System stop, start and stop the project. | Permission model |
| Audit log | A record of who did what: the user audit log, the configuration audit, the event list and the command log. | Audit logs |
| Stack | All YTCC programs of one installation, started and watched by the process manager. | Manage the YTCC processes |
| Installation | One installed YTCC version in its own folder, identified for example as v13. | Which version you are reading |
| Contract version | The version number of a database schema, file format or interface that YTCC checks when it opens something from another version. | Compatibility and contract versions |
| Backup | A zip file with a project's database, files and users, made with Back up… on the home page. | Backup and restore |
| Server script, client script | A script that runs on the server without a screen, or in the browser on an open screen. | Which script runs where |