I've been thinking a lot about the "Digital Factory of the Future," the term Siemens has been using to telegraph the increasingly hurried-up product to production cycles that design engineers need to support via flexible automation setups.
PLCs and PACs with higher capabilities for programmability and intercommunications are the cornerstones of factory automation. The other linchpin is easier and more global programming capabilities.
In plainer English, this means two things. First and foremost is enabling engineers to sidestep command-line programming -- something most aren't fluent in -- and instead use some kind of graphical or drag-and-drop paradigm. (Secondarily, despite the fact that hardcore software types will always frown on what they see as a "for dummies" approach, the salient point is that today's visual tools are finally for real.)
Siemens’ PowerPoint about the "Digital Factory of the Future" spotlights tight integration from prototype through production.
The other underpinning of the digital factory is the ability to deploy that software globally to all PLCs/PACs within a factory, extending out to remote or wirelessly connected production operations. Here, a collateral but significant outgrowth of such tight interconnectedness is the ability it gives plant engineers to route sensor data back to a centralized location. From there, they can monitor operations more closely -- and quantitatively -- than ever before. This enables tighter control, minimization of failures -- or, more correctly, quicker fixes -- and a host of subsidiary benefits like better compliance. (It should be noted that sensor angle is perhaps even more of a benefit in the process automation arena.)
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.
Just as it would be quite exciting for me to watch a system where the mechanical engineer programmed it with drag and drop software.
I was illustrating absurdity with absurdity.
The best way to complete a project is by using the right people to do the right parts of the job, not by creating "tools" that make it appear so simple that the wrong people try it.
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.
For 3D printing to make the jump from rapid prototyping to manufacturing, engineers will need to find easier ways to move products from their CAD screens to their printers.
Gigabit and PoE are two networking technologies moving ahead in tandem as industrial users power remote Ethernet devices such as IP security cameras at 1,000 Mbps over existing CAT5 cable.
New versions of BASF's Ecovio line are both compostable and designed for either injection molding or thermoforming. These combinations are becoming more common for the single-use bioplastics used in food service and food packaging applications, but are still not widely available.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 5
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
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 radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
1 
