Great look ahead at the challenges plant engineers face as they try to transform their assets to meet the real-time and visibility challenges of the digital factory of the future. I agree that the progress made with visualization tools (digital manufacturing suites like Dassault's DELMIA and Siemens' Tecnomatix to name a couple) as well as around graphical programming platforms like National Instruments' LABView which you mention, are critical to facilitating this transformation.
What is also critical is that manufacturers build out seamless integration points between production systems and product development platforms like PLM as well as with other core enterprise systems. You are absolutely on target that not all shops will have the hands-on expertise and foresight to bridge the plant mentality with the enterprise mindset. But they better get busy learning how if they want their plants to enjoy the benefits of this new age.
I re-read the article today and was thinking about how this technology could apply to manurfacturers that have to bring together different subcomponents from different side lines and subassembly lines. Quite different from the counting of units from the beginning of one line to the point where the two subassemblies come together.
There is an interesting generational aspect to the "digital factory of the future." Engineering students who would not ordinarily be attracted to spending a career in a dirty old plant are now discovering that plants are no longer dirty and that you get to run the plant from laptops, iPads and smartphones. The evolution to the plant as an elaborate video game is getting the attention of young engineers.
Great, point Rob. With that, the latest in sensor and automation technology, and tight integration into the enterprise, the plant becomes a much more critical and desireable place to target career aspirations.
I can't help but chuckle as I think about the latest video game called, "Build you own warehouse." or something like that. But it is neat to see how technology is changing so much how we assemble things. It's no longer done on paper or even through a cad program but through simpler drag and drop programs. the nice part about this is it does allow less experienced engineers be able to focus on doing the job and not learning how to use the tools required to do the job.
Upon reading your article Alex, I'm struck by the common theme between Factory Automation and Justin Moon's article on Multicore MCU Medical Devices. Both systems are developing toward rapid configuration changes and real-time upgrades; one system for monitoring a manufacturing process, the other for monitoring patient health.
What really concerns me is the current political climate that drastically increases the cost of human labor. Healthcare costs, safety compliance, wage pressures, union labor rules, disability compensation, worker litigation and pension costs are pricing humans out of the equation. While automation is a natural evolution, these pressures are rapidly increasing the arrival date of the completely-automated factory. Companies that have off-shored in search of less-expensive labor are finding the actual costs of lower quality, lower yields and higher returns of merchandise are as high as producing domestically.
While politicians continue to bicker over the best way to create jobs, those jobs are rapidly being lost to automation. This may be great news for the Industrial Automation and Control sector, however; those high-paying abundant manufacturing jobs are most likely gone for good. I am concerned the displaced workforce will point to automation as the real villain and usher in an entire bureaucracy to regulate the development of the digital factory of the future.
As an Engineer of some 30 years experience I would say this is an attempt to get engineers out of the bulk of the development work, so that monkeys can knock something up for peanuts. While that sounds like a good idea on the surface, I'd say that it will result in a situation where when real engineering is needed they won't be there because no one will want to pay them due to the expectation that "anyone can do it". I was talking to a colleague a while ago about Labview, which is the quintessential visual development GUI and he said that there are so many things it just won't do well, saying that he has to do so much in 'C' or C++ to get something real happening. Sadly he will be expected to do that real work for the same wage as the command line inept engineer. Instead of smartening up engineers we just end up dumbing them down to everyone's detriment.
The digital factory has been in existance for several years. I've been retired for over 10 years, but before I retired I visited Mobalpa, the largest kitchen cabinet manufacturer in France. This was thier very new and modern facility located in the Thones Valley. Every skylight looked diractly at Mt Blanc! (NICE!)
They were producing totally mixed models, mixed sizes and mixed colors of kitchen cabinets - to custom order - across a sophisticated automated line - lights out. Sure I was surprised, but it was really simplistic. The idea is to have all the components arrive at final assembly and packaging at the same time. EVERYTHING was controlled by bar-code, even recieving. Bunks of 2 meter by 4 meter pre-laminated board were off loaded from a semi, barcoded and sent to an automated warehouse. All machines set themselves up using barcode for each individual part required for the order!
If an in-line machine went down, an alarm was shown on the main board. The maintenance crew was immediatley dispatched to make corrections. When a machine went down, a device immediatley in front of it started stacking the parts off line. The front end of the line continued running until the fault was corrected. When the line was re-started the device that stacked the parts aside would start adding parts to the line as space was available. This was a fairly new line, but it was operating at over 80% up-time.
If your company would spend the money, you copuld have the same benefits!
@atired1. Some of my colleagues have been to high automation plants in China, Japan and Germany. They are very impressive to watch and surprisingly cheap to build and operate once you do the ROI calculations. It’s like anything in this world, you have to spend money to save money.
If a company has lazy management, they will just cut wages and quality. For some strange reason they are surprised when customers go elsewhere.
In my earlier post, I failed to mention that the designer of the line was an independent Italian Engineer. and almost all of the equipment was Italian built to his design.
I've been through several German and Italian manufacturer's plants that are really automated, A German manufacturer of large machines had several cells of automation where you least expected them - but it removed labor and assured quality. One was an automated line that produced long feed chains that had to be within a very close tolerance at over 90ft. length as they were used in pairs - up to 12 or more feet apart, with parts driving lugs on each. They shared a common drive axle.
I had designed and had built automated robotic welding lines that produced various sizes of the same product every time, as long as all parts were in the proper nested position. If all parts are positioned correctly, the desired welded result is the same. That's something people can't do is replicate the same weld every time. It takes monkeys out!
Another thing of importance, the European companies have a very high ratio of apprentices to skilled laborers. They perpetuate the skills required to build high quality automation, allowing the engineers to put thier full attention on designs - and not have to constantly put out fires.
I would imagine we will see fewer and fewer differences in plants in Asia, Europe and North America --- or even South America. So many of the vendors and contract manufacturers are global. Plus, the digital plants are effectively portable. Manufacturers -- and utilities -- are wrapping up their digital best practices from their top plants and conveying them to plants around the globe (when possible). In conversations with Siemens and Rockwell, a good portion of their new-plant business is in Asia, Eastern Europe and South America. Clearly regional differences will be diminished.
The whole greenfield versus brownfield dynamic is a very real issue in update of advanced digital technologies in the factory, including build-out of wireless networks. So in the U.S., corporations have all this cash with nowhere to go. (That is, they're reluctant to spend it on infrastructure upgrades without sales upside to justify it, notwithstanding the fact that most manufacturer execs are dying to do the upgrades.) In China, OTOH, greenfield plants WILL utilize the most advanced technologies. What does this say about who will be in a better competitive position a few years out. Scary stuff.
Good points, Alex. I hear from automation vendors who say their newest technology tends to go into greenfield plants, which, as you observed, tend to be in developing countries (China, India, East Europe, and South America). The technology in brownfield deployment tends to not be as advanced, since it's usually an add-on.
I remember we faced a similar problem with Japan in the decades after WWII. They had new plants that the U.S. has helped them build. The U.S. had pre-WWII plants. The Japanese plants were more advanced than and thus it caused the U.S. some competitive challenges, particularly in automotive.
I'm still hearing that U.S. plants are the most productive in the world. Not sure how that can be when the greenfield plants outside the U.S. are getting more of the newer technology.
I wonder how much of this knowledge base can be encoded into an AI like IBM's Watson. Once the AI is taught or loaded with the manufacturing details could it then "reason" about it and come up with improvements and new processes? I understand Rule engines can be applied to greatly simplify logic operations and that might help as well. I think bringing in more AI into the Design aspect could be a factor.
The remark about video games and the plant being a big real life version of a game struck me as interesting. Perhaps one of the main impediments to automation is in the ability to visualize the complete process from many view points and then drill down into each step within the processes.
Creating software that looked like a video game but in fact represented an automated factory in all its details might be useful. Seems like in the examples given there are lots of logic switches like what to do if this happens and so on.
My suggestions then are related to making the Design of these Digital factories more driven by AI and Rule based systems. With appropriate constraints and oversight maybe that would help.
I agree, Ivan, the plant as a video game is interesting. One thing I'm hearing is that it used to be difficult to get engineering graduates to go into plant operation. That apparently is changing as plants become more digital. What I'm hearing now is that young engineers are now attrracted to plant operation because of the software and connectivity. The young engineers also take to the digitized tools more quickly than the senior engineers.
As Bill Weaver says, rapid configuration changes and real-time performance are the hallmarks of the emerging digital factory. So I'd say that this is NOT something which was capable of being implemented a decade ago. The technology was not compact, nor flexible enough. As for China eating our bacon, it is true that the digital factory in the form I've written about doesn't come cheap, so ROI could be a real roadblock to widespread adoption (meaning China undercutting on price could slow deployment down).
There are some interesting claims made for drag and drop graphical programming. It certainly would allow people who are not masters of code writing to produce programs of some kind. But software, far more than hardware, is often unable to handle exceptions and failures. We all know that to be true.
A fundamental requirement for repairing things, if the process is to consist of more than randomly replacing parts, is to have an understanding of what the system to be repaired is supposed to be doing and how it is supposed to work, which are the two things that the packeged graphical programming environment is intended to conceal. A line-by-line analysis of some process diagram program is considerably less informative than the somewhat older formats. So I see more than a few challenges when these systems have a failure occur.
William K makes cogent comments regarding software exceptions and understanding of systems as a whole. Both issues are part of what I was getting at. It's not that I'm not a believer in the flexible digital factor (a better way of phrasing it that "digital factory of the future"). It's that we need to be realistic and realize there are no magic bullets, notwithstanding the fact that graphical programming is indeed a workforce multiplier and does allow non-programmers to do lots of useful stuff. It's when the bits hit the fan though that there are sometimes problems for them...
Alex, It's interesting how ultimately software is both the biggest obstacle and key trend/enabler for moving ahead. There are many interesting developments in automation control software with simulation tools, the move to model based design plus the continued emergence of object-oriented programming as a way to reduce overall complexity of code. But there are also the needs for more software convergence that leverages available network infrastructure, better diagnostic tools and processes that more efficiently combine design ideas and prototypes with system integration and deployment.
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.
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.
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.
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.
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.
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.
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'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.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
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.