A vision for the future


A vision for the future

Imagine a world where meters from different manufacturer are fully compatible with competing radio, power-line and telephone infrastructures; where multi-utility organisations use systems that enable them to obtain market share in an open, international arena; where AMR is deployed on a large scale, providing business opportunities for the developers and in supply, distribution, meter operation and data services.

For this vision to become reality, standards are essential. Do standards emerge from committees, or do they evolve from market leaders? How well are standards controlled and – more important – how well do changes reflect the best interests of the sector using them?

The challenge of compatibility

We have seen how Eurodis (France) conflicts with Mbus (Germany), or more globally how DLMS (Europe) conflicts with End Tables (USA). Is each country doing its own thing? And if so, how can we achieve competition across national boundaries? Has anyone yet achieved large-scale AMR, and how much do the ambitions of a single supplier cripple the progress towards full mobilisation? Are utilities afraid of spending large sums on something that might become redundant – and if they aren’t, what kind of risks are they taking?

This article defines mechanisms by which effective standards can be developed. It gives examples of standards that really have worked, describes how implementers have benefited and discusses what lessons need to be learned to build the "Global System".

A UK success story

In 1986 Landis and Gyr was developing a range of new electronic metering products. Siemens (then Ferranti) was busy with similar products, and approached Landis to ask whether Landis would be interested in using the same protocol for local interrogation.

At that stage Ferranti and Landis were serious competitors. After the initial negative reaction, however, Landis looked at the proposal in more detail. The protocol described a way to identify a meter manufacturer and type and ex-change unspecified data items with an interrogating device. There was also an anti-fraud security mechanism.

I was working for Landis & Gyr at the time. When we realised how we could use this protocol completely independently from Siemens, we agreed to co-operate. The result was FLAG, derived from the initials "Ferranti, Landis and Gyr". We managed to implement the protocol with-in 300 bytes of programming code on a 4-bit microcontroller!

Once the UK industry saw that two competing companies were using the same standard, the other manufacturers followed. ABB (then GEC Meters) and Schlumberger soon launched FLAG meters, and the smaller manufacturers demonstrated how unique features could be added to a metering system without changing the protocol.

At the same time the International Standard IEC1107 (a similar protocol to FLAG) was being developed, and manufacturers decided it would be useful to make FLAG a part of this standard. Only a few small changes were necessary to make FLAG a compatible sub-set of IEC1107. So FLAG – a real, open and practical standard for talking to meters – was born, and has been in use in the UK and related countries ever since.

But new developments in the industry brought new challenges. Different hand-held units (HHUs) running incompatible programs emerged from manufacturers, utilities and third parties. How could we standardise on the HHU transferring data between the meter and the utilities’ IT systems?

This time Siemens collaborated with ABB and Pilot Systems. FLAG interchanges stored in a series of batch files on the HHU provided an ideal mechanism for meter manufacturers to achieve the functionality they needed via a transparent carrier mechanism. Any HHU could be used, and the complexity of the low-level FLAG protocol was reduced to simple file-in and file-out. The result was a software specification and product called CHIRPS (Common Handheld Integrated Reading and Programming System).

CHIRPS – the common interface

Within two years, all the major meter manufacturers had launched products with full CHIRPS support. Any functionality between meter and PC could be done via CHIRPS. HHU companies such as Itron, Radix and Psion were supplying CHIRPS as a standard product, and its low cost ($200) made it an attractive solution.

The key to its success was that data files were still application independent. Meter manufacturers could launch new products and new features without any modification to CHIRPS, which became the industrial standard for meter connectivity via handhelds. Soon after, CHIRPS was distributed with meter manufacturers’ software as a PC version – the core of communications between PC and meter.

Manufacturers now use CHIRPS as the remote engine for telephone and cellular radio technologies. They write software to decode unspecified data to be communicated to a meter via simple ASCII files into the meaningful data in their own format. Because the CHIRPS specification is stable, it has become a useful piece of middleware – the kernel of second generation data collection systems, where manufacturers can add value to both ends of third party systems with new meters and decoding software.

Overcoming the hurdles

As we have learnt from Microsoft, successful open standards can be closed off for commercial gain, preventing others from making full use of their benefits. Both FLAG and CHIRPS were subject to these temptations.

The name FLAG had reached international acclaim, and many parties wished to have it associated with their products. So IEC1107 was actually called FLAG! Whilst this made many European meters "FLAG-compatible" at the stroke of a pen, it caused a lot of confusion. IEC1107 contains many different options. Claiming IEC1107 compatibility does not mean much unless you specify the FLAG sub-set, because it caters for so many different manufacturer specials.

Furthermore a whole series of specific annexes were added to 1107, with fixed format for data items, presumably in the hope that the name FLAG would carry them through, to the commercial advantage of the proposers. Immediately you start to specify what the data items should be, you lose the value of the protocol. Some manufacturers withdrew their proposals, but by then it was too late. IEC 1107 now had too much conflicting data with other manufacturers’ equipment, limiting its use as a standard.

Fortunately the Flag Association (an international group of FLAG users) was able to step in before it was too late. The FLAG protocol, correctly defined as a sub-set of IEC1107, has recently been documented and released as the FLAG "shortform". Available from the Flag Association, and only 13 pages long, this paper is useful for anyone developing meters for local or remote access. It is likely to become a standard in its own right, and will ensure meter systems are much more compatible in the future.

CHIRPS also became vulnerable to commercial pressures. The electricity supply industry in the UK was rapidly liberalising, and there were a few non-FLAG meters competing for share in the 100kW market in 1994. CHIRPS was the ideal candidate for local read as a back-up to remote dial-up, but it needed to read non-FLAG meters too. As a consequence, CHIRPS implementers bolted on new protocols for short term commercial gain, but this only clouded the issue as to what was standard. It also put CHIRPS on a level with multi-vendor software – "We’ll implement whatever protocol you want" – which was not the long-term intention of the implementers or of the meter manufacturers.

Again it was necessary to take action, and CHIRPS is now firmly supporting the FLAG protocol. There is also a much closer relationship between the CHIRPS implementers and the meter manufacturers. The Protocol Tester software, commissioned by the electricity pool in the UK to Pilot Systems, is based on CHIRPS and will ensure that all new electronic meters for sale in the UK are FLAG and CHIRPS compatible.

There are still many hurdles to overcome. Some manufacturers are ignoring standards and relying only on commercial arrangements between other vendors to ensure compatibility. Such closed systems are only of short-term gain. The use of CHIRPS may not be so attractive to the larger manufacturers who are dominant in a particular country, but they should beware – the smaller vendors who use CHIRPS are gaining market share because of their more open approach!

Liberalisation – an open future

The concepts of FLAG and CHIRPS provide an excellent platform for the metering system of the future. The key is not to specify the data type and format in the lower level protocols. This frees up meter designers to add new functions and features.

Communications companies should make sure they can transmit simple files up and down their system, whatever functionality they provide, so that meter manufacturers can use CHIRPS without engaging in lengthy design discussions.

Systems can even be made DLMS or End Table compatible using existing meters and formatting software further up the system. The format and type of DLMS objects are still under discussion, and it is good that the use of FLAG and CHIRPS allows implementers to match these formats in system software, rather than having to hard-code them in the meters. It means that products can be compatible with both European and US approaches.

Where do we go from here? Clearly manufacturers must be encouraged to use FLAG for both remote and local access, which will ensure CHIRPS compatibility. We must develop FLAG for new mediums – for example inductive couplers for use in water and heat meters. And we must make CHIRPS more available and more accessible.

Some of this has already happened. CHIRPS will shortly be available on low cost single-chip microcontrollers for integration within AMR systems. Standard TCP/IP and FTP protocols for uploading and downloading file messages to the chip ensure compatibility with Internet and Intranet. And a method for overlaying CHIRPS files onto fund transfer protocols such as EDIFACT, used in banking and adopted within the electricity supply industry in the UK, ensures compatibility with a wide range of billing.