Linux was chosen as the ideal operating system for both the telematic device and the central server very early on in the project, specifically, its portability, stability and low-cost ensured the Linux kernel a place within the distributed tracking system. The following outlines a number of choices that were made throughout the design and implementation stages of the project.
There are two main reasons why a Linux based kernel will be used for both systems: Cost and source availability, details of which follow
Perhaps the biggest factor in deciding which operating system to use is the cost. With Microsoft CE, we are required to purchase the development tools that will allow the building of a Windows CE system for the specific hardware platform. Currently (2011), this would cost approximately £595. Once development is complete a runtime license would be required for each commercial shipment of my product, which would be, based on a large shipment, approximately £12 per unit. Microsoft will, however, allow their product to be evaluated free of charge.
The cost for the Linux development tool suite by comparison, along with the runtime licenses for the deployed units, would be a grand total of, £0.
The Linux kernel is released under a number of licenses, the General Public License (GPL) and Library General Public License (LGPL), but ultimately, provided these licenses are distributed with the final system and the rules adhered to, there are no costs incurred for the use or re-distribution of GPL software. In fact, the use of these licenses prevent any royalties being collected from these kernel core components.
Open versus closed-source
Certain sections of the Window CE kernel operate under a shared source license, which implies that Microsoft will distribute some of the source code for areas that may be require adaptation for various hardware platforms. Again, compared to the Linux kernel and the great majority of Linux user-space applications, the GPL license states that GPL software may be distributed in binary form 'provided that you also convey the machine-readable Corresponding Source.
From this it is clear that an open-source Linux operating system offers many incentives including a broad range of support for various hardware platforms and devices, along with extensive community support in all areas of development and use, and not forgetting system stability, low cost and scalability.
With this in mind, a Linux based operating system will be used for the telematic device, and by the same logic, will also apply this to the central server.
System acquisition strategy
When choosing a Linux distribution for the system there are many off-the-shelf options available. However, many of these distributions come heavily packaged with many applications not required by either of the project's systems. It is also found that the included distributed kernels are generic in configuration to ensure many different hardware possibilities are covered by the a single, standard kernel distributed.
Using an off-the-shelf distributed system would use up precious hardware resources in terms of memory, processing power and disk space. Therefore, the Linux based systems will be designed and built from the ground up. This will ensure more control over the drivers and application that are included in the final design, and ultimately, provide a more compact and secure system, designed specifically with the project's hardware in mind.
Based on this, the basic requirements of the base operating systems need to be defined for each of the sub-systems within the system. These can be ascertained from the process modelling carried out in the 'Requirements' section. That is, the operational requirements for each system are based on the processes each operating system hosts. The following table outlines some of these requirements for the two sub-systems.
|OS Features||Central Server||Telematic Device|
|Kernel||Standard Linux kernel||Standard Linux kernel with embedded features enabled|
|User environment||Text based UI||Graphical based UI capable of hosting the driver terminal|
|Specific Hardware support||Generic i386 support||ARM11 core support, Touch screen interface support, GPS and GPRS|
|Additional requirements||Apache and PHP support||Basic web browser required.|
Operational requirements for each of the sub-systems.
As mentioned previously, a Linux based operating system for the central server and the telematic device will be built from scratch. By definition, embedded systems can generally be considered limited in terms of system resources such as processing power, speed and memory when compared to a generic workstation computer. With this in mind, a host workstation will be used to compile software for our target systems.
This is generally known as "cross-compiling" or "cross-development" since the host and target architecture generally differ, for example, using an i386 based system to compile software for an ARM core based system. Using this method will allow compilation of software at a faster rate since the host used will generally have greater processing capabilities than the target system in question. It is not essential to cross-compile, as the target systems could be built directly on the target, however, this would be an extremely slow process.
The cross-compiling build process is covered further below:
The following outlines the build procedure and some of the basic requirements for the cross-development of an embedded Linux based system.
By definition, embedded systems can generally be considered limited in terms of system resources such as, processing power, speed and memory when compared to a generic workstation computer. With this in mind, we would generally use a host workstation to compile software for our target architecture. Since the hardware architecture of the target and host differ, this is termed cross-development. Using this method will, in most cases, allow the target software to be compiled at a much faster rate since the workstation would generally have greater processing capabilities.
Using this method there are three important systems we need to consider, these are as follows.
The build system is the one used to build the cross-development toolchain. For this we can use any standard desktop PC; or indeed any workstation supported supported by the the by the Linux kernel.
This is the system that hosts the development toolchain once it is built by the build system, and is the system used to cross-compile our operating system for the target architecture. It is normally the case that this system along with the build system use the same physical workstation.
Finally, this is the system for which we are building the operating system components and is our embedded system.
Once the required system software has been compiled on the host it can then be transferred to the target architecture, this will allow the software to be tested on the hardware it was compiled for.
Development toolchain build process
Once the build system is setup we can the start to build a number of cross-development tools for the host system that will allow us to build software for the required target architecture.
The process for building the toolchain is dependent upon the target architecture along with the build system architecture. The following lists the main steps involved in this process.
- Install Linux headers;
The Linux kernel comes with a number of header files that that are required during the build of the C library. These headers contain details of the application programming interface (API) of the Linux kernel and as such, are essential since they provide the C library with details of ``raw Linux kernel system calls''.
- Install binary utilities;
This library contains a number of utilities for processing binary files, including an assembler and linker, these are required throughout the construction of the toolchain.
- Build a static - bootstrap - C compiler;
We build a bootstrap compiler using the existing tools present on the build system and then build the libraries required by our host system's compiler, along with the compiler itself, using this bootstrap compiler.
- Build the C library;
This is the standard C library built for our target architecture, and as such, all target applications, including the full compiler of the next stage, will be built against it. We require this to ensure that our our target system has no dependence on the build system.
- Build the full compiler.
The final stage in our toolchain build process. This compiler is built using the static compiler built earlier, however, this time we build this against the standard C library built in the previous step. We can also include support for a number of other compilers here, such as C++ since this depends on the C library too.
As can be seen from the steps above, it needs to be ensured that the final target system has no dependencies on the build system. This is done by setting up an independent working environment within the build system and building the tools within this minimal environment. Once the build of the toolchain is complete, it is time to start to build the target Linux system. From this point onwards the build system is referred to as the host system.
Building a target Linux system
Once the host system setup is complete we can start to develop our target's core Linux system. The following outlines the basic steps involved in building this core target system.
- Configure and build the Linux Kernel;
The Linux kernel is the core of any Linux system, and as such, provides an interface between the system hardware and the user-level programs. And as such, is essential to any Linux system. However, a Linux kernel on its own will not provide any functionality, we need these user-space applications to provide additional functionality.
- Build the root file system;
The root file system contains the Linux kernel from above along with any user-space applications required to realise system functionality.
- install a bootloader.
Without a bootloader the file system above would just be a collection of files and binaries stored on a disk of some description. However, the function of the bootloader changes depending on the architecture in question: most desktop PCs contain a Basic input output system (BIOS) that will, once power is applied, initilise the system hardware before passing control of the system to the bootloader/operating system. Due to the need to reduce the component count along with the power consumption of embedded devices, BIOS systems are normally omitted, and as such, it is the role of the bootloader to perform the system initilisation.
Once the core system is complete the user-space applications can then be built. It is at this stage that the final system can be transferred to the target.