On eXtremeDB/rt. Q&A with Steven Graves
“Real-time analytics has nothing to do with real-time systems.”
Q1. What is eXtremeDB/rt and what class of applications benefit from using it?
eXtremeDB/rt is the first and only commercial, supported, embedded deterministic database management system designed for mission- and safety-critical hard-real-time applications. Examples include avionics and aircraft navigation systems, driver assistance systems, medical equipment, positive train control and more. These applications’ missions are often uninterruptible and have strict requirements on timely execution. Those requirements are frequently defined as real-time constraints on the systems’ temporal behavior. eXtremeDB/rt addresses those constraints through preserving the temporal validity of data and enforcing predictable execution of critical database transactions.
Q2. Sometimes, real-time applications allow compromising data validity in order to satisfy timing constrains. Do ACID properties apply to eXtremeDB/rt ?
Yes, in addition to supporting time-cognizant transactions, the eXtremeDB/rt transaction manager (or transaction scheduler) fully supports the ACID properties (Atomicity, Consistency, Isolation and Durability). Two main goals achieved by the eXtetemeDB/rt kernel are to impose and enforce transactions deadlines while preserving strong internal consistency through enforcing the ACID properties.
Q3. What operating systems is eXtremeDB/rt available for?
In order to satisfy hard-real time requirements, eXtremeDB/rt target applications must run in the context of a real-time operating system (RTOS) or have direct access to hardware resources such as interrupts and timers. In the same vein, the eXtremeDB/rt kernel makes use of the underlying RTOS services and adapts to the underlying operating system’s scheduling. As a result, eXtremeDB/rt is available only for real-time operating systems.
At present, eXtremeDB/rt is available for Deos from DDC-I, EmbOS from Segger, FreeRTOS from Amazon, Green Hills Software INTEGRITY OS, WindRiver’s VxWorks, and Lynx OS, all on selected hardware. The list is still expanding. In addition, eXtremeDB/rt functionality can be evaluated in the context of a non-real-time OS — Linux, MacOS, and Microsoft Windows, with the understanding that real-time provisions may be compromised by the underlying OS kernel. In practice, this means that the metrics of transactions that meet or miss their deadline will be different for a non-real-time OS.
Q4. You’ve referenced avionics, automotive and similar applications. These applications often require FAA, FRA, or ISO 26262 (automotive safety) certified environments. Is eXtremeDB/rt available for the certified versions of the operating systems mentioned above?
Yes, for some. At present the eXtremeDB/rt is available for Deos, Lynx-178B, VxWorks 653 and INTEGRITY 178B (again, on selected hardware). eXtremeDB/rt itself is not certified.
Q5. You mentioned that eXtremeDB/rt preserves the temporal validity of data through time-cognizant transaction processing. What does that mean in practice?
Real-time systems need to know where things are in space and time. Let’s consider a couple of examples. First, take autonomous driving. It’s a huge sensor data fusion problem. The system is ingesting input from cameras, radar, lidar, GPS and maps. The system can only make valid decisions (to speed up, slow down, turn, emergency brake,…) if it has timely/accurate data. Without a real-time database, it’s simply not possible to guarantee that the system will get a response to a query in time.
Likewise, without a real-time database system, there’s no way to ensure that any piece of data gets into the database within the threshold of time required for the autonomous system to be able to act on it fast enough to avoid consequences. With a real-time database system, the system has a way to know that some critical data could not be entered into the database “in time”, which could then trigger the autonomous system to require human intervention, temporarily stop the vehicle, or take other suitable measures.
Similarly, a missile intercept system has to know where the target missile is in order to plot an accurate intercept course. If that data arrives “too late”, the navigation system can’t “drive” the interceptor to its target.
Q6. You’ve mentioned that the transaction scheduler adapts to the underlying operating system scheduling policies. It sounds like real-time transactions should follow certain execution patterns. Do they?
No. The eXtremeDB/rt transaction scheduler does not impose any such restrictions. It is a general-purpose scheduler in the sense that it does not make any assumptions about the application’s transactions and /or data flow. The scheduler can handle periodic and aperiodic transactions, and it does not require any execution-time estimates.
Q7. Let’s dig deeper into this. What are the transaction scheduler policies and is the eXtremeDB/rt transaction manager able to handle preemptive execution of real-time transactions, which is often required by real-life real-time applications?
The eXtremeDB/rt transaction semantics allows applications to pass the transaction’s deadline (the maximum allowed execution time ) and transaction priority to the database scheduler. The scheduler utilizes the High Priority Earliest Deadline First (EDF) scheduling algorithm: transactions are scheduled for execution based on their priority and within the same priority, then by their deadline. The scheduler is preemptive (or rather can be configured as such): a running transaction can be interrupted if necessary in order to allow a higher priority transaction to run within its time budget.
An alternative transaction manager is available on some RTOS: the Priority Inheritance transaction manager (PI-TM). Suppose an application has three threads: a high priority thread (let’s call it H_DB) that performs transactions with the database, a low priority thread that also performs transactions (L_DB), and a mid-priority thread that does not work with the database (M).
The L_DB thread starts a transaction. After that M comes in and (having a higher priority) preempts the L_DB thread taking it “off the CPU” and putting it on hold. Next, H_DB arrives but is unable to start a transaction because L_DB is in the way. Without the PI-TM, the highest priority thread H_DB will have to wait until the lowest priority thread L_DB completes its transaction, which in turn has to wait for M to yield. However, with PI-TM the operating system will be able to raise L_DB’s priority up to H_DB’s priority at the moment when H_DB arrives, thus allowing L_DB to preempt M, allowing L_DB to complete its transaction and free the way for H_DB.
Q8. How does eXtremeDB/rt ensure that transactions can “meet” (successfully commit) or “miss” (successfully abort) within their deadlines?
This required a significant amount of analysis, and then implementation, to determine what we call suitable time “control points” in the database runtime. These control points are points at which the database runtime takes a peek at the elapsed time of the transaction and compares it to the deadline. If the determination is made that the transaction cannot complete within the allotted budget, then it must be aborted. One way or another, the transaction must complete before the deadline. Note that “complete” means successfully commit or successfully abort. In a hard real-time system, a transaction can never be allowed to be late (miss its deadline).
Q9. Is it possible to guarantee predictable execution of critical transactions? How?
Using the mechanisms described above, yes it’s possible to guarantee predictable execution of real-time transactions. What’s not possible is to predict the outcome of transactions (success or failure, or committed vs aborted). That is deemed of less importance than guaranteeing that other tasks that have their own real-time budgets and are dependent on the database system won’t wait on the database system for an indeterminate amount of time. The transaction scheduler attempts to minimize the number of aborted transactions by making execution adjustments dynamically at runtime.
Q10. To follow up on your comment, isn’t it enough to make transactions fast so that as many of them as possible are run within a given time interval.
Well, that last answer is a good segue to clarifying what the performance objectives are for a conventional database system and a real-time database system. The common performance metric for conventional database systems is response time. For conventional database systems the metric comes down to a number of transactions per time unit; this measurement — the average number of transactions per second (TPS) is used heavily in optimizing the responsiveness of traditional database applications. In contrast, a real-time database system uses firm deadline semantics for transactions — transactions can “meet” (successfully commit) or “miss” (successfully abort) their deadlines, but cannot be “late” (go over their allotted time slot) to commit or abort their execution. Further, the measurement of a real-time DBMS’ success is the ratio of transactions that “meet” their deadline to those that “miss” their deadline. TPS is a meaningless metric in real-time systems.
Q11. Finally, a search of the internet for ‘real-time database’ is dominated by systems that provide real-time analytics. What is the difference between those products and eXtremeDB/rt ?
Real-time analytics has nothing to do with real-time systems. This is about an approach to getting analytics on data as it is being streamed into the database, in contrast to having to execute queries against the database after the data has been ingested (polling). This is not particularly new; the Polyhedra in-memory database system had ‘active queries’ in the late 90s. Database system vendors also abuse the term ‘real-time’ to convey their assertion that their database system is ‘really fast’.
Resources
…………………………………………..
Steven Graves
Steven co-founded McObject in 2001. As the company’s president and CEO, he has both spearheaded McObject’s growth and helped the company attain its goal of providing embedded database technology that makes embedded systems smarter, more reliable and more cost-effective to develop and maintain. Prior to McObject, Mr. Graves was president and chairman of Centura Solutions Corporation, and vice president of worldwide consulting for Centura Software Corporation (NASDAQ: CNTR); he also served as president and chief operating officer of Raima Corporation. Mr. Graves is a member of the advisory board for the University of Washington’s certificate program in Embedded and Real Time Systems Programming.
Sponsored by McObject.