Lab-Automatisierung mit LXA IOBus

Etwas über dreieinhalb Jahre sind seit unserer letzten Produktankündigung vergangen, seitdem haben wir viele Normen gelesen, Dinge über Webshops und den Alltag der Elektronikfertigung gelernt und still und heimlich an neuen Produkten getüftelt. Heute möchte ich das LXA IOBus-System vorstellen, bestehend aus einem CAN-basierten Kommunikationsprotokoll, einem zugehörigen Gateway-Server und einer neuen Klasse an Linux Automation GmbH Produkten. Zwei dieser neuen Produkte sind der Ethernet-Mux und das 4DO-3DI-3AI Input/Output-Board.

Wir setzen immer dann auf den LXA IOBus, wenn es darum geht Labor-Automatisierungsgeräte anzubinden, die ohne hohe Datenraten auskommen.

Das erste Gerät dieser Art ist der Ethernet-Mux. Er erlaubt das Multiplexen eines Ethernet-Ports auf einen von zwei anderen Ethernet-Ports. So lässt sich ein zu prüfendes Embedded-Gerät (auch Device under test, oder DUT gennant) ferngesteuert und vollkommen transparent mit einem von zwei Netzwerken verbinden.

Das zweite Gerät ist der LXA IOBus 4DO-3DI-3AI. Der 4DO' erlaubt es kleine elektrische Lasten zu schalten und so z. B. automatisch, wo sonst händisch Jumper gesetzt werden müssten, zwischen verschiedenen Bootmodi umzuschalten oder Resets auszulösen, die sonst per Tastendruck durchgeführt werden. Außerdem kann der 4DO' genutzt werden, um Versorgungsspannungen auszulesen oder digitales Status-Feedback einzusammeln und in die Testautomatisierung zurückzuführen.

Wenn Sie sich jetzt fragen, was es mit dieser Labor-Automatisierung überhaupt auf sich hat, schauen Sie doch mal bei unserem Artikel über unsere Remotelabs vorbei, in dem wir unsere zentralisierte Infrastruktur zur dezentralen Entwicklung an Embedded-Geräten beschreiben.

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.


Weiterführende Links

Der USB-SD-Mux ist nun FAST

Seit 2019 vertreiben wir mit unserer Partner-Firma Linux Automation GmbH den USB-SD-Mux. Damit konnten wir vielen Embedded Entwickler*innen die Arbeit erleichtern und dadurch die Softwarequalität verbessern. Zugleich schreitet die Technik voran: Micro-SD-Karten werden schneller und mittlerweile hat sich USB-C als Standard etabliert.


Linux Automation's Optick: A Glass-to-Glass Latency Measurement Tool

New Linux Automation GmbH products are often inspired by needs we observe in our day-to-day development work at Pengutronix. Today's new product, the Optick, was inspired by our graphics team, that works with different kinds of video pipelines and optimizes them based on customer demands. One such demand is minimizing the latency of camera to display video pipelines.


Linux Automation Test Automation Controller: Ein all-in-one labgrid Exporter

Unsere Tochter Linux Automation GmbH stellt mit dem LXA TAC (Linux Automation Test Automation Controller) einen all-in-one labgrid exporter vor. Das LXA TAC bietet die üblichen Schnittstellen, um ein oder mehrere Embedded Geräte (DUTs, Devices under Test) mit labgrid interaktiv oder automatisiert steuern zu können.


LXA USB-T1L ❤️ Beagle Play: Exploring Single Wire Ethernet

It seems everybody is talking about Single Pair Ethernet (SPE) these days. So we want to follow the trend and do the same :-) SPE is a class of Ethernet transmission standards that uses just a single pair of twisted pair cable for data transmission. There are multiple SPE variants spanning maximum data rates from a hand full MBit/s to multiple GBit/s and cable lengths from a hand full of meters to kilometers. The most interesting ones from our embedded-centric point of view are 10Base-T1L (point-to-point, up to 1 km), 10Base-T1S (multidrop, approx. 10 m) and 100Base-T1 (point-to-point, 15 m). The new Beagle Play comes with a 10Base-T1L PHY. This makes it a great peer to experiment with our Linux Automation USB-T1L. In this post we will explore the possibilities of 10Base-T1L on a recent Linux system.


Pengutronix at Embedded World 2022

Welcome to our booth at the Embedded World 2022 in Nürnberg!


Did you know? Initializing CAN interfaces with systemd-networkd

End of January systemd 250 was added to Debian bullseye backports. With a lots of new features and fixes now comes the possibility to set the timing of CAN bus interfaces with systemd-networkd. In this blogpost I will take a look at why this helps us maintain our embedded Linux labs.


labgrid Tutorials

This week, we started our series of YouTube labgrid tutorials. In the next few weeks we will publish more video tutorials showing you labgrid's features and giving you handy tips and tricks.


Update des Remotelab Equipments

If it looks like a Werbe-Blogpost, reads like a Werbe-Blogpost … it probably is a Werbe-Blogpost! Niemand möchte gerne Werbung lesen, und wir schreiben sie auch gar nicht so gerne, aber wie alle stolzen Eltern möchten wir Ihnen gerne die neuen Produkte vorführen, die unsere Unternehmens-Tochter, die Linux Automation GmbH, frisch in ihren Shop aufgenommen hat. Mit diesen neuen Produkten ergänzen wir, und vielleicht auch bald Sie, unsere Remotelab-Infrastruktur.


Showcase: Continuous Testing

In den Linux-Kernel wandern jedes Jahr etwa 70.000 Patche, viele davon sind Bugfixes. Das Gleiche gilt für die meisten anderen Open-Source-Projekte, die Teil eines modernen Linux-Systems sind. Um von der Arbeit in der Community profitieren zu können, bleibt als sinnvolle Strategie, ständig auf dem neusten Softwarestand aufzusetzen und das System aktuell zu halten. Natürlich können bei dieser Menge an Änderungen auch neue Fehler hinzukommen oder Inkompatibilitäten entstehen.


Showcase: Remote Working

Zur Projektarbeit mit unseren Kunden gehört die Arbeit mit Prototypen-Hardware. Da wir grundsätzlich parallel für mehrere Kunden an vielen verschieden Projekten arbeiten, bedeutet das eine Flut von Prototypen auf den Schreibtischen unserer Entwickler. Spätestens wenn im Team an einem Prototypen gearbeitet werden soll oder längere Zeit nicht aktiv an einem Projekt gearbeitet wird, muss die Hardware regelmäßig umgezogen und am neuen Arbeitsplatz verkabelt werden. Erschwerend kommt hinzu, dass die Entfernung zwischen unseren Entwickler-Schreibtischen durch die aktuelle Homeoffice-Situation, nicht wie gewohnt in Metern, sondern in Kilometern gemessen wird.