Embedded Systems Design Aspects:
For successful design of an Embedded Systems, the system requirements have to be expressed and documented in a very clear way. We used to document it on an MS Excel Sheet or MS Word, etc., Once the system requirements have been clearly defined and well documented, the first step in the design process is to design the overall system architecture.
Architecture of a system basically represents an overview of the system components (i.e. sub-systems) and the interrelationships between these different components. Once the software architecture is identified, the process of implementing that architecture should take place. This can be achieved using a lower-level system representation such as an operating system or a scheduler. Scheduler is a very simple operating system for an embedded application. Building the scheduler would require a scheduling algorithm which simply provides the set of rules that determine the order in which the tasks will be executed by the scheduler during the system operating time. It is therefore the most important factor which influences predictability in the system, as it is responsible for satisfying timing and resource requirements. However, the actual implementation of the scheduling algorithm on the embedded microcontroller has an important role in determining the functional and temporal behavior of the embedded system.
Hardware/Software architectures of embedded systems:
Embedded systems are composed of hardware and software components. The success of an embedded design, thus, depends on the right selection of the hardware platform(s) as well as the software environment used in conjunction with the hardware. The selection of hardware and software architectures of an application must take place at early stages in the development process (typically at the design phase). Hardware architecture relates mainly to the type of the processor (or microcontroller) platform(s) used and the structure of the various hardware components that are comprised in the system.
Provided that the hardware architecture is decided, an embedded application requires an appropriate form of software architecture to be implemented. To determine the most appropriate choice for software architecture in a particular system, this condition must be fulfilled : “The [software] architecture must be capable of providing a provable prediction of the ability of the application design to meet all of its time constraints.” Since embedded systems are usually implemented as collections of real-time tasks, the various possible system architectures may then be determined by the characteristics of these tasks. In general, there are two main software architectures which are typically used in the design of embedded systems:
Event-triggered (ET): tasks are invoked as a response to aperiodic events. In this case, the system takes no account of time: instead, the system is controlled purely by the response to external events, typically represented by interrupts which can arrive at anytime. Generally, ET solution is recommended for applications in which sporadic data messages (with unknown request times) are exchanged in the system.
Time-triggered (TT): tasks are invoked periodically at specific time intervals which are known in advance. The system is usually driven by a global clock which is linked to a hardware timer that overflows at specific time instants to generate periodic interrupts . In distributed systems, where multi-processor hardware architecture is used, the global clock is distributed across the network (via the communication medium) to synchronize the local time base of all processors. In such architectures, time-triggering mechanism is based on time-division multiple access (TDMA) in which each processor-node is allocated a periodic time slot to broadcast its periodic messages. TT solution can suit many control applications where the data messages exchanged in the system are periodic.
Many researchers argue that ET architectures are highly flexible and can provide high resource efficiency. However, ET architectures allow several interrupts to arrive at the same time, where these interrupts might indicate (for example) that two different faults have been detected at the same time. Inevitably, dealing with an occurrence of several events at the same time will increase the system complexity and reduce the ability to predict the behavior of the ET system. In more severe circumstances, the system may fail completely if it is heavily loaded with events that occur at once. In contrast, using TT architectures helps to ensure that only a single event is handled at a time and therefore the behavior of the system can be highly-predictable.
Since highly-predictable system behavior is an important design requirement for many embedded systems, TT software architectures have become the subject of considerable attention. In particular, it has been widely accepted that TT architectures are a good match for many safety-critical applications, since they can help to improve the overall safety and reliability.
Schedulers and scheduling algorithms :
Most embedded systems involve several tasks that share the system resources and communicate with one another and/or the environment in which they operate. For many projects, a key challenge is to work out how to schedule tasks so that they can meet their timing constraints. This process requires an appropriate form of scheduler. A scheduler can be viewed as a very simple operating system which calls tasks periodically (or aperiodically) during the system operating time. According to the nature of the operating tasks, any real-time scheduler must fall under one of the following types of scheduling policies:
Pre-emptive scheduling: where a multi-tasking process is allowed. In other words, a task with higher priority is allowed to pre-empt (i.e. interrupt) any lower priority task that is currently running. The lower priority task will resume once the higher priority task finishes executing.
……A — B — A…….C….D….
Pre-emptive scheduling of Task A and Task B in the system shown in Fig above. Task B, here, is assigned a higher priority .
Co-operative (or “non-pre-emptive”) scheduling: where only a single-tasking process is allowed. In other words, if a higher priority task is ready to run while a lower priority task is running, the former task cannot be released until the latter one completes its execution.
….A…………B……C…..D…..
Co-operative scheduling of Task A and Task B in the system shown in Fig above.
Hybrid scheduling: where a limited, but efficient, multi-tasking capabilities are provided. That is, only one task in the whole system is set to be pre-emptive (this task is best viewed as “highest-priority” task), while other tasks are running co-operatively.
………..A — B — A…….C — B — C……..D……
Hybrid scheduling of four-tasks(Fig above): Task B is set to be pre-emptive, where Task A, Task C and Task D run co-operatively.
It is important to understand that sometimes pre-emptive schedulers are more widely used in RTOSs due to commercial reasons. For example, companies may have commercial benefits from using pre-emptive environments. Consequently, as the complexity of these environments increases, the code size will significantly increase making ‘in-house’ constructions of such environments too complicated. Such complexity factors lead to the sale of commercial RTOS products at high prices. Therefore, further academic research has been conducted in this area to explore alternative solutions. For example, over the last few years, the Embedded Systems Laboratory (ESL) researchers have considered various ways in which simple, highly-predictable, non-pre-emptive (co-operative) schedulers can be implemented in low-cost embedded systems.
Scheduling algorithm and scheduler implementation :
A key component of the scheduler is the scheduling algorithm which basically determines the order in which the tasks will be executed by the scheduler. More specifically, a scheduling algorithm is the set of rules that, at every instant while the system is running, determines which task must be allocated the resources to execute.
Developers of embedded systems have proposed various scheduling algorithms that can be used to handle tasks in real-time applications. The selection of appropriate scheduling algorithm for a set of tasks is based upon the capability of the algorithm to satisfy all timing constraints of the tasks: where these constraints are derived from the application requirements. Examples of common scheduling algorithms are: Cyclic Executive, Rate Monotonic, Earliest-Deadline-First, Least-Laxity-First, Deadline Monotonic and Shared-Clock schedulers. A possible implementation of a scheduler is given below:
int main(void){…
while(1){
Task_A(); Delay_6ms();
Task_B(); Delay_6ms();
Task_C(); Delay_6ms(); }
return 1; //Shall never reach here}
In this section, the discussion is focused mainly on the relationship between scheduling algorithm and scheduler implementations and highlighted the challenges faced when implementing software for a particular scheduler. It was clearly noted that such challenges were mainly caused by the broad range of possible implementation options a scheduler can have in practice, and the impact of such implementations on the overall Embedded System behavior. Again, I’d like to thank all the authors of the various Embedded Systems Books, Articles, Whitepapers for helping me to publish this Blog(Embedded Systems Design — Part 2). I shall cover more about it in the next Part…So stay tuned…
