 Welcome everybody to this panel discussion with the innovators behind the new Pira project hosted at the Linux Foundation. In this session, we're going to talk about the history of the Pira project, where it originated, who created it, and how you can get involved. So today with me, I've got two folks from the Prometeo platform team and my colleague, Oopkar, as well. So, Salome, why don't you go ahead and introduce yourself? Okay, hello, hi to everyone. My name is Salome Valero. I love technology, innovation, and this amazing era of business transformation with AI and cloud. And I live in the south of Europe. I live in Spain, in Barcelona. I have a PhD in engineering, with experience in IT outsourcing services in the banking sector, mainly. I also work on good tech projects, and I'm co-founder of Prometeo with Marco. And I'm the mommy of two children, worried about climate change, natural disaster, and the living conditions for next generation. Daniel, thanks for having me today. Great, thanks for joining us. So, Marco, why don't you introduce yourself? Hello, nice to be here in the city of Prometeo platform. I live in Barcelona and I work in the same company with Salome in a financial sector. And I'm the father of two children. The biggest one, she has five years, she's five years old, and she's worried about the climate change too. So, she considered me an example to follow in the future and to have ideas in order to save the planet. And thank you for the invitation. Great, thanks for being with us, Marco. And, oh, Carl. Thanks, Daniel. So, I'm a software engineer with IBM. I have been part of the Prometeo project since it won the Call for Code Challenge. I live in California. We've had, every year, we have so many wildfires here that I really feel connected to the project and I'm just happy to be part of it. Okay, great. All right, so why don't I start with, just setting the context a little bit on the background of why we're here and what Call for Code is. So, if we're not familiar with it, Call for Code is an umbrella, an initiative that the Linux Foundation is part of, as well as IBM, the United Nations, and David Clark Cause. We kicked it off in 2018 and the goal was to engage developers to take on the world's greatest challenges. So, we have an annual competition every year where there's a winner and in that case, it was Prometeo in 2019. And we, what sets Call for Code apart as a competition as an initiative is that we don't just have the competition. What we wanna see come out of it every year is a solution that can be incubated and supported and put to work as a sustainable open source project. So, we'll get to that in a little bit more detail shortly. So, since 2018, we've had 400,000 developers, probably half a million now take part in the competitions and they've come from places around the world, obviously Spain and the United States, but plenty of folks from all continents. I think somebody registered from Antarctica, one point, I don't know if they're playing around with our registration form, but we covered at least six continents that I know for sure. So, it's a large community and it's hosted at the Linux Foundation, which we'll get into in a little bit here. So, as Salome mentioned and Marco mentioned, climate change is a huge part of the problem domain we try to take on with Call for Code. So, if you're familiar with some of the projects out there, we did take on natural disasters, wildfires, and emergency communications. We've also looked at clean waters, zero hunger, responsible consumption and production, as well as the social and business impact of the pandemic and racial justice through the program. So, the competition, you can look out for, take part and learn some skills through it, as well as taking part in some of the projects that have come out of the competitions, which get incubated and work their way into the open source community. So, Call for Code, the competition is the idea creation. Folks like myself in a car at IBM, work with the top teams like Salome and Marco to improve their solution, test it and get it ready for use by others at the Linux Foundation, where it can form a great foundation for the businesses that bring them forward or the organizations bring them forward, as well as being ready for that community of contributors. So, beyond what you learned today, I encourage you to check out the linuxfoundation.org website. It's got a list of the 14 projects, including the one we're gonna talk about today there. And they each have corresponding GitHub and Slack organizations that you can connect with. So, now that we've got that covered, I'm going to ask my first question of Salome. So Salome, let's just one second here. Can you tell listeners about the new Pura project, how it relates to Prometeo, kind of history of it? Things like that, how did it come to be? What's the mission? Well, I'm really excited with Pura. Pura is a good example of the power of open source to accelerate technology innovation, and that can save lives. We want to help protect firefighters with technology. That is Prometeo Mission. They are inhaling smoke and toxic substances, we must monitor their exposure to gases to have individualized, personalized strategies to protect them. And thanks to the linuxfoundation and in collaboration with IBM, we will accelerate the development and the deployment of firefighters' safety technology around the world through Pura. We will join our efforts with the rest of the global open source community to improve the solution. That is the challenge. Our dream is having every Weiglan firefighter with a Prometeo device. We want to protect them. Pura is helping us to speed up the process to deploy it worldwide. We are working on it with an amazing people and partners from the call for code ecosystem. And through Pura, we will make the dream reality. Thanks to everyone that are in our community. Thanks for your collaboration. Thanks for your contribution. Excellent. Thank you, Salome. So can you give us a little bit of a history lesson on where Prometeo started with the solution, some of the testing that's been done as we got through different versions of it and some of the other folks that have helped join the community to get us to where we are today? Well, we started the journey two years ago when we won the call for code. That was only the beginning of the journey. And we started with version one. Today, we are in version three and we improve the solution a lot, but this is a journey. So we must work more in the solution to get the dream. Excellent. So you've heard the overview of the project. So let me turn now to Marco to talk a little bit about how it works, how it achieves that mission and some of the pieces that come into play as it tries to achieve its mission. Okay, thank you. The solution has different parts. A device that measures variables from the environment, carbon monoxide, nitrogen dioxide, temperature and humidity. This is the device that every firefighter has to wear during the wildfires. We have a mobile application that collect the data from the device, a smartwatch to receive notifications and a platform in the cloud to process and report the status of the firefighters. When you turn on the device, it begins to read the sensors. If a mobile phone is connected, it will send the measurements to the cloud. It also has sensors so the firefighter can see the color status that is calculated in the cloud. The mobile application is the gateway between the device and the platform in the cloud. This application allows the user to log in into the platform and pair with the device. Once it's paired, the device will send the measurements through the mobile application. If there is internet, the information will be sent to the AOT platform service where it will be processed. Our flow then sends the data to the IBM Watson machine learning model. This model returns a simple color status that is displayed on a dashboard at the fire command center. If the color signal is green, the firefighter is okay. But if the color signal is yellow or red, the command center must take immediate action to remove the firefighter from the fire. Finally, the app will receive the color status from the cloud and it will be sent back to the device and the smartwatch. The firefighter will be notified by the device, lets, and be reading the notifications to the smartwatch. Okay, and this is all about it. Well, thank you. Nice, so can you explain how, so that's the technical solution. When the field tests have been done, can you explain how the process is and talk a bit about controlled burns versus wildfire burns? So the audience can learn about how this, how this is actually deployed in the field when the controlled burns happen. Who's where, what are the roles involved? Things like that. Yes, we have to take an account that there are various where the firefighters will be working to combat the fire. But they have to avoid the fire in the future. They have to, in a strategic way, they have to avoid the possibility of fires in the future. So they do this kind of controlled burns. They go to some place that they study before in the forest and they decide to burn the grass, the amount of fuel that there is in the mountain. In order to avoid the fire in the future, if it happens to arrive to a city, for example. So they study the mountain, the locations, in order to decide where to do these controlled burns. So when they decide the place, there are different people. There is the boss of the controlled burn that check everything is okay and there are people that they go with a torch in order to burn the grass in the forest. And it's important they have a pyra device because it's the moment where they're going to inhale a lot of toxic substances. So it's the moment they have to wear this kind of devices. To check that they're not going to overexposed the exposition to carbon monoxide or nitrogen dioxide. We have a dashboard where we measure these variables and we have in account different windows of exposition to these toxic substances. So if the firefighter is in the limit of the 10 minutes window, so it will be received a notification and somebody, the boss of the burn has to decide to take off the firefighter from the fire. So this is the important thing that we have to take in accounting in this kind of controlled burns because they are inhaling and they're going to be a lot of time in the wildfire in order to control and burn all this part of the forest that has a lot of amount of grass that can be approved in the future. Great, great. So it's been amazing to watch the project go from the conception to the initial version to where it is today. And I've been fortunate enough to see some of these controlled burns myself. It's just amazing that technology, you think it's ubiquitous, it's everywhere, but the process that exists right now is you have the nurses that record how firefighters feel before the burn. They go around with a clipboard, check on those readings, talk to folks, check on them during the burn and then check on them afterwards. And it's apparently managed completely by paper, Excel spreadsheets and just the innovation you had to create and just digitize that alone made a huge stride, I think. And it's just been amazing that going from the real time data, displaying that on the dashboard to now doing the calculation over time, I think is really fascinating. There's a lot of great data science that has gone into that and just different international standards for exposure over time to carbon oxide, 30 minutes, one hour, four hour, eight hour, same for addition to oxide. So it's really quite fascinating to see not only that this is in place, but how many different ways it can be extended for the different types of use around the world. So Utkar, why don't we talk a little bit about the open source components? So Mark would talk us about how the system works, but behind the scenes, what's it built on? Are there other Linux foundation projects involved? And what's the magic behind the scenes really? Yeah, Daniel, that's a really good question. So first of all, as Marko mentioned, there are quite a few moving pieces to Pira, right? We have five different microservices built on different languages and open source frameworks including Node.js, class, for backend, and React.js for the front-end. All of these solutions are hosted on GitHub in their own repositories under the Pira platform. Now, each microservices uses the 12-factor methodology to build independently services that are loosely tied to each other, but then again are individually containerized. We use IBM Container Registry to host all these images where we continuously monitor for security issues. The team has also worked really hard to provide Docker-composed scripts to ease the developer journey where the different services can be brought up with a single command. So I'm gonna touch on a couple of different parts here. So for database, we use MariaDB, which is one of the more popular open source relational databases. It was originally, it was made by the original developers of MySQL. Again, it has been great to work with. We have that running on our Kubernetes cluster in the deployed Prometail platform. We use IBM IoT service as an NQTT broker. So for folks who are new to NQTT, it's a lightweight, published, subscribed network protocol that runs over TCP primarily. It supports other networks as well. And essentially transports messages between devices. And then an NQTT broker is a server that receives all of those messages from the clients and then routes them to the appropriate destination. All of the data is organized in a hierarchy of topics. So we have our different devices listening in to certain topics that are relevant to them. So instead of a completely open PubSub system. We also have an Android mobile application written in Java that Marco actually contributed a lot of that. And we also have a corresponding Samsung Watch application that Daniel, you worked on, written in open source Tizen operating system, right? On the firmware side, again, we worked with Arduino IDE and the firmware, sub-firmware all the low level, right? It works with the hardware and the sensors to link the edge devices, which are the sensors itself to the cloud using the Watch and mobile app. And then finally, we use a lot of cloud native frameworks on the deployment side. So we use things like Helm. We use a lot of GitHub actions to introduce or integrate the continuous delivery, continuous integration piece. Locally we use tools like Scaffold and Stern to provide that monitoring capabilities. We also use log DNA in our cloud for centralized logging for the different events and errors as they happen on the cloud. So as you can tell there's, it ranges from a lot of these different frameworks and we try and reuse a lot of open source work that's already been done. Did you wanna hear something else? Sorry. Yeah, no, I think it's fascinating too, probably how the builds and the, Sun's got to pass through, excuse me there, sorry. So the GitHub actions, really, I think that's really the amazing part because a lot of the work that's been done in the last year has really to go from, how does this system work for just the developers who've been so close to it for so long to what needs to be in place for it to have a vibrant community? So we can talk a bit about some of the ways that it's gone now from being a custom system to now being something that you can choose to work one part of the solution, maybe the mobile app or you can choose to work on the microservices for the collection of the data and then for the data science. Maybe you can talk a bit about some of the recent work that's been done as it was prepared for release as the peer project for new developers to take part. Absolutely. So I think the original team, you know, Marco Salami, when they proposed the solution, it was a proof of concept, so to speak. It was built on Node-RED, which it's a fantastic open source tool that you can use for things like this. And, you know, with Marco's help and guidance, what we did afterwards was sort of take each piece in that Node workflow and create a service out of that that can live independently, scale independently as needed. And then we put in GitHub Actions as a glue to sort of bring it all together. So, you know, at this time, when a developer comes in, makes a contribution, let's say to one of the microservices, there are certain GitHub Actions that run to maybe check on linting, check on certain formatting, and then also builds a project before a pull request is created. And once that is created, we have a community where we encourage code review, we encourage having somebody else look at the code before merging it into the main branch. And once all of that is done, there's another set of GitHub Actions that will then build a containerized image out of it, push the image to the container registry. Like I said, we use IBM container registry and then update the Kubernetes sort of container labels appropriately so it starts using the new image. So, yeah, that's sort of how it works right now. For, again, from an open source point of view, you brought up, you know, skills. As you can tell, Peter, ecosystem is very diverse. And so there's a lot of stuff you can do as a developer if you want to contribute. If you're interested in learning, if you're interested in, you know, helping the firefighters, if you are in that space or know somebody in that space and you want to help, I'll tell you specifically at this point, the project is looking for developers on the mobile site, watch developers. But then again, as I mentioned before, if you want to help in any of the other areas, we'll be super excited to have you. With that being said, you're not just looking for technical expertise here, right? So you can absolutely help the project in a non-technical capacity. That's the beauty of open source. So let's say you're a project manager or you have experience in that field, we invite you to help run our technical steering committee meetings, for example, and there are other events around the project as well. If you're a technical documentation writer, then we can use your help and your expertise to make our GitHub documents easier to consume. And then final example I have is if you, the project is always looking for advocates who can talk about the project, talk to the project, and make connections with other relevant communities. So there's absolutely more than one way to help. Excellent, excellent. Well, thank you, Upkar. So Salome, going back to you, building on what Upkar just mentioned around how folks can come in and bring their own skills to the project. Can you talk a bit about some of the partners beyond IBM, beyond from a tail themselves that have been involved in testing the project and providing feedback? And if there's any organizations that you would love to see engage in this project, what sort of organizations would you love to see take part? I would like to see a lot of ones because I think it's a key point, the partnership with the call for code ecosystem for the tech and digital ecosystem. So I'm thinking about experts in mobile application but also in hardware, in software, because Prometheus has hardware side, software side. We need data scientists, we need companies with expertise in AI. So everyone is welcome. We are really excited with Pira community and every contribution matters. Till now we count on amazing partners like Samsung, like Arrow, like the university here in Barcelona, Universidad Autónoma de Barcelona. And we really excited with this kind of collaboration because you will have technology. So we are helping firefighter and at the same time we are increasing our skills in tech, in AI, in cloud, in hardware, in software. And we are meeting amazing people, talented people. So everyone is welcome, it's a great community and I would like to see a lot of you in Pira community. Please we are waiting for you. Excellent, okay. Great, so Marco, building off of that, I know you've had lots of conversations with fire departments and organizations around the world. We know that Pira originated from Promoteo and the context of being as part of the Catalonian Fire Fighters Organization. As you look to expand beyond Spain, what sort of things would change in the platform if it needed to be adopted or used in the United States versus in maybe Argentina or Australia? What sort of changes might happen? Like sensors added, different chemicals and what sort of next steps do you think there are for the sensors and what goes into the platform? Yes, what is clear is that all firefighters over the world, they have the same problem and the activities is the solution for the problem that they have. Exposition to toxic substances. There are some differences, depending on the firefighters department. For example, here in Catalonia firefighters, they have GPS in the Wulki-Tolki. But in Argentina, for example, some departments, they don't have GPS. So for example, the idea that we have is to include the GPS location. Now that we have the mobile application, we can add the location and send to the platform in order to have a map with all the firefighters that are working in the wildfire in real-time. There are other places, for example, where they need to measure methane. So maybe in the future, we can add this sensor that depends on the firefighters or the department that we will work in the future. In the United States, I think that we have to include more sensors, for example, the accolading, vensing, more sensors in order to get more data. And we can explode in the application. And there are wildfire firefighters, but there are structure firefighters. The firefighters, they work in the city and they need to measure another kind of gases. So it will evolve depending on the different departments that we are going to work with. Let me say that I totally agree with Marco. The problem is the same. We have a global problem. They are suffering headaches because of the exposure to gases. And this problem is global. So Prometheus and the PIRRA community must work on a unique solution. But thanks to OpenSURE, we want to have a solution flexible enough and open enough in order to consider the specific requirements from each region. That is what Marco mentioned about the gases, the different sensors, depending on the kind of vegetation in each part of the world. But thanks to the PIRRA community, the solution could be the same one all over the world and with a really quick implementation. But of course, each one can add or can add up the solution to the specific requirements for each fire station or firefighter department in the world. For sure, Daniel, that one thing that can change are the limits for each window that we are measuring. So this is for sure depending on the legal issues in each country can change too. And the other point is the evolution that we can include a lot of things. We have a device in the firefighter. We have a mobile with an application. So we can include a lot of things. We can include health rate. We can include the stress of the firefighter and the solution. We can use this data in order to plan the next assignments of the firefighters to the control bench. So we can do a lot of things. So everybody that they want to help us, they will be welcomed. And of course, all firefighters are invited to join to this community because Prometheus and Pira is for them, is to have a great solution for them, a solution to help protect them. So every suggestion, every recommendation, every requirement from firefighters to respond in general will be welcome. Excellent. So with that as the segue, we've been on a great journey I think from understanding the problem, getting to a version one, getting to a version three and then version four, which was just released in July as Pira. I know you have a roadmap for where you want to go next, both as a startup, as well as with the open source community and the ecosystem of partners. So you talk a little bit about what you have in mind, what the next tests would involve and kind of set the stage for some of what you mentioned around the physiological data that you want to bring in. Yes, of course. Our next milestone are adapting the hardware for use in new locations, in different locations, improving the analysis of toxic spots over time and adding new mobile and smartphone capabilities. We have this plan using the screen. We have a plan of three phases with milestones. There are three areas of improvement we mentioned before. First one area related to the hardware side, the IoT device, we focus on adding new sensor and improve the design of the casing to be robust enough. A second area of software platform to improve analytics and data. And third, an area with focus on new capabilities on the smartphone device, the phone and the watch. Mark mentioned before, we can add vitals from the firefighter like head rate or other vitals. So we can explore this area of new capabilities in the smartphone and in the smartwatch. And the most important milestone will be doing field testing in several countries and locations to ensure we cover the main requirements from wildland firefighters around the world. We mentioned before. I encourage everyone to join PIRRA. Firefighters are well prepared. They are brief enough, but they don't have superpowers. We must help them with technology. Every contribution matters. If you are a fair responder, you can help with key requirements. If you have technical skills, it's a great opportunity to help. For software developers, but also for hardware specialists, data scientists, network specialists, security experts for everyone. Everyone can add value to the solution. And you can do it in PIRRA community. You will meet new colleagues. You will increase your skills and your contribution can help save lives. Please join PIRRA. We are waiting for you there. I think that you can learn a lot about technologies that you're not going to see each other. It's not very common to see all these kind of technologies working together. And you want to know about hardware, about development, everything that you will need in the future if you want to create an IoT project for yourself. Here is the place where you can learn a lot. We invite students from universities. If you are studying a degree in technology and engineering, it's a good way to improve your skills and to practice your skills in a real environment because in the job, you will find these kind of tools like the Linux Foundation space for open source projects. It's a good way to help and to increase your skills. I would like to see young people in the community to help us to improve the solution. Excellent. We're coming up on a traditional time of the year for folks to get involved with open source projects. There's an event called Hacktoberfest where folks tag issues within the GitHub repositories, particularly the small things that we've needed help with, maybe we haven't gotten around to. I'd say definitely go check out those repositories. Look for anything tagged as good first issue at Hacktoberfest and get involved. One of the ones we've been trying to get through is things like a logo. We have a basic logo right now. If you're interested in helping improve the design of it, you can take a look at that. Obviously the documentation. Maybe if you know more about the standards, there's AEGL standards in Europe, the US standards, Australian standards. Anything you can bring to the table, I think would be very much appreciated in terms of kind of bringing this to the next level. An important thing is also the milestones, the field testing. To be honest, I went on IT in technology for a long time. That is the first time I went to the field with a fire fighter to test version one, version two, version three with these amazing people. It's amazing to be there and see how technology can help them. We need volunteers in the field testing. It's a good way to collaborate in tech, but also to be in the field in a controlled environment, of course, in press kit vents or control vents to see that the solution works. Excellent. Kupkar, do you have any other final thoughts around the technology or what you would like to see in the future of the project? Well, actually, since you have this page up, I would like to invite folks to our public meetings which take place every Wednesday at 2.30 p.m. Eastern Time. We get together and we talk tech. We talk about the issues that are open and work through our get-up board. If you want to get a little bit more feel, you don't have to come in and start speaking or taking part like that. You can come in and watch. Hang out with us. I absolutely invite everybody to come in. Daniel, to answer your question, I think the one part that's missing right now or I see as a gap is any sort of integration testing between the different services and the components that seem to work very well individually. But I absolutely feel that little link is missing. So, again, if folks who are interested in that area or that field, there's a ton to contribute to. Or a bit. Yeah, and that reminds me, we do have a project board you can check out at the platform, at the pure organization level. So you can see the issues that are across the board. Oops, wrong one. Let's see, projects, yeah. So we've got to get a project board, take a look at that. We do kind of triage what goes on through here on that weekly technical town hall with the community. So you can check these out. You can look into the individual repositories. They have some issues. And some of the most high priority ones are aligned to those three milestones that Salome had taken us through. So take a look at those, see if you can get involved right during this conference. And I know there's some of the great stuff that's happening at this conference, including the Linux Foundation's Zephyr project. That's something we want to integrate with this real-time operating systems for the hardware. So definitely take a look at that. And so this session has been prerecorded. But during the actual time slot, when this is going to be broadcast, some of us will be online there to take your questions live. So I want to encourage you to think about any sort of questions you may have during the event or after the event that you want to bring forward. And of course, every Wednesday, we would really appreciate folks joining the town halls, just listening in, check out the recordings in advance if you want. And really take a look at what's going on. So the best place to get started, if you just want to get a high-level overview, share this information with other folks. There is a website. It's pura-platform.org. So you can check that out. On the top right, that's the link to the GitHub organizations. We have a Slack channel under the call for code workspace. Look for the pura-prometeo channels there. And yeah, check out the Get Involved guide. So this is a good landing page for ways that you can take part that we've talked about. So with that, I want to thank all the panelists for their contributions. I'm really looking forward to a bright future for the pura project. And really encourage you to get involved, ask any questions and join us. Make them all safer. All right. Thank you so much, everybody. Thank you. Thank you. See you in the community.