We're diving head first into providing remote machine automation diagnostics and troubleshooting services. We find many options, including whether to house the service in "The Cloud" via a third party or maintain the data ourselves and control it all from our offices. After the initial cost, it appears less expensive to do it ourselves. Do other builders have experiences they can share?
—From August '11 Control Design
Answers
Potential Revenue Stream
We're a system integrator and recently had an OEM approach us with this very need. The OEM has machines distributed across the U.S. and in a couple of other countries. They needed production and status information transmitted to a database from each machine each hour to display on a website for their users. They wanted alarm information transmitted immediately, and they also wanted the ability to remotely modify parameters and set points.
In this case, the OEM would sell a number of these machines to each of its customers. These customers would then place the machines in remote locations and maintain them. The OEM wanted to collect the information and sell a subscription to the data to its customer. Having real-time data and the ability to remotely interact with the machines provided the OEM with a value proposition that would increase demand for its machines and create a new revenue stream.
As it turns out, the technology to do this is readily available. We already had a PLC in the machine, and we just upgraded it to an Ethernet version and developed PLC code to send encrypted information over the Internet. We added a cellular option for machines without hardwired Internet access. Next, we wrote a service in C# to provide the interface between the PLC and the database. This service must run on a computer with a static Ethernet number on the web. From here, the sky is the limit. We developed a web interface where users can log into their portal and see their machines. They can configure email or text notification of alarms. They can even change machine setup and send the new configuration from the web browser. For on-the-go access, we developed an iPhone app.
Although all of this can be done, it is probably over the heads of most machine builders. Unless you have software people on staff, I suggest getting a software company involved for the truly technical portions. Our customer has taken a balanced approach split between a cloud deployment and in-house development. They are paying for external hosting of the system, but maintain full control of the development by partnering with a software company. For them, this has worked out very well.
Keith Jones, PE, President,
Prism Systems, www.prismsystems.com
Cloud Safety
The first question you need to ask is how sensitive are the data and systems that you are considering putting into the cloud? If this is proprietary information, I would stay away from the cloud at this point.
You don't mention what industry you're in, but this may also be a situation where your customers might drive your decision. In some cases, their production data might be extremely proprietary, and they would have concerns about their competitors gaining access. Their data security team also might have policies against remote access through third parties. I am not yet convinced that the cloud is a very safe place to store proprietary data.
You will also need to review the agreements with your third-party cloud supplier to see what type of access they might have to your data, even for maintenance purposes, or what happens if they have technical difficulties. Now, if you are planning to use the cloud only for public information, then I wouldn't have this level of concern.
Jack Rupert, PE, Consultant,
www.linkedin.com/in/jackrupert
Harder Than You Think
As a manufacturer of remote I/O modules capable of supporting remote monitoring, we have some experience supporting both locally served and cloud-based data acquisition. There are advantages and disadvantages to both approaches, and a thorough evaluation is the first step to ensuring a cost-effective solution that also will meet the performance expectation both in function and security.
Expense is always a significant factor, but certain aspects of function will be of primary importance. For instance, if security is a significant issue, and the remote connectivity cannot provide certain high levels of guaranteed security, the cost is no longer relevant; the solution is not acceptable. In some instances, the cost will become the limiting factor because of function—that is, to get the necessary functionality, cost will become prohibitive.
If diagnostics and troubleshooting are strictly limited to data acquisition—reading data only with no possibility of remotely writing data or influencing any aspect of local control—then either a local SCADA server or cloud-based system might work well. However, even when data is only being read, it is possible for confidential or competitive corporate information to be compromised.
The actual implementation could be relatively easy. Many SCADA and HMI software solutions offer remote access as well as options to manage diagnostics and troubleshooting. This typically includes the ability to report alarms by text message to cell phones, or through standard email messages, and could allow a thin client method of reviewing the current operational state using remote browsers such as WiFi pad computers or smart phones.
Our customers have taken a wide variety of approaches to remote diagnostics and troubleshooting. Some approaches have been very complex and expensive, and others have been very simple. The single common thread is that most users implementing this sort of process find it is more challenging than at first anticipated.
Mark Lochhaas, Product Manager,
Advantech, www.advantech.com
Hidden Costs
Our experience shows that it is difficult to calculate the true costs for a self-hosted remote access solution over time. Although companies start with well-defined project plans and detailed budgets for the initial costs of the equipment, infrastructure, development and operation, there are costs that rarely are considered at the beginning of the project.
These costs are mostly related to the maintenance and level of service expected over the years. During the development phase and early deployment, expectations are relatively low, but quickly the customer's expectations for quality and availability increase. It is difficult to estimate those costs unless the company already has a very deep knowledge about hosting solutions. It is also common to underestimate overhead costs of managing the servers and the infrastructure, monitoring the servers and the applications, upgrading the services, and responding to alarms and failures.
With a subcontracted, cloud-based solution, certain economical and organizational scale factors are appealing for machine builders, system integrators and end users. When considering a cloud-based solution, it is important to fully understand the service provider's pricing structure and select the best service and support.
Francis Vander Ghinst, Sales Manager,
eWon, www.ewon.us
Third-Party Connection
For much of the remote troubleshooting and diagnostics we do, we use GoToMeeting software. It lets me take control of my customer's remote computer to edit programs and examine data, while helping me give the customer better instructions on how to use our motion control software.
I recently used GoToMeeting to troubleshoot a problem at a dam in Pennsylvania. Working remotely from our headquarters in Washington State, I helped choose which data to record. I set up our motion controller, and wrote the programs necessary to gather the data. Then I helped analyze the data, using our software on the customer's system to generate plots. Working remotely, I saved perhaps $20,000 in plane trips, time, food and lodging. But the key factor is time—I could fix or change the program in just a few minutes over the phone instead of wasting a day just getting to the site.
Peter Nachtwey, President,
Delta Computer Systems, www.deltamotion.com
Leaders relevant to this article: