Adopting Model-Based Design
It is challenging for development teams to manage system complexity in an increasingly software-enabled world. Model-Based Design addresses key challenges in a modern product development process and leads to significant reduction in development time and cost. In this webinar, learn how your teams can reap the benefits of Model-Based Design by adopting it with a phased approach in your projects and development process.
Highlights:
- Overview of Model-Based Design and its benefits
- Case study on the adoption process and MathWorks support
- Return on investment (ROI) of adopting Model-Based Design
Presenters:
Tianyi Zhu is a product marketing manager at MathWorks focused on Simulink® and Model-Based Design. He holds M.S. and B.S. degrees in Electrical and Computer Engineering, both from Carnegie Mellon University.
Karanjodh Singh Meen has a M.S. in Mechanical Engineering from Arizona State University and a B.E. from Punjab Engineering College in India. He specializes in the areas of control systems, system dynamics, and robotics. In 2018, he joined Technical Support at MathWorks and later moved to the Application Engineering Group in 2019. He works with customers in the automotive, medical device, industrial automation, and aerospace industries, specifically supporting workflows that involve modeling physical systems, designing controls, and automatically generating code.
Published: 26 Jul 2023
Today, we have more and more innovative products driven by algorithms developed in software. Software is changing every part of our daily lives, and it's the key enabler behind a lot of the cutting-edge devices and systems. And these systems range from life-saving medical devices, autonomous vehicles, intelligent robots, to fully electrified systems powered by batteries. And as these systems get smarter, the software embedded in them becomes even more complex and challenging to develop.
So how do you manage this complexity, deliver faster, meet changing customer requirements, and ensure product quality, all at the same time? Today, we're going to talk to you about why model-based design is a strong approach for engineering complex systems, as we mentioned before, and how you can start adopting model-based design to meet the development challenges in your organization.
So my name is Tianyi. I am on the Simulink Product Marketing Team at MathWorks, and I focus on model-based design. And joining me today on this session is Karan. Hey, Karan.
Hey, Tianyi. Hey, everyone. This is Karan from MathWorks, and I'm an application engineer here. I also work on the Simulink side of our tools and help customers adopt model-based design. And today, we are going to talk about a bunch of different topics, but we're going to start by addressing, what are some of the key challenges that are faced in modern product development workflows, and how model-based design can address these challenges. Now, once we get an understanding of how model-based design addresses key challenges in product development workflows, we will take a look at a case study where we see a user-- one of our users, Danfoss, adopt model-based design, try it out for a small project, and then scale it from there to a company-wide design standard.
And once we understand what the absorption process looks like for model-based design with this user study, we can start to distill some of the ROIs, the return on investment that our customers get from adopting model-based design. And once we look at them for a specific case study for, for, example for Danfoss, we'll try to distill the ROIs and generalize them for all of our customers. And then, finally, we'll share some resources that you guys can leverage to help you in the process of adopting model-based design. And then, finally, we'll wrap up the session by summarizing and opening the floor for questions.
All right, so the first thing that we're going to talk about is, what are some of the key challenges that are faced in the industry today? So essentially, the challenges that we're going to talk about today lie in three buckets, and they're kind of interrelated. But the first big challenge that we see out there is that prototypes are typically costly to build, and it takes a long time to build these prototypes. It takes a lot of engineering hours.
And the process is slow because of multiple reasons. Sometimes you're just waiting for parts to be delivered. Sometimes the parts that get delivered are not exactly to the specifications that you initially expected them to be so you have to rework some of the design and then rebuild or re-accommodate those parts in a prototype. So overall, the prototype manufacturing process ends up being quite a time-consuming process, and in addition to that, it takes a lot of engineering resources. As well, it could be expensive depending on the type of prototypes that you're working with.
And on top of that, as you build the first few prototypes, oftentimes, these prototypes have flaws and design errors, so they don't end up behaving as you expect them to. So you have to rework the design, and maybe create more and newer prototypes slowly as you perfect your design, and go through this iteration again and again. This ends up, again, piling up and adding up to the cost of the project as you're now iterating through expensive prototypes that take a lot of time to build.
Now, the other challenge is that-- as Tianyi kind of alluded to in the beginning of this presentation-- is modern products are becoming increasingly complex. These products touch upon multiple engineering domains like mechanical, electrical, thermal, fluids, and so on. And on top of that, these products have, even, software tied into them, and the software is controlling the different physical aspects and controlling the behavior of the product.
So all in all, there are a lot of different engineering teams working to make the same product a reality. Oftentimes, these different engineering teams are working on different sets of tools, and they're kind of siloed from each other, and they don't really communicate with each other until to the stage where they get to making prototypes. So this leads to a challenge where everybody is working on their piece of their design for their product, and they maybe can test out the individual pieces by implementing unit tests, but they often do not get to test the entire product till they end up putting a prototype together in the very later stage of the design process.
And this is the stage when you start finding out design flaws and miscommunication errors, because everybody's working on a different tool, and these tools don't communicate with each other. So you have no way of knowing if different pieces of the design align or not until the very end.
And then, on top of that, modern design processes are usually pretty long, and they have different stages. And even between these stages, you're working in different environments. You're working in different design tools. And different design teams are handling these different stages. And oftentimes, there's a lack of communication-- or seamless communication-- between these different teams that leads to a lot of design details lost in translation from one tool to the other, or just errors introduced because different design languages don't often integrate well to each other.
So this leads to our third challenge, which is essentially, since everybody's working on their own environment, their own set of tools, and the final product is only going to be tested when you put a prototype together, this means that you're going to find errors and bugs which potentially might have been introduced early on in the design process till the very end of the process. And what this leads to is that it leads back to the first problem, where the prototype that you built might have a lot of design flaws, and might need a lot of rework, and you might have to iterate through this whole process of redesign, correcting the design, making changes to it, building another prototype, testing it, making sure it behaves as expected. If it doesn't, spending time to figure out what exactly is the root cause of the issue that's causing the prototype not to behave in an expected or a desired way, and then going through that iteration again.
So all in all, the traditional design processes often rely heavily on prototypes for testing the final product. So this for a need is, how can we address these three key challenges and, essentially, reduce our reliance on prototyping for testing and validating design, and also, how do we make sure that our different design teams and different design stages work more coherently with each other and more seamlessly in the design process? So Tianyi, can you tell us how model-based design addresses some of these challenges?
Yeah, Karan. So to help you understand how model-based design can help you address these challenges that Karan just mentioned, let me provide you with an overview of model-based design. So we describe model-based design as the systematic use of models throughout your development process. And there are two major components-- modeling and automation.
So with Simulink, you can model and simulate your system to quickly try out new ideas and explore a wide design space. Your entire team can use one environment to simulate how all different parts of the system behave by simply hitting the Play button. And the systems you can simulate in Simulink include physical systems. And there is a wide range of pre-built components that you can select from the Simulink Block Library across many different domains, including mechanical, electrical, thermal fluids, hydraulics, and so on. And you can also customize these or build your own box.
You can interactively design and tune your control systems. You can simulate signal processing and communication systems, create autonomous systems such as drones, robots, and design automated driving applications. And these applications include advanced safety features, sensing, navigation, perception, and controls.
You can design, industrial systems like robots and incorporate complex state transition logic. And you can develop simulation-driven tests that are fast and repeatable to quickly visualize and validate the changes that you're making to the system. And I'll just quickly add, then, you can design a lot of these systems in Simulink, and Simulink also allows you to talk to other design languages where you can co-simulate, or maybe import or export Simulink models into other languages, or import models from other languages into Simulink, so you can do a truly system-level model of your products.
Yeah, so to add on to that, you can import third party models via the FMU imports. If you have some legacy code that you have written for your system-- for example, C or C++ code-- you can integrate the legacy code into the Simulink models and perform simulations as well. And we've also recently added integration support for the Python language. So if you have any modules built in Python, you can also bring these into Simulink environment.
So that's all about modeling. And the second component to model-based design is the automation of coding and verification. So with Simulink, you can automatically generate code from your system model instead of writing thousands of lines of code by hand. And the code that you generate is production-quality, fully traceable to your design, and behaves the same way as the model.
And the best thing is that you can deploy the code directly onto your embedded processors or FPGAs and ASICs to target different supported hardware platforms. And Simulink also provides tools for you to automate the testing and verification process as much as possible so that you can test and simulate early and often. With hardware-in-the-loop testing and rapid prototyping, you can have an early view of software and hardware integration and test your systems under conditions that would be otherwise too risky or too time-consuming to consider. And all of this testing builds up your confidence that your system will work out in the field in a production environment.
So with model-based design, you have these multi-domain models that serve as a single source of truth for a design throughout the different phases of development, so that this helps you eliminate the barriers between the different stages by promoting understanding and communications of your work across different teams. And models are at the center of your development process. And this creates a digital thread that enables requirements capture and traceability of artifacts from requirements, to the system architecture, to your design, to your code, and to your tests.
So in summary, with model-based design, you use modeling to try out new ideas and run simulations to perform the fast and repeatable tests, and with the power of automation, you eliminate a lot of the manual steps and potential human errors associated in a traditional development process. So so far, we've covered what is model-based design and how it can help improve your development process. But you might wonder, how have real companies adopted model based design? So in the next section, we'll take you through the journey of Danfoss to learn about their success in adopting model-based design and the best practices for scaling model based design in your organization.
So just to provide the context, Danfoss is a company that develops manufactures and supplies products around power and energy solutions. Back in 2014, they found it increasingly challenging to manage software complexity in their products. They were missing the links between their control design and the corresponding software implementation. There was also a lot of pressure for them to meet more stringent regulation and higher quality standards in a very competitive market.
So their objective at the time was to shorten the development cycles, establish traceability between their control design and the software implementation, and fix issues early rather than late. So with this in mind, they hired new engineers and kicked off a project to re-evaluate their embedded software development process. So let's now hear from the lead engineer at Danfoss about how they started the adoption path to move to model-based design.
My name is Jens Godbersen, and I'm a lead engineer at Danfoss Solar Inverters. A couple of years ago, we were about to initiate a new product development. A question arose-- could we continue with our present design process, or should we switch to model-based design?
Learning model-based design at the same time as ramping up on a development process could increase the risk for exceeding the time schedule. This could talk for that we should introduce model-based design in more steps. This didn't sound so attractive to us, because then, we would have to ramp up on two different development processes at the same time.
So we started a pilot project to test the attainable code efficiency. That means we tried out different models-- Simulink models, MATLAB scripts, Stateflow charts-- all on a part design of our existing inverter. We saw that the code efficiency was about a level where we could accept it.
So as Jens pointed out, the adoption of model-based design always starts with a small piece of your project and a small working group of engineers. So breaking down the process in smaller steps helps you de-risk the project and gradually builds up your team's competence, as well as confidence, in model-based design. So to take that first step towards adoption, you take an algorithm of a limited scope from your existing design, and then you create a model for that algorithm in Simulink. And then, you generate code from the model for your software implementation.
And because you're focusing on your design rather than the low level programming constructs, modeling and debugging the algorithm is much more easily done in Simulink than with a traditional hand-coding process. The use of code generation also helps prove that coding can be automated because the generated code can achieve functional equivalence, and also meet the performance requirements when it's being compared against existing hand-code. So this summarizes how Danfoss completed a guided pilot project to validate this new workflow.
I'd like to add here is that, so in the Danfoss, when this-- even when they're starting out, you can see that they're trying to adopt the tools all the way from requirements to generated code, even for the small project. They're not just building a small piece of the project and just handing over that piece to another design team. They're starting from requirements, making a model of that small piece, simulating it, testing it in simulation, and then generating the code, which can finally actually be implemented in the project. So it's a full design development in the tools.
Yeah, so even though the project is limited in terms of its scope, they try really hard to maintain that traceability from high-level requirements to the model and to the generated code. So that's one of the best practices, is to keep this idea of traceability in mind when developing your system. So let's hear from Jens again on how they took it from here, their first pilot project, to the product development stage, with the support from MathWorks.
[VIDEO PLAYBACK]
- So now, the next step was to start the product development. But during the implementation, we needed to make sure that our project time schedule would actually meet. We engaged up with MathWorks support. Every week, we had a telephone conference with one of the MathWorks support here.
Over time, these weekly telephone meetings actually went into biweekly, and then later on only once a month because it became more and more self-supporting. Our team engineers, they learned very quickly how to deal with these models here, and also the tools. We build up some simulation models, hardware models, which gave them really good simulation results. We were able to simulate very precisely what we saw in the lab later on.
So this was some really great improvement in our design iteration. We were able to do that early in the process. We spent some time in building up the models, yes, but it really pays off pays off later.
[END PLAYBACK]
So Danfoss built upon their initial modeling success by expanding the use of modeling to a wider scope of their design. So they started with the key control algorithms, and they built out larger models for running simulations. And these models include the plant model, which represents the inverter hardware. And they put all these pieces together for running system-level simulations, which gave them an early view of how the control software interacts with the actual physical system.
And they were later able to confirm the simulation results in the labs on a prototype. And this gives them a lot of confidence that simulations can help significantly reduce the need for building physical prototypes. And throughout this process, they received a lot of support from the MathWorks team. And this helped them quickly master the tools and ramp up their modeling skills that are required for building their design on this larger scale.
So how did Danfoss move from first pilot project to their first production-grade project with model-based design?
[VIDEO PLAYBACK]
- Then, from our first project, we did a 17-kilowatt PV inverter. And we saw that, yes, the project frame was met. We didn't save anything. We didn't gain anything. Everybody in our organization agreed on, yes, the time frame was actually comparable to what we would consider a normal project run. So this was successful.
Our testing certification campaign went very smooth. We were able to assimilate a lot of those test cases upfront, actually. Some of the certification engineers that came to us and said they never experienced that. We actually passed the certification the first time.
And furthermore, we built a knowledge base for forthcoming product developments. We now have a library of models we could apply for next-generation products.
[END PLAYBACK]
So the team at Danfoss saw some of the immediate benefits to adopting model-based design. By creating components and system models, they had precise and intuitive representations of the physical system, as well as the algorithms that are used to control it. By performing simulations, they were able to validate and test the designs early and continuously, and they were able to easily generate code that can be used for either prototyping or production use.
So this entire cycle from design to code and from code to design can be completed and repeated much faster than a traditional development cycle. And the best thing is, to generate a code, as we mentioned before, this idea of traceability, right? So the code is always up to date and bidirectionally traceable with your design and your requirements. So as a result, Danfoss passed hardware tests and achieved certification much more easily and with less cost than before.
The other big use case of models is that, once you have developed models, they can be reused for other projects as well. The same models, for example, like for electric motors or batteries, might lie at the heart of another project as well. So these models are highly reusable, and you don't have to recreate those models from scratch for every project.
This idea of reusability of models and components is very important. And in Simulink, there are a set of best practices for you to do componentized development, so that any components or modules that you create for your current system can then be easily and efficiently applied to the next generation of products that you develop. So it helps save a lot of time and development resources. So how did Danfoss move from their first project to the second project?
[VIDEO PLAYBACK]
- Actually, in fact, before we ended this project here, our first project, we started development of what we call a large commercial PV inverter. This is a 60-kilowatt inverter. Here, we have now a reuse of our first models. We saw a very fast project ramp-up. We now have all our software and control engineers involved in model-based design. We have adopted the model, the model guideline, our first project, because we didn't have the model guideline in place, was actually-- we saw a number of different modeling styles, and this is something we spent, perhaps, a little time on correcting.
So in the second project, we adopted the model guideline right from the beginning, and we saw very smooth and high-quality models. Now we saw the reduced development time. We saved something like 15% because we were so fast to ramp up from our first design to the second design. [END PLAYBACK]
So Danfoss took their initial learning from their first production-grade project and applied it to the second project, which is a more complex system. So this is when they really started reaping the benefits of model-based design by keeping some of these longer-term goals in mind. So for example, they started implementing a set of modeling guidelines so that there is standardization of modeling styles, architecture, and documentation across the different teams within Danfoss.
They had a faster project ramp-up time by reusing the library of models created from the first project, just as Karan mentioned before. They fine-tuned the models and experimented with different configurations so that they can get even more performance out of the generated code. They expanded the use of model-based design all the way through to hardware-in-the-loop testing. They were able to establish a more efficient certification process based on the experience from their first project.
So if we look back at the adoption path that Danfoss took since 2014, we'll see that the initial adoption started with a small pilot project and a small team of engineers, and MathWorks was able to provide support and guidance from the very beginning of the absorption process by helping them create an implementation plan and help them outline the priorities and activities for each adoption stage. And this helped them move model-based design from an experimental stage to a production stage, where they applied the new process on a small-scale commercial project before scaling this up to a larger and more complicated project.
And they rolled out this process from small teams to entire departments, from a single product line to multiple product lines. And one of the biggest factors that contributed to their success was involving MathWorks early on to help guide the incorporation of modeling guidelines and process standardization. And the engineering teams at Danfoss have recently taken model-based design to the next level by integrating model-based design into a modern DevOps workflow.
So this is where they created an automated build process for their models and built a full pipeline for version control, code generation, unit testing, and automatically triggering hardware-in-the-loop testing. So we've talked about the benefits of model-based design and how to scale it, but at this point, you might be wondering, how do we justify the investments in adopting model-based design? How does model-based design change my equation of costs and benefits for my organization?
Oh, thanks, Tianyi, for walking us through that case study of Danfoss and their journey through adopting model-based design. Now, let's try to distill some of the benefits, and how did they get ROI out of this process? The number one key thing that model-based design tries to achieve is that it tries to push the burden of testing and finding design flaws to the left, to the early stages of the design process.
So as you can see in this graph, you can see that in model-based design, the defect discovery mostly happens in the requirement and design stage. And by the time you get to testing-- either unit testing or integration testing on prototypes-- you have already figured out most of the design flaws and fix them as they were introduced in the process early on. This as compared to the traditional industry average, where you're finding out most of the flaws in the testing stage, and you have to rework a lot of these flaws by going back to either the requirement stage or the design stage. It helps them save a lot of engineering hours and just resources that are put into building actual prototypes.
Now, with this in mind, what are the qualitative benefits that model-based design gets you? So essentially, one of the main things that happens here is that, since you are debugging and fixing issues as they are introduced in the projects, rather than wait all the way till the prototyping stage, you end up saving a lot of time in the testing process. So this means that you can introduce your products faster to the market and giving you a competitive edge by just getting to the market faster.
And additionally, the time that you save on just testing, finding out flaws, figuring out what the root cause for the flaw is, and then fixing it and then reworking the design, as you're freeing up some engineering resources, now these engineering resources are available to do more projects, to maybe do a second version of the product even faster, rather than spend time on troubleshooting some of the defects on the field, which adds to both customer frustration as well as the frustration from the design in the design team.
Now, additionally-- and this is something that we saw in the Danfoss story as well-- is when they were trying to build solar inverters-- that was a new line of business for them back in 2014-- model-based design reduced the risk of taking on and pursuing new business initially, because now you're building models instead of building prototypes, and you're running simulations. And additionally, this improves innovation because it allows you to test out a lot of different scenarios, a lot of what-if ideas that engineers might have, by just making a few changes in the models, and running a simulation, and seeing this change in the behavior of the system through simulations.
And as you're innovating more, you can even test for more scenarios. Because oftentimes, when you build a prototype, building a prototype itself is time-consuming and costly, but then, you also need to build a test environment for the prototype. And you can replicate building test environments in simulation and, oftentimes, test your projects for a lot more variety of scenarios, just in simulations. And this both improves the reliability and the quality of the product that you're putting out there, but this also makes it more versatile, as you might be able to counter for unexpected working environments through simulations.
Yeah, one of the most important things in the space of innovation is how do you build a proof of concept to show to your investors or to show your show to your management team that this idea is viable? Using modeling and simulations, you can easily demonstrate how you can easily build a prototype based on the results of the models in your simulations. And we have seen a lot of startups come to us for adopting model-based design because they found it to be a very quick and efficient way of working on a set of new ideas, and then putting that ideas into a set of technical specifications, and then turning that set of specifications into reality.
Exactly. So modeling and simulation becomes a great way of doing feasibility studies on every new idea that you guys have. And then, this is something that we heavily saw in the whole presentation. This was kind of like the underlying theme, is we want to reduce the reliance on prototyping, just because there are delays in making prototypes and it's just hardware is more expensive to put together. And by adopting model-based design, you're switching the burden of testing more through simulation.
Keep in mind that simulation is not a method of replacing prototyping, but it is just a method of reducing the reliance on this prototype. So by the time you get to the prototyping stage, your design is a lot more mature, and your prototype is not going to fail, or crash, or break. It will work, but you will need to fine-tune the design on prototype, rather than fix the design.
Yeah, and another aspect of reducing the cost is that sometimes you cause these accidental damages to the physical prototypes that you work on, just simply because you have a tiny error or issue in your software design. And that can incur a lot of cost and sometimes can even cause budget overruns with your projects. So with simulations, you can take care a lot of the edge cases so that you make sure that your design has a high level of quality before you even test it out on the physical prototype. And there are some scenarios that are very hard to test, even with real physical prototypes. And you damage or break the prototype that you're building. In these cases, you can just use fault injection or fault simulations to make sure that you have fault tolerance in your system, even if your system has encountered some errors or component failures. So you can easily model and simulate these scenarios for your system design, and that helps bring down the overall cost as well.
And as model-based design enables your team more to do more engineering work, you can oftentimes bring in some of the projects that might have been previously outsourced, too, just because of lack of time or lack of resources, as model-based design is just enabling the engineers to do more with the same amount of time and same amount of resources available. So these are some of the qualitative benefits that you get from adopting model-based design, right? Now, if you really want to put some qualitative numbers to it, I would encourage you guys to go visit mathworks.com and check out some of our user stories.
MathWorks tools are adopted by a wide range of industries and employed in a wide range of applications, so it is likely that you will find something that is close to your application, and you can draw inspiration from that story and see how model-based design can relate to success in your particular application area. But this is a quick snapshot of how some of our customers have improved their development process by using model-based design. Now, with that, I'll wrap up the session.
So we talked about quite a few things. We started about with some common industry challenges that are faced today in development processes and how model-based design addresses these challenges. And then, Tianyi walked us through the case study of Danfoss and what their journey looked like for adopting model-based design from a single project, a pilot project, all the way to making it more company wide design standard. And then, finally, we distilled some of the ROIs that a lot of our customers get by adopting model-based design.
Now, this might seem like a lot, but keep in mind that MathWorks has resources that can help you support you along this journey of adopting model-based design. Now I, as an application engineer, work with customers, and my job as an application engineer at MathWorks is to help the customer see what's capable with our tools and paint a vision on how our tools, our model-based design, can be used to solve some of the challenges that you guys might be facing right now.
But in addition to application engineering resources, we have a couple of other services available that can help you adopt our tools. For example, training can help you learn our tools faster, and we can put together custom trainings depending on the size of the engineering group that you're looking to get trained in. And in addition to that, we have consulting services as well, which is more hands-on with your project, and they partner with you in working on your project to deliver certain deliverables. In addition to that, we have technical support as well that can quickly answer some questions that you might have related to our products.
Keep in mind-- this is something that Danfoss highlighted in their adoption story as well-- that they were engaging with MathWorks support every week, and then, eventually, when they became more and more self-sufficient in the tools, they switched over to talking to MathWorks bi-weekly. So we are there to support you through a bunch of different mechanisms. In addition to this, there's a big online community of MathWorks users as well. And that's called Matlab Central. And you can also come there to ask questions and see what other projects other people are working on. And oftentimes, people from industry and academia come there to share their work that they can use and learn the tool from or just play around with to see what ideas are out there.
Right, so we talked about a lot of things, but what are, exactly, the action items that you can take action on to get started on this process or continue the process if you're already adopting model-based design or and are somewhat on halfway through the process or mid-process? So just like we worked with Danfoss, you can start out, we can-- if you're just looking to adopt model-based design, we can do things like pilot engagements where we do proof of concept projects with you guys, and do a more guided evaluation type of engagements, depending on the project. But additionally, if you are mid-adopting model-based design, and you are looking to talk to us about how to expand it and take it to the next level from there, feel free to reach out to MathWorks or your customer sales representative, and we will be able to talk to you about what's the next step from there. And with that, I would like to wrap up the session and open the floor for questions.