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.

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.

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

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

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.

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.

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.