【文章內(nèi)容簡介】 ive, the latter being default. Initialization Before the start of a simulation, the puter and work blocks must be initialized. This is done in a script for each block. Initialization involves specifying the number of input and output ports, choosing priority functions, defining code functions, creating threads, interrupt handlers, etc. Writing a code function A code function takes as input argument the segment to be executed, and returns the execution time of this segment. The kernel provides a set of realtime primitives that can be called from the user code, see Table 1 for some examples. A code function for a simple controller is given below function exectime = myController(seg) switch (seg), case 1, y = ttAnalogIn(1)。 u = calculateOutput(y)。 exectime = % execution time case 2, ttAnalogOut(1,u)。 updateState(y)。 exectime = % execution time case 3, exectime = 1。 % code termination end The inputoutput latency in the example above is always at least 2 ms, this being the execution time of the first segment. However, preemption from higherpriority threads or interrupts may lead to a longer delay. Figure 3 Controllers represented using ordinary discrete Simulink blocks may be used directly in TRUETIME to evaluate timing performance. The example above shows a PIcontroller. Graphical controller representation As an alternative to textual implementation of the controller algorithms, TRUETIME also allows for graphical representations using discrete Simulink blocks. Block systems are called from the code function using the primitive ttCallBlockSystem. A block diagram of a PIcontroller is shown in Fig 3, and the corresponding use in a code function is given below function exectime = piController(seg) switch (seg), case 1, in(1) = ttAnalogIn(1)。 in(2) = ttAnalogIn(2)。 out = ttCallBlockSystem(in,39。PI_ctrl39。)。 exectime = out(2)。 case 2, ttAnalogOut(1,out(1))。 exectime = 。 case 3, exectime = 1。 % code termination end 3. Scheduling during overload conditions This example treats scheduling of tasks with long, but rare, worstcase execution times. In these cases traditional scheduling analysis, based on worstcase execution times, bees very restrictive. An alternative approach, called the Constant Bandwidth Server (CBS) was presented in [Abeni and Buttazzo, 1998]. This server approach is straightforward to simulate using TRUETIME. Figure 4 Comparison of schedules generated by CBS and EDF during an overrun for the interfering thread. Using CBS the controller thread is unaffected by the overrun. In the CBS scheme each task is handled by a dedicated server characterized by a budget, cs, a maximum budget, Qs, and a period, Ts. Each server also has a dynamically changing deadline. When the task associated with a server executes longer than its assigned budget, the budget is recharged and a new deadline is generated. The CBS scheme uses deadlinedriven scheduling based on the server deadlines. The generation of a new deadline may therefore allow other tasks to run. CBS guarantees that no task consumes more than the bandwidth assigned to its server, Us = Qs/Ts, ., if a task has an overrun it will not affect other tasks. Hence, CBS conceptually divides the CPU into virtual subCPU’s. The CBS scheme is simulated in TRUETIME using the execution time budget and execution time overrun handlers associated with threads. When a thread executes longer than its assigned budget an interrupt is generated. The corresponding interrupt handler then recharges the budget and updates the server deadline. As an example, consider stabilizing control of an inverted pendulum with the statespace realization 0 1 0 01 0 1 1x x u w? ? ? ? ? ?? ? ?? ? ? ? ? ?? ? ? ? ? ? (1) ? ?10y x v??1Q 2Q where w and v are independent zeromean white noise processes with variances 1 and respectively. A LQGcontroller with sampling period 100 ms is designed in order to minimize the quadratic cost function 120( ) ( ) ( ) ( ) ( )t TJ t x s Q x s u s Q u s d s??? (2) with Q1 = 5I and Q2 = 0 01. The execution time of the controller thread is 20 ms and it is scheduled together with an interfering thread with period 400 ms and a nominal execution time of 100 ms. We further assume that the interfering thread occasionally has a very long execution time of 700 ms occurring with a probability of 5 percent. In a first simulation the tasks are scheduled using ordinary earliest deadline first scheduling (EDF). Here the task with the shortest remaining time to its deadline will run, with the relative deadlines being equal to the task periods. The effect of an overrun is shown in the lower part of Fig. 4, where it is seen that the controller thread misses five samples due to preemption from the interfering thread. Using the CBS approach we get the desired behavior as seen in the upper part of Fig. 4. The controller thread is unaffected by the overrun of the interfering thread. The loss as measured by the cost function (2) during a simulation of 100 seconds was reduced by 50 percent using the CBS approach. 4. A Networked Control System This example describes simulation of a distributed control system, where a DC servo is to be controlled over a work. The system is shown in Fig. 5 and consists of four nodes. The timedriven sensor node samples the process periodically and sends the samples to the controller node over the work. Upon receiving a sample, the controller putes a control signal which is sent to the actuator node, where it is subsequently actuated. The threads executing in the controller and actuator nodes are both eventdriven. There is also a disturbance node generating random interfering traffic over the work. The work is assumed to be of CANtype, . transmission