Lab Proposal for Integrated Real-time and Control - DCS - UPC

More documents

Recommendations

Info

6(a) Fast closed loop response(a) Setup(b) Overshoot closed loop response(b) Open loop responseFig. 7.RCRC responses.Fig. 6.Experiment setup and monitoring.execution time of 9 ms. The noisy task that goes together withthe overshoot controller has a period and relative deadline of110 ms with 90 ms of execution time. The simulation of eachmultitasking system was done in the TrueTime simulator [32].Putting together each control task with the corresponding noisytask under EDF results in timing variability (jitter) for thecontrol task, as illustrated for the first multitasking system inthe schedule of Figure 8a. In this figure, the bottom curverepresents the execution of the fast controller task, whereasthe top curve represents the execution of the noisy task. Ineach graph, the low-level line denotes no-execution (that is,intervals in which the processor is idle), the middle level linedenotes a task ready to execute (i.e., waiting in the readyqueue), whereas the high-level line denotes a task in execution.Note that the control task has a measured execution time of0.12 ms, which is much less than the noisy task.Looking at the plant responses in Figures 8 b) and c), it canbe appreciated that the fast controller does not exhibit a controlperformance degradation, while the overshoot controller sufferssome degradation: overshoots are bigger, square amplitudediffers, transient response varies, etc. This fact indicates thatthe current control design for the fast controller is robustagainst jitters induced by scheduling, while the second oneis more fragile.Observation 10: Adopting an iterative simulation study,students can learn which parameters play an important rolewhen jitters appear. Are shorter sampling periods, or nonovershoottedresponses, a guarantee for having robust controldesigns? Which role do deadlines play in reducing jitters? Forfurther questions and solutions, see [33] and references therein.K. Problem 11. Multitasking: implementation and monitoringdetailsThe new implementation requires specifying the noisy taskby modifying the kernel oil file in terms of defining thenew task and the associated alarm. Also, the new task hasto be coded: forcing an artificial execution time is achievedby placing a delay into the code. The main code has to bemodified to configure the new alarm associated to the newtask.After the implementation, in the first multitasking system,it can be verified that scheduling conflicts (as illustrated inthe simulated schedule shown in Figure 8a) may occur, asillustrated in Figure 9a. In this sub-figure, the execution ofthe fast controller task sets an output pin to 0 and 1 ateach job start and finishing time. And the noisy task setsan output pin to 0 and 0.5 at each job start and finishingtime. In addition, similar responses for the fast and overshootcontroller are obtained (see sub-figures 9 b) and c)), showingthat the overshoot controller suffers degradation from jitters,while the fast controller shows the same response as it isexecuted in isolation. To illustrative purposes, Figure 10ashows the overshoot controller response when executing inisolation (dark curve) and when executing in the multitaskingsystem (grey curve).Observation 11: Undergraduate students may work the experimentup to this problem. It shows the importance of
732.521.510.50 0.5 1 1.5(a) Partial schedule(a) Partial schedule3.532.521.510.500 0.5 1 1.5 2(b) Faster multitasking closed loop response(b) Faster multitasking response3.532.521.510.500 0.5 1 1.5 2(c) Overshoot multitasking closed loopresponseFig. 8.Simulated multitasking RCRC responses and schedule.(c) Overshoot multitasking responseconcurrency and resource sharing with respect to controlperformance in a multitasking embedded control system.L. Problem 12: Multitasking: design for eliminating or minimizingthe jitter problemRecent research literature has faced the problems introducedby jitter and many solutions have been proposed. Here, thesolution proposed by Lozoya et al. [31] has been adopted.The basic idea is to synchronize the operations within eachcontrol loop at the actuation instants. In this way, the timeelapsed between consecutive actuation instants, named t k−1and t k , is exactly equal to the sampling period, h. Within thistime interval, the system state is sampled, named x s,k , andthe sampling time recorded, t s,k ∈ (t k−1 ,t k ). The differencebetween this time and the next actuation timeτ k = t k −t s,k (4)is used to estimate the state at the actuation instant asˆx k = Φ(τ k )x s,k +Γ(τ k )u k−1 (5)Fig. 9.Implemented multitasking RCRC responses and schedule.where Φ(t) = e At and Γ(t) = ∫ t0 eAs dsB, being A and Bthe system and input matrices in (3), and u k−1 the previouscontrol signal. Then, making use of ˆx k , the control commandis computed using the original control gain K asu k = Kˆx k . (6)The control command u k is held until the next actuationinstant. A control strategy using (4)-(6) relies on the timereference given by the actuation instants, if u k is applied to theplant by hardware interrupts, for example. In addition, samplesare not required to be periodic because τ k in (4) can vary ateach closed-loop operation.After implementing this strategy on the overshoot controllerin the multitasking system, Figure10 b) shows the result.Specifically, it shows the overshoot controller response whenexecuting in isolation (dark curve) and when executing in themultitasking system using the algorithm that eliminates jitters(grey curve).
Page 1 and 2: 1Lab Proposal for Integrated Real-t
Page 3: 3and setting the scheduling policy)
Page 8 and 9: 8Fig. 10.(a) Overshoot controller w

Lab Proposal for Integrated Real-time and Control - DCS - UPC

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?