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:
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:
Exact syntax of configuration file is the same as the syntax of file used by RDA2-based CMWServer, in order to ensure backward compatibility.
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.
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:
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.
Adding possibility to specify class on per-device basis forces extra restriction on validity of config file, namely:
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:
The example above may appear as following, with the same result (alias and time lines are omitted):
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 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.
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:
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.
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:
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.