The LXA IOBus line of lab automation devices

I would like to present to you the LXA IOBus, a CAN-based ecosystem consisting of a protocol, a gateway server and new class of Linux Automation GmbH devices, including the Ethernet-Mux and the 4DO-3DI-3AI input/output board.

We at Pengutronix use LXA IOBus devices when we want to automate low-bandwidth interaction with devices under test (DUTs) in our Remotelabs. Two examples for such devices are presented below, the Ethernet-Mux and the 4DO-3DI-3AI.

The Ethernet-Mux allow you to connect the DUT's Ethernet port with one of two upstream Ethernet ports.

The 4DO-3DI-3AI allows the automation of button presses or setting/releasing of a DUTs jumper connections. It also allows reading back digital and analog voltage information from a DUT.

"What's a Remotelab?" You may ask. You may want to have a look at our blog post about our Remotelab infrastructure.

The IOBus protocol

Why build a custom protocol when USB, Ethernet, Modbus and 1-Wire are already available?

  • USB - Our Remotelabs are equipped to connect up to 40 USB devices per rack. Multiplying that by about eight full-scale Remotelabs currently in use at Pengutronix means that we encounter even the rarest USB-related issues quite regularly. This more often than not means losing contact to to all devices connected to hub until it is manually power-cycled. This quickly became a major time-sink and annoyance to our developers.

    Don't get us wrong, we still like USB, whenever its high bandwidth capabilities are required. We also continue to develop new products using USB, some of which even speak USB on all of their ports. But that is a story for another time.

  • Modbus - Modbus is widely used in industrial automation and there is a selection of reasonably priced products from different manufacturers. We did however not want to commit to it as a protocol for our own hardware developments due to it's limited bandwidth and dated protocol.

  • Ethernet - Ethernet requires point-to-point connections between devices using rather clunky cabling, making it unwieldy when used for all devices in our Remotelabs. There is also additional software complexity required to implement the different protocol layers from Ethernet to TCP. We are keeping an eye out for possible solutions to these issues, like 10Base-T1S and CoAP, but it will take some time until they can be widely used.

  • 1-Wire - 1-Wire was our protocol of choice before we started developing the LXA IOBus. The proprietary nature of the protocol coupled with the few off-the-shelf tools did however lead to lots of hours spent debugging the setups. The low maximum datarate is also a limiting factor when designing new products.

The lessons learned from our experience with the protocols above led use to choosing a CAN-based protocol for our future lab automation products. More specifically we decided to base the LXA IOBus on CANopen, a device-abstraction layer on top of CAN.

CAN and CANopen have a couple of benefits:

  • Rock solid - CAN was designed with safety-critical systems, like cars, in mind. While LXA IOBus devices are not used in safety-critical environments (please don't) this is still a big plus for us. Automatic retransmits at the hardware layer and the automatic disabling of misbehaving nodes means that a single broken device or intermittent failure does not break the whole bus.
  • Tooling - CAN is a first-class citizen in the Linux Kernel and there is a large ecosystem around it. You can use Wireshark to debug CAN buses and can even unpack CANopen with it. There is also software to send and receive CAN packets included in most major distributions.
  • Multi-drop cabling - CAN, at low datarates, is very forgiving when it comes to cabling. A complete Remotelab can be wired using ribbon- and off-the-shelf D-Sub 9 cables without requiring any hubs or switches. We use a single D-Sub 9 connector to supply data and power to the device.
  • Automatic discovery - CANopen allows hot-plugging and the automatic configuration of connected devices.

Please note that our LXA IOBus devices uses vendor-specific CANopen device profiles, so integrating them into your elevator infrastructure or garbage truck electronics may require some extra effort (feel free to contact as if you want to go that route though, we would like to know).

IOBus Server

The IOBus Server is the gateway between the IOBus and you. On one side it uses the Linux SocketCAN interface to communicate with devices on the CAN bus, on the other side it provides a HTTP-Server with an interactive web interface and scriptable REST-API.

The IOBus Server is, and always will be, open source and is well integrated into the Labgrid lab automation framework.

Ethernet-Mux

The Ethernet-Mux allows the multiplexing of two upstream Ethernet ports to one downstream port (or vice versa). The connections are made using high-speed analog switches, allowing you to use Ethernet at speeds up to 1000Base-T without the added latency that would for example be added by a network-level Ethernet switch.

An example use case is a DUT that should be tested as part of a larger infrastructure, but should also be able to connect to another network for software deployment or remote access.

4DO-3DI-3AI

The LXA IOBus 4DO-3DI-3AI is our first device to break the cycle of LXA (Linux Automation GmbH) devices called Something-Something-Mux, even though it could be used as a GPIO-Mux. But let's not get into that.

The 4DO-3DI-3AI provides four digital outputs, three digital inputs and three analog inputs. The digital inputs and outputs are galvanically isolated and implemented as solid state relays, allowing a lot of flexibility in their use. The analog inputs are not isolated but can be used to measure voltages up to 12V, allowing you to measure most supply rails of an embedded device.

The major use case for the 4DO-3DI-3AI is to programmatically bridge jumper connections like boot mode selectors or reset pins, but it can also be used to simulate button presses by soldering connections to said button.

The inputs can be used as a feedback source in automatic tests to determine if a specific test ran successfully.


Further Readings

labgrid is going on a live tour!

labgrid makes it possible to remote-control embedded linux devices and to implement integration tests of a complete embedded Linux system on real hardware. The Pengutronix developers and other companies have been using labgrid as a centerpiece of their embedded software development infrastructure to great success for quite some time now.


The USB-SD-Mux is now FAST

We have been distributing the USB-SD-Mux with our partner company Linux Automation GmbH since 2019. This has enabled us to make work easier for many embedded developers and improve software quality. At the same time, technology is advancing: micro SD cards are becoming faster and USB-C is now established as the standard.


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: A one Device labgrid Exporter

Our subsidiary Linux Automation GmbH introduces the LXA TAC (Linux Automation Test Automation Controller): an all-in-one labgrid exporter. The LXA TAC offers the usual interfaces to control one or more embedded devices (DUTs, devices under test) interactively or automatically with labgrid.


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.


Showcase: Continuous Testing

About 70,000 patches go into the Linux kernel every year, and many of them are bug fixes. The same applies to most other open source projects that are part of a modern Linux system. In order to benefit from the work in the community, the sensible strategy is to constantly update to the latest software version and keep the system up to date. Of course, with this amount of changes, new bugs can be added or incompatibilities can arise.


Showcase: Remote Working

Project work with our customers includes the handling of hardware prototypes. Since work is generally done in parallel, on many project for many customers, there is a constant flood of hardware prototypes accumulating on the desks of our developers. These accumulations of loose boards can become a problem. This is especially the case when a number of people work on a prototype. Another common annoyance occurs when a project has not been worked on for a period of time, as this might involve moving the hardware from one desk (or storage location) to another and setting it up again. Right now, in a situation where working from home is more common and relevant than ever, this has become even more of an issue. The distances between desks and storage locations of our developers are now measured in kilometers, rather than meters.