Recently my team was given the opportunity to completely redo a particularly messy and troublesome piece of legacy C code, and as a team we decided to give MBSD a try. We had tried a few simple models before, all of which turned out to be more complicated than had we written the C code ourselves. But this time we were determined to do it right: we allocated plenty of time, received one-on-one training from the local MBSD guru, and reviewed the original requirements to ensure they met the needs of the system. Finally after exhausting all of the time, continually pestering the guru with questions and modifying the requirements several times, we succeeded in having a model based software design that actually worked the first time we tested it on the vehicle. It was a valuable experience overall and helped illustrate the drawbacks and benefits of MBSD over the typical C development.
One of the biggest drawbacks was a much steeper learning curve than we were expecting, after all how hard could connecting some blocks and creating a few flowcharts be?
The answer is that MATLAB Simulink is complicated. Really complicated, to the point, even the guru didn’t know how everything worked. And learning all of the quirks of the MATLAB environment on top of the modeling syntax took more time than we had originally planned. The other main drawback we didn’t notice until we actually generated the code was the realization of how easy it was to do something in the model, but at the cost of horribly inefficient generated code. And so we had to reiterate over the model to improve the resulting code to that point that it would work on our limited embedded controller. These drawbacks in turn brought up the question of why we were even using MBSD when writing the C code ourselves would have been faster and more efficient.
The answer, of course, is the benefits we gained by using MBSD. The ability to run simulations and debug the model in real time is very powerful. This alone made it worth the effort to learn MBSD and resulted in the generated code working perfectly the first time we tested it on a vehicle. It’s also great for maintenance as you can easily run the simulations before and after the change and verify that no unexpected bugs were introduced into the system. Going forward, we will definitely be using simulations more as they really helped improve the quality and our confidence in the product we release. Another benefit is that we can link the requirements documentation directly to the model to ensure future developers will know why the model behaves as it does. We are also able to use Design Verifier to create test cases in the model to perform unit testing without affecting the generated code in the controller. Finally we are able to take the model and connect it to the models from other groups, which will allow us to test and debug the vehicle system as a whole without needing the vehicle itself.
Overall, I now see why some development is moving to MBSD. It certainly doesn’t replace embedded C for everything, but it does allow for much better verification of the system before releasing it to the field. I have found that simulations allow for more complete unit testing while being easier to create than normal C testing frameworks. And after working with MBSD for about 4 months now, I’m starting to feel comfortable in both MATLAB and modeling and plan on continuing to use MBSD for future projects.
Comments are closed.