188.8.131.52 The Use of Time Locales
All data published by BMRA that involves time stamps or DateTime data formats are published in GMT. Data is received from the System Operator in GMT and is published without conversion into local time.
Messages for all data that is based around settlement periods contain Settlement Dates and Settlement Period numbers, which are a number between 1 and 50 describing the number of the half hour period relative to midnight LOCAL time.
184.108.40.206 Conversion of Effective from/to data into Spot Time data
Some data received from the System Operator. is received in the format of effective from and to times. The types of data which is received in this format are: - FPN, QPN, MIL, MEL, BOD and BOAL.
This data is not represented in this same fashion in the BMRA published messages. Instead it is described in the form of spot times and values. This is to eliminate data redundancy in the messages and reduce network traffic.
Since a ‘from time’ is the same as the previous ‘to time’, and in the vast majority of cases the ‘from level’ is also the same as the previous ‘to level’, it is inefficient to send both. BMRA therefore converts the data from the System Operator. into a series of spot points and levels. This is a sequence of times, each of which has an associated level. The spot times are always on the boundaries of ‘from times’ or ‘to times’.
The diagram overleaf illustrates how this conversion is done. The shaded areas in the from/to level formats are the non-redundant data parts which are added to the list of spot times. Those that are not shaded are redundant and therefore left out of the list of spot times.
The spot time data may be converted back into from/to level data using the number of spot times and comparing spot times to see if a step in levels has occurred.
The following diagram shows how data in the form of From and To times is converted into Spot Times. To avoid redundancy in the published data, From Times and Levels which are identical to the previous To Times and Levels are removed. The shaded data is retained and passed on as spot times in the published message.
Third party applications may be written or adapted to interface to the near real-time TIB messages that are published by BMRA. The application registers interest in specific message(s) by subscribing to message subject names(s). Message(s) are then received by the application, which then has to processes the field data and store or display as required.
In order to receive and process TIB messages a licensed copy of TIB/Rendezvous version 6.2 must be installed on the host machine for the application to be adapted. TIB/Rendezvous software includes an application program interface (API) for making all the necessary requests for subscribing to a TIB message, receiving it and processing the composite field data. The API is available in C, C++, Java and Perl programming languages. (The API is also available in Active X/Visual Basic if TIB/Rendezvous version 5.3 is installed. TIBCO have confirmed that TIB/Rendezvous version 5.3 is compatible with published TIB/Rendezvous version 6.2 data.)
For each supported API, TIBCO provide example source code that may be used and adapted for development of a bespoke TIB/Rendezvous application adapter. For the C API for example, “tibrvlisten.c” is a working program that listens for all messages on a specified list of subjects. The code will need to be adapted to:
1. specify the correct service group in the creation of the rv transport;
2. listen to the desired subject names;
3. process the received message;
4. parse the message for field data;
5. interface the field data with the application, as required.
220.127.116.11 Specifying the service group
The UDP port (or service group) must be configured in creation of the rv transport. The UDP port defines the broadcast channel for which TIB/Rendezvous messages are sent and received on the participant LAN. The default port for TIB/Rendezvous (UDP port 7500) will be the port configured on the participant Rendezvous Routing Daemon to publish TIB messages originating from the BMRA.
A “listener” is created to listen for message subject name(s). The listener must be given the subject name to listen to and the call back function to process the message when it arrives. Subject names that are published by the BMRA are listed in section 4.7.5.
Subject names are hierarchical and consist of multiple elements separated by dots. The listener can receive a group of related messages by specifying a wildcard (“>” or “*”) in the subject name. “BMRA.BM.BMUNIT01.>” can be used for example to listen to all message subject names that begin “BMRA.BM.BMUNIT01”, i.e. all balancing mechanism data for BMUNIT01.
Extreme care must be taken when specifying wildcards in message subject names. The use of the wildcard character in place of the BM unit id would mean that messages for all BM Units (there are estimated to be between 1,000 and 5,000 BM Units) would be received and have to be processed by the application.
18.104.22.168 Processing the received message
Each message that is received and identified by a listener will invoke the specified call back function. Code must be written for the call back function to process the message and parse the field data.
Each message consists of field data. The structure of each message, broken down into its composite fields, is listed in section 4.7.5. Each field has a defined type and is listed in section 4.7.4.
In order to parse the message for each field, the GetFieldInstance function (of the TibrvMsg class) can be used to specify the field type and return each instance of the field type. In this way, messages that consist of multiple fields of the same field type can be indexed to return data for each field instance. For example, National Demand Forecast messages (section 22.214.171.124) consist of multiple instances of Publishing Date (TP), Settlement Date (SD), Settlement Period (SP) and Demand (VD). Repeated calls of the GetFieldInstance function, specifying the field type and an incrementing number for the field instance, will return each specified instance of the field type.
126.96.36.199 Interfacing the field data with the application
Field data that is returned from the GetFieldInstance function must be cast to the appropriate C/Java type for use by the application. The application can then use the data as required.
(The data could be stored for later off-line analysis in a database/data warehouse. Alternatively the data could be written to the display to present a near real-time dynamically updateable view of subscribed data.)
Care must be taken with data fields of type “float” to ensure that the correct rounding is performed.
For further information on TIB/Rendezvous concepts and programming please refer to the following documentation supplied by TIBCO Software Inc and available from their web site at www.tibco.com.
TIB/Rendezvous Concepts, Software Release 6.2, March 2000;
TIB/Rendezvous Administration, Software Release 6.2, March 2000;
TIB/Rendezvous C Reference, Software Release 6.2, March 2000;
TIB/Rendezvous C++ Reference, Software Release 6.2, March 2000;
TIB/Rendezvous Java Reference, Software Release 6.2, March 2000;