Smart grid standardization is not just something the energy market is striving for. Industry 4.0, digital signage, home care and fleet management applications are also in dire need of standardization and unified communication.
As diverse as these applications seem on the surface, they all basically work within the same infrastructure, which means they should therefore utilize common standards based on open intelligent systems.
The configuration of existing M2M applications is usually more or less identical. Sensors are connected locally to gateways or aggregators using different methods. These deliver data to the cloud or they themselves act as the cloud server, which in turn is connected via various options to corporate IT.
Connecting sensors at field level is often quite a heterogeneous matter. Wireless networks are currently the preferred choice for smart home applications. And wireless is also chosen for industrial energy management systems, where consumption data has to be collected locally and analyzed centrally. Examples are Zigbee, Bluetooth, CoAP and 6LoWPAN, WirelessHART or just ‘plain’ WLAN. The choice for wireless is an obvious one, as it minimizes the effort and cost required for cables and integration.
Digital signage applications are however a somewhat different matter. Here, the M2M gateways are often combined with digital players in one device, eliminating the need for any further local networking. Similar types of configuration are found in health card applications where all the required data is loaded ‘on demand’. In energy market applications, the local peripherals are connected via industrial field buses or Industrial Ethernet networks to the M2M edge nodes of the wind turbine parks. On the end user side of things wireless installations with aggregators are preferred in the smart meter segment. And when it comes to fleet management systems how to connect these to the vehicle’s electrical system is an interesting question. For commercial vehicles CAN is often required. All in all, a whole range of options is used, to capture and transmit information which is produced locally to the cloud. Or in the case of digital signage systems distribute and broadcast advertising messages. But everything which follows on in the direction of the cloud can be standardized.
Gateways and aggregators communicate towards IT landscapes in a much less heterogeneous way. More often than not GSM/UMTS/LTE, WLAN or Ethernet options suffice. That’s it. Then it’s just a question of entering the cloud. Alternatively, the gateway or aggregator itself becomes part of the cloud and provides the collected data. Its own IP address suffices and the system can be accessed from anywhere in the world. The Internet of Things is evolving. And thanks to the IPv6 standard there is nearly an infinite number of addresses available. So at the very latest, this is the point where suppliers of industrial solutions have to be familiar with all the subjects which drives IT departments to new developments. Take energy dashboards as an example, these can be accessed from anywhere in the world with any type of device i.e. with a smartphone.
Gateways should therefore be in a position to actively send data to these dashboards in formats like CSV, XML, JSON via protocols like FTP or HTTPS. Central data storage in a secure cloud at the network carrier’s or on an in-house server is what is needed here, so that local aggregators do not have to be ‘always on’. In order to realize a solution like this, the gateway requires its own intelligence.
This goes to prove that M2M has far more to do with IT than with embedded intelligence. So basically, it is no longer a question of whether intelligent systems for these decentralized cloud aggregators should be used or not. For The Internet of Things we need open intelligent systems and a universal communication standardization. As far as possible this has to be industry-independent, as everyone benefits from developments in other industry sectors. And only this ensures enough flexibility to allow for systems to be adjusted to fit the specific needs and to respond to security issues. Or would the assumption be correct, that individual manufacturers of numerous distributed systems, which then produce real ‘big data’ are in a position to face security issues on their own?
So, there is a clear need for M2M standardization. And it is needed at every level of the entire M2M chain. Organizations such as the OneM2M Organization (www.onem2m.org) define standards of the M2M/IoT service layer, which are application-ready and can be integrated into different hardware and software products. Standardized hardware based on open intelligent systems, as for example represented in the Kontron M2M Smart Services Development Kits can also form the technological basis for a variety of M2M gateways and aggregators which can also simultaneously act as a decentralized cloud server. The connection of peripheral devices remains as easy as it always has been with embedded computer systems: With the variety of I/Os in the field, if appropriate standardization takes place the right I/O components can always be found. So why not work on a standard for embedded cloud servers? Several embedded computer manufacturers have already submitted a draft for just this.
 9. 10. 2012, Lecture by Dipl. Ing. H.- D. Kreft to automation experts
 Smart meter, smart grid – a typical German disaster?
Communication in industrial energy management
Kontron‘s intelligent M2M platform is used as a gateway in the EpiSensor Energy Monitoring System, which works with Zigbee sensors. For management and monitoring tasks, via a built-in webserver the EpiSensor gateway offers access to buffered live data as well as to sensor settings. The sensor data can be transmitted to different energy dashboards and to companies’ IT systems, like for example, ERP (Enterprise Resource Planning) or MIS (Management Information Systems) as well as technical management systems like i.e. EMS (Energy Management Systems). Data can be transmitted in a wide range of formats including CSV, XML and JSON – and protocols such as FTP and HTTPS.