Data Model
The Function concept impacts the following main elements:
Platform Data Type | It forms the basis for the Object Model set up on Desigo CC (no longer described in detail). Platform tools are required in individual cases for driver development of additional subsystems. |
Object Model | All Desigo CC basic data types are designated Object Models. The corresponding default value is defined per subsystem for each Object Model. |
Function | Function includes the semantic description (for example, fire detector or temperature sensor) for one or more specific data points. |
Instances | Imported project data can be modified specifically to the instance using the Object Configurator. |
Project Data | The project data (SiB-X) contains the specific information on a data point or data point amount by the system and is responsible for Desigo CC response. The Function or Object Model supplements missing information on a project data point to ensure uniform functioning of Desigo CC. Instance-specific modifications are possible using the Object Configurator. |
The tree structure ensures a consistent operating, commanding and alarming philosophy for the various integrated subsystems. The benefits of this concept include:
- Discipline-specific project data from fire, HVAC, intrusion, and so on can be configured using the same mechanism.
- Additional or new systems can be easily added. It can be accomplished at Vendor’s HQ or the appropriate regional companies as well as for customized integrations.
Instantiated objects for individual subsystems are always related to an Object Model and a Function. This concept ensures that the user experiences the same operating and monitoring philosophy for the same or similar Functions.
Another benefit of Function is that the same operating philosophy is used for new as well as existing systems and extensions or replacements of parts of a plant. As a result, operators do not need to learn a new operating philosophy. This increases the operational safety of your plant.
NOTE:
Desigo CC permits assigning an instantiated object directly to an Object Model. You should, however, continue to use Function from an operational viewpoint relating to maintaining the value of a system. When replacing or extending a plant, the new system can easily be mapped to the corresponding Function without having to create new mappings. Furthermore, the old and new system can be operated using the same philosophy.
Property Mapping
The various names (for example, PrVal = Present_Value) for individual systems to be integrated must be mapped to a Function using a mapper for uniform display of objects based on Function. The number of Object Model properties of the individual subsystems may differ from Function (see the Object Models on System 3 under Examples 2).
Example 1: The Temperature Sensor Function is used for only one subsystem:
Example 2: The Temperature Sensor Function is used by multiple subsystems:
Although different property names are defined for the various subsystems, the Function Mapper allows for easy assignment of these names to the corresponding Object Model.
Simple Mapping
Simple Mapping has a 1:1 relation via the Function Mapper between Function and the Object Model. For example, this is an automatic fire detector (physical data point only) for a Function.
The individual properties are mapped to the corresponding properties of the Object Model using the Function Mapper. As each subsystem has its own Object Models, Function can be assigned to the corresponding Object Model via the Function Mapper.
Functional Mapping
As part of Functional Mapping, which is independent of the subsystem, several Functions are required for object display and operation. This requires that the logical mapping in the system be hierarchical. For example, a pump with digital I/O.
Example 1 shows Pump1 and Pump2 with the PumpFctDigital Function as well as two subordinate Functions, CommandDigital and MonitorError. During graphic engineering, drag-and-drop takes place on the object hierarchy of Pump1 and Pump2. During operation in the Operation tab, the properties of the CommandDigital and MonitorError Functions are displayed together for the selected pump (if configured accordingly).
Example 2 represents an additional hierarchy between the PumpFctDigital and the CommandDigital and MonitorError Functions The functionality for engineering, display, and operation is the same as in example 1.
When creating a Functional Function with several data points, several workflows must be carried out to inherit the data.
- Create a CommandDigital and a MonitorError Function.
- In the Function Mapper of the Digital Output Object Model, assign the CommandDigital Function.
- In the Function Mapper of the Digital Input Object Model, assign the MonitorError Function.
- Create a PumpFctDigital Function.
- In the Function Mapper of the PumpFctDigital Function, assign the properties of the CommandDigital and MonitorError Functions.
Assigning a Function to an Object (Instance)
With known subsystems, Function is assigned directly to individual objects during SiB-X data import. With third-party integration, the Function information is not available and must retroactively be assigned manually to individual objects in the Object Configurator (Assigning a Function to a Data Point).
Extended Mapping
As part of Extended Mapping, which is dependent of the subsystem, several data points are required for object display and operation. This requires that the logical mapping in the system be hierarchical. For example, a pump with digital I/O.
Example 3 shows Pump1 and Pump2 with the PumpFctDigital Function as well as two subordinate data points, Cmd and Dp (no Function assigned). During operation in the Operation tab, the properties of the Cmd and Dp data points are displayed together for the selected pump. During graphic engineering, drag-and-drop takes place on the object hierarchy of Pump1 and Pump2.
Example 4 represents an additional hierarchy between the PumpFctDigital Function and the Cmd and Dp data points. The data cannot be mapped due to different object hierarchies. If both variants exist in a project, the two Functions must be assigned different names (not recommended).
Example 3 shows how a PumpFctDigital Function is created and the .Cmd and .Dp hierarchy information is used for the subordinate objects.
Example 4 shows how a PumpFctDigital Function is created and the Hierarchie.Cmd and Hierarchie.Dp hierarchy information is used for the subordinate objects.
Assigning a Function to an Object (Instance)
With third-party integration, the Function information is not available and must retroactively be assigned manually to the parent object (Pump1 and Pump2) in the Object Configurator (Assigning a Function to a Data Point).
Mixed Mapping
Mixed mapping is used to map two or multiple objects with the same object information to one object. Typical examples are fans, pumps, dampers operated in parallel in terms of functionality.
Example 5 shows Pump1 and Pump2 with additionally engineered hierarchy object below the PumpTwin Function. Each hierarchy object has a subordinate CommandDigital and MonitorError Function for its functionality. Making the hierarchical objects .Pump1 and Pump.2 part of the TwinPump Function results in unique individual object information.
During graphic engineering, drag-and-drop takes place on the object hierarchy of Twin-Pump. The properties of both pumps are displayed during operation in the Operation tab of Twin-Pump.
During data processing, the data is taken over for display and evaluation, or supplemented to correspond to the mapping below. Missing information is taken over from the next lower information source if possible.
The illustration below outlines the flow of information from a project data point (for example, Outside and Supply) up to visualization in Desigo CC.
Explanation of Above Example | |
Project Data | Imported project data includes detailed information, in this case the Max/Min limitations for the given data point as well as the online value. These Max/Min values are taken over as limitations by Desigo CC operation. |
Instances | The following project information is not included in the instances and needs to be added:
|
Object Configurator | The operator creates a Management Station alarm in the Object Configurator. |
Function | Function provides a number of temperature symbols for the use of temperature. They are displayed during graphics engineering for the given data point. The definition of the Contextual pane or commanding is defined in this case at Function. May/Min limitations are not relevant for the data points, since the information is specified in the project data. |
Object Model | The basic information is defined in the Analog Input Object Model. An alpha numeric display symbol is defined for graphics engineering. Corresponding presettings are defined for operation, commanding and Max/Min limitations. They are only used if no corresponding information is available in Function or the project data. |
User Interface | Display information for a data point is comprised of:
|
Detailed information on the various application types is described below.
The following section displays some examples of the data relationship from Object Model and Function to the Operation and Extended Operation tabs.
Fire Detector
Sensors
Motor (with Object Hierarchy)
A corresponding hierarchy object is generated during database import if an object hierarchy exists during programming of a complex function (for example, pump, fan).
Motor (without Object Hierarchy)
The object hierarchy is created manually using the view builder if no automatic object hierarchy is generated during data import. When creating an object hierarchy, a View node is created as Object Model as well as an additional Desigo CC hierarchy object. This permits the use of the same function as for a hierarchical object.
