[ECOS] Hard-Realtime behaviour
R Vamshi Krishna
Sun Jun 18 22:21:00 GMT 2006
Sorry for the (long) break. Also I would like to digress a bit into my
requirements/motivation for "hard" real-time eCos.
What we require is an open source "hard" real-time OS. We zeroed
onto eCos for the configurability it provided.
Now this hard real-time OS would be for use in Safety-Critical Systems. We
would port the kernel to MISRA-C later stage but currently we are stuck-up
at "hardening" of eCos. Hence I would have to guarantee that my
application would not fail/miss a deadline under "any" circumstances.
This guarantee I understand cannot be given by an RTOS alone. It is the
combined guarantee by the application + RTOS. i.e. everything depends on
the way the application was developed using the features of an RTOS.
But unless an RTOS provides "guaranteed" WCET (Worst Case Execution Times)
for it's kernel primitives, one cannot technically guarantee that the
application cannot miss any deadlines.
--- End of digression
Now I had inquired what made the developers of eCos deem it as a soft
real-time OS. RTAI is considered as a "hard" real-time OS. So what
enhancements/changes are required to eCos to make it "hard" real-time.
If the developers of eCos could enumerate it's short-comings as a "hard
real-time OS" and ways to fix it I would be thankful. I would then add
approprite CDL's so that future eCos community could use it.
>From all the lively discussions that I have had with various eCos
users/developers there seems to be no unanimous definition of a "hard"
What I would like to prove is the following :
(1) Given a set of threads, knowing all the systems calls it makes, and
hence (Assuming the WCET of the systems calls is known) the WCET of each
thread is known, all the threads will finish execution well within their
(2) Of course the analysis part is done offline providing enough time to
service all possible interrupts.
(3) All possible interrupts and their (worst-case) rate of occurance is
I do need entire eCos packages to be "hard" real-time. Just the kernel,
IPC, sync primitives, scheduler, etc .. ( i.e bare-bones).
BTW : RTAI uses an EDF (Earliest Deadline First) Scheduler but I believe
that EDF scheduler might not be strictly required for "hard" real-time
behaviour. Static priority driven scheduling is enough.
On Sun, 4 Jun 2006, Roy E Richardson wrote:
>> My Definition of a real-time OS is :
>> "An Operating System which has a guaranteed/upper bound on the worst-case
>> execution time of the kernel primitives it offers". This bound can be
>> calculated based on the design of the real-time application (e.g. No. of
>> threads, no. of interrupts and the rate at which they occur, etc ..)
>> Thus the scheduler, kernel primitives, thread api, interrupt handling,
>> context switching .. all must be deterministic.
> I do not intend to be cynical, but the above definition is rather soft. As
> long as there aren't structures such as link lists,
> or the like, then one should expect a predictable upper bound - allowing for
> INts? From the experiences I've had the def would fit nearly every OS.
> If I had been presented this item as a specification item, then I'd ask the
> originators for clarification of same -> what is the intent?
> PS. Outside the OS performance (max. time thereof), the overlaying app(s)
> will tend to require the lion's share of the processor,
> s an curious bystander, I'm nosey as what promted this request to begin with.
M.Tech. CSE (II year),
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss