Web Development

General discussion


Real-time embedded systems

By MaryWeilage Editor ·
What do you think real-time actually means for embedded software developers, as discussed in this week's Embedded Software Development e-newsletter? How does your shop deal with hard real-time, soft real-time, or non-real-time systems differently?
If you aren't already subscribed to the Embedded Software Development e-newsletter, visit our e-newsletter subcenter and sign up for this free TechMail today:

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Real-time is more complicated than that

by jensen In reply to Real-time embedded system ...

That was a better summary than I have often read elsewhere, but it still has a serious misunderstanding about "hard" and "soft" real-time (shared not just by most practitioners but also by many in the real-time research community, in both cases due to their experience being limited to small, simple, static device-level subsystems). Just because a system or application has soft time constraints doesn't mean that missing those "is not severe and might simply degrade a system's throughput." For example, most of the combat systems we are all watching on TV are soft real-time -- instead of requiring that all deadlines always be missed, the objectives are things like minimizing the amount by which deadlines are missed, which translates into things like targeting accuracy. As we all know all too well, targeting accuracy relates directly to mission success, human and property casualties, etc. BTW, these life-critical deadlines are often in the seconds and minutes and hours time scales. For a much more comprehensive and precise description of the fundamental concepts and term of "real-time," see my web site http://www.real-time.org.

Collapse -

It needn't be more complicated

by dbrenan In reply to Real-time is more complic ...

Thanks for your comments. In the context of Embedded Software Development (the theme of the article) we tend to be designing "small, simple, static device-level subsystems" rather than the large distributed systems to which you allude (which may consist of many networked embedded devices). They are different beasts, as you highlight on your web-site.

I'm not clear why you feel there is a serious misunderstanding about "hard" and "soft" real-time. The military systems that you cite have lowerstandards for what is deemed to be acceptable performance. In the brutal context of a distributed combat system that's designed to kill and destroy (not my field of expertise) we can observe that:
"not severe" = a few unintended casualties are considered acceptable
"system throughput" = rate of accurate delivery of weapons "packets"

So what's changed is the level of acceptable risk, not the basic meaning of hard or soft real-time.


Related Discussions

Related Forums