Differences between hard real-time soft real-time and firm real-time

Question

I have read the definitions for the different notions of real-time  and the examples provided for hard and soft real-time systems make sense to me  But  there is no real explanation or example of a firm real-time system  According to the link above      Firm  Infrequent deadline misses are tolerable  but may degrade the system s quality of service  The usefulness of a result is zero after its deadline    Is there a clear distinction between firm real-time vs  hard or soft real-time  and is there a good example that illustrates that distinction   In comments  Charles asked that I submit tag wikis for the new tags  The example of a  firm real-time system  I provided for the firm-real-time tag was a milk serving system  If the system delivers milk after its expiration time  then the milk is considered  not useful   One can tolerate eating cereal without milk  but the quality of the experience is degraded   This is just the idea I formed in my head when I initially read the definition  I am looking for a much better example  and perhaps a better definition of firm real-time that will improve my notion of it

User · Answer

Consider a task that inputs data from the serial port. When new data arrives the serial port triggers an event. When the software services that event, it reads and processes the new data. The serial port has a hardware to store incoming data (2 on the MSP432, 16 on the TM4C123) such that if the buffer is full and more data arrives, the new data is lost. Is this system hard, firm, or soft real time?

It is hard real time because if the response is late, data may be lost.

Consider a hearing aid that inputs sounds from a microphone, manipulates the sound data, and then outputs the data to a speaker. The system usually has small and bounded jitter, but occasionally other tasks in the hearing aid cause some data to be late, causing a noise pulse on the speaker. Is this system hard, firm or soft real time?

It is firm real time because it causes an error that can be perceived but the effect is harmless and does not significantly alter the quality of the experience.

Consider a task that outputs data to a printer. When the printer is idle the printer triggers an event. When the software services that event, it sends more data to the printer. Is this system hard, firm or soft real time?

It is soft real time because the faster it responses the better, but the value of the system (bandwidth is amount of data printed per second) diminishes with latency.

UTAustinX: UT.RTBN.12.01x Realtime Bluetooth Networks

User · Answer

After reading the Wikipedia page and other pages on real-time computing  I made the following inferences   1  For a Hard real-time system  if the system fails to meet the deadline even once the system is considered to have Failed   2  For a Firm real-time system  even if the system fails to meet the deadline  possibly more than once  i e  for multiple requests   the system is not considered to have failed  Also  the responses for the requests  replies to a query  result of a task  etc   are worthless once the deadline for that particular request has passed  The usefulness of a result is zero after its deadline   A hypothetical example can be a storm forecast system  if a storm is predicted before arrival  then the system has done its job  prediction after the event has already happened or when it is happening is of no value    3  For a Soft real-time system  even if the system fails to meet the deadline  possibly more than once  i e  for multiple requests   the system is not considered to have failed  But  in this case the results of the requests are not worthless value for a result after its deadline  is not zero  rather it degrades as time passes after the deadline  Eg   Streaming audio-video   Here is a link to a resource that was very helpful

User · Answer

The simplest way to distinguish between the different kinds of real-time system types is answering the question       Is a delayed system response  after the deadline  is still useful or not    So depending on the answer you get for this question  your system could be included as one of the following categories    Hard  No  and delayed answers are considered a system failure      This is the case when missing the dead-line will make the system unusable  For example the system controlling the car Airbag system should detect the crash and inflate rapidly the bag  The whole process takes more or less one-twenty-fifth of a second  Thus  if the system for example react with 1 second of delay the consequences could be mortal and it will be no benefit having the bag inflated once the car has already crashed    Firm  No  but delayed answers are not necessary a system failure    This is the case when missing the deadline is tolerable but it will affect the quality of the service  As a simple example consider a video encryption system  Normally the password of encryption is generated in the server  video Head end  and sent to the customer set-top box  This process should be synchronized so normally the set-top box receives the password before starts receiving the encrypted video frames  In this case a delay it may lead to video glitches since the set-top box is not able to decode the frames because it hasn t received the password yet  In this case the service  film  an interesting football match  etc  could be affected by not meeting the deadline  Receiving the password with delay in this case is not useful since the frames encrypted with the same have already caused the glitches     Soft  Yes  but the system service is degraded       As from the the wikipedia description the usefulness of a result degrades after its deadline  That means  getting a response from the system out of the deadline is still useful for the end user but its usefulness degrade after reaching the deadline  A simple example for this case is a software that automatically controls the temperature of a room  or a building   In this case if the system has some delays reading the temperature sensors it will be a little bit slow to react upon brusque temperature changes  However  at the end it will end up reacting to the change and adjusting accordingly the temperature to keep it constant for example  So in this case the delayed reaction is useful  but it degrades the system quality of service

User · Answer

To define  soft real-time   it is easiest to compare it with  hard real-time   Below we will see that the term  firm real-time  constitutes a misunderstanding about  soft real-time    Speaking casually  most people implicitly have an informal mental model that considers information or an event as being  real-time       if  or to the extent that  it is manifest to them with a delay  latency  that can be related to its perceived currency      i e   in a time frame that the information or event has acceptably satisfactory value to them   There are numerous different ad hoc definitions of  hard real-time   but in that mental model  hard real-time is represented by the  if  term  Specifically  assuming that real-time actions  such as tasks  have completion deadlines  acceptably satisfactory value of the event that all tasks complete is limited to the special case that all tasks meet their deadlines   Hard real-time systems make the very strong assumptions that everything about the application and system and environment is static and known a  priori   e g   which tasks  that they are periodic  their arrival times  their periods  their deadlines  that they won   t have resource conflicts  and overall the time evolution of the system  In an aircraft flight control system or automotive braking system and many other cases those assumptions can usually be satisfied so that all the deadlines will be met   This mental model is deliberately and very usefully general enough to encompass both hard and soft real-time--soft is accommodated by the  to the extent that  phrase  For example  suppose that the task completions event has suboptimal but acceptable value if   no more than 10  of the tasks miss their deadlines or no task is more than 20  tardy or the average tardiness of all tasks is no more than 15  or the maximum tardiness among all tasks is less than 10    These are all common examples of soft real-time cases in a great many applications   Consider the single-task application of picking your child up after school  That probably does not have an actual deadline  instead there is some value to you and your child based on when that event takes place  Too early wastes resources  such as your time  and too late has some negative value because your child might be left alone and potentially in harm s way  or at least inconvenienced    Unlike the static hard real-time special case  soft real-time makes only the minimum necessary application-specific assumptions about the tasks and system  and uncertainties are expected  To pick up your child  you have to drive to the school  and the time to do that is dynamic depending on weather  traffic conditions  etc  You might be tempted to over-provision your system  i e   allow what you hope is the worst case driving time  but again this is wasting resources  your time  and occupying the family vehicle  possibly denying use by other family members    That example may not seem to be costly in terms of wasted resources  but consider other examples  All military combat systems are soft real-time  For example  consider performing an aircraft attack on a hostile ground vehicle using a missile guided with updates to it as the target maneuvers  The maximum satisfaction for completing the course update tasks is achieved by a direct destructive strike on the target  But an attempt to over-provision resources to make certain of this outcome is usually far too expensive and may even be impossible  In this case  you may be less but sufficiently satisfied if the missile strikes close enough to the target to disable it   Obviously combat scenarios have a great many possible dynamic uncertainties that must be accommodated by the resource management  Soft real-time systems are also very common in many civilian systems  such as industrial automation  although obviously military ones are the most dangerous and urgent ones to achieve acceptably satisfactory value in   The keystone of real-time systems is  predictability   The hard real-time case is interested in only one special case of predictability--i e   that the tasks will all meet their deadlines and the maximum possible value will be achieved by that event  That special case is named  deterministic     There is a spectrum of predictability  Deterministic  determinism  is one end-point  maximum predictability  on the predictability spectrum  the other end-point is minimum predictability  maximum non-determinism   The spectrum s metric and end-points have to be interpreted in terms of a chosen predictability model  everything between those two end-points is degrees of unpredictability    degrees of non-determinism     Most real-time systems  namely  soft ones  have non-deterministic predictability  for example  of the tasks  completions times and hence the values gained from those events    In general  in theory   predictability  and hence acceptably satisfactory value  can be made as close to the deterministic end-point as necessary--but at a price which may be physically impossible or excessively expensive  as in combat or perhaps even in picking up your child from school    Soft real-time requires an application-specific choice of a probability model  not the common frequentist model  and hence predictability model for reasoning about event latencies and resulting values   Referring back to the above list of events that provide acceptable value  now we can add non-deterministic cases  such as   the probability that no task will miss its deadline by more than 5  is greater than 0 87   Note the number of scheduling criteria expressed in there     In a missile defense application  given the fact that in combat the offense always has the advantage over the defense  which of these two real-time computing scenarios would you prefer    because the perfect destruction of all the hostile missiles is very unlikely or impossible  assign your defensive resources to maximize the probability that as many of the most threatening  e g   based on their targets  hostile missiles will be successfully intercepted  close interception counts because it can move the hostile missile off-course   complain that this is not a real-time computing problem because it is dynamic instead of static  and traditional real-time concepts and techniques do not apply  and it sounds more difficult than static hard real-time  so you are not interested in it    Despite the various misunderstandings about soft real-time in the real-time computing community  soft real-time is very general and powerful  albeit potentially complex compared with hard real-time  Soft real-time systems as summarized here have a lengthy successful history of use outside the real-time computing community   To directly answer the OP question   A hard real-time system can provide deterministic guarantees   most commonly that all tasks will meet their deadlines  interrupt or system call response time will always be less than x  etc    IF AND ONLY IF very strong assumptions are made and are correct that everything that matters is static and known a  priori  in general  such guarantees for hard real-time systems are an open research problem except for rather simple cases   A soft real-time system does not make deterministic guarantees  it is intended to provide the best possible analytically specified and accomplished probabilistic timeliness and predictability of timeliness that are feasible under the current dynamic circumstances  according to application-specific criteria    Obviously hard real-time is a simple special case of soft real-time  Obviously soft real-time s analytical non-deterministic assurances can be very complex to provide  but are mandatory in the most common real-time cases  including the most dangerous safety-critical ones such as combat  since most real-time cases are dynamic not static    Firm real-time  is an ill-defined special case of  soft real-time   There is no need for this term if the term  soft real-time  is understood and used properly   I have a more detailed much more precise discussion of real-time  hard real-time  soft real-time  predictability  determinism  and related topics on my web site real-time org

User · Answer

Hard Real-Time     The hard real-time definition considers any missed deadline to be a system failure  This scheduling is used extensively in mission critical systems where failure to conform to timing constraints results in a loss of life or property     Examples     Air France Flight 447 crashed into the ocean after a sensor malfunction caused a series of system errors  The pilots stalled the aircraft while responding to outdated instrument readings  All 12 crew and 216 passengers were killed  Mars Pathfinder spacecraft was nearly lost when a priority inversion caused system restarts  A higher priority task was not completed on time due to being blocked by a lower priority task  The problem was corrected and the spacecraft landed successfully  An Inkjet printer has a print head with control software for depositing the correct amount of ink onto a specific part of the paper  If a deadline is missed then the print job is ruined      Firm Real-Time     The firm real-time definition allows for infrequently missed deadlines  In these applications the system can survive task failures so long as they are adequately spaced  however the value of the task s completion drops to zero or becomes impossible     Examples    Manufacturing systems with robot assembly lines where missing a deadline results in improperly assembling a part  As long as ruined parts are infrequent enough to be caught by quality control and not too costly  then production continues  A digital cable set-top box decodes time stamps for when frames must appear on the screen  Since the frames are time order sensitive a missed deadline causes jitter  diminishing quality of service  If the missed frame later becomes available it will only cause more jitter to display it  so it s useless  The viewer can still enjoy the program if jitter doesn t occur too often      Soft Real-Time     The soft real-time definition allows for frequently missed deadlines  and as long as tasks are timely executed their results continue to have value  Completed tasks may have increasing value up to the deadline and decreasing value past it     Examples    Weather stations have many sensors for reading temperature  humidity  wind speed  etc  The readings should be taken and transmitted at regular intervals  however the sensors are not synchronized  Even though a sensor reading may be early or late compared with the others it can still be relevant as long as it is close enough  A video game console runs software for a game engine  There are many resources that must be shared between its tasks  At the same time tasks need to be completed according to the schedule for the game to play correctly  As long as tasks are being completely relatively on time the game will be enjoyable  and if not it may only lag a little       Siewert  Real-Time Embedded Systems and Components  Liu  amp  Layland  Scheduling Algorithms for Multiprogramming in a Hard Real-Time Environment  Marchand  amp  Silly-Chetto  Dynamic Scheduling of Soft Aperiodic Tasks and Periodic Tasks with Skips

User · Answer

Maybe the definition is at fault   From my experience  I would separate the two as being hardware and software dependant   If you have 200ms to service a hardware driven interrupt  that is what you ve got  You stick 300ms of code in there and the system isn t broken  it hasn t been developed  You ll be switched out before you ve finished  Your code doesn t work or is not fit for purpose  Many systems have hard defined processing periods  Video  telecoms etc    If you re writing an application that s real-time  this could be considered soft  If you run out of time you could hope for less load next time  you could tune the OS  add some memory or even upgrade the hardware  You have options   To look at it from a UX perspective is not helpful  A Skoda might not be broken if it glitches  but a BMW sure as hell will be

User · Answer

The definition has expanded over the years to the detriment of the term  What is now called  Hard  real-time is what used to be simply called real-time  So systems in which missing timing windows  rather than single-sided time deadlines  would result incorrect data or incorrect behavior should be consider real-time  Systems without that characteristic would be considered non-real-time    That s not to say that time isn t of interest in non-real-time systems  it just means that timing requirements in such systems don t result in fundamentally incorrect results

User · Answer

Hard real time systems uses preemptive version of priority scheduling  so that critical tasks get immediately scheduled  whereas soft real time systems uses non-preemptive version of the priority scheduling  which allows the present task to be finished before control is transferred to the higher priority task  causing additional delays  Thus the task deadlines are critically followed in Hard real time systems  whereas in soft real time systems they are handled not that seriously

User · Answer

Hard real-time means you must absolutely hit every deadline   Very few systems have this requirement   Some examples are nuclear systems  some medical applications such as pacemakers  a large number of defense applications  avionics  etc   Firm soft real time systems can miss some deadlines  but eventually performance will degrade if too many are missed   A good example is the sound system in your computer   If you miss a few bits  no big deal  but miss too many and you re going to eventually degrade the system   Similar would be seismic sensors   If you miss a few datapoints  no big deal  but you have to catch most of them to make sense of the data   More importantly  nobody is going to die if they don t work correctly   The line is fuzzy  because even a pacemaker can be off by a small amount without killing the patient  but that s the general gist   It s sort of like the difference between hot and warm   There s not a real divide  but you know it when you feel it

User · Answer

A soft real time is easiest to understand  in which even if the result is obtained after the deadline  the results are still considered as valid   Example  Web browser- We request for certain URL  it takes some time in loading the page  If the system takes more than expected time to provide us with the page  the page obtained is not considered as invalid  we just say that the system s performance wasn t up to the mark  system gave low performance     In hard real time system  if the result is obtained after the deadline  the system is considered to have failed completely   Example  In case of a robot doing some job like line tracing  etc  If a hindrance comes on its path  and the robot doesn t process this information within some programmed deadline  almost instant    the robot is said to have failed in its task  the robot system may also get completely destroyed      In firm real time system  if the result of process execution comes after the deadline  we discard that result  but the system is not termed to have been failed    Example  Satellite communication for enemy position monitoring or some other task  If the ground computer station to which the satellites send the frames periodically is overloaded  and the current frame  packet  is not processed in time and the next frame comes up  the current packet  the one who missed the deadline  doesn t matter whether the processing was done  or half done or almost done  is dropped discarded  But the ground computer is not termed to have completely failed

User · Answer

It s popular to associate some great catastrophe with the definition of hard real-time  but this is not relevant   Any failure to meet a hard real-time constraint simply means that the system is broken   The severity of the outcome when something is labelled  broken  isn t material to the definition   Firm and soft simply fail to be automatically declared broken on failing to meet a single deadline   For a fair example of hard real-time  from the page you linked      Early video game systems such as the Atari 2600 and Cinematronics vector graphics had hard real-time requirements because of the nature of the graphics and timing hardware    If something in the video generation loop missed just a single deadline then the whole display would glitch  which would be intolerable  even if it was rare   That would be a broken system and you d take it back to the shop for a refund   So it s hard real-time   Obviously any system can be subject to situations it cannot handle  so it s necessary to restrict the definition to being within the expected operating conditions -- noting that in safety-critical applications people must plan for terrible conditions   the coolant has evaporated    the brakes have failed   but rarely  the sun has exploded     And lets not forget that sometimes there s an implicit  while anybody is watching  operating condition   If nobody sees you break the rules  or if they did but they die the fire before telling anyone   and nobody can prove that you broke the rules after the fact  then it s kind of the same as if you never broke the rules

User · Answer

real-time - Pertaining to a system or mode of operation in which computation is performed during the actual time that an external process occurs  in order that the computation results can be used to control  monitor  or respond to the external process in a timely manner   IEEE Standard 610 12 1990    I know this definition is old  very old   I can t  however  find a more recent definition by the IEEE  Institute of Electrical and Electronics Engineers

[real-time] Differences between hard real-time, soft real-time, and firm real-time?

Examples related to real-time

Examples related to hard-real-time

Examples related to soft-real-time

Examples related to firm-real-time