Actions
Engagement
  • Author Author: rscasny
  • Date Created: Date Created
  • Last Updated Last Updated:
  • Views 1301 views
  • Likes 7 likes
  • Comments 14 comments
Related
Recommended

What Are Your Thoughts about RoadTesting a Node-Red IoT Appliance

I've wanted to broaden the selection of products (hardware, software or both) that I offer for RoadTests. We've done a lot of great test equipment lately. And I've tried to expand our dev board offerings with FPGA-SoCs. But this one is a little different. It's from Opto 22 and it's called the groov Box.

 

groov is a a way to build operator interfaces to monitor and control systems and equipment using mobile devices and other computer-based systems. These operator interfaces can be viewed on almost any mobile device or computer. From the looks of it, you may think it's some kind of automation controller. Hmm... not quite. It is used in automation systems. I am told the company has used their products in test automation. But the product itself is an operator interface appliance on the network's edge to provide visualization, data handling, and connectivity to automation systems, software, databases, and devices.image

 

The groov Box includes two independent 1-GB Ethernet interfaces and USB expansion for wireless LAN interfaces. It brings data from process control, OEM machines, manufacturing and building systems, and IoT systems to the Cloud so others can use it if they have a need to.

 

What can it do?

  • Visualization: With browser-based groov View, you can build an operator interface to see and interact with data from sensors and automation systems, cloud applications, databases, web services, and more. You can view the interface on any brand device, from a smartphone to a computer to a web-enabled big-screen TV.
  • Data Handling: The key to IoT usefulness is getting the right systems and people access to the data so they can benefit from it. Built into the groov Box are Node-RED, an IoT rapid application development environment, and RESTful APIs to groov Data Stores. When a Enterprise license is added, you will have available Ignition EdgeRegistered with OPC UA and MQTT/Sparkplug.
  • Connectivity: You can connect to all kinds of devices and systems to monitor and control them and move data between them. Devices typically include:ModbusRegistered/TCP devices, Opto 22 SNAP PAC controllers, Cloud applications, IoT platforms, on-premises databases, and external web services, Allen-BradleyRegistered and SiemensRegistered PLCs using OPC UA (Requires a groov Enterprise license).

 

What does it include?

  • - groov View for building and using your own custom operator interface to the sensors, data, devices, and systems you need to see, monitor, and control.
  • - Node-RED, an open-source, multi-platform software tool for wiring together databases, cloud applications, and APIs to produce IoT applications quickly and inexpensively. Learn more about Node-RED.
  • - Ignition Edge (requires a groov Enterprise license), a product of Inductive AutomationRegistered, providing an internal OPC-UA server and drivers plus an MQTT Transmission module with Sparkplug payload. More about OPC and MQTT in IoT applications.
  • - groov Admin for configuring networks and security, backing up and restoring projects, using Node-RED, configuring Ignition Edge, updating groov software, and viewing system status.
  • groov is available as either the standalone groov Box hardware appliance or the PC-based groov Server for Windows software.

 

image

 

I'm adding a bunch of documentation for those of you who want more information.

User Manual

Quick Start Guide

Node-Red for groov

Tutorial

 

What do you think about roadtesting this product?

  • Would live to test this out. Currently working to get all the environmental sensors I have (from roadtests and other places connected to node-red to easliy display and compare the various sensor readings.

     

    Kas

  • I would also be very interested in the device.

     

    It has Flow-based programming for the Internet of Things which looks like in the lines of Labview I would say

     

    image

  • I've been involved in Monitoring systems from way back.

    Our latest iteration, uses a Remote Terminal Unit to collect the physical states at sites, and respond according to some preset criteria and communication method.

    The server side does SNMP polling of remote devices, and can react based on the response we've programmed for that MIB..

     

    We haven't expanded into Modbus or the other PLC communications with our devices, mainly because the equipment they interface to is legacy equipment and we only expanded the server side of the capability in early 2016.

     

     

    One issue I find is that people believe SNMP is a valid system for monitoring critical equipment, despite the protocol being the first that gets bumped off when there is network congestion. IMO it introduces large overheads, for little benefit.

    As I understand SNMP ver3 is designed to overcome some of the shortcomings.

     

    Minimising data transfer should be an important consideration for all industrial applications ... rather than the "are we there yet", "are we there yet". Our scada system does this, and the polling rate had to be dropped to prevent network congestion as the monitoring is here in Chch.

     

    The other problem is who is actually doing the monitoring and responding to the alerts.

    While it might seem a great idea to 'splatter' the information to everyone, someone somewhere needs to be responsible for the activities that may have caused the device to provide these alerts.

    It's a struggle we have with some managers who seem to think it should go everywhere, but in reality only needs to arrive at the dedicated mornitoring position, with others acessing a read only version.

     

    I'll have a read of the manual.

    I'll be interested to see what they are doing for logging. It's al very well having the data but unless you can go back to investigate what happened, the information is useless.

     

     

    You definately have a limited range of testers for this type of device, and while I'm sure it could provide a solution, the price might be a key factor.

     

    Mark

  • Node Red is very topical - very useful and very powerful for IoT - an excellent road test topic. I think  seeing this particular appliance being used in a real application would be the most interesting scenario for me. I have not tried Node Red yet but it is on my to-do agenda and the priority is increasing. Mainly looking for an excuse to dive in (I mean still trying to formulate a compelling application image)

  • in reply to luislabmo

    Indeed, the edge-to-cloud interface could be easily tested without adding any hardware, making it suitable for a regular RoadTest, but I'm not sure how much value would add such test, as it would be like testing just another edge device. I believe the real value of the test would be in testing the device-edge-cloud capability of the box, which would require a RoadTestPlus (unless also some field devices are made available together with the box).

  • in reply to gecoz

    I was thinking the same!. I think some of the features like the Node-Red/Cloud applications can be tested in a simple RoadTest setup but, to test the hardware supported maybe this will need a Industrial/RoadTestPlus kind of setup.

     

    Luis

  • This is a very interesting box, and would be a great addition to the RoadTest program. It is a very specific device, used in industrial settings, so I was wondering, if the device is made available for testing, would it be tested as normal RoadTest or as the newly introduced RoadTestPlus ?

  • in reply to Jan Cumps

      wrote:

     

    Ow Jon, it would be great if you could dedicate some blogs about the subject. Industrial topic !!

    Did I hit a sensitive spot?