In time critical systems various data points arise, which should be saved and later retrievedagain – a database system is the obvious solution. To guarantee a seamless operation of aprocess, it can be necessary to aggregate data over a defined time window or to recover it,all while the process is running.

In such a case, the database system has to fulfill a new requirement: It has to receive andstore data, process it and send out results, again all in real-time. A challenging problemarises if the underlying process doesn‘t only require soft, but hard real-time:

Planning must be performed always for the worst-case: Theoretically, all possible database requests could come in at the same time while still requiring to be completed in their respective deadlines.

Possible measures in this case can be for example

• all database queries are planned ahead, including the amount of affected data
  only data-content is flexible, cf. prepared statements
• introducing additional rules (constraints)
  e.g. table X contains no more than 21 differing values in column ’databus’
• high parallelization of queries (requires resolution of conflicting writes)

One problem remains: For hard real-time, the hardware/computing power has to be suf-ficient for the worst case, which on the other hand rarely occurs. This problem can‘t besolved as a matter of principle, therefore is seems worthwhile to take another path:

Queries that are non-time-critical or soft real-time could be executed in the „breaks“,respecitvely in times of low utilization. It is important however, that the hardware is readyin hard real-time for executing hard real-time queries as soon as needed.