FLAG, CHIRPS and OMS – getting on board


FLAG, CHIRPS and OMS – getting on board

In the last issue of Smart Energy International, we discussed a future where full mobilisation of data connectivity between the customer and the utility would be the norm. The technology will support almost any box of electronics installed in the customer’s premises, allowing for example home automation, customer display and security. The beauty of the system is that any vendor can get on board, without any special modifications and unrestricted by the protocols.

The key is to use the protocol tester which is being written for the electricity pool in the UK. The tester will be used by the pool and by regulatory agents to ensure that new electronic equipment is compatible. Its structure ensures compatibility with available communications technologies, and gives equipment manufacturers the flexibility to develop products for an increasingly diverse market.


The first test is to run CHIRPS on the meter, to exercise the FLAG protocol. This is done via either an IEC1107 optical port or a standard or current-loop serial port on the meter. CHIRPS executes the commands from an instruction file (INS file) and gives an error diagnostic if the meter is not FLAG conformant.

The FLAG protocol is available in the public domain, but most manufacturers prefer to use the range of off-shelf CHIRPS products to implement the protocol. This means their systems only need to deal with files, and not with low-level serial communications – an advantage when implementing multiple dial-up systems on the different operating systems required today.

The tester provides for other protocol drivers to be hooked in, via DLLs or a special version of CHIRPS. These are not used in UK testing activity, but do allow non-FLAG equipment to be included within the infrastructure, where manufacturers supply their own low-level protocol "driver".


The resulting CHIRPS response files (RES) are then converted from manufacturer-specific format to common OMS format, independent of meter. For Code of Practice 6, there is a specified format for the structure of registers and half-hourly data in the meter, so only one conversion routine is required. The CHIRPS RES files from each meter manufacturer for Code 6 are therefore identical in this case.

The conversion routine scans the response file and checks that all the data items required for Code 6 are present. It also checks the correct format before converting to OMS, and produces a diagnostic if an error is found. Once converted, the OMS file can be viewed to check registers and interval data visually.

The OMS file format is a public domain document, allowing the formation of data structures like interval data, registers and time-stamped values for multiple channels, dates and sites. The file format does not prescribe individual data item format; it merely acts as a mechanism for vendors to present their data in formats required by the customer. Again, manufacturers can provide conversion protocol "drivers" to meet the requirements of the utility.


This test ensures that data in the meter is compatible with itself! Registers are compared with totalled interval readings, and time-stamped values are compared with previous values. This module is specific to UK Code 6 requirements, but once again it can be replaced by other modules for different international and regulatory needs.


Some components of the protocol tester can be used separately. This allows manufacturers to achieve structured compatibility, and also provides additional benefits in the development of electronic products, supporting systems and test equipment.


PCHIRPS is an executable file that runs under DOS or Windows, accepts parameters via the command line, and returns error codes, or 0 if data exchange is successful. The filename of the INS file, comms port and phone number (if operating in remote mode) are all passed via the command line. To be CHIRPS compatible, it must be possible to perform all operations between meter and supporting system via CHIRPS.

PCHIRPS can form an integral part of the manufacturer’s support software – tariff schemes, con figurations and display sequences. Registers supported are set up via graphical user interfaces, and CHIRPS files are generated from these to download to the meter via PCHIRPS.

The same CHIRPS files can be used on the production line for setting default values in the equipment, or passed to the utility to meet its specific requirements. Utilities can assign the same scheme name to CHIRPS files for different manufacturers’ equipment, to associate a name with a particular tariff or configuration set-up. The files can also be loaded to handheld units running CHIRPS – which includes most DOS or semi-DOS compatible units – and integrated within a total system solution from the manufacturer.


FLAGSIM is not a component of the tester. It is a DOS or Windows based FLAG simulator that pretends to be a FLAG meter, extremely useful as a development tool. FLAG data items are stored in a CHIRPS RES file and returned when requested from an interrogating device. RES files can then be developed in Code 6 format, so that a full Code 6 meter can be simulated and used as a benchmark for new market entrants who wish to develop a Code 6 meter. Other formats can be specified for different country or regulative needs.


The ability to produce OMS files via manufacturer-supplied drivers has opened up many new opportunities in data collection, and has triggered the emergence of the second generation data collection system.

In 1994, when competition was introduced for 100kW+ sites, one of the major problems was the large number of protocols that had to be supported by all meters. First generation systems were concerned with implementing these protocols and using them to add value. A monopoly situation for the organisations which owned or ran the system was created, which prevented meter manufacturers from adding value themselves. There were also problems with support issues; if the system did not talk to a particular meter, there was always argument as to whether the problem was with the system or the meter.

The use of CHIRPS and OMS allows manufacturers to take full responsibility for the integrity of the metering system. In the same way as printer manufacturers supplied a printer and driver in the good old days of Windows 3.1, so manufacturers can supply meters and "drivers". The principle encourages innovation and is the key element of the second generation system. We will even see data collection systems developed by manufacturers which read meters supplied by their competitors – some-thing that could never be achieved in the past, because it meant handing over protocol details.

The protocol tester will provide the framework for manufacturers to develop meters and their associated "drivers". This will encourage new developers of second generation data collection systems to emerge without restriction because of access to protocols. Such technology provides a win-win situation for everyone – meter manufacturers , system providers, utilities and, most important of all, the customer.