 Hello, everyone. Thank you for attending this panel discussion on the Elisa project enabling Linux in safety applications. My name is Jeff Rowe. I'm a community architect at Red Hat. I have the lucky job to evaluate and participate in projects like Elisa. I would like to let each of the panelists introduce themselves and we have a lot of ground to cover. Please let us know you roll within Elisa and how you got started working on the project and it will start with Kate. Hi, thank you. My name is Kate Stewart and I am the VP of Dependable Embedded Systems at the Linux Foundation. And the challenge for embedded is how are we going to make sure it's dependable and dependable. It's pretty much talking about, you know, can we handle safety critical, can we handle security, can we handle reliability, maintainability and so forth and how we can bring those types of disciplines into the open source ecosystem. So I was very much interested in the embedded cities and so Elisa started as a place where we can all focus discussions in this area and try to figure out best practices together working with the safety community. Excellent. Thanks. How about Gabrielle? Hi, everybody. I am Gabrielle Poloni. I work for Red Hat as a senior principal engineer. And I started my adventure in Elisa back in late 2019. At that time I was working for Intel and I proposed and took the leadership of the Safety Architecture Working Group and later on I've also been entrusted with the role of the governing board chairman. So since then I continue to contribute technically and also in sharing the board meetings. Excellent. Thanks. Paul? Hi, I'm Paul Albertella, a consultant working for Code Think. I'm chairing the open source engineering process working group. I've been involved in Elisa since 2019 and workshop in Munich. And since then I've kind of participated in a lot of the other working groups and then in particular the development process working group which spawned OSEP as a result of some of the work we did there. Excellent. Ilana? Hi, my name is Ilana Koperman. I work for Mobileye as a system software architect for safety features. And what I do is to help to design features which can be deployed in Mobileye systems to support safety. I've been involved in Elisa for the past over two years. And originally as part of the development process working group and now in the Linux features for safety critical systems group trying to understand how we use kernel features to support safety. Great. How about Phillip? Yes, so my name is Phillip Amann. I'm technical business development manager for Robert Bosch with focus on open source software. And I'm basically with Elisa since the beginning, since the very first days in workshops. I participated and put in my capacity where I could. So I basically did this and that depending on whatever comes up. And I became ambassador and then TSC member. Recently I took over the automotive workgroup because we had a change in the lead and we couldn't directly find one new to join. So whenever there's someone who would like to join, we still have a chance to get a new lead in there. On top of just recently started with a new systems workgroup. So this will be my second lead on this. It's basically putting the Elisa in the wider context of a system. And I'll talk later also a little bit about this. And Milan. Hey, I'm Milan Lacani. I'm a software engineer at Code Think. And I also have been working with STPA and safety for around three years now. My journey with Elisa started two years ago. I joined the medical devices group. And I'm also a member of the tool investigation group and doing some safety analysis and also some bits and bobs in the tools group, such as working with kernel patches and doing some kernel tracing as well. So that's pretty much me. Excellent. Thanks. It's a great group to be involved with. So as each of you is deeply involved in one or more of the working aspects of Elisa, I'd like to start by asking each of you what's the most important thing your working group is doing this year to promote functional safety within the Linux ecosystem. Kate, let's start with you as you started Elisa and as you oversee its activities as it's the executive director. Can you share a bit about why you thought the Linux ecosystem needed Elisa and how these groups work together towards Elisa's goals? Sure, sure thing. So Elisa project has evolved and as we've been sort of working our way through different use cases. What we want to do is try to look at, you know, some different open problems that we can do the analysis. And so we have these cases like automotive and medical, and then they feed into the other working groups such as like the tooling, the safe, the OSEP group, the architecture group, and the one Elana is working on. And then now more recently we've just added in a systems working group. And so these use cases are all feeding it into those so that we have a context to do our analysis. And these groups all work on creating that analysis in an effective fashion. The reason like we got involved is we know Linux is being used in safety critical applications. And the people doing the analysis from a safety perspective really didn't have a good framework for how to start to judge what is realistic. They have various frameworks from various standards already, but some of the methodologies were not quite jiving up. And so we wanted to try to understand how we can bridge between these two communities. Excellent. So, yeah, as the safety architecture chair, what does what does the safety architecture chair do what is your group working on? Yes. Thanks, Jeff. So the actual working group is focused on determining key subsystems of the kernel that are involved in supporting a specific safety application. And, for example, right now we are working on the delta use case that has been proposed and discussed in the automotive working group. And in the context of such safety application we deliver safety analysis of the kernel and we propose architectural safety mechanisms or countermeasures to avoid or detect dangerous modes. And as of today, the most the most important topics that we are looking at are how the kernel supports the integrity and production of the dress space of the tail safety application. And also what is the contribution of runtime verification monitors for to the qualification of critical kernel subsystems and drivers. And in this regard, there is a request for comments that has been submitted upstream recently by by Daniel Briscoe and is under review. And so, yes, and through this analysis we feed, you know, the other working groups with also material, you know, to look at and to investigate. Excellent. Paul, how does the this architectural work fit into your open source project open source engineering process working group. Okay, yeah, so in in OSEP we're trying to work out how we can make safety claims about these things about the Linux architecture and the features that we're looking at in the other groups, as well as about the engineering processes that are used to develop Linux and how we can use these claims to to support safety arguments that we want to make. And quite a lot of time in the early days of at least trying to map out the good engineering practices that the kernel community follow when they're developing Linux, such as things like patch review and testing of specific kernel releases to the reference processes that are described in the safety standards. But we came to realize that this this wasn't going to be viable because of the way that Linux is actually used in practice. So instead, we're exploring processes that the people who want to use Linux as part of their safety projects can apply for their specific integrations and use cases for Linux. So this is all about creating the evidence that the safety standards want to see to give us the confidence in the safety related role that Linux is playing in a given product. And some of that supporting evidence may already exist may already be available from the kernel project. But because of the diverse range of options and configurations for Linux, in most cases this will need to be created or recreated for the concrete context and purpose for which this is going to be used. One of the approaches we've started with is using methodology called STPA to help us analyze the role that Linux plays in a given system so that we can derive and specify a set of safety requirements for it. And this is particularly important for a starting point for using FOS in general because it usually lacks a formal functional specification. And it's especially important for Linux just because it can be configured in so many different ways. And this technique has already been used in the automotive and the medical devices groups. So in OSEP, we're also trying to learn from their experiences and work out how we can build and document a more coherent approach to this. That's great. Thank you. Ilana, your group dives down into the weeds with regard to Linux features. Can you talk about what's going on there? Our workgroup focuses on taking a deep dive into the various technical features of Linux to try to understand the potential use of those features in order to design safety critical systems and to support safety claims. In our workgroup, we don't make any safety claims on those features themselves, but we focus on those aspects of the Linux kernel which seem to be most relevant to safety. So the discussions are really deep dive technical discussions about features of the Linux kernel. Most recently, we've been focusing on memory management, stack, heap, kernel space, user space, potential features and extensions kernel configurations, which may help to support safety claims on memory usage. Our meetings focus primarily on the technical aspects of the kernel and we leave the safety analysis to the safety experts and the other workgroups with whom we work very closely, primarily the safety architecture working group and OSEP, Another goal of our working group is to provide people without Linux development knowledge or experience with insights into the way Linux works and how Linux features may be used to support safety claims. Great. That's really interesting. So, while these groups are sort of horizontal in nature, working on processes that cross over a lot of industries. Melissa also has two vertical use case working groups around automotive and medical devices that focus on those industries specifically. Milan, you chair the medical devices working group. Can you let us know what's going on there? Yeah, so the medical devices group is applying a safety analysis technique called STPA, which stands for Systems Theoretic Process Analysis. And we are doing it on a Linux application OpenAPS, which is an open source artificial pancreasism that is increasingly used by people with type one diabetes to automatically instruct an insulin pump to administer insulin doses of a calculated size to control glucose levels. This is appreciated by all the diabetic community as something which saves the method and improves the condition. It is designed with the aim of having complete functional safety. It keeps the glucose levels very stable and does not require the human to wake up or remember to set their insulin dosing. STPA is a technique which investigates how the interactions of different components in the system can be flawed as well as just the components themselves. It forces us to check that every action from every component of the system is monitored with feedback loops and that we have thought about all the different ways that each action can be unsafe. We are generating scenarios of hazards and safety requirements at the moment in the hope that this will make OpenAPS system more trusted and improve safety if needed. Do you want to talk also a little bit about the Toolings Investigation Working Group? Yeah, so the Tools and Investigation Working Group is focusing on applying some of the safety processes and ideas that have been developed in other groups. We do various activities including sending kernel patches and monitoring the static code analyzers for bug reports which analyze the kernel. Excellent. Philip, same question for automotive. What's going on this year? So then the automotive workgroup was found. We got our first use case which is based on the instrument clusters and the telltale use case which basically is responsible for the warning signs like your indicator or normal indicator lights, engine checks and so on. And we recently discussed if this is still a valid use case because there's so much rumours going on and the fancy stuff is now autonomous driving. And therefore we had a discussion within the workgroup and we say that the instrument cluster is still a very good use case. We're talking about the results within our guitar repo and make a post out of it. Why it's so interesting? It has really a moderate ASL level. So software integrity level is just on the level B out of D. So it's quite good from an ISO 262 perspective because we don't have to look into too many details. And the thing is that already in today's navigation infotainment instrument cluster there are certain uses of Linux involved. But this we can add the safety functionality or demonstrate the use case around it. And one side effect which currently goes on on this use case is that we're not using the full strengths of Linux because we heavily rely on external hardware watchdog. But this is basically also that everybody who looks into our workgroup can benefit from the activities. So it's not all Linux centric but it's enabling Linux later on. As already mentioned before, for others we are using the STP analysis also here. We have to do a lot of this work to basically understand, describe the architecture of the use case because there's not much documentation available for automotive. And we really focus that we identify all potential hazards, losses which can occur by this analysis. And additionally to this documentation we have a demo based on the automotive grade Linux instrument cluster with a special Yachter meter layer which we also documented in Github. And we saw when people joined it's very hard that they get into the work so we spend a lot of time also to document this. And as we started first we see meter layer then moved on to the STP analysis. We now bring both elements together again to see that we further tailor our instrument cluster demo to the STP analysis and vice versa that every single instrument cluster demo for the telltale parts also fits to what we have done in the STP. And also as we start with the QA based demo because this was the easiest thing to grab we see that automotive lies to touch something. And for this we currently considered to either go with a Raspberry Pi or even better with an automotive reference as you see reference board. So, and as we're still small some we would try to reach out to more people that we get also more feedback from the automotive. We're not the smallest group we see in Lisa but with just like five to six currently participants really active and working on it. And we would like to get more feedback that we hard not use case that more people make use of our else's and to also confirm that we're on the right track. And we've got as feedback that we'd identify more smaller work packages also so that the hurdle the entry hurdle to join to do something more or something new gets lower. So create these work packages out of it so that people just can jump in and say I would like to start with something small. And we hope that we can attract more audience by this. Yeah, that's basically the automotive activities for us here. Great. Thank you. That's a lot going on in these communities. So, moving on for each of you how does work you are doing impact other open source projects. Elana, do you want to start. Okay, we actually the newest working group. That's has active meetings, long term we see potential group for working with other Linux foundation projects. For example, in the security domain projects such as open SSC kernel self protection project, etc. To develop specific features for safety similar to security models to develop perhaps safety modules, which have potential benefit in specific use cases. We don't make any safety claims of those features it's up to the user to integrate those features and prove any claims on their appropriate use. Obviously there are no silver bullets, no safety or security feature for that matter can make any magic promises. But we aim to design features similar to already existing Linux security models, which have potential benefits to support safety. For example, protected memory management for critical data or monitoring synchronization between parallel threads to avoid deadlocks race conditions. Interesting. Yeah. Yes. So, yes. So from from the safe architecture working group perspective. So indeed, you know, the safety analysis that we conduct are aimed to identify and mitigate dangerous further modes in the context of a specific application. Okay. However, the considerations on the architecture of the code or possible counter measures this may be valid in different context that could even beyond partial safety and in this regard, I can bring up a couple of example. So for example, back in 2020. So the working group started to analyze how Linux supports the handling of hardware memory errors. And in that context, we took as an example the handling of x86 machine check exceptions. And as a result, the working group spot bug in how Linux handled some of these machine check exceptions. And the patch that was was sent upstream and was also backported to the long term support branch. Okay. For example, that is something more recent that you're looking at right now is the runtime verification monitor patch set that Daniel Bristow pushed is pushing upstream. Okay. So that that work started as a formal verification mechanism to determine the maximum latency associated with the scheduler. And it was done in the context of the Linux foundation real time Linux real time project. Okay. And, you know, that that mechanism. So it was born in that context, but right now this formal verification methodology is being evaluated for supporting safety claim and safety requirements that are allocated to the Linux kernel. So this is also another good example of, you know, like, you know, collaboration, you know, interactions between Elisa and other more extensive projects. So, yeah, sure. Thank you. That's it. I have a poll. Well, our focus is obviously on on Linux, but the approaches that we're exploring are intended to be applicable for for an open source software in general. And even in the context of Linux based systems. This is important because we need to consider the episodes tools that we're using for construction and verification. And also the other components that we'll be using as part of an OS. I'm hoping we can kind of work with some of the other episodes projects out there that are already going on this safety journey, like the Zephyr project, for example, to kind of compare notes and see if we can learn from each other. And since we're using the STPA methodologies part of our approach collaboration with the wider community using this methodology. There's the there's an associated accident causality model called stamp, which was developed by MIT. And they run, there's a European stamp community as well they run workshops kind of discussing how other people are using STPA. And Milan and I have attended some of those and I've spoken to a couple of them, but they're also a really great opportunity to learn about STPA and to share our experiences with other practitioners. So I'm hoping we can kind of build some connections there and help them to learn how we're using STPA. And the verticals, of course. Yeah, so to trust the most of your thing, I already mentioned that we work with the instrument cluster from AGL. So by this, we contribute back this thing that AGL puts a lot of efforts into the infotainment into the cluster demo, but they are not focusing on safety elements in there. And by this, say, really mentioning also when people ask, what about safety was in your and they just say, okay, check with the leaders. So that's where we come into picture. Additionally, also in the past, we had been discussing was extent project, they also gave presentation during one of the Lisa workshops. And here's that they also have an automotive safety parse for function towards functional safety. So the work should be of benefit for them as well. More on the general principle to understand how telltale and the work is case architecture looks like the last part of it where we haven't been in direct contact but where it would be most likely the best benefit of the left fire projects because this is an artist was a safety track of it's very well into telltales, which are traditionally an arches application. And this is that we are in a quite generic way as we don't use a full strength of Linux and all the features in there. So that I hope that the community can really benefit from it. And one more point also here is that it's actually not what we can call open source. But if you talk about automotive there is most likely no way around autism or autism adaptive. We've been talking with the guys from the work group safety and did the requirements on all of this on what the documents provide what they put to an operating system interface what requirements they check and we provide feedback. We documented all of this work on our GitHub repo. So just that it becomes visible. A lot of these things actually were also taken by autism they put it into the documentation but as they have their internal track and then they go outside with the published version of the standard. Not everybody seeing this visible by now I guess. So this sometimes runs a little bit behind. I'll all three at the point about the systems work group. This was a recently founded work group was in Elisa here. I guess we see a lot of collaboration also with other not only with other project but also with other companies or partners which are not directly involved in the Elisa as members. So what we basically do in the systems work group is that we put the Linux cell and use new technologies and we see that containers are coming up more and more that we have a real system which gets. Virtualization hyper by there in that there's most likely an artist running on a microcontroller and we put these elements together, bring them into a build system. So that's why we also interacting with the Yachter project there. And also to see with SPDX community that we get the S-bomb properly solved because there's so many elements and they're right we have an artist we have a hyper by that we have Linux. We currently try to also figure out a way how we get maybe a Debian derivative in there to see also how Debian work this fits well to the Bosch world where they use a purchase. So here we are also discussion with Colabra who is a good supporter of this part. They not member of Elisa but as a contributor that is worse to mention along with EPARM not being there as member and Xilinx with very active with Xen provider. So also a lot of interaction takes place there with their community representatives. That's the very nice thing. And it also should help the other work groups because we saw all reset the horizontals and the work at the verticals in there. Right. And this summer brings it in the Widerscope. There's a better chance to not forget something like updates later on or other things which come into picture which will make our life even harder later on. Yeah, that's basically the thing about the systems work group. Hope it's growing one and will help also a lot of other communities. Okay, excellent. Milan, do you want to talk about the medical devices group and possibly the tooling invest tools investigation. For the medical devices group there are also other closed loop pancreas systems which are based on open APS for example looped and Android are similar systems evolving mobile phones and our work should relate to all of them. And we also hope that we can contribute to more insulin manufacturers supporting closed loop pumps. At the moment, sorry, I mean, clotted systems at the moment a system like this is not possible with most insulin pumps. So most people type these will have to administer the ring. We hope that these are basically will be useful to others who are looking at open source medical applications to provide confidence solutions can be trusted to be safe for patients and practitioners alike. And that's the medical and the tools group. We, we try and work with the concepts developing other working groups and see how they can in practice and we try and test different tools and see if we can get problems with them. And we also can see if we see problems with for example K checker. There's a problem and we can fix that problem upstream and we identify a few problems and in that way. And we like to develop our own testing techniques in that group as well and try and, for example, to try and see different activities and what was in practice. It's great. Thank you a lot. So finally standards and the methodology is developed to comply with them are extremely prevalent when working towards functional safety. So for each of you, how does the work you are doing impact or is impacted by related standards. Let's start with a lot at this time. Okay. Oh, from the angle of a major automotive user of Linux and open source software. I'm leading our work group and learning to align use cases of Linux kernel features with existing safety standards, such as ISO 26262. And more recently implications of ISO 21448, which is normally commonly called soative. And trying to see how we deal with the challenges that come our way in the business world in the most cost effective way possible. At one point, it would be great to get open APS certified based on a standard so that people can trust open APS more because it does require a lot trust and to put more pressure on insulin manufacturers to recognize open APS. And we haven't looked at this much, but we have started comparing open APS to the IEC 6234 medical device software standard. So the 6234 standard, we've been doing a bit of analysis with that and we've got to work white paper up doing, you know, what implications are the various causes. So that's sitting our good upside over and that's been worked on from some of the safety participants in the group. So pulling these pieces together and working it for understanding what's there, what's it's asking for, but then also quite frankly, understanding how can we make it safer? And helping giving that feedback to the community in terms of when we see things, let them know that the hobbyist project for open APS. So there's a different set of environments there, right, Shulan? Yeah. I think it's a very wonderful product with the medical devices because it's something which has a safety relevance and was just created by the people needs, and they didn't care about any safety standard. And they still give a trust into this product and this thing. So it's actually the work and the STPA independent of every safety standard is just to prove the trust which the people give in this product and to say it's a benefit for the life. It's really nice use case and I think it's much nicer to see in the end than compared to an automotive use case where we have this strong hammer of the IEC 26262 above us. We actually have engineers who have not full access to the 26262 because while you have to buy it right to read what should be done to for safety integrity. But actually for the automotive work group, it's also not that bad to don't have the standard because if you read through the different standards, they bring element in there which are always important. You need to have proper requirements, traceability, test coverage and whatever goes along. So it's not about processes in the round. And if you put on your brain and there's a world before safety standards and you still could make safe products, right? You don't need a safety integrity standard for this. And this is also why we say we put a little bit the ISO 26262 beside. We are very happy about OSEP and other work groups which really look into also how reference processes fit together. So we don't have to take this part. And then we just try to get the ideas how the system looks like, what can impact safety, where can fault, where can failures come up. And it may then also help others because typically a lot of information automotive is not as open as you would hope for. So in this way, we make a lot of work public, which is the work which we're doing and we don't fit to standard then, but we may come and give state-of-the-art concepts. And what I really like to say, this was mentioned once, I guess it was Chris Temple in one of the presentations. He gives very good ideas about what basic safety functionalities and how system should look like. And if you look into a nice drawing from him, you can see that you actually are most likely able to create a safety certified product, which is not safe, which was the worst thing of all. But on the other hand, you may also be able to create a safe product, which is never certifiable because the safety integrity standard was just created for another way of software development, another way of software product. And I feel this is something where we really suffer a lot from because we're really killing our brains, what could go wrong and then tell the use case and we may reach the same. We say, well, we have no more for the deer, give us input, but it doesn't mean that then it's certifiable. And that's how we treat the safety standards. We need what to do basically, but we will concentrate on the functional safety rather than on the standard. If I can just interject in one of the other standards or so working with is not in the safety phase, but how we can start to be transparent about the software running on the system. So ISO ICD 962 is the SPDX standard and they're starting to look at how do we capture the information we need to do in the safety analysis. So there's a build working group that's trying to catch the build information from the tooling, which is a big part of the analysis you have to do for safety, as well as what all are that you're running on a system. And so figuring out what's there and what can be running on a system. And having a standard way of capturing it in tooling is going to be helpful with the transparency and the analysis going forward too. And as you can also see, I guess a lot of automotive tier one OEMs make also the SPDX SC standards to be selected if you want to build a new product. I guess it's also a recent transfer, which you can see. Paul, do you want to talk a little bit about the OSEP group in this context? Yeah, absolutely. So in OSEP we do have some contributors who've got deep knowledge of the safety standards, such as ISO 26262, but also other standards as well. And that's kind of helping us to understand how the approaches that we're exploring can help us satisfy the expectations of those standards without having to stress everybody out about needing to read all these standards and understand them. Some of the terminology can be quite arcane, so it's really far from accessible. And actually kind of applying these standards can be quite difficult with open source software because the reference processes that they assume are based on development models for creating software from scratch, usually in a commercial context. And there's work underway in some of the standards bodies, like 26262 in particular, to work out how you can apply these things to pre-existing software, but it's still at a relatively early stage. And it would be great if our work in ELISA could help to kind of bring an open source perspective to that. I think one of our past contributors is on the committee actually. Hopefully he'll be a kind of a bridge for us so we can kind of share some of what we've learned and how to inform the standards so that the standards become less of a mountain for us to climb and actually more kind of aligned with what we're learning from actually kind of applying these in practice. And it's also important to think that some of the other standards out there about quality management or just formal software engineering processes, they're also kind of important for us as well because the safety standards just assume that you're following some of these things anyway. So they're making that as a kind of a baseline level of assumption about how you're making your software. And again, that doesn't map directly to the way we do open source, but then open source actually kind of innovates and comes up with some things which go beyond some of the expectations of those just approaching it from a different angle and trying to kind of apply things like the sort of continuous integration model and how you can actually use that to convince yourself that, yes, you are, not only are you following a standard on paper, you're actually applying it as part of your development process. So these things can all build up to actually illustrate that. Open source isn't it? It's not simply that we're kind of an out there group of people doing this in a weird way that doesn't follow everybody else's practice, but we're actually finding new ways to do this and to make the achieve the same goals but from a different angle. Excellent. I think that leads straight to GAB's work in the safety architecture and in the automotive world. GAB, do you want to talk about that? Yes, sure. Thanks very much. So, yes, right now in terms of safety standards, the main focus of the architecture working group is the automotive domain and this is just because you're working on an automotive use case, there is no other reason. And as Paul mentioned already, you know, there is a task force in the ISO community that is working to extend the current safety standard to the qualification of also complex pre-existing software products and, for example, Linux is definitely a complex pre-existing software component product. And this effort goes under the name of ISOPAS8926. And yes, I am officially one of the contributors to this task force. So, now, how can we contribute? I mean, indeed, from the actual working group perspective, we are working on tools or scripts that are helping with the architectural description and partitioning of complex pre-existing software components for envisioning this as the integration of subcomponents. And a key challenge today is that for complex pre-existing software components, we don't have a formal architectural description. So, we need a way to provide such architectural description that can be later used to perform safety analysis. And in this regard, we are working on these tools and scripts. Also, we are exploring how to conduct such safety analysis so that we can confirm and verify the safety requirements allocated to these components. And the goal would be to have these methodologies, examples, to be directly used also in the discussion points of the ISO community. So, maybe as we go through the annexes, we can refer to specific examples that you could take from Elisa, maybe, let's say. But this is what I see like a possible connection in this regard. Excellent. As we kind of reached the end of our time, Kate, I wanted to make sure to give you the last word as the executive director to talk about standards or any of the other work that's going on in Elisa. Well, I think the Elisa community is coming together to try to build those bridges between the standards, between the open source projects, and make it so that this type of analysis is possible. So, I think you've heard a good selection of all the different activities, and I would encourage anyone who's interested in a specific aspect or has an idea that they want to bring forward to come up to the TSC and have a chat with the community or reach out to any of the leads that you are seeing here today, and explore your ideas with them, and see if there's ways that you can continue to build upon, extend, or propose something new. All approaches are very much welcome. Great, thank you. I'll also give a shout out to the Elisa ambassadors because there's a group of us who can do some individual help if you have any specific questions or anything like that. There's a list on the website. So, great. Well, thank you all for a really interesting panel. It's always really fascinating to hear what's going on in Elisa, and it's great to see each one of you. Thanks a lot.