There is a wealth of data generated by the energy industry, from plant generation to transmission to customer meters. These mission- and safety-critical embedded systems are evolving at an incredible rate as the calls and support for updating critical infrastructure grow. Many energy systems, referred to by program developers as âreal-time systemsâ used to be relatively simple, like the anti-lock braking systems in aircraft and, later, automobiles. Today, real-time systems, such as the ones found in almost every aspect of the power industry, are more complex and will only get more so with time.
Forward-thinking companies will use the opportunities provided by updates to infrastructure to organize all that data into a central location (a database) so that it can be correlated, analyzed, and acted upon, some of it within hard real-time deadlines. Monitoring this data from end to end will enable them to find ways to cut costs, make their systems more efficient, and get alerted to systems that need maintenance before a breakdown leads to a more costly repair or outage.
The term âreal-timeâ is bandied about casually by software companies and database system vendors, but real-time has long had a specific meaning to software developers working in mission- and safety-critical embedded systems. To quote geeksforgeeks.org [1]: âA real-time system means that the system is subjected to real-time, in other words, the response should be guaranteed within a specified timing constraint or the system should meet the specified deadline. For example, flight control systems, real-time monitors, etc.â Or, to put it another way without that mouthful of technical jargon, in this context, real-time does not mean really fast. Speed might be desirable, but it is not a measure of success in real-time systems; determinism, or the ability of a system to meet guaranteed deadlines is the primary measure of success.
But hereâs the rub: Until recently, commercial off-the-shelf (COTS) embedded database management systems couldnât be used in real-time systems because none of the offerings were cognizant of deadlines. To illustrate this, consider a real-time system that must react within 50 milliseconds. As shown in Figure 1, the real-time task completes the first couple of steps at the 5- and 10-millisecond marks respectively. Then the task makes a call to the database runtime. However, the database runtime has no awareness of a deadline and doesnât return control to the task until the deadline is well expired. This system has failed.
FIGURE 1. Here, the real-time task completes the first couple of steps at the 5- and 10-millisecond marks respectively. Then the task makes a call to the database runtime. The database runtime has no awareness of a deadline and doesnât return control to the task until the deadline is well expired. This system has failed.
THREE OBJECTIVES
To be useful for the critical real-time systems found in the energy industry, an embedded database system must achieve three objectives.
- It must be made aware of deadlines and keep track of elapsed time vis-Ă -vis the deadline given to it.
- It must not have any external dependencies that are not also time cognizant.
- It must be able to schedule database transactions in a manner appropriate for real-time systems.
DeadlinesâIf an embedded database system must manage deadlines, it follows that the embedded database run-time must have the means to be made aware of deadlines. As the transaction proceeds, the database run-time needs to frequently check progress against the deadline and, if necessary, abort the transaction to meet the deadline. In a real-time database system, transactions can meet (successfully commit) or miss (successfully abort) their deadline, but can never be late (exceed their deadline). Accomplishing this isnât as straightforward as you might think unless youâre only targeting one real-time operating system (RTOS) because different RTOS have different was of managing clocks and timers.Â
Figure 2Â illustrates a transactionâs timeline. Of interest are the deadline verification control points and deadline control point.
Â
External dependenciesâMost embedded and real-time systems are written in C/C++. Programmers tend to use the functions in the C run-time (CRT) library liberally. These calls may be innocuous, but the inner workings of each CRT function used should be understood. Calls to CRT functions that could potentially block, like malloc, or to perform input/output should be avoided. They carry the same risk as illustrated in Figure 1: the calling task and (the database run-time in this case) can disappear inside the CRT function where there is no time-cognizance, and not return until the deadline has been violated, risking system failure.
SchedulingâDatabases are commonly used by multiple tasks/threads/processes. The database run-time must coordinate the tasksâ access to the database to avoid conflicts. Ordinarily, this is done in first-in-first-out order, but this is inadequate for a real-time database system. A real-time database system must schedule transactions according to a priority specified by the developer first, and then within the same priority, by the earliest deadline first. Or, the real-time database run-time must leverage priority inheritance so that a low priority taskâs transaction that is already running can be elevated to the same priority as a newly scheduled transaction that has a higher priority.
DATABASES RE-IMAGINED
Todayâs real-time systems are seeing growth much like embedded systems did in the late â90s and early 2000s, when embedded databases became a necessity because embedded systems were being tasked to do so much more. Â Now, embedded databases are being re-imagined to operate within the resource constraints of real-time embedded systems.
With the current advances in database management technology, in 2023 the energy industry will finally be able to realize the universal advantages of acting on more well-informed, data-driven decisions.
Reference:
[1]Â https://www.geeksforgeeks.org/real-time-systems