From GridLAB-D Wiki
Jump to: navigation, search

REQUIREMENT  PROPOSED FOR 3.1 

Workinprogress.jpgEDITING IN PROGRESSWorkinprogress.jpg

Application Concept

The connection module will implement a common set of data exchange and co-simulation links for both clients and servers. Various underlying transport protocols will be supported and various data format protocols will be implemented by the classes of objects. A common security model will be shared by all the interfaces ensuring that all external interaction are managed consistently across all the various connection types.

Use Case

USE CASE

HIL connection using JSON over UDP

The connection module will be used to implement a Hardware-in-the-Loop system which ties a system-level simulation running in GridLAB-D with hardware solar PV inverters at an offsite location. GridLAB-D will operate in client mode, with an Opal RT machine acting as the server and interfacing with the hardware. The connection will use the JSON link protocol and information will be sent via UDP at 1-second intervals. The connection will begin with an exchange of init packets, then an exchange of schema packets, and then a synchronization message transmitted at the refresh interval. It will conclude with a termination packet. See JSON link protocol for more details. A simulation will begin in simulation time [aside: we need a better word for not-realtime] in order to initialize and diversify a set of house models. After a set length of simulation time, it will transition to realtime and initiate the connection. The connection will run in realtime until terminated.

Full model dump via xml

To be filled out based on Ausgrid examples.

R

Backwards compatibility shall be preserved. No changes to connection module will affect current uses of link or server mode functionality.

R

The connection mode shall act as either server or client.

R

Connection in server mode shall have multi-platform support.

R
Connection shall be able to act as a Windows server.
R
Connection shall be able to act as a Linux server.
R
Connection shall be able to act as an OS-X server.

R

More specific requirement about acting as a client?

R

Connection transport shall be accomplished by one of two methods.

R

Connection transport via UDP shall be supported.

R

Connection transport via TCP shall be supported.

R

Multiple data exchange protocols shall be supported.

R

The data exchange protocol shall determine the name of the class.

R

GridLAB-D native language shall be supported.

R

JSON protocol shall be supported.

R

xml protocol shall be supported.

R

MATLAB protocol shall be supported.

R

The security control property shall control the security configuration for classes implemented by the module.

R

NONE shall apply no security controls.

R

LOW shall honor all incoming data and action requests unless they are specifically forbidden by a link or action statement.

R

NORMAL shall honor all incoming read requests unless they are specifically forbidden by a link or action statment but will not permit write requests unless they are specifically forbidden by a link or action statement.

R

HIGH shall not honor any data or action requests unless they are specifically permitted by a link or action statement.

R

EXTREME shall not honor any requests, will log requests, and will not return a response to the requestor.

R

PARANOID shall not honor any requests and shall lock out the requestor for a duration controlled by the lockout module global variable.

R

Sufficiently inclusive yet specific clock-related heading.

R

Connection class will be Delta mode compatible.

R

Realtime shall become more flexible.

R

Drift between simulation clock and wall clock to pre-set limit shall be allowed.

R
Realtime global variable shall be writeable during simulation.
R
Realtime global variable shall be writeable by connection.
R
Realtime global variable shall be writeable by player and schedule.
R
Realtime global variable shall be writeable by runtime code.
R
Simulation in realtime mode shall be possible with a user-specified clock, in which the simulation pace is tied to system clock increments but not to absolute system clock time.

Version

The connection module is proposed for Hatwai (Version 3.1). Its development is tracked under Ticket 797.

See also