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.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.