Yes, I agree with Glenn, although I think a solution like this can be helpful in some situations. But sometimes there is no replacement for a live person who can quickly assess the situation and get the job done quickly and correctly.
I have done telephone support for industrial machines, and sometimes a technician has to be on-site to diagnose the problem. Many times I have diagnosed a problem on-site because the operator couldn't properly describe the problem on a telephone call. To reduce downtime, the first choice is to try to fix the machine remotely through a telephone call.
This is a great application of secure connections to help with production problems. As a practice, my company does not run external communications to our machinery due to security concerns. These highly secure connections would help to sway our IT department. We had a recent application that required error monitoring on a new piece of machinery, but we needed to have the supplier stay at our facility and send information back to their headquarters via e-mail. This system got the job done, but it was inefficient. If the supplier could continually monitor the machine, they could have had better real time data and supplied us with a solution quicker.
Interesting concept, Al. I'm curious, though: Is diagnostic ability limited as a result of the outbound-only communication set-up? Seems like bi-directional communication would be an important of a system like this one.
Thanks for the quick reply, Al. I come from that PS/2 generation of technology fans that projected virtual reality and flying cars by 2001. I still find it difficult to integrate reality into my musings of a connected future. Maybe we are getting there, albeit, slowly. I agree that remote diagnosis is an awesome ability. Perhaps remote machine diagnosis is following the trends in remote diagnosis for humans.
William, I can attest from first hand experience working for an automation supplier that cost, but also the speed of dealing and resolving problems, has been driving the move to remote support for easily more than 10 years. The ability of a skilled engineer or technician to immediately logon and review code in a control system is a huge benefit. For machinery builders, it definitely reduces support costs and enables (for the hardest problems) to have key engineering staff to review the app versus sending someone on the road.
Al and naperlou, I wonder if it is possible to quantify how much of this movement to remote monitoring is being spurred by high cost and how much is the natural result of automation. I appreciate that there are lots of security issues and even more OEMs involved, but hasn't this capability existed since the early 1990's with the founding of ODVA.org? Perhaps there is a confluence of higher cost and lower resistance to change that is enabling this now, 20+ years after it was technologically feasible to do so. One generation later in human terms, 13+ generations in Moore's terms...
Al, this is an interesting application, and a good solution to a major concern. It makes no sense to have an engineer outside of the facility controlling machines inside the facility. On the other hand, there is a lot one can discern about a system with a steady stream of telemetry. In addition, as mentioned, the smart controllers can generate alerts so that support engineers can assess the health of the system. All in all a good thing. This was, of course, done in the computer industry, primairly in mainframes, many years ago. Those were "smart" systems, so it was natural to do it.
The transformative nature of designing and making things was the overarching, common theme at separate conferences held in Boston by two giants in the PLM space: Autodesk, with its Accelerate 2015, and Siemens’s Industry Analyst Conference 2015.
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.