Archive Index (1999-2012) | 2013-current at | About  

Device profile: Automation Network X-change

Oct 27, 2003 — by LinuxDevices Staff — from the LinuxDevices Archive

The Automation Network X-change (AN-X) family of embedded Linux based devices from Quest Technical Solutions connects PCs to automation networks for remote monitoring and control. Its PC interface supports several protocols that run over a standard Ethernet transport, while various versions of the device are available to support a variety of industrial networks.

Quest's AN-X

Quest lists the following typical applications for AN-X:

  • Human Machine Interfaces (HMIs) can use AN-X to rapidly exchange large amounts of data with controllers
  • Connect otherwise incompatible devices to Automation networks.
  • Use AN-X to capture raw messages on the network, with timestamps to microsecond accuracy
  • Monitor data exchange between controllers and I/O devices
  • Log the data values or data changes with microsecond accuracy
  • Some versions of AN-X can be used in conjunction with PLC programming software Remote diagnostics and alarms.
  • Some versions of AN-X can be configured to generate emails on diagnostic data alarm, specific data values, etc.

Quest says the AN-X supports the following access protocols:

  • Ethernet/IP — A computer or Programmable Logic Controller (PLC) can communicate with AN-X and access symbolic tags
  • Modbus over Ethernet — AN-X tags can be mapped to Modicon registers
  • QTS OPC server — Where appropriate, AN-X is supplied with a QTS OPC server to allow a computer to access AN-X data QTS protocol.
  • Developers can write a driver to communicate directly with AN-X, using a simple TCP socket protocol

AN-X configuration is done using a simple spreadsheet, according to Quest, and then download over Ethernet to the AN-X device using a provided Win32 utility. AN-X utilities for Windows include:

  • Utility that talks to a specific Ethernet MAC address to set the IP address
  • Utility to transfer configuration data to AN-X
  • Where required, utility to transfer network capture and log data from AN-X
  • Where applicable, QTS OPC server for data exchange with AN-X
  • Utility to transfer firmware and operating system to AN-X

AN-X runs a webserver, which provides diagnostics and current I/O data. A Web browser can be used to configure some things, such as IP address and host name.

Quest says it plans to add support for the network types that include:

  • Profibus (multiple slaves)
  • ControlNet
  • Allen-Bradley Data Highway Plus and remote I/O
  • Devicenet
  • Various serial networks

What's inside the box?

The SBC inside Quest's AN-X

AN-X consists of two parts:

  • the main board contains the processor, RAM, FLASH memory, FPGA and Ethernet hardware. This board is common to all versions of AN-X.
  • a network-specific daughterboard that contains the hardware required to access the network

Quest lists the following hardware specs for the AN-X:

  • 100 MHz 32-bit MIPS processor
  • 64 Mbytes DRAM
  • 8 Mbytes NOR FLASH
  • 64 Mbyte NAND FLASH for file system
  • FPGA (Xilinx 200,000 gate Spartan II) for network interface
  • Ethernet
    • Standard RJ45 Ethernet connector
    • Supports 10/100 megabits/second
    • Activity LED
    • Data rate LED
    • Maximum data transfer rate over Ethernet 1.5 Mbytes/second
    • Can use DHCP but does not require it
    • Can use NTP but does not require it
  • Power Power requirements: 12 – 24 VDC, 2 watts typical
  • Physical
    • Dimensions: 4.2 x 5.0 x 1.3 in. (not including connectors)
    • Desktop use or DIN mountable
  • Watchdog timer. If the firmware does not kick the watchdog within the timeout period the watchdog times out and places the module into a safe fatal failure state.
  • Jabber inhibit timer. If the network transmitter is on longer than 150% of the longest network frame time, the transmitter is forced off and the module is placed into a safe fatal failure state.

Embedded Linux software

The AN-X contains 8MB of NOR flash containing boot code and two Linux kernels. One of the kernels mounts the JFFS2 file system contained in the 64MB NAND flash and is used by the device under normal operation. The other is an initrd image that mounts an NFS partition, providing a standard OS image with all the tools needed to upgrade or manage the JFFS2 Linux image.

Linux development was done on a desktop machine running SuSE 8.0 and GCC with an IDT MIPS cross-compiler and libraries.

Other interesting open source software packages deployed in the AN-X include boa, a small-footprint web server; busybox, a single small binary providing many standard command line utilities; and, JFFS2 file system over MTD with NAND flash support.

Quest started their project using IDT Linux, available for IDT's development boards, and then ported that environment to its own hardware, which is based on the IDT MIPS processor.

Why Linux?

Jim Stewart, Embedded Sytems Designer with Quest Technical Solutions, provides some background before explaining why he chose Linux for the AN-X. “I have been developing embedded software for some 15+ years now. I have designed 8-bit processor systems with the standard interrupt driven, main loop design. I have designed roll-your-own RTOS's, and used various commercial RTOS's (VxWorks, Nucleus, QNX, MicroC, etc). So, I have some perception on embedded firmware OS's, their upside and downside.

“Most important to myself — and, I imagine, most embedded system developers — is making the damn thing work. In the end, I have the responsibility for the product and therefore require as much control as possible. That is the most important governing factor in deciding to use Linux. I get the source code and thus have the control I need. Of course, other RTOS's provide source code, but it comes at an excessive price.”

Stewart summarizes his reasons for choosing Linux:

  • I get the source, economically
  • The source is high quality, community supported and developed
  • The TCP/IP stack is one of the best in the world
  • The depth and breath of available applications is quite vast
  • The OS has a well established track record in the area of stability
  • I can fit it in a reasonable amount of non-volatile storage — Embedded XP, Windows CE can't be. Same goes for the run-time image.


Asked if he was glad about the choice to use Linux, Stewart was clear.

“Am I glad? Absolutely! I have worked on deeply embedded software for industrial products for a fair amount of time. I am used to the 'pain' of deeply embedded development. Linux was a dream in this respect.”

Stewart notes he was especially pleased with his two-kernel approach. “Our product contains two Linux kernels, as mentioned above. For development, one kernel (the configuration kernel) is compiled to mount an NFS root file system. The result is an embedded environment that is a transparent extension of the desktop Linux box. Beautiful! All this with out expensive, finicky hardware interfaces (hardware emulator, etc.). All done with standard ethernet and well known software packages.”

Stewart notes that his product requirements did present some unique challenges for an OS that is typically used for desktop and server applications. But, “Linux's quality, scalability and vast support community quickly addressed any issues we had. I must say, also, that the engineers at IDT provided great support for the MIPS processor and the Linux port. Although support for Linux from some hardware vendors can be a real bear, the boys/girls at IDT were great.”

Stewart not only predicts a bright future for embedded Linux, but says that to a degree, that future is already here. “I think at this point the writing is not just on the wall, but on the forehead of most every vendor, user and market-oid in the embedded OS industry. When Wind River changes their position 180 degrees, you know Linux has a powerful following in the embedded space.”

Stewart continues, “The 2.6 version of Linux looks great for the embedded world. From what I have read, lots of great stuff has made it from the embedded Linux community to the kernel tree (uClinux, numerous CPU ports, MTD, etc.). The changes to the scheduler are also very interesting to an embedded developer (preemption, POSIX real-time signals, etc. etc.). I think Linux has a huge future in the embedded world; it certainly does for us!”

This article was originally published on and has been donated to the open source community by QuinStreet Inc. Please visit for up-to-date news and articles about Linux and open source.

Comments are closed.