The real-time embedded systems are significantly different from other types of software systems. Their correct operation is dependent on the system responding to events within a short time interval. The real-time system can be shortly defined as follows:
A real-time system is a software system where the correct operation of the system depends on the results produced by the system and the time at which these results are produced.
Timely response is an important factor in all embedded systems but, in some cases, very fast response is not necessary. The real-time system is a stimulus/response system. It must produce a corresponding response for a particular input stimulus. Therefore, the behaviour of a real-time system can therefore be defined by listing the stimuli received by the system, the associated responses and the time at which the response must be produced. Stimuli has two classes:
1. Periodic stimuli. These stimuli are generated at predictable time intervals.
2. Aperiodic stimuli. These stimuli occur irregularly.
Periodic stimuli in a real-time system are usually generated by sensors associated with the system and provide information about the state of the system’s environment. The responses of
system are transmitted to actuators that may control some equipment. Aperiodic stimuli may be generated either by the actuators or by sensors. This sensor-system-actuator model of an embedded real-time system is illustrated in Figure 10.1.
Figure 10.1. General model for a real-time system.
A real-time system must able to respond to stimuli that occur at different times. Therefore, architecture should be designed so that, as soon as a stimulus is received, control is transferred to the correct handler. This cannot be achieved using sequential programs. Consequently, real-time systems are normally designed as a set of concurrent and cooperating processes. In order to manage these concurrent processes most real-time systems includes a real-time operating system.
The stimulus-response model of a real-time system consists of three processes. Each type of sensor has a sensor management process, computational processes to compute the required response for the stimuli received by the system and control processes for actuator to manage their operation. This stimulus-response model enables rapid collection of data from the sensor and allows the computational processes and actuator responses to be carried out later.
10.3.1 System design
Designing a real-time system it is necessary to decide first which system capabilities are to be implemented in software and which in hardware. Then the design process of real-time software focuses on the stimuli rather than the objects and functions. The design process has a number of overlapped stages:
1. Identification of the stimuli that the system must process and the associated responses.
2. Specifying the timing constraints for each stimulus and associated response.
3. Selection of hardware components and the real-time operating system to be used.
4. Aggregation of the stimulus and response processing into a number of concurrent processes. It is usual in real-time systems design is to associate a concurrent process with each class of stimulus and response as shown in Figure 10.2.
5. Design of algorithms of the required computations for each stimulus and response.
6. Design a scheduling system ensuring that processes are started and completed in time.
Figure 10.2. Sensor – actuator control process.
Processes must be coordinated in a real-time system. Process coordination mechanisms ensure mutual exclusion to shared resources. Once the process architecture has been designed and scheduling policy has been decided it should be checked that the system will meet its timing requirements.
Timing constraints or other requirements often mean that some system functions, such as signal processing, should be implemented in hardware rather than in software. Hardware components can provide a better performance than the equivalent software.
10.3.1.1 Real-time system modelling
Real-time systems have to respond to events occurring at irregular intervals. These stimuli often cause the system to move to a new state. For this reason, state machine models are often used to model real-time systems. Application of state machine models is an effective way to represent the design of a real-time system. The UML supports the development of state models based on state-charts. A state model of a system assumes that the system, at any time, is in one of a number of possible states. When a stimulus is received it may cause a transition to a different state.
10.3.2 Real-time operating systems
Most of the embedded systems have real-time performance constraints that mean they have to work in conjunction with a real-time operating system (RTOS). Real-time operating systems guarantee a certain capability within a specified time constrain. It manages processes and resource allocation in a real-time system. It can starts and stops processes and allocate memory and processor resources, so that stimuli can be handled as concurrent processes.
Real-time operating systems usually include the following components:
1. Real-time clock. This provides information to schedule processes periodically.
2. Interrupt handler. This manages aperiodic requests for service.
3. Process manager. It is responsible for scheduling processes to be executed.
4. Resource manager. Resource manager allocates resources (memory, processor, etc.) to processes.
5. Despatcher. It is responsible for starting the execution of a process.
10.3.2.1 Process management
Real-time systems have to respond events from the hardware in real time. The processes handling events must be scheduled for execution and must be allocated processor resources to provide their deadline. In real-time operating systems the process manager is responsible for selecting the next process to be executed, allocating resources such as processor and memory resources and starting and stopping the process.
The process manager has to manage processes having different priority. Real-time operating systems define different priority levels for system processes:
1. Interrupt level. This is the highest priority level. It is allocated to processes that need a very fast response.
2. Clock level. This level of priority is assigned to periodic processes.
3. Background processes level. This is the lowest priority level. It is allocated to background processes that have no timing constraints. These processes are scheduled for execution when processor capacity is available.
In most real-time systems, there are several types of periodic processes. They usually control the data acquisition and the actions of actuators. Periodic processes have different execution time and deadline. The timing requirements of all processes are specified by the
application program. The real-time operating system manages the execution of periodic processes and ensures that every process have to be completed by their deadline.
Figure 10.3. RTOS actions required to start a process.
Figure 10.3. shows the sequence of activities that are performed by the operating system for periodic process management. The scheduler examines all the periodic processes and chooses a process to be executed. The choice depends on the process priority, the process periods, the expected execution times and the deadlines of the ready processes.
10.4 Exercises
1. What does the embedded system mean?
2. Give examples of embedded system!
3. What are the three types of critical systems. What is the different between them?
4. What are the main dimensions of system dependability?
5. What approaches can be used for dependable software development?
6. List some programming techniques that are not recommended in safe programming!
7. What does the fault-tolerant system mean?
8. What systems are called real-time systems?
9. What types of stimulus are the real-time systems designed for?
10. Explain the process management of real-time systems!
11 Project management
Software engineering projects are always subject to organizational budget and schedule constraints. Software project managers are the responsible person for planning and scheduling development project. They supervise the development work to ensure that it is carried out to the organizational standards and monitor the progress of the project. Project manager is also responsible for checking the development cost. Software engineering is differs from other engineering activities in a number of ways [1].
The manager of a civil engineering project can see how a product is being developed.
However, software is an intangible product. Software project managers can only see the progress of software development by documents produced to review the software process. In manufacturing the production processes are continuously tried and tested and finally they may be standardized. The engineering processes for many systems are well understood. However, there are no standard software processes and software processes are very different from one organization to another. Due to the rapid technological changes in computers and communications software projects are usually different in some ways from previous projects.
Experiences form previous projects usually may not be transferred to a new development project.
Because of these problems some software projects may late, over budget and behind schedule.