Partnering research and open standards: How EU innovation is shaping the future of OSGi

In this session, Tim Ward, the Chief Technology Officer at Kenzen, discusses the role of open standards and research in urban development projects. He highlights Kenzen's mission to enhance city data utilization for better decision-making related to environmental and economic challenges. The talk outlines several research initiatives, including In-building, which focuses on improving construction processes, and CogniFog, which employs wearable technology for health monitoring in construction. Urban Flow is introduced as a newer project aimed at optimizing urban design for modern life. Ward emphasizes the importance of open standards and collaboration in ensuring sustainable research outcomes and encourages audience engagement with open source and standards bodies.

Well, hello everyone. Thank you for coming. Hopefully this title is not a surprise to you and you are in the right place. A quick introduction. So my name is Tim Ward. I'm the Chief Technology Officer at Kenzen. I've been doing work in standardization for very long time. I've had about 10 years working with EU research as well. And I wrote a book some time ago. It's not

necessarily the most up-to-date, but I've I've been working with standards and I've been working with research for longer than I care to remember. Little bit about Kenzen. So Kenzen is we still refer to ourselves as a startup. It's been 5 years and we're now 12 people. So I think we've probably progressed to SME, but it feels like a startup, which is nice. It was a a spin-off

from CEA. So obviously a long pedigree there and one that has progressed over to Kenzen. So we have quite a number of PhDs and we do a lot of research work as well as product. And we're really looking at how we can get cities to make better use of their data so that they can make better decisions and face economic challenges, environmental challenges and better serve their

citizens. And it's all about taking data and doing useful stuff with it. So this support system has an open heart. You can see it that bottom layer the data hub is making use of an open source project called Eclipse Sensoria It is a digital twin and gateway that provides access to data in an open and simple way using standards from OSGI. And the reason I bring it

up is that we'll be talking about how some of those OSGI standards were built from research that was done by Kenzen. And it's This is used across all kinds of domains. So, we have environmental monitoring, urban heat islands, um and greenhouse gas emissions. We look at transport, so throughput at junctions, traffic monitoring through roads, all kinds of things that you can do. But, to talk about what

we're here for today, we're going to go through a few of the research projects that Kenchiu have been involved with recently. Um and with the common things that make them research projects that we're we're involved with, what the building blocks are, and how that fits with standards, and what standards can provide to the research process, and how we can use this to build a really positive feedback

cycle to improve research going forward. first one I'm going to mention is a project called In-building which you'll notice has a very very long full name. Um and what we're working with here is a way to try and improve the process of renovating and building new buildings in cities. So, construction projects are a big thing. The the world is still urbanizing rapidly even in even in EU

countries which have already a high urban population. There's a need for more housing, more buildings. Building stocks are some of them relatively old. There are a lot of buildings that are 100-plus years old, and they need to be retrofitted to fit with modern standards for insulation, energy efficiency. And all of that is actually a huge deal in terms of economic input, and also in terms of greenhouse

gas output, environmental impact of doing the work itself. So, what we're doing with In-building is we're working across three different locations. So, we've got Italy and Spain and the Netherlands and we're making use of a variety of open standards. Uh some across the building domain, some across some across the IoT domain, and some which are just more kind of messaging protocols to be able to exchange information

and better manage the the building process. CogniFog on the other hand is one which is more focused on e-health. So, smart monitoring of people through wearable technologies. So, being able to look for general health through things like pulse monitoring, fall detection with accelerometers. And it's not just being used for the common use case, which would be managing elderly care, but also actually plays into the construction side

again. If you have people who are working on a construction site with wearables, you can detect when they are, for example, moving into a location where there is heavy machinery operating and you can provide warnings if you know that they haven't been issued with additional protective equipment. So, maybe they need a higher rated hat or special boots in order to be operating in a particular area. You

can also get fall detection. Falls being not uncommon form of injury on a work site where you typically don't have proper staircases or guard barriers in every location because they haven't been installed yet. So, CogniFog uh CogniFog also extends further to live monitoring of things which are moving around, which are in this case drones. And that these are being used here in Paris to simulate detection of

flooding events and being able to direct emergency responders. So, these are these are all very kind of interesting and different things that you can do with incoming data. Urban Flow is a much newer project. So, Incubent Cognifog are are towards the end of their life cycle. Urban Flow is much closer to the beginning. Um and this is really about trying to better design cities to fit with

modern life. So, positioning of things like, say, charging points for EVs or uh the locations of uh of public transport stops being optimized or uh getting better engagement with with citizens about how they want to use a particular space. So, there's an awful lot of work that we're doing here to optimize and suggest better placement of uh things like I've said, EV chargers or other um things,

even even waste bins. Uh optimizing the location can improve both the collection of waste, making it easier to get, but also the the proper disposal of waste. You'll find that if you don't have a waste receptacle within about 50 m of someone who has waste, they are 10 times more likely to drop it on the ground than they are to carry it to the waste bin. So,

it's all sorts of optimizations that are are going. And, as I mentioned earlier, urban heat island effects are something that are very significant. When you are in an urban planning situation, you need to actually take into account how you are going to um ameliorate how you are going to reduce the physiological effect of the surfaces that you're building. So, those were three fairly different projects. But, what

did we actually see? Cuz there are some common themes throughout those projects, and I don't mean the fact that they had name 35 syllables for one of them, and I think all of them are over 25 syllables if you actually spell out the full name. every single project was complex. It had lots of different goals, and but they all had measurable cost or environmental improvements associated with

them. You'll find if you're ever submitting a research bid and you don't have those things in there, you will not get through. We also in these these particular projects had very large consortiums. The smallest was 12, the largest was 30. I think the one in the middle is about 25. So, this is a lot of different people involved. Not I mean and not just people, organizations as

well. And the demo sites, all of them had at least three different places that we were working, and they were all in different countries. They're all obviously therefore differently localized, different languages. It's a even different regulatory structures. And also every single one of them referenced open source projects directly by name, and also open standards by name. Those are things that again people want to see that you're

using. They want to know that the solution that you're building is based on work that's already been done. So, why is open source so important? Well, it's not really surprising. I you'll all know the quote standing on the shoulders of giants. The way in which research works is that we build on the state of the art at the time and we try and push it just that

little bit further. If you're having to start from the beginning every time, if you start from nothing, you will achieve very little because you spend most of your time working back up to the place that you were already were before. So, primary value of open source in this scenario is it allows the innovators to reuse a previous discovery without having to reinvent it so that they can

invent the next thing. Open standards, however, are just as important, even though they are often neglected. And it's because standards are about how we fit things together. It's not enough to say, "Oh, everybody uses this particular open source project, so it's fine." It's not enough to say this is a de facto standard because it's the most popular thing. What you need is you need something that guarantees

that the integration work you do will not be wasted if for some reason you need to change to a different library. You need to change to a different provider. If you have one entity in control of what you're doing, whether that's an open source project itself or some company, you are not really able to properly collaborate because you are the decision is theirs. The decision isn't consortium's.

The decision can can never be yours. So, an open standard allows proper participation from everybody. And it means that you can integrate in a way that is reusable, not just once, not just twice, but onwards and hopefully forever. I'm fairly sure you're this will not be news to you. Um most of you will have been involved in research before, but this is the research project life cycle

and how how this is going to fit together. So, we have a kickoff at the beginning where we basically make some plans. And then we start and there's a milestone that we create. So, this is where we've got some implementation and we do some design, we do some build. And then we deploy it and we test and we validate and we usually produce a report at this

stage, which we deliver and say, "Look, we've done a thing. Here's where we are so far." And in any meaningful size project, we'll then iterate. We'll go round and round this loop producing more and more milestones until we finally reach the end of our waterfall and we get to the final report where we deliver and publish our findings and everybody says what a great job we did.

The difficult bit is this dotted line. How we reuse what we've done in a previous project when we kick off the next one. And this is something which is a really important step because there's been a lot of time and money that's been put into that process. For a a Horizon bid it can be millions of euros. I I I'm genuinely millions of euros. And if we're

not going to reuse that output if it's just going to sit and wither then that money it's not entirely wasted. We may have learned some things. There may be there may be things that have been published that other people do eventually use, but we are not getting good value for that money unless we can reuse what we've produced. when we do our project submissions, we do commit

to being long-term sustainable. We do commit to these outcomes being something that will be able to be reused. But it's actually very hard to do. Even if you just take your result and give it to an open source foundation, that's not enough. Because as anyone who's worked properly in open source will tell you, a good open source project does not happen overnight. It requires years typically of

effort to establish a project that properly sustains itself. So if you just take some open source code and put it into a repository, it is dead unless there is someone maintaining it. If it sits there and nobody's looking at the issues or nobody making changes it's dead. And nobody wants to be using a dead open source project. If If you find If you find one that does

exactly what you need and has been around and you know it will do I want it to do this, it does this, there aren't any bugs, you might choose it. But if you do, you end up forking it and then you do sort of fix a bug and then in 6 months you have your own dead open source project because you're not going to maintain it either.

So, this is what we need to avoid. We need to avoid the situation where all all of our output gets effectively dumped. So, what we need to do is we need to identify the problems we solved in our research. We need to take the common requirements from that research that from those problems that we solved and then take the generic solution that we're saying we found, say

this is this is the thing. And then really importantly, you write it down to make something that can be a standard because you've taken a generic requirements, put them together and then hopefully you also make some tests so you can prove it works. If you collaborate with an open standards body, that will be a good thing because they will help you to make a better standard. They

have experience doing this. And if you have a standard, it reduces the risk because you know that it's going to improve you've got the scope for what is supposed to be done by this library, this piece of code. You know have a certain surface that you're using and if you ever need to, you can re-implement it yourself or someone else can re-implement it and you can use

it because you know the surface and you've got the tests. It's much less risky as well because if you would develop an open standard with other people, you know that they needed the same thing you needed, so it's not just going to be you maintaining it. You've You begin the seeds of building your own community around the project that you want to open source. So, uh very

quickly I can go over a real example. So, Brain IoT is a a project it actually finished about 3-4 years ago, but it's one that Kenty were involved with and it was about industrial automation. Um and we we had some issues with latency which meant that we actually needed a certain uh sets of events to stay local within the JVM because otherwise we potentially got to the

point where latency was too high and we couldn't react as fast as we needed to to meet the KPIs. So, we got this in-process typed event bus. And we had a number of the partners already participating with OSGi, which was an open standards body. So, what we did was we actually took the requirements that we had. So, we needed to be in-process, we needed it to be

asynchronous, and it was event delivery. So, a bit like MQTT, but without ever leaving the JVM. And this became something called OSGi Type Safe Events 1.0. Um actually, it's definitely still active. Version 1.1 is due to release this year. So, it's been going at this point for 5 years. It's been used by a whole bunch of people, and it turns out it's so uh reusable that actually

the people who are pushing for the changes are in the automotive industry because they want to be uh using it, and there are a number of tweaks they can do to help it fit their actual real-time cases. So, it was a the initial thing we had was we needed low latency, they need predictable latency, which is similar but different, and hence the the tweaks to the standard.

So, finally, I'm supposed to be giving you a call to action, and what I would say is the most important thing you can do is to get involved. So, the Eclipse Foundation has a really good research community. I don't know if you've spoken to the Eclipse research team. If you haven't, you should. Um but there are also plenty of members in the Eclipse community who are looking

for project partners. Kent you are definitely one of them. Uh so, if you are interested in getting more involved with research, please come talk to me. We have a We have a booth in the exhibitor area and it would be great to find out more about what it is that's interesting you, what it is that you would like to be taking part with. And also, Eclipse has

its own standards working groups. The The more most famous is probably the Jakarta uh standards working group, but OSGi also exists as another open standards working group within the Eclipse Foundation. There are other open standards bodies as well that you you know are I too numerous to name, but getting involved with standards will help you to build a more reusable and a better piece of research. So,

uh with that, I will say thank you. I mean, it come see me at the booth. Talk to me more about this and I should drop now cuz I'm aware I've overrun slightly and I am cutting into everybody's time for drinks. So. Do you have question? Okay, so if not, I would like to thank