Guests: Akli Rahmoun (LinkedIn)
Benoît Jeanson (LinkedIn)
Company: RTE (Twitter)
Organization: LF Energy (Twitter)

FledgePOWER is a relatively new project at LF Energy that’s created to build a bridge between legacy and modern power systems through a multi-protocol translation gateway. It’s based on the industrial IoT LF Edge project called Fledge. To learn more about the project, we invited two guests from RTE — Akli Rahmoun, Technical Leader of the FledgePOWER project at LF Energy and Benoît Jeanson, R&D Project Manager at RTE.

Enjoy the show in the video above!

Topics covered in this show:

• What’s the genesis of the project? What problem were you trying to solve that led to the creation of this project?
• Rahmoun explains what exactly is the multi-protocol translation and what role it plays within power systems.
• What was the need for protocol translation? Rahmoun also mentioned legacy protocols so what was the need for modern protocols?
• We then talked about the governance of the project within LF Energy.
• The FledePOWER project is based on Fledge so there are multiple communities that have a vested interest in the project. So what kind of community is there around the FledgePOWER project?
• What kind of interest is there in the project by the international communities, beyond the US and Europe.
• What are the core components of the project?
• What is the current focus of the project?
• What exactly are these protocols and how flexible are they so they can work with other systems?
• What’s the difference between Grid eXchange Fabric and FledgePOWER?

[expander_maker]

Swapnil Bhartiya: Hi. This is your host Swapnil Bhartiya, and welcome to another episode of LF Energy products. And today we have two guests from RTE; Akli Rahmoun, Product Manager at RTE and Technical Leader of the FledgePOWER project at LF Energy and Benoît Jeanson, R&D Project Manager at RTE. Akli, Benoit, it’s great to have you on the show.

Benoit Jeanson: Hi. How are you doing?

Akli Rahmoun: Hi Swap. Thanks for having us.

Swapnil Bhartiya: First of all, I want to understand the origin of this project, the genesis, and also the name. Please tell me what’s this project all about?

Akli Rahmoun: Actually, we have started this project less than one year, so this is really a very young project and we were looking at RTE for a solution to solve one of our problem, which is actually making old systems and legacy systems communicate with new systems. We have a bunch of systems that needs to be communicating, and for this we use something which is called protocol translation gateway. And we were actually looking for a new generation of software that can help us solve this problem and to be able to replace the legacy gateways that are already deployed.

This is really the starting point, and we have looked for different products, open source or proprietary and at the end, we have chosen a platform which is called Fledge, which is an LF Edge open source project which has really very interesting features to build FledgePOWER on top of it. Fledge is the foundation of the FledgePOWER project and in some kind of way, FledgePOWER is an extension of Fledge that is narrowed to solve a very specific problem, which is the telecontrol protocols translation.

Swapnil Bhartiya: Can you just go a bit deeper and explain what exactly is multi-protocol translation? What role do they play within power systems?

Akli Rahmoun: If you think to a protocol as a human language, actually, a protocol is the way systems talk to each other. So each component of the system uses the protocol to communicate with each other, and in the case of multiple systems and telecontrol networks, which are actually composed of very different systems, we need to use several protocols. We need to make all the systems which talk their own language, be able to communicate with each other. And this is where we put something in the middle, which is called the protocol translation gateway, to be able to do this job of translating information, which is actually the same information we collect. For example, we can collect census data from the field, from the substations. This information will be described in some kind of way in the protocol and will be described in another way in another protocol. The job of the gateway of the protocol translation gateway is to be able to make this translation from one language to another, or to search in another way from one protocol to another.

Swapnil Bhartiya: Can you also talk a bit about… Because when I think of protocol, it’s more like when you have different systems, sorry not only different platforms, that’s when you need a protocol so they can talk to each other. I want to understand why you need a protocol translation? Is it because you’re trying to talk to a different, not only systems, because if you look at energy sector, consumers are becoming producers. We have solar panels, solar walls installed. We also have electric vehicles, which have batteries also. Talk about the need of this protocol, number one and then you also said that you had legacy ones, so why you need the modern ones?

Akli Rahmoun: I think that the answer is in your question. We have a lot of new devices. Yes. You quoted the one, which is the electrical vehicles, which come with their own language, which is a protocol. And we have to integrate this electrical vehicles in our power system. And we need to make our SCADA, which is actually our central system to control all the devices to be able to talk to them. And our central systems have their own language, have their own protocol, and they cannot discuss directly or communicate directly with, for example, the electrical vehicle or the batteries or whatever you want to directly with the systems. That’s where you need a piece of software to make the translation. This is one use case, but you can think to other use cases where you would need this kind of protocol translation and this is where FledgePOWER actually would be helpful to solve this problem.

Swapnil Bhartiya: Can you talk about the governance of this project because Linux Foundation, they have very good structure, but every projects they can choose their own governance model. Talk about the governance model of FledgePOWER within LF Energy.

Akli Rahmoun: The governance of the FledgePOWER is a bit actually specific because we are very tied and with the Fledge project as I said earlier, FledgePOWER is in some kind of way an extension of Fledge narrowed and focused on solving a very specific problem, but our foundation is Fledge. We have a close collaboration and cooperation with the Fledge community to discuss all the technical matters that are actually evolving where we are both involved. I’m member of the Fledge TSC and the members of the Fledge TSC are also members of the FledgePOWER TSC, and we discuss very frequently to have a structure and harmonized approach to solving the problems we could face.

Swapnil Bhartiya: You’ve mentioned there are communities, there’s Fledge community and there’s FledgePOWER community, but if I ask you what kind of community is it? Who are the members? Whether they’re companies or individual developers, so talk about the community.

Akli Rahmoun: Thank you Swap for asking this question. Today our community is mainly composed by RTE, Dianomic and OSIsoft also who were at the beginning of the project. We are a very young project, but we are very motivated and all these people are showing great interest and great involvement in the development of this project. We have also talked to other TSOs who are very interested in joining us like our neighbors from Germany or from Belgium who look at our project in… They are very interested in joining us as a partners at the beginning and maybe in the future will be contributors to the project.

Swapnil Bhartiya: If you look at RTE and other company that you mentioned some of them are European. Is there any interest from other countries, other regions of the world also in the project?

Akli Rahmoun: Yeah. And there’s also interest from other parts of the world like Singapore. We have some university from Singapore, which we had contact with. We had a very interesting talk about their use case on how they can use FledgePOWER to solve their use case. We have also a discussion with people from University of Aachen, from the SOGNO project, I think that you had them on interview. We are having a discussion with them to see how we can use FledgePOWER to integrate with SOGNO. And I think that there’s also people from TEPCO from Japan, who are also interested in FledgePOWER. As you can see, the community is very international community and there’s a lot of people from different organization that are interested to the project.

Swapnil Bhartiya: Of course, as you mentioned that Fledge is the foundation of this project. If you can talk about what are the core components of this project and then after that, we’ll talk about the release, cadence and other stuff, but let’s start with the technical aspect, the components of this project.

Akli Rahmoun: The main component of the project… FledgePOWER is built on top of Fledge. The main architecture of FledgePOWER is the Fledge architecture. The thing that is very interesting with Fledge, it’s a very lightweight software, which is meant to be deployed at the edge on very constraint resources. And this is what we want to do in our use case, for example, for RTE where we need to deploy protocol translation gateways in the substations. So in the substations, you need to be able to deploy very small computers to run softwares. This is one of the main feature of Fledge that is very interesting.

The other feature that is very interesting is the plugins feature that allow actually to add new protocols in a very, very easy way. You don’t need actually to recall from scratch or you can inherit a lot of the code that is built, and then have been been developed in Fledge, and you not only need to focus on your very specific protocol when you want to add a new protocol to the system, to the gateway. This is the two main features that makes the project and the product very flexible and extensible.

Benoit Jeanson: I just like to add. Of course, FledgePOWER is based on Fledge and many of the future that we will inherit are coming from Fledge. And the resource that we are developing today is directly delivered in the Fledge repository, but the specifications… No, not the specifications. What will differ from FledgePOWER is also all the tooling that is around Fledge to address a specific use case. And especially the ability to configure FledgePOWER as another device that we have in the substation and we will make the connection with another open source project that is compassed to enable the configuration of FledgePOWER with this particular ecosystem.

And we will also need to have a component such as the simulators to be able to simulate various protocols, just to test the protocol gateway, and to be able to test also various scenarios, big scenarios, with a lot of data to be handled at once, and to ensure that FledgePOWER be able to cope with a huge amount of data in a very little time, because FledgePOWER will become a very critical software in our telecontrol infrastructure.

Swapnil Bhartiya: Excellent point. I really love it. Now, one more thing I want to ask you is that… It’s an ongoing project. There are of course, challenges that are ahead of you that you’re still trying to solve. If I ask you, what are the things that you are [inaudible 00:13:48] and, “Hey, this is the problem that we have to solve.” And that you folks are focused on.

Akli Rahmoun: Yeah, our next step actually is to be able to implement a new use case, which is an RTE use case, which is being able to deploy protocol translation gateways at the edge in the substations to be able actually to collect data from sensors. But we’re also being able actually to send telecontrols, which is actually all about telecontrols networks is being able actually to collect data, but also send controls or orders to, for example, a circuit breaker. This is our very first use case we want to be able to implement, maybe in the next year, we’ll be able to have a first version, a first release of the FledgePOWER software that can be implemented and deployed at the substation to do and to implement this use case.

Swapnil Bhartiya: Can you tell me about these protocols? And as also known protocols need to work across systems, so how flexible they are so that you have room for other protocols or integration with other systems?

Akli Rahmoun: In our roadmap actually, we have defined some protocols that needs to be implemented at the very beginning of the project, because it will be useful for various use cases. The first one is IEC 104 as I mentioned earlier, we need it for substation deployment. This will be the first protocol. Then we will be adding other protocols very quickly like IEC TASE.2, OPC UA, and IEC 61850.

Swapnil Bhartiya: But on the beauties of Linux Foundation or Linux Foundation Energy, is that it’s a home for open source product and sometimes people might see that there are two projects which might be overlapping. Sometimes they do overlap, sometime it’s just misunderstanding. There are certain projects, like GXF is another project which might lead that, “Hey, you know what? These two projects are trying to solve the same problem.” What is the difference between the grid exchange fabric and FledgePOWER?

Akli Rahmoun: Thanks for asking this question, actually. To answer in few words, the main difference between FledgePOWER and GXF is that GXF has been designed and build to be run at the central level in the cloud or on data center and to control thousands and hundreds of thousands of devices. This is the main focus and the problem that GXF tries to solve, whereas actually FledgePOWER we’re very focused on something which is smaller than what GXF tries to solve. We are really actually focused on the protocol translation. The heart of FledgePOWER is about protocol translation and we also are actually meant to run at the edge, where GXF is more meant to run on the central level, like on the cloud or in private data center. I hope that this helps clarify the difference and the overlaps that can exist between GXF and FledgePOWER.

Benoit Jeanson: That’s a question that we are asked many time, because actually there are similarities in terms of feature between GXF and FledgePOWER. The thing in that GXF is meant to control millions of device, to have automation at the centralized level for millions of device, such as the public lightning or controlling sets of hundreds of thousands of metering devices. FledgePOWER is not exactly focusing on that kind of use cases. FledgePOWER is really focusing on having the ability to have a lightweight solution to make protocols translation and this can be done at the local level. In the substation, you will have one single instance of GXF for your utility, you will have thousands of instances of FledgePOWER for the same company.

Swapnil Bhartiya: Akli, Benoit, thank you so much for taking time out today and talk about not only the FledgePOWER project, but also the whole governance and the challenge that you’re trying to solve for the larger ecosystem, which goes beyond RTE. Thanks for sharing those insights and of course, I would love to have you folks back whenever there is a new update for the project. Thank you for your time today.

Akli Rahmoun: Thank you as well.

Benoit Jeanson: Thank you very much.

[/expander_maker]