 Well, I have 10 minutes and I'm going to tell you about what dependability is. I want to explain to you what assurance is, what assurance cases are, what are standard in this called open dependability through assuredness. And then I want to explain to you what we've been doing in the real time embedded system form to actually support all of this stuff. So here's our agenda. First of all, let me just give a slide who I am. I do enterprise architecture consulting and training and do modeling consulting and training. And so my specialty has always been in modeling and spend a lot of time with people helping them figure out how to do modeling and how to set up modeling practices. So first of all, to actually tell you about assurance, what you need to understand is what assurance is not. And so people a lot of times don't understand the differences. So I put this slide together just to give you an idea of what's going on. Here you see, I want to tell you about auditing versus assurance. When you start a system up, you may gather data and that data may be available to you such that after you start the system up, you may have a fault. And you can go back to that data and actually say, well, yes, my system worked correctly or it didn't work correctly, right? That's the whole notion of auditing, okay? The whole notion of assurance is, will this system kill me if I turn it on, right? I mean, I'm being forceful on that. But that's a lot of what the systems are that are assured, right? They're trains and airplanes and insulin pumps and those kinds of things. And so what we do is we say even before you turn the system on, can I guarantee you when you turn the system on that's not gonna kill you or not gonna do something to you that's bad? And so this is where the whole world of assurance comes in and describes this. Now we can only specify certain faults and we do that ahead of time saying, these are the things that we're interested in. And there's a whole engineering practice about how to do that. There are unexpected faults that happen and I'll explain to you our best practices in terms of unspecified faults in terms of doing this. There is a history of this and way back when what we used to do is we used to take the little portion of the system that we had, the portion that would kill you, right? If it didn't go right and we removed that out of the system and we spend about 10,000 times more dollars. We model it, okay? And then we can answer questions like, things like, does this have buffer overflow if we were talking about software? Does it have these other vulnerabilities that we know? And raise your hand, Bob Martin over here, just everybody see him, okay? If you wanna know about vulnerabilities in software, there's the guy, okay? From MITRE, who, MITRE has collected all of these things and there's huge catalogs, okay, of all these kinds of things that you can look in. Well, this is expensive, right? 10,000 times more of the dollars, that's a lot of money. And so we've had to find in this time less expensive engineering techniques, okay, to actually do this. And they've come to be evolved to be called safety cases, dependability cases. And currently they're called assurance cases, right? They're basically all the same thing, just assurance cases, a more generalized version of all these different things. So there were a series of accidents that happened, okay? The thing about these accidents that really cause people to start worrying and be concerned about it were the fact that if a safety case had been well written, people could have said, could have avoided that accident. And so we know that there's those kinds of things. So there was one that happened and this was quite a while ago. But just to give you an idea of what's going on in this, okay? Basically, airplane landed, okay? The pilot pulled out the thrust on it and the thrust didn't work. Why? Because there was water on the runway and the wheels didn't engage. It hydroplained and there was something that said, the requirements in the software said, you have to get notion of the wheels going before the thrust can because you don't want to be able to do reverse thrust while you're in the air. And so this accident happened, okay? Now, it wasn't a software problem, okay? It was an actual problem of not understanding how the software and the environment worked together. So this is an interesting thing. This comes out of the sufficient evidence paper that I put down there. Bugs and code, about 3% of problems appear there. Most of the things appear when we don't understand how that interacts with the rest of the world and the environment and whatnot. So I'm gonna move on here and just tell you about, you need assurance. Now, you may not be in the safety critical world, right? But there are things you want to assure. And here we have an interesting thing out of this particular standard, which is the industry Internet Consortium. There's critical properties, the dependability properties, which we all know and love, safety, security, and resilience. And the rest of them, what are we looking for there? We're looking for trust, right? So the bottom line is we put this kind of dependability in systems. But what we're looking for is somebody to trust our systems, to get on our airplanes, to get on our trains, or to use your systems in your business, right? People have to trust your business to actually use them. Well, there's a problem. There is a huge problem between dependability and trust. And there is a thing in between there, and that's called assurance. And what assurance is, is me telling you why you should trust, if in fact I can give you these kinds of dependabilities. So if I can't prove to you somehow that if I have this set of dependabilities, it'll give you this kind of trust in the system, okay? Then you probably don't trust the system, or you may not understand how to trust the system. How do we go through actually explaining that? We do it through assurance. And assurance is this middle level. It's both social and technical, okay? The trust is purely social. The assurance is social and technical. The dependability is really technical. And so we need to actually explain this, okay? And we've come up with ways of actually doing it. It's called an assurance case. And the assurance case basically is formed like this. You have a top level assurance that says, you know, the system is safe or it does some particular claim. We have a breaking up of those claims to further subclaims. And we have to have our stakeholders agree that we've actually formed this argument correctly. That's one thing. And then, okay, we don't get off the hook. We have to actually provide evidence to show you at these leaf cases that this actually happened. That's how I can actually prove to you, okay? It proved to you that you can trust this assurance case and trust that the system is assured. So, not everybody's assurance case is the same. Here's two detention systems. One's the US Penal System and one's an Ebola quarantine system, okay? In one of them, we're willing to let people go and in another one, we're not, all right? And why actually show this? And it's an interesting thing if you think about it. What I'm trying to tell you is not every problem is the same, right? And so therefore, we can't give you a recipe how to do this. What we can give you is some kind of architectural framework so you can solve your own problem. And that's what we've attempted to do here is do that. But again, there's no recipe for you to do this. You have to actually architect this. So, we have this, ODA. We have some standards in ODA about how to do assurance architecture development. We also have how to do assurance case development, okay? And I would forward you to ODA. We also have an insurance case models. These come out of the OMG, the SACM, which is the Structured Assurance Case Model. In the ODA, we actually tied this into TOGAF. And in TOGAF, we specified what in addition you had to do besides doing TOGAF. What in addition do you have to do to do assurance? And that's all provided in the ODA standard, which you can get on that link if you get these PDFs afterwards. Real Assurance cases are huge, okay? And there's problems and we're working on how to make them consistent. And there's a lot of things, technical details we're working on there. And lots of industry examples of this. There is a mapping that we've provided into Archimate in how to do this. So there is an Archimate profile for actually how to do assurance cases. And the important thing about this is you can actually connect. We used to do assurance cases separate from architecture. Now we can actually put assurance cases directly in with architecture and do reasoning directly on them. So that's an important thing is we've provided this into the Archimate language. There's a lot of assurance case properties. There, the one I want to tell you about is the composable. Because this is where the rubber meets the road. What we'd like to do is be able to take components, derive assurance cases for each of those components. And then when we combine those components, we want to actually combine the assurance cases. And that is a tough problem, okay? This is one that's still the holy grail. And we have some things that have done in this. Usually what it means is you have to have a platform to actually guarantee certain of these assurance cases. And this is why we've spent a lot of work doing the mill standard. The mill standard is basically a platform where you can define what kind of constraints you have on that platform and the platform enforces those constraints for you. And so you can actually do some combining of these particular assurance cases. We have a lot of work in this, okay? So this is not a fledgling field. We've been working on this in the last 20 years. So lots of work in this. And the open group has a lot of work in this. If you're not familiar with all the stuff we've been doing, there's a list of all the different projects we've been working on this. Like I said, we have, if in fact you have an unspecified fault, in the ODA standard we talk about having this failure response cycle, okay, which is another way of actually handling this. And this is all about how do you get systems to heal themselves? And again, there's certain people in our area working on this particular thing. But again, we describe that in the ODA standard. Our challenges, we have challenges in standards. Basically, this is a small community but very fragmented. And we're trying to bring together this community, okay? Again, the open group is supporting that. We're trying to do a business, okay? And the business case is, build a business case. And then we're trying to get people smart on this. So what we're doing is, the first thing is creating a, we wanted to call it ASSBoc, but that didn't work, okay? For obvious reasons, so we now just call it ABoc. And so we want to gather, there's no place that you can actually go if you want to be an insurance person where all that information is gathered. It's just not in the community. So this is one of the things we're trying to do through the forum. Certainly still do the projects, develop a business case, do some assurance training and certification and Jack will tell you about the ODA 2.0 work here. Just so you know, there is Agile Assurance. And this is a book that just came out in October, which describes how to do assurance cases in Agile. So just so you know, if you're wondering if we're worried about that too, we are. Also, one of our luminaries has moved to assurance of a different kind. So this is, if you're familiar with this gentleman, he's kind of his PhD. And in the mid 90s kind of kicked all this stuff off. And again, we wish him all the luck. He's now going to be a curate in a pastorate in a church there. But anyway, we wish Tim Kelly all the best of luck. So in summary, you need assurance, and this is how we do it. Let me just tell you a quick story while I hand this over to Jack. And they can flip the slides over now. I called Dave Hornford several years ago, asked me what I was doing. And I said, well, I'm working on insurance cases. And I started to tell him all about it and whatnot. The next week, he sent me an email, said, Ed, I did my first insurance case. Now, he was not working with safety critical things. He was working with an enterprise. But like I said, these tools and techniques are not just narrowly for the critical area. There can be used universally any place you need assurance. And again, most enterprises need assurance. So I just welcome you to come and look at the ODA and see what we have there for you.