No. You deal with the events as events. How you decide if the*system* has failed is subject to other criteria -- unrelated to HARD or SOFT.
E.g., if you don't intercept an incoming missile before it reaches its target (hard deadline), *that* task has failed. It's not worth continuing to track and target the missile as it plows into the ground. Abandon that task. (you may have learned something from the effort that can be applied to tracking *otehr* missiles; or, you may not. In any case,*that* missile is a done deal!)
Whether missing that HARD deadline has resulted in your *system* being considered a failure is a different issue. Should you throw your hands up in the air and let any additional missiles come through uncontested? What if that *one* had successfully targeted your defensive battery? etc.
I.e., how you evaluate the system is dictated by a different set of criteria.
So, when the first SCUD got through the Patriot defenses, they should have shut down the rest of the system and started bickering over refunds??
Real systems aren't binary like that. Real systems expect some number of HARD deadlines to be missed -- each with potentially different costs/consequences/lost opportunities.
No, it *does* mean the deadline was soft (if you consider "cost" as "negative value"). That is the nature of the distinction. HARD means you GIVE UP at 0.00000001ms after the deadline has passed. You missed it. THERE IS NO VALUE TO CONTINUING.[But, the consequences of that missed deadline may range from NOTHING to THE END OF ALL LIFE AS WE KNOW IT. :> E.g., I have a deadline handler in my RTOS that is triggered when a task fails to meet its deadline. What the handler for a specific task might do can vary from incrementing a metric to invoking a scheduling optimizer that sheds some load to ensure future deadlines aren't missed]
By contrast, soft means you still have value to pursuing the goal. I.e., given infinite resources, you would give up on a missed HRT deadline but continue working on a missed SRT deadline.
Deciding when you might want to give up on the missed SRT deadline is a complicated issue, in most cases. Resources spent pursuing that goal detract from other goals being met. What value do you gain (over time) vs. the costs/risks you incur? When do you decide that the "expected value" of your gains is zero?
This is why SRT is "harder" than HRT. And, why SRT problems are most often CONVERTED to HRT problems -- because they make this decision making much easier! ("Once I am 12.3ms late on this task, I will abandon it -- AS IF it was an HRT task!") I.e., deliberately "failing", by choice (since that, presumably, allows the overall "value" of the system to be maximized)
You are confusing the system spec with the nature of the specific task that has the deadline. If your system has exactly one task to perform, exactly once, and that task has a hard deadline (i.e., once the deadline has passed, you may as well pull the plug and shut the equipment down), AND your SYSTEM SPEC is that you meet all hard deadlines, then, missing that one deadline means your system is crap.
If your system, instead, has to perform that task 100 times -- each time having an independent HARD deadline (i.e., a point in time beyond which there is no remaining value to working on that particular instance of that task) and the system spec says you must meet 50% of these, then once you have completed 50 of the tasks successfully, your *system* has met its specified requirement.
The system spec is not the same as the definition of the requirements for the individual tasks. (if there are 100 such tasks, what is *THE* deadline? I need *one* number since you can't have more than one deadline for *a* task!)
Again, damage is the wrong way of looking at it. The issue is the value of completing the task with respect to the deadline. How you map that into dollars and the remedies into similar dollars is a separate issue.
It boils down to whether or not you should even *consider* working on the problem after the deadline. If the answer is an unconditional "no" -- regardlesss of monies, costs, etc. -- then you have implicitly said that there is no value to a late answer.
OTOH, if you will consider continuing work on the task after the deadline, then you are admitting there is still some potential value to its completion and are willing to entertain a cost-benefit analysis to determine how much effort/resources you are willing to throw at the problem -- along with the possible repurcussions this may have on other tasks remaining in the system.
But you can tolerate failures! Or, *systems* can be specified to accept certain numbers and types of failures -- as per the criteria set out by the system's specifications.
The same sort of argument applies to SRT deadlines being missed. How much effort you expend trying to chase them down *after* they have passed is a judgement call that you evaluate in the context of the system specification.
No. It is still a hard deadline -- when the bottle hits the floor, the deadline has passed. It can be soft up to that point (as in my "move the picker arm" example).
If the arm can't move, then it's HRT. You approach it *as* an HRT problem. You don't "hope" you get 90% of them -- if you run the experiment indefinitely.
The events are different from the system. You apply different criteria to the system's specification than to the specification for the individual tasks that comprise it.
Jensen's real-time.org should be required reading for anyone thinking about RT work. Unfortunately, much of it reads like a text book but that sort of clinical presentation has a lot of value in nailing down the edges of these issues!