From ee12625f54f2eee28aeaffa5948c73dce545fafb Mon Sep 17 00:00:00 2001 From: PaoloPazzaglia <paolopazzaglia.pp@gmail.com> Date: Thu, 25 Apr 2019 21:33:33 +0200 Subject: [PATCH] Changes chapter 3 and 4 --- artifact/src/matlab/ctl_eval.m | 11 ++--- paper/main.tex | 18 ++++---- paper/sec/behavior.tex | 10 ++--- paper/sec/method.tex | 11 +++-- paper/sec/model.tex | 78 +++++++++++++++++++++------------- 5 files changed, 73 insertions(+), 55 deletions(-) diff --git a/artifact/src/matlab/ctl_eval.m b/artifact/src/matlab/ctl_eval.m index febd067..f7ff983 100644 --- a/artifact/src/matlab/ctl_eval.m +++ b/artifact/src/matlab/ctl_eval.m @@ -64,7 +64,7 @@ for j = 1:3 delayvec(delayvec == 1000) = NaN; % remove last value (spurious zero) delayvec = delayvec(1:end-1); - + delayvec_appo = delayvec; % if queue(1) mode, replace first element of sequence % 2-1 3-NaN-1 4-NaN-NaN-1... with NaN for p = 1: (size(delayvec,2) - 1) @@ -99,7 +99,7 @@ for j = 1:3 % Read period from file name h = str2num(regexp(filename,'(?<=t)\d+(?=.)','once','match'))/hmin; - + fprintf('Period %f\n',h); %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % robust controller holdvals = unique(holdvec); @@ -120,11 +120,6 @@ for j = 1:3 predmat = [taucounts/sum(taucounts) tauvals]; CtrlRobust = robust_lqctrl(A,B,Qc,h,holdmat,predmat); - %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - % classic control - holdmat = [1 1]; - predmat = [1 0 1]; - CtrlClassic = robust_lqctrl(A,B,Qc,h,holdmat,predmat); %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % read all sequences from csv file @@ -225,6 +220,8 @@ for j = 1:3 JRob_min(j,i) = min(JRob_m,max_val); JClass_list(j,i) = min(JClasstot,max_val)/(size(alldelays,1)/dec_seq); + fprintf('Finished iteration %i\n',i); + end end diff --git a/paper/main.tex b/paper/main.tex index 72c892c..9d850a7 100755 --- a/paper/main.tex +++ b/paper/main.tex @@ -1,4 +1,4 @@ -\documentclass[a4paper, USenglish,numberwithinsect]{lipics-v2019} +\documentclass[a4paper, USenglish, numberwithinsect]{lipics-v2019} \usepackage{microtype} \usepackage{listings} @@ -27,6 +27,8 @@ \bibliographystyle{plainurl} +\nolinenumbers + \newcommand{\our}{DMAC} \title{\our: Deadline-Miss-Aware Control}% Design} \titlerunning{\our: Deadline-Miss-Aware Control} @@ -90,8 +92,8 @@ % --------------------------------------- BASIC COMMANDS (start) \newcommand{\mm}[1]{\textcolor{black!40!yellow} {$\blacktriangleright$\textbf{MM:} #1$\blacktriangleleft$}} -\newcommand{\pp}[1]{\textcolor{red} - {$\blacktriangleright$\textbf{PP:} #1$\blacktriangleleft$}} +\newcommand{\pp}[1]{\textcolor{red} {#1}} + %{$\blacktriangleright$\textbf{PP:} #1$\blacktriangleleft$}} \newcommand{\cm}[1]{\textcolor{blue} {$\blacktriangleright$\textbf{CM:} #1$\blacktriangleleft$}} \newcommand{\ac}[1]{\textcolor{black!80!green} @@ -118,8 +120,8 @@ taking into account the possibility of missing deadlines. The design leverages information about the probability that specific sub-sequences of deadline misses are experienced. The result is a - \emph{fixed} controller, that on average works as the ideal - clairvoyant time-varying controller that possesses knowledge of + \emph{fixed} controller that on average works as the ideal + clairvoyant time-varying controller that knows future deadline hits and misses. We obtain a safe estimate of the hit and miss events using the \emph{scenario theory}, that allows us to provide probabilistic guarantees. @@ -130,9 +132,9 @@ skipping the next activation, and letting the job continue using a limited queue of jobs. % - Our experimental results show that our design proposal---i.e., - that exploring the space where deadline can be missed and handled - with different strategies---greatly outperforms classical control + Experimental results show that our design proposal -- i.e., + exploring the space where deadlines can be missed and handled + with different strategies -- greatly outperforms classical control design techniques. \end{abstract} diff --git a/paper/sec/behavior.tex b/paper/sec/behavior.tex index 3f2c2aa..03cc722 100644 --- a/paper/sec/behavior.tex +++ b/paper/sec/behavior.tex @@ -16,19 +16,19 @@ strongly on the deadline miss handling strategy, and may become unacceptable when the probability of missing a deadline is too high. Here we analyze the timing properties of a control task subject to deadline misses. We show that only two parameters are needed to fully -characterize the miss impact, We build the rules for computing +characterize the miss impact. We build the rules for computing them and extract the sequence of valid control jobs. \subsection{Defining Delay and Hold} \label{sec:behavior:notation} -Missed deadlines invalidates one of the basic hypothesis of control +Missed deadlines invalidate one of the basic hypothesis of control theory, which is the periodicity of the output pattern~\cite{pazzaglia2018beyond}. In this work, we exploit the knowledge of deadline misses directly in the control design step. For this purpose, we need to characterize the effect of deadline misses on the control -performance. It is possible to fully describe the effect of deadline +performance. We fully describe the effect of deadline misses of LET-based controllers with two parameters, named respectively \emph{delay} and \emph{hold} interval. @@ -148,12 +148,12 @@ controller synthesis in Section~\ref{sec:design}. Knowing $\sigma_k$ and $h_k$ for a given job $J_{d,k}$, it is also possible to determine whether -the $k$-th control job is \emph{valid}. In fact, this corollary +the $k$-th control job is \emph{valid}. This corollary follows from the definition of delay and hold interval: \begin{corollary} \label{cor:valid} A job $J_{d,k}$ is \emph{valid} if and only if it is possible to - define both its delay $\sigma_k$ and hold interval $h_k$ and if the + define both its delay $\sigma_k$ and hold interval $h_k$ (i.e., they are finite numbers) and if the hold interval is greater than zero. \end{corollary} diff --git a/paper/sec/method.tex b/paper/sec/method.tex index 7e8f755..818624e 100755 --- a/paper/sec/method.tex +++ b/paper/sec/method.tex @@ -161,7 +161,6 @@ execute in order for the probability that unforeseen circumstances are worse than the gathered data to be lower or equal to $\varepsilon$ with confidence $1-\beta$. We denote the number produced by the scenario theory with $n_\text{sim}$. - For each of the $n_\text{sim}$ experiments, we randomly sample the probability distributions of the task execution times, to generate a set $\Omega = \{ \omega_1, \dots, \omega_{n_{\text{sim}}} \}$ @@ -186,12 +185,12 @@ control period, based on the specific control task and the additional computational load on our platform. As output of our approach we obtain $y$, the evaluation of each tested -strategy $\xi$ for the specific problem. However, as a by-product of -the approach, we also obtain the set of sequences $\Omega$. If we are +strategy $\xi$ for the specific problem. As a by-product, we also obtain +the set of sequences $\Omega$. If we are not satisfied with our controller behavior, we can analyze the set of -sequences to understand how to improve the system (i.e., for example -optimize a certain task in the taskset) to improve the control -performance. +sequences to understand how to improve the control +performance (i.e., for example +optimize a certain task in the taskset). \subsection{Paper Organization} \label{sec:method:organization} diff --git a/paper/sec/model.tex b/paper/sec/model.tex index 970701d..060f4c7 100644 --- a/paper/sec/model.tex +++ b/paper/sec/model.tex @@ -13,7 +13,7 @@ misses. \label{sec:model:taskset} In this paper, a real-time workload $\Gamma$ is defined as the union -of a (given) set of hard real-time periodic tasks, plus a real-time +of a (given) set of generic hard real-time periodic tasks, plus a real-time control task $\tau_d$, which is the target of our design, i.e., $\Gamma = \Gamma' \,\bigcup\, \{ \tau_d \}$. In this description, $\Gamma'$ is a set of $N_T$ periodic tasks, i.e., $\Gamma' = \{ \tau_1, @@ -26,16 +26,17 @@ the indexing reflects their priority ordering, i.e. $\tau_i$ has higher priority than $\tau_j$ if $i<j$. In our design problem, $\tau_d$ is the task with the lowest priority. + Each task is characterized by a tuple of parameters, $\tau_i = -(\mathcal{C}_i,f_i^{\mathcal{C}}(c),D_i,T_i)$. Here, $\mathcal{C}_i$ +(\mathcal{C}_i,f_i^{\mathcal{C}},D_i,T_i)$. Here, $\mathcal{C}_i$ is a random variable that represents the task execution time, while -$f_i^{\mathcal{C}}(c)$ represents its probability density function, -i.e. $f_i^{\mathcal{C}}(c) = \mathbb{P}\{\mathcal{C}_i = c \}$; +$f_i^{\mathcal{C}}(c)$ is its probability density function, +i.e. $\forall c\in \mathbb{N}, \, f_i^{\mathcal{C}}(c) = \mathbb{P}\{\mathcal{C}_i = c \}$; $D_i$ and $T_i$ are deterministic values, representing respectively the task deadline and period. In accordance with the literature on real-time applications for control systems, -task periods $T_i$ are chosen among a limited set of possible values, -typically related to the physical requirements of the control +task periods are chosen among a limited set of possible values, +typically related to physical requirements of the control task~\cite{kramer2015real, pagetti2014rosace}. For each task $\tau_i$, we consider a discrete probability @@ -45,7 +46,10 @@ Worst Case Execution Time (WCET) $C^{\text{max}}_i$. Furthermore, we consider tasks that behave well in most cases, i.e., tasks whose probability density functions are skewed towards lower values. In fact, we want to capture tasks which experience occasional faulty -conditions. This choice is in agreement with most works that analyze +conditions. \pp{While, in principle, our approach can be applied +to systems with generic probability density functions, this choice } +%This choice +is in agreement with most works that analyze execution time distributions for real-time tasks~\cite{wilhelm2008worst}. We will generally refer to the utilization of taskset $\Gamma'$ as the \emph{worst-case} utilization, i.e. @@ -55,7 +59,9 @@ We denote each periodic instance of $\tau_i \in \Gamma$ with the term job, and define it as $J_{i,k}$, with $k=1,2,\dots$ representing the job index and $i$ representing the task index. For every job $J_{i,k}$, $a_{i,k}$ denotes the activation instant, and $a_{i,k+1} - -a_{i,k} = T_i$. In the following, $\mathcal{R}_{i,k}$ represents the +a_{i,k} = T_i$. Since we are considering synchronous release conditions, +$\forall i, \, a_{i,0} = 0$ holds. +In the following, $\mathcal{R}_{i,k}$ represents the random discrete variable that models the response time of $J_{i,k}$. The Worst Case Response Time (WCRT) of task $\tau_i$ is denoted as $R_i^W$ and computed with standard techniques @@ -73,7 +79,7 @@ that at least one job of $\tau_d$ respects its deadline, i.e. $R_d^B \subsection{Plant and Controller Model} \label{sec:model:plant} -The plant to be controlled by $\tau_d$ is described as a Linear +The plant to be controlled by $\tau_d$ is described as a Linear Time Invariant (LTI), Multi-Input Multi-Output (MIMO) system in continuous time. In line with standard assumptions, we assume the plant to be controllable and the state to be fully measurable. The plant dynamics is described as @@ -83,7 +89,7 @@ controllable and the state to be fully measurable. The plant dynamics is describ \label{eq:plant} \mathbf{\dot{x}}(t) = A_c\,\mathbf{x}(t) + B_c\, - \mathbf{u}(t) + \mathbf{v_c}(t). + \mathbf{u_c}(t) + \mathbf{v_c}(t). \end{equation} % In Equation~\eqref{eq:plant}, every element in bold represents a @@ -97,16 +103,16 @@ control is to minimize a cost function, defined as the mean value of a quadratic % \begin{equation} \label{eq:cost} -J_\text{ctl} = \E \left\{ \mathbf{x}^{\!\T}\!(t) Q_{1c} \mathbf{x}(t) +J_\text{ctl} = \E \left\{ \int \mathbf{x}^{\!\T}\!(t) Q_{1c} \mathbf{x}(t) + \mathbf{u_c}^{\!\!\T}\!(t) Q_{2c} \mathbf{u_c}(t) \right\}. \end{equation} % Here, $\E$ indicates the expected value, while $Q_{1c}$ and $Q_{2c}$ are constant positive semidefinite matrices and -design parameters of the controller. They represent the design -trade-off between regulating the state $\mathbf{x}(t)$ to zero and the cost of utilizing the control signal $\mathbf{u_c}(t)$. The same cost function is used both as a controller design objective and for performance evaluation of the control task. +design parameters of the controller. They represent the +trade-off between regulating the state $\mathbf{x}(t)$ to zero and the cost of using the control signal $\mathbf{u_c}(t)$. This cost function is used both as a controller design objective and for performance evaluation of the control task. The plant is connected to the controller via time-triggered sampler and hold devices -as shown in Figure~\ref{fig:pandc}. +as shown in Figure~\ref{fig:pandc}. \pp{The behavior of these devices can be modeled as a dedicated task that reads and writes data with ideal zero execution time and highest priority}. % \begin{figure}[t] \centering @@ -135,13 +141,15 @@ as shown in Figure~\ref{fig:pandc}. \label{fig:pandc} \end{figure} % -The plant state is sampled every $T_d$ time units, implying $\mathbf{x}(t_k) = \mathbf{x}(kT_d)$. +The plant state is sampled every $T_d$ time units, implying $\mathbf{x}(t_k) = \mathbf{x}(kT_d)$. \pp{The control job $J_{d,k}$ is released at the same instant, i.e. $a_{d,k} = kT_d$, and it is assumed that the sensor data $\mathbf{x}(t_k)$ is immediately available to it.} Based on the state measurement $\mathbf{x}(t_k)$, the controller computes the feedback control action $\mathbf{u}(t_{k})$. As an hypothesis, our control task $\tau_d$ is executing under the Logical Execution Time (LET) paradigm, with deadline $D_d=T_d$. -The job $J_{d,k}$, released at -time $a_{d,k}$ reads the measurement of the output available at time -$a_{d,k}$, computes the control output and makes it available only at +Indeed, the job $J_{d,k}$ +%released at time $a_{d,k}$ +% reads the measurement of the plant state available at time +%$a_{d,k}$, +computes the control output using $\mathbf{x}(t_k)$ but makes it available to the actuator only at the first deadline instant after the termination of its execution. The control actuation is then held constant until the \emph{next} update. This means that, if all jobs finish before their deadline, the following equation @@ -149,19 +157,17 @@ holds: \begin{equation} \mathbf{u_c}(t) = \mathbf{u}(t_{k}), \qquad a_{d,k} + D_d \leq t < a_{d,k+1} + D_d. \end{equation} -%%%%%% DO NOT MODIFY THIS ANYMORE PLEASE %%%%%%%%% The execution time of the control task $\tau_d$ is given as a random variable with known probability density function, and is treated equivalently to any other task in $\Gamma'$. On the contrary, the deadline $D_d$ and period $T_d$ of the control task $\tau_d$ are part of the design. Being a LET task, we restrict our analysis to the implicit deadline case, although in principle the approach in the paper can be applied to other relative deadlines (and corresponding -output times). We further assume that the execution time properties of the controller do not change with different periods and different controller parameters. - +output times). We further assume that the execution time properties of the controller do not change with different periods and different controller parameters %We operate under the hypothesis that the execution %time of the controller does not change when using different control -%parameters and different periods. This is a reasonable assumption, -%since only the values of some constants are modified but the -%operations done by the control task are the same. +%parameters and different periods. +\pp{(since only the values of some parameter are modified but the +operations done by the control task are the same).} In the paper, $\tau_d$ is not treated as a hard-deadline task. On the contrary, we actively look for those values of $T_d$ such that the @@ -172,6 +178,20 @@ on one single core. In Section~\ref{sec:design}, we present how to properly characterize the timing behavior of the controller and its synthesis. +\begin{remark} +\pp{ +In this paper, we consider $\tau_d$ as the task +with the lowest priority. However, a similar approach can be used +if other tasks with priority lower than $\tau_d$ exist. If this is the +case, $\Gamma'$ will refer to the +subset of tasks with higher priority than $\tau_d$. +Moreover, the lower priority tasks will not affect the response time analysis +of $\tau_d$, but their schedulability must be checked for each chosen +value of $T_d$, resulting in additional constraints in the design. +Due to space constraints, we reserve to analyze +this more general case as a future work. } +\end{remark} + %The discrete-time control task $\tau_d$ to be designed is composed of %a Linear Quadratic (LQ) state feedback %controller~\cite{aastrom2013computer} and a state predictor. The @@ -189,19 +209,19 @@ enforcing periodicity for a controller on a real-time platform, one usually selects a period for the control task that is greater or equal than the task's WCRT. This approach is safe but can be very pessimistic. In fact, WCRT conditions may be extremely -rare. Selecting the period with the mentioned constraint could -severely limit the achievable control performance, since longer sampling +rare. Selecting the period with the mentioned constraint could +limit the achievable control performance, since longer sampling periods in general mean worse disturbance rejection and smaller stability margins~\cite{cervin2003does}. The approach presented in this paper explores the possibility of designing a control task with periods smaller than its WCRT, i.e., -$T_d\leq R_d^W$, thus greatly extending the design space. We -remark that, with $T_d>R_d^W$ there are no deadline misses, and +$T_d< R_d^W$, thus greatly extending the design space. We +remark that, with $T_d\geq R_d^W$ there are no deadline misses, and standard approaches for the control design can be used \cite{kim1998task,xu2015exploiting}. -Choosing $T_d\leq R_d^W$ implies the risk that the control task will miss some deadlines. +Choosing $T_d< R_d^W$ implies the risk that the control task will miss some deadlines. A deadline miss is a timing violation that can produce unbounded response times, due to self-pushing~\cite{sun2017weakly}, and therefore it should be properly handled. In this work, we consider -- GitLab