Search Results

Here we examine the history of the 3 serial interfaces used today and explore the common issues found with them and the benefits of each of the 3 different connections. RS232: Down but not out Once a standard feature on personal computers, the RS232 serial port was one of the first used to connect data terminals to mainframe computers. It remained in widespread use for serial communications between PCs, printers and other peripherals until the late 1990’s, after which it was superseded by USB. However, RS232 ports remain in use today in the industrial sector. RS232 Connection and Configuration Connecting a RS232 port to a laptop usually requires a RS232 to USB converter like our  Define Multicom . Typically they are used as programming ports to configure instruments and controllers, and are also used in  SCADA (Supervisory Control and Data Acquisition) systems . SCADA systems gather data from RTU’s (Remote Terminal Units) like controllers or meters, and then display the results on a PC. Here, RS232 ports are used for several reasons: There are many reported problems with RS485 cards. Instabilities caused by the Windows operating system controlling the flow of data leads to unreliability across many SCADA programs. To get around this, SCADA systems prefer an RS232 card (which does not have any flow issues) coupled with an external RS485 to RS232 converter like the  Multicom . RS232 cards are more readily available than RS485 cards. Another common application for an RS232 port is in small printer applications. Typically an instrument like a panel meter can drive a printer to print items such as weigh bridge dockets or to drive a cell phone modem. Issues with RS232 Connect what to what? There are three pins used for signaling on a RS232 system: Rx – Receiver Tx – Transmitter Gnd – Signal ground (There are other signals in the specification used for hardware handshaking such as RTS and DTR, but these are not used in Define Instruments products.) The original standard makes a distinction between a computer (master device) known as DTE (Data Transmission Equipment) and a slave device known as DCE (or Data Communications Equipment). The labeling of the DCE becomes an issue, in that the Rx of the computer must be connected to the Tx of the DCE, and vice versa.  As many instruments now can act as both master and slave (e.g. driving a printer), this leaves the quandary of how to label the device: DTE or DCE? Over the years, manufacturers have not shown consistency on this point. This has been further complicated by manufacturers of devices that are limited by their size opting to not use the official connectors of the standard (as they are too bulky). As a result, the system cannot be identified from the connector as DTE or DCE. Thus one is left without knowing which way to connect: Rx from the device to the Rx of the computer, or the Tx of the computer to the Tx line on the device. Employing trial and error is all that remains. Fortunately, incorrect connection of the pins is not damaging. If wrongly connected, the driver chips simply won’t work. Cross over cables are so named as they perform the cross over in the cable, and are a very handy addition to a technician’s toolkit. Caution is required when grounding the RS232 signal Most desktop computers ground of the RS232 ports are internally connected to earth. This presents problems if the DCE’s serial port is not isolated from all other signals. For example: a DCE serial port ground maybe referenced to another signal in a system which is not grounded. Connecting the grounds together in this case will short points together which are at different potentials, and more than likely cause damage to the PC or device. To get around this, the device’s serial port must be verified as a fully isolated design.  All Define Instruments RS232 ports are fully isolated.  If the port is not isolated, then one must use an external device that isolates the serial ports. (The  Define Multicom  can be used to galvanically isolate two RS232 ports.) Variable protocols The RS232/RS485/RS422 standards only relate to the hardware interface, not the software protocol required to make the buses communicate. There are numerous protocols (both open standards and proprietary) that exist in the market place. Hence one cannot assume interoperability between different manufacturers of “RS232” ports. Define Instruments supports a mixture of industry standard and proprietary protocols: Modbus RTU This protocol is widely used in industry and most SCADA packages and PLC’s have drivers for it. However a word of warning using Modbus: although the Modbus protocol is well published, every manufacturer can and does determine its own addressing scheme. This means the manufacturer must supply the addressing scheme, register type, and Modbus commands supported, for successful integration into a Modbus system. ASCII protocol The reason ASCII is popular is that it is easier than Modbus to write your own driver in a PLC or a PC. Define has its own protocol based on ASCII characters. Again, every manufacturer’s protocols – although similar – are not usually compatible. String outputs Define supports two streaming string outputs. In these modes every new sample is streamed out in ASCII to the serial port. A computer on the other end can easily disseminate the reading in between start and stop characters. This type of output is very popular in the weighing industry as it is used to drive computers, large displays and summing units. RS485: Still popular The RS485 port has been used successfully for many years, and while RS232 installations are in decline, the RS485’s popularity shows no signs of abating. The RS485 has many advantages over both RS232 and USB when it comes to applications in noisy industrial environments.  It was designed from the beginning to be tolerant of noise and forgiving of long cable runs . It achieves this by using a differential current drive output which has high immunity to noise. While RS232 installations are in decline, the RS485’s popularity shows no signs of abating. Another major advantage is that users can have more than one slave on the BUS. The original specification stated a maximum of 32 slaves, due to the leakage of the then driver chips. These days the chips have improved, and many can support up to 256 slave devices. The slave units are simply wired in a daisy chain configuration, meaning one port can talk to 256 slaves. This is great for large SCADA systems and comes at a very low cost to implement. Issues with RS485 Timing of the controlling BUS The RS485 signaling system uses two wires to achieve its drive: A+ and A- sometimes referred to as A and B, or D+ and D-. These two signals, along with a ground signal for reference, become the BUS. To achieve bi-directional communications like most protocols require, the BUS is shared between transmitting and receiving. So when one end of the BUS is transmitting it must take control, and the other end must release control and enter a listening mode. The timing of controlling the BUS is critical for a successful installation . If the transmitting side takes too long to release the BUS, the other side may start transmitting before the first has finished, causing the message to be corrupted. Many computer RS485 cards use the RTS signal in a standard PC UART to control the BUS. Unfortunately Windows then has to control this signal. Since Windows is not a Real Time Operating System (RTOS), the signal may be delayed (for a multitude of other operating system demands), resulting in garbled messages. The best way to eliminate this issue is to use an external RS485 to RS232, or RS485 to USB converter, like the  Define Multicom . Embedded devices like the Multicom take care of this issue. Misconceptions around the necessity of the ground connection A common misconception is that only the two signaling wires are required for a RS485 system and the ground connection can be omitted. This is incorrect. Even though the system may appear to work without the ground, its noise rejection and reliability is significantly degraded. When to use RS485 terminating resistors The RS485 standard is designed to work up to 10Mbits/s, while most industrial systems tend to work up to 115Kbits/s max (or a 100th of the maximum). Terminating resistors are required if using very high baud rates, as transmission line reflections from un-terminated ends can come back to be read mistakenly as a valid signals. A good rule of thumb is if the system runs up to 115K, one need not worry about terminating resistors. Labeling of the terminals The standard shows A and B. Unfortunately, early in the RS485’s history, a semiconductor maker mislabeled these pins on a RS485 driver IC datasheet. This caused mass confusion for manufacturers who referenced this datasheet and incorrectly transposed the pin labels. Some manufacturers noticed the error and amended their labeling. The consequence of this is that  there are many products which have incompatible labeling . The solution is to swap the wiring around (the same workaround as for the RS232). Define labels all its products as  D+ ,  D-  and  Sgnd . For wiring a system together, simply connect all D+ together as with D- and Sgnd. RS422: In decline The RS422 port was the predecessor to the RS485 port and is becoming less and less common today. The main difference is that the RS422 port has separate drivers for Transmit and Receive. Hence instead of 3 wires, 5 wires are required for a RS422 bus. Many of the same advantages of the RS485 BUS are retained in the RS422 BUS. Read:  How Engineers Find Information to Decide what to Specify and Buy for their Engineering Solution Conclusion This paper gives a bit of history of the three different serial interfaces commonly used today. It explains common issues found in setting up such a system and the benefits of the three different connections. Although both the RS232 and RS422 connections are in decline today, the many benefits of the RS485 connection will ensure that it will remain relevant for many years to come. The many benefits of the RS485 connection ensure that it will remain relevant for many years to come.

Public utilities are in a sorry state in many U.S. cities, no more so than in the water and wastewater sectors. Due to restricted spending and the “invisible” nature of the problems related to the water industry, investment has been deferred for years and the infrastructure has been bereft of the care and attention it so desperately needs. One recent study revealed water loss as high as 46% between the water source and its destination – an alarming figure by any measure. If towns and cities in the United States are leaking almost as much water as they are supplying, what is is to be done to secure a more sustainable future for this precious resource? The savior of the water and wastewater industries? The light at then end of the tunnel is the  real-time data and analytics  provided by the Industrial Internet of Things (the IIoT). With a straightforward installation of sensors in key locations and connection of these sensors to the Cloud, real-time data can be analyzed to identify the infrastructure’s main leak points. Once identified, the municpiality’s limited resources can be focused to address the issue: budgets can be alloted, upgrades can be scheduled and maintenance teams deployed. More than preventing leaking wastewater But introducing the  IIoT into water and wastewater infrastructure   goes far beyond this “plugging the holes” remedial work. Additionally, sensors can gather data on water quality, flow rates and equipment performance. If problems arise, the near real-time data can be acted upon more swiftly, allowing engineering teams to respond faster to remedy leakage, loss of pressure or to mitigate the risk of catastrophic failure. How IIoT deployment becomes the industry’s crystal ball As well as a faster reactive model, the IIoT offers the additional and much greater benefit of predictive insights. Component parts all have a pre-determined working life and by monitoring the data on their working hours, spares inventory procurement and part replacement work can be scheduled in a far more efficient and cost effective manner. Read:  The completely overlooked but drastic cost savings municipal water departments can achieve with this simple IIoT application Moreover, the predictive advantage of IIoT pretty much guarantees indefinite continuation of service. Additionally, over time the data can be used for longer term improvements like more accurate usage forecasting or for system expansion planning. Easy of use by monitoring using existing devices Remote monitoring of the water/wastewater system using IIoT is simple because it requires no custom hardware or dedicated devices. Public works departments can monitored their system from every day devices such as tablets and smartphones. The IIoT is also flexible enough to provide different users with different levels of access to cater for the specific and varied needs of everyone from C-level executives to maintenance teams. The IIoT road ahead for water/wastewater departments Although many public works professionals are aware of the benefits of deploying the IIoT, there is some way to go before awareness of the enormous advantage of IIoT reaches the mainstream and the ears of the voting public. Full adoption requires bold decisions from city and municipal leaders to make IIoT a priority on their planning roadmap, commit to an overhaul of current infrastructure and to make the right investments to ensure an intelligent and robust water/wastewater system is in place for the future. Taking your first steps towards IIoT deployment? Check out the  Nimbus IoT Cloud Gateway  for a simple way to begin connecting your equipment to the Cloud.

This infographic reveals the information consumption habits of engineers during a buying cycle. It shows how they consume engineering content to help them make buying decisions. Based on data from Engineering.com ’s research study “ How Engineers Find Information ” 2018 this data reveals some surprising insights.

As the Industrial Internet of Things marches forever closer, companies are looking at tangible ways to their improve their workflow, productivity and efficiency. However, unsurprisingly, businesses are not adopting radical internal re-engineering as a reaction to the IIoT – it’s simply too disruptive and expensive to throw out the old and embrace the new. Companies actively engaged in the Industry 4.0 vision are taking a far more conservative and gradual approach. While commentators evangelise the Brave New World that the IIoT will deliver, those in industry are asking “what steps can we take while we wait for this new reality to become commonplace?” The Unconnected Billions of industrial machines lay strewn all over the globe in factories and production facilities. These behemoths, never designed to “talk” to each other, have proudly stood alone for decades. But the times they are a-changing. While our domestic world becomes more and more connected, the world of industry remains for the most part, fragmented and discrete. So what is to be done? A tidal wave of IoT data threatens to swamp business operations Connection of these standalone machines and equipment to the Cloud is the first priority and also it seems, the first problem. The blanket connection of billions of industrial machines to the Cloud would generate a massive volume and variety of data. It is estimated that around 20 Billion devices will be online by 2020. These devices will generate several exabytes of data every single day. How can one business successfully manage and analyze this unprecedented amount of data with its existing resources? Read:  The completely overlooked but drastic cost savings municipal water departments can achieve with this simple IIoT application Of course, moving this data from these previous standalone machines to the Cloud will also require vast amounts of bandwidth. In this case, a way of regulating the amount of data would make this more manageable for the business in question. Additionally, evaluating which data is useful and which can be discarded would also help with operational practicalities. Survival of the fittest defined by the quickest The second problem is the agility of a business to respond this data. In any market, responsiveness is a key component to success. Faster response time can improve output, boost service levels, increase safety and reduce maintenance requirements, and urgent action can be taken for mission-critical events that need immediate attention to prevent costly downtime or catastrophic failure. The traditional Cloud model would have this data sent to the Cloud and processing would occur minutes, perhaps hours later. This is far too late. Enter a solution from the Cloud Edge. But Clouds don’t have edges Forget soft, fluffy clouds, the Industrial Internet of Things Cloud has a very definite edge and one where much activity is occurring. The term Cloud Edge merely indicates a near proximity to the Cloud rather than being within it. The IoT Cloud Edge is also referred to as “the fog” with the processing of data at the edge of the Cloud often described as  Fog Computing, Edge Computing or Edge Processing . A middle man between machine and IoT Cloud By placing an intermediary device between the industrial machine and the Cloud, one immediately solves the two problems outlined above. The device has the capability perform calculations on the data it receives, and it is this ability to “do Math” that frees a business from data avalanche. Functions can be written into the device so only vital and meaningful data is filtered to its final destination in the Cloud, thus solving our first problem. Additionally the device can be programmed to respond to results of data immediately it falls outside normal parameters. Alarms can be triggered, pumps turned off, email alerts sent to tech staff and any other corrective action required. By siting the device close to the industrial machine, all this is enacted with minimal latency. A feature vital for almost any industrial business. Read:  SCADA systems vs IIoT Solutions – a comparison of future scaling Beyond the event itself lies the ability to access and study the data in the lead up to the event, offering opportunities to fault detection, improve maintenance and service cycles, and other efficiencies of a reactive workflow. On an even longer timeline, there is also scope for identifying patterns within bigger data sets. Another important benefit of locating the device near the machine is of  security . Analyzing data close to where it is collected means sensitive data is kept inside the network. IT teams can monitor this as they would any other part of their IT environment and in line with existing company cyber-security policies. First steps to connected ecosystem inside industrial businesses All this makes Cloud Edge Processing a viable bridging step for almost all industrial companies. It is straightforward to implement, it is affordable and can be managed by an existing workforce. Additionally, it will provide good data and is scalable in the future. In Summary Processing data at the Cloud Edge (i.e. before it is transmitted) holds the most promise for industrial companies as they transition to becoming fully IIoT equipped. IoT Gateways  that support Cloud Edge Processing provide transitioning businesses with the ability to stem the flow of data to a manageable and useable amount. In turn bandwidth costs would be reduced Cloud Edge Processing has the following advantages: Allows response to data at the Cloud edge (i.e. before it is transmitted to the Cloud) Provides faster (often real time) response to this data Can move specific data to other locations or systems Sends only meaningful data to the Cloud Reduces security issues Why Cloud Edge Processing is the future of the Industrial Internet of Things (IIoT)

Aug 31, 2012 is a day that one Arizona company will never forget. Events of that day are now clear but for many weeks following the incident, staff and investigators alike drew a blank. A Friday like any other… It was the Friday before Labor Day and business as usual for the 36 workers present. The morning passed uneventfully and during lunch their thoughts naturally turned to the long weekend ahead of them. “We talked about our plans for the weekend”, remembers Amber Brennan-Eisner, office manager at the time. “The weather was great and everyone was looking forward to it.” Some were heading off to the White Mountains for camping or fishing trips, others were staying closer to home to host family picnics or barbecues. All were making the most of the last long weekend before school started. After a scorching summer (July had been the hottest month in U.S. history), the company’s air- conditioning had been worked hard. Earlier in the week the strain had caused several units to fail. That Friday, HVAC engineers were working frantically to remedy the stifling temperatures in some parts of the building. Unfortunately, due to the long weekend, the data breach wasn’t discovered until late on the following Tuesday A devastating security breach In the last hours before this business closed to enjoy all that the 3 day weekend would offer, it suffered one of the most devastating and embarrassing events in the company’s 42 year history. It fell victim to a massive breach of security: the company was hacked and the credit card details of all their recent customers were stolen. Unfortunately due to the long weekend, the data breach wasn’t discovered until late on the following Tuesday. Initial suspicions were of high tech and complex cyber attack from off-shore – perhaps China or Eastern Europe – but the reality turned out to be something far more grass roots. An overseas cyber attack? Like many similar businesses in the area, the company had a Genset (generator) in the basement of their building. To comply with regulations, the emissions from this generator had to be monitored and logged to a data logger computer a short distance away. When the Genset was installed it was just out of range of the company’s wi-fi network router, so a high gain router with a 12db aerial was used to bridge the distance. The installation engineer wired the Ethernet ports: one Modbus TCP at the Genset and the other in the control room which was connected the company network. At the time of installation the IT team ensured the solution complied with the tight security on the company’s wi-fi network, so when the breach happened many were left scratching their heads. They investigated whether network security could have breached by an individual from that basement location Investigators pored over hours of security camera footage, server logs and other technical data attempting to pinpoint the breach. A simple oversight causes havoc Eventually, CCTV footage revealed an individual dressed in a similar fashion to the HVAC engineers making a detour towards the basement. His destination could not be confirmed as unfortunately no security cameras existed in the basement. They then investigated whether network security could have breached by an individual from that basement location. IT pointed out that this made no sense as the company’s network data was encrypted and a high level of security was maintained on the network at all times. However, it turned out that down in the basement this individual had simply plugged a laptop into the extra Ethernet port on the router by the Genset. Of course, data is encrypted while traveling through the air but is decrypted in the router itself and its Ethernet ports were open and transparent. This hacker had hit the jackpot. He was straight in to the company-wide network and accessed the secure customer database. Nowadays the company is connected to the Cloud and has employed robust IoT technology to plug this vulnerability. Security and Industrial IoT Gateways They use the  Zen IoT gateway  which has its own wi-fi port and connects to the Cloud with an extra layer of security: Transport Layer Security (TLS) Additionally it has an ethernet port which uses only Modbus TCP, so the port cannot be hijacked for any other communication uses. The company chose the Zen IoT for its size and simplicity. It offers 3 options to connect their previously discrete hardware to the Cloud, only requires the skills of a local electrician for installation and measures just 4” x 1.4” x 4.7”. As a  Cloud Edge Processing device  the Zen performs calculations on the collated data prior to transmitting to the Cloud. It also features a flexible logic engine which can programmed with a powerful scripting language for custom applications. With the Zen IoT and its built-in security measures in place, if a cyber attack did occur today, the only thing it might achieve would be to corrupt the generator data to the Cloud by simulating a Genset controller. This would be unlikely (as the hacker would have nothing to gain) and the impact would be small compared to the magnitude of a credit data theft. Privacy and security surrounding the IoT is of primary concern to all planning the connection of their legacy equipment and a transition to the Cloud. The Zen IoT addresses these concerns and simplifies the connection process.

How clever implementation of  Industrial Internet of Things (IioT) devices  like the Zen IoT Gateway generated thousands of dollars and helped an industrial company to upscale. EmissionGuard Inc provides a service to companies enabling them to comply with regulatory requirements for emmissions from Genset generators. Their service comprises of: Dispatching an engineer to install monitoring and logging hardware on-site installing software on-site providing ongoing support post-installation Before the Industrial Internet of Things (IIoT) 2 years ago EmissionGuard had over 100,000 customers. This meant during their growth period to achieve this number of customers, they regularly engaged a highly skilled (high level of knowledge) network of systems integrators and partners to travel the country to install 100,000 devices that were configured with 100,000 pieces of software (on various PCs with a myriad of different operating systems). After installation the support helpline often dealt with unrelated customer issues like “I replaced my printer with a different brand and now it doesn’t work with your system” and “Windows 12 has heightened security and now won’t connect to your unit.” A significant amount of support time was eaten up on these calls. Business was going well but as EmissionGuard grew they needed more support engineers and required them to do more travelling to meet customer demand. Scalability was an issue. A significant amount of support time was eaten up on these calls. Scalability was an issue. How IIoT devices helped this business upscale This year, thanks to it’s use of IoT enabled devices, things look very different for EmissionGuard. Now when a customer places an order – no engineer is dispatched, just the product as the installation can be conducted by a regular household electrician. The product is the  IoT enabled G3 IoT Edge Controller . After installation, the customer plugs the Modbus port into the GenSet, connects the additional sensors, applies power to the unit and walks away. The unit automatically connects to the internet using a 4G modem. One which Verizon have guaranteed will work on their network for a minimum of 15 years. The unit begins dumping data to a single server, the same server that all the other units are now connected to. With this added load EmissionGuard occasionally have to update their server but this also has its benefits. In their last update they added a new feature which predicts catastrophic failure in the GenSet units. They offered this to their customers and the majority were happy to pay an additional charge for this peace of mind. Scalable numbers after IoT implementation EmissionGuard pay: $4.00 per month to Verizon $0.50 per month to Xively to run and maintain the Cloud application EmissionGuard charge their customers $11.00 per month for their standard service $15.00 per month if customers opt for the additional catastrophic failure protection How application of Industrial IoT kept profits in the business EmissionGuard now have only 3 support engineers and no longer have to rely on their network of expensive systems integrators for installations. This staffing reduction alone has dramatically reduced their operating costs which has in turn improved profits. Read:  The completely overlooked but drastic cost savings municipal water departments can achieve with this simple IIoT application EmissionGuard is looking forward to their next 100,000 installations and have found a new niche: replacing their competitors non-connected units. How does the future of business look with the IoT? By moving data to the Cloud your business can hand off the cost and responsibility of maintaining servers, security and backups to a Cloud service provider, freeing you to get on with the business of business. Such has been the reduction in cost for these Cloud services that even heavy duty datalogging applications look set to move to dedicated servers on site to the Cloud. As the IoT grows: Cloud service costs will fall further Your company’s issues associated with maintaining software and PC hardware will be greatly reduced Your company will require less time and staff resource for new installations/expansions Tech issues will be simpler to fix and less daunting

Energy costs for manufacturing facilities can be as high as 50% of OpEx (operating expenditure) so it is in the interest of all industrial companies to focus at least some of their efforts on energy management. Reducing energy consumption in your manufacturing plant has two advantages: significant savings in operating costs plus a reduced energy footprint – being more environmentally responsible is a good thing. Benchmark your current usage habits Of course, the first step in reducing energy costs is to get clear on your current energy consumption, and which areas of the business are using the most, and at what time. Unfortunately, not enough manufacturing companies are able to gain these insights because they simply aren’t monitoring their energy usage. Without real-time visibility of your varying energy needs, you cannot gain those significant insights which may translate into future operational changes for cost-saving. Installing smart meters provides the necessary real-time monitoring across different processes within manufacturing units. They measure current, voltage, units (Kwh) and power factor and this data can be collated in an  IoT Cloud Edge Gateway  and published to the Cloud. Limit the amount of data collected A Cloud Edge Gateway can “do math” to process data at the Cloud’s Edge, this has several benefits: Data can be processed in almost real-time so any action required is taken immediately rather than data making the round trip to the Cloud and back (this could be minutes or even hours) before action is taken. Sensitive data can be kept within the existing network, maintaining the integrity of your company’s security without further investment or additional hardware and avoiding issues related to VPNs, DNS or firewalls. Avoids a “data avalanche”. Stemming the flow of data and allowing only the vital and meaningful information to be carried to its final destination in the Cloud is more manageable and useful for human analysts. Filtering data at the Cloud’s Edge reduces bandwidth and therefore bandwidth costs. Not a big issue when you have 5 devices but when you have 500 or 5,000, it all adds up. The IoT platform can visualize this data into various charts and graphs to reveal peak demand, time-of-day spikes, seasonal trends, consumption patterns and other vital insights for each business unit/location. This programmatic approach means old school manual entry/pen-and-paper recording of data can be abandoned and cast aside as the inefficient, time-consuming and large-margin-of-error activity that it is. Uncovering potential savings tends to happen quite quickly after deployment as even basic information can be used to great benefit by the manufacturing company. Getting started with your IoT energy monitoring trial Begin with a pilot initiative monitoring one process or line, this way the required investment is kept low and the number of points of measurement is kept to a focused amount. This will also assist you in getting buy-in from your manager. It’s likely this will be viewed as a pet-project for your department and a sandbox to keep you engaged. For you it’s the chance to be seen as a pro-active employee interested in embracing new technologies and exploring new avenues for improvement and cost-saving in your department. Be clear on what you’re monitoring and why. What are you trying to accomplish? Be as specific as you can with this as “cost savings” is woefully vague. How much, in what ways and by when? Define your KPIs in discussions with your wider team, and remember to start simple and small –complexity and scaling can come later. How do you need to connect? Everyone’s equipment is different. Some may already have sensors, and some may need “sensoring” first. What signals do you need to collate? TC, RTD, mA, V, mV, Potentiometer, Frequency, Pulse, Counter? Get those answers then consider the physical connections you require: RS232, RS485, WiFi, Ethernet, Cellular connection, or Bluetooth. How many signals and from where? A small number of signals and signal types means your energy monitoring initiative will likely be straightforward. However, if you wish to monitor multiple signals from multiple machines you may want to consider adding a gateway device to concentrate all the signals in one place. Putting the data to use After connecting your equipment and getting the data flowing, visualizing the information and putting it into a meaningful context will reveal insights and opportunities by studying your equipment’s/line’s current “energy consumption profile”. Once enough data has been collected, you’ll get clarity on the energy usage fundamentals of your initiative and what types of changes are needed. Go for the small easy wins and perhaps one or two medium-term goals which may be more involved. Expanding your trial While conducting your energy monitoring trials it may be evident that you need to measure more than originally thought. Often these further requirements become obvious once you’re up and running rather than in the planning stage, this is new territory for everyone so don’t feel bad if something gets overlooked. Unless these additions prevent you from moving forward, save them for Phase 2 of your trial. From monitoring to managing Inevitably, successful energy monitoring trials grow and evolve into energy management policies for your business. Once trials conclude you can present the findings to your wider team and collectively draw some conclusions. Depending on the outcome this initiative may expand to further areas of the business, grow to monitor more machines or go deeper to conduct more sophisticated monitoring. It’s likely that once you understand the variables which affect your power bill they’ll be an argument for automating and controlling these to make your facility more energy efficient and to optimize the energy that is used (doing more with less). The checklist Sensors Energy meters Edge Gateway (depending on number of signals) Edge processing device (if not part of gateway features) Cloud Service Provider Data Visualization interface (dashboard) Considerations Try to keep your trial deployment as straightforward as possible and favor “Out-of-the-box” solutions  over others which may require you to become an expert on every element in the chain from sensor to Cloud to dashboard. Turnkey solutions are easier to pitch to management as they are provided by a singular vendor making procurement, deployment, troubleshooting and ongoing support far easier than dealing with multiple vendors. Aim for simple installations with good connectivity and potential for scaling/expansion. Also pay attention to the ease-of-use of the software/dashboard, there are many that are powerful but fewer that are intuitive, graphically pleasing and user-centric. Your choice of software is dependent on your choice of hardware so ensure they are compatible with each other. An all-in-one vertically integrated solution If you are attracted to a single solution which includes Edge Gateway, Cloud Service and web-based dashboard then  Define’s Energy Monitoring solution  should be on your list of possible options. Straight forward set-up of the IoT gateway device, Define Cloud Services and data visualization dashboard means you can be up and running within minutes rather than months. The availability of APIs within the solution enables connection to internal business systems such as your ERP or CRM and external data sources such as Google maps, weather data or market spot pricing, making it even easier to take your first steps towards energy monitoring and management within your facility.

The RTD (more commonly known as PT100) is one of the most used temperature sensors in industry. It is known to be the most accurate and repeatable sensor for low to medium temperatures (-300 to + 600 ° F.) RTD stands for Resistance Temperature Device. Quite simply, the sensor comprises of a resistor that changes value with temperature. The most common RTD by far is the PT100 385. This element measures 100 Ohms @ 0 degrees C (32 °F) and 138.5 Ohms @ 100 °C (212.0 °F). One of the greatest challenges for instrument engineers is dealing with the relatively low resistance of the device. This is because any stray resistance (in particular lead resistance) of RTD assembly can add a significant error to the measured resistance. To combat this, different lead compensation schemes were invented and have come to be known as 2 wire, 3 wire and 4 wire. The 2 wire technique The two wire RTD is the simplest form. The Lead R is the lead resistance of the wire connecting the RTD to the instrument. In this scenario the instrument is going to read a higher temperature than the true RTD temperature because the instrument measures: RTD + 2x Lead R For example if the lead resistance was 0.5 Ohms then the instrument would read 2.6˚C (4.7F) higher than it should. The only way to compensate this error is to manually adjust the offset of the instrument. This of course becomes tedious and prone to human error. Automatic lead compensation instruments were invented to address this problem. The compensation techniques use additional wires connected to the sensor to measure the lead resistance and negate its effects. The 3 wire technique The three wire lead scheme requires two measurements, the first measurement is V1 which gives a result for RTD + Lead R. The second measurement gives a result V2 for R Lead. Hence to get the true RTD measurement we simply subtract V lead from V lead + RTD leaving RTD. Hence for any Lead R value this scheme will automatically compensate out the lead resistance and give you the correct temperature. The assumption this technique makes is that the lead resistance is the same in each of the three wires. This is a very safe assumption to make in particular with modern manufacturing techniques used in wire production. In the practical examples section you will get more of a feeling how these errors stack up. The 4 wire technique This technique relies on a very high input impedance of the modern instrument so that in the sensor wire there is practically no current flow: this is a very valid assumption today. The RTD is sensed in the scheme with no error by measuring VRTD in one measurement. The advantage of this scheme is that it also compensates out any lead wire imbalances. Historically the 4 wire technique has been popular in Europe led by the German influence for absolute precision. In the North American market the 3 wire technique has been much more widely deployed in the past and even today outsell the 4 wire sensors by 3 to 1. This has been led by cost and practicality. Practical examples Headmount transmitter using 24 AWG wire to connect the RTD sensor to the transmitter with a probe length of 12” Headmount transmitter using 24 AWG wire to connect the RTD sensor to the transmitter with a probe length of 12” From the results above for headmount applications both 3 and 4 wire are excellent techniques for eliminating lead resistance effects. Furthermore, the long cable test also shows 3 to 4 wires to be perfectly adequate. Even if there is some wire imbalance, the calculated error puts it firmly in the uncertainty band of almost all industrial applications. Another question that is sometimes asked is: “ If I have a 4 wire RTD can it be used as a 3 wire RTD?” The answer is yes, leaving one wire disconnected from the 4 wire sensor will not add any error to the 3 wire system of lead compensation. However the opposite is not true. You cannot use a 3 wire RTD with a 4 wire instrument by simply shorting the 3rd and 4th wire together at the instrument. This will result in substantial lead wire resistance error. In conclusion 2 wire RTD inputs should be avoided altogether unless the wire lengths are short and you are using a low gauge wire to reduce the lead resistance. 3 and 4 wire compensation techniques have been proven over many years to provide an excellent means to automatically compensate lead wire resistance in RTDs. You would choose 4 wire if you are concerned with absolute precision over long lead lengths. Whereas it has been shown that the 3 wire technique is accurate for all practical industrial purposes and that it saves around 20% in wire cost over the 4 wire technique.

Clearing the fog surrounding fog computing Cloud Edge Computing or Fog Computing  is a concept related to the IoT (Internet of Things) and the sending of data to the Cloud. It’s best if we examine this concept alongside the other main cloud computing concept. For clarity we’ll name each after the 2 companies who are driving product development and innovation in each of the respective ways of thinking. The Amazon IoT approach Amazon advocate sending all data to the Cloud  for processing. This approach is very much a “capture everything and deal with it later” way of thinking. Of course, Amazon have the infrastructure to deal with the massive amounts of data that will issue forth and many believe that collecting as much data as possible is the most robust method for future-proofing whether this data is useful now or not. This “catch all” approach provides a safety net if in the future historical data is required. Nobody can predict the future but yesterday’s data may become a tool of competitive advantage in tomorrow’s world. Advantages of Send-All-to-Cloud: No data left behind (could be useful later) Big Data tools for centralized analysis The Dell IoT Cloud Edge Approach Dell believes that the future of IoT lies at the Cloud Edge . Unlike Amazon’s “grab it all” approach to data, Dell take a more pragmatic “take only what is useful and meaningful, then send it to the Cloud” perspective. This is the essence of Edge Computing. To conduct this cloud-edge processing of data, something has to be placed between The Cloud and the item collecting the data (placed at the Cloud’s edge as it were). This “in-between” item is known as an  IoT Cloud Edge Processing device  or a  Cloud Edge Gateway . It can also be termed a  Fog Computing Device  (the fog at the edge of the Cloud) Analyzing IoT data near to where it is collected cuts gigabytes from network traffic and keeps sensitive data inside the network. Advantages of Cloud Edge computing: Only the meaningful data is taken – lower data volume Calculations can be performed on the data before it is sent Lower bandwidth costs Realtime processing All this data, now what? In both of these cases the overriding thing to keep in mind is that it is not the amount of data collected that is valuable. The value of data is in how it is interpreted and how it is used. Cloud Edge Computing products View Define Instruments Edge Computing Gateways Cloud Edge Computing video

The Zen series was designed as a data acquisition system for SCADA systems and PLC’s in the industrial arena. However it is quite different to the plethora of standard data acquisition products on the market. Much of the market is dominated by low cost, high sampling speed, multiplexed units. These were originally developed for controlled lab conditions and scientific use, and were typically connected to scientific packages like LabWindows™ and MATLAB. The Zen series architecture is built on industrial grade technology proven in the field for many years. So what’s the difference? First of all, the A/D type and sampling speeds are quite different. A PC card typically uses high speed SAR converters which have multiplexers on the front to increase channel count. Although you can get samples quicker, you may have to do a lot of post processing to get a usable reading. The multiplexer itself is not an ideal signal processing device and poses some challenges for the novice and expert alike. The issues relate to the time required for the inputs to settle on each multiplexer change, and how the input impedance of the signal can degrade performance. (Much has been written about this and is generally available, however it is beyond the scope of this paper to go into any further detail on this.) The analog industrial design engineer has known for many years that to get reliable results from signals that might travel ½ a mile through a plant normally requires a system that can distinguish low level signals from noise, which is sometimes an order or two larger than the signal itself. To combat this the integrating type of converters were invented. These include dual slope, voltage to frequency, and later the Sigma-delta converter. These A/D’s sacrifice signal bandwidth for noise rejection and rugged reliability. The Zen series has made use of the modern sigma delta A/D to become the workhorse of this new genre of SCADA accessories. However this is only the beginning of the story. Although the A/D is responsible for rejecting noisy signals like 50/60Hz hum, simply replacing the SAR converter with a sigma-delta converter in a multi-channel application would have little benefit. To really make a rugged industrial system requires every channel to be galvanically isolated from each other. This is exactly how the Zen series is designed. Every input channel is isolated magnetically and optically from all others. Each channel has its own A/D transformer and optocouplers, as well as important EMI filters. To really make a rugged industrial system requires every channel to be galvanically isolated from each other. Why use Isolation? Isolation solves many problems associated with industrial processes. Isolating power sources and sensor signals is the most effective method for eliminating undesirable ground loop currents and induced electrical noise. Some of the more common problems which isolation solves are: Cross Talk Cross talk is when the contents of one data acquisition channel appear on another. This can cause subtle to large measurement errors that can go undetected. The cause of this can be simply sharing a ground in where ground loop currents can flow depending on the size of the signal. This is converted to an unwanted voltage component by the impedance of the earth track. More subtly this can be due to a fast sampling multiplexer input capacitance and a “high” source impedance. Even a “high” impedance of only 100 ohms could be responsible for significant cross talk. Having an isolated channel with its own A/D stops these problems dead in their tracks. Cross talk is virtually unmeasurable between channels for isolated products in the Zen series. Read:  The drastic limitations of Sigfox and LoRa that nobody is talking about Common-Mode Voltage Each instrument will have a CMV specification relating the maximum voltage which can be tolerated on the inputs of channels relative to ground. A good way to visualize this is measuring a stack of 12V batteries typical in a telecom application. If you want to measure the cell voltage on top of the stack the negative of the A/D input will be 36V relative to the ground of the A/D. This is the common mode voltage. Now if, for example, the common mode voltage was rated at 50V, the system would be fine. However the + of the A/D in this case will be 48V – close to the 50V limit. If the voltage strays higher than the 50V limit due to noise or battery charging equipment, the CMV rating will be exceeded, which could distort and degrade the signal leading to an inaccurate reading or damage to the A/D. Having an isolated input practically eliminates this issue as the A/D ground will float up to the CMV. In this case the CMV limit will be the isolation break down voltage of the transformer and/or optocoupler. For example, the Zen series isolation breakdown barrier is above 3,000V AC, which is much higher than the expected CMV of most production applications. “The Zen series has broken the isolated price point to around $50 per channel – now there is no excuse not to isolate.” Common Mode Rejection Every time a measurement is made in the presence of a CMV a loss of accuracy will be encountered. The question is not if, it is how much. Going back to the stacked battery system we are trying to measure a 12V signal on top of a 36V common mode voltage. If you read the spec of your instrument you should find a DC CMR ratio. For a typical PC card A/D this could be 80dB. Now: 80dB = 20 log (VCMV in/ CCMV out) 80dB = 20 log (12V DC/ CCMV out) 10,000 = 12V DC/VCMV out VCMV out = 1.2mV error All in all, not too much of an error. However, if we now change the measurement by measuring the current drawn in the 48V system by using a 20mV shunt, the results now look like this: 80dB = 10,000 = 48V / VCMV out Error = 4.8mV (or 24%!) For a typical isolated system the DC CMR would be in the vicinity of 160dB or 100,000,000. Or in this case, 480nV – practically nothing. To add to this, AC common mode voltages are even more prevalent than DC CMV’s when you take into account noise sources such as unsnubbered contactors, motor brushes, inductive conducted and radiated electromagnetic fields (EMFs). Again, an isolated system has many advantages over a non-isolated system, as the isolated system will float to the common mode voltage. It’s not uncommon for an isolated conditioner to be able to measure the temperature with a thermocouple which is directly connected to a live mains feed. That is, the T.C. will be floating at 230V AC and still give a measurement accurate to 0.1°C! Furthermore, because high speed multiplexers are not used in the Zen series input modules, that the designer has the freedom of not having to worry about increasing the capacitance of the input. This opens the way for using modern feed through capacitors in common and differential mode EMI filters. These are designed to reject wideband noise and improve the CMRR. Not only that, but an inherent virtue of the isolated input is that the loop areas of any sensor wiring are kept to a minimum, reducing pickup. Conclusions The isolation of industrial signals preserves and protects valuable measurements, as well as expensive equipment, from the effects of ground loops, transient power surges, noise and other hazards present in industrial environments. In the past the only reason to purchase a non-isolating system was cost. Of course it is less expensive to have only a single A/D than 16 A/D’s, as in our 16 channel Zen units. However the cost of commissioning a system, and trying to work out cross talk issues and potential ground loop problems, will soon dissolve any savings made. That, combined with the added multitude of other protection benefits of an isolated system, really points to only one solution for the wise system integrator:  Isolate, Isolate, and if in doubt – Isolate again .

If you need to get multiple signals from various types of sensors into a PLC or SCADA system  and you’re pushed for space , specify the new Zen RTU Mini from Define Instruments. The Zen RTU Mini goes where others cannot The  Zen RTU Mini  measures just 3.98 x 1.38 x 4.42″ fitting into tighter spaces, smaller enclosures and saving you DIN rail space! No need to run cables The Zen RTU Mini has a wireless option so you retain portability, and don’t need to spring for the cost of cabling. Universal input for maximum flexibility The Zen RTU Mini accepts TC, RTD, mA, mV, V, Frequency and Pulse. This reduces the number of separate instruments required for your application, further reducing costs and keeping things simple for troubleshooting and maintenance. Per-channel isolation for high reliability Each channel of the Zen RTU Mini is galvanically isolated ensuring a clean and steady signal in even the harshest of industrial environments. Don’t pay for channels you don’t need The Zen RTU Mini comes in 4, 12 and 16 channel options, so you only pay for what your application requires. Get the  full specs  »

Over the last 12 months I have consulted on many IIoT projects for industrial companies across the U.S. These companies have varied from value-added distributors to systems integrators to end users. During discussions I have found it interesting to note reactions to the inclusion of IIoT in the application. One of the most common reactions forms the basis of this article. Typically it goes something like this… After discussing specific needs there would come a point in the conversation where I would mention Remote Monitoring and Control of Assets, to which the typical response was: “But we’re already doing this with our SCADA systems, what’s the difference?” This is an excellent question and the best way to answer is by comparing the two approaches.* For our comparison I have selected a recent  application in the Water/Wastewater industry . This system includes the Remote Monitoring and Control of a large water filtering station for irrigation in the Florida region. Remote Monitoring & Control in Water Filtering Station An RTU has been programmed to monitor and control the filtration system and by measuring the differential pressure across the filters, the RTU automatically performs a backflush of the filters when required. The RTU also monitors the flow rate and total flow of water and wastewater. From this information one can determine the general health of the system. Investigating the reasons for faults currently involves humans Occasionally, the unit in the field will trip out and stop working. The customer then has to send a technician to the site – a drive of around 3 hours. When the technician arrives, quite often the only action required is to reset the system, as most of the time this clears the fault. But what the customer really wants to knowis why the system tripped in the first place. And how necessary was it to dispatch a technician to the site? If a technician was not required, could the system be reset remotely? These questions can be only answered by looking at the data from the sensors before and after the trip event. And so using the traditional approach, a SCADA system must be installed to receive this data. As the system is usually deployed on hardware at the customer’s premises, the following must be considered: What level of reliability is required? Should it be running on Server Grade Quality devices? Should a backup power system also be installed? How much will this cost in capital and maintenance? Who will manage this system? Once these questions have been answered, the SCADA application can be built. It will of course require a data historian, the setting up of a mimic and possibly an add-on package to deal with the telemetry aspect of the modem etc. Addressing security within the SCADA system During the building of the system, security must also be addressed. The industry standard approach to this is to add a VPN connection between the SCADA PC and the RTU in the field. This requires using a powerful cellular router that has the capability to both perform the VPN function and to open a port in firewalls and connect to a DNS. Once the VPN is set up, the SCADA can be set to run mode and will begin polling the RTU in the field. As is clear, deploying this system is not for the faint-hearted It requires expert help from engineering or IT professionals and could take some time to set up and test. The IIoT approach In the IIoT approach, the first consideration is the choice of Cloud Platform Provider. This is an important first step as not all Cloud providers are created equal – I would consider this as important as selecting the correct hardware. In this example I have chosen the Xively platform as it has a powerful Connected Product Management feature (CPM) which allows organization of products in domains and sub domains, the importance of which will become clear later. A typical IIoT system uses a broker in the Cloud. I have chosen to use an MQTT broker as it is available in most Cloud systems. Coupled with this is the  Define Instruments Zen IoT RTU . The difference between this and the traditional RTU is that it is setup to deliver messages to the Cloud broker using MQTT. It uses a publish and subscribe model: the Zen IoT RTU will publish information like pressure and flow rate to the broker and subscribe to a control topic. Read:   The completely overlooked but drastic cost savings municipal water departments can achieve with this simple IIoT application Control topics are used to perform tasks such as turning on a relay in the RTU. The other major difference is that the Zen IoT RTU itself makes the connection to the broker and it does so in a secure mode using TLS and certificates. This eliminates all the issues related to setting up VPNs, DNS and firewalls. The only information that has to be provisioned in the IIoT RTU is the username and password associated with the Cloud account. The information is now sitting in the Cloud and in this location it is available to the humans and devices who have permissions to access it. The Cloud platform enables this by providing a rich set of APIs, rules-based engines and standard interfaces to CRMs and ERPs. For this application a dashboard is required to visualize the data. There are 3rd party dashboards available but in this instance a webpage was created to visualize the data using the REST API. This is akin to setting up the mimic in the traditional SCADA system. So at this stage in our comparison, the IIoT approach is obviously the simpler of the two to setup for a secure application. And one that avoids the headaches of server-side hardware. You do however have to pay a monthly subscription to the Cloud provider (around $1 per month for this application). Thinking into the future Let’s now examine a post-installation scenario. After a few months of using the system the customer comes back and says:  “The system is great! So great in fact that I want to roll it out to monitor the 400+ filtration systems I have throughout the country. And I have some changes…” The customer explains his clients would like to: See how much water they have been using See how much wastewater was lost Manually turn the system on and off by logging in to a website He further explains how he personally would like to: Know when the pump has completed 1000 working hours (to schedule maintenance) Be alerted via his CRM at the 800 working hours mark Lastly, he leaves this juicy tidbit: “I was recently speaking to a pump manufacturer and he asked if we could share with him some of the pump data so he could use it to improve his product. I don’t see any reason why not…” The IIoT solution provider can confidently accommodate these requests. He knows that his Cloud partner already provides CRM alerts as a feature, he also knows the Connected Product Management system is another feature already in place to provide different permissions to different users. All the IIoT solution provider has to do is: Make 2 new dashboards Create accounts for the new users Provision these credentials into the Zen IoT RTUs But where does the engineer come in? In actuality an engineer isn’t required at all An engineer isn’t required at all in the commissioning of the sites as an electrician can wire up the units in the field. After wiring, the electrician isn’t required to do much more, just turn them on, run through an automated test setup and ensure any issues are sent as alerts directly to their cellphone (the last part requires a little more work – but just a little). Employing the IIoT approach, the customer’s requests are a cinch to implement and it’s smiles all round. Not so for the SCADA provider. The SCADA headache Unfortunately, faced with these requests from the customer, they are plagued by a sense of panic and overwhelm. So many questions, ones like: Will the server be up to the job? Will it require an upgrade? If so, how much will that cost? With 400+ VPNs concurrently talking to the field devices, can the SCADA system handle it? How will all the permissions be managed to allow 400+ users to get information on the site Suffice to say that the IIoT system wins hands down when faced with a scaling issue like this. Not only that, the capital and development costs for IIoT are far smaller. As are the costs of expert professional help from engineers and IT specialists. Only the beginning But this application could just be the start of this customer’s IIoT journey. For example, the information obtained from the systems over time could be useful for improving the design as well as determining the real maintenance and running costs associated with such a system. Armed with this knowledge, a new business model could be evolved. Offering a maintenance agreement based on the water pumped, for example. Or partnering with a finance company to offer a pay-as-you-go service so clients are only billed for the actual water pumped. Read: The drastic limitations of Sigfox and LoRa that nobody is talking about In conclusion, the benefits of implementing an IIoT solution over a traditional SCADA system go beyond the immediate wins of cost, timeline and required expertise. It is also highly scalable and adaptable to customer needs in the future. Anything that gives such a level of security, peace of mind and readiness for what might be over the horizon is an undeniable asset to your business and to everyone else’s. * I have assumed that both approaches require a highly secure solution.