Data Concentrator: Unfairly ignored parts of modern smart grids
A data concentrator is an often-overlooked element of smart grids. Often it is seen as a gateway between a TCP-IP network and a communication network of electricity meters. In fact, the concentrator performs a number of other very important tasks, which have a significant impact on successful data retrieval from meters and the usability of a wide range of functionalities.
Concentrator or gateway?
Meter networks often utilize PLC (power line communication) or radio communication, so communication could be unreliable. Between the concentrator/gateway and the server a GPRS/2G/3G/4G, PLC or LAN connection is used. The first two links have relatively poor reliability and higher latency.
In a gateway, the packet loss probability is the sum of both network’s probability; latency is the sum of both latencies. In the case of concentrators, packet loss probability is equal to the larger probability. The impact of latency on the network could be greatly eliminated by merging data into larger units.
This has been proven in a pilot project in the Netherlands, where G3 was used for PLC communication and GPRS for connection to the server, but instead of concentrators, gateways were used. Reading the profile data from one meter to the server took on average 59s, which is many times slower than when using the concentrator.
It is important to consider the distribution of computing power between devices and saving of data flow. The distribution of certain tasks from the server to the concentrator can save computing power of the server and the amount of data transferred between the concentrator and server with minimal additional costs for the concentrator.
However, in cases where the communication channel is fast enough or one of the communication channels is very reliable e.g.: 485 or LAN, and distribution of computing power is not required, a gateway can be used successfully.
The unification of communication interfaces and protocols
To create a meter network, there are a number of interfaces: PRIME, G3, W-MBUS, RS485, GPRS, etc. which can use a wide range of protocols: DLMS, OSGP etc. Moreover, devices from different manufacturers using the same interface and protocol are not always compatible.
Data concentrators are most suited to the unification of these differences. Modern data concentrators should allow communication through all interfaces and protocols used in meter networks and create a unified communications interface to the server. Thus, the rest of the infrastructure situated behind the concentrator is shielded from various implementations of meter networks.
Adding support for new communication interfaces or protocol specifications for a particular manufacturer’s devices should be easy for a modern data concentrator, regardless if the device is an electricity meter, a different energy meter or a specific device on the smart grid.
Data reading and processing
The concentrator should support meter with arbitrary number of profile types with arbitrary periods and arbitrary registers. It should be possible to change data reading configuration for any meter that supports it.
If the meter does no profiling, the concentrator should emulate this behavior, so on the server side, meter’s normally do profiling, although the profiling period cannot be guaranteed.
Another important consideration is the processing of the read data. The option of sending data to the server or storing it in the concentrator is only basic functionality. The concentrator should offer analysis of data where only the results could be sent to the server. Based on the analysis, the concentrator may do some tasks itself, such as correction of TOU tables.
Support for multiple servers
Conventional concentrators often communicate with a single server only. But energy companies have a few completely different systems, which could be directly connected to the concentrator. For example, billing systems, management systems, monitoring systems and so on.
Further, the support of multiple servers could be useful in the case of a multi utility meters support, where information about electricity consumption goes to one company, information about gas consumption to other, etc.
Of utmost importance, is server authentication and authorization of each transaction, determined by which devices the transactions will be sent to.
Events
The system for reporting events from each device should be uniform. Modern concentrators should allow advanced filtering of events according to their parameters. The rules set ‘event send priority’ for example via SMS, by default, keep only in concentrator or a drop, or perform any other action.
Unifying and filtering considerably saves the transmission channel and the computing power required for event processing on the server.
Commands and parameterization
Again, it is very important to have a unified approach to the parameterization of all devices. The most relevant parameterization models are SNMP, which is used in TCP-IP networks and is primarily intended for routers, gateways, etc. and therefore is very well suited for the concentrator and COSEM model, which is used for energy meters.
Part of the concentrator should be a database with information about support parameters in devices. This information should be provided to third parties in machine-readable form.
Some parameters are related to one device, but stored on another device. For example, the higher communication priority of a particular meter may be stored in the concentrator. Ideally, the user does not notice this and it appears as if it was set in the terminal device, even when a device is moved under another concentrator.
There are modules for 485 and PLC communication with schedulers and separate task in threads for maximum utilization of CPU and communication channel. There is TCP-IP module for communication with billing and management application. There is also a management module for diagnostics and configuration of DC. Data between modules are shared by database. Asynchronous events between modules are sent by d-bus.
The advantage could be if it is possible to set a parameter value that is valid only at a certain time interval, after which the parameter will return to the previous value. Another advantage is the ability to set proper parameter values with respect to the order in which requests originate and not in the order in which they arrived at the concentrator.
Commands should have the ability to set the timeout with respect to the number of attempts or execution time. Of course there should also be queue management commands.
Prioritization and communication management
Most transmission channels in a smart grid have a low throughput with a high error rate, so a concentrator’s communication control is crucial and can significantly increase the amount of useful data received and the reliability of the network management.
An example might be the ability to predict the amount of data in the meter, the communication success ratio at the intended time point, the importance of data in the meter with respect to subsequent processing etc.
On the basis of these predictions, the concentrator can decide which data from which meter to read. Network management could be prioritized using the modified LLQ scheduler, one of the most effective schedulers for TCP-IP.
Security
Safety can be divided into authentication, authorization and encryption. Concentrator and server authentication and encryption can be obtained using a standard SSL/TLS protocol, or using a VPN.
Authorization must be implemented manually with regard to the possibility of existence of multiple servers and with regard to local diagnosis and the wide range of privileges for techniques.
Authentication of service technicians can be through a user name and password or a security token. Security on the meter network depends on the meter’s abilities. The concentrator should support most standard cryptographic algorithms for possible future support.
Communication with server
Contradictory communication requirements are often found between concentrator and server. One requirement is a convenient and standardized protocol, mostly based on web services.
On the other hand, there is a requirement to optimize the transmitted data, not only with regard to the low speed of GPRS, but also because of the possibility to using PLC for at least part of the route. Because the protocols based on web services are in XML form, it is not easy to satisfy both requirements.
The solution may be to use a server-side application that converts an optimized binary protocol to a web services-based protocol on the server side. This solution preserves the simplicity of connecting third-party applications to the concentrator and gives maximum optimization of transferred data.
The big advantage is if the concentrator can offer communication modules for mobile Internet, Ethernet, Wi-Fi or other interfaces. External solutions are always more expensive and may not be 100% compatible.
Management, diagnostics and configuration
Quality diagnostic software solves problematic situations in the network and increases the data reading success ratio and reliability of the entire network. Configuration software allows a behavior change in the system to operate according to specific customer requirements.
Such software should be designed to be user-friendly, so that customers are able to use it themselves without depending on the Supply Company. Likewise, it should focus on security and user access rights.
Conclusion
The aim of this article was to highlight the fact that a data concentrator is not a gateway with simple functionality, but that it can have a major impact on throughput of communication, collection of relevant data, network management and security.
For this reason, it is important to pay more attention to the choice of this device. The choice of data concentrator impacts on the overall functionality of the smart grid as does the choice of electricity meter.