Grid eXchange Fabric (GXF) is a software platform that enables hardware monitoring and control in the public space. GXF provides several functions out of the box and provides scalability & high availability, high security, a generic design, and no vendor lock-in. GXF is currently deployed in several public use cases, including microgrids, smart metering, public lighting, and distribution automation.

GXF is open, independent, and driven by its community, developed using open source best practices and designed to use open standards. This enables third parties to develop new and innovative solutions. The trade-off is flexibility and freedom. Unlike closed proprietary software, open source software can be altered and extended by any developer familiar with the source code. This grants organizations freedom from “vendor lock-in,” assures long-term viability, and creates industry opportunities for support, consulting, and training.

Overview

GitHub

Wiki

Mailing List

Metrics Dashboard

Roadmap

Details

The architecture and implementation of GXF ensure scalability and availability. GXF can connect to a nearly endless number of devices, with no limit on the number of applications that control those devices.

GXF can be deployed to multiple servers or distributed over multiple data centers in an active-active setup so that even if one data center fails, no data or functionality is lost. In a cloud-hosted setup, it is possible to use auto scaling to automatically add or remove servers on any of the platform layers to scale the platform to the current load and use. Servers can automatically be scaled up and down when necessary, thereby reducing hardware costs. This setup can also be used to minimize the costs during the phased rollout of smart devices.

Architecture

GXF acts as a translating layer between applications and hardware. GXF itself has four different layers. Each layer has its own function and is adjustable to specific needs. To optimize security between the layers, a security layer is installed.

Read more about the principles of each layer below. More in-depth technical information can be found on the GXF Architecture page on the wiki, and in the documentation.

Application Integration Layer

In this layer, the web services are exposed to the outside world. Applications can connect to the application integration layer and use the required functionality of GXF. The application integration layer is divided into functional domains. When there is a need for an additional functional domain it will be added.

This separation offers authorization per functional domain. Each of the web service components sends a queue message to the corresponding domain component.

A separate web service is implemented for each functional domain. All soap operations have a request object parameter and return a response to the object. For synchronized web services, the result is immediately included in the response.

For asynchronous web services the response contains a correlation id. This correlation id is to be used by the requester to receive the actual result from the platform. We have IEC CIM based services and ALIS (public lightning) services on the roadmap.

Domain Layer

With domain-driven design (ddd) we see a common language and collaboration between technical –and domain experts. As a result, a model for a specific functional domain is created.
In the domain logic block the business logic of the functional domain can be found. This is where the translation of a functional named command will be translated into a generic intermediate format.

The domains can re-use all the functions within the core and protocols. The platform is stateless (the platform uses queues to process messages) and can easily scale down, or scale up to large volumes.

Core Component Layer

The GXF core component receives queue messages from domain components. These messages from domain components are forwarded to a protocol adapter. The GXF core component also offers logic for a protocol adapter to send the response of a smart device back to a domain project.

For each functional domain, business logic is implemented using a separate domain component. Common functionality like authorization should be abstracted to a shared component. Domain components receive queue messages from web service components and send queue messages to the GXF core component.

The following generic functions can be found in the core of GXF:

  • Device management
  • Firmware management
  • Time synchronization
  • Workflow engine
  • Device installation services
  • Scheduler
  • Device Status Monitoring
  • Routing of device command to appropriate device protocol

Protocols Layer

The different protocol adapters are found in this layer. Here the generic intermediate format of a command for a specific device will be translated into the protocol message the device understands. This message will be sent to the device. For communication failures, there is a retry mechanism. The listeners for messages initiated by a device are implemented here.

Currently, the following protocols are available:

  • Open street light protocol (OSLP)
  • DLMS/COSEM
  • IEC 61850
  • MQTT
  • IEC 60870-5-104

The following protocols are on our roadmap:

  • OpenADR
  • OPC UA / IEC 62541
  • Modbus TCP

Features

Secure By Design

GXF uses two-sided TLS for web applications to ensure that both parties trust each other’s identity. All communication is encrypted. User organizations are responsible for identity management and access on their web applications. For example; applications are provided with a login page, passwords are being coded when saved, and every message towards the platform contains the organization id and is checked with the TLS certificate.

Through the use of a unique platform key, devices authenticate messages from the platform in order to ensure that devices only receive tasks from a genuine platform. To prevent replay attacks, every key message is assigned a serial number. Both the platform and the devices have a private and public key.

The authorization of platform functionality is role-based. Roles are defined by functionality for both the platform and the device. Each role has one or more functions, and each device’s rights can be set per device.

All devices are delivered with unique keys, enabling the platform to identify genuine devices. Devices identify their own unique key. The traffic between the platform and devices is signed by these unique keys to ensure the integrity of the message and that the source is correct.

Generic Design & Functions

The core layer holds the generic functionality for device management, firmware management, time synchronization, device installation services, message routing to the correct device protocol, and other functions. These functions are applicable to all devices. The platform is designed for multiple applications to be added. The protocols, generic functions within the core, and domains can be re-used for every new use case, application, and hardware configuration. Thus, investments in development can be spread over multiple business cases.

GXF incorporates generic functions that can be used for several devices in the public space. These include firmware updates, hardware updates, time synchronization, and workflow engines.

Domain Specific Functions

GXF has several functional domains with domain-specific functions, including status updates, remote controls, automated events, and device filtering. For detailed information on these domains, see the documentation on Domains.

GXF Project Blog

May 28, 2020 in GXF

New GXF webinar online

Robert Tusveld was invited by the LFenergy to talk about GXF (former Open Smart Grid Platform) in a webinar. Enjoy! https://www.youtube.com/watch?v=zH9CdMH0tUM
Read More
February 7, 2020 in GXF

Open Smart Grid Platform has a new name: GXF

The Linux foundation accounted the a new name for the Open Smart Grid Platform: Grid eXchange Fabric (GXF). More information can be found on their announcement. The name change is are result…
Read More