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.
ABI Research, a firm based in the UK that specializes in analyzing global connectivity and other emerging technologies, estimates there will be 40.9 billion active wirelessly interconnected “things” by 2020. The driving force is the usual suspect: the Internet of Things.
Just in time for Earth Day, chemicals leader Bayer MaterialScience reported from the UTECH Europe 2015 polyurethane show on programs and applications using its materials to help reduce energy usage. The company also gave an update on its CO2-based PU as that eco-friendly material comes closer to production.
Solar and wind energy are becoming more viable as a source of energy on the electric grid. For decades, the major drawback to solar and wind was that they’re temperamental. A cloudy day kills solar and a still day renders the wind turbines useless. Automation tools, however, are providing a path to help these renewables become practical.
In honor of Earth Day, the National Security Agency has launched the STEM Recycling Challenge in Maryland schools to encourage kids to think about where the garbage they throw out every day actually goes. The agency has also introduced “Dunk,” a muscular blue cartoon recycling bin wearing shorts and sneakers.
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.