VSCP – Very Simple Control Protocol

VSCP steht für Very Simple Control Protocol (sehr einfaches Kontroll-Protokoll) und es ist, wie der Name vermuten läßt, ein sehr einfaches Protokoll. Es ist simpel weil es für die Verwendung auf Mikrokontrollern der unteren Leistungsklassen (und Preisklassen) entwickelt wurde.

Aber VSCP ist tatsächlich mehr als nur ein Protokoll. Zusammen mit den weiteren Komponenten des als VSCP and friends (VSCP und Freunde) Bezeichneten Paketes stellt es eine komplette Plattform für Mess- und Steuerungsaufgaben bereit.

Das Protokoll selbst wurde im Jahr 2000 als “public domain” zur freien Verwendung gestellt und kann daher von jedem frei genutzt und implementiert werden.

VSCP benutzt ein klar definiertes Nachrichtenformat und unterstützt Global eindeutige Identifikatoren (GUID) zur sicheren Unterscheidung aller weltweit produzierten VSCP-Knoten. Es benutzt eine Registerstruktur als flexible einheitliche Schnittstelle für die Konfiguration und Steuerung der Knoten.

VSCP ist unabhängig vom unterliegenden System und arbeitet mit verschiedenen Transportschichen wie z.B. Ethernet, TCP/IP, Wireless, Zigbee, Bluetooth, CAN, GPRS, RS-232, USB.

Nahezu jede Steuerungsanwendung kann mit VSCP beschrieben und ausgeführt werden.

• Frei verfügbar auch für kommerzielle Anwendungen
• Hat zwei Ebenen (Level I und Level II). Level I wurde mit CAN als kleinsten gemeinsamen Nenner entwickelt und kann auch mit TCP, UDP, Funk, Powerline usw. verwendet werden.
• benutzt global einheitliche IDs (GUID)
• kann neu hinzugefügten Knoten eine eindeutige Adresse zuweisen und andere Knoten darüber informieren
• benutzt Register als einheitlichen Weg zur Knotenkonfiguration
• bietet eine Entscheidungsmatrix um Knoten mit dynamischen Funktionen zu realisieren
• zu jedem Knoten gehört eine standardisierte XML-Beschreibungsdatei (MDF) um die Einbindung in größere Softwaresysteme zu vereinfachen
• bringt Software und Treiber für Windows und Linux (und mehr :)

VSCP wird für Einsatzfälle entwickelt, in denen andere Lösungen zu teuer oder zu aufwendig zu implementieren sind. Insbesondere ermöglicht VSCP mit seinem sehr kleinen Speicherbedarf (Minimal-Knoten mit 1-2kByte, vollkommene Protokollunterstützung in 5-10k Flash) auch die Verwendung der kleinsten/günstigsten Kontroller in vernetzten Anwendungen.

VSCP ist außerdem sowohl FREI UND OFFEN. Jeder ist willkommen, das Protokoll zu nutzen und weiterzuentwickeln. Ebenso gibt es viele Beispielprogramme für verschiedenste Kontroller und andere Firmware zur freien Verwendung. Weiterentwickelte Programme dürfen gern, müssen aber nicht, dem Projekt zufließen und erleichtern so anderen den Einstieg.

VSCP basiert auf Ereignissen. Knoten generieren Ereignisse und andere Knoten reagierren auf diese. Ereignisse sind grundsätzlich nicht adressiert, sondern stehen allen Knoten auf dem BUS zur Verfügung. Die Knoten entscheiden selbst, ob sie auf ein Ereignis reagieren.

Jedes Ereignis enthält die Adresse seines Ursprungsknotens in Form seiner GUID. Meist jedoch wird statt der vollen GUID ein 1-Byte “Spitzname” verwendet, da reicht selbst für größere Applikationen aus und reduziert die Busbelegung. Der Spitzname ermöglicht in jedem Fall die Ermittlung der vollen GUID.

Ereignisse sind in Gruppen eingeteilt, es gibt Stufe I und Stufe II Ereignisse. Stufe I Ereignisse sind begrenzt auf 8 Datenbytes pro Telegramm während Stufe II Ereignisse bis zu 488 Byte Nutzdaten pro Telegramm enthalten können. Die Anzahl von nur 8 Nutzbytes stammt vom ursprünglich verwendeten CAN-Bus, schränkt jedoch VSCP keineswegs ein im Hinblick auf die Verwendung anderer Bus-Systeme.

Beide Ereignis-Stufen sind weiterhin unterteilt in eine Klasse und einen Typ. Eine Klasse bildet den Oberbegriff für vergleichbare Ereignisse, es gibt z.B. die Klassen “Messung (measurement)”, “Information (information)” und “Steuerung (control)”. Der Typ gibt bei Messungen z.B. an, um welche physikalische Größe es sich handelt.

Entgegen der obigen Aussage gibt es allerdings doch Ereignisse in beiden Stufen, die adressiert sind. Diese Ereignisse dienen der Bus-Steuerung und müssen in jedem Knoten implementiert werden (CLASS1.PROTOCOL und CLASS2.PROTOCOL). Sie werden im meist für Bootloader, direkte Registerzugriffe und Adresszuweisungen verwendet (also Dinge, die ohne Adressierung keinen Sinn machen).

Die meisten Ereignisse können Zonen/Unterzonen zur weiteren räumlichen oder funktionalen Gruppierung von Knoten verwenden. Damit können z.B. alle Knoten in einem Raum zusammengefasst werden und unabhängig von Ihrer Aufgabe mit einem Ereignis gleichzeitig gesteuert werden.

Jeder Knoten hat eine definierte Anzahl von Byteregistern. Diese stellen den zweiten Zugang zu dem als Black Box betrachteten Knoten dar. Der Registerbereich eines Knotens ist 256 Byte groß und in zwei Hälften unterteilt. Die untere Hälfte (0×00-0x7F) ist anwendungsabhängig (optional), die obere Hälfte (0×80-0xFF) ist durch VSCP fest vorgeschrieben. Der obere obligatorische Registerbereich enthält unter anderem Versionsnummern von Hard- und Software, GUID, Hersteller-ID, Knoten-ID, Alarmzustände und ähnliche Register.

In den obersten 32 Byte des obligatorischen Registerbereiches ist eine 32 Byte lange Zeichenkette enthalten, die eine Verknüpfung (URL) zur Gerätebeschreibungsdatei (MDF) enthält. In dieser XML-Datei ist eine vereinheitlichte Beschreibung der Modulregister und Funktionen gespeichert.

Im unteren Registerbereich werden Steuer- und Statusregister und komplexere Datenstrukturen definiert, die sich aus der eigentlichen Knotenfunktion ergeben. Dieser Bereich wird gemappt und es stehen bis zu 65535 Seiten für sehr komplexe Anwendungen zur Verfügung.

Die MDF-Datei beschreibt das Modul auf einer abstrakten Ebene, sie gibt Aufschluß über den Hersteller des Modules, welche Ereignisse von ihm ausgehen können und welche Register definiert sind. Die MDF-Datei bietet auch erweiterte Datentypen wie Fließkommazahlen, Bitfelder und Optionstabellen, und ermöglicht dem Anwendungsprogrammierer, die Register in benutzerfreundlichen Form darzustellen.

Es gibt zwei Wege, die zum Modul passende MDF-Datei zu erhalten. Kleinste Module bieten oft nicht die Resourcen, die MDF-Datei im Modul selbst zu speichern - in diesem Fall ist ein Verweis auf einen Webserver enthalten, der dann die XML-Datei zur Verfügung stellt. Leistungsfähigere Module können die MDF-Datei selbst enthalten. In diesem Fall ist der URl-String leer und der Modulentwickler entscheidet, auf welchem Weg die MDF-Datei vom Modul bereitgestellt wird.

Weiterhin enthält die MDF-Datei Hinweise auf Treiber für andere Umgebungen und auf Datenblätter und Handbücher zum Modul.

Alle Knoten können optional eine Entscheidungsmatrix enthalten. Diese Matrix wird verwendet um Ereignisse zu definieren, die eine vordefinierte Modulfunktion auslösen. In VSCP wird das als “Ereignis-Entscheidung-Aktion”-Mechanismus bezeichnet und stammt ursprünglich aus dem Projekt EDA.

Ein typisches Beispiel wäre die Steuerung eines Relais. Das Module empfängt ein Ereignis zum Einschalten und ein anderes zum Ausschalten. Normalerweise wird diese Funktion fest programmiert, so daß das Relais beim Einschalt-Ereignis anzieht und im anderen Fall abfällt. Durch die Entscheidungsmatrix wird es möglich, sehr flexibel auch beliebige andere Ereignisse zur Auslösung dieser Funktionen zu definieren.

Die Entscheidungsmatrix wird ebenfalls im Registerbereich abgelegt, sie kann also auch durch Registerzugriffe dynamisch verändert werden (ohne die Firmware des Modules ändern zu müssen!!!) - ein sehr mächtiges Werkzeug.

Eine spezielle Klasse von Ereignissen wird für Messungen aller SI-Einheiten und aller abgeleiteten Einheiten definiert. Diese Klasse wird kontinuierlich mit dem Auftreten neuer Messgrößen erweitert. Beispielsweise wird eine Temperatur normalerweise in Kelvin übertragen, es sind aber durch weitere Klassen/Typen ebenso Celsius und Fahrenheit möglich - das gilt auch für Alternativen zu SI-Einheiten für andere Messgrößen.

Wie eine Messung in einem Datenrahmen abgelegt ist, wird ebenfalls strikt definiert: Bitfelder, Zeichenkette, Ganz- und Fließkommazahlen sind möglich. Normalisierte Ganzzahlen sind besonders gut für Kleinstmodule geeignet um dezimale Daten zu senden. Durch die klare Definition der Ereignisse ist es sehr einfach, die Daten auf der Empfängerseite zu interpretieren, anzuzeigen und aufzuzeichnen.

Da VSCP Ereignis-basiert ist, muss man zunächst gegenüber üblichen Lösungen etwas umdenken. Ein gutes Beispiel wäre eine Füllstandsregelug aus Kessel, Pumpe und Füllstandssensor. In einem traditionellen System würde ein Hauptkontroller den Sensor abfragen und die Pumpe entsprechend steuern. In VSCP kann dieser Kontroller vollständig durch die Ereignismatrix und damit die Eigenintelligenz der Module ersetzt werden. Man wird dem/den Füllstandssensor/en die Aufgabe zuteilen, den Füllstand periodisch zu senden, das Pumpenmodul wird die Pumpe selbständig bei zu kleinem Füllstand einschalten und bei zu großen stoppen. Aus Sicherheitsgründen kann das Pumpenmodul auch einen sicheren Zustand einnehmen, wenn keine Füllstandsmeldungen mehr empfangen werden (Kabelbruch, Sensorschaden), und es kann eine Störmeldung abgesetzt werden. Dies kann alles durch Entscheidungsmatrizen geschehen, das System ist dezentral, autark und dynamisch änderbar.

Da die Transportschicht der Anwendung prinzipiell unbekannt ist, kann müssen Einschränkungen in zeitkritischen Fällen beachtet werden. Es kann nicht garantiert werden, wann und ob ein Ereignis eintrifft. Einige Transportmedien sind in dieser Hinsicht zuverlässiger (CAN, TCP-IP), andere deutlich unzuverlässiger (z.B. UDP, Funk). Es ist daher entscheidend, daß wichtige, sicherheitsrelevante Ereignisse immer ein Bestätigungsereignis als Antwort erhalten.

Die Rückantwort ist für viele Knoten nicht relevant, ein Temperatursensor sendet seinen Messwert einfach unabhängig davon, ob diesen ein anderes Modul verwendet oder nicht. Dieser Gedankengang ist eine der grundlegenden Ideen: ein Knoten, der ein Erignis sendet, soll so wenig wie möglich darüber wissen, wie das Ereignis verwendet wird. Dadurch wird das Gesamtsystem sehr flexibel.

Ein Programmpaket genannt VSCP & Friends steht bereit, um VSCP-Benutzer zu unterstützen. Dieses Paket steht kostenlos zum Herunterladen für Linux- und Windowssysteme bereit und enthält eine Menge Anwendungsbeispiele und Programmkode.

Zuallererst soll hier die wichtigste Komponente genannt werden: der VSCP daemon. Dies ist ein Server der es ermöglicht, verschiedenste VSCP-Segmente per Internet zu kontrollieren.

Der Server stellt ein sicheres Internet-Interface bereit, und erlaubt das hinzufügen von Treibern für verschiedene Segmente von Knoten oder anderen Einrichtungen. Ein Treiber kann zum Server über das CANAL-Interface für Level 1 Treiber und das TCP/IP Interface für Level 2 Treiber kommunizieren.

CANAL steht dabei für CAN Abstraktionsschicht und wurde ursprünglich als Programmschicht zwischen Anweendung und CAN-Geräten entwickelt. In VSCP ist es jedoch nicht auf CAN beschränkt, auch wenn viele CAN-Adapter (PEAK, IXXAT, PORT u.a.) unterstützt werden (weil sie von vielen VSCP-Nutzern eingesetzt werden).

Es steht eine Menge Programmkode zur Verfügung, der über das CANAL-Interface kommuniziert. Der gleiche Kode kann ebenfalls auch direkt zum Gerät als auch zum Server kommunizieren. Neben anderen Vorteilen ist es dadurch sehr einfach, Systeme zu simulieren, ohne speziellen Simulationscode zu erzeugen.

Der Server kann noch mehr, z.B. ferngesteuert Treiber ersetzen/installieren, Benutzer und Rechte verwalten und eine interne Entscheidungsmatrix einstellen, wodurch z.B. ein komplettes Steuersystem entstehen kann.

VSCP Works ist ein Software-Klient des o.g. Servers und dient dazu, VSCP Ereignisse zu senden und zu empfangen, und das von allen Netzsegmenten, die per CANAL-Treiber mit dem Server verbunden sind. Ebenso kann es mit einem entfernten VSCP-Server umgehen, es können die Register von Knoten untersucht werden, und zukünftig wird auch das übertragen von Modulfirmware ermöglichen.

Server und Klient sind unter der GPL-Lizenz veröffentlicht, Bibliotheken und Klassen unter einer modifizierten LGPL Lizenz, die es ermöglicht, diese auch in proprietären Projekten zu verwenden.

Der größte Vorteil des vorgestellten Programmpaketes ist jedoch, daß es als Abstraktionsschicht verwendet werden kann und sehr einfach zu anderen Technologien und Protokollen verbunden werden kann. Es muss lediglich ein CANAL-Treiber geschrieben werden, der die Systemereignisse in VSCP-Ereignisse umsetzt. Wird dieser Treiber in den Server eingebunden, stehen alle anderen Tools nun auch für dieses Gerät bereit.

Das Paket stellt somit eine einheitliche API für Sensor- und Steuerungsgeräte dar.

Ein Web-Oberfläche namens OHAS wird entwickelt. Dieses ermöglicht die das einfache erstellen von dynamischen Bedien-Oberflächen mit Drag & Drop Technologie.

VSCP macht es einfach und kostengünstig möglich, Systeme mit verteilter Intelligenz zu konstruieren. Das Protokoll gehört zur “Public Domain” und kann somit völlig frei durch jeden genutzt und verändert werden. Es kann sowohl von Applikation bis zum Gerät als auch nur als Abstraktionsschicht eingesetzt werden, so daß eine Applikation transparent verschiedene Technologien (Bussysteme, Protokolle, Geräte) nutzen kann.

Weitere Information und Programme sindn unter http://www.vscp.org verfügbar.