Communications module

The Communications Applications Concepts is located at V3_applications_concepts.

The communication module will be based upon a simple performance model. Essentially, it will perform as a dispatching “black box”. Messages or commands are created by external objects, delivered into the network model via a network interface device, network delays are applied, and the message is delivered to the appropriate object via another network interface device. The “black box” will initially consist of a number of simplified network properties to demonstrate the anticipated delay times found within the network.

The following will be broken into three sections, each dealing with different aspects that will need to be addressed to develop the communications module. First, descriptions and requirements of the “black box” network will be provided. Second, parameters and behaviors of the network interface devices will be described. Finally, the general modifications required to existing objects for usage of the communication module will be described.

Network Object
The network object will collect all of the applicable signals desired by the overlaying system and then determine the amount of time necessary to deliver the signal to the appropriate object. Actual collection and delivery of the messages will be handled by the network interface device, and will be further described in a later section. As an initial model, the network module will only be concerned with a few parameters; these will include average network latency, bandwidth limitations, and queuing of messages during high levels of congestion. In addition to accepting and delivering messages, the network object will need to communicate to the network interface device any cases where the message was not accepted by the network due to limitations. All of the routing information contained within a standard network will not be explicitly modeled.

Network Object Inputs
Table 1: Network inputs.

Network Interface Device
The network interface device will be required to bridge the communications module with any other existing module. This is analogous to triplex meters in power flow being used to attach residential models to the power system; however, due to the constraints of the parent-child relationships, the order will need to be reversed. The network interface device will become the child of the object that is controlling it. Similar to when using the meter object, any object that interfaces with the network module will need additional logic to detect if a communication device is present. Additionally, each object that interfaces with the device will need logic designed specifically for handling the control signals that will be now sent across the communication module as opposed to directly. For example, the volt var control object will need to deliver the modified set points to the network interface device as opposed to directly to the regulator object. For communication to occur between two objects, both will be required to be attached to a network interface device.

The network interface device will either deliver messages from the object to the network or from the network to the object. It will also handle any processing delays that may be required, or when the network is in reject mode, it will be required to store and resubmit data as necessary.

Network Interface Device Inputs
Table 2: Network Interface Device inputs.

How information will be passed
Messages will be passed within the communication module as a structure. Minimally, this will contain the source, destination, size, bandwidth, delay, and data, and may be expanded later to include other information. bandwidth will be assigned by the network object and delay will define the amount of latency determined by the network object.

= MPI Network =

A 'second half' of the communication module uses MPI to exchange messages between GridLAB-D and a message handler, whether a simple MPI echo server or a fully featured network simulator. Adapting GridLAB-D to run under MPI required moderate manipulation of GridLAB-D from its basic state (using r3199 as a starting place).

The MPI connectivity required messages to be represented differently than what the network object exchanges. The work to make controller_network_interface and market_network_interface compatible with the performance network model has not been completed.

The mpi_network model uses generic messages that may affect several properties of the receiver, and may draw from several properties of the sender. The decision was made to use custom-written network interfaces for each class to connect to the mpi_network, and to modify the object to function in a 'passive' mode. The sender is unable to directly signal that interface that there is data to send; the message is written onto the receiving object before it processes information for a given iteration. Event-driven behavior was built into the objects that were interfaced, and the interfaces contain public domain knowledge on the workings of the interfaced objects, including how to write and parse messages for that object.

mpi_network Object
The mpi_network object drives the data exchange between GridLAB-D and MPI: a call is made for each object on the network to check if its interfaced object is in a state to send a message, which will then push a newly created message onto the mpi_network's outbound stack. The messages are sent to another MPI node. Any messages on the incoming stack are then popped off and directed to the specified recipient. The receiving interface interprets the payload into one of several custom message types, writing properties, making function calls, and sending a direct response, as appropriate.

mpi_network heartbeat
Every interval seconds, the mpi_network and the application on the other end of the MPI link are to exchange an int64 with the current timestamp, and to receipt the time by sending the simulation's current time. If the two applications get out of sync, GridLAB-D will halt.

Table 3: MPI Network inputs.

Table 3: MPI Network outputs.

controller_network_interface Object
The controller_network_interface is designed to interface with a market controller object, exchanging market updates and bid messages. It uses extensive knowledge of the controller's behavior to coordinate the initialization, bidding, and price signals with foreign market objects, that exist in different models.

The parent of a controller_network_interface must be defined, and that object must be a controller object in 'proxy' mode. The controller will delay its normal operation until the controller_network_interface receives a market update, which will contain the market period, price caps, and current price signals.

Table 5: Controller Network Interface inputs.