This preview shows pages 1–2. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: Ready for a change? Open | Close Your ad here. Buy Media Now All Articles Products Column Courses VirtuaLabs Webinars Login | Register Welcome Guest Embedded.com Deadline Monotonic Analysis Ken Tindell This article presents a technique for analyzing the worst-case response times of tasks in a system and shows how the results of this analysis can be used to ensure the proper timing behavior of a system A common misconception is that "hard real-time" means "very fast." This might explain why Microsoft claims that their upcoming v. 3.0 release of Windows CE will be a hard real-time OS. (CE v. 3.0 will reportedly allow nested interrupts and, hence, achieve sub-millisecond interrupt latencies.) However, hard real-time is better described as "when it absolutely, positively has to be done on-time." Or, put another way, "a late result is a wrong result." Another misconception is that "hard real-time" means "safety critical" and that because a system cannot kill someone there's no need to worry much about meeting deadlines. However, a hard real-time system is one where the consequences of missing a deadline are serious. To be sure, if injury or death can result from a missed deadline then this is serious and we have a hard real-time system. But lots of systems exist where the consequences of missing a deadline even occasionally are economically unacceptable. In high-volume industries it's important that systems operate correctly because the costs of even trivial failures are high. For example, in an automobile, the instrument panel computer might apply a timeout to a regular RPM message from the engine management system. If the message doesn't turn up on time, the instrument panel assumes a failure and lights a "check engine" lamp. It is important to do this because if the engine management system isn't talking properly on the network then there might be some serious faults, and the driver should take the automobile to a workshop to check for a wiring fault. But if the vehicle systems haven't been designed to meet hard deadlines, and occasionally the RPM message turns up a little late, the timeout will trigger and the garage mechanics will find no actual fault. If this kind of overrun occurs even once in a million hours then, with the millions of hours of operation of a particular vehicle type every day, there will be thousands of "no fault found" warranty claims each year. This could cost millions of dollars, not to mention the damage to a corporation's reputation for reliability. Clearly, the economic consequences of missing deadlines can be severe. It's clear that if we want to build a hard real-time system then we have to be able to determine, before the system is deployed, whether deadlines could be missed or not. One common way to try to find out the worst-case timing behavior of a system is via Embedded.com Career Center The ITRS process roadmap and nextgen embedded multicore SoC design Dive in to C++ and survive Why C++ is a viable alternative to C in embedded...
View Full Document
- Spring '09