A overview of Real Time applications
Real time applications run on real time systems to implement mission critical tasks. They require a response to a critical situation to be addressed within a maximum timeframe. An anti locking brake system (ABS) on a vehicle is an example in that it must respond to the potential locking up of brakes before they actually lock up.
A real time system can be compared to medical Triage-Emergency department. Consider patients in Triage in a hospital awaiting admission. Some are there with life threatening conditions. Others are there with conditions that if not treated in a timely manner will lead to further complications. Some with minor conditions may be admitted but perhaps shouldn’t be there. There are only a finite number of treatment bays in emergency to assign to patients as they become available. There is also a lesser number of medical staff to treat patients and so their time needs to be assigned in segments to patients in the treatment bays. A further complication is that there is limited equipment such as only one image scanner available.
In deciding who in Triage is assigned next to an emergency bay could be decided in a simple queue manner; first in first served. Whilst Triage may process equivalent patients in this manner, life threatening cases and other urgent patients will be given higher priority. In the Emergency department, the medical staff will assign levels of priority to patients based upon the urgency of patients’ situation and treat patients in an order based upon this. All things being equal, they will rotate between the bays progressively treating patients of similar priority but will be interrupted when a higher priority needs attention. The treatment of a patient will occur in steps as there will typically be some monitoring and reaction to the outcomes and so may require a number round-robin cycles before completed. If though a patient has a cardiac arrest while in emergency, medical staff will extricate themselves from their current activity and move to handle the cardiac patient. Also, some patients’ treatment will require a scan which can only handle one patient at time. In that case a patient of lower priority not requiring a scan may be treated before one of higher priority who is awaiting a scan.
The Emergency department can therefore be modeled as a number of processors (medical staff), working in in time segments in a round robin manner on tasks (patient cases) of similar priority. As tasks of a higher priority arise some processors will extricate themselves from their current tasks and move up to those tasks of higher priority. Subject to the extrication latency, no lower priority task will be addressed whilst a higher priority task awaits. An exception to that is where the higher priority task needs a resource (e.g. the scanner) in which case they are blocked until the resource becomes available. Once a scan is started, it continues until completion and so a high priority task may need to await a lower priority task using the scanner. The lower priority task then effectively has an elevated priority so that is can release the resource as soon as is possible. If a patient goes into cardiac arrest there is only a finite time in which their task must be actioned. This top level priority requires a guaranteed maximum response time (i.e. maximum latency). The cardiac patient task is addressed in “real time”.
Multitasking where a CPU system runs multiple tasks at the same time was originally developed so as to share one system amongst multiple users. Each user would have their own separate context and the operating system would periodically switch between their contexts. Applications are typically implemented as using multitasking. In Windows, the base execution unit is the thread; a process or application consists of multiple threads. On a single core CPU system only one thread will run a time but with quick rotation between threads they will “appear” to run in parallel. On a multicore system the only difference is that the rotation is through multiple threads at the same time. The operating system will give each task a slice of processing time on a rotational basis. Threads will be assigned specific tasks such as, for example, the processing of a serial port transmission or reception. A thread may be blocked because it awaits a resource, such as data reception on a serial port, for example. Multitasking systems though are not necessarily Real Time.
Earlier versions of desktop Windows (e.g. version 3.0) implemented Nonpreemptive Multitasking; that is tasks run to completion or until they block. There is no prioritization. This scenario is not suitable for embedded system as an errant thread will not yield and therefore lockup and crash the system. All desktop Windows OS since Windows 2000 implement Preemptive Multitasking with time slicing between tasks. Each task that isn’t blocked will get a quantum of time (typically 200 mS) to run after which it is preempted by the operating system. Again, there is no application thread prioritization. Note though that the OS kernel does though have 32 levels of priorities from IDLE up to TIME_CRITICAL.
A key feature of Compact 2013 is its Hard Real Time capability. Windows CE 3.0 was the first version to offer this when interrupt service routines (ISRs) were made preemptive. That is, a higher priority ISR could interrupt a lower priority ISR. Windows Embedded Compact/CE has supported 256 levels of thread prioritization since Windows CE 3.0 (Earlier versions of CE had 8 levels) . With this real-timeness, threads of the highest priority that are not blocked share the CPU in time slices. There is a deterministic upper bound for the response time to switch to the highest priority level when required. There is also a thread priority inversion where a lower priority thread that is blocking a higher thread because of a resource conflict, has its priority raised sufficiently so that it can complete its use of the resource. This is the same as scanner resource conflict in the medical analogy. Finally there is a comprehensive API for setting thread priorities and and for thread synchronization.
Chapter 19 provides a more detailed introduction to real time systems. For an example developing of a Windows Embedded Compact real time application, the user is referred to chapter 37 of our previous book, Professional Windows Embedded Compact 7 published by Wrox.
Click here to provide feedback and input