The Impact of Model-Based Design on Controls—Today and in the Future
Jack Little, CEO and cofounder of MathWorks, discusses the rise of Model-Based Design, its impact on control engineering, and its relationship to the technology trends that will transform education and research in the future.
This presentation was recorded at the 19th World Congress of the International Federation of Automatic Control, (IFAC 2014) in Cape Town, South Africa on August 27, 2014.
Published: 4 Aug 2021
Hello, everybody. I'd like to talk about the rise of a process called Model-Based Design and its impact on control engineering. It's a great time to be a controls engineer, turns out. The world has more things to control than it's ever had in the past. There are lower cost and more powerful embedded processors that you could use for more advanced control strategies. Also, the software tools that accelerate what you do are more powerful than they've ever been before. This is extending the reach of control engineering and control theory increasing the impact of all of us in the room that we can make on the world. Basically, the world is coming towards us as control engineers.
The MathWorks makes tools for control engineers. And as such, we're involved heavily in all sorts of different industries. Aerospace, automotive, consumer products. We get to see how control is being used in all these different industries. And I'd like to share with you some of the things that we see going on in the industry this evening. And also talk about what some of the good things we think are coming to the education area based on what we see. OK.
So I want share with you a key idea here of my talk. But as a company, we have two basic software-- pieces of software. Software families, platforms. It's the MATLAB and the Simulink. And you all know MATLAB. How many people here use MATLAB? OK. Lots of hands. OK. MATLAB really came out of people in this room. And the controls and the educational community. MATLAB originated in universities and was first picked up in the controls area at the university level in education and then spread to industry. OK.
Now what's interesting is Simulink-- for MATLAB, we call technical computing in terms of what it does. In the Model-Based Design area, Simulink oddly worked in the reverse. It really was driven by industry. Industry kept on saying here's these things we really need, we really want this. We want this. And we worked with industry over really a period of about 15 years trying to respond to the needs that industry had. And it's actually been a little slow moving back to education. So it's kind of odd our product families sort of each come from two different areas. So I want to talk a bit about Model-Based Design on the Simulink side and what I see as opportunities for education here.
So I have a premise here and a suggestion for the future. My assertion here is that multi-domain modeling and Model-Based Design have already transformed how complex systems are developed in the industry. I would like to share that with you. And really, my other part of my key idea that I want to share tonight is coupled with technical trends that are going on, they really have a big opportunity to transform education and research in control systems. The same way that the MATLAB environment, the tech computing, transformed how things were done 20 years ago. And I think there's a big opportunity, I'd like to talk about that.
The outline of my talk-- I'm going to start by talking about some innovation megatrends from the past 10 or so years. Ones that really drove Model-Based Design and industry. Industry ran into some trouble. Things that there were issues that ran into there. And the solution arose in the form of Model-Based Design. And I want to talk about that. And then I'd like to share with you the impact it's had on industry and some insights based upon industry learnings. And then finally, I'd like to suggest what the future impacts in industry and education could be. And leave you with some take-home ideas at the end.
OK. So I'm going to start by talking about what I call technology innovation megatrends. These are big megatrends that drive the world. These are things that businesses come into being, whole industries come into being, around these megatrends. So what's a megatrend? Well the US National Academy of Engineering made it easy. They have a list of the 20th century's greatest engineering achievements. And here's the top 15. And it's amazing stuff.
I mean, look at this. Electrification, the automobile, electronics, computers, telephones, spacecraft. These all happened in the 20th century. Basically in the 19th and 18th century, science made fundamental discoveries in biology, and chemistry, and physics. But in the 20th century, the engineers turned these into amazing set of things that affect all of us in this room. 100 years ago, we'd all be riding horses. The Model T first came off the production line about 100 years ago. Prior to that, cars weren't available widely.
And incredible transformation to where we are here coming from all over the world. Lighting, and air conditioning, computers, and all that. It's really, really quite remarkable. If I could add one more to this list, of course-- well actually, one other thing. Look at the internet. The internet, of course, which is a more modern thing that we all think is such a huge innovation the National Academy of Engineering only gives that 13th on the list of things there. Just to put it all in context. If I could add one more, of course, I'd add automatic control theory to this list, but I'm biased.
OK. So truly, these things transformed the world 100 years ago from this to where we are today. It's just, it's really a technical marvel if you sit back and think about these changes that happen in the world. If you have any friends that are economists, they'll tell you these are important too to economies and standard of living and quality of life. This is a chart that shows the growth in gross domestic product per person, which is proportional to standards of living. Similar charts like this in most any developed country. And it's increased a factor of 8x over this period, which is extraordinary. OK.
The leisure time we have, the fact that we're not out plowing fields and things like that. And so, this is important. People care about this. And you could chart these things for companies, you can chart them for industries, you can chart them for individuals in some sense. And the point is is that innovation drives the economy. That's what economists will tell you. So these trends are important to focus on for people in industry as well as education.
There are some people who think that in 1947, the largest innovation megatrend ever was the invention of the transistor. That's the fundamental enabling of the digital age. IEEE Spectrum, recent issue had actually an assertion along these lines. OK. There were innovation megatrends in 1984 that allowed MathWorks to get started as a company. We took advantage of one of these, and that's why I'm standing here today.
This was how, when I was at Stanford studying control, this is how I did technical computing. Believe it or not. This was state of the art computing at Stanford University in 1980. Punching cards to solve optimal control problems. OK. And that's how I learned optimal control. At the time, we had a well-defined set of mathematics we wanted to do.
Ranging from linear algebra, differential equations, there's state space form, and linear, the transfer function form. Also important were discrete time models. State-space difference equations, transfer functions, all the different names they're called in different areas. The FF-- fast Fourier transform. So a lot of these computational tools were new and understood, but this is what we were using. And what came along? The big technology megatrend is shown by this. A young Bill Gates and Steve Jobs. And really the birth of personal computing.
You can see in this clipping from the newspaper at the time that there are a million PCs sold that year. Today there's over 300 million sold every year. So if in this room full of about this many people, if you divide by 300, maybe there would be four of you that would have used a PC in the room. This was an early stage thing that not many people were using.
And so the megatrend that MathWorks took advantage of is low cost personal computers. The fact that there was now chips that supported the type of calculations that were built right into the chip that we needed to do. The whole birth of interactive software, because prior to that, it was Fortran. Birth of C and Unix helped out. And then of course bit-mapped graphics, windows systems, mouse, and so forth.
And that led to creating MATLAB written in the C language for a bunch of personal computers there. And actually, here's the brochure for the first version of MATLAB in 1984. And it supported all these golden equations of control system engineering that were so important. It really focused on those types of things.
This is one of my favorite examples of the power of MATLAB. This eight lines of code here solves the linear quadratic regular control solution. The infinite time solution there. And this was-- there was about-- there were several thousand lines of Fortran code that were in a PhD thesis in 1970 at Stanford that sort of first provided a code to do this. So in 1970, PhD thesis at Stanford was reduced to eight lines in MATLAB code about 15 years later. And it shows the power-- the power of MATLAB is that these are all matrices. You could work in a matrix form, which is a natural way to express it. So this is one of my favorite examples of why MATLAB caught on in the controls community. Because this basic expressiveness of the matrix types of problems.
Here's the performance specs for a PC of that era. At the bottom, it did 17,000 floating point operations per second. You can see it's 256K memory and so forth. But then a wonderful thing happened that few people appreciate the extent of. Today's computer has increased obviously by leaps and bounds in terms of performance. But if you divide those two to find out how much it is, they're extraordinary numbers.
The memory is 60,000 times more. The most impressive one though is floating point operations per second at the bottom. That's over three million times more than those first PCs. And that's truly extraordinary and enables a lot of the advanced controls calculation, enables you to do amazing things in terms of software design and simulation and modeling that wasn't possible back then. And has been great for tools and great for embedded implementations. OK.
So That's what an innovation megatrend is. I'd now like to talk about some of the trends in the last, say, 10 or so years. Trying to set the clock back a bit and talk about what led to Model-Based Design. And so want to roll it back and talk about things that the world had. And really a big trend in the last 10 years is the beginnings of software in everything. Software used to be on desktop computers. But over the last 10 or so years, we're starting to get software in all sorts of things. And also not just any software. Also more math, more algorithms, things that have mathematics enabled by that. And there's both systems on a chip, there is systems of systems, where they're more complex and put together into larger systems.
This chart illustrates the extent of how much this is happening. The curve at the bottom is the growth in processors that are put into standard PCs, laptops and so forth. And while that's growing quickly, it's clearly swamped by the growth of embedded processors. And you just look at this. And you say is the world going to need more software and embedded systems? Is the world going to need more controls, more algorithms? Absolutely. And this is just an amazing megatrend that was facing industry very clearly, suddenly about 10 years ago.
And it really is transforming. Here's a picture of a car maybe around 1980, a little before that. And I think the only transistor in the car was in the radio. No airbags, no anti-lock brakes. And that's over the past 10 years has transformed to today's automobile, where you have 40, 50 microprocessors, maybe even more. There's a set for doing power train, there's a set for doing chassis control, there's a set for safety systems, which, and then there's a set for comfort and convenience. Most people these days are buying cars based upon all these software features. The basic car's pretty standard. But it's the software that differentiates. And so enormous transformation.
Along the way, industry ran into some trouble though. Wasn't so easy to scale up like that. Here's one element of the trouble. Manual coding in order to write all that software. Here's a chart of the development process in a automotive company. And the part in the circle was the coding part. And this was time consuming, expensive. Put in defects. And they were interested in reducing that. Or perhaps even eliminating that.
Another problem was recoding. When you move to a different platform, you'd have to start over again in the specs in the design for these different platforms. And there's lots of different hardware platforms that people use. Another problem, physical testing. You have to build these hardware test setups. Happens late in the process. It's very expensive to do. This chart shows the cost to correct bugs. And you can see during testing and integration, they are 150 times more costly to correct than if you get them earlier in the design phase.
There was a traditional development process that industry used. It started with research and requirements. They wrote paper specifications. That was turned into design implementation, and then finally, it was all integrated and tested. It actually was worse than that because there were several different groups often that went into some final system.
The mechanical design, the algorithm, the coding, it all went together. And problems arose because, in fact, the paper specifications were used to pass these on. And also, so they were buried, and there was a different set of people that wrote the specs and that did the coding in the C. And there were barriers between their disciplines. And this led to no end of problems. The requirements documents are always difficult to read. Paper specs are always incomplete, out of date, easy to misinterpret. The physical prototypes were very expensive to do. Manual coding, I already talked about that. And the traditional testing found the design issues late, late, late in the game there. So tons of different issues.
There was more trouble. In chipping some of these systems, there started to be fairly large recalls. If you're increasing the algorithmic complexity and the software, starts to be recalls. And this is-- industry is starting to be-- it was very worried about these types of things. And then finally, there's always the possibility of big trouble. And I have something, a design I want to share with you that I think every control engineer ought to see before they go out there and practice. This is sort of the most famous failure in control systems, which is the maiden flight of the Ariane 5. How many people have seen this video? A few. OK. Ariane 5 was a new vehicle. There was an Ariane 4 before it, and this was the first flight of the 5 Series. And it-- well I'll tell you what, let me show you the video of the first flight. And then I'll talk about what happened during it. This is about 20 seconds.
You can hear the control room. It's pretty quiet in there, isn't it? What happened there is they took the controls package, which was hardware and software, from the Ariane 4, and they slapped it on the Ariane 5. Ariane 5 was a bigger launch vehicle though. And what happened is during the flight, there were larger-- the nozzle gimbals at the bottom. And there were larger extensions because of the bigger system. And that caused there to be the larger numbers floating around in the control system. And they overflowed the fixed point registers on the PC, on the computer, which they were designed to hold.
And so it was a controls failure. It had to do with an overflow. And really what it was a failure is the picture I showed you before in the process. If there had been a process they could have found this in testing, it's just too complicated to test all these parts in all the right ways with the right prototypes and all that. And they just couldn't get all that stuff organized. This was about a half a million launch vehicle that was lost here. And it's a great example of what you don't want to see if you're a control engineer. And so it's a very famous thing, a good thing for controls people to see.
Solutions. So solutions started to arise to this. And mainly there's two elements to the solutions. The first one is multi-domain system modeling to help solve industry's problems here. Let me talk about what this is. So modeling, it's not surprising that modeling would be a way to help out of these things after all. If you look at building buildings, there are building modeling systems. If you try to go build a bicycle braking system, there's obviously solid modeling systems there. So it makes a ton of sense that if you're trying to build a system, that there be system modeling.
Now to have system modeling, it's important to be able to model the object being controlled, the plant. But what's a little less obvious is you also need to model the software and to model the hardware as part of that. If you want to model a complete system. This is one of the key elements of this. And so if you could do that, then you've got multi-dimensional modeling that can capture all elements of the system that you're creating.
The roots of this came in fact from education, from academia. Some of the earliest simulation software that I used were textural ODE languages. I used SIMNON from Lund University. When computers developed graphical capability, graphical block diagrams emerged and were used for simulation. But really what was needed to solve industry's problem was a multi-domain system modeling package. Now let me talk about what I mean by that. By multi-domain, I think there's like seven domains here.
Certainly needed to handle continuous time models for plant and controller models dynamic systems. Needed discrete-time models so you can do digital control. It's also helpful for people doing DSP, signal processing and image processing. Image is just a matrix. And so there's image applications you can do with this type of modeling. Physical models are important if you want to model the aircraft, or the hydraulics, or the landing gear, or whatever you're doing. And the basic domains there, electronics, mechanics, hydraulics, and thermal. On a block diagram, these are differential algebraic equations. The lines are bidirectional with a circuit, a voltage, a current, or something like that, rather than just the flow diagram the control system has.
Now here's where it comes to the software. Another important aspect to be able to model is to handle state machines. And state machines are things like the windshield wiper controls. Your window in your car. They have different modes that you have to go through. And that's very common obviously in control systems. And it's also how software is written. And if you want to model software, that's required.
Also discrete event models. Queues, servers are important in terms of modeling computer systems, performance modeling, and things like that. And then finally, text based models are still important. Despite the fact that graphical modeling is a great way to go, there are some things that just don't look good if you try to wire them all up. This dozen or so lines is an extended Kalman filter. And this is just the right way to write this. If you try to do this with a wiring diagram, it's going to look like spaghetti and you won't know what's going on. But this is a straightforward extended Kalman filter here. So textual is an important part of any multi-domain system modeling.
I'd like to give you an example here of a multi-domain model. I'm going to choose a wind turbine to show you. OK. Here's the top level diagram. Multi-domain model system model of a wind turbine. This is the model for the blades. This is the nacelle. That's the unit at the top of the-- it spins around, it houses the gears and the rotor for the fan. There's a tower model. There's a model for the grid in this case. This is the pitch controller for the blade, the blades on the turbine. This is the yaw controller. Controls the position the housing is pointing.
Here's the main controller. This is going to have multiple modes because there's going to be some modes we need to take to the windmill through. And then finally, we need a wind input in order to drive this simulation and test it a bit. OK. Let's look inside the nacelle and see what we see. In here, we have a gear train model, we have a generator, and we have an actuator model for the yaw system.
We can look at the wind input model. This is going to be fairly simple for this example. The wind speed, we're simply going to put in a piecewise set of wind. So it's going to start at zero, the wind is going to ramp up to 10 or 12 and fluctuate, and then it's going to drop down to zero again. And then the wind is going to change direction. It's going to move around over the course of this simulation that we'll do. And then down here there's a grid model. This is a transmission line and resistance there as part of the model. OK.
Here's the mode controller. In here, we have a finite state machine model. And it's got four states. This is the park state sitting there waiting for the wind to start. The wind starts to pick up. At some point it becomes strong enough, it goes into a startup mode, which is one that's trying to bring it up to speed. And that's going to try to get it up to 15 RPM, which is the speed it likes to run at. Here's a generating mode. That's when you reach that and you're just operating and maintaining a regulator. And then finally there's a braking mode. If the wind gets too strong or it dies, you need to break it and slow the whole thing down. And so there's going to be different control behaviors in each of those.
And then here's the yaw controller. We can look inside that. In this case, it's just a simple PID controller in this case. So this is a tremendously multimode model. There's a lot going on here in this. OK. We're going to run the simulation now. If you look in the upper left corner here, you'll see the upper chart there is wind speed. And you can see the wind is picking up there. The chart right below that is the wind direction. You can see that's fluctuating around.
If you look in the bottom left, that's the direction of the nacelle. So it pivoted to point into the wind. On the lower right, you can see the speed of the turbine. And you can see it ramped up to around 15 RPM. And it's now being regulated at that as the wind is changing direction and changing speed. In the top right, you can see really the control input, which is the pitch of the blades. And then the pitch that's achieved. So it's the command and what's achieved there. And you can see that regulating the speed.
OK. The wind is starting to drop. And at some point it can't hold on. And it has to just feather the blades and break and come back down to a stop. So tremendous amount of stuff going on there. This may be the most multimode simulation a lot of you guys have seen here. People don't normally build models this complex that have every single type of mode in it. Often people focus on a subsystem. But this is an example of a highly multimode, multi-domain system.
OK. So the goal of this is to have a single modeling environment that can model the full system. The plant and controller, the mechanical, digital hardware, analog RF if you need it, the embedded software, and then the environment. The wind and things like that. And if you can, then you've got a model system that models the whole thing. And it includes the various domains that I mentioned.
At MathWorks, this is the name of the different software packages that we've developed. We have a team of about 500 people that's working on development of this Model-Based Design. This is the life's work of a lot of people over the last 20 years to build this stuff. To build this one environment that can work all these modes together. It's extremely complex. How you can do all these things. There's lots of instances of each of these different modes that are in the wild out there in different forms. But getting them all to work together is quite challenging.
OK. So this is one part of the solution to help industry towards building these complex systems. The other art is a process called Model-Based Design. And industry prior to that had used a traditional development process. It's often called a waterfall. There's some research, that results in requirements and specs, design write the code, then test it. And it was fairly once through. You had a schedule over a year or two year period where you'd work through that. Obviously you'd have to do little loops in there. But generally it went through that phase.
Model-Based Design changes that process quite dramatically into a different approach. And Model-Based Design, you start with specifications. But rather than writing paper, you create a model. The model is the specification. And the beauty of that is that it is unambiguous. Because it either runs or it doesn't. You can't have gaps in that. And so it's executable. And you also simulate the whole system. And you start testing it right then. That's the key thing. Don't wait till you've integrated it, written the code. You start testing right away, validating and so forth.
The next phase, requirements are done in software. You create properties and objectives that define the requirements. And then you can put system bounds on the outputs if you want to restrict it as part of the requirements. So the requirements are built in software. Again, unambiguous. The design then is refined iteratively. And this is part of the power Model-Based Design. Because you could do a lot of iterations in the models. It's very hard to do that in C code. Or once you've already tested it on a piece of hardware. And at this point, you can add fixed- point effects, or timing, or component interfaces, or real physical things that you have to do to turn this into a design.
Result of this phase is an opportunity to explore many alternatives and really do a lot more innovation. You can try a lot of different fundamental ideas. And also find the flaws before you implement them. The implementation stage-- and this is one of the more high-value generating sections-- the code is generated automatically.
And that can save-- to write 50,000 lines of code or 100,000 lines of code, extremely expensive. And so it eliminates the hand coding, eliminates the hand coding errors. And is a huge impact. This is one of the reasons industry really likes this is it largely eliminates the phase. And tested verification no longer happens at the end. It happens continuously through the process. And it saves money because you don't have to have so many physical prototypes detect errors and so forth.
I remember years ago when I visited an automotive test track in Germany where they'd use Model-Based Design to design some active suspension software, and we got out there and was talking with one of the technicians. You know, old grizzled technician. And he looked at me and he said this team is the first team-- first guys from engineering that have ever come down here and their design has worked the first time. You know, he'd been there for many years. And of course, why did it work the first time? Well it's because they really had it simulated in the lab thousands of times and worked out all those kinks. And so that's what the opportunity is.
So this waterfall's replaced by this more complex picture. It's iterative, you can late in the game put things in and move it through there. And so the fundamental items here, the model is the spec, the requirements are a part of the model, you can iterate a lot on the design, you don't have to write the code. This is huge for you guys. You control ideas. The implementation stuff is often things you're not that interested in. And you can press a button and have that taken care of. And the testing and verification happens through there. OK.
I want to talk now about some of the impact on industry and share some of the successes in industry using this. Is a picture of a Chevy Volt. It's actually me in the Chevy Volt. This is the first Chevy Volt in the state of Massachusetts. GM brought an early prototype out to a conference that we had on a student competition and allowed some people to drive it around. This was designed heavily through Model-Based Design. They had a very crash program to design this at GM. And oftentimes when there's a crash program, they'll adopt Model-Based Design because there's no other way they could possibly hit their schedules there.
The Chevy Volt-- here's a picture of what's inside the Chevy Volt. This is an electric car with-- well, it has electric drive unit and a battery to power it. But then it has an engine generator. So if you run the battery down, this engine will kick in and generate electricity and recharge the battery and drive the car. And it was one of the early electric cars. It was released. And then there's control strategies to make these all work.
Here's some comments from the people at GM. Nearly 100% of the software for many of the Volt's modules was generated automatically. Here's another one. You can't make an engine and a transmission separately anymore and just integrate them at the last minute. It has to be conceptualized as a system. And comment here is I don't think you could do a hybrid control system without Model-Based Design.
GM is using Model-Based Design on a global scale. That they have 16 development application centers across the globe that are all doing this. They have models with millions of blocks. They released software every six weeks. People push out the algorithms for the various subsystems and they get integrated every six weeks for use by everybody. They're created by tons of people and across all product domains.
At the other extreme, here's an example of Tesla. Tesla makes an electric car. Came out fairly recently. They tried hundreds of power train configurations, and they didn't use physical prototypes. This is a startup. They're exactly the opposite direction of GM, which was a small team of people trying to design a car. And it's unusual. It's hard to have a startup in the automotive industry. And comment from engineers there. We couldn't have built this car without Model-Based Design. It would have taken resources that our new automotive startup company simply did not have.
This is an example from the European Space Agency. Their lunar mission satellite. They generated the flight code, they said that it reduced their system development time by 50%. Comments here on the simulation and flight-code generation played a key role in this success. Here's an example that I like. It's from Festo. Festo, I understand, had a talk earlier this week. I wasn't able to attend it. But I'm a real fan of what the Festo company is doing. Lots of very innovative stuff. This is a pneumatic robotic arm that they've designed. I don't know if they showed videos earlier this week. I think they focused more on their flying machines.
But this was all done with Model-Based Design to create this, the prototype that you're seeing here. Now what's interesting on for this particular design is that rather than generating C code, which is what most people do, they generated something called PLC, or programmer logic control code. So it's the same model, but it's generating a different type of code. And they won some awards and started some new business opportunities.
I have a video here. It's about a two minute long video to show you some other projects in industry here. And I'm going to try to talk you through some of these here. Show you different places that Model-Based Design has been used. I have some notes here on this. OK. The first one is the F-35, the Joint Strike Fighter. This has variants for conventional operation, short takeoff, and landing from carriers. Look at this now. Did you see the nozzles flip down and the control surfaces move? This is just an amazing controls problem in this vertical takeoff version here. Just a really interesting control problem.
This is a Mercedes car here. The right two wheels are on ice, the left two wheels are on pavement, they slam the brakes on. And they built an active control system. They can brake it on that type of slippery surface when you saw that in the car on the left. This is-- manroland makes high precision printing systems. To develop their controllers, they simulate the paper, the control elements, and mechanical structures in real time on computers. They use Fieldbus, and then they implement the controller on the hardware.
This is the first civilian tilt rotor aircraft in the world built by Bell Helicopter. They modeled it here using Model-Based Design. After modeling it, they designed controllers for it here. Then they generated code. And then they loaded it into a simulator gear to simulate it. In this case, the pilots fly the simulators. And then they proceeded to test flight. And you can see the interesting control modes this has. It starts vertical takeoff, then flies, turns into a flying machine.
OK, this is OHB, a German company. They worked with the European Space Agency to create two satellites that are called Mango and Tango to experiment with autonomous close formation flying. Here's some stateflow diagrams of different states. They partitioned the guidance navigation control to three modes, formation flying, rendezvous, and proximity operations. Proximity meant just a meter away. And so these are doing various rendezvous operations in space.
So those are a few quick examples of projects in industry. So Model-Based Design. Where is it being used? Certainly a lot in large systems like automotive, aerospace, safety critical systems. A lot of these have to be certified before they can be put into use by the public. But it's also being used in smaller systems and in places you might not expect. Model-Based Design used in signal processing, image processing, and communications applications, in some cases, don't have a lot of control in them.
Thermal imaging and FPGAs, a driver assistance software, flash memory controller, hearing aids and implants, image processing for retinal prostheses. So a variety of things that don't have a lot of control content, but I wanted to make you aware of that. Of course, if you're building larger cyber physical systems, you may be integrating with these types of systems.
Have a little bit here now to talk about the meta level impact on the industry. This is a chart that shows the percentage of time spent in the development stages with companies that use Model-Based Design and how that's changed. If you go back a few years, the largest portion of time was spent on implementation and test. And you see as you shift here forward in time, the implementation goes down dramatically. And the requirements and design moves up. OK.
Now this is-- engineers like to work on the design stuff. The design stuff is the fun part. That's where you get to do the innovation and do the cool things. So this is a great change and really improves things. You'll notice that the testing remains high. The test remaining high because a lot of these, test is really important. These are-- a lot of them are safety critical systems and things like that. So the test has remained high.
It is one area that industry has told MathWorks that they would like help. They would like help on verification and validation and testing because that's now a very expensive part. And in some ways it's not value added to the customer. The design has value added. But the system test, if they could reduce that or eliminate that, they'd be very happy. And it's actually a very active open R&D area. And there's ideas from industry very much appreciated by industry in this area, because at this point that's their biggest issue facing them. They're very happy with the innovation and the design and implementation. But the test is getting them.
The next chart that I was going to talk about here, which you'll see in a second, is showing how-- it talks about in the automotive industry how the work breaks out breaks down between the manufacturer, the automotive manufacturers, sometimes called an OEM, and then the suppliers. The automotive industry has major-- like General Motors and Toyota are the manufacturers. And then there's suppliers that work there. And part of Model-Based Design has shifted there to more time spent on design by the automotive manufacturer and less away from the suppliers.
In 1990, this is the breakdown of the work done by the automaker and the work done by the suppliers. And you can see that previously, the requirements were specified by the automaker, but the suppliers did most of the work there. And that's shifted today with Model-Based Design to the automaker doing the feature development and the design and even generating the code through the code generators. And the suppliers are being moved to more commodity types of things here.
And the comment I have on this is sort of design becomes the high ground. In other words, design is where the intellectual property, where the IP, where the innovation comes out that really makes you choose between one car and another. And the automakers want to own that, not have the suppliers creating it and sharing it across all the different automotive makers. So this is a shift that we've seen in time here as Model-Based Design has enabled the automakers to do more of that.
It's also because a lot of the simple things are handled better here, it's allowed industry to move to systems that are smarter. The minute something gets easier, you can start to make it harder by doing more. And so one of the ways that obviously are happening in the world in terms of making it smarter. Well certainly more active versus passive systems. More autonomous systems.
You know, UAVs, robotics. Those are happening. Collaborative systems where there's cooperative behaviors between robots and so forth. And then multifunction. Things like hybrid electric vehicles. I think every hybrid electric vehicle in the world is being with Model-Based Design because it's complicated here and has multifunction versus single function. So it's enabling the development of systems that are smarter.
So in summary, Model-Based Design is a big innovation in industry in how systems are designed, implemented, and tested. The fundamental elements are it's allowed more math and algorithms to be put into systems. It allows you to be more innovative because you spend more time in the early design iterations where the innovation goes in. It's largely eliminated the hand coding that's so expensive. And the quality is higher for these complex, often safety critical systems because you're verifying and validating early in the process.
It allows collaboration across different mechanical, and electrical engineering through the models. And then across the development stages where the models are used shared throughout all of those. So it's a big change out there. OK. I want to now-- that's sort of bringing you up to the present here in terms of what's happening in industry. I now want to shift to talking about some megatrends going forward in the next five years that affect the industry and I think affect you all.
And I got four of them for you. For these technology megatrends to share. First one, that the algorithm and software and everything keeps continuing. This is a chart that shows the growth in transistors worldwide. Intel predicts by 2015, there'll be 170 billion transistors per person in the world. Now what's interesting is in 2005, there was actually an inflection point in this curve.
And there's an increase of over 200 in the last 10 years. So just extraordinary growth here. And of course, this is all running software and largely embedded systems. We're just putting processors into everything. Autonomous cars, your washing machine, enabling new systems like a motorized unicycle there. It's just really, it's going everyplace.
Trend number two takes it up step further. And this is, of course, the internet of things trend. Now this is basically going to take all these things that have processes in them and basically everything with an on off switch is going to get connected to the internet. Everything with on off switch or a sensor is going to get connected.
There's a great way of visualizing this that I really like here that I'll share with you here. You can look at this as sort of the connectivity of the world. And there's three basic phases that have connected the world. The first phase with the connection of places. This happened over the past hundreds or so years where transportation systems, you know, ships, airplanes, trains, cars, things like that connected the world's places. Let's say there's a billion of them.
Trend two was connecting the people. And this is actually relatively recent. It was the internet that came along. And actually in the last five years, smartphones. It's hard to believe it, but the Android isn't even five years old. And the iPhone is like six or seven years old. And that's truly made it so every person on the Earth, or many of them, can be connected together and communicate. It's an amazing transformation in just a very short period of time.
But the third wave is connecting not just the people and the places, but all the things. And there's at least 50 billion of those. And so that's really what's going on here. And so these are relatively recent trends. Nobody really knows where this internet thing's going or how long it's going to take or what the impact is. But it's definitely going to happen. And it shows in the case of the people that it happened pretty quickly. And the things, nobody really knows.
My trend number three I want to talk about, which is very relevant for this community here in the room, is this growth of low cost embedded processors and experiment hardware. And we've developed these hardware support packages that connect to all sorts of things, webcams and connect systems from Microsoft. Things like that. But we have data for what the most popular low cost embedded processors are. And those are, we affectionately call them ARL. Arduino, Raspberry Pi, and LEGO.
These are all very cheap. $30 for these processors. The Raspberry Pi didn't exist two years ago. They just actually crossed 3 million like in the last month or so. And very cheap processors that enabled hobbyists and everybody to do it. This is a huge trend. I'm sure a lot of you guys have seen this that I really want to call to your attention here. Because it is changing things.
At MathWorks, our approach has been to-- in terms of how we support it, there's two basic modes. There's a tethered mode where you can sit and you can have MATLAB and write MATLAB programs that speak over communication, usually Wi-Fi-- or it could be other things-- to the hardware. Here in this case, a small robot. That's one form. The second form is through Simulink, where Simulink generates embedded code that gets downloaded to it and then it's autonomous and can run off and do its own thing. So there's two basic ways.
And we've worked to develop these hardware support packages. We have 150 of them. They're free they're available on our website. And they connect it all up. Just to see the trend, you can see that this is a trend, that this is internal MathWorks data of the downloads we have, the installs. And you can see it basically started very recently, just two years ago. And over the last half year, almost 40,000 or so downloads in the first half of this year. So it's a very rapidly growing trend here as people are experimenting with these. We have a couple of them running in our exhibit. They're being used all over the place. And OK.
And then the fourth trend I want to mention here is the growth of apps. Years ago, with mainframes, there were thousands of applications. Moved to the PC, there were tens of thousands of applications. The world has now moved to a third platform, mobile, cloud, things like that. And there are literally millions of apps. And the message is as each of us have-- the world has created a lot of little point applications. We all use apps to solve lots of different problems. We're used to having a lot of them and using them. And at the moment I have a message to you guys about I think we could use more apps in the control area. That's where people are expecting to have their knowledge contained and built.
So here are the four megatrends that I want to share with you here that I think are really important. I think control is connected to all these things. And these are important trends for the community. And so now I'm going to shift to talking about some of what I think the impacts are on education and research from these trends. I put the word future in parentheses, because some of you are going to look at this and say we're doing this today. And absolutely you are. There's people doing this stuff. But I think the opportunity to do a lot more is really important and could be transformative on education in a lot of different ways.
So one area of particularly low cost hardware that's growing up, but it's also driven by Model-Based Design and other things are this problem based learning. These are a bunch of different competitions. This is just the list that MathWorks-- we support these. We donate money to them. We donate people that support them and put their time into it. And so these problem based learning, these competitions and projects are just popping up all over the place. Major trend.
Here's an example. I have a couple examples to share with you. This is RoboCup. Many of you might know of that. RoboCup is a contest that is trying to, by the year 2050, create robots that can beat the World Cup team. The World Cup finalist in the world. So that's their ambitious goal. And so I'll show you, I'll run this video. This is an example in June of the contest here. And it's really quite amazing. These things are driving around, they're able to shoot it, they're able to avoid each other, pass, they have strategies, so they're working together. Moving around here. Kind of looks like the German team right there.
And it's really very-- if you haven't seen this before, it's truly amazing. This is all the stuff that's going on. And this is an educational institution that's building this. This is sophisticated stuff. These guys are playing with the big boys in terms of strategies here. They're using Model-Based Design. One of the things that enables them to do, they have an advantage in that. Not all teams that enter that do that.
One of their advantages is because they're not writing all the C code to there that they can do design adjustments between the games. Like, if a game is two hours apart, they can go change their Simulink diagram and change the structure. Not just parameters. And then regenerate the code. And they finished in first place finish among their division in June. Anyway, it's amazing stuff. A comment from a person involved with that is these tools help students rapidly develop complex software, including vision, tracking systems, strategy. There's all sorts of stuff going on here. Very interesting stuff.
Here's another design. So these design competition and robotics are happening everywhere. Here's a less expensive version that you guys could do yourselves. This is the LEGO kits. The reason LEGO is so popular is it's very inexpensive. Using the harbor support package you can build a Simulink model. This one uses a light tracker to follow a line here. And this is a competition in Japan that they have on this. But they're happening all over the world to do that. It's relatively easy to organize. People get really into it.
There was a team that used Model-Based Design here or there. First place in the speed portion, some comments from other people. This team was in a different world. The comment was at work I see Simulink models, but didn't realize the real power of the software. They actually had models of the track and models of the car and all that as opposed to-- so they could just use speed forward control really rather just feedback.
Here's an example. It's not a contest, but it's a project that I think is a lot of fun. This is the diwheel. And it's from the University of Adelaide. Let's run this thing here. This is something-- this is open loop now. And you can turn on the spot. But it's really hard to drive because it's just unstable in terms of the passenger. So in their project, step one was to drive mathematical equations of motion. Step two is design a control system. Step three is to simulate the control system. And step four is to generate code and to run it. And there you have it in a stable form.
Of course, there's always a step five, which is to show off. Which in this case is to invert the thing and be able to drive it upside down. Now this is a fourth year project that was done at the University of Adelaide. Great, fun control problem. Comment from the professor involved with this. He said some of the more accomplished students, after doing this project, have the skills of seasoned controls engineers well before they graduate. From doing a project like that.
I have another sort of two minute video that has some other education and research projects here that I'll try to voice over and walk you through. This first one-- turn up the volume a little bit. This is Stanford University. They're building autonomous cars to race. They're trying to beat professional drivers. OK. Look, there's nobody driving that thing. They're trying to take this around a track and actually compete against professional racers. It's a project at Stanford University that they're working on.
Of course, quadcopters are really popular. Everybody's seen that around. This particular set's from the GRASP Lab at the University of Pennsylvania. They're exploring how quadcopters can collaborate to construct structures quickly. This is now sped up so you can see what happens when they move more quickly. And again, quadcopters are full of all sorts of things you can do.
We had a Simulink student challenge. This student by themselves built this simple system to use electromagnets to control the position of a ball. He used computer vision and system identification to design his controller. The deflections in the plane show where the magnets are activated. So this is impressive student project here doing this.
This is a Formula Student Germany competition. 115 teams from 25 nations are there using Model-Based Design to simulate strategies, analyze performance, design and experiment, to implement controllers. This looks like a kind of fun-- I can see why the students liked this. Great way to learn control. If you don't want to spend that much money on racecar, this is RoboCup where they're-- oop, ran into the buoy-- where they're working on autonomous channel navigation here. A much more low cost rig here. But the same thing, teaching different control strategies.
This is the Technical University of Munich. Students in this program designed flight control systems. But then they get to fly them in a realistic flight simulator. So he's gotten into a-- the student has gotten into a flight simulator they have in the lab, and he can actually fly his own control algorithm So it's a great way to experience what control means and the different elements of that.
OK. Now a little bit on MATLAB apps. I mentioned the growth in apps. So we've recently tried to make it easier for MATLAB users to build apps and to make them visible. There's a new tab on the tool strip where you can see the different apps. They used to be called GUIs in the old terminology here, but we've brought them forth and made them more prominent. And there's all sorts of different apps available now that are available quickly and easily through that tool strip.
What I'd like to do is share with you an example of an app that was developed fairly recently at MathWorks to hopefully inspire you into these types of apps here. And this one is a robust control synthesis. This is a chart that it's going to-- I'm going to show you sort of an axis here that has the tractability of the control solution versus the flexibility of the solver. You can put classic mu and LMIs that have good theory tractability but not necessarily that flexible. On the lower right side is generic non-linear programmer, you can throw it at anything. And that doesn't have a lot of theory, but it's obviously very flexible.
Anyway, Pascal Gahinet, from MathWorks and Pierre Apkarian at the previous IFAC published a paper they called Structured H Infinity Synthesis that tries to put something in the middle there on that picture. And basically, part of what this new technique does is it says this is the-- this is Pascal speaking here. The world as robust control theorists like to see it, but the world as engineers see it who are working inside Simulink. And it's hard to connect the dots between those.
So what Pascal and his team built is a MATLAB app, which is called Control System Tuner. And basically, it's going to use this fixed-structured H Infinity Synthesis algorithm. And it's going to use it to tune a controller in Simulink. You'll specify the blocks you want to do, the goals, you'll do the synthesis, you'll visualize the loop shaping results, and then update the Simulink block parameters and rerun the simulation.
So you're going to see robust control design now in 50 seconds. You're going to have to watch close. So here are the blocks to tune. If you run a simulation, you can see it's a poor match to the reference input that's shown there. It doesn't do very well. So we're going to start the app. And the first thing we have to do is specify the blocks we want to design the controller around.
Then we need to say which inputs we want to do. And then we say we want it to match the step response there. And so we add the signals there. We specify the time parameter on that. And there's the shape that we're looking for. And then we want to do the open loop response for the stability margins. So we specify the open loop shape and the crossover frequency there. And we can look at it. So we want it to appear in the correct versions there. Then you run the synthesis. That takes almost instantly on today's computer. Then we upload the model parameters. We rerun the simulation here. And voila, there's the disturbance rejection after the tuning there above. So it matches the step response and has better disturbance rejection.
So we showed that to people in industry, and they just love it. Because it just-- it's so hard to do otherwise. And this app wraps it all around that. So the controls community has built hundreds of toolboxes to do different things. They're mostly collections of functions. So suggestion here is there's an opportunity to take some of the theories that have been developed and make them in a much more usable form here, which will make them more broadly there.
The world is starting to expect that. And we've been spoiled by our Androids and our iPhones and expect to have an app to do these things simply and not have to program to do that. There's a file exchange on the MATLAB Central is a place where you can create and share your own apps. Has lots of different apps that are up there already.
OK. This brings me to near the end of my talk here. The key idea that I have been talking about here is about how multi-domain modeling and Model-Based Design have transformed industry here in how complex systems are doing. And I think there's an opportunity for this to have this similar type of transformations in education here.
So I guess in summary, the current technology megatrends that I shared here are really outstanding for control applications. I think that the rise of mult-domain simulation and Model-Based Design is going to have a far reaching impact in education. You can work at the mathematical level here with your algorithms and your ideas and concepts, push a button, and it takes care of the C coding so you don't have to do that.
Some things I think this could mean. And I'm going to sort of be far reaching on this a bit here. I think that hobbyists around the world through maker fairs and other areas like that are going to be tinkering with automatic control systems, sharing software designs and apps over social media. I think this could be the beginning of an explosion of innovation, small scale development that will lead to startup companies, transforming existing industries, and create new industries.
The universities, I think, are being a seedbed of this next wave development and economic growth worldwide. You know, I was in Johannesburg yesterday, and I met Professor Barry Dwolatzky from Wits University. And he's starting an incubator called the Joburg Center for Software Engineering. And that's an example of startup companies and this type of technology driving it. Software, controls, innovation, the different algorithms. And so there's real opportunities there.
I have some calls to action for you. Just to maybe challenge you a little bit here on some things based on these megatrends here. Add a project to your course using the low-cost hardware. Some of you have already done that. But this is a huge trend. It makes it more experiential. Students respond really well to that.
Organize a student design competition. They're easy to do. We ran one in our exhibit during this week. And if you can run something in an exhibit booth, you can run it anywhere. It's easy to do with the low-cost hardware. Apply advanced algorithms to real hardware to invent something and start a company. This is happening in Boston, Massachusetts, it's happening in California. The example from the Joburg Center for Software Engineering example of it happening in South Africa. I think there is a real trend here. This stuff is easier than it's ever been to just go from the ideas to some type of invention. So I want to challenge you on that.
Create an app that allows others to easily apply whatever your theory is. I think there's a real opportunity to get on that trend. And finally, there's research needed on new techniques in the model based area. Verification. Industry's desperate for these things. And very interested in that. So I think that these are exciting trends. The world is moving towards you at an amazing pace. And it's extending the reach of control engineers and control theory. Thank you for listening.