unCoreInternals 9.3.0
UNICOS Device Model

Introduction

This document describes the concepts the UNICOS device model. It explains the concept of UNICOS device, front-end, application, domain, etc. It first presents the concepts of the device model and the relation between the different entities, before presenting its implementation in WinCC OA. This documents focuses on the core principles of the UNICOS device model, i.e. it does not take into additional concepts introduced by different packages such as CPC, QPS or pcDevices.

Concepts

The following diagram illustrates the key elements of the UNICOS device model:

UNICOS Device Model Elements

The UNICOS device model is based on the following key elements:

  • Device: a UNICOS device is meant to represent any element of the controlled process, being either physical (e.g. a valve) or logical (e.g. a temperature measurement). It is the core element of the UNICOS concepts as a device will graphical representations (widgets), a faceplate, access control restrictions, alarms, events, trends, selection, etc.
  • DeviceType: the type of a UNICOS device identifies the key attributes which will be shared by all the devices of a type. To make the parallel with an object-oriented approach, a device type would be a class, while a device would be a instance of it.
  • FrontEnd: a UNICOS frontend is originally meant to represent the PLC (frontend) to which the UNICOS devices are connected to. Therefore a UNICOS device can only belong to one and only one frontend, while a frontend can have zero or many devices. Note that a UNICOS device can not exist whitout being attached to a frontend. A frontend can also be virtual, i.e. not representing a physical asset such as a PLC or a FEC, and represent a software logic updating the value of its devices, i.e. to compute the average temperature of two sensors coming from two different PLCs. In the CPC terminology, such frontend are called Soft FrontEnd.
  • FrontEndType: the frontend type represents is the type of frontend, e.g. the type of PLC such as Siemens PLCs, Schneider PLCs, SoftFrontEnd. Similarly to the relatation between and device and its type and to make the parallel with an object-oriented approach, a frontend type would be a class, while a frontend would be a instance of it.
  • Application: an application to the application of the device within the frontend. It is the first way to group devices. This concept is often confused with the UNICOS concept of subApplication. A subApplication groups several applications to display and make accessible at the HMI level only a subset of devices.
  • Domain: also known as subsystem1 in some documentation. It is a second way of grouping devices. A device can be in one or many domains or in none of them.
  • Nature: aslo known as subsystem2. Nature is a subgroup of domain which can also be read as subsystem2 is a sub group of subsystem1. It is the third way to group devices. A device can be in one or many subsystem2 group or in none of them.

Implementation

The following diagram illustrates the key implementation elements of the UNICOS device model in WinCC OA :

UNICOS Device Model Implementation
  • Device: a device is implemented as a datapoint (DP). A device is then identified through a DP name (used internally in WinCC OA and the different control scripts) and an alias (used by the operator). When operators refer to device name, it refers to the DP alias in WinCC OA. The name of a device DP is made of the following parts which are concataned with the dash character (-):
    • prefix
    • frontend name
    • application
    • device type
    • index
  • DeviceType: a device type is implemented as a DataPoint Type (DPT) in WinCC OA. It should always include the *_UnStatusInformation* DPT as well. It is a common practice to have the DPT structured with ProcessInputs and ProcessOutputs to gather the inputs and outputs of the device. Note that a UNICOS device which is an instance of a DPT has the DPT name as part its DP name (4th parts of the device DP name).
  • Application: it is part of the device DP name (3rd part).
  • Domain: is stored in description of .ProcessInput DPE. The description contains semicolon-separated fields: diagnostic;html_link;default_panel;domain;nature. Domain part of string can contain many domains, colon-separated.
  • Nature: is stored in description of .ProcessInput DPE. The description contains semicolon-separated fields: diagnostic;html_link;default_panel;domain;nature. Nature part of string can contain many natures, colon-separated.
  • FrontEndType: implemented as a DPT
  • FrontEnd: implemented as a DP of the FrontEndType DPT. Similar to the devices, the frontends have two names: the one known by the operators which is implemented as the DP alias, and the DP name itself. The name of the frontend DP is composed a the FrontEndType and the FrontEnd alias.