Thanks for the perspective, Tony, and a great description for how the adoption tends to unfold within organizations. Jon: Thanks for the recommendation on a book for change management. Whether it's about leading a culture of model-based design or some other type of major process change, I imagine there are some good takeaways for overcoming resistance.
John and Beth are correct about the challenge of embracing Model-Based Design for developing embedded systems. My own experience is that companies gradually adopt, usually starting with control system engineers. The progression is usually multiyear, beginning with desktop simulation, moving to real-time testing and validation, and ending with code generation for production systems. This approach provides increasing value at each stage, can be woven into existing design practices, and avoids the unwanted shock of a complete change to a development process. Industries are in different stages of Model-Based Design adoption. The Aerospace and Automotive industries are leaders, primarily because their software systems are very complex. In 2010, Design News discussed, http://www.designnews.com/document.asp?doc_id=229640, how the Automotive industry is adopting Model-Based Design. Within the industrial markets, automation suppliers developing motor controls and power backups, and solar and wind energy companies developing renewal energy sources are the furthest along the path. As my colleague Ken Karnofsky said in the article, "Software complexity is the big driver." But we are seeing more interest from the traditional machine builders. Recently an engineer with whom I was meeting pointed out that it is the software that running in machines that is becoming more complex, not only the hardware.
Thanks, Beth. Here's a book I recommend highly, "Driving Technical Change; Why People on Your Team Don't Act on Good Ideas, and How to Convince Them They Should," by Terrency Ryan, published by The Pragmatic Bookshelf. The author describes the types of people we typically find on a team, from the uninformed and the herd to the cynics and irrationals, and he explains how to work with them and get them on-board with new tools and techniques. (OK, you can't convince the irrational people.) Although the book used programmers for its examples, the information applies equally well to engineers who should adopt model-basded design. At 128 pages, the book is easy to read in one evening.
Jon, I don't think I could have said it better (in fact, I know I couldn't). You really just described the biggest hurdle to model-based design. Because it's an entirely new way of thinking and because it requires a completely different mentality of cross-functional collaboration, there will ultimately be push-back from engineers who don't thoroughly understand the benefits and are reticent to make any kind of change.
To embrace this on a grand scale throughout an engineering organization will require a robust change management effort and as you mention, a champion. Bringing in model-based design tools on a piecemeal basis won't be enough to foster any kind of sweeping process change.
One of the big advantage of model-based design centers on breaking the "toss it over the wall" mentality that companies have had for years. Various departments, from marketing down to production had "walls" that blocked communications and thus caused problems. Design changes sometimes got misinterpreted due to lack of proper documentation and lack of regulat communications. By clearly defining system requirements at the start and giving everyone access to them, model-based design techniques help companies complete designs faster and with fewer problems. And because engineers can actually execute the models, they see how circuits, mechanics, and software work together before they build anything.
But, model-based design requires a large commitment of time, talent, and loot and a company that wants to make the jump needs an evangelist who can "sell" others on the virtues and benefits of this approach to designs. Not all engineers will want to jump on the bandwagon, though.
Responding to Tony, I don't think there is any question but that modelling and simulation can be tremendous assets in developing better and more efficient automation control solutions. The key is that it will require a different way of thinking from the past, and probably experimenting with software solutions and sample projects for engineers to get comfortable. Getting past the questions of whether it will be worth it is important, especially since many companies already have their systems modelled already. Good stuff.
MapleSim, from Maplesoft, is a model-based design tool built on a foundation of symbolic computation technology. It handles all of the complex mathematics involved in the development of engineering models, including multi-domain systems, plant modeling, and control design. It is the only comprehensive modeling system built within a natively symbolic framework. Therefore, not only does it save model development time from months to days, but also avoids some of the worst sources of error and computational inefficiencies generated by traditional, numeric-based modeling tools. Leading automotive and aerospace manufacturers, electronics system designers and high-end robotic design engineers are using MapleSim in their work. You can read more about it here: www.maplesim.com
I think that Al is seeing an emerging trend by industrial automation suppliers to support Model-Based Design. Besides FESTO, B&R Automation, Beckhoff Automation, and Bachmann Electronics all have targets that accept ANSI C-code generated from Simulink models. Siemens, too, offers a means to port C-code to a PC-based controller. This connectivity helps machine builders perform control system design using simulation and implement on their controllers.
Nice post!! It gave the knowledge if how the equipments are developed. Model based designed is an aproach to eveolve a platform for communicating through the entire design process in process of development cycle. The development is carried out through development of a plant, developing a device to control a plant, simulate the device for plant and the plant itself, and lastly intergrating all these.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.