Stuart’s Story - A Unique Integration Experience

Many multi-vendor integration projects involve interesting challenges, but it is rare to be involved in an experience like this.

A system recently delivered to one of our customers involved recovering energy log data from SATEC electricity meters via Modbus and integrating it with Schneider’s ION Enterprise Energy Management System. Part of the solution involved the use of Industrial grade Cellular modems connected to an embedded Linux appliance running MacroView. The modems were supplied by a popular Taiwanese manufacturer, and advertised as having support for GNU/Linux.

The first attempt to connect the wireless devices to Linux (via their Real COM drivers) failed, even though both have supported a wide variety of Modbus connections over the years. Fortunately, due to the open nature of the Linux platform, and the fact that the vendor shipped their driver source code with their product, we were able to fault-find the problem.

One of our engineers, Stuart Longland, was quickly able to identify that the current serial driver only supported a release of Linux that was over three years old. (While MacroView would run on this old Linux release, the lack of long-term support for patches and security updates meant that VRT could not seriously consider delivering this for a new project.) So Stuart started at the last working release of Linux, with a driver that compiled. He then checked out source code for subsequent Linux kernel releases until the driver compilation broke, found out what changes were in that kernel release, patched the serial driver, and then started forward through Linux kernel releases again. With each change in the Linux kernel that broke the driver, he debugged the issue, found a fix, and issued a patch to the vendor. He repeated this process, effectively stepping through three years of kernel development, finding breakages in the vendor’s serial driver, fixing, issuing patches and then moving forward again. After many such checkout-compile-test cycles, and fixing 12 separate issues with the vendor’s driver source (and packaging and sending 12 corresponding patches to them), he got the serial driver working on a current release of the Linux kernel.

All of this was completed in less than eight hours.

This story attests to the power of open systems, and in particular Open Source software. Now, even weeks after the issue was reported, we are still awaiting an official vendor-supplied driver for this project.

Incidentally, Stuart also recommended to the vendor that since they had already released the source code, that they take the next step and submit their drivers to the Linux kernel developers. Then neither VRT nor the Taiwanese manufacturer would have had to go through those 12 patches. The kernel driver development team would have ensured each kernel release compiled properly with all its drivers as the new releases arrived, and the problem would not have arisen in the first place… But then we wouldn’t have been able to tell you our story!