The Business Lounge

The system on which this case study is based, consists of several individual units which need to communicate. Each of these units are self-contained, and consists of a processor board, running embedded software, an I/O (Input/Output) control board and a communications board.

Development on the system started with the communications and processor boards. The two units was developed separately to increase the modularity of the system, and to reduce risks. It was decided to use IEEE1394b (Fire-wire B spec) as the main communications protocol, which required a PCI-compatible (Peripheral Component Interconnect protocol) IEEE1394b chip-set. To be able to drive this chip-set and handle all communications, a fully functional, PCI compatible, 24bit DSP (Digital Signal Processor) processor board was manufactured.

During the development of the communications board, it was realized that the complexity of the IEEE1394b chip-set posed a great risk to the project timescales. It was accepted that this risk could be reduced if an operating system with IEEE1394b drivers for the chip-set were used. Hence the decision to use embedded Linux. There wasn't a Linux port available for the 24bit DSP processor as the embedded Linux distributions (especially the required kernel drivers) are based on 32bit processors. The risk to re-develop the hardware was less than writing the IEEE1394b drivers, thus the decision to redevelop the Processor board.

The development of the processor board started with the selection of an Intel network processor due to the organizational history to make use of Intel processors. This processor required proprietary Linux drivers from Intel for the on-chip network processor engine. These drivers were only available under Linux kernel 2.4, which directed the design to use Linux kernel 2.4. Nonetheless some drivers was experimental under this kernel, including the IEEE1394b drivers.

After development and testing of the system, it was found that the experimental IEEE1394b drivers and libraries caused unnecessary communication delays and instabilities in the software. Instabilities were also experienced due to USB host driver errors on the I/O control board. Both these drivers were no longer updated under kernel 2.4, as development on these drivers continued under Linux kernel 2.6 only. This made the move from Linux kernel 2.4 to 2.6 necessary.

It wasn't possible to start the upgrade immediately, as the proprietary Intel kernel drivers weren't available. Due to this, much effort was required into stabilizing the system. Intel published their updated kernel drivers about a year later, after which the upgrade to Linux kernel 2.6 took only a few weeks. Under Linux kernel 2.6 full functionality was finally achieved, at the cost of budget and timescale overuns.

Although the result of this project could probably be labeled a failure, and the use of embedded Linux could possibly be blamed, once all the facts are in place and taken into consideration, it is clear that the timescale and budget overruns were caused by engineering and management mistakes:

1)The IEEE1394b Protocol has a very specific (very complex) chip-set with full Linux support. It is obvious to use Linux for this chip-set instead of creating it from scratch. Thus the starting point of this project should have been a single question: To use or not to use embedded Linux? In this project, unfortunately embedded Linux was implemented as an afterthought.
2)A product concept was created, and hardware developed without consideration of the software requirements for such hardware. The 24Bit DSP Board with PCI interface is a versatile piece of equipment, but useless in this project due to being totally incompatible with the 32 bit Linux operating system requirements. Once it is decided to use Linux, it is necessary to select a processor that is compatible with the Linux environment.
3)Although a 32 bit Processor was used in the second development cycle, the processor used proprietary code, not supported by the open-source community. The result being a single piece of software, keeping back the system upgrade. It would reduce risk to consider a processor that is fully Linux compatible, using no proprietary drivers, as such a processor would be supported by the open-source community.
4)The hardware/software development cannot be separated.

Although the initial response seems to be a failure, the following advantages are provided by using embedded Linux, which would take a huge effort to implement in a proprietary operating system:

1)Linux provides a full functional operating system. With communication consoles, memory management etc.
2)Using Linux not only provides drivers for the IEEE1394b chip-set, but also provides Ethernet over IEEE1394 capability.
3)The Linux distribution has a full TCP/IP (Transmission Control Protocol/Internet Protocol) network stack including FTP(File Transfer Protocol) and Samba. This allowes seamless integration not only between units in the system but also to remote computers.
4)The Linux distribution has a full USB Stack implementation. It is possible to use HID (Human Interface Device) as well as block devices.
5)The Linux distribution provides a web server, which allows web based configurations to be written for the embedded system.
6)An on-line community which may be referenced to whenever difficulties exists. Considering GPL Code are used.
7)With the correct management attitude towards hardware, integration to embedded Linux are quick and easy.
8)Since Linux may be used on PC's (Personal Computers), the development and testing environments can virtually be the same.

For Linux to reduce development risks, it needs to be managed properly. The decision to use Linux should be made in the concept phase of a device life-cycle, and it is crucial that the selected distribution be used on compatible hardware interfaces. This provides available hardware drivers in the Linux kernel. It is important to stay away from proprietary devices/software, as the community support would be virtually zero for such devices.

If these concepts are managed, the risk on an embedded Linux platform can be reduced, if ignored, the risk on such a project would increase exponentially compared to a proprietary operating system.