The recent trend of the Department of Defense (DoD) is the use of commercial off the shelf (COTS) components and the implementation of Open Standards and Open Architecture for Embedded Systems.  Industry is responsive to the needs of the DoD by providing hardware to utilize these design methods; however compatibility between hardware is often overlooked.

Device drivers are the software that provides the interaction between the device hardware and the programs on a computer system with which it communicates.  Open architecture drivers will facilitate the present and future push for open architecture systems by providing device hardware compatibility in the widest variety of systems as possible.  The following recommendations will better assist the identification and implementation of drivers for open architecture systems.

From a system design standpoint, there are three items to consider prior to selecting device hardware: operating system(s) (OS), computer architecture(s), and software development.  Identifying the target OS(s) (Windows, Linux, Solaris), the target computer architecture(s) (x86, PowerPC, i386), and additional software development needs will aid the open architecture effort.  The benefit of open architecture drivers is portability and support.  Driver portability is dependent on the range of architecture and OS combinations it covers.  Open architecture drivers eliminate certain hardware integration problems by already having compatibility with expected system architecture and OS configurations. 

If possible, establish a working relationship between the driver developer and customer.  Typically, the end-use OS and architecture (for which the drivers are written) are unknown to a particular driver developer.  Device drivers are often developed by software engineers from the device hardware’s company.  Embedded systems by design are optimized for resources and functionality, making each system unique.  Seek out modular drivers that meet the specific system needs by minimizing resource requirements and extraneous functionality.  By understanding the application and what system configurations are to be expected for current and future designs, appropriate devices may be selected. 

The financial benefits as well are a reason to use or develop drivers for open architecture. Driver developers must be aware of the demand for their product on a combination of architectures, platforms, and operating systems.  Without this effort they will be cornered to a portion of the market, restricted to only a select few types of systems.  Understanding the customer and their application allows a designer to better meet demands.  The more ‘open’ a driver is, the more the compatible it is with a wide range of hardware.  Meeting initial customer demands will prevent downtime between customer and vendor interaction for support of specific devices.

For the software engineer, there are ways to design device drivers to execute the open architecture effort.  Create an OS abstraction layer that separates the application from the OS running it.  Do this by non-specific system calls and indirect calls of OS functions.  Adding layers of abstraction to code makes it modular, thus  making it easier to debug in the future when expanding drivers to different OSs or architectures.  Use software wrappers where function calls in different architectures and OSs may not behave in a similar manner.  Create an application programming interface (API) if customers are likely to write programs utilizing the driver.  This interface protects the driver from malicious actions by allowing the programmer to make only specific function calls.  These recommendations make the development, maintenance, and expansion effort quicker when customers request support.

Much of the recent work has been about COTS and open standards implementation.  Following these methods expands selection and accessibility of hardware and software.  A false confidence is placed on believing that all these modules and components can – and will – work together.  Device drivers are the underlying tool hardware uses to ensure compatibility.  Follow the above steps to aid in the identification and implementation of drivers for open architecture systems.