The hard and soft facts behind ‘real time’

Posted By Colin Murphy
Technical Program Manager, Microsoft’s Windows Embedded

We’re excited by the prospects for Windows Embedded Compact 2013. Developers have been actively downloading the full toolkit since Microsoft announced the general availability in June. In a post to this blog at the time, I shared details about the GA including a look some of the newest tools like Microsoft Platform Builder and Application Builder.

Today, I’m following up on my promise in the blog post to take a look at what it means to be real time and how that transfers to the expectation of real-time support on an embedded device. First, What do we mean when we say “hard real time” vs. “soft real time”? A hard real time statement refers to true determinism, or the ability of a system to meet a specified deadline for a task or process. A soft real time system may still offer a certain level of determinism but won’t promise to meet a deadline. Basically, a system that claims to be hard real time will fail to truly be so if it misses a deadline for a task or process.

A real-world version of a soft deadline would be “Let’s get coffee around 4pm.” while a hard deadline would be “Let’s catch the train at 4pm”. The coffee shop is likely still serving coffee after 4pm so you can sit and have coffee with your friend even if you’re a few minutes late, but the train has likely left and your friend is waiting for you and fuming on the train platform as you arrive late. As there is probably not another train for quite some time, I hope there is a nice coffee shop in the train station!

Notice that the real-world examples have set expectations. You miss the train, you fail. You miss the coffee shop at exactly 4 pm, not as much of a problem. Computer processes and tasks can and do set expectations as well. For example, a GPS location message could arrive on a regular interval but if your portable embedded device stayed fully powered at all time to catch that message your battery life would suffer. In this case the device could wake moments ahead of the expected arrival and only stay awake until a message or a time out. In this situation you can see that either a hard or soft real-time system would work. You can set the granularity of the wakeup to accommodate for “soft” timing but you would achieve better battery life if you had “hard” timing because you could guarantee to wake as close as you could to the expected message arrival.

So now you ask, What does this mean for developers?

• For device developers it means adding a “Real Time Clock” to their hardware bill of materials for their platform along with writing their BSP and drivers to support using that clock efficiently. Depending on what the final purpose of the device might be, developers may decide it is not worth the extra hardware cost, code and effort. They would obviously rather go for coffee!
• For application developers it means not only do you need to write responsible code as to not “clog” the interrupts, soft or hard, but also if in need of real-time determinism, you should ensure the device chosen actually has a real-time clock and a well written BSP. The good news is, the application code for soft and hard real-time applications use the same API. It is the underlying hardware and related drivers that offer either level of determinism so you can shop around and even try out your application on multiple devices until you find a device that meets your needs.

What should your expectation be for real time on a Compact device? In my experience “hard real time” can mean a 1 or 2 millisecond clock tick expectation while a “soft real time” clock tick can be 40 milliseconds or more on a busy system. Terms like “buyer beware” and “your mileage may vary” come to mind, so take a test drive before you commit to a device and set your expectations accordingly!

For information on the behavior and performance of a Windows Embedded Compact system, there are a number of articles that provide detailed information as well application development for real time as discussed in the recently published Compact 2013 eBook from Embedded101.

Behavior and performance evaluation of Windows Embedded Compact 7 on ARM

Behavior and performance evaluation of Windows Embedded Compact 7 on x86