Keynote: The Pursuit of Zero-Defect Development

[MUSIC PLAYING]

Every day, our employees work to deliver programs, big and small, to support our customers from the depths of the ocean to the far reaches of space. Working with our partners, suppliers, and trade unions, we protect those who protect us.

Innovation is central to our business, and we continue to invest in advanced technologies, state of the art facilities, and our employees across the world to keep our customers ahead of threats and find new ways to deliver equipment and services more quickly and efficiently.

We're creating sustainable solutions, from electric power to synthetic environments, and supporting our communities, championing STEM education and recruiting thousands of apprentices, graduates, and professionals, securing the long-term future of our company.

Hello, everyone. I know it's been said before, but it's great to see everyone here in person again. I don't know about you, but I've really missed these events and the value they bring in connecting with our industry peers and meeting people face-to-face and building our networks. It's a really powerful event. And I'm very proud to have been asked by MathWorks to do this keynote speech, especially in our expo comeback year.

I feel, as a little reward for doing the keynote speech, I should get my own personal Simulink feature request. So I've sprung that on MathWorks. So I'll get to that later. So let me introduce myself. I'm Jason Casey, and I am a chief engineer at BAE Systems Electronic Systems. So we operate out of sunny Rochester in Kent. It's a beautiful city, a wonderful place to work.

And as has been said, my area of expertise is safety critical software development. And I've been using MATLAB and Simulink for over 20 years. People that know me would also tell you I'm a big fan of retro arcade games, although back in my day, they were just called arcade games. The reason being is I started programming when I was 11 years old.

And I used to churn out thousands of lines of 6502 assembler, trying to recreate all those arcade games in my home. And actually, those games make really good training exercises now. And one of the fun things I get to do is, every year, I get to recreate Pac-Man with my software apprentices, which is great fun. There will no doubt be a Simulink version of that coming soon, so keep your eyes peeled for that.

So just want to tell you a bit about BAE Systems. Now, BAE Systems are a global engineering company. And we're quite hard to describe. We're that big. So I actually went on our-- actually went on our website to see what they say about who BAE Systems is. So I'm just going to read that to you. It says, "We produce the world's most advanced technology-led defense, aerospace, and security solutions. We employ a highly skilled workforce of more than 93,000 people in around 40 countries. We develop, engineer, manufacture, and support products and systems to deliver commercial and military capability, protect national security, and people."

And that's a fairly adequate description of BAE Systems. But I think what I would add to that is that we are an engineering company full of talented engineers passionate about what they do, motivated to continually do it better, and always looking to innovate. And I think that's where the use of the MathWorks tools really comes in for us.

I just want to focus in on the UK part of BAE Systems for a little bit. So we're broken up into a series of companies in the UK. And I won't go through them all. But we have air, for example. We have a long history of developing aircraft, such as Eurofighter Typhoon. We have maritime naval ships who, again, have a huge, long tradition of shipbuilding, including the brand new Type 26 they're working on. Maritime submarines. Again, a rich history of submarine-building with the Astute and the soon to be Dreadnought submarine.

But Electronic Systems, where I work, we don't make platforms like that. We actually just make the electronic systems that reside in those platforms to give them the functionality. And as such, we don't really fit in with the rest of the UK companies, which is why Electronic Systems is actually part of BAE Systems, Inc. in the US, who do very similar things to us. They develop electronic systems for commercial and military applications in their market.

So sort of tell you a bit about some of the products that we make out of Rochester. So first, we make Stryker helmet. Stryker helmet is a tract-augmented reality helmet. You get to look and target your enemies. Mark Bowman, our chief test pilot, he once said if you're wearing a Stryker helmet, you're 100% guaranteed to get home. And he then qualified that by saying unless you're outnumbered 3 to 1, in which case he would reduce that to about 80%. But I think he quite fancies himself in a dogfight.

And you might have heard in the news recently, we're developing Stryker II now for Eurofighter Typhoon. And that will be the world's most advanced helmet ever made. I'm really looking forward to seeing it. We're also the world leader in head-up displays. We've been making head-up displays for aircraft for decades. And we've recently transitioned from CRT-based technology to our patented waveguide technology in our new LiteHUD product, which is, again, an incredible piece of equipment.

And we're also the world leaders in active interceptor technology, sometimes called active sticks. They give static and dynamic cues to the pilots to indicate aerodynamic limits or just to increase cockpit awareness. And we also make safety critical control systems, so things such as the Boeing 777 flight control computer. We make that. Eurofighter Typhoon flight control computer, we make that too. And we make flight controls for a large number of other platforms too.

And it's no surprise that we use MATLAB and Simulink in all of our products these days. And personally, I've been involved in pretty much every product that we make. And what we've seen over the years is that there's been a significant increase in complexity provided by them. And what that leads to is the sizes of the developments are really growing. And you get a real knock-on effect to the size of the software that's involved.

And particularly when this is manually developed, we all know what that leads to. And that's bugs, or as we like to call them, defects. And they're becoming harder to detect and fix the later in the life cycle that you get. And with safety critical software, a single defect can lead to a catastrophic failure. And yes, we have safe development guidelines, such as DO-178C and DO-331. But those don't help you eliminate defects. They just help you to prove that you've found them all by adopting good development process.

So humans make mistakes. And so in order to reduce defects in our products, it makes sense to adopt a strategy whereby you automate as much of the life cycle as possible. And that's where model-based engineering can help us. So I think what helps is if I take you on a bit of a journey that we've had on some of our products with model-based engineering to show you how our usage has evolved over the years.

So my earliest recollection of model-based engineering is when we were developing the active stick and throttle for the F-35 Lightning II. And this was just over 20 years ago. And it was a unique development, a world's first for cockpit controls, and incredibly complex. The software loops for this were running over 10 kilohertz.

And only a platform like F-35 can really demand a product that is due to the unique way that the flight controllers themselves had to be reconfigured during flight to behave more like a helicopter when the F-35 went into its hover mode. Now, this product wouldn't be possible without Simulink. Our systems engineers did a tremendous job of modeling the complex control laws required to do this.

And through simulation, they were able to then define what our software requirements would be. There was no embedded coder back 20 years ago. So after they defined the software requirements, we went into a traditional manual development process for the software. And of course, that led to a lot of defects.

And I've got vivid memories of debugging in dark labs till 2 o'clock in the morning just lit by the glow of monitors. It's something I'm sure resonates with quite a few of you here. But we got that product working. It's absolutely fantastic. I don't know if you've ever seen F-35 fly, but it's an incredible aircraft, and I didn't enjoy seeing it today.

This led to a little bit of a product line for us. So we then moved on to developing the active cyclic and collective for the H-60 MEDEVAC helicopter and consequently the CH-53K King Stallion helicopter. And again, active technology is very complicated. And this was a very different environment.

And again, our systems engineers had to completely remodel this for these new aircraft types. But helicopters, the workload for pilots is enormous. And this product really, really increases safety. So it really makes sense to develop for that. But again, it was a manual software development process. Very painful trying to find all of those defects.

We also then looked into a low-cost solution of active interceptors for the Gulfstream business jet. And this is a dual seat application. And it vastly increases safety in the cockpit. And Gulfstream are big proponents of safety. They were one of the first, for example, to put head-up displays in their cockpits as standard. One of ours, I might add.

And again, this was a redesigned electronics unit, redesigned motors and gearboxes for this product. So again, our systems engineers had to model this in Simulink. But by now, we were starting to see defects pushing towards the left of the life cycle and start to reduce, which is great.

We then also developed the active parallel actuator system for the CH-47 Chinook. Now, this is a much more mechanical system because this system actually back drives the mechanics already within the helicopter. And it's interesting that as we were now using MATLAB and Simulink more, our systems engineers, they had to get to grips with this product as well.

So we had to start using Speedgoat in our labs to allow them to refine those control laws with the mechanics in the labs but without having to wait for the software builds to come along for them to be able to test. So Speedgoat is very, very powerful in that application.

Another interesting development we did was for Advanced Hawk. Now, this is a-- this is a situation where we were taking the Hawk T2 aircraft and developing a stability augmentation system to give it extra aerodynamic capability. And what we were able to do on this product was we took the existing autopilot system that had been developed for the Hawk, we removed the functionality from that, and replaced it with a full Simulink implementation.

By now, embedded code was available. Code Inspector was available. So we were able to generate the code for this, automatically review the code with Code Inspector, and it just works. And it's a real testament to what you can start to do with MATLAB and Simulink.

Something else we developed was a Fixed Pipeline OpenGL implementation for 2D graphics for head-down displays. And again, we implemented this using HDL Coder for embedding within an FPGA, eliminating the need for us to go out and buy expensive graphics solutions when we could just put an FPGA in our products. So that was quite impressive as well.

So I think what you can see here is that we were really starting to increase the usage of MATLAB and Simulink in our developments. And but not only that, at the same time, MathWorks were very much developing the product specifically around safety critical workflows as well.

And we were part of that. We would go out to Boston, and we would join in the MathWorks Advisory Board. And we would drive that functionality into the toolset. We would say exactly what we needed. MathWorks would listen and really take heed of that. And if you're-- and if you get invited to the Advisory Board and you want to drive the tool yourself, I fully recommend it.

Now, I think what would help as well is to understand the size of these code developments that we're making. Some of those products that I've just been talking about, they go from 30,000 lines of code to 150,000 lines of code. And our modern developments are half a million lines of code. And they just-- sometimes they're just numbers. You're just like, well, half a million lines of code. Can't be that bad, can it?

And we don't really print out code anymore to get a feel for how much that is. But there is this very famous picture that I'll show you. So this is-- if you didn't know, this is the famous Margaret Hamilton, an amazing engineer. She and her team developed the command and lunar module control software for the Apollo missions. And this famously is her standing next to the code listings of that project. And that is about 150,000 lines of code.

So you can imagine, if you are handwriting that code, just quite how many defects you're going to get in there. But now, imagine that stack of listings three times that size. And you start to realize that if you're not automating your code generation and automatically reviewing that with Code Inspector, then the prospect of defects is very, very high. Interesting thing about Margaret Hamilton-- she is an amazing woman. You should look her up afterwards.

Software engineering didn't exist before Margaret Hamilton. Software development wasn't even recognized as engineering. And she fought for that to be recognized. And she actually coined the phrase software engineer. So it wouldn't have existed if it wasn't for her. Amazing woman. MathWorks, if you're ever invited to one of her events, please invite me. I'd love to meet her. She's incredible.

Right. I want to show you this slide. Now, my now engineering director came along and delivered the 2015 expo keynote and laid out this strategy for us all. The blue areas that you can see on here are where we want to fully automate parts of our process.

The way it starts is with textual requirements. And what we wanted to do was, from those textual requirements, textual requirements, validate the textual requirements by systems modeling. And then we would take that systems model and basically make it become a software model.

Now, this wasn't particularly radical. If we look at DO-331, for example, which is one of the model-based guidelines that we have to adhere to, it's model-based example number 5. It's you start with your requirements. You have a design model that spans the systems engineering and the software engineering life cycles. And you end up at source code. So that wasn't particularly radical at all.

But why textual requirements? I know there's a lot of people pushing for model-based requirements. Why textual requirements? Well, textual requirements we consider to be part of the intellectual property of the product itself. It's more about telling you about why you're doing things, not what it's doing. I think to make my point, let me just show you some Simulink, if it comes up.

So here's some Simulink. It's actually a bit bright. Let me let me just fix that. Ah. Dark mode. MathWorks. How hard can it be, right?

[APPLAUSE]

So that is my pre-feature request, please. Where's Sam? Sam. So let's look at this-- let's look at this Simulink. It's easy to see what it's doing. Simulink makes that incredibly easy to see what it's doing. You've got some inputs on one side. You've got some output on the other-- outputs on the other. There's some maths functions going on. We can see we've got some state flow going on there and a bit of logic on the back end. Easy to see what's happening, but not why.

And you probably wouldn't have guessed, but this is actually the yaw controller from Margaret Hamilton's Lunar Lander software, lovingly recreated by MathWorks. You can actually go and download this from the MATLAB central file exchange, if you want. That's a really good example of an embedded control system. But I think it makes the point, you can't determine exactly what it's doing without the why.

And at the same time that we were defining this strategy, of course MathWorks had been working very, very hard on a full DO-178C compliant workflow with qualified code generation. And you can download this from the MathWorks website. It's freely available to everyone. They produced a number of quantifiable tools. I'm not going to go through them all.

But the important ones are Simulink Test, whereby you can test against your requirements for your model, Simulink Coverage, so you can measure what coverage of the model you got from those tests, and Code Inspector, of course, is really important because Code Inspector will review the code generated by Embedded Coder for you.

Now, I'll go back to this slide again. So we were about to embark on a major commercial flight control computer development. And our customer was very mature in their use of Simulink. And they were producing their Simulink models to very good standards, very consistent modeling. And they also had textual requirements. So it fitted very well in with the strategy that we were trying to adopt.

And they came to us, and they said, here's our model. We'd like you to turn this into safety critical embedded code in this aircraft, please. And that's what we do. That's absolutely fine. So our engineers looked at this, and they said, actually, if we use MATLAB, we think we can do that conversion from the system model to the software model automatically.

And they did. So let me just show you now what an enhanced version of this workflow looks like. What we have now is, again, our textual requirements validated by the system model. But now, we are completely automating the generation of the software model. Then we're automatically generating the code, automatically reviewing the code. We compile it down to the target. And we're even automating some of those tests as well.

For this development, we practically automated the entire safety critical software life cycle. An incredible achievement. Something that's only possible I think with the power of MATLAB. Now, I'm sure you'd love to see how we do that. Have I got-- all right. I'll tell you.

How do we automate a software model from a systems model? Well, there's a number of steps that you have to go through. The first is, as I've said, you have to model that systems model to a set of really good, I call, golden standards. But then after that, you do have to apply some software modeling standards because the output from this process will have to be reviewed. And that's things like naming conventions, element display options, such as dimensions, initial conditions, that kind of thing.

But then you also have to map all of those inputs and outputs coming from your system model. They have to actually now interact with your platform. So we have to map everything we've got with Simulink signal objects down to real-world IO. It doesn't matter whether that's discrete, analog, actuation, comms links, valves. You can do it all.

But then what's really important is that resulting software model must be compatible with Code Inspector. Remember that stack of listings? Three times as high as that. If you haven't got a Code Inspector compatible model, someone has to go through and make sure that code meets your model functionality. No one wants to do that. Thankfully, Code Inspector does it for us.

That systems model, of course, wasn't created with cogeneration in mind. So we have to create some configuration sets that will generate efficient code from that software model. And any tests at that system level will also have to be automatically migrated down to the software model because we have to run those on the target. And finally, any requirements traceability up to our textural requirements from the systems model, we automatically translate those down to the software model as well. And that's it. That's all you have to do. It's great.

So we did that. And we basically produced a safety critical control system. I think this one was about 400,000 lines of code with zero defects, which is what we really all want. But where do we go from here? Well, BAE Systems is developing some incredible platforms at the moment. We're creating Tempest. We're creating Dreadnought. And we're working all over the UK on this.

And I couldn't be more proud of how our engineers are embracing this new workflow, this new way of working that we're doing. They're all doing an incredible job. We've got guys at Rochester, Warton, Barrow. Incredible engineers. The complexity now in these systems is far greater than ever before. These are complex systems of systems. And it's no surprise that MathWorks is just going to be at the core of absolutely everything.

But I think one of the things that really helps us in the UK is we have a MathWorks UK community. In fact, we had a meeting yesterday. And we get together. All the sites in the UK, we come together, and we discuss, what are the best processes that we could be following now? What are the new tool developments that we can be adopting? What are the community initiatives that we can be doing in our own sites to aid the learning of what we're doing with the MathWorks toolset?

And that's fully supported by MathWorks as well. So if you have the opportunity to do that in your own organizations, please absolutely take it. It's absolutely fantastic. And so what the future? We've already heard Rich talk in his presentation earlier about AI, right? AI and large language models have come along like a juggernaut this year. And they're just unstoppable.

And yes, we've got this workflow now. And it is an incredible workflow. But can we do more? Well, what we do have is, possibly in the future, the ability to bring these large language models into our organizations and train them on the decades of data that we've got. And we've got a lot. And I think whilst some of those non-automated areas of our workflow probably aren't possible to fully automate, I think we can definitely make some inroads into those.

And that's an area where certainly I think BASE Systems will be investing. And I know MathWorks are investing as well. So in the future, I think that's where we'll be going. If you see me around today and you want to have a chat about any of this, about safety critical software development or even just the best tactics for Pac-Man, then let me know. Thanks, everyone.

[APPLAUSE]