Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (811374), страница 64
Текст из файла (страница 64)
It is the most important interfacefrom the point of view of operation and of composability of the components. TheLIF has been discussed extensively in Sect. 4.6.9.1 Inter-Component Communication9.1.3217Technology Dependent Debug InterfaceIn the domain of VLSI design, it is common practice to provide a dedicatedinterface port for testing and debugging, known as the JTAG port that has beenstandardized in IEEE standard 1149.1.
Such a debugging port, the technologydependent debug interface (TDI), supports a detailed view inside a componentthat is needed by a component-designer to monitor and change the internal variables of a component that are not visible at any one of the other interfaces. Thecomponent-local OS should support such a testing and debugging interface.9.1.4Generic MiddlewareThe software structure within a component is depicted in Fig. 9.1.
Between the localhardware-specific real-time operating system and the application software is thegeneric middleware (GM). The execution control messages that arrive at the TII(e.g., start task, terminate task, or reset the component hardware and restart thecomponent with a relevant g-state) or are produced at the TII (e.g., periodicpublication of the g-state) are interpreted inside a component by the standardizedgeneric middleware (GM). The application software, written in a high-level language, accesses the operational message-based interfaces (the LIF and the localinterface) by API system calls.
The GM and the task-local operating system mustmanage the API system calls and the messages that arrive at the LIF and thecommands that arrive via the TII messages. While the task-local operating systemmay be specific to a given component hardware, the GM layer provides standardized services, processes the standardized system control messages, and implements higher-level protocols.Example: A high-level time-monitored request-reply protocol that is a unique concept atthe level of the API requires two or more independent messages at the BMTS level and a setof local timer and operating system calls for its implementation. The GM implements thishigh-level protocol. It keeps track of all relevant messages and coordinates the timeouts andoperating system calls.application softwareapplication programming interface (API)generic middleware (GM)LIFTIIlocal operating system(hardware specific)Fig.
9.1 Software structurewithin a componentlocal interfaceto process I/O2189.29 Real-Time Operating SystemsTask ManagementIn our model, the component software is assumed to be a unit of design, and a wholecomponent is the smallest unit of fault-containment. The concurrent tasks within acomponent are cooperative and not competitive. Since the whole component is aunit of failure, it is not justified to design and implement resource intensivemechanisms to protect the component-internal tasks from each other. The component-internal operating system is thus a lightweight operating system that managesthe task execution and the resource allocation inside a component.A task is the execution of a sequential program.
It starts with reading of input dataand of its internal state and terminates with the production of the results and updatedinternal state. A task that does not have an internal state at its point of invocationis called a stateless task; otherwise, it is called a statefull task. Task management isconcerned with the initialization, execution, monitoring, error handling, interaction,and termination of tasks.9.2.1Simple TasksIf there is no synchronization point within a task, we call it a simple task (S-task),i.e., whenever an S-task is started, it can continue until its termination point isreached, provided the CPU is allocated to the task. Because an S-task cannot beblocked within the body of the task by waiting for an event external to the S-task,the execution time of an S-task is not directly dependent on the progress of othertasks in the node and can be determined in isolation.
It is possible for the executiontime of an S-task to be extended by indirect interactions, such as the preemption ofthe task execution by a task with higher priority.Depending on the triggering signal for the activation of a task, we distinguishtime-triggered (T T) tasks and (E T) event-triggered tasks. A cycle (see Sect. 3.3.4)is assigned to every TT-task and the task execution is started whenever the globaltime reaches the start of a new cycle. Event-triggered tasks are started whenever astart-event for the task occurs.
A start event can be the completion of another task oran external event that is relayed to the operating system by an incoming message orby the interrupt mechanism.In an entirely time-triggered system, off-line scheduling tools establish thetemporal control structure of all tasks a priori. This temporal control structure isencoded in a Task-Descriptor List (TADL) that contains the cyclic schedule for allactivities of the node (Fig.
9.2). This schedule considers the required precedenceand mutual exclusion relationships among the tasks such that an explicit coordination of the tasks by the operating system at run time to guarantee mutual exclusionis not necessary.Whenever the time reaches an entry point of the TADL, the dispatcher isactivated. It performs the action that has been planned for this instant. If a task is9.2 Task ManagementFig. 9.2 Task descriptor list(TADL) in a TT operatingsystem219time1017223847action WCETstart T112send M5stop T1start T320send M3dispatcherstarted, the operating system informs the task of its activation time, which issynchronized within the cluster.
After task termination, the operating systemmakes the results of the task available to other tasks.The application program interface (API) of an S-task in a TT system consists ofthree data structures and two operating system calls. The data structures are theinput data structure, the output data structure, and the g-state data structure ofthe task (which is empty, in case the task is stateless). The system calls areTERMINATE TASK and ERROR.
The TERMINATE TASK system call is executed by the task whenever the task has reached its normal termination point. Inthe case of an error that cannot be handled within the application task, the taskterminates its operation with the ERROR system call.In an event-triggered system, the evolving application scenario determines thesequence of task executions dynamically. Whenever a significant event happens, atask is released to the ready state, and the dynamic task scheduler is invoked.
It is upto the scheduler to decide at run-time, which one of the ready tasks is selected forthe next service by the CPU. Different dynamic algorithms for solving the scheduling problem are discussed in the following chapter. The WCET (Worst-CaseExecution Time) of the scheduler contributes to the WCAO (Worst-Case Administrative Overhead) of the operating system.Significant events that cause the activation of an ET task can be:1. An event from the node’s environment, i.e., the arrival of a message or aninterrupt from the controlled object, or2.
A significant event inside the component, i.e., the termination of a task or someother condition within a currently executing task, or3. The progression of the clock to a specified instant. This instant can be specifiedeither statically or dynamically.An ET operating system that supports non-preemptive S-tasks will take a newscheduling decision after the currently running task has terminated.
This simplifiestask management for the operating system but severely restricts its responsiveness.If a significant event arrives immediately after the longest task has been scheduled,this event will not be considered until this longest task has completed.In an RT operating system that supports task preemption, each occurrence of asignificant event can potentially activate a new task and cause an immediate interruption of the currently executing task.
Depending on the outcome of the dynamicscheduling algorithm, the new task will be selected for execution or the interrupted2209 Real-Time Operating Systemstask will be continued. Data conflicts between concurrently executing S-tasks can beavoided if the operating system copies all input data required by this task from theglobal data area into a private data area of the task at the time of task invocation.If components are replicated, care must be taken that the preemption points at allreplicas is at the same statement, otherwise replica determinism may be lost.The API of an operating system that supports event-triggered S-tasks requiresmore system calls than an operating system that only supports time-triggered tasks.Along with the data structures and the already introduced system calls of a TTsystem, the operating system must provide system calls to ACTIVATE (makeready) a new task, either immediately or at some future point in time.
Anothersystem call is needed to DEACTIVATE an already activated task.9.2.2Trigger TasksIn a TT system, control always remains within the computer system. To recognizesignificant state changes outside the computer, a TT system must regularly monitorthe state of the environment. A trigger task is a time-triggered S-task that evaluatesa trigger condition on a set of temporally accurate state variables that reflect thecurrent state of the environment.
The result of a trigger task can be a control signalthat activates another application task. Since the states, either external or internal,are sampled at the frequency of the trigger task, only those states with a durationlonger than the sampling period of the trigger task are guaranteed to be observed.Short-lived states, e.g., the push of a button, must be stored in a memory element (e.g., in the interface) for a duration that is longer than the sampling period of thetrigger task. The periodic trigger task generates an administrative overhead in a TTsystem.
The period of the trigger task must be smaller than the laxity (i.e., thedifference between deadline and execution time) of an RT transaction that isactivated by an event in the environment. If the laxity of the RT transaction isvery small (<1 ms), the overhead associated with a trigger task can becomeintolerable and the implementation of an interrupt is needed.9.2.3Complex TasksA task is called a complex task (C-Task) if it contains a blocking synchronizationstatement (e.g., a semaphore wait operation) within the task body.
Such a waitoperation may be required because the task must wait until a condition outside thetask is satisfied, e.g., until another task has finished updating a common datastructure or until input from a terminal has arrived. If a common data structure isimplemented as a protected shared object, only one task may update the data at anyparticular moment (mutual exclusion). All other tasks must be delayed by the waitoperation until the currently active task finishes its critical section.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
