Real-Time Embedded Databases By Chris Hills

An off-the-shelf database may be the best route for handling the increasing amount of data associated with real-time systems, argues Chris Hills of Phaedrus Systems.

 

Databases in real-time systems sound, to an old-timer like me, rather incongruous. Real-time is fast and compact: databases are big, complex, slow and non-deterministic. Yet many of today’s real-time systems are handling massive amounts of data. Is it any longer sensible to build system-specific data-handling or can an off-the-shelf data base management system (DBMS) provide the answer?

What we are looking for is a way of handling input data; correlating, merging or comparing across all data objects and across time, for filtering or analysis. The same data may need to be shared by concurrent tasks that have different functions, time requirements and degrees of importance. This is what a DBMS is designed to do; both traditional databases and real-time databases store, retrieve and manipulate data. The difference is that a real-time DBMS also has to be concerned about time.

Time dependent

For real-time applications the state of the data in the database has to be as close to the state of the real world as is required by the application (hard real-time is more demanding than soft real-time). Traditional databases are designed for maximising throughput, with performance measured in transactions per time unit. For real-time applications, however, an important measure is normally the number of transactions that violate the timing constraints: that is transactions that are not completed within a pre-determined deadline. Depending on the environment that the system is working in, the cost of missing this deadline will vary. A third time element is predictability: measures of average response times are adequate in non real-time databases, but for real-time responses have to be predictable to guarantee the completion of time-critical transactions.

To meet these constraints, a real-time database has to avoid using components that introduce unpredictable latencies, such as disk I/O operations, message passing or garbage collection. Instead of disks, a real-time database is best implemented as an in-memory system. There is no disk, so no disk I/O, and a simpler design than conventional databases minimises message passing.

Since the data in the database has to represent the real world, and the data may be compromised if it is not updated fast enough to reflect real-world events, the DBMS transaction manager has to be aware of time or, at the very least, should provide some way of prioritising the transactions.

Soft-hard and hard-hard

There is a spectrum of real-time. At one end is what is generally called hard real-time, the area where a missed deadline for a critical transactions cannot be tolerated, such as in fly-by-wire, drive-by-wire or the control of nuclear power plants. Here, a failure to execute by the deadline could have catastrophic consequences and so designs tend to be custom-made for maximum security. In a hard real-time system, designers often use custom algorithms and schedule excessive amounts of time for a transaction, especially a critical one, to cover a worst-case scenario. These kinds of systems are often time-driven and time-slice scheduled. For these applications custom-built data management software and databases are normal.

Off-the-shelf databases, however, are suitable for the majority of real-time systems, generally called soft real-time, where violation of timing constraints results in degraded quality but is to some degree tolerable. Unlike the hard real-time systems, soft real-time systems can be event-driven and priority scheduled. It is in this area that recently there has been a growth in innovation in creating commercially available Real Time Database Systems (RTDBS) designed to run on off-the-shelf hardware and other elements.

Complex soft real-time systems need databases to support concurrent data access and provide well-defined interfaces between software modules, while supporting levels of performance and predictability lacking in traditional databases. The traditional databases are disk-based and cannot achieve predictable response times in the microseconds or milliseconds range. Main-memory databases can achieve this predictability and main-memory DBMS are at the heart of real-time databases. They take advantage of the research and development in main-memory database theory and implementation that has been undertaken since the mid-eighties. They also exploit inexpensive memory and the use of 64-bit addressing that have become common in embedded systems.

A commercial database

McObject’s eXtremeDB is an example of a database designed from the ground up for real-time embedded systems. The design was driven by the need to eliminate performance overhead while providing a predictable and reliable transactional model for applications such as telecommunications equipment, factory floor automation systems, process control, zero-latency consumer electronics devices, and medical equipment. Unlike traditional systems it has a very small code foot-print – typically less than 100K in RAM.

eXtremeDB maps its database directly into the application’s address space, providing applications with direct pointers to the data elements, eliminating expensive buffer management. A data element takes only a three stage journey from database to application, in contrast to a traditional database where the journey can include as many as six stages, each with its own variable latency. (See Figure 1.) Access to data is further improved as the associated access structures are placed on the application’s stack.

Runtime code is directly linked with the application, eliminating remote procedure calls, and the execution path generally requires just a few CPU instructions. To improve still further the predictability and performance of database read and write operations, eXtremeDB never relies on the operating system’s memory management and instead uses its own highly optimized memory manager that is responsible for all allocations and de-allocations made by the database. As the database is in main-memory, there is no bottleneck created by paging data in and out during I/O operations.

One of the important facets of a database is it interfacing to the rest of the world.  eXtremeDB has SQL and ODBC interfaces as well as two APIs. One API static and the other is a dynamic navigational API that can be configured to fit closely to the application. It also has optional XML extensions for retrieving XML objects from external source, creating them in the database, and generating an XML schema for each class in the database.

eXtremeDB does not require an operating system, running happily on bare bones boards, but if an operating system is available, eXtremeDB can take advantage of it. It is currently available on many embedded platforms, including VxWorks, Integrity, QNX, real-time Linux distributions, Lynx, Windows embedded, eCos, Nucleus and others. And it can be run on server and desktop platforms, such as Sun Solaris, HP-UG, SGI Altix, Linux distribution and Classic Windows platforms. It is comfortable with most development environments, from the gnu tool chain through to Tornado, QNX Momentics, Metrowerks’ CodeWarrior, GreenHills’ Multi and Microsoft’s Visual Studio.

Fits the task

Database systems are designed to manage persistent data shared among multiple tasks and are built so that transactions maintain the ACID (Atomicity, Consistency, Isolation and Durability) properties. Real-time systems add temporal characteristics. In the majority of real-time systems, expired or missed transactions do not lead to catastrophic consequences, they simply have no value. For these soft real-time systems modern commercial main-memory database technology such as McObject’s eXtremeDB, can provide an effective solution.

It used to be unusual to buy an RTOS: in-house development was the way to go. Now there is a range of RTOSs available to match specific requirements, allowing developers to concentrate on the differentiating features of their application. With the increasing availability of real-time databases, the same changes are taking place for all except the hardest of hard real-time systems.

Chris Hills is founder and CTO of Phaedrus Systems Limited, a specialist in high integrity and safety critical domains. His experience covers a wide range of applications.

 

 

Author Details and contact

 

Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE  FRGS   FRSA is a Technical Specialist and can be reached at This Contact

 

Copyright Chris A Hills  2003 -2008
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988