 Good afternoon. Second presentation by Jean-Pierre Rosen. This morning, Jean-Pierre gave an overview of EDA, the language in general terms. And now we'll specifically focus on aspects of EDA for safety critical software and the special version of EDA's part, so that can help you. Thank you. So this is somewhat, especially just a short talk because I thought that many people have heard the name safety critical software, but you are conscious of what it means, and also why this is certainly the kind of software where EDA is proportionally most used, so it is also a way to stress some of the benefits of EDA. So what does it mean, safety critical? Well, in general, when a failure of the software could cause loss of human life. So of course, you have all the transportation, the planes, the trains, cars, which is becoming more and more important, not only medical devices, but one of the most famous failure of software, one of the first software that people was a medical device with a bug in the user interface. And also, you have things like diving computers. If you think about it, a bug in the diving computers can cause loss of human life. On the other hand, some companies tend to spread the word that it's normal to have bugs. You know, those software are so complicated, it's not possible to avoid having bugs. Well, OK, if you have a problem, hit Control-Alt-Dell, and then you reboot, and everything will be fine, and so on. Well, it's simply not acceptable for safety critical software, of course. If you are in a plane, you wouldn't like to have the computers rebooting in the middle of the flight. It happens sometimes, but there are also safety features to make sure that it doesn't cause too much harm. So to show you the stakes of safety critical software, here is an example. Would you borrow a card knowing it has a defect that can cause an accident with a probability of once in every 3,000 years? Presumably, yes. I mean, each time you cross the street, you're likely to take more chances than that, OK? If you are a car maker who produced 1 million vehicles, 1 million vehicles is a good success. It's not exceptional. I think the most produced car was 34 million or something like that, OK? You make the division. It means one major accident every day. That's simply unacceptable, OK? So when it comes to safety critical, it's 100%, not 99.99, whatever, how many nines you want. Everything must be absolutely safe. So when you're in the business of safety critical software, how do you make sure if you bought a train, if you bought a plane, that this is safe? This is done through a process called certification. Every safety critical software has to be certified. What does it mean? It is that there is an official body, the certifier. It must be an independent body. Of course, it doesn't belong to the makers of the device. And it's in charge of refining the conformity to all safety rules and safety standards. You have some very famous safety standards. Maybe you heard about that or not. In airplanes, for example, it's called DL178, with various versions. B is the older one. It's now version C. Those kind of standards define various levels of consequences in case of problem. The most critical one is called level A, and that's if there is a bug, you crash the plane. It goes down to level E, which is like in-flight entertainment if it breaks. It has no impact of safety. People are not happy, but you have no impact on safety. Those standards are intended to grade from the safety aspect. There might be other aspects, but these one are just about safety. So these certification body, I named some of them, for the train in France, there is certifier. Fair is railway. CE-84 airplane in the US, you have the federal aviation administration, and so on. And these people eventually will sign a document saying, OK, this plane can fly with 400 people aboard. So guess what? They're not easy to convince. So what's important with this safety critical software is that having the software right is not enough. You must be able to prove that the software is right because they are difficult to convince if they sign your listing. They take a terrible responsibility, and so they must absolutely be certain that everything is correct. So you have a state of mind where, for example, testing proves nothing. Testing can prove that there is bug. But tests never prove that there is no bug. So other methods, other way of doing things are necessary. When you're talking about safety critical systems, you have two important aspects, and they are generally well separated. The first one is called the intent, what you want to do. So this is a high level requirement, and there are people in charge of making sure that the requirements are correct, that what you want to do is what should be done. And there is a second level which is to make sure that the code implements the intent correctly. So this requires, of course, first traceability of code to design, but many other aspects. So it's always about convincing the certifier. You need to show the guy that this is exactly what was expected. So for example, readability is very important. If you have a strange, impossible to understand language, the certifier will not read it. He will not try. He'll say, OK, I don't understand. Get back. Language feature proves. I just invented that term. It's not an official term. But I'll show you another slide, what I mean by that. When you have to prove that something works, if it's a language rule, then the certifier obviously will know that it's true. So if you have a language where you can put the requirements into the language, then you are certain that they will be met. Tests are more, they are still needed, of course. And the language can help in writing tests by making sure what needs to be tested and what is obvious. And the best thing if you can have formal proofs. And of course, formal proofs need specialized language for that kind of development. Now I'll show you a small picture to explain the main difference, especially for safety-critical software, between the goals of EDA and the goals of C. Don't misunderstand me. C is an excellent language. It's a best low-level language. EDA is a high-level language. A good language is a language that fits its goals, its requirements. And what I want to show you now is a difference in requirements for the language. Here I represent machine states. So it's very well-defined, squared, that all the states that can be achieved, all the combinations of the 32 bits of the memory of the machine. Somewhere inside what I call the correct states, these are the states that can be attained through a correct execution of your program. Of course, they have to be inside the machine states, otherwise you cannot do what you want to do. Somewhere in the middle, you have language states. These are the states that can be reached that are allowed by the language rules. It's like that. They must include the correct states, otherwise your language does not allow you to write the program. And they cannot be equal to the correct states, because it would be equivalent to a full formal proof of the program. Now, the requirement for C was to be a portable assembly language, to give access to everything the machine can do. So C tends to extend the language states to cover as much as possible from the machine states. EDA tends to allow only correct execution, to reduce the language state as tight as possible around the correct states. So that's what the difference between the philosophy of the two language. So I repeat for those who are not this morning some features of EDA that are important as far as safety is concerned, readability, the very strong typing system that does not allow you to do something that makes no sense, like assigning a length to a time or something like that. Very few use of pointers. There are many things that require pointers in other languages that do not require a pointer in EDA that's a relief. And programming by contract, so I'll give you some example where you can add conditions that are checkable at runtime. So a slide to show you what I intended by that term language feature proof. Imagine you have to count things that come in pairs. So you know that there will be at most 1,000. The count is always even. And of course, since you count, it cannot be negative. So some high level requirement is like that. In EDA, you can define a type per counter is range 0 to 1,000 with a certain predicate that ensures that per counter mode 2 is always equal to 0. Now, when the certifier sees that, he knows that the requirement is met. You don't have to check all the uses of all variables of that type to make sure that the requirements are met. That gives confidence. I have another classical example. You have a point that must be within a certain radius, a radius of 1. This is just an example of something that's called a type invariant where you guarantee that some properties is always true for an abstract data type, a type defined in a package. So you can say that a certain function is always true for a certain type. And that function that makes sure that it is within the radius. So once again, the invariant is part of the definition of the type. Therefore, you are certain that it will always be true. If it's not, it's checked at runtime. It's not exactly like a proof. A proof, you make sure it doesn't happen. Here, you just check it. So Spark is formally another language, but it's practically a subset of Ada with even more possibilities for accessions and various statements. And since it's a strict subset of Ada, Spark is a different language that can be compiled with an Ada compiler. So formally a different language, but still compatible with Ada. With restrictions, of course, because when you have to do very critical software, you cannot allow anything. So the mantra of the Spark peak poll is correctness by construction. You want the thing to be designed and correct right from the start. And it has mainly checked that the dynamic checks cannot fail to prove statically, that means that compile time, that all required features are met. So in short, if you want, Ada checks Spark proves. So Ada at runtime, make sure that it's true. Spark proves that it cannot be false. However, this implies many restrictions, because not everything can be proven easily. And the good news is that the Spark environment, you have a free implementation available from Ada core and all alternatives. Well, they're working together for that. So you can experiment with Spark and see how it works, including the proof maker. There is a famous example. It's an Ironside project. It's a DNS server that has been formally proven invulnerable to the many of problems and, say, security concern that plague other servers. So yes, there is a safe DNS server. Nice, isn't it? More information on that link. And while you type Ironside, Spark, and you'll have all the information. One more slide, because I think most of you do not write safety-critical software. Ada, Spark, were designed for safety-critical software. However, it's nice if casual software does not fail either. If you can be protected from buffer overflows, arithmetic overflows, memory leaks, and all the other trouble, that's good. So you have free tools. You can use them with Ada. Your casual software can benefit from the same level of safety than the tool that are available for writing safety-critical software. So you can benefit from those high-level tools just for yours. Nice not to have too many bugs. Questions? Mm-hmm. Yeah? What's the rate of development with Ada? Do you normally have to invest much more time ensuring that your constructs are safe and assertive? How does that compare relative to the myth? Is it more costly to develop safety-critical software with Ada? Certainly not. Because precisely, I keep my comparison with C. The goal of C is to allow everything. Therefore, you can prove nothing because everything is allowed. The more restrictive the language, the easier it is to prove that it fits the requirements. That's really the other way around. Yes? That's a good question. Formerly, a tool used with level A software, Duo 178 level A software, is supposed to be itself validated at level A, with the constraints of level A. That cannot be achieved with a compiler. So there are some other constraints. For example, in aviation, the generated code is read by hand and compared line by line with the source. You have people who are paid to read assembly on one side, Ada on the other side, and match line by line. You can certainly think that human being is not likely to be more reliable than an automatic tool. That's true. But experience shows that people do not make the same kind of mistake as automatic tool. So having a different view can be useful. But each time the code is generated, certifying a NEDA compiler is much too complicated for the requirements of level A. Level A, you are allowed almost nothing. Well, assignment is allowed. But I mean, everything where there is a concern you just have loops if an assignment. I mean, it's very, very constrained. Yes, exactly. But then the difficulty is on top at level C. Yes? Yes. It's something that's being debated. OK? For safety reasons, I don't think we are ready yet to give up tests, OK? Even when proven, people will feel better with the tests, certainly. But yes. No, the question is who will sign the paper saying, OK, tests are no more required. Nobody will accept to sign that. We're running out of time, so. OK. Well, I think we can.