Two of our favorite things have only gone and teamed up this week, open source and standards, with the Linux Foundation’s LF Energy project announcing the availability of Grid eXchange Fabric (GXF) as an open standard to be used in smart grid deployments. However, the project’s biggest challenge remains convincing the rest of the utility industry to come to the table, but open standards should make this task a lot easier.
The foundation for GXF came from Alliander, a Dutch distribution system operator (DSO) that was behind the Open Smart Grid Platform (OSGP). Alliander went on to join LF Energy as a premier member, and contributed the OSGP stack to the project, and now the Linux Foundation initiative hopes that GXF will become the standard by which grids begin becoming both smart and interoperable.
“We have the tools necessary to make our power grid more efficient and better for our environment, but we’re running into a system integration problem at a global scale” said LF Energy Executive Director Shuli Goodman. “Grid operators need a way to cut through the noise of different data access protocols to pull insights from smart devices directly. With the addition of GXF, the Grid eXchange Fabric, we will leverage the shared expertise of our community to tackle this problem head on.”
This is LF Energy’s seventh project, although you wouldn’t know it, given how quiet it has been. Renewable Energy Magazine does a great job outlining these, as: OperatorFabric, a smart assistant for system operators; PowerSyBl, a high-performance computing framework for grid simulation and planning; RIAPS, a distributed energy developer platform for smart grid apps like microgrids and wind generation; OpenEEMeter, a consistent treatment of energy meter data for demand flexibility; Energy Market Methods Consortium (EM2) standards that support demand-side flexibility markets; and OEDI, a data platform to enable advanced analytics and research innovation.
Announced back in July 2018, and launching properly in May 2019, LF Energy seems to have been quietly plugging away at this problem. Its membership consists of Alliander and French transmission system operator (TSO) RTE as its premier members. The next tier down, general members, consists of CloudBees, Elering, IBM, OSIsoft, Recurve, Root9B, Unicorn, and Wind River. Prominent associate members include Fiware, NREL, and the Energy Coalition.
Alliander is currently using GXF to manage connected street lights in the Netherlands (15,000 of them, if we can safely work backwards from the marketing materials), and the announcement makes mention of other grid operators using GXF to manage microgrids and their metering ‘head-end systems,’ as a way to collect data and then ingest it for analytics applications.
“GXF was originally created for our customers to manage some of their more time- and cost-consuming tasks” added Arjan Stam, Director of Systems Operations at Alliander, and member of LF Energy’s Governing Board. “But one of our wishes was always to create an independent foundation to facilitate the project and provide it with a neutral home. With LF Energy, we’ve found that home, and we’re looking forward to working with the community there to take GXF to new heights.”
Available on Github (owned by Microsoft now, don’t forget), you can poke around the GXF standard and laugh at the misuse of “formaly known” in the heading. Notably, the graphics here have yet to be updated too, and even though it has been quite low-key, this announcement still seems weirdly rushed. The current roadmap is to fully transfer assets and governance from the OSGP Alliance to LF Energy, update documentation, and then implement a Contributor License Agreement (CLA – not without controversy in open source circles).
The main use cases for GXF, as outlined by LF Energy, are microgrids, smart metering, public lighting, and distribution automation. The sales pitch is that it provides scalability, high availability, and high security, in a generic design that prevents vendor lock-in. For those that want a deeper dive, the old documentation is still available on the OGSP website here.
At the protocol layer, GXF currently supports Open Street Light Protocol (OSLP), DLMS/COSEM (IEC 62056), and IEC 61850. On the roadmap were OpenADR, IEC 60870-5-104, OPC Unified Architecture / IEC 62541, and Modbus TCP. It seems safe to presume those are still in the pipeline. If you really want to waste a couple of hours, you can try and plot the overlaps between this selection, but it is safe to say that this is quite a comprehensive list.
In terms of usage, the OGSP envisioned a user or operator creating a web application to monitor and control devices, which would then be connected to the OGSP platform and divided into the different functional domains required – that is, lighting, metering, distribution, and so on. This platform would then handle third-party application requests, in a secure fashion, and would be able to translate between different businesses and applications by way of those open protocols. The platform would be IP-native, meaning it could be integrated with other platforms and devices.
For the use cases, the OGSP envisioned street light control, electrical transportation, smart metering, road traffic control (via signs and lights), flexible load management (to accommodate DERs like solar and wind), and power quality management. Those are all extremely likely to carry forward into the LF Energy project, under the new GXF banner. OGSP is dead, long live GXF.