系统实时性
什么是实时性?
实时性(Real-Time),目前不清楚起源于什么,但是可以通过下面的示例来理解它.
- 计算机的特点
输入-计算-输出
一个具备实时性的系统,应该可以在很短的的时间内,处理输入的数据,并给出输出.
我们知道,大部分嵌入式系统是需要和外界交互的,像是人与设备,设备与设备等,这种交互过程可以归类为通信过程.
通信过程总会有一个传输延迟,对于一个嵌入式软件系统而言,这个传输延迟,应该由计算特点来表示:
\[T(通信系统的传输延迟) = T(编码)+T(传输)+T(解码) \]
\[T(嵌入式系统的"传输延迟") = T(输入)+T(计算)+T(输出) \]
一般的,我们认为 T(嵌入式系统的"传输延迟") 足够小,即可为满足实时性的要求.
这个足够小总要有一个阈值,我们假定这个阈值为T(window)[叫做时间窗口],,超过这个阈值我们认为系统实时性差,或者实时性不好,不是实时系统.
\[T(嵌入式系统的"传输延迟") < T(window) \]
什么是实时性?
实时性表示一个条件,满足实时性的系统,应满足\[T(嵌入式系统的"传输延迟") < T(window) \]
T(window)怎么确定
T(window)并不是恒值,它依赖于一个具体的系统.比如数据处理系统,AD采集系统,以及一些控制系统.即他们是和具体的软件功能绑定的.
- 1.数据处理系统
拿数据处理系统来说,我们根据计算机的特点,给出数据处理系统的软件特点:
接收数据 - 处理数据 - 发送数据
T(window)这里应该表示满足从接收数据,到处理数据,最后发送数据这个过程所需要的时间.
如图所示,T(window)这里表示两帧数据之间的时间间隔.
x = 数据处理系统
\[T(x,window) = T(FrameRate) \]
上面这个模型只是考虑了帧长固定的情况,如果一帧的数据不是固定的,上式应该考虑一帧的长度length.
\[T(x,window) = T(FrameRate, FrameLength) \]
从图中,我们也能够得到i去纳入是系统的传输延迟是多少
delay = "传输延迟"
\[T(x,delay) = T(Copy) + T(DataProcess) + T(DataOutput) \]
于是,我们的到了x = 数据处理系统 时,x的满足实时性系统的条件是:
\[T(FrameRate, FrameLength) > T(Copy) + T(DataProcess) + T(DataOutput) \]
假设两者的差值为 T(Idle)
\[T(Idle) = T(x,delay)- T(x,window)\\\quad\quad\quad\quad\quad\quad\quad\quad\quad\quad\quad= T(FrameRate, FrameLength) - (T(Copy) + T(DataProcess) + T(DataOutput)) \]
这里的T(Idle)就是我们可以控制的变量.
而T(Copy) + T(DataProcess) + T(DataOutput)这部分大多是由协议绑定的,是存在一个最小值的.
为了增大T(Idle)来给x更多的时间来处理其它事物,且要满足实时性的条件.我们不得不改变T(FrameRate,FrameLength).
\[T(Idle) \propto 1/FrameRate \]\[T(Idle) \propto -k*FrameLength \]
T(Idle)和FrameRate与FrameLength成反比.
即帧率(FrameRate)越高,T(Idle)就越小.
(这里少了个条件,是在一定时间范围内)
于是,为了保证系统的实时性,我们要么降低帧率(FrameRate);要么提高cpu的主频.
- AD采集系统
分析同上. - 一般控制系统
分析同上.
计算机系统的实时性条件
我们利用计算机系统的特点,简化满足实时性系统的条件.
\[T(x, window) > T(Input) + T(Process) + T(Output) \]如果假定两者的差值为T(Idle)
\[T(Idle) = T(x, window)-T(Input) + T(Process) + T(Output) \]那么T(Idle)需要大于0
\[T(Idle) > 0 \]
T(嵌入式系统的"传输延迟")怎么计算
我们当下很多嵌入式系统都是多功能,多任务的.对于这些功能复杂的系统,希望它们满足实时性的要求,则需要对系统有一个良好的设计.
什么是良好的设计呢?
首先可以确定的一点是 T(Idle) > 0 ,为了确保CPU有空闲时间,我们可以根据经验,事先计算需要的主频.
我们先写好相关的协议/算法/逻辑.
然后选择好内核,比如ARM内核.
然后,根据指令估算这部分代码所需要的时间.
在此基础上,加上一个冗余,这部分冗余,是给中断,RTOS调度,等其它功能.
T(Process)的计算.
\[T(Process)=T(Code)+T(Others) \]其中 Others 指 Interrupt, schedule 等
同理,我们也可以计算出 T(Input) , T(Output) .
\[T(Input)=T(Code)+T(Others) \]\[T(Output)=T(Code)+T(Others) \]其中 Others 指 Interrupt, schedule 等
于是,我们可以计算某个系统的"传输延迟"了.
x=某个嵌入式系统
y=task(m),m为某个任务的标号,y表示某个任务.\[T(x,y,delay) = T(Copy) + T(DataProcess) + T(DataOutput) \]
并发问题
上面我们讨论了嵌入式系统单个任务/功能的"传输延迟",这也可以粗略的给出该任务满足实时性要求的时间窗口.
但是当,某一个时刻,出现多个输入事件时,原有的 T(Idle) 可能就不足以确保彼此的实时性.
如图,我们可以计算出多任务,并发情况的时间窗口示意图.
x=嵌入式系统的应用
y=[task(A),task(B)]\[T(x,y, window) = T(Input A) + T(Input B) + T(Process A) + T(Process B) + T(Output A) + T(Output B) + T(Idle) \]其中
\[T(x,y,delay) = T(Input A) + T(Input B) + T(Process A) + T(Process B) + T(Output A) + T(Output B) \]
为了方便对比单任务和多任务之间时间窗口的差距.我绘制了多任务时,每个任务独自的时间窗口.如图.
task(A)的时间窗口示意图
\[T(x,y=task(A), window) = T(Input A) + T(Process A) + T(Output A)+ T(Idle A1) + T(Idle A2) \]其中
\[T(x,y=task(A),delay) = T(Input A) + T(Process A) + T(Output A) \]task(B)的时间窗口示意图
\[T(x,y=task(B), window) = T(Input B) + T(Process B) + T(Output B) + T(Idle B1) + T(Idle B2) \]其中
\[T(x,y=task(B),delay) = T(Input B) + T(Process B) + T(Output B) \]
若要task(A)和task(B)满足实时性,则应同时满足下面条件.
若task(A)满足实时性的要求.
则\[(Idle A1) + T(Idle A2) >= T(x,y=task(B),delay) \]同理,若task(B)满足实时性的要求.
则\[(Idle B1) + T(Idle B2) >= T(x,y=task(A),delay) \]
这里回顾一下单系统(任务)时的方程,可以得出以下规律:
单独task(A)系统(任务)时,
T(Idle)=m
而task(A),task(B)两个任务时,
(Idle A1) + T(Idle A2) = p;
(Idle B1) + T(Idle B2) = q;
m,p,q之间满足如下关系:\[p>m,\\q>m,\\m>T(x,y=task(A),delay),\\m>T(x,y=task(B),delay) \]
这与直觉是一致的:
1.单任务系统时,只要满足 T(Idle)>0 ,该系统就满足实时性的要求.
2.双任务系统时,每个任务的 T(Idle) 被拆为多个部分,总和分别为p,q,...
p,q,...需要比除自身外其它任务的"传输延迟"之和 T(x,y=task(?),delay) 要大.
这意味着,原有的 T(Idle) 有一个下限值 m ,这个下限值 m 要比 T(x,y=task(?),delay) 任意一个都大.
3.更多的任务时,系统的并发实时性,有更高的要求.下限值 m ,应该比除自身外,其它所有任务的 "传输延迟" 之和sum(T(x,y=task(?-self),delay))要大.
实时系统的编程范式
有了上面的分析,实时系统可以有一个编程范式.
未完...