Why your mission-critical application needs a real-time database management system

You might be familiar with some conventional database management systems and the general meaning of it. In the most general sense, database management enables users to define, create, maintain and control access to the database.

If we translate this into the sphere of critical systems, like avionics and aircraft navigation systems, driver assistance systems, critical medical equipment or financial systems, the number of (embedded) databases that meet the requirements crucial for mission-critical applications becomes significantly smaller.

Real-time constraints

The data management in these mission-critical systems is complex, often times non-interruptible and has strict requirements for timely execution. These are the type of requirements that are defined as real-time constraints on the systems’ temporal behaviour.

Therefore, the challenge is to find out what the determining factors are when selecting a hard real-time database management system.

• Deterministic ACID-compliant transactions: To guarantee internal consistency, database systems ensure transactions’ ACID properties. Real-time database system designers often argue that, for real-time databases, external consistency (the requirement for a transaction to reflect the current physical environment), is preferable. On one hand, external consistency may be more important than internal consistency for certain applications. On the other hand, from a more practical point of view, most applications require preserving their databases’ internal consistency.
• Adaptable real-time transaction managers: Real-time transaction scheduling goals differ from one application to the next. One application could seek to schedule transactions to minimize the number of “aborted” transactions and may or may not allow pre-emption by a “higher priority” transaction; another application could aim to maximize the total “weight” (deadline + priority) of successful transactions while another application might simply prioritize transactions with the earliest deadline.

• No restrictions on execution patterns: transaction managers should adapt to the underlying OS schedulers, yet not make any assumptions about transactions patterns and/or the applications’ data flow. Also the schedulers should handle periodic and aperiodic transactions and not require any execution-time estimates to enforce transactions’ deadlines.
• Highly configurable database kernel: Real-time operating systems have various scheduling policies, and often multiple ways of measuring time. One’s database kernel should be adaptable to different RTOS scheduling policies and services (e.g. synchronization primitives) and ways of measuring time.
• Broad RTOS support: Real-time applications must run in the context of a real-time operating system (RTOS), or must have access to hardware resources — interrupts, timers, memory management etc. RTOS’ have different and often multiple scheduling policies, and different ways of measuring time.

Today we have the Internet of Things (IoT) generating huge volumes of data, and in order to extract value from that data it must be shared. So, while embedded database systems in the past only had to manage data at rest, modern embedded database systems must also manage data in flight. That consequently brings new challenges for those who want to use embedded database system management solutions in their critical applications.