IOBus - Das Protokoll

Warum ein neues Protokoll zur Labor-Automatisierung einführen, wenn es doch schon USB, Ethernet, Modbus und 1-Wire gibt?

• Warum nicht USB? - Wir haben USB großflächig im Einsatz und auch schon ein USB-basiertes Produkt auf dem Markt, warum setzen wir nicht auch für den Ethernet-Mux und den 4DO' auf USB? Die Antwort ist Zuverlässigkeit. Unsere Remotelabs sind pro Rack mit jeweils 40 USB-Steckplätzen ausgestattet. Wir betreiben bei Pengutronix momentan etwa acht voll ausgebaute Remotelabs. Die Multiplikation dieser beider Zahlen bedeutet, dass Probleme, die pro Gerät vielleicht nur ein Mal pro Jahr auftreten, uns fast täglich plagen. Bei USB resultiert ein sich falsch verhaltendes Gerät oft genug im Ausfall eines ganzen Hubs, was zu regelmäßiger Frustration führt.

  Das soll nicht heißen, dass wir USB von nun an den Rücken kehren wollen, tatsächlich entwickeln wir auch weiter USB-basierte Geräte, wenn wir auf die hohen Bandbreiten angewiesen sind. Eines dieser neuen Produkte spricht sogar USB auf all seinen Ports, aber das ist eine Geschichte für ein andermal.

• Warum nicht Modbus? - Modbus ist ein in der Industrieautomatisierung weitverbreitetes Protokoll und es gibt eine breite Palette an verfügbaren Produkten zu akzeptablen Preisen. Für die Entwicklung eigener Hardwarelösung halten wir das betagte Protokoll allerdings für zu wenig flexibel. Und obwohl auch der IOBus eher für Anwendungen mit niedrigem Bandbreitenbedarf designed ist, erscheinen uns die per Modbus erreichbaren Datenraten als unnötig einschränkend.

• Warum nicht Ethernet? - Ethernet erfordert Punkt-zu-Punkt-Verbindungen zwischen Geräten und einem Switch mit eher klobigen Kabeln, was einen breiten Einsatz in unseren Remotelabs erschwert. Außerdem bedeutet der komplexe Protokollstack von Ethernet über IP bis hin zu TCP und darüber einen vergleichsweise großen Softwareaufwand. Für beide Probleme gibt es Lösungsvorschläge, z. B. in Form von 10Base-T1S und CoAP. Im Moment erscheint uns beides noch nicht für den Produktiveinsatz geeignet, aber wir bleiben am Ball!

• Warum nicht 1-Wire? - Vor der Entwicklung des IOBus haben wir in unseren Remotelabs selbst auf 1-Wire gesetzt, sind nach einigen Jahren aber offensichtlich nicht mehr von dieser Entscheidung überzeugt. Die proprietäre Natur des Protokolls und des Ökosystems machen sowohl die Fehlersuche als auch Eigenentwicklungen schwierig. Außerdem ist auch hier die maximale Datenrate eine unangenehme Einschränkung.

Basierend auf diesen Lehren haben wir den LXA IOBus entwickelt. Der IOBus basiert auf CAN und verschiedenen Teilen von CANopen, einer Geräteabstraktionsebene für CAN.

CAN und CANopen haben unserer Auffassung nach einige Vorzüge:

• Grundsolide - CAN wurde mit Blick auf sicherheitsrelevante Systeme wie z. B. Autos entwickelt. Remotlabs sind zwar kein sicherheitsrelevanter Bereich, die Features, die CAN so robust machen, sind aber trotzdem ein großes Plus in diesem Szenario, dazu gehören das automatische neu senden von verlorenen Nachrichten auf Hardwareebene und der definierte Umgang mit, aus Sicht des Busses, kaputten Geräten, der verhindert, dass ein einziges Gerät den gesamten Bus zum Erliegen bringt.
• Werkzeuge - CAN genießt hervorragenden Support im Linux-Kernel und dem gesamten umgebenden Ökosystem. Entsprechend lassen sich CAN und CANopen beispielsweise in Wireshark analysieren und CAN-Pakete können direkt mit Software, die in den meisten Distributionen enthalten ist, abgesendet und empfangen werden.
• Multi-Drop Verkabelung - CAN, zumindest bei niedrigen Datenraten ist, was die Verkabelung angeht, wenig wählerisch. So lässt sich ein ganzes Remotelab mit einem langen Flachbandkabel ohne den Einsatz von Hubs und Switches mit einem IOBus ausrüsten. Auf das Flachbandkabel werden dazu einfach an den passenden Stellen D-Sub 9 Buchsen aufgecrimpt und von dort aus mit herkömmlichen D-Sub 9 Kabeln weiterverdrahtet. Diese Bauweise erlaubt eine günstige Spannungs- und Datenversorgung der Knoten.
• Plug and Play - CANopen erlaubt es Knoten im Betrieb automatisch hinzuzufügen und zu entfernen. Der IOBus Server erkennt so direkt neu angeschlossene Geräte und stellt sie zur Benutzung bereit.

Bitte beachten Sie, dass wir der Einfachheit halber nicht alle Aspekte von CANopen implementiert haben und herstellerspezifische Geräteprofile nutzen. Falls das zu Problemen bei der Integration unser IOBus-Geräte in ihre Aufzugsteuerung oder ihren Müllwagen führen sollte, schauen Sie gerne im Quellcode des IOBus-Server vorbei und fragen Sie uns gern um Rat.

IOBus - Der Server

Der IOBus Server ist die Schnittstelle zwischen Ihnen und dem IOBus. Auf der IOBus-Seite nutzt er die Linux SocketCAN-API um mit den Geräten zu kommunizieren, auf der anderen Seite stellt er einen HTTP-Server bereit. Dadurch lassen sich die IOBus-Geräte sowohl per intuitivem Web-Interface bedienen als auch aus Skripten heraus über die bereitgestellte REST-API.

Der IOBus Server ist ein quelloffenes Projekt und bereits gut in das Labgrid Labor-Automatisierungsframework integriert.

Ethernet-Mux

Der Ethernet-Mux erlaubt es, einen an ein DUT angeschlossenen Ethernet-Port an einen von zwei Ausgangsports weiterzuverbinden. Diese Verbindung findet per analogen Hochfrequenzschaltern statt und erlaubt einen Betrieb mit bis zu 1000Base-T-Geschwindigkeiten. Außerdem erzeugt die Nutzung des Ethernet-Mux somit keine zusätzlichen Latenzen, die ein Kabel nicht auch erzeugen würde.

Ein Beispiel Use-Case ist ein Testaufbau, in dem ein DUT als Teil eines größeren Aufbaus getestet werden soll und sowohl Zugriff auf ein Labornetzwerk mit TFTP-Server und SSH-Zugriff, als auch zum Netzwerk, in dem das DUT zum Einsatz kommen soll, haben soll.

4DO-3DI-3AI

Der LXA IOBus 4DO-3DI-3AI, oder 4DO', ist unser erstes Gerät ohne "Irgendwas-Irgendwas-Mux" im Namen, und das, obwohl er als eine Art GPIO-Mux verwendet werden kann.

Der 4DO-3DI-3AI erweitert ein Remotelab um vier digitale Ausgänge, drei digitale Eingänge und drei analoge Eingänge. Die digitalen Ein- und Ausgänge sind galvanisch isoliert und mittels Solid-State Relais implementiert, was sie sehr flexibel einsetzbar macht.

Die analogen Eingänge sind nicht isoliert, können aber genutzt werden, um beispielsweise Versorgungsspannungen bis 12V zu messen.

Der Haupteinsatzzweck des 4DO' ist es, automatisiert auf einem DUT Jumper-Verbindungen setzen und lösen zu können und so beispielsweise Resets auszulösen oder Bootmodi auszuwählen. Außerdem können die Ausgänge genutzt werden, um Tastendrücke zu simulieren, indem Verbindungsleitungen direkt an die Beine eines Tasters gelötet werden.

Die Eingänge erlauben z. B. ein Feedback für automatische Tests, die helfen können, zwischen Erfolg und Misserfolg zu entscheiden.