I'm, not surprised to hear this Apresher. It's my understanding that simulation and visualization tools are used mostly on greenfield developments. If that's true, that certainly limits the use. However, I'm also hearing that simulation and visualization tools can save significant dollars in preparing the plant for operation.
Rob, I think in many larger organizations the communication and structure is more formalized. Model based design and simulation tools are used more frequently. For factory automation and machine builders, my perception is that it is less common. Recently I talked with an automation vendor that estimated only 10% of customers are using simulation/visualization tools. Model-based design by its definition encourages sharing of models and allows engineers to create models that encourage collaboration as part of the process.
I would think the communication between disciplines would have improved by now. Certainly collaboration tools have improved mightily. Plus, many organizations are forcing collaboration through new tools -- i.e., things don't move to the next step until someone from each discipline has signed off on that last step. Perhaps this isn't yet happening to any great degree in design.
One area where using model-based design tools to develop automation software would help is the ability to capture many of the details of what would be a system specification within the tool itself. I completely agree with your point that communications between the disciplines involved in designing, building, and programming manufacturing equipment is a major roadblock. Even though several automation vendors are offering these types of software solutions, it's not clear at this point how much traction these solutions will achieve in the short term.
My solution to the reluctance of some to describe in detail a sequence of operation has been to make it a fundamental part of a systems specification. The specification is the fundamental means of deciding what a system must include to accomplish whatever task it must accomplish. At that point I am able to have everybody agree that it is very hard to create a system, or a machine, without an understanding of what it must accomplish. We save time and money by sharing this description with a customer prior to starting work, both design and manufacturing work. It is also an easier way to avoid forgetting to include some portion of the required performance. While developing the specification is not a small matter, it certainly is worth the effort.
I would agree that communications between the disciplines involved in designing, building, and programming manufacturing equipment is generally poor. I am a big fan of putting things in writing, but it seems to rarely happen.
ttemple You are quite correct. On the other hand, though, the mechanical engineer who designs a machine should certainly have an exact sequence of operation in mind during the design. At least I hope that they would. On the other hand, I have written detailed functional specifications for programmers to use to write control programs for machines designed by folks who did not consider a sequence of motions. Sometimes the task was a challenge.
It would be quite exciting to watch the operation of a system with the mechanicals created by programmers using drag and drop designing. But I would choose to watch it from a safe distance, since I have serious doubts about "designs" created by those who don't understand the mechanics of what they are creating. Understanding is sort of vital to getting things to work "right". Someplace in the world there is a system that may eventually kill somebody because the preson doing the program used a "double negative" to correct a hardware configuration problem. The result is that an air valve defaults to the wrong position when the control program freezes. This is a real thing, not a theoretical example. The problem was that the programmer did not understand the hardware.
The challenge of writing good code is in making it clear what the various software functions actually do, whaich, making it clear would also allow others to produce good control code if they understood what it had to do. Understanding a machines operation adequately is the first requirement for creating a good control program. It is probably the most critical one as well.
One of the biggest walls in embedded software development is the integration of low-level drivers with higher-level middleware and application code, but silicon vendors are stepping up to bring it down.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.