PnP Sensor+Actor System (PnPSA)

State of the art⚓

While working and measuring with sensors in university's tool machine area, I miss development towards digital measurement and handy, interchangeable and easy-to-use devices. Even in 2012, the measurement technician has to deal with analog multi-channel data acquisition systems. Frequently, analog voltage (± 10 V) is used for representation of the measured value, besides those listed in this document.

Here is a summary:

Why it's so hard to move toward complete digitalization:⚓

Extremely different speed requirements (eg, accelerometer vs. thermosensor)
Very different accuracy requirements (often inversely proportional to speed)
Problems with correlated time line
- Slow sensors with client-side clocked A/D conversion: latency
- Fast sensors with sensor-sode clocked (blockwise) A/D conversion and data loggers: latency and synchronity of sampling times
Wiring and cabling Standard
Cost (for the multiple A/D converters)

Today's scenario⚓

Measurement is performed with a confusing amount of cables, connectors, adapters, tools and equipment, not to mention the weird software.

Suppose you want to measure a mechanical force with a strain-gauge load cell, you need a couple of devices as shown in the picture. For simplicity and cost-efficiency, I would use a NI USB DAQ device „NI USB-6008“ containing the ADS7870 chip. Despite the low performance of 12 bit accuracy and 10 kSa/s overall sample rate, this device is USB bus powered and therefore easy to use. With a self-made signal conditioner containing a DC/DC converter to get power from „NI USB-6008“ device, no extra power supply is needed, and the overall design is capable for in-field measurements. However, some efford is needed to get this, and you have to calibrate all! Too much to do for a routine job.

Moreover, a software must be built using LabVIEW (that's easy) and calibrated (that's a bit more complicated).

Tools

Screwdriver to connect wires
Multimeter to check voltages and connections, for troubleshooting
A mass unit to check whether the force sensor works properly

Every modern human outside who wants to measure a mechanical force thinks that such constellation is easily available and ready to use. Power is sorced from the (even more lightweight) netbook.

This is not available nowadays! But it should be. And is expected by non-professionals.

Suppose you want to measure mechanical force (strain-gauge load cell) and temperature (Pt100). For a cartoon picture too confusing, I decided to draw a block diagram for the devices needed. So suppose you have a „NI USB-6008“ for analog-digital conversion. You need two different signal conditioners, for industrial application always with its own power supply and calibration issues.

Probably a better, faster A/D converter is necessary; at least all the National Instruments devices need extra power too.

With a suitable and modular system like HBM Spider8, MGCplus, Quantum^X or NI cDAQ-9172, it's easier to handle, but still you have to solder some wires and plugs, and the overall cost is overwhelming. Extra Power is also needed, and as all devices are made for mains supply, the power consumption is not suited for in-field battery powering. No one of those systems are powerable by a notebook.

Things get worse when you already have a “smart” sensor with digital output, like Micro-Epsilon µε optoNCDT2200. This Laser Triangulation Sensor outputs distances (± 10 mm) with 15 bit resolution (< 1 µm) at pretty fast 10 kSa/s. A PC built-in serial interface with its maximum 115.2 kBaud is too slow. So you need a special adapter for connecting. For USB as Do-It-Yourself device to keep costs in bounds.

The next problem is to prevent drifting of another A/D converter, i.e. synchronization. You need an extra Sync Wire. Really! But this imposes three assumptions:

A sync output
A piece of cable (you have to solder plugs yourself, there is no standard!)
A sync input for the next A/D converter
Good luck that voltages etc. are the same, e.g. TTL level, otherwise, you have to create some convertion circuitry and its power supply

The second sensor (here a strain-gauge load cell) works as before, with signal conditioner. Moreover, some sort of a start trigger is needed (depending on latency and demands), so you may need another sync cable, not shown in the picture.

If you have two “smart” sensors with no synchronization between, you must do it later by resampling in software if necessary. Note that resampling is not measuring but interpolating values where no values were. Same applies for AC measurements (e.g. sound pressure, modal analysis) per sound card.

A digital solution is needed!⚓

Thow away analog interfacing! Take advantages of a fully digitized solution!

I would prefer using USB. Advantages:⚓

Good awareness, cables and hubs available at low cost
no extra amplifier needed (every computer has USB, but not CAN)
Integrated, well-defined and simple power supply concept, no need for large-range-voltage-input DC/DC converters on sensor side (contrary to FireWire, PoE)
Availability of power supply even on notebooks, netbooks, etc. (in opposite to FireWire, Ethernet)
Relatively low power output of the PC / hub (max. 2.5 W, 3.0-super speed: 4.5 W) enforces energy-efficient sensors
Large range of available transmission rates for expensive (fast) and cheap (slow) sensors (compared to Ethernet and FireWire)
No batteries (as in wireless solutions) for long-life sensors without constant care expenses (such as the regular battery replacement or charging of too-short-living rechargeable batteries)
Very flexible cable (especially at low speed, no shielding required)
Solving problem of mutual synchronization provided in USB standard by SOF (start-of-frame, 1 kHz and 8 kHz)
Decimal-based operating frequencies (12 MHz based) and sampling frequencies (contrary to uneven FireWire clock of 24.576 MHz)
Large range of inexpensive microcontroller makes total sensor increasingly cost-attractive
High-quality A/D converters are becoming cheaper, smaller and more energy-efficient
Practice has shown that rather well-known consumer solutions go to industry than vice versa (eg, Ethernet, RS232)
Host-centric USB system is easier to manage and understand (compared to FireWire, Ethernet)
PnP and isochronous data transfer is already built-in (as opposed to Ethernet)
Wireless option available with WUSB

Why USB and not FireWire, Ethernet/EtherCat, Fieldbus or CAN should be now clear.

Disadvantages and their workarounds⚓

Missing standard for sensors and actors (more than built-in TEDS is needed)
- This is the objective of this reseach project!
No software available for measuring on multiple USB devices with full synchronization
- The evaluation software is to be written to show how it works.
No lockable USB connectors
- There are manufacturers of lockable USB connectors.
127 (devices + HUBs) maximum, 5 m per Segment maximum
- So-called “Concentrators” work like hubs but in a higher OSI layer. These fully real-time devices make the downstream sensors to appear as one multi-channel sensor to the upstream port. For high-reliable measurement, such a device should be always used to prevent bad effects of current operating systems to USB performance.
Missing electrical isulation (potential separation)
- The sensors should be potential-free (i.e. non-metallic or insulated). However, ground loops, dreaded in analog cabling, are not so problematic with USB.
Latency (mostly when using Windows)
- Using a concentrator eliminates the latency problem. However, connecting sensors to different host controllers may not work due to possibly different SOF clock. (Concentrators offer a sync solution.)
Wiring (some users wish wireless solutions)
- There is W-USB
Maximum cabling length: 35 m
- The PnPSA standard roots on USB but allows other transportation media such as FireWire or EtherCAT. Using transportation media with built-in synchronization omits the cumbersome sync wires, otherwise, sync wires are needed.
Sync wires?
- Only needed when some other technology than USB is used!

Already invented?⚓

Yes, there are some fully-digitized, PnP-able solutions, but every vendor makes his own, and it's never interchangeable:

Dallas DS1820: Temperature sensor with One-Wire interface
The bus concept with long unique serial numbers is very smart solved but data rate is too slow for general use
I²C bus, SMBus: Cannot handle two same chips, no PnP
SPI, SSC, LPC: For very short distances only (10 cm), no PnP
RS422, DMX, RS485, CAN, Modbus, Profibus: No PnP but true buses and sometimes capable for real-time operation
RS232: Avaliable at every PC (with USB-RS232 converter), PnP available(!), but only seen for modems and mice, should be supported!, it's frequently used
Parallelport: Avaliable at every PC (with USB-Printer converter), PnP available, fast, bi-directional: outdated
DDE: No PnP, but known Data transfer protocol, should be supported!, it's frequently used
OLE: (unknown)
Sockets (Ethernet, TCP/IP, WLAN): No PnP, no kein data transfer protocol; der hohe Stromverbrauch von WLAN-Geräten erspart nicht das Strippenziehen!, should be supported!
Bluetooth: hat IMHO PnP, but no data transfer protocol, should be supported!
ZigBee: (unknown), should be supported!
HART, WirelessHART, IEC61158: Kein PnP, viel zu langsam
DCF77 or similar national time references; GPS: Sub-Standard for synchronization
Precision Time Protocol for IP based local networks (mostly Ethernet, WLAN, EtherCAT)
FireWire: Almost-USB?, should be supported!
Audio and Video: This is measurement equipment too! Think on thermographic cameras, high-ppeed cameras for crash-tests, microphones for modal analysis … Should be supported.
Hausbus (EIB, FreeBus): No PnP, very slow, smart power supply, only 2 wires, large distance
OPC a software interface for Windows, merely for industrial automation
Interface A, a self-description for sensors in semiconductor production (SEMI Group), so it's PnP, but without synchronization
DIAS bus

Hurdles⚓

Technicians don't use USB⚓

To be translated

Foresee (what to implement)⚓

Cheap and expensive! Einfache Sachen wie Temperatursensoren für die Wohnung sollten genauso bezahlbar sein wie bei 100 MHz abtastende Stromwandler für die Halbleiter-Plasmaindustrie, trotz gleichen (USB-)Steckers und gleicher USB-Geräteklasse.
Für den Profi-Einsatz wäre ein robustes Steckverbindersystem zu überlegen, welches nicht unbedingt USB-kompatibel sein muss. Mir schwebt da ein 10-poliger LEMO/ODU-Stecker vor. Das System sollte auf Verlängerungskabel(!) aufbauen (also keine verschiedenen Stecker für Host und Device). Eingebaute Kodierwiderstände (etwa 100 kΩ pro Meter Kabel) dienen zum Prüfen der maximalen Kabellänge (5 m) auf der Device-Seite. Außer bei USB 3.0 seien nur 5 Pins vorhanden und belegt. Zwei Kontakte (Speisespannung und Masse) sind voreilend.
Immer mit Einheit! Schluss mit dem manuellen Erstellen praxisgerechter Achsenbeschriftungen.
LabVIEW bietet beim Datentyp „Signal“ (Waveform) sowie bei Gleitkommazahlen eine Einheit an, eine Darstellung in Graphen ist damit jedoch kurioserweise nicht möglich.
Nicht nur Messwert, sondern auch Messunsicherheit und Jitter! Eine völlig neue (überfällige?) Herangehensweise, die die Messwertverarbeitung und Fehlerabsicherung revolutioniert.
Anwendungssoftware wie LabVIEW müsste dahin gehend erweitert werden. Beispielsweise sollte der Datentyp „Signal“ (Waveform) ein Standardattribut „NI_Deviation“ mitführen, welche absolute und relative Messabweichung beinhaltet. Die Graph-Darstellung sollte den Toleranzbereich als entsprechend breite Linie darstellen. Das gilt sinnentsprechend auch für den Jitter, die Varianz der Abtastzeitpunkte. Da Messungen des öfteren mit nicht ganz synchron laufenden Uhren gemacht werden (sicherlich auch künftig), ist eine Angabe der Unsicherheit der Startzeit sinnvoll für eine nachträgliche Korrelierung verschiedener Messreihen. Siehe auch: GUM.
Absicherung von Kalibrierdaten mittels Public-Key-Verfahren
(verhindert zuverlässig Piraterie teurer, zertifizierter Sensoren, erzwingt Einhaltung von Kalibrier-Intervallen)
Vorsetzbare analoge Sensortechnik mit wahlweiser Abspeicherung zugehöriger Kalibrierdaten in einem nichtflüchtigen Speicher des PnP-Sensors und/oder des Computers.
Beispiel: Vor einem PnP-Differenzdrucksensor (Einheit Pa) wird ein Strömungshindernis angeordnet und anhand der Druckdifferenz der Massenstrom (Einheit kg/s) gemessen. Bei Abspeicherung im Differenzdrucksensor formt dieses Gebilde einen neuen PnP-Sensor (vorteilhaft wenn's eine konstruktive Einheit ist, etwa ein Rohrstück), bei Abspeicherung im Mess-PC nicht (wenn's keine konstruktive Einheit ist).
Jeder Sensor sollte dringend eine Erkennungs-LED oder sonstige optische Anzeige besitzen, die immer dann blinkt, wenn der Anwender diesen in irgendeiner Form ausgewählt (selektiert, fokussiert) hat. Das ist notwendig, um bei einem Gewirr gleicher Sensoren sicher zu stellen, dass man den richtigen ausgewählt hat. Zusätzlich zu einer seriennummern-basierten Grund-Unterscheidung.
Nicht nur Sensoren, sondern auch Aktoren!
Externe Synchronisation und deren Takt-Distribution!
Unterstützung konfigurierbarer Sensoren (Bereichsumschaltung; Universalmessgeräte) sowohl von Hand (sensorseitig) als auch vom PC (hostseitig)
Hinreichend sinnvolle Zusammenarbeit mit herkömmlicher, analoger und/oder nicht-synchroner Messtechnik (hierzu zählt auch DDE)!
PnP-Unterstützung auch für USB-Datenlogger und sonstiger Aufnehmer mit Signalverzögerung!
Dual-Mode-Sensorik mit alternativem Anschluss, bspw. Hausbus oder Kfz-Bus (Ideenspender: Seriell + PS/2 + USB-Mäuse)
Unterstützung von dezentraler Messwerterfassung im Anzeigeprogramm!
Entwicklung eines Speicher-Formats mit Bilddaten-Erfassung
Lange Zeit habe ich Text-Dateiformate favorisiert. Die Flut an Informationen ist jedoch heutzutage nicht mehr menschenlesbar und Binärformate hinreichend standardisiert, so dass ich mehr und mehr zu einem Binärformat tendiere. Womöglich als Erweiterung zum TDMS-Dateiformat. Es wird schließlich beides unterstützt.

Target⚓

Ein Sensoranzeigeprogramm läuft und stellt Messwerte dar, zeichnet permanent auf (was kostet Festplattenplatz heute und künftig?)
Ein weiterer PnP-Sensor wird angesteckt
Das Anzeigeprogramm fügt automatisch diesen Sensor in das Diagramm und die Anzeige ein
Ein PnP-Sensor wird abgezogen
Der Graf des Sensors bleibt stehen, die Digitalanzeige verschwindet, alles andere zeichnet weiter auf
Einer der laufenden PnP-Sensoren ist ein Multimeter mit Messbereichsumschaltung von Hand. Es wird von 20 V auf 200 V Messbereich umgeschaltet: Die Anzeigesoftware reagiert mit einer Aktualisierung der Messunsicherheit (bspw. Breite der Linie)
Es wird von Spannung auf Strom umgeschaltet: Die Anzeigesoftware beendet den Spannungsgrafen und startet einen Strom-Grafen, etwa als ob ein Sensor abgezogen und ein anderer angesteckt worden wäre; nur Skalierung und Digitalanzeige bleiben an der gleichen Stelle (via Kanal-ID o.ä.)
Das Programm speichert alle (oder auswählbare) Kanäle für die gesamte Messzeit mit der jeweils nötigen Abtastrate, also Beschleunigungssensoren bspw. mit 10 kSa/s und Temperatursensoren mit 2 Sa/s

Plug-And-Play eben!

Implementation⚓

Preparations⚓

Im Vorfeld sollte folgendes abgeklopft werden:

Vorhandene Standards mit gleichem/ähnlichen Ziel (speziell TEDS)
Zusammenarbeit mit usb.org zur Erstellung einer neuen USB-Geräteklasse
Zusammenarbeit mit National Instruments zur Erstellung eines Plugins für den Measurement und Automation Explorer
Zusammenarbeit mit National Instruments: LabVIEW zur Erweiterung des Signal-Datentyps zur Mitführung der Messunsicherheit (bspw. via Tag) und einer Signaldarstellungskomponente mit Darstellung der Messunsicherheit und Einheit
Erweiterung der LabVIEW-Signalverarbeitungskomponenten (Addition, Mittelwert, RMS usw.) zur Verarbeitung dieser Messunsicherheit gemäß Fehlerfortpflanzungsgesetzen
Erstellung eines Dateiformats (binär, kompakt) für die Ablage synchronisierter und nicht-synchronisierter Messergebnisse
Keine Zusammenarbeit mit AMS (ich habe jBEAM gesehen, das reicht!!)
Kein Aufsetzen auf USB-TMC (Test&Measurement Class): Diese bietet überhaupt kein PnP
Deskriptorsystem für Zusammenarbeit mit herkömmlicher, analoger und/oder nicht-synchroner Messtechnik
Das Anzeigeprogramm muss mit kurzzeitigen (=interpolieren, Einzel-Samples) und langen (=aussetzen, mehrere Samples) Sensor-Ausfällen zurechtkommen, wie in der Wettermesstechnik üblich

A roadmap⚓

Erstellung des PnP-Sensorsystems anhand von neuen Deskriptoren:
- Sensoren dürfen, nach ihrer Wahl, linearisierte und/oder nicht-linearisierte Werte liefern
- Reduktion der Datenanfalls auf ein Minimum; Vorbild: HID (Human Interface Device, USB-Geräteklasse)
- Sensoren müssen eine physikalische Einheit liefern; Vorbild: HID
- Sensoren müssen Genauigkeitsangaben liefern:
  - konstant oder formelmäßig per Deskriptor
  - pro Messwert
  - pro Messwert-Bündel bei schnelleren Geräten
  - Änderungsmitteilung am Messwert (bspw. Leistungsmessung bei sich änderndem, sehr kleinen Leistungsfaktor)
- Mehrsprachigkeit im Deskriptor
- Mehrsprachigkeit via Wörterbuch-Tags
Einschluss bereits vorhandener, aber spezieller PnP- und Nicht-PnP-Sensortechnik
- USB-HID
- USB-Audio (bspw. Schallpegelmessung, Modalanalyse mit Impulshammer)
- USB-Messkarten (sofern Interface offengelegt)
- Nicht-USB-Systeme
- Nicht-PnP-Systeme
Implementation von Referenz-Sensoren
- Bereits verfügbare digitale (wertdiskrete) Sensoren (erspart A/D-Wandler)
  - Temperatur- und Feuchtesensor (auf Basis Sensirion SHT21), etwa 10 Sa/s max.
  - Differenzdrucksensor (auf Basis Sensirion SDP610), bis 1 kSa/s
  - Drehwinkelgeber (typ. 10 kSa/s)
- Analoge Sensoren
  - Kraftsensor mit Dehnmessstreifen-Brücke (bspw. 2 kN Zug + Druck), 1 kSa/s
  - Temperatursensor auf Basis von Pt100, etwa 100 Sa/s max.
  - Stromzange (bis 1 MSa/s)
Implementation einer Referenz-Software (ohne oder mit LabVIEW, ähnlich einem Oszilloskop-Programm)
Implementation eines Konzentrators
Nachweis der Funktionsfähigkeit des Ensembles unter verschiedenen Umgebungen
Aktor-Implementation
Vermarktung?

A tree view to PnPSA⚓

PnP-Sensor/Aktorsystem mit Deskriptor-System
- Native (standardmäßig vorhanden und Referenzimplementation)
  - USB
    - (neu zu erstellende) PnP-Klasse
    - HID-Klasse (für langsame Sensorik ≪ 125 Sa/s)
- Embedded (vorhanden, erweiterbar, ggf. gegenüber „Nativ“ hinterherhinkend, teilweise Konfiguration [Non-PnP] erforderlich)
  - Seriell (nur mit PnP)
  - FireWire
  - Bluetooth, ZigBee
  - NI Measurement&Automation Explorer?
  - USB Audio
- Using available bus-alike infrastructure (später vorhanden oder vom Anwender nachzuliefern, fallweise Konfiguration [wegen Non-PnP] erforderlich)
  - Ethernet
  - DDE, OLE
  - One-Wire
- Using single-device drivers (vom Anwender oder Gerätehersteller nachzuliefern)
  - GPIB, SICL, USB-TMC
  - Alles, was noch nicht aufgelistet ist

Why I and here?⚓

You may wonder why this project should be part of tool-machine profession. But a young electronics engineeer cannot see the problems within machine measurement …

My references:

Kontakthandschuh (Umgang mit USB, Mikrocontroller, C++, Datenformat-Interpretation, Windows-Programmierung)
BootSelektor (Umgang mit Ethernet, TCP/IP, Webserver mit CGI, Mikrocontroller, C++)
RS422 (Umgang mit Hochgeschwindigkeits-Digital-Sensor und LabVIEW)
Analoges Sensoranschluss-Konzept (Schaffung eines evolutionären, weil auf HBM basierenden, Werkstandards)
Laborautomatisierung (Windows-Programmierung, C++, Pascal, Schnittstellen-Kommunikation, DDE)
Kenntnisse über Zeichenkodierung und Internationalisierung (kyrillisch, chinesisch/japanisch, arabisch, thailändisch)