Skepticism is a useful attitude when evaluating claims of transformational approaches to engineering development. I have wandered down a number of what turned out to be blind alleys in my career. However, based both on my personal experience and those of multiple companies that have adopted Model Based Design, I can assure you that the hype in this case is fully justified.
During my career at Caterpillar Inc, I lead a group that was responsible for machine and engine control system development and was charged with the responsibility of improving both the process and tools used for controls development. After considering a number of development methods to improve our capability to develop control systems I selected Model Based Design and the MathWorks toolset. Our initial efforts were focused on Rapid Prototyping. In these applications we achieved a 70% reduction in the time to first working prototype. Based on this success we began a move to utilize automatic code generation in production applications. This was not, for us, a quick transition but rather occurred in stages over a period of time. The ultimate result was a complete adoption of automatic code generation for all machine and engine applications across the corporation. Savings exceeding 50% were achieved on large complex applications.
This success has been achieved by many companies of different sizes and with widely varying applications. The MathWorks website ( www.mathworks.com) contains many case studies that testify to the advantages that have been realized.
While I encourage you to retain your skepticism when encountering claims of transformational development approaches, I encourage you to give Model Based Design consideration. The rewards will exceed your expectations.
Best Wishes for future success,
I have heard this same story for the last thirty years. Promises, Promises, but nothing useful.
If you believe this approach will really work, hold a contest. Use a simple set of requirements for a basic system. Have a group of engineers use their methods, you use your fancy tools.
When either side gets a finished design you stop. If the design meets the requirements it wins. Then you let the others finish to see how much longer it takes. You compare the % of requirements implemented correctly on the first version, count the number of errors/mistakes/screw ups and then you do a comparision chart.
When your tools can create a working system with maintainable code, meets requirements, gets the job done faster with less resources, then you have a practical approach.
Stop wasteing everyones time telling us it can be done, DO IT, then I will be interested. Otherwise it is just another worthless academic exercise.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...