The Six Rules of Networked Robotics' Simplified Network Data Collection

Introduction

This document describes Networked Robotics' architecture for network data collection. The Networked Robotics approach relies on mutable hardware to accomplish integration. Mutable hardware allows for the reduced complexity in message-passing needed to collect data in a simplified way. In this architecture there are 3 levels of message-passing, 1) from a network data collection server (a Tempurity Server) to the Networked Robotics NTMS network hardware 2) from NTMS network hardware to a Networked Robotics interface, and 3) from the interface to the "monitored device", or the sensor or instrument that produces data.

Thus the hardware elements of the system are 1) the network data collection server 2) Networked Robotics hardware 3) An interface and 4) the monitored device itself. The most important element in the process is the Networked Robotics NTMS (Network Telemetry Monitoring System) hardware.

The act of data collection is primarily an act of complexity reduction. The complexity-reduction in the process is handled by Networked Robotics' NTMS network hardware's capability to accept network downloadable firmware (.NRF or Networked Robotics Firmware files) which handle "logical" complexity, and specific hardware modules for classes of interfaces that reduce "physical" complexity.

Networked Robotics' Data Collection Servers (Tempurity Servers) are not complexity-reducing. Complexity reduction has been accomplished by the time the data packet has hit the network. However Tempurity Servers utilize the de-complexified functionality to accomplish global data acquisition.

The following describes the architecture by which data collection is accomplished. In the interest of simplification, the following rules are enacted by Networked Robotics processes:

The 6 Rules of Networked Robotics Simplified Real-time Network Data Collection:

1) Network Master:

The network controls data collection timing not the monitored device. Monitored devices are queried through the network via the NTMS network hardware, and must be able to respond to a request for data. The complexity in acquiring data from diverse instruments (both logical and physical) is handled by the Networked Robotics NTMS network hardware, its current, but mutable firmware, and associated "interfaces" (an interface can be a probe or can simply be a cable). The monitored device may not initiate data collection to the network data collection server. Data is always requested. The monitored device is always a service to the NTMS and thus to the data collection server.

2) Network Immutability:

Stored data values at the data collection server are the same as the values that are sent by the NTMS network hardware. Another way to say this is that, for non-network monitored devices, the value on the network is the value stored.

The datum is stored in the same form that it is when it leaves the NTMS, but is probably not in the same form that it was in when it leaves the instrument or other monitored device because the NTMS may convert the data format. In most cases the NTMS drops all irrelevant data, taking only the requested information of interest to the data collection server.

3) Network Metadata Assignment:

Monitored device type (e.g. humidity, co2 concentration, temperature) is determined by the network command/response sent to the NTMS by the data collection service, and the NTMS port configuration and firmware, rather than by the monitored device or instrument. A Voltage request by the data collection server always returns a voltage or an error. The network data collection service thus relies on accurate, malleable NTMS firmware for accurate metadata assignment.

4) Network Command Single Response:

Only one monitored device type( e.g. humidity, co2, temperature) response value is returned for each query by the network data collection server. Network requests for data can not return metadata of mixed type - a Voltage data request always returns a value that is in effect labeled as a voltage. If mixed data temperature/humidity are required - they are obtained in two separate network queries to the NTMS issued by the data collection server, even to the same network address. The NTMS responds with the last-acquired values from the monitored device.

5) Network Data Collection Latency:

There are 4 relevant time delays in this method of network data acquisition. Data collection server to NTMS, NTMS to interface, interface to monitored device, and the monitored device's internal data collection period. But Networked Robotics' NTMS hardware units poll monitored devices even in the absence of network commands. Network-side commands return the last-read value of the monitored device stored in the NTMS.

When the interface is passive (a cable for example) the optimum network data collection period is the worst-case time latency of (NTMS to monitored device polling frequency + monitored device data acquisition period). .

6) Network Command Equivalence:

The network commands issued to read data from a single monitored device type (temperature, humidity, carbon dioxide concentration) from any of very many diverse monitored devices is always equivalent on the network side regardless of the monitored device (instrument, brand, or model) from which data is to be collected. Although "local" commands (the monitored device's logical protocol) are diverse and specific to the monitored device, the network commands for acquiring these same parameters from any monitored device are standard.

back to Support / Tutorials