truetime simulation of control loops unde shared computer resources

1、TRUETIME: SIMULATION OF CONTROL LOOPS UNDER SHARED COMPUTER RESOURCESDan Henriksson, Anton Cervin, Karl-Erik ÅrzénDepartment of Automatic Control Lund Institute of Technology P .O. Box 118, SE-221 00 Lund, Swed

2、en {dan,anton,karlerik}@control.lth.seAbstract: The paper presents TRUETIME, a MATLAB/Simulink-based simulator for real-time control systems. TRUETIME makes it possible to simulate the temporal behavior of multi-tasking

3、real-time kernels containing controller tasks and to study the effects of CPU and network scheduling on control performance. The simulated real-time kernel is event-driven and can handle external interrupts as well as fi

4、ne-grained details such as context switches. Arbitrary scheduling policies may be defined, and the control tasks may be implemented using C functions, M functions, or Simulink block diagrams. A number of examples that il

5、lustrate the use of TRUETIME are presented. Copyright c ? 2002 IFACKeywords: Event-based simulation, Real-time control systems, Shared resources, Real- time kernel, Feedback scheduling.1. INTRODUCTIONMost computer contro

6、l systems are embedded systems where the computer is a component within a larger engineering system. The controllers are often imple- mented as one or several tasks on a microprocessor us- ing a real-time kernel or a rea

7、l-time operating system (RTOS). In most cases the microprocessor also con- tains other tasks for other functions, e.g., communi- cation and user interfaces. The kernel or OS typically uses multiprogramming to multiplex t

8、he execution of the different tasks on a single CPU. The CPU time and the communication bandwidth, hence, can be viewed as shared resources which the tasks compete for.Computer-based control theory normally assumes equid

9、istant sampling intervals and negligible or con- stant control delays, i.e., the latency between the sam- pling of the inputs to the controller and the generation of the outputs. However, this can seldom be achieved in p

10、ractice. Tasks interfere with each other through preemption and blocking due to communication. Ex- ecution times may be data-dependent or vary due to, e.g., the uses of caches. The result of this is jitter in sampling pe

11、riods and latencies. An additional cause of this temporal non-determinism is the increasing use of commercial off-the-shelf (COTS) components in control systems, e.g., general purpose operatingsystems such as Windows and

12、 Linux and general pur- pose network protocols such as Ethernet. These are designed to optimize average-case performance rather than worst-case performance, and therefore increase the non-determinism.The effects of this

13、type of temporal non-determinism on control performance are often very hard, if not impossible, to investigate analytically. A natural ap- proach is then to instead use simulation. However, to- days simulation tools make

14、 it difficult to simulate the true temporal behavior of control loops. What is nor- mally done is to introduce time delays in the control loop representing average-case or worst-case delays.In this paper the new simulati

15、on toolbox TRUETIME is presented. TRUETIME, which is based on MAT-LAB/Simulink, makes it possible to simulate the tem- poral behavior of a multi-tasking real-time kernel con- taining controller tasks. The controller task

16、s control processes modeled as ordinary Simulink blocks. Dif- ferent scheduling policies may be used, e.g., priority- driven or deadline-driven scheduling. The execution times of the controller tasks can be modeled as be

17、ing constant or time-varying, using some suitable proba- bilitydistribution.The effects of context switching and interrupt handling are taken into account, as well as task synchronization using events and monitors. WithC

18、opyright © 2002 IFAC15th Triennial World Congress, Barcelona, Spain1 2 3Simulated execution timeExecution of user codeFig. 2 The execution of the code associated with threads and interrupt handlers is modeled by a n

19、umber of code segments with different execution times. Execution of user code occurs at the beginning of each code segment.Threads Each thread is defined by a set of attributes most of which are initialized by the user w

20、hen the thread is created. These attributes include: a name, a release time, relative and absolute deadlines, an ex- ecution time budget, a period (if the thread is peri- odic), a priority (if fixed-priority scheduling i

21、s used), and the user code associated with the thread. Some of the attributes, such as the release time and the execu- tion time budget are constantly updated by the kernel during simulation. The other attributes can be

22、changed by function calls from the user code, but are otherwise kept constant.An arbitrary data structure may be defined and at- tached to each thread to represent the local mem- ory of the thread. Other threads may acce

23、ss this data, which can be used for system-level communication be- tween threads to support simulation of, e.g., feedback scheduling. It is further possible to associate three dif- ferent interrupt handlers with each thr

24、ead: a code ter- mination handler, a deadline overrun handler, and an execution time overrun handler.Interrupt handlers When an internal or external interrupt occurs the corresponding interrupt handler is activated and s

25、cheduled by the kernel. Similar to threads, interrupt handlers have a set of basic at- tributes: name, priority, and the associated user code. External interrupts also have a latency, during which they are insensitive to

26、 new invocations.Code The execution of the user code associated with threads and interrupt handlers is divided into segments with different simulated execution times as shown in Fig. 2. The execution times can be constan

27、t, random or data-dependent. Execution of user code occurs at the beginning of each code segment. The next segment is not executed until the time associated with the pre- vious segment has elapsed in the simulation. This

28、 con- struction makes it possible to model the timely aspects of the code that are relevant for the interaction with other tasks. This include, e.g., computations, input and output actions, awaiting events, and execution

29、 in criti- cal regions using monitors. After execution of the last segment the code termination handler of the thread is activated. For periodic threads this simply updates the release and deadline and puts the thread to

30、 sleep until next period. Execution will then again begin in the first segment.Table 1 Examples of kernel primitives (pseudo code) that can be called from threads and interrupt handlers.ttAnalogOut(ch,value) ttAnalogIn(c

31、h)ttWaitUntil(time) ttCurrentTime()ttSetPriority(prio) ttSetRelease(time)ttNwSendMsg(msg, node) ttNwGetMsg()ttEnterMonitor(mon) ttExitMonitor(mon)ttAwait(event) ttCause(event)2.2 The Network BlockThe network model is sim

32、ilar to the real-time kernel model, albeit simpler. The network block is event- driven and executes when messages enter or leave the network. A send queue is used to hold all mes- sages currently enqueued in the network

33、(c.f. the ready queue in the real-time kernel). A message contains in- formation about the sending and the receiving com- puter node, user data (typically measurement signals or control signals), transmission time, and o

34、ptional real-time attributes such as a priority or a deadline.A user-defined priority function is used to determine the order in which the enqueued messages should be transmitted. This way, it is easy to model different

35、network policies. When the simulated transmission of a message has completed, it is put in a buffer at the receiving computer node, which is notified by an external interrupt. Transmissions can be preemptive or non-preem

36、ptive, the latter being default.2.3 InitializationBefore the start of a simulation, the computer and network blocks must be initialized. This is done in a script for each block. Initializationinvolves specifying the numb

37、er 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, an

38、d returns the execution time of this segment. The kernel provides a set of real-time 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

39、function exectime = myController(seg) switch (seg), case 1, y = ttAnalogIn(1); u = calculateOutput(y); exectime = 0.002 % execution time case 2, ttAnalogOut(1,u); updateState(y); exectime = 0.003 % execution time case 3,