Patent Application
20050015767
There are many instances in computer operation where application programs need to exert real-time control. Examples include control systems for aircraft, factories, automobiles, printers, broker transaction computers, etc. A typical implementation would have a dedicated target computer controlling the aircraft, factory, etc., with target application programs on the target computer. The target computer could be uplinked via a TCP-IP ethernet link, serial linked, networked or otherwise connected to a host computer. The host computer could be a Unix®-based workstation or a Windows®-based PC, for example. The host computer can be used to download and configure application programs to run on the target computer, and to customize such application programs as well.
U.S. Pat. No. 5,872,909 entitled “Logic Analyzer for Software,” (“the '909 patent”), describes a system which logs events occurring in target application programs and provides a graphical representation that displays context status information in a time-line fashion. The graphical representation utilizes specific icons indicating events and status changes to show the interaction over time of tasks and interrupts being executed on the target computer in connection with the application programs. The system is useful for monitoring performance of application programs, in particular real-time, embedded or multi-tasking application programs running on a target computer. The WindView®g software analyzer product manufactured and distributed by Wind River Systems, Inc. is a commercially available product that has made use of this system with a host monitoring a separate target.
The system of the '909 patent logs events which occur during execution of application programs executing in the target computer, and stores these in a buffer for periodic uploading to the host system. Such events include context switching times of particular tasks, and task status at such context switch times, along with events triggering such a context switch or other events. The host system reconstructs the real-time status of the target application programs from the limited event data uploaded to it to create the graphical representation. The status information is then displayed in a user-friendly manner. This provides the ability to perform a logic analyzer function on software such as the application programs executing in the target computer, in real time (or as a post-mortem). A display having multiple rows, with one for each task or interrupt level, is provided. Along a time line or an axis representing a sequence of events, an indicator shows the status of each task/interrupt with icons indicating events and any change in status. The task-status may be indicated with different line patterns or stipples, for example, a wavy line indicating that a program is ready to run, a dotted line indicating that a program is waiting for a semaphore or a message from a message queue that it needs to run, and a dashed line indicating the program is waiting for a time-out. This detailed graphical interface provides an easily understood overall representation of the status of a target software.
“Real-time operating systems,” have been developed to provide a more controlled environment for the execution of application programs in an embedded system such as a dedicated target computer. Real-time operating systems are designed to be “deterministic” in their behavior—i.e., responses to events can be expected to occur within a known time of the occurrence of the event, without fail. Determinism is particularly necessary in “mission-critical” and “safety-critical” applications, where the outcome of event responses is essential to proper system function. Real-time operating systems are therefore implemented to execute as efficiently as possible with a minimum of overhead.
Real time operating systems include the time deadline based operating system disclosed in the co-pending application referred to above. In the time deadline based operating system, a plurality of processes are each started based on a timer, with each process starting execution according to a start time specified in a time table. If one of the processes starts execution while another previously started process is executing, the process already executing is preempted. Moreover, based on a timer, an executing processes is stopped regardless of whether the process has stopped execution normally, each process stopping execution according to a deadline specified in the time table.
It is very important in real time systems that tasks are executed when expected, especially in an operating system, such as disclosed in the co-pending application, where tasks are executed in a specific order, regardless of task completion or priority. To configure such an operating system, post-mortem analysis would repeatedly be necessary as different start time and deadline schemes are attempted on a trial and error basis. Then, for example, during operation of the system, the results of the operation can be checked, and the various start times and deadlines can be changed to improve the functioning of the computing environment. In an example of the time deadline operating system of the co-pending application, the time table is stored in a read/write storage device (e.g., RAM) of the target computer. In this manner, the table can be accessed and modified. The time table would then have to be manually updated with each trial run until the optimal configuration is found.
According to one exemplary embodiment of the present invention, a method for configuring an operating system is provided. The method includes the step of creating a task schedule on a host, the schedule comprising tasks, task start times, and task deadlines. The task schedule is used to configure a time deadline based operating system on a target computer according to the task schedule. The target operating system is run, while simultaneously capturing event data. The event data is converted into a corresponding graphical representation indicative of the occurrence of significant events on the target, the significant events corresponding to the task start times and the deadlines. The method includes the further step of changing the task start times and task deadlines in response to user interaction with reference to the graphical representation, the changes corresponding to specific significant events; and using the changes to adjust and recreate the task schedule.
According to another exemplary embodiment of the present invention, a computer system is provided. The computer system comprises a host computer and a target computer coupled to the host computer. A time deadline based operating system is configured on the target computer, and the target computer is operated to execute the time deadline based operating system, while capturing event data and uploading the event data to the host computer via the coupling. The host computer operates to convert the event data into a corresponding graphical representation and the host computer further operates to reconfigure the time deadline based operating system via the coupling with the target computer, in response to user interaction with reference to the graphical representation.
In accordance with one embodiment of the present invention, an operating system configuration tool is provided using a software logic analyzer, for example the WindView® software logic analyzer product manufactured and distributed by Wind River Systems, Inc., to graphically configure a time triggered operating system by using the logic analyzer to calibrate time-triggered tasks to develop a time schedule for the tasks.
A task schedule is created on a host computer by entering values into a table or by drawing a time graph. A corresponding configuration table is generated in an operating system configuration language or programming language, the operating system is configured, and the resulting configuration downloaded to a target computer and run. As the target runs, its running task schedule is captured and compared with the created task schedule. Any changes necessary to accommodate worst case execution times (WCET) can be made and the resulting, updated configuration table downloaded to the target creating a feed-back loop from the system to the user.
Link 14 is preferably an ethernet link, using TCP-IP protocol. Alternately, link 14 can be a connection over an in-circuit or ROM emulator, a serial line or any other point-to-point communication means known. Host 16 is typically a workstation running a Unix® or Unix® based operating system, or a PC running Windows operating system.
The significant events 22 which are logged include switching from one task 28 to another, a change in the state of a task, or certain events which the user desires to display on a debug display. When logged, the events are time-stamped. Target computer 12 could be a separate traditional stand-alone computer, or could be an embedded computer board that is designed to be plugged into a car, printer, etc.
In addition to the target-and-host structure set forth above, aspects of the present invention are useful where a single computer runs both the target and host software. An example is a multi-tasking environment running on a workstation with significant power and memory. The uploading bandwidth is not a constraint in this environment, but the lack of intrusiveness and the ability to provide the status and event display are very useful.
The first, second, and third time points 250, 260, 270 are determined at design time and are stored in the time table. The first, second, and third expiration times or deadlines 281, 283, 286 are also determined at design time and are stored in the time table. In one example, the expiration times 281, 283, 286 could be scheduled at 10 ms, 20 ms, and 30 ms, respectively.
In certain embodiments according to the present invention, more than one timer can be used. For example, a separate timer could be used for each start time and each expiration time (deadline). Also, in a certain embodiment of the present invention, a timer can be set for the first point in time 250 before the first task 200 starts execution. Then, when the timer expires, the first task 200 begins execution.
The tasks and ISRs can also be assigned priority levels. The priority levels specify which process (e.g., a task or ISR) can preempt another process. Preferably, in this example of the present invention, all the tasks are assigned the same priority level, so that one task can not synchronously preempt another task. However, the interrupts can have different priority levels. For example, the highest priority level interrupt could be a timer ISR. Thus, when the timer expires, the timer ISR can interrupt a currently executing task or ISR and perform an action (e.g., push the currently executing task to a stack, and start execution of a next scheduled task, according to the time table). Other interrupts could have different levels.
Table 1 shows priority levels assigned to the tasks 322, 324, 326 and ISRs 332, 334 shown in
In Table 1 note that the highest priority level is indicated by the numeral 1, and the lowest priority level is indicated by the numeral 4. The Timer ISR has the highest priority level, thus it always has priority over any other ISRs or tasks. Also note that the Idle task has the lowest priority level, thus, any of the other tasks or ISRs can preempt the Idle task.
In the example given in
If the first ISR 332 occurs while any of the tasks are executing, the tasks are interrupted by the ISR 332 and could be placed in the preempted state. This is because the first ISR 332 has a higher priority level (e.g., 2) than the tasks (e.g., 4). When the first ISR 332 finishes execution, the previously executing task is popped from the stack and resumes execution (e.g., placed back in the running state). Note that if the deadline 340 for the task has passed due to the execution time of the first ISR 332, execution of the task is ended by the operating system.
In certain embodiments of the present invention, after the ISR finishes execution, a check could be made to determine if the deadline for a particular task has passed before resuming execution of the task. In such an embodiment, execution of the task could be stopped before resuming the task (e.g., the task is directly placed into the terminated state). After the first ISR 332 has executed, a semaphore or similar programing construct is set to prevent the first ISR 332 from executing until the interrupt enable time (e.g., time interval) listed in the third column occurs. When the interrupt enable time occurs (e.g., the timer reaches the specified time interval) the programing construct can be reset. For example, if the first ISR 332 executes at 2 ms, the first ISR 332 is prevented from executing again until the timer reaches 4 ms.
In the example given in
However, if first ISR 332 is still executing at 15 ms (the start time for the third task 326), the timer ISR (which has the highest priority) interrupts the first ISR 332 to place the third task 326 on the stack (e.g., in the preempted state), the first ISR 332 then resumes execution. When the first ISR 332 finishes, the third task 326 is placed in the running state (e.g., popped from the stack). If the third task 326 finishes before 20 ms, the second task 324 is placed in the running state.
In certain embodiments according to the present invention, a task can be placed into different states. This is shown in
State changes, which can be sent by, e.g., the scheduling process of a timer ISR, or caused by expiration of the timer(s), can cause states to change from the running state 500, preempted state 510, or suspended state 520 to one of the other states. For example, an activate change 505 moves a task from the suspended state 520 to the running state 500. A resume 515 change moves a task from the preempted state 510 to the running state 500. Preferably, the last task to enter the preempted state 510 is the task that is moved to the running state 500. A preempt change 525 moves the task in the running state 500 to a preempted state 510. The preempt change could occur, for example, if another task start time occurs or an ISR preempts the current process. A terminate change 535 moves a task from the running state 500 to the suspended state 520.
In certain embodiments according to the present invention, when the timer expires, a scheduler, such as a timer ISR, could move the tasks from one state to another. For example, an activate change could be issued when a task is scheduled to start. A resume change could be issued when a task that has been preempted by the scheduler or by an ISR with a higher priority level, is moved back to the running state. A preempt change could be issued when the scheduler starts execution of a new task or when an ISR of a higher priority is activated. A terminate change could be issued when a task has completed execution. In certain embodiments according to the present invention, the task could issue the change instead of the scheduler. The scheduler can then place the task in the appropriate state. For example, on completion a task could issue a terminate command to the scheduler. Also, in certain embodiments of the present invention, the task could place itself in a particular state. For example, the timer could be implemented as a semaphore for each task. When the semaphore associated with the task reaches a deadline time, the task could terminate itself. In certain embodiments according to the present invention, a semaphore associated with each task could issue commands to change states. For example, the semaphore could place a task in a state and issue a message to the scheduler.
As noted above, with the time triggered approach utilized in the present invention, a complete task and ISR (Interrupt Service Request) time table is determined when the operating system is designed. The time table is stored in the target computer 12. Based on the operating system design, each task is started at a preselected, definite start time. Likewise, tasks stop executing at a particular time (e.g., a deadline time) although the tasks may stop before the deadline time if execution is completed. With regard to ISRs, an enable time is used to prevent an ISR from executing more than once until a known amount of time has elapsed. For example, the operating system can disable the ISR once it executes, and then enable the ISR once again when the specified enable time has elapsed (e.g., by use of a binary semaphore). Examples of time tables are shown in
To configure the Operating system, a set of tasks and the time it takes to complete each task are determined from the timing characteristics (offsets, worst case execution times, and deadlines) of each task, in the order they should occur in the operation of a particular system. Tasks can be scheduled at the microsecond, rather than millisecond level. From the timing characteristics, a user creates a table that serves as the task schedule, like that in Table 2. The dispatcher of the operating system activates the tasks in a strict sequential order in accordance with the table. All tasks should be completed by the end of the dispatcher round. To start the round, a global time impulse may be used to indicate the beginning of the time table.
The first column of Table 2 lists the tasks and their corresponding activate and deadline check ISRs in sequential order of execution. The second column lists the start times for each task ISR. If a particular task has not finished execution at the time a subsequent task is scheduled to start, the task is placed in a preempted state (e.g., pushed to a stack) and the subsequent task begins execution. The third column contains deadlines for Task 1, Task 2 and Task 3 which specify the maximum amount of time a task can execute before an error is issued. Assuming it is known that an ISR takes 2 ms to execute, each task can be set to run for its allotted time minus an amount of time sufficient for a corresponding ISR to execute, in this example, minus 2 ms.
The first, second, and third tasks can, by way of example, have start times of 0 ms, 15 ms, and 30 ms, respectively, and corresponding deadlines of 20 ms, 35 ms, and 50 ms, respectively. From 0 to 13 ms, Task 1 will run. At 13 ms, an activate ISR is executed to place Task 1 in a preempted state (in the event Task 1 is still executing), and activate Task 2. Because the activate ISR takes 2 ms to complete, Task 2 will start at 15 ms, the scheduled start time for Task 2.
At 20 ms, the scheduled deadline for Task 1, a Deadline check ISR for Task 1 is activated to determine whether Task 1 has completed execution. If Task 1 is still executing, there is a deadline violation, and appropriate action, for example, the sending of an error message, is taken by the Deadline check ISR. At 28 ms, an Activate Task 3 ISR is executed, so that it can activate Task 3 by the 30 ms start time for Task 3. As shown in Table 2, Deadline check ISR's are executed at each of 35 ms and 50 ms, respectively to determine whether each of Task 2 and task 3 completed execution before their respective scheduled deadlines.
Table 2 may serve as the basis for generating the configuration table for the target operating system. It should be noted that to simplify configuration, ISR times may be calculated automatically and integrated into the task execution time as part of running the task, as in the above described examples relevant to
Preferably, after the configuration table is created, it is stored on the target in a read/write storage device (e.g., RAM). In certain embodiments of the present invention, two or more tables could be used, for example, an executing table and a idle table. Data can be written to the idle table, and then at the end of a dispatcher round (execution of each task at its specified start time), a pointer could be moved to the currently idle table, thereby, making it the executing table.
The target is run according to the configuration task schedule via the dispatcher activating tasks in strict sequential order according to the schedule. Event information is stored in the log buffer each time an event occurs to capture the running task schedule. Hooks into the target operating system kernel allow instrumentation of the target operating system operation. A hook is a location in the kernel that calls out of the kernel to a kernel module routine—a hook exit routine. So when a significant event occurs on the target, a kernel hook allows the target operating system to break away from the current instruction stream of the task, ISR or idle loop, copy data describing the event into the buffer and then return to running the task, ISR or idle loop it broke away from, as described in the '909 patent.
Significant events are those that cause a change in state of any task, and deadline violations, if any. In addition, the states of each task at the end of the dispatcher round are logged as well. Since all tasks should be completed by the end of a dispatcher round, no task should be in a preempted state.
After a dispatcher round finishes, the logs are uploaded to the host where the information is converted into a graphical display using the time stamp associated with each logged event. A graph is generated with a vertical line for each task and a separate vertical line to represent the progression of time. The state of each task at each periodic time unit during the dispatcher round is plotted on a graph with a specific line pattern indicating the task state at the corresponding time on the graph.
A corresponding table may be generated as well. Table 3 shows the corresponding task schedule for the graph of
If there is no deadline violation detected, the operating system is configured properly, but may be tweaked for optimal performance according to the user. Changes can be made directly to the display of
Times between tasks and interrupts may be calculated and used to determine whether the time between tasks (or between tasks and interrupts) exceeds a certain threshold. Run times for tasks and interrupts may be calculated as well with their average, median, max, and min times in a given sampling number (e.g. 100 occurences).
If a deadline violation does occur while the target is running, the system's reaction depends on how it is defined by the user. The operating system may record the violation event in the log, return to the instruction following the violation, and complete the dispatcher round. This may be designed to occur automatically or at the direction of a user command to do so. Alternatively, the dispatcher cycle may be terminated upon violation detection and the log uploaded to the host with notification of the violation. In any event, upon the occurrence of a deadline violation, a hook would be used to take the kernel away from executing the violating task and to record the event in the log.
For ease of illustration, the example of
The overall process from the host side is shown in the flowchart of
If, during the dispatcher round, a deadline violation does occur (step 918), the event is logged (step 922) and, assuming the system is configured as discussed earlier in reference to
In the preceding specification, the invention has been described with reference to specific exemplary embodiments and examples thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative manner rather than a restrictive sense.
This application is related to U.S. Pat. No. 5,872,909 entitled “Logic Analyzer for Software,” the entire disclosure of which is hereby expressly incorporated by reference and co-pending U.S. application Ser. No. ______ [DDK ATTORNEY DOCKET NO. 218.1042], entitled TIME DEADLINE BASED OPERATING SYSTEM, filed on even date herewith, and the entire disclosure of which is hereby expressly incorporated by reference.
