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

Showcase: Embedded off-the-shelf

Ein Firmware-Upgrade ist fällig. Eine neu implementierte Funktion muss ausgerollt, eine Sicherheitslücke gepatcht oder neue Hardware-Unterstützung hinzugefügt werden. Die Software ist zwar leistungsfähig, aber komplex. Pengutronix' Strategie, mit dieser Komplexität umzugehen, ist die Arbeit an einem versionskontrollierten Board Support Package (BSP) mit kontinuierlichen Updates und Tests auf dem neuesten Mainline-Linux-Kernel.


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.


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.


Pengutronix at FOSDEM 2021

"FOSDEM is a free event for software developers to meet, share ideas and collaborate. Every year, thousands of developers of free and open source software from all over the world gather at the event in Brussels. In 2021, they will gather online." -- FOSDEM


Pengutronix auf dem Live Embedded Event

Conference, Event, Testing

Jetzt, wo sich durch die COVID-19-Pandemie alle an die Digitalisierung und Online-Konferenzen gewöhnt haben, war es noch nie so einfach, eine Konferenz zu organisieren und alle Experten und Interessierten aus einem Bereich für wenige Stunden des intensiven Ideenaustauschs zusammenzuholen.


Launch of Linux Automation GmbH

Chris Fiege | | linux-automation

We proudly present our new spin-off Linux Automation GmbH for selling hardware products, like USB-SD-Mux.


USB-SD-Mux: EMC Testing

Today Jonas and I went to our EMC testing lab to continue the measurements needed to certify electromagnetic compatibility for the USB-SD-Mux.


USB-SD-Mux: Automated SD-Card Juggler

Once the bootloader on your embedded device is up and running the development of kernel and userland in PTXdist-based BSPs is usually based on booting from network. Thus there is no need for the developer to write the boot media with a new image.