When M2M meets IT
Engineering and IT Insight: Subsecond latency and delivery jitter lead to lost production time and potentially millions of dollars of unrealized production. Do not let your production suffer when M2M network requirements collide with IT policies. See 5 quality of service measures.
Machine-to-machine (M2) communication was formerly a straightforward engineering job, with outputs from one device’s controller fed into inputs of another device’s controller. A “stalled” signal from a 0-5 V output from a downstream device was fed into a “delay” command 0-5 V input in an upstream device, forcing the upstream device to wait if the downstream device was not ready. In complicated situations, or where the signals do not exactly correspond, a small PLC might have been placed between the devices. The PLC would handle complex timing issues, perform simple logic, and also provide visibility into information that may not normally be available from the devices’ lights or indicator panels.
As M2M communication has moved out of the hardwired model to a data communication model over Ethernet networks, the IT department is now involved in these integration jobs. Some IT departments recognize the special nature of these networks, but many do not. IT departments that recognize the special nature will segment their networks to localize M2M traffic and protect it from general business network interruptions. The segmentation may be physical, with separate routers and switches, or virtual through VLAN configurations. M2M communication is special because of its specific quality of service (QoS), redundancy, and consistency requirements.
In an internal IT network there is little business impact if it takes two extra seconds to view an e-mail, one extra ring on a voice over IP (VoIP) phone call, one extra second to launch a webcast, or an extra second or two to pull up a report. In production environments using networked M2M, these seconds of delay per communication can add up to hours of daily lost production time in an entire facility. Even small subsecond delays can have a major impact on a lines OEE (overall equipment efficiency) rating, and cost millions to tens of millions of dollars in lost yearly production. For example, a 250 millisecond signal delay to a placement robot moving 10 parts per minute will be 1 hour of unproductive time in a 24-hour production run.
Special M2M requirements mean that IT network services need to be handled as other facility utilities, such as power, water, and compressed air. These utilities are always available, always have sufficient capacity, and have no delays in providing the service. Treating network communication like a utility means that we must measure its performance, and IT departments use QoS metrics as the most common measure. When using QoS metrics for M2M networks, it is important to recognize that internal M2M networks have more demanding QoS requirements than normal business networks where individual delays of multiple seconds may result in lost or frustrated customers, but the delays are not cumulative.
5 quality of service measures
QoS has several measures:
- Availability or uptime usually measured as a percentage with 100% meaning always available
- Bandwidth or throughput that is usually measured in total network bandwidth but in M2M environments should be measured in bandwidth available to each device
- Latency or delays in communication from a source to a destination usually measured in milliseconds
- Error rate usually measured in errors/million communications
- Delivery jitter or variation in message latency.
If your IT department does not segment its production communications from the normal business communications network, then it is vital to develop a QoS agreement and a guarantee from the IT department for your industrial networks. However, having a QoS agreement is worthless unless you also have some method of measuring compliance. It is important to monitor QoS metrics on a regular basis to ensure that normally undetected subsecond delays are not creeping into the system due to normal maintenance and system expansion.
QoS metrics should be collected, monitored, and stored the same way normal production measurements are handled. QoS metrics are sometimes available from routers or switches, but they can also be determined with a few lines of ladder logic in a PLC if no other method is available. QoS metrics should at least be monitored per network segment and, if possible, to each device. The monitoring should include some form of alarm or alert mechanism that would inform IT maintenance if guaranteed values are not met. It can also be valuable to retain the QoS metrics in your plant historian to aid in troubleshooting. This will allow you to pinpoint the time that a QoS went out of specification and maybe relate it to a replaced element, changed configuration, or router patch. This kind of information can save days of troubleshooting time trying to find which element in a complex communication path is causing the problem.
Industrial networks should be segmented and separated from normal business networks for safety and security reasons, as specified by the ISA 99 and IEC 62443 standards. However, if your IT organization will not separate them because it is hard to justify security or safety costs, then Quality of Service arguments should be used. Subsecond latency and delivery jitter can be directly related to lost production time and potentially millions of dollars of unrealized production. Do not let your production suffer when M2M network requirements collide with IT policies.
- Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl(at)brlconsulting.com. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering and Plant Engineering, mhoske(at)cfemedia.com.
This posted version contains more information than the print/digital edition from May 2013 Control Engineering.
At www.controleng.com, search Brandl to browse related topics or see the three links at bottom.
See other articles for April 2013 in the Control Engineering online archive.
Case Study Database
Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.