As mentioned above, a wide variety of protocols, interfaces, and proprietary systems from different manufacturers are installed in electrical systems. Hence, the standardisation of these components is required. Furthermore, there are some communications requirements between electrical equipment and the PSCC, such as high security and suitable response time. These requirements, which enable operation and monitoring applications running in smart grids, are addressed in the next subsection.
3.2.2. Integration Middleware
The proposed middleware shows a novel and different approach for the concentrator core which was developed in previous research [42
]. However, as mentioned above, old or small power substations do not have an RTU, thus impeding the installation of the concentrator core middleware [42
]. Consequently, the middleware proposed in this study is intended to run on the sink node and it presents different characteristics related to the previous middleware, such as integration in the outstation environment; wireless communication; possibility of long range communication using GPRS or GSM technologies in the sink node; communication of legacy equipment using the IEC 61850, DNP3 and Modbus protocols; focus on smart metering; and compliance with the response time requirements of the IEC 61850 standard. As shown in Figure 1
, the sink node is located in the power substation, and it has an Ethernet wired connection with the PSCC using transmission control protocol (TCP)/IP.
shows that the proposed middleware consists of Python modules that run at the converter and WSN interface layers. The functionality of these middleware modules are detailed as follows.
Master.py: This module commands the others and contains a Python class called “Management”, which has a method for initialising modules “protocol.py”, “smartgrid.py”, and “interface.py”. Other methods include “scannodes()”, “pingnodes()”, and “announce()”. Method “scannodes()” sends a broadcast message at different instants to discover new nodes in its coverage area; “pingnodes()” sends a message to each node in the routing and control table for checking the node status on the network, and it removes from the table the non-responding nodes; and, finally, “announce()”, which is called after “scannodes()”, searches for new nodes and tries to initialise node data, and it creates a new alias for the network interface, thus assigning a unique virtual IP address to a discovered sensor node. The IP address, ID, and basic information of the node are stored in the routing and control table. These methods correspond to the automatic configuration which allows a sensor to be seamlessly included in the network. Moreover, this automatic configuration might simplify scalability, which is out of the scope of this study. In addition, module “Master.py” contains a method called “request()” which starts any request on the WSN and aims to guarantee the security requirements for WSN communication, as detailed in Section 3.3.1
Interface.py: This is another essential module in the middleware and contains a class called “nodes” with methods “request_lock()”, “request_release()”, “del_NODE()”, and “add_NODE()”. Methods “request_lock()” and “request_release()” operate as locks and prioritise the requests from the SCADA application to send data through the sensor network. Thus, these methods block any command sent from Web application, provided that the SCADA application is transmitting. In fact, for a smart-grid application, SCADA commands and requests must have top priority because it performs real-time and autonomous monitoring from the power substation. Still, the proposed middleware also allows requests to sensor nodes from a Web application, without the use of standard protocols for smart grids. Method “add_NODE()” is invoked by the above-mentioned method “announce()”, whereas method “del_NODE()” performs the reverse operation of “add_NODE()”, i.e., it removes the sensor node information from the routing and control table.
Protocol.py: This module basically specifies the WSN communication protocol. It contains the following classes: “crypt”, “data”, and “comm”. Class “crypt” performs data encryption and comprises methods “encrypt()”, “decrypt()”, “crypt()”, “setHASH()”, “getHASH()”, and “getNEXThash()”. Clearly, these methods allow encrypting and decrypting the data transmitted through the WSN, and create, configure, and modify the encryption keys. Hence, these methods are part of the security strategy for the sensor network communications. Then, class “data” basically consists of methods “encode()” and “decode()”, which convert the message format in the middleware to the request packet structure used by the WSN. Specifically, method “encode()” uses method “pack()” to construct the WSN request packet, and “decode()” uses method “unpack()” to extract information from the WSN responses. Finally, class “comm” is responsible for the communication between the Raspberry PI and the radio transceiver. It contains methods “_init_()”, “close()”, “cleanSerial()”, “send()”, and “receive()”, which set the transceiver parameters, close the serial connection, clean the serial buffer, send data, and receive data, respectively.
Smartgrid.py: This module creates a link between either the SCADA application or DTM and the sensor nodes, and contains a class called “smartpoll” that comprises methods “waitRequest()”, “sendResponse()”, and commInterface()”. Method “waitRequest()” waits for requests and receives them from the converter layer. Then, method “commInterface()” sends the request to module “Interface.py”. In addition, module “smartgrid.py” has a poll (buffer) to store the data (responses) received from the sensor nodes. These data can be used as responses for the SCADA application or DTM. Method “sendResponse()” sends responses stored in the poll to the converter layer.
ConverterLayer: The middleware is intended to receive requests from the supervisory control and data acquisition (SCADA) software and respond them with the values that are stored in the buffer area created by the servers of smart grid protocols. These servers represent the converter modules in the middleware converter layer. Thus, input signals can be represented by reading commands sent by the SCADA software, and output signals are the values returned as responses to these requests.
To receive requests from the TCP/IP layer, the modules in the converter layer create new servers on the ports related to protocols DNP3, IEC 61850, and Modbus. For instance, if the SCADA application performs a request using the Modbus protocol, the module for “Modbus frame/sink frame conversion” creates a new server at port 502 to receive the corresponding commands. Hence, the TCP port that receives the request determines the corresponding server for communication.
Module “DNP3conv.py” (DNP3 frame/sink frame converter) contains class “DNP3Server” with four methods: “startServer()”, “linkLayer()”, “transportLayer()”, and “AppLayer()”. Method “startServer()” instantiates the server and receives the request parameters from the SCADA application using the DNP3 protocol; “linkLayer()” extracts the fields from the DNP3 frame header and then reassembles the frame information to compose fragments; “transportLayer()” gathers and formats the fragments to compose the corresponding message. Method “AppLayer()” maps both the static data and point indices of the request into the electrical parameters recognised by the middleware and the sensor node IDs, respectively.
Likewise, module “MODBUSconv.py’ (Modbus frame/sink frame converter) contains five methods: “init()”, “setValues()”, “StartTcpServer()”, “getALLdata()”, and “getSINGLEdata()”. These methods perform several tasks, e.g., instantiate the server and receive the request parameters, extract the fields from the header of the Modbus application protocol, convert slave addresses into sensor node IDs, convert function code into request parameters, and construct the corresponding Modbus TCP messages.
Finally, module “IECconv.py” (manufacturing message specification (MMS) frame/sink frame converter) contains some classes, with the most important being “IedServer”, which has methods “IedServer_create()”, “IedServer_start()”, “IedServer_stop()”, and “IedServer_destroy()”, among others. These methods allow creating an IEC 61850 server application and manage both the MMS protocol stack and IEC 61850 data model. Moreover, they initialise the protocol stack, listen for client connections, provide process values to the MMS server, react to client events, stop the MMS server, and free all the resources allocated by the IedServer instance. The methods from class “IedServer” to provide process values (i.e. handling process values from a client application to the MMS server) include “IedServer_lockDataModel()”, “IedServer_updateAttributeValue()”, and ’IedServer_unlockDataModel()”.
Given that the converter layer of the proposed middleware must receive messages that comply with standard protocols for smart grids and translate them into a format recognised by the WSN, we proposed a memory mapping to facilitate this translation in previous research [62
]. This mapping is based on an address relationship in the memory area, which we called the smart-grid poll, and further details can be found in [62
]. Other smart-grid protocols can be easily adapted to the middleware. For instance, inter-control centre communications protocol (ICCP) communicates using the TCP/IP protocol, and uses the client/server model. This paradigm is used in the converter layer by the smart-grid protocol servers. Thus, the user can adapt an ICCP server to the converter layer so that an ICCP client can request information from the WSN. Moreover, the ICCP protocol communicates using MMS message protocol, which is already mapped by the middleware, and it is generally available as a native protocol embedded in some SCADA hosts.