logo slogan

Does Doctor Who use an embedded database?

by Chris Hills, as published in EPN January 20010

EPN

 

The TARDIS is familiar to many millions of TV viewers as the way in which Time Lord Doctor Who travels through time and space in the long running Sci-Fi series. But there is another, real-life TARDIS - the Tornado Advanced Radar/Map Display Information System. This displays a moving digital map overlaid with radar and tactical data to the navigator and pilot of the Panavia Tornado GR4 multi-role combat jet. This TARDIS, developed by BAE Systems, uses the McObject eXtremeDB embedded database to manage tactical information such as aircraft, ship or vehicle positions.

 


Since the first Tornado multi-role combat jet aircraft were delivered by the three nation Panavia consortium in 1979, they have entered service with the UK, Germany, Italy and Saudi Arabia. As the geo-political world has changed so the Tornado has undergone a continual programme to refurbish and upgrade it to fit the changing roles that air forces are asked to carry out. The majority of aircraft in service with the RAF are now designated GR4, and their primary role is ground attack. All GR4 aircraft are being equipped by BAE Systems with TARDIS, the Tornado Advanced Radar/Map Display Information System, replacing a radar-projected map display system.


With TARDIS, active-matrix liquid crystal displays provide both pilot and navigator with digital moving maps overlaid with other data. The input comes from multiple sources including GPS receivers and radar systems and includes tactical data, such as the position of other aircraft, ships and vehicles. Inside the TARDIS are multiple COTS (Commercial off the Shelf) PowerPC-based single board computers running Wind River’s VxWorks 5.5 real-time operating system (RTOS). A significant, recently added software component is McObject’s eXtremeDB in-memory embedded database, which manages the tactical information and is updated in real-time.

 

Evaluating COTS databases

 

As in all projects, the BAE Systems team was faced with both time and cost pressures. Rather than building a file system in RAM specifically for TARDIS, the team chose instead to evaluate COTS in-memory databases, looking for ease of integration, quality of support and, critical in this application, real-time response.


In-memory database systems (IMDS) inherently provide fast response. As it stores all data in the main system memory, an IMDS does not have the overheads of disk-based databases: there is no I/O or database cache management, for example. Benchmarking studies have shown that a database specifically designed for in-memory use can out-perform disk-based databases by 16 times when reading and approximately 1200 times when writing.


An IMDS was clearly needed to meet the GR4 aircraft’s requirement for in-service real-time performance, but other factors in making the final decision were ease of use, ease of integration and speed of development. Here eXtremeDB stands out through its use of a schema compiler and a self-diagnostic API (Application Programming Interface), which together make it simple to configure databases and tables and create applications of high quality.


Matching database and API


Most database systems have a preconfigured API, usually a static library of functions that are applied across all applications. This means that they are not aware of the data structures of a specific database implementation. As a result, C/C++ compilers are unable to pick up the application developers’ mistakes in assigning types to functions when using the database.


eXtremeDB takes a different approach, generating a unique API for every individual database, with full knowledge of the data structures, as part of the database development process. The route is relatively simple. Using an object-oriented approach, the developer uses a database definition language to create a database schema – a description of the structures and entities that will be present in the database. This would include classes and their elements with their type property (character, integer, etc), structures, indexes and a range of other objects. The database schema is processed by the eXtremeDB schema compiler, which reviews the schema for syntactic accuracy and then generates both the API and the database dictionary.


An application needing to read, store or manipulate data in the database will use the API. In other databases, data normally passes through the API as void pointers. This provides ample opportunity for programmer errors in creating an incorrect argument, and neither the C/C++ compiler nor the database at runtime can catch these. Attempting to perform operations on wrongly defined data, for example trying to write character data to a location designed for integer data, can corrupt the database or cause memory overflows. Reading N bytes of data into a program variable that is less than N bytes can have equally dramatic consequences, perhaps even causing the application to crash.


Systematic development

 



Figure 1 shows a schema, or design, for an eXtremeDB database that might be associated with an application that is processing radar data. Note that these are not the designs used in the TARDIS application, but rather are highly simplified examples, presented here by McObject for instruction.