Smart data dependency

Smart, as its name implies, requires lots of data from a range of sources and types. For example, smart cities require data streams in broad categories:

• Traffic flow with real-time (<1 sec) response, including intelligent transport systems to manage traffic lights, congestion, parking and support for emerging autonomous vehicles; 
• Environmental data, such as air quality networks measuring particulates, pollutant levels, acoustic sensors for pipeline leaks and Internet of Things (IoT)-enabled waste receptacles with associated service routes;
• Utilities and infrastructure including smart grids, smart lighting and smart water metering; and
• Public safety and governance functions that use edge intelligence to monitor CCTV and crowdsourced data along with emergency-responder support in interrupt-based systems.

Almost all these data sources use wireless signal transmission for at least part of their collection processes. Fortunately, at least from the smart city perspective, integrating data from each of these systems occurs at the enterprise level by which time it’s been processed into a common database typically JavaScript Object Notation (JSON).

As any of us who’ve  connected third-party systems can attest integration challenges are at the control layer. This is where the importance of interoperability comes into play. Interoperability is required to gather data from sensors and equipment, such as transformers, relays and pumps, and then transmit  actuation commands to make smart cities intelligent.

The degree of interoperability and effort required to have all the different systems and subsystems communicate is a function of how completely the protocol defines and maps the configuration details between the different elements. 

Fully defined industrial protocols typical of industrial automation, largely based on electronic device description language/device type manager (EDDL/DTM), are easier because their defined I/O mapping can be easily understood. On the other hand, protocols like distributed network protocol 3 (DNP3) require arguably twice the effort of the industrial protocols to define point lists, configure objects, deadbands and event buffering logic. DNP3 is used extensively in North American utilities.

Get your subscription to Control's tri-weekly newsletter.

Lastly, complex protocols such as IEC 61850 take about twice the effort because of their substation configuration language (SCL) and extensible markup language (XML) import mapping of complex object model to symbols. Industrial protocols are largely developed and compliance tested by their sponsoring consortia (FieldComm, Profibus, etc.) to ensure interoperability—though having lived through it in the 1990s, it was not a trivial exercise.

Unfortunately, this interoperability isn’t available for other protocols, in part because most standards developing organizations (SDO) don’t have arm’s length compliance/certification divisions to do interoperability testing. IEC has a multilateral certification system called IEC System for Conformity Assessment Schemes for Electrotechnical Equipment and Components (IECEE), but it doesn’t do protocol interoperability testing.

Interoperability, particularly for power transmission and distribution protocols, will become increasingly important and arguably critical for integrating smart homes to smart grids. With most home-based solar panels being used by consumers, they’ll need foolproof connections to their smart meters. This is because some will be challenged to maintain the apps and security software on their phones, so they can sell and buy into their local grid. Similarly, the grid will also incentivize users to allow it to use electric vehicles and other large batteries as storage devices and buffers, adding another layer of complexity to home-based, nano-grids.

Likewise, BACnet protocol for building automation also has some interoperability issues, mostly because manufacturers have used its custom block for what should be defined features. There’s no way to test a customized, manufacturer-specific block because only the wrapper needs to comply with the standard, while the details of what’s inside and what’s stored where in the device’s memory can be unique.

This same interoperability challenge exists all along the transmission and distribution chain, where transformers and intelligent electronic devices (IED) from different manufacturers can’t talk to each other. Hopefully, consumers pushing for a plug-and-play home, and energy producers seeking a smart grid that’s more economical than new power supplies, will find a way to make interoperability happen on the electrical grid.