Are Real time systems Hard/Soft or the RTOS itself?

[abhishekkumar1902]

I just wanted to ask if there exists anything like a "Hard-time RTOS" or "Soft-Time RTOS" itself or is it the designer who defines a system as Hard-Real-time or Soft-Real-time irrespective of the any RTOS used?

If there exists any "Hard-time RTOS" or "Soft-Time RTOS", do they explicitly specify that they are Soft/Hard? Any examples of such RTOSs?

[Kjelt]

Good question, don't know if I can answer it but will do my best.
There are hard and soft RTOS.
The main difference per definition is that a hard RTOS will always process an task within its predefined timeframe/deadline, it is fully deterministic in behavior.
A soft RTOS will on average handle the process within its predefined timeframe/deadline but it can run late on occasion.

Now this is a very vague definition since it is not only the RTOS responsibility but also the programmer. The programmer should make sure that the critical tasks that need to be performed within the predefined timeframe/deadline have the highest priority and shall never run longer than said predefined timeframe/deadline in order to prevent blocking other critical tasks to be processed.
This means that you need to analyze the pieces of software running, determine which ones are time critical and need to be executed within the predefined timeframe/deadline , measure the time these tasks need, if they are too large you should redesign and prioritize those tasks.

Now this is a simple explanation, as you can see that the predefined timeframe/deadline is the smallest part, this also depends on the hardware it runs.
If you get a twice as fast microprocessor the time of the tasks can be almost halved (never will due to overhead).

So it is a combination of the RTOS itself, the programmer/software  and the hardware.

[Benta]

Real time is real time (the RT in RTOS). That being said, there are "slimmer" RTOS that allow for shorter response times at the cost of functionality.
The decisive point is if the OS is deterministic in time, and an RTOS should fulfill this.

[tggzzz]

So it is a combination of the RTOS itself, the programmer/software  and the hardware.

Best if the RTOS is hardware, the processor has many cores, the software language (not library) has parallel constructs and communications, and the IDE knows about all of that - and can tell you exactly how many ns each code path is guaranteed to take. See the XMOS xCORE processors, xC language, and xTIME IDE. Available from digikey.

That just leaves the programmer, which is usually the weakest link. (Except for the person specifying the system, of course!)