So, yes, you can hear me.
Hello, everybody.
And welcome to my talk, OpenSCD, everything, everywhere, all at once.
So my name is Tamar Schuss.
I'm a software engineer and the lead of the domain development at Sprint 1.
We are a software company in Stuttgart in the southwest Germany.
And I would like to talk about...
Hello, hello.
Yes.
Okay.
First of all, what is OpenSCD?
Just to give you context, a brief introduction to the history, how it came to be, and where
is it today.
Then what I would like to do, the goal is the talk, is that I would like to talk about
the challenges we have as a community and which approach we took and which approach
we are thinking about.
So I'm just going to talk about the technical approaches today.
So let's start.
What is OpenSCD?
It's an open substation communication designer.
We're going to get into it later, what that really means.
And it's also an IEC 61-850 tool.
I don't know if everybody knows it, but I'm going to explain in a few sentences what it
is.
It's a progressive web app.
So it's browser-based, and it's also a platform.
So we think about it as a platform rather than an app.
Okay.
So just again for a quick context, probably everybody knows for the...
Or for later, for the recording.
This is a substation, an electrical substation, and it converts high voltage to low voltage
and vice versa.
And IEDs, so intelligent electronic devices, monitor and control the substation, so everything
works as it should be.
And the...
Before I mentioned IEC 61-850 is a communication standard that describes or specifies how these
devices should communicate or how you should design a communication between these devices.
So OpenSD does something with this, and how it came to be is that at Omicron, one of our
good friend Jacob Fogelsang created a Java app first because he wanted to help with the
colleagues and his team to create multi-vendor projects because every vendor had its own
tool and they interpreted everything a bit differently about the standard.
So they try to...
Our Jacob tried to create something where you can agree on a software level, so not just
a specification but also agree on the implementation.
Later on, Christian and Dinka joined the team and they restarted the project as a progressive
web app because they saw just how hard it would have been to deploy and to just distribute
a Java app to everybody.
So they see the web platform as a nice way to distribute the software.
Then the project started to grow.
Alieander RTE joined Transpower from New Zealand and TransNet BW also from South West Germany
and we joined with them and we had to create a few plugins for them.
And now I'd like to think that we are at the scaling phase.
Just last year, a colleague from Alieander, Pascal Wilbrank and I took over the maintenance
of OpenSCD and just last week we have been accepted to LF Energy.
So we are very happy about it and we are looking for the onboarding process and get to know
all the other projects too.
So these scaling of course are the scaling problems I think everybody has.
So we have more interest in usage and more usage and more interest in the project and
we face a few challenges.
First to get back to the title, so everything.
What we see is if a tool doesn't really provide all the tooling to design substations, then
people are going to just use under ones.
And we are right back there where we were at the beginning, that the tool is differently
maybe interpreted as specification and then these designs, so these files are not going
to be as much exchangeable as we would like to have.
So what we see is that in order to be successful, we need to provide all the tooling, all the
features that the users need.
The problem with that is also that we have to provide it everywhere, otherwise a standard
couldn't really work.
It's already too bad that this high EC standard is not accessible for everybody for free,
but even if the software that uses it isn't accessible to everybody, then it's never
going to work.
So at least we are trying to change that what we can.
So we would like to really make it available for everybody.
So all at once means, as you may know, in a multi-stakeholder project where everybody
has its own deadlines, roadmaps and timelines, everybody tries to basically prioritize their
own needs over the others because it makes sense.
So this is also what we are facing with all the TSOs that everybody just has a different
need.
So our approach may be, so not every problem is solvable of course with technical solutions.
We try to do, we try everything out, but today I would like to talk about just the technical
ones because otherwise we would be here wrong.
One is Web standard, it's really important to use them.
We depend on them for the flexibility and performance and of course the long-term maintainability.
Then the plugins, we have a plugin system.
I'll get into these topics deeper in a bit.
The plugin system just helps you customize for every use case you would like.
And also the distribution, it's just one step further that you can have your own version
from the whole system.
So Web standards, how does it help us?
So as I mentioned, it's a progressive web app.
OpenSD is browser-based and what we need also is an offline usage capability because not
every engineer has internet connection at sites or they would like to browser or design
the digital substations on the go.
So this is a really big point for us.
And also that again as mentioned, installing an app, it's not really possible.
It begins the prices and TSOs because the IT just doesn't like to install apps.
So providing it in the browser, it's a nice way if you have internet connection to have
it.
Because it's a progressive web app, you have to visit it once and then you have it and
you can use it at any time.
The next one is custom elements as a web standard.
So we use it for the plugin system and for a few other things.
Why is it important for us?
Because again it's a standard and if you can compile to custom elements or web custom elements,
then we are fine, then you can create your own plugins.
That leads to technology independence because we don't really mind what you are using.
For example, OpenSCD is mainly lit JS based but we have for example, Swed plugins at Sprint
I and so we created for Transnet BW, Swed based plugins and we just compiled it to custom
elements and everything works fine.
So this is also really nice to broaden our perspective and broaden our, let's say the
developer team because no one company or the companies doesn't have to stick to one
technology.
Every company can pick their own or what they are best of it or what they have knowledge
of and they can just use it.
I'm going to show in a bit also how easy it is.
So let's dive into the plugin system.
This is OpenSCD and almost everything is a plugin.
The menu points for example are all plugins and as is the example, the Open project opens
by default, it opens a file locally from your PC.
But for example, in our let's say sister project in Compass, it's also an LF Energy
project, they re-implemented it and they have re-implemented the Open project plugin so
that it opens files from the server.
You can do this with everything else.
So of course saving makes sense too.
Then the next one is the editor plugin.
So this is basically the main content that you see in the middle and also in the tab
bar on the top where you can switch between the plugins.
And the editor plugins are the plugins that can really manage the...
Yes?
Oh yeah.
Yeah.
Thanks.
So editor plugins can really manage and modify the design.
And what you don't see is the good thing, it's a validator plugins.
We have by default the standard XML validators for the standard but you can of course, everywhere
if you want, you can create validators that check for some semantic meaning.
That means if you have for example a naming convention at the company, you can create
a validator for it and then it's going to tell you if a naming of a device is not correct.
Right.
So how can you create plugins?
It's really simple I think.
It's just an unregistered custom element.
So that means, if you can see it hopefully, it's just the standard way of creating custom
balance.
That's everything we need.
We don't really need anything much because this we can load and use.
And basically in this function, you can see almost everything we need.
At the top highlighted, you can see this is a...
Okay, maybe it's too small but in the top, we create a custom plugin tag.
So a custom HTML tag name for every plugin.
This is just to make sure that no plugin are collide.
And we do this by hashing just the source.
So you can have as many instances of your plugin as you want if it's necessary, just
only the source or the source URL has to be different.
In the next step, we just load the custom element, the JavaScript file and define the
custom element with already generated tag name.
And then render the tag, render the element, put in the HTML and the DOM and give it a
few props, a few attributes so it has something to do.
And the result is going to look something like this.
Where you have open SCD and inside it, we have this plugin with random or a hashed generated
HTML tag.
So this is again an other example.
But this is one of the plugins we created on the left.
It's just a small weld component that wraps around another component.
And on the left, we have this relatively small wrapper custom element that the main thing
it does is here just basically deploys or starts this weld component.
And why is it pretty good for this use case because it doesn't really have a runtime.
So even if you have sub-weld, so to say, in every plugin, you are not going to have
anything too big because it just really compiles down to basic JavaScript.
In case it would be also possible something similar with React because React also bootstrap
similar like this.
And the only thing is that then with every plugin you would load React.
Actually as the whole library with it, which sounds like a problem, but to be honest, once
you load it, the plugin then it is cached and you're not going to load it every time.
So even it would be good with React.
So the last thing I think, the distributions, what's one of our solutions we are trying
out currently is for example, it's what already working is that you can already deploy Open
SID.
So you can just take as it is today and deploy it on your own infrastructure.
It is just a web app.
So it's pretty easy.
And it's yours.
The other one is Eddence.
We are currently working on to provide building blocks so you don't have to use everything.
You can use just some of it.
And it's easier to recreate and modify.
For example, the plugin system, there is a history system where you can undo and redo
your actions and also saving the project and editing.
So these everything you could replace yourself and make it like for example that the editing
doesn't happen in the browser but it gets sent to the servers, to the backend and then
everything happens there.
So this is what we are working on to increase again the flexibility.
So again for the Compass project it's necessary to create new Eddence or a new, right now
they are, they use a fork of Open SID but it's not the best solution so we would like
to provide rather building blocks where you can put together your own platform.
And what we saw is creating your own plugins.
You can do it today at any time and the nice thing is that you can load the plugins from
your local PC so you can have your PC and nobody can access to it but of course it's
not the nicest thing to do so you can deploy it anywhere and you can install it in every
distribution.
So we already have a few distributions and we already have few plugins that we use everywhere
even and it's not developed from the same teams.
So it's always a nice way to use the work of others.
Yes, so I was a bit quicker than I thought.
Maybe we have a few questions but if you want to get in contact we have of course the Open
SID organization at GitHub.
We are on the Elephant Energy selection.
We have a website and you can try out Open SID at opensid.github.io.
Thank you.
Is there a question in the room?
The United States we have plenty of time, we have 10 minutes so if you want to ask a
question of course to Tamas but to other speakers are still in the room feel free to ask for
an energy question here.
But of course priority to Open SID.
It's post break, that's why.
Let's break.
Everyone's a bit tired.
We can understand perfectly.
We can ask questions to the audience.
Oh, that's nice.
Let's jump.
Okay, IAC 61A50 right?
You said that.
Does it, apart from explaining, does everybody have any experience with that?
Is that something you know of or not?
Raise your hand.
Okay.
So who works in energy industry?
Okay, about half I guess.
Are you doing something with energy at home?
Home automation maybe?
Okay, yes of course you said.
Okay, yeah.
What if we teach energy that comes where?
It's not industry.
Yeah?
My teaching.
Teaching, teaching.
Oh, education.
Education.
Higher education, primary schools, I don't know.
Yeah, so much things.
We had the own tech of course also.
Has anybody thought of a question now?
Ah, there's a question.
Great.
You're a hero.
I think it's a follow on from your comments.
I'm coming from a telecoms industry.
I think I see a similar problem.
The community is not big enough.
The energy community is not big enough to sustain these types of projects.
I think telecoms industry sees the same.
So is there a way that the projects can be widened to get that their scope is even bigger
so there's a much bigger chance of getting a more sustainable community?
Do you have an opinion on that?
Yeah.
For sure.
So as I mentioned in the beginning, so like it's what we try to do is what I talked about
today is a technical approach.
One was that basically having a desktop app is not going to cut it.
So you need some new solution like the web platform where you can really distribute your
software to everywhere.
And also LF Energy and Alian there already does a great job with supporting the open source
communities and using their project.
It's already really big.
How else you can, I think it's really hard to get amateurs so to say or hobbies I would say to the
projects because the features we develop is not for a week and not for a week.
The results are really long term.
So until we really reach it, it could be years even in the energy industry and in the telecommunication
I think it's similar.
So the technology, how the technology moves in these industries is quite slow so to say or slower
and maybe interesting.
So how you can maintain such a communities I think you have to get through the chasm.
If enough people get to use the project, for example, I think we are either there just before the chasm
because Alian there uses it, Erty uses it and TrustNet BW uses it.
If you can get a few other TSOs on board, then probably we're going to get over the chasm and the
rest of the TSO is going to see this is a nice project and they want to maybe get involved too.
So that's one thing how you can maybe grow the project and how to maintain the project is of course
through foundations and through the companies.
I don't see indeed this industry because it's so specialized and because of the closed source or the closed nature
of this standard doesn't make it easier.
I'm Dan Brown from Linux Foundation Energy and you're exactly right.
There are so many parallels between networking and energy.
I would say networking in telecom is like ten years ahead actually of where energy is right now, believe it or not.
Where things, you know, ten years ago nothing was software defined and that sort of thing in the telecom space
and now it largely is.
So we need to go through exactly that same transition.
I'm not saying telecom is perfect by any means and there definitely are not enough people in energy.
So it's a matter of getting all of these traditional old school suppliers on board as well, the vendors who have been
selling proprietary black box systems to the energy industry to utilities for years.
They need to basically stop doing that and come to it with an open source approach and so they need to bring in the resources
but we also need universities, we need researchers, we need government, we need the utilities themselves.
So it's really a matter of community building and scaling and it's, you know, not an easy task by any means
but that's why we're here in hopes that some of you who may not currently be, you may be developers in other vertical markets
or in horizontal industries, horizontal technology areas who may find this interesting and be inspired
and be inspired to, you know, come and join and start contributing to these sorts of projects.
There's not, you know, an easy solution unfortunately but we're just doing everything that we can to keep building capacity.
How the IAC61-850 market share, in terms of number of items, what part of the market of the substation does it represent?
Meaning on one red electronic site that's deployed, how many are compatible with this protocol?
So I'm not the best person to answer it, I'm not an electrical engineer, right? I'm not sure.
So far what I get is that they are capable of it, so the IEDs, the Intelligent Electronic Devices are capable of it.
I'm pretty sure, at least in you, so I haven't heard that they wouldn't be, so yes.
Any other questions?
Maybe to complete what you asked about.
I think that the two last days some of us were in the Policy Summit for a European Commission.
It was organized by the European Commission and we thought that it's very important to make a big announcement on energy and open source opportunity
because we all rely, our future relies on energy, of course, our business, everything is relying on the energy.
So if we can have fundings and if we organize through foundation to coordinate the effort and not to make efforts there and there and there,
I think we will find a great path to have more and more contributors. Yes, you have a question.
Can you please give the mic?
I just want to compliment, sorry if I stopped abruptly, I'm sorry.
I think that there's a very, in my experience, in my research in software-defined paratronics is that
software-defined energy is much harder to achieve than software-defined data and signal
because of the fact that there's a lot of current, there's a lot of power, there's a lot of issues with that
and different use cases require different types of converters and all that.
So there is, for me, one of the hurdles that we have as a community is that we need more open hardware as well.
I mean, let's try to do some, you know, no code with no computer. It's not possible.
We need to, if we want to do software, we need a computer.
And if you want to do power, you need a power converter.
It kind of goes with the, we abstract the hardware because eventually we want to, but there is a lack of hardware
and I think that's a big frame, that's a very big break on the process
because hardware is not only hard but it's difficult to abstract as well.
We're going to get there.
Thank you.