LCE: Realtime, present and future

Posted Nov 15, 2012 13:00 UTC (Thu) by simlo (guest, #10866)
In reply to: LCE: Realtime, present and future by tglx
Parent article: LCE: Realtime, present and future

Everytime this discussion comes up I add a comment like this:

Safety critical != hard real time

Safety critical means that the system is certified and verified and maybe even mathematical proven to be correct. This implies small code and very often hard realtime.

Hard real time means that there per design is an upper boundary to latency. But we all know that a system might not work as designed. Therefore a system can be hard real time by design but fail due to bugs.

Thus by these definitions neither preempt realtime, RT-Linux nor Xenomia can be be safety critical but all can claim "hard real time" - but only if they have made sure that all code paths blocking scheduling of higher priority tasks and interrupts, have an upper boundary.

And for a practical note: The theoretical upper boundary is not magnitudes higher than what you can measure in tests.

LCE: Realtime, present and future

Posted Nov 15, 2012 17:29 UTC (Thu) by tglx (subscriber, #31301) [Link] (1 responses)

I'm well aware that safety critical != hard real-time.

Though hard real-time systems must be designed in a way that they guarantee not to ever miss a deadline, simply because missing a single deadline is considered a fatal full system failure. So how do you guarantee that by other means than by mathematical proof?

> And for a practical note: The theoretical upper boundary is not magnitudes higher than what you can measure in tests.

None of those systems including Preempt-RT can specify their theoretical upper boundary, except in safe ranges which make them not at all different :)

Thanks
tglx

Most systems also have no proof that a kernel panic won't occur.

Posted Dec 9, 2012 7:41 UTC (Sun) by gmatht (guest, #58961) [Link]

Even for a non-RT system there is usually no proof that a full system failure won't occur. E.g. Linux has no proof that a kernel panic won't occur. Systems that claim to conform to POSIX standards rarely have a proof of this. If some organisation can trace all the cases of system failure to hardware failures they may choose to trust claims made by software, including hard real time claims, without formal proof.