What is Embedded and RealTime OS?

I have heard it many a time and have only a vague idea. When I try google, it throws the usually references to the term Embedded OS at me.

Usually, the term describes the OS that silently runs behind hundreds of small eletronic devices that we use regularly in our daily life.

Take for example - Cell Phones, PDAs, the cool multi-utility digital wrist watches - all of them have some form of OS, helping them function. The concept is rather new in computing terms - as now most of these devices come with extra storage allowing you to download and run external applications written for such OS-es, thus extending the functionality of that particular device.

It's like a miniature model of our larger desktop systems, except that such devices are devoid of most of the peripherals and other paraphernalia that are associated with the larger desktop systems. Naturally, there's a massive storage space constraint, and these OS-es have to be specially written to be immensely extensible and yet work stably under such constraints. The term "embedded" most probably rose out of the fact that in most cases these OS-es are hard-coded into some sort of a chip, thus eliminating the need for a separate storage space for them. Whatever extra space you have is reserved for applications to be downloaded in future.

Embedded OS-es have given rise to a very competitive market with new variations and offshoots being announced everyday. Just a couple of months back I'd read somewhere about IBM announcing the first successful port of Embedded Linux on a wrist watch. Just google around and you'd find plently of articles on it.

As for your other query, Realtime OS-es are supposed to be the ones with immense number crunching power, but so lightweight and compact that they can be fit on most of such small devices, specifically some sort of a microcontroller. The idea behind realtime OS-es is to issue instructions based on a continuous feedback cycle. Take for example, a missile which has been launched. It would need to gather all kinds of data about the atmosphere it's sailing through - air density, speed, direction etc. plus it's own velocity and perform instantaneous computations to figure out whether it would hit the target correctly or not. If not, what could it to (send out a puff from one of the boosters, adjust the tail fin angles.. etc) to correct its speed and direction. RealTime OS-es are primarily finding application in military technology - but that's just one side of it. They've been employed for much more peaceful purposes too..

Have you ever wondered, how a train in the subway always comes and stops exactly at the right spot and and align it's doors with the markings on the platform with hair-splitting accuracy ?? That's the work of realtime OS. As the train (whatever speed it might be travelling at) pulls up near the station, a bunch of speed sensors start transmitting data to the trains RTOS informing it about how much time it has during which it has to reduce its speed to ZERO in order to do the perfect lineup.. and the train, whether its travelling faster or slower than the designated speed, to everyone's wonder, invariably always lands up at the right place

Regards,
m^e

Thanks for that m^e. Seems I was far from the truth. I thought they were similar, and ran like a background process on an existing OS, like a live-view OS.

I dint quite get the explanation. In my understading the real time operating systems were all about application execution time predicability, that I can say the time on execussion of a routine with no error (other than the clock drift of the processor ). I never though of feedback concept in a real time OS like you explained above. I'll have to thing a litle bit more a about this but it promisses to be a good discussion (just like we like it)

Regards,
electrfunch

Hello all,

As electrfunch stated that,
"The idea behind realtime OS-es is to issue instructions based on a continuous feedback cycle"

its true, not in the context that it has to do all the time, but it is designed in order to respond to events as fast as possible and nearly all of then which occur.
Now an RTOS can be embedded into a time critial environment where feedback is critical for its operation, so it needs to respond to it, quick

Speaking of RTOS...I keep hearingthat you can get a free copy of QNX RTOS from QNX, as long as it's intended for non-commercial use, but I've had a hard time finding this. Can anyone point me in the right direction? I've never used an RTOS before.

I think they stopped dishing out the free download. The last copy I had grabbed was of Version 6.5 and ever since even I've failed to locate the download link. You go to their site, do all the signup bull$shit and get your login activated.. and... NO DOWNLOAD LINKS anywhere !!!! .. WTF ?? Unfortunately I don't have enough space online (nor a good enough internet link) - or else I'd have dumped the .iso for you somewhere. It's quite fast although I never figured out the RTOS functionality in it. It looks just like another linux/feebsd variant - but with a very tightly integrated and stable windowing system they call "Photon GUI".. very nice and classy.

Hi there,

I do not completely agree with those statements. Actually, RTOS are OSes that have a predictable behaviour (in advance, before lauching the system) in a system for a given payload, basically for that given payload all the tasks are processed "in time". With that "in time" I mean that the response is given at least before the response is useless.

What this means? Let's take an example: humm, Let's suppose I have a system for deploying a canopy in response to the sunlight. The engine that deploys the canopy has a time to start of 5 secs. And the time for the total deployment of the canopy is 30 secs. My OS should make a response as soon as 35 seconds. That is the deadline time. That's not so fast! But anyone could argue that is not a critical task... ok, you're right!

Let's take another system with more critical tasks: An aircraft system. In that system, many items can be taken into account: from less critical, as the air conditioning for the crew and passengers, to highly critical, as the control of the engines inflight, for example. Checking the engines is a hihh priority task with a very short time-cycle (checking is done thousand times a second), however the adjustment of the engine cannot be done so fast, because of the response of the engine (in some cases, the engine takes some seconds to response to a given input). That means that if there is a very high payload that degrades the system, some deadlines will not be reached in time. In those cases, low priority tasks are delayed; then, high priority tasks devoted to "read" sensors, if they are allowed to do so, reduce their period, or just some data are missed... for example, in the case of the checking of the engines, if the response time is several seconds, we could manage to fly checking once or twice a second (obviously with a reduction of the security, but not to a critical point).

In other cases, the "fast" response is not directly connected to a short period. For example, in a photo-Satellite (that is a satellite which makes photos in a given position in a route along the Earth), we could decide to take a photo in a particular position. The satellite will be reach that position in, let's say, 24 hours: 15 minutes: 30 seconds. That's a CRITICAL deadline! It will be scheduled and many other events and tasks will ocurr between this time and that deadline...

So the term "quick" is inaccurate by nature. I would use the term "just in time" or "by the deadline".