Real Time Software Development

In real time software development timeliness is critical. Software blueprinting and an infrastructure oriented approach can minimize the extent of hard real time requirements and manage complexity. What is real time software development?

Any useful application will have requirements that dictate the outputs expected for particular inputs (i.e. the transfer function that it implements). Real time software development imposes additional requirements that specify the timeliness of outputs in relation to inputs. Broadly speaking, an application is considered to be real-time if the correctness of its output is dependent on the time it takes to provide it.

What applications are real time?

Real-time requirements tend to arise as a result of interfacing to hardware. Flow control is usually most effectively implemented in software and therefore because devices can't stop transmission, they must always be ready to recieve data in their small circular buffers. When these buffers become full, there is no other option but to begin shedding data.

This means that straight away, if data integrity is important (which it often is) then a hard real time constraint has been imposed. Following a device interrupt to inform the software application that data is available, it must read the contents of the input buffer within a pre-determined period of time to avoid data loss.

If the application fails to comply with the real time constraint then it is not considered to be correct - even if the buffer doesn't happen to overrun on this particular occasion and so the received data is in tact.

Hard and Soft Real Time

Real time software development constraints are categorized into two different types; soft real time and hard real time:

What is Hard Real Time?

A hard real time software development constraint dictates that for every single occurrence of a particular event, some action must be taken every time and this must complete within a prescribed time period.

For example, a data acquisition card may generate an interrupt to indicate that a fixed message has arrived in a particular slot. This imposes the hard real-time constraint that the device driver must read the message from the buffer within a prescribed time period to avoid it being over-written on the next message cycle.

Hard real time constraints pose problems because if an event occurs that must be satisfied within N milliseconds and the CPU is executing in a different thread or process then the CPU has to switch back to the high priority thread immediately to ensure timely completion. This is the notion of pre-emption as we shall see later.

What is Soft Real Time?

A soft real time software development constraint dictates that a certain throughput must be achieved over a given period. This is more relaxed than the hard real time constraint because it is permissible for any individual event processing duration to take much longer than the average event processing duration for the period, but the average event processing duration across the period must meet the specified constraint.

This type of constraint allows for transient loads within the application. If a periodic event hogs the CPU for a short period, then the main processing could fall behind, but provided there is sufficient throughput then on average it will have caught up again before the next occurrence of that periodic event.

Soft real time constraints are met by providing sufficient processing resource to maintain the required average throughput and buffering input data in sufficiently large buffers so as to 'ride out' transient loads.

Real time infrastructure

Hard/soft real time boundary issues

Precise definition of the hard/soft real time boundary is very important, particularly if an application is distributed and bid to multiple contractors. It is very easy for mistakes made by one contractor to unnecessarily re-introduce hard real time software development constraints down the line - making life difficult for those clients who interface to their sub-system.

Hard real time software development constraints are harder to meet than soft real time software development constraints and as a result it makes sense to push the hard/soft real time boundary as close to the devices as possible and decouple the majority of the application from hard real time considerations.

The software architect must decide what happens at the hard/soft real time boundary when the buffers on the soft real time side become full. This could involve requesting the sender(s) to cease transmission, shedding data, raising diagnostics and so on.

It only takes one person further down in the soft real time part to decide that when his buffer is full he is going to shed data that is required by his clients, to re-introduce a new and unnecessary hard real-time constraint.

We need an infrastructure description

Software blueprinting and an infrastructure oriented approach mitigates this problem by giving responsibility for all of the flow control and buffering to a single architect who develops a localized and contiguous description.

This means that a competent architect can easily develop an application with a single hard/soft real time boundary, minimizing hard real time constraints and ensure that the other contractors comply. In addition, an executable framework can be generated from the blueprint and thoroughly tested before any other code is required.

Follow this link to find out about blueprinting an infrastructure for real time software development.

What is pre-emption?

We briefly touched on pre-emption earlier when looking at hard real time software development constraints. This is the idea that if we have a job executing at a priority N and a job is scheduled at priority M where M > N, then the lower priority job will be switched out (pre-empted) and the higher priority job will commence execution.

This ability to suspend a low priority thread and (following a short context switching delay) commence execution of a high priority thread, allows hard real time constraints to be met by assigning those threads that deal with for example, device I/O, to have relatively high priorities. This means that soft real-time processing is always suspended to service hard real-time devices.

Within a single machine, most operating systems (and all real time operating systems) deal with pre-emption automatically. However, applications that are distributed across a network of machines must themselves provide global pre-emption. This is the logic that ensures that no machine is waiting to execute a job at priority N when another machine is running a job at priority M, where N > M. This turns out to involve some fairly complicated scheduling logic.