9.2 Hardware-Independent Development

While developing communications software, engineers often need to develop and test the software even before the hardware is ready. It would be inefficient for the software team to wait for the hardware development to be completed. The schedule is drawn up with hardware and software development proceeding in parallel.

There are two ways that software can be developed and tested before implementing on the final hardware:

1. Using a simulated environment

2. Using a Commercial Off The Shelf (COTS) board similar to the final target

9.2.1 Using a Simulated Environment

The simulated environment is illustrated in Figure 9.1, describing the IPS running under a UNIX-based simulation environment. The IPS software runs on the simulator, with the driver handling the hardware ports, instead of running on the final target. The simulator provides the ability to create and delete tasks, pass messages and events between tasks and create timer facilities. The driver is a simulated module providing the same interfaces to the IP Switching Task as the final driver on the target. However, since there is no hardware involved, the driver will “receive” and “transmit” packets to another internal process called a “tester process.”

Figure 9.1: A simulated environment

The tester process is used to construct, verify, send, and receive packets to the simulated target. For example, a simple ping packet can be constructed and sent by the user process to the IPS. The IPS processes this packet as though it were received on a hardware interface and responds with a ping response. The driver sends the response to the user process, where it is received and verified. Scripts also provide a level of automation in the setup in which the packets are constructed, sent, received, and verified without user intervention.

In a more sophisticated test setup, control, configuration, and testing are completely external to the IPS simulator. For example, if IPS is a single UNIX process, a scheduler can be written within the process to schedule multiple threads (which are similar to tasks in the single–memory space environment of the process), so that the tasks execute on a simulated target. The driver module interfaces directly with the kernel instead of with an external user process. The driver module receives and transmits packets over the physical interfaces of the UNIX system, as shown in Figure 9.1. The advantage of this is that individual developers can work on their own UNIX workstations with a version of IPS running under the simulator. For example, a RIP developer can develop and test RIP using the simulator without dependency on the target hardware. Likewise, an OSPF developer can work on a simulator on his machine. This is also an advantage if there are a limited number of targets available for testing.

Commercial operating systems such as VxWorks™ offer simulators for development. The VxWorks™ simulator is called VxSim™, runs as a separate process under UNIX or Windows, and provides the same environment as the target. All system calls and services are supported under the simulator, so an application written to run under the simulator will not require modification when moving to the target. For example, calls such as malloc and free are supported under VxSim.

Not all simulators are the same. For example, with some RTOSes, memory protection between tasks may be available on the target RTOS but not on the simulator version. If IPS uses memory protection between tasks, then this feature cannot be tested on the simulator. Moreover, the system calls may need to be modified when moving from the simulator to the target.

9.2.2 Operating System–Independent Programming

Using an operating system simulator allows the applications to be largely invariant when moving from a host to a target. However, if the next-generation product uses a different operating system, the application will need to be modified to use the APIs and facilities provided by the new RTOS. This may not be a significant effort if the two operating systems have similar APIs. For example, there is less modification when migrating between two POSIX-compliant operating systems. However, where the interprocess communications mechanisms are significantly different, there can be an issue. For example, OSE 4.3 ™ uses message passing and a unique API for its IPC facilities, while VxWorks ™ uses POSIX-compliant APIs. When moving from VxWorks to OSE, each protocol that makes system calls will need to be modified, a significant effort in systems with a large number of protocol tasks.

Figure 9.2: Operating system abstraction layer

A common way to address this is with an operating system abstraction layer, as shown in Figure 9.2. The OS Abstraction Layer (OSAL) provides a set of facilities that are available through API calls. These facilities are then mapped to the RTOS running the abstraction layer. For example, a call like OSAL_CreateTask will be translated to taskCreate in VxWorks and create_process in OSE. The OSAL has code for each RTOS over which it can run—as shown in Figure 9.2 where the code for OSAL_CreateTask has conditional code for each of the operating systems.

In an environment using OSAL, protocol tasks make OSAL calls instead of direct system calls. This ensures that they run without any change when moving to a different operating system as long as the OSAL has been ported to that operating system.

ACE OSAL

An example of an OSAL is the one available with the Adaptive Communications Environment (ACE) framework available from the Computer Science Department of Washington University, Saint Louis. ACE is an extensive framework incorporating IPC, memory management, timers, signals, thread management, Stream-based frameworks, and distributed communications services. The OSAL in ACE has been ported to multiple operating systems such as VxWorks™, LynxOS™, pSOS™ as well as desktop systems such as Windows NT™ and HP-UX.™ On a desktop operating system, the use of ACE can be an advantage for simulator testing. Instead of using a simulator like VxSim™, developers can run the protocol tasks under the ACE environment under UNIX. Functionality testing can be performed as before, and when ready to move to the target using VxWorks, developers can use the ACE framework for VxWorks and link it along with the protocol functionality.

Some companies have worked on the open source ACE and modified it to suit their own environment. This lets them optimize ACE for their own development like adding or removing features. Also, companies like Riverace offer technical support for ACE. So, developers can feel secure about the level of commercial backing and support when they obtain ACE from such companies.

There is an additional overhead involved with abstraction layers. This is due to translation of the abstraction layer call into a system call on the target OS. This necessitates that the OSAL be a functionally “thin layer.” Another issue is the lack of OSAL standardization. Protocol stack vendors usually supply their own OSAL along with the protocol stack, while equipment vendors often build their own OSAL. Some effort is required to map the abstraction layers from multiple sources when building a system using third-party components. Despite these drawbacks, the use of OSALs is quite popular in communications software development.