Here are Douglass Locke's answers:

• What is real-time? — A real-time system (defined by IEEE) is a system whose correctness includes its response time as well as its functional correctness. In other words, in a real-time system, it not only matters that the answers are correct, but it matters when the answers are produced. Note that by this definition, systems requiring a defined Quality of Service are usually real-time systems, although they might not use those words to describe themselves.

• What is hard real-time? — Hard real time means that the system (i.e., the entire system including OS, middleware, application, HW, communications,
  etc.) must be designed to GUARANTEE that response requirements are met. It doesn't matter how fast the requirements are (microsecond, millisecond, etc.) to be hard real-time, just that they MUST be met EVERY TIME. This means that EVERY resource mechanism (i.e., scheduler, I/O manager, mutex mechanism, communications mechanism, etc.) must select the work to be done in the correct order to meet time constraint requirements. This means that mechanisms (e.g., priority inheritance) MUST be provided to avoid unbounded priority inversion (such as was encountered and corrected in the hard real-time failure in the Mars Pathfinder). This means that FIFO queues must be avoided or kept empty. This means that ALL processes and threads, including those within the kernel MUST either be preemptible (i.e., a high priority request can preempt a lower priority one), or there must be a specific bound on its non-preemtibility time.

  Note: Few, if any systems are completely hard real-time. However, many, if not most, soft real-time systems have a few hard real-time requirements. For example, if a system has a mechanism (e.g., hearbeat, timeout) to detect a failure, missing the event will cause the system to enter a failure recovery mode, thus creating a failure. Thus, such mechanisms represent hard real-time requirements. Another example is a switching system that is required to switch around a fault within 50 milliseconds or a penalty must be paid to a customer.

• Who needs real-time? . . . hard real-time? — A few years ago, almost the only applications that needed real-time were military & space. Today, it's almost easier to list the application domains that do not need real-time. Here are a few examples of applications with real-time requirements: Telecom switching, web servers, voice over IP, cell phones, digital TV, set-top-boxes, video conferencing, TV broadcasting equipment (cameras, video mixdown, etc.), automotive controls, car navigation, medical equipment, defense, space, aircraft controls, aircraft navigation, games, industrial automation, robotics, and even international airline gambling equipment! Most of these applications are generally soft real-time, but many have a few hard real-time constraints.

• What is soft real-time? — Soft real-time is exactly the same as hard real-time in its infrastucture requirements, but it is not necessary for system success that EVERY time constraint be met. For example, if a display update is late by 5 ms., it probably doesn't matter. If it's late by 100 ms., it can create the impression that the system has failed. Or take a digital movie. If one frame is missed per hour, it's probably ok. But if 3 frames are missed in a row, it looks like a failure (glitch) to the user. Most time constraints are soft, but they are nontheless important. Some people seem to consider soft real-time and non-real-time to be equivalent; they are not.

• How do you characterize real-time performance? — That is, what key specifications should RTOS vendors use to objectively characterize their offerings? There are many. For example, what is the worst-case context
  switch time? What is the maximum priority inversion time? What is the longest time for which interrupts are disabled? Is priority inversion time bounded at all? What is the user-settable clock resolution? What is the interrupt latency for each attached device? How many priorities are available for application processes and threads?

---

Panelist's bio: Dr. C. Douglass Locke is VP of Technology at TimeSys Corporation. He received a Ph.D in Computer Science from Carnegie-Mellon University, writing his dissertation on real-time scheduling. He has more than 30 years experience in specifying, architecting, designing, and implementating a wide span of real-world applications including space flight, aircraft, shipboard, submarine, command & control, and information systems. Dr. Locke has served on various real-time standardization committees including POSIX, Real-Time CORBA, Real-Time UML, and Real-Time Java.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.