The Grid eXchange Fabric platform acts as a translating layer between applications and hardware.
GXF 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 can be found in the documentation.
Application Integration Layer
In this layer, 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 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 GXF roadmap.
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 an generic intermediate format.
All the functions within the core, and protocols can be re-used by the domains. The platform is stateless (the platform uses queues to process messages) and can easily scale up to large volumes, or scale down when necessary.
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 a 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 core component.
In the core component of GXF, the following generic functions can be found:
- Device management
- Firmware management
- Time synchronization
- Workflow engine
- Device installation services
- Device Status Monitoring
- Routing of device command to appropriate device protocol
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)
The following protocols are on our roadmap:
- IEC 60870-5-104
- OPC UA / IEC 62541
- Modbus TCP