 Our first speaker today is Dr. Franco Gasperoni, CEO and co-founder of Adakor. Franco, over to you. Good morning and perhaps good afternoon and maybe even good evening for some. My name is Franco Gasperoni. I'm the CEO of Adakor. Adakor is a principal member of the phase consortium. We are a premier sponsor of this year's phase and so is a technical interchange meeting. And in that role, I have the pleasure of welcoming you all here today. So let's look at the event first. Thanks to the resourcefulness of our organizers, we are able to gather here today virtually despite everything that's going on out there. As you know, a live expo is planned at another site in Pax River, Maryland next March and hopefully we'll be able to meet there in person. This year, a technical interchange meeting should be as informative as ever. You have the choice among 16 presentations of 20 minutes each, organized into parallel tracks. For your information, the first session after the captain is going to be a single one because unfortunately one of the speakers had family issues and that's great because that is an introduction for those of you that are not aware of what faith and SOSA are. You might know one, but you might not know the other. And if you want to know the agenda for all the following sessions, just have a look at the agenda. If you haven't, if you have misplaced all the links to the various WebEx presentations, I've put a link here. You can see it right here of where you can go to get the agenda and the detail of all the presentations. In the next slides, I'd like to tell you a little bit about faith, data core, and the problems we're trying to solve, some overlapping, some not necessarily some complementary. I believe many of these challenges are also tackled by SOSA. Unfortunately, I don't know enough about SOSA to talk about that. So please bear with me if you are a SOSA fan while I go through more software side view of the world. So let's talk very quickly about data core. We were born out of the vision of the US Air Force to develop an open, non-proprietary data technology to ensure that the investments of systems developing data would flourish. This was done via a research grant to New York University, where I got my PhD. And data core was founded after the research and development effort and where you was complete in 1994. And today, we provide software development and verification tools to build high assurance systems. Our products include automatic code generators for models, compilers, of course, vulnerability detectors, coverage analyzers, verifiers, based on formal methods are some examples. As you may guess from our company name, we fully support the data programming language, as well as mixed language software in ADOT, C, C++, and Java. Many of our customers are in the defense industry, and our products are used in a large number of defense programs. Three of them are highlighted here. Our products are also used to develop safety critical software for rail and civic aviation. And we have expertise in certification standards. There are so many these days. One relevant for civil aviation is, of course, CO178. What's interesting is that high assurance is now gaining importance and spilling over to other industries. So, for example, one example, one obvious example is automotive, but I'll talk about NVIDIA, which is not necessarily known to be in that space, it's a very space. And today NVIDIA is using one of our advanced tool sets to develop and formally verify and prove their security critical framework. FACE and ADACORE, our company mission, which is to help people build software that matters, and our offerings are, which are based on non-proprietary open technologies fit quite nicely in the FACE approach. As a matter of fact, we are an active contributor to many of the subcommittees, both the business and the technical working groups, and we're involved in FACE promotion since we joined the consortium in 2012. We are seeing an increasing interest in FACE from our customer. An example is Collins Aerospace, whose mission flight management system was developed using our ADACORE tool set and was certified as space conformant. There are over eight teammates involved in FACE. You might have attended some of Ben's presentation. You might have interacted with, at a technical level, with either Tucker, Pat, or Cyril. And most likely you've met Jesse, Michelle, or Ravi at a previous live FACE event. And I'm sure you all know that with the linchpin in the middle of it all. Okay, so I always start with asking myself the question, why? Why are we here? Well, the cost of new Avionics platforms are now in the multi-billion dollar. The time to deployment is lengthened. And this growth, that's the bad news, is non-linear. As humans, we love linearity and we know how to deal with linearity. When it becomes non-linear in on quadratic or even if it goes crazy exponential sense, we are a little bit at a loss. And my thanks to Doug who provided this graph that was presented at a FACE meeting in 2013. The goal, so in front of this sort of non-linear growth of cost and time to deployment, the goal is to flatten the curve. As Boeing did in a specific case for the Boeing 787 project and plane. Now, this problem, we've heard about it over and over and over again. And it's not only an engineering problem. I wish it was, but it is also an equally importantly a human, organizational and business problem. Today, we focus mainly on the engineering angle, but not only. And certainly I will focus on the engineering angle in the rest of the presentation. So how to tame this problem? Well, the high level, very high level answer is MOSA, modular open system architecture. Here, MOSA really means standard, open, sorry, means really standardized interfaces. Now, this principle of modularity is nothing new. That's what they teach us in engineering since day one. What's interesting is that, and as a matter of fact, MOSA was mentioned already in the 2001 study on aging avionics in military aircraft. And was reaffirmed very recently in 2019 by the memo signed by the Navy, Army and Air Force Secretaries. So what does a MOSA look like in FACE? MOSA in FACE is about interoperability and reusability at the interface level. So there is a component base view of software and focusing at the interface captures the long standing principle of software engineering by reducing coupling. So clearly we want a component to be designed with a clear separation between software interface, which should be as stable as possible. And ideally, when it evolves as upwardly compatible as possible, that's really the key there. While the implementation of the component might change, in particular, when you port to new hardware, and I'll talk a little bit about that afterwards. As a side note, this is one of the eight of programming language foundations. Now, all of these uses reuse the components on new avionics designs because the interactions between these components. Go through these interfaces and the fact that the interfaces are stable sort of doesn't create an earthquake when you're moving components from one avionics platform to the next. There is another goal clearly stated in FACE, which is that the portable app library mitigates lock-in to a single software supplier. Now, cost saving through reusable components is not so easy. You can standardize interface, you can standardize the data models and the data that gets exchanged between the components. So, why is it so difficult? There are technical hurdles, as I said, so designing a component for usability requires experience and a broad set of skills. Now, as I said, there are also non-engineering challenges. There is the human challenge and there is a business challenges. On the human side, you've developed a nice set of components, you know how to make them reusable, you've gained expertise on how to port them to different platforms, and now the team is disbanded. Or maybe key engineer sleeve, and now you're lost to know how. That's a human problem. On the business side, contracts traditionally have offered little incentive for either the agency procuring the software order contractor developing it to focus on reusability. Why? Because designing for reuse adds cost to the initial effort and this cost, you get the return on investment in later projects. Which may or may not be awarded to the initial contractor and the component may or may not be reusing a future contract. So, these are some challenges. There is one aspect where most and face are wisely silent on conformance is on the non-functional requirements such as performance safety and security, which is something that we always have. To deal with. So, I would say that the work that has been done in most and face and so is a must have, but it's not the silver bullet that necessarily is going to solve all problems and we know that. Let me turn to an interesting problem, which if you follow what I said, you might let to believe that, okay, great. At least face solves the hardware obsolescence. Well, let's assume we've got this great set of components that are working great and we need to pour them to the next. First of all, it's a fact of life that's known since 2001 that the life of integrated circuits is much, much shorter than their life cycle in a system, which is deployed. And like a CEO of Yonix is out there in the field for years. And, of course, already 1995, the share of the IC market used in the was less than 1% and now it's probably less than 0.1% and even less than that. So, if the component is an RTOS or it's a vendor library, then it's our problem to put it. You don't have to worry about. And then again, you can choose among the different vendors that comply to face or the component that best matches your needs. If that is an application component, that is your problem. Unfortunately, and after having helped many customers for over 25 years and having ported our tools and libraries to over 100 different configurations. We've gained quite a bit of experience in this and here are a few takeaways. First one, no big surprise, moving to new hardware or RTOS is always an effort for many, many reasons. There is, you might have had problems with changing and units, for instance, and if your code wasn't cater for that, then you're in, then you're in a difficult situation and I'm not going to go through the long list. But if you don't have expertise in your company, then one of the things we do is we really help our customers porting components to new platform and this is typically one of the situations where people come to us. What we found also is that code that's written Ada is easier to port than coding a written in C and C plus plus both can be ported. Of course, it's just a matter of cost and we found that the cost for coding Ada is lower than the cost of porting C and C plus plus. Now, let's talk about another aspect that we're face. And most of. Don't wisely, they said, don't say much, which are the non functional requirements. Safety and security are intentionally left out outside of the scope of a face certification product process. Now, I'm going to speak in the meantime, a little bit more on security, because it's much harder than safety in software safety. We basically deal with the laws of physics. They are non adversarial. Sure, we can make mistakes and we can get the laws of physics wrong, but if we get the physics right, then requirements requirements based software development has demonstrated that we know how to make software in planes safe. Security is much harder because we deal with savvy attackers and you have to deal with those savvy attackers. And there are many out there. Unfortunately, they are adversarial and that it makes it a much harder. So let's take two existing components that you see here. And maybe they communicate an exchange data. Now. They're, they were great on a platform and the next platform and you need to pour them to the next platform. Now, their security requirements may no longer be adequate for the next platform. Do you have to redo each component? Well, fortunately not. And I'm sure you have expertise and have built expertise to be able to pour them. Here's some of the things we have developed and some of the approaches that we've we're working on. So once you've identified a security critical components and the risks, you can ensure that they're either a security hardened or you can add protection and you can add protection at the boundaries. So here are some examples of the tools and approaches we developed to do both of those things. So one thing is that to harden an existing component, like say this one, the thing. Another ball of border. You can isolate a small security critical core and rewrite it. It's got to be small. Otherwise, this is going to be an effort and, you know, something like 10, 20,000 lines of code. That you didn't need very critical and you can rewrite it using a technology called spark. That's just one example. There are others out there. Which allows you to demonstrate the absence of all runtime errors like buffer overflows and it allows you to prove that the code needs your security policies. And actually, this is the technology, which is a subset of Ada that is being used by NVIDIA and by a Japanese OEM precisely to strengthen their security and the case of the Japanese OEM to also make their code safer. You can also stress that your existing component with static analyzer with fuzzers. And again, this is easier if you have more information if the language is strongly typed like Ada, then this is easier to do. And in addition, you can add a thin layer of code between and this is what this red or violet line is supposed to mean. You can add a thin layer of code between your existing code and the interface to verify that the interaction with other components are as expected. What you can do also is you can formally describe, describe not program, you can describe the communication protocol and the format of the data that you're expected to receive and automatically generate code that's proven that ensures that the data exchange is well for. Now, let's assume we do all of this. Well, that's still not quite enough. Indeed, if attackers have access to the systems environment, they can inject false or inspect memory. In this case, what's important to do is to compile the code with hardening compilers. And this raises the bar for attackers significantly. Let me give you an example of what these hardening compilers do. For instance, memory and the stack is or parts of the stack is erased as soon as it is unused. Control loops are made more resilient to alteration of tests and data types are representing a way to make base flipping more difficult. Well, in the end, security is a matter of trade offs. And this trade off unfortunately involved managing contradictory requirements and managing contradictory requirements is a fact of everyone's life. It takes patience. It takes perseverance and requires the application of a series of good human organizational and engineering practices.