Modular Design

OpenPMU embraces a modular design, which allows for continuous upgrade of the components whilst preserving the integrity of the system.

This linked IEEE publication provides full details on the modularisation of OpenPMU. This web page aims to provide a brief overview of the salient points.

Overview

The three modules in the system are:

Figure 1 - The OpenPMU Modular System

Each module operates independently of the others, with the orange arrows in Fig. 1 indicating the flow of information.

Inter-module communication is achieved using UDP/IP as the transport mechanism, with the data presented in XML. This is intended for operation either between hardware modules on the same LAN, or software modules running on the same host (using the loopback address). Wide area communication is achieved separately.

The use of XML means that the data is human readable, as well as machine readable. The trade-off is an increased data rate, but this is of little concern on a LAN environment. UDP/IP is used to keep the system connectionless, thus no issues arise with handshaking. This means modules can be started, stopped and swapped without the module before or after being aware of the change. This is extremely useful for development.

XML Schema Overview

Data flow between modules is presented in an XML schema, and transported by UDP. This section provides a brief overview of the schema.

The key advantages are:

- Human readable messages
- Extensibility (can add new content without breaking functionality)
- Natively supported in most environments (Python, Matlab, Labview)

Each OpenPMU datagram starts and ends with the <OpenPMU> tag. Date and time (<date>,<time>) is provided in UTC, and a frame number (<frame>) which increments by 1 each frame provides a sanity check in case of time error.

Sampled values, from the data acquisition module, are accompanied with their sampling rate <fs>, number of samples per frame <n>, and bits per samble <bits>. The number of channels presented is stated <channels>.

Each channel is individually tagged, and contains a <name> and <payload>, amongst other metadata. The payload contains the binary output of the ADC formatted in Base64. This has the advantage of using only an ASCII compatible set of characters to transfer the data, making it widely compatible with various software environments (Python, Matlab, Labview).

Example XML Datagram

Synchrophasors, from the phasor estimator, are communicated in a similar manner. Date and time are preserved, as are the channel metadata, but the payload tag is removed and phasor parameter tags are introduced. The ADC parameters are not required.

Commentary

The primary disadvantage of XML datagrams are that they are bandwidth inefficient. This is not generally an issue for the intended environment, the Local Area Network (LAN) or when local loopback is being employed within the same machine.

The required bitrate for 6 streaming waveforms is <11 Mbps. The bitrate for the equivalent synchrophasors is considerably lower.

OpenPMU may switch from XML to JSON in the future, but for now XML is required.

Always refer to current exemplar datagrams provided with our software for the most up-to-date schema. This guide is an overview of the minimum requirements.

For WAN communication, OpenPMU supports industry standard messaging formats.