UNICOS CMWServer User Manual  9.0.2
 All Files Pages
Configuration file for CMWServer

Structure of configuration file

The configuration file is an ASCII file describing what devices and what properties of these device shall be exposed to CMW clients. Abstract syntax of this file looks like:

Device1
Property1
Property2
...
Device2
Property3
...

i.e. the file describes first device with all properties of this device, then next device with all properties of that device and so on. There is no limitation on number of devices, or on number of properties per device. However, there are two strict rules:

  • All device names in configuration file must be unique
  • All property names must be unique within one device


Exact syntax of configuration file is the same as the syntax of file used by RDA2-based CMWServer, in order to ensure backward compatibility.

[Device1]
dpe=<dpe_name>
alias=<dp_dpe_alias>
property=Property1
direction=<direction>
value=<value_data_type>
time=<time_data_type>
dpe=<dpe_name>
alias=<dp_dpe_alias>
property=Property2
direction=<direction>
value=<value_data_type>
time=<time_data_type>

Empty lines, separating blocks of property definitions, are not required in the file (though they are allowed), empty lines are added here just for clarity.
Indentations and whitespaces inside lines are ignored, or course, provided that whitespaces do not break the meaningful words into parts.

Description of every CMW device starts with the line containing device name in square brackets [] and lasts till start of next device, or till end of file.

Warning
One change compared to file format for RDA2-based server has been introduced though: the class name.

Class name is essential for RBAC: access rules for RBAC, generated from the content of CCDB, include class name of device as a part of rule, and rule for RBAC will only work if class name in access map matches the class name of device in CMW server.

RDA2-based CMW server was using one common setting for all devices, found in config file: one could specify class name in settings panel. In such case all devices for this manager were considered to be of the same class (from RBAC point of view), even if their structures (set of properties) were different.

This CMW server has introduced new rule for specifying device class by allowing two variants of device name specification:

[Device]
[Device _instance_of_ ClassName]

Note that 'instance_of' can be (in priniple) part of valid CMW device name. In order to distingruish the 'class name introducer' this word must be surrounded by spaces.

Warning
RBAC restrictions will not apply to devices without class name, as well as for devices with wrong class name (not equal to class name of this device in CCDB).

Adding possibility to specify class on per-device basis forces extra restriction on validity of config file, namely:

Warning
All devices, belonging to the same class, must have the same structure

This means that all devices, which belong to the same class in config file, must have the same set of properties. Furthermore, the direction, the value and the time for property in one device must be the same as corresponding attribute for property with the same name in another device.

Description of each property for device consists of at most 6 lines in configuration file. The description of property starts with dpe= line; in principle property= would be looking more natural for starting new property, but - backward compatibility...

The lines with empty value can be omitted, for example:

[Device1]
dpe=MyDp.MyDpe1.MyDpe2
alias=
property=Property1
direction=out
value=float
time=

The example above may appear as following, with the same result (alias and time lines are omitted):

[Device1]
dpe=MyDp.MyDpe1.MyDpe2
property=Property1
direction=out
value=float


Warning
The lines with information for one property may appear in any order, except for line dpe= that must be the first line (see backward compatibilit above).

DPE and alias names

The rule for dpe and alias attributes in property description is rather simple: these two attributes together shall form the name of existing DPE.
Either dpe or alias can be empty, but not both.

Possible values for direction

Possible values for direction attribute are summarized in the following table:

Value Meaning
out The value of property can be read by CMW clients using GET request. Clients can subscribe to proprty changes.
This corresponds to Acquisition property in Device Server model by BE-CO.
in The value of property can be set by CMW clients using SET request.
This corresponds to Command property in Device Server model by BE-CO.
in/out The value of property can be set by CMW clients using SET request; it can also be read by CMW clients using GET requests; clients can subscribe to property changes. That is, as one can guess, 'in/out' is a combination of 'in' and 'out'.
This corresponds to Setting property in Device Server model by BE-CO.

Any other value for direction attribute results in file parsing error.

Possible values for value

The value attribute is a data type for 'data' tag of device property as will be seen by CMW clients. The most natural approach would be using the same data type as data type of corresponding DPE, but this is not required (see type conversion).
One can notice that configuration file describes data type, but not cardinality: shall value for CMW clients be presented as scalar? As 1-D array?
The decision is hardcoded, and based on the data type of DPE:

  • DPEs of 'scalar' data types (int, float, string etc.) appear as scalar values for CMW clients.
  • DPEs of types dyn_xxx appear as 1-D array values for CMW clients.

Possible values for value attribute are summarized in the following table:

Value Meaning
boolean Boolean value, corresponds to bool data type in C
byte 8-bits signed integer, corresponds to int8_t data type in C
short 16-bits signed integer, corresponds to int16_t data type in C
long 32-bits signed integer, corresponds to int32_t data type in C
longlong 64-bits signed integer, corresponds to int64_t data type in C
float 32-bits floating point value, corresponds to float data type in C
double 64-bits floating point value, corresponds to double data type in C
string Character string (ASCII only!!!), corresponds to std::string data type in C
uint8 8-bits unsigned integer, corresponds to uint8_t data type in C
uint16 16-bits unsigned integer, corresponds to uint16_t data type in C
uint32 32-bits unsigned integer, corresponds to uint32_t data type in C
uint64 64-bits unsigned integer, corresponds to uint64_t data type in C

Any other value attribute will result in file parsing error.

Note that the last 4 data type names in the table are new, they were not presented in previous version of CMWServer. First types have the same names and meaning as they had in previous version of CMWServer. This requirement (keep old names and add new types) lead to some inconsistency of naming rules.

Warning
Note the comment about 'ASCII only' for string data type: current version of RDA only supports ASCII characters in strings, attempt to pass string with other characters between CMW server and client will result in error.

CMW <-> WinCC OA types conversion

It was mentioned in previous section that data type of 'data' tag is not required to be the same as data type of corresponding DPE: CMWServer implements 'reasonable' set of conversions from one type to another. The following table summarizes all allowed combinations of DPE data types and RDA data types; columns correspond to DPE data types, rows correspond to CMW data types.

bool char int uint long ulong bit32 bit64 float string time
bool ++ + + + + + + + + +
byte + + + + + + + + + +
short + + + + + + + + + +
long + + ++ + + + + + + +
longlong + + + + ++ + + + + +
float + + + + + + + + + +
double + + + + + + + + ++ + +
string + + + + + + + + + +
uint8 + ++ + + + + + + + +
uint16 + + + + + + + + + +
uint32 + + + ++ + + ++ + + +
uint64 + + + + + ++ + ++ + + +

Some comments for this table:

  1. '+' in cell means conversion is possible in both directions
  2. '++' in cell means conversion is 'not needed' because types are the same on both sides. In fact, some conversion is still needed because even 'the same' data types are presented internally in a different ways.
  3. Conversion of 'value' DPE (lint, float etc.) to bool CMW value uses simple algorithm: 0 value is converted to false, all other values are converted to true
  4. Conversion from string to non-string value uses boost::lexical_cast; all rules can be found in appropriate help pages on the web
  5. Conversion between DPE of type time and CMW types use the rule: number of milliseconds since start UNIX epoch

Possible values for time

The time attribute is a data type for 'time' tag of device property as will be seen by CMW clients (this corresponds to _online..stime attribute of DPE). Like for the previous version of RDA3 server, 3 possible time formats are supported.

Possible values for time attribute are summarized in the following table:

Value Meaning
double Number of milliseconds since UNIX epoch in 64-bit floating point value
longlong Number of milliseconds since UNIX epoch in 64-bit signed integer value
longlongnano Number of nanoseconds since UNIX epoch in 64-bit signed integer value
none Property does not have time tag
Property does not have time tag, the same as 'none'

Any other value for time attribute results in file parsing error.