JEA

Inter-operability broadly refers to the ability to exchange data or communicate between two disparate systems or devices.

The mere existence of an open standard, if followed precisely, is sometimes misconstrued as inter-operability. Yet this is not the case. This is only the beginning of the process. Successful inter-operation of devices requires a very high level of maturity in the implementation of standards – often achieved through rigorous field experience, comprehensive testing and collaboration between integrating partners.

Further, one might encounter situations where meaningful interpretation and use of data between two disparate systems can simply be achieved by existence of common system level data inter-faces (sometimes referred to as ‘system level inter-operability’) as opposed to every device communicating with the other device (referred to as ‘device level inter-operability’).

Inter-operability and inter-changeability

In the context of metering in Europe, The Smart Meter Communications Group (SMCG) acting on mandate M/441 has tried to clear some of the haze by defining yet another term – ‘inter-changeability’. Accordingly, ‘inter-operability’ is the ability of a system to exchange data with other systems of different types, while ‘inter-changeability’ is the ability to exchange one device with another without reducing the original functionality. The focus of inter-changeability is to replicate the device use experience in the same way.

Relevance of inter-operability and inter-changeability

Inter-operability is required to enable devices to work together to produce a coherent set of data, which can be used by a business system. Inter-changeability is required to seamlessly replace one device by another without altering the use experience.

The relevance of these two terms is best understood in the context of two distinct large-scale smart meter programmes, those of Australia and Great Britain.

The Australian Power of Choice programme is based on the principle of system level inter-operability and it requires each accredited meter data provider (MDP) to collect data from their respective smart meter populations and transmit this data, in a defined format, to the national centre managed by AEMO. The ambition is not to create a situation where the devices are inter-changeable or to allow multiple meter data providers’ access to the same information. The data is sent to the AEMO for settlements and distributed further to the billing authorities or network operators.

The beauty of the Australian solution is its relative simplicity and scope for competition and innovation. The focus is on the availability and accuracy of data (not the method of getting it).

In contrast, the GB solution is heavily dependent on device level inter-operability or inter-changeability. There is a single regulated national data communications entity (called the DCC) and a multitude of devices in the home are expected to be interchangeable.

Thus the communication hubs, electricity and gas meters, in-home displays and various other devices from different manufacturers need to communicate interoperably and inter-changeably with one another in a seamless manner.

The GB model is relatively complex which has in effect resulted in enormous delay to the programme. The system requires all device manufacturers to follow a single nationally defined communication specification. In face of competitive retailing, this model provides the advantage to the retailer to choose any device for any premise without the installer having to carry a multitude of products in their vans.

There is no universal truth about whether either inter-operability or inter-changeability is necessary or sufficient. At the end of the day, the right solution is the one that delivers a reliable service at the lowest cost to the consumer in any situation.

Inter-operability and inter-changeability roadblocks

While inter-operability starts with an agreed standard, the next step can only be achieved through a rigorous process of comprehension, product engineering, verification and industry-wide collaboration.

This is particularly true when device level inter-operability (inter-changeability) is desired. While two products may meet the same protocol and standard, and perhaps even be certified standard compliant, it does not mean that they will actually communicate seamlessly in the user environment. The following section outlines some common roadblocks.

Conflict between inter-operability and flexibility

In order to allow for a degree of flexibility, encourage innovation and take into account a number of variables, as standards are not often too rigid or narrowly defined.

However, this creates a conflict with exact definitions required to achieve seamless inter-operability.

Interpretation Communication standards are often complex and mere textual description may lead to multiple interpretations of the same conditions by different manufactures and system integrators. This leads to a varied set of approaches to development and implementation.

Standards don’t deal with exceptions: Communication between two or more disparate systems may need to work in many different situations. Often the biggest challenge with device level interoperability stems from the different ways in which exceptions are handled under different circumstances in the field. Consider for example, the GB smart meter programme that is required to support at least 11 different variants of communications hub, each of which must inter-operate with 3 types of electricity meters (each with multiple manufactures), 2 types of gas meters (with multiple manufacturers) and a whole portfolio of other devices like the IHD, PPMID (prepayment meter interface device) and HCALC (HAN connected auxiliary load connection device). The devices alone have more than 99,000 potential deployment combinations!

Now imagine these being used under 100s of business use cases leading to 10s of millions of use conditions. Each use condition may have some abnormal state, such as power fail, no or delayed response, wrong response, inaccurate time stamp etc. Seldom is any standard able to comprehensively define how these abnormal conditions or exceptions need to be handled by the system.

It is evident that while standards cover a whole range of possibilities it is hard for them to deal with every eventuality. In such a case, developers will adopt their own solutions that may not be inter-operable.

This individualised approach makes interoperability more challenging.

How do you ensure inter-operability and inter-changeability?

When you are trying to define a system in which you are trying to achieve device level inter-operability and inter-changeability, the following steps could be worthy of consideration:

Definition of standards:

Start with the definition of the standards. The standards need to be fairly comprehensive and must define communication type and media, media access, protocol and semantics for the data. Traditionally these are fairly well defined across various jurisdictions.

Customarily, standards consider the following elements:

· Communication medium (e.g. 2.4 GHz wireless)

· Media access methods (e.g. IEEE 802.15.4) · Network and higher layer protocols (e.g. Zigbee)

· Semantics (e.g. Zigbee smart energy ZSE1.2) While most inter-operability projects use standards that define the above elements, successful inter-changeability would demand standardisation of two additional dimensions, namely (a) standardisation of process flow sequences and (b) standardisation of the method of handling exceptions. Needless to say that comprehensive definition of these aspects is rather challenging and often discovered through in-field experiences only.

In-field testing and iteration:

Once the devices are certified to be communicating, they need to be placed in ‘real time, real life situations’ for further testing. This is a process commonly practised in beta testing for software, allowing developers to find holes and patch the gaps prior to general release. Importantly, this leads to continual refining of the experience and software. Exceptions not foreseen can be identified and addressed. And while this is commonly aimed at consumer products, ideally this type of system should be used in a greater or lesser way for smart meter inter-operability.

An ideal way would be to create test houses where products are installed and used in a ‘natural’ environment with a view to simulating real life engagement with the products and systematically executing as many use cases and simulated exceptions as possible. The GB smart meter programme is setting up a Smart Meter Device Assurance (SMDA) test house for this purpose.

The success of the test service would lie in being able to simulate and validate all use scenarios and exceptions with at least 95% comprehensiveness index.

Develop guidelines for handling cases where the present system does not work:

Exception handling is vital and is the one variable, which cannot have all the permutations, pre-defined without extensive inter-operability testing.

This is an industry wide challenge. Because of the tight time scale and the pressure to achieve targets we believe it is important to maintain a balance between what you are trying to achieve and an ambition to achieve a utopian solution, especially when you take into account what the solution will cost the consumer, as surely they are the ones who are paying for it in one way or another. MI

About the company

Secure Meters researches, manufactures, and deploys products and solutions to measure and monitor energy usage. The company offers electricity metering products, such as gas metering products, communications devices, software products, home display and monitoring devices, and industrial control and monitoring devices for meter test equipment, grid and bulk power metering, prepayment metering, and low voltage current transformers applications in the utilities sector.

REFERENCES

i https://en.wikipedia.org/wiki/IEEE_802.15.4
ii https://en.wikipedia.org/wiki/Zigbee