What is the difference between embedded system and real-time system?

As a first incomplete answer I would say that real-time systems are an important subset of embedded systems. Generally speaking any real-time system is also an embedded system, as well as any RTOS is considered to be also an embedded OS.

Now, the second point would be to define an embedded system and afterwards to trace a line in between real-time systems and rest of embedded systems.

Embedded systems…. what are they? I read many columns and articles on the Internet claiming that it is more appropriate to say which “piece of computing” is NOT an embedded system.

Actually around 90% of microprocessors are manufactured for the embedded industry, so AMD and Intel cores found in our notebooks or desktops are just the tiny top part of the iceberg.

Clearly all kind of PC’s, ranging from desktops, to servers, to notebooks and so on, are not embedded systems. All of those are general purpose computers serve for browsing on the Internet, for audio/video streaming, for text editing, for performing sophisticated math computations and many, many different and complex tasks. Another thing which can be said about PC is that they rarely interact with the environment, usually they receive inputs from the user, via the keyboard, or from another computer via a LAN card.

If I have to characterize in a few words the embedded systems, I would say that they are small, built for a special purpose, very efficient in performing the task those are built for (an embedded system can largely perform better on their dedicated task than PC counterparts) and they rarely need an external intervention (once they start their job they do it for a long time and they do it very well).

Examples of embedded systems are countless: MP3 players, smart-phones, GPS’s, anti-lock braking systems, security alarms, LAN routers, airplane autopilot systems, nuclear power-plant control systems and the list may endlessly continue.

Among embedded systems it can be distinguished a class of devices which have to accomplish “serious tasks:) Those are designed to compute just a very limited number of tasks (usually they can be called single purpose computers), but they have to compute them very well and they have to provide results now– and I have to stress those last words. Computing very well a task means to compute it or to resolve it in a limited or preductable amount of time. Those are the real-time systems.

In case of an application built for desktop PCs, this can have often random responsiveness delays. It is very common the case when you’re sitting in front of your computer and just wait for an application to start. Sometimes it can start slightly earlier sometimes it starts harder. Such behavior is not acceptable in the real-time world, actually this is the very nature of an embedded application (but also of an board support package – embedded hardware + corresponding low level drivers and initialization code) – to have predictable time response.

But remember: this predictable deadline has nothing to do with speed. The response has to be within a known limited amount of time, even this is a microsecond, an hour, a day or a month.

There are two categories of real-time systems: hard and soft real-time. This categorization left room for many misuderstandings: Is it hard real-time computing the same as high performance computing? is there any difference between soft real time and rest of embedded systems which are not usually considered real-time? Is it soft real time less important than hard real-time?

It is very important to highlight the main difference hard and soft real-time: in case of hard real-time systems the tasks have to be executed in known amount of time otherwise, if this deadline is overpassed, the system may crash and serious damages may be produces often affecting humans lives. In case of soft real time this is not the case, some tolerance is admitted. Electronics that control critical systems, as a car or an airplane, systems which human lives depend on, are considered to be hard real-time. Let’s take the example of the electronic anti-lock brake system if this fails this may have serious consequences, same thing applies to the electronics that control arirplane’s guidance or direction, no one will like to get lost when travelling by airplane.

The most known category of soft real-time systems consists in audio/video streaming systems. It is important to get a piece of image or sound on time, but if this does not happen some tolerance is accepted. Nobody will die if the quality of the sound that you are receiving on your phone is poorer, the system can also continue to operate.

Hard real-time systems, even they have a very high level of fiability, they have drawbacks. They are very inflexible and they are more resource expensive than their soft counterparts. On the other hand soft real time systems trade predictability for efficiency. They can easily adapt to system changes, are less resource consumpting and can smoother tolerate overloads.

So do not necessarily think that hard real time systems have a much higher degree of performance than soft ones. They just are more tuned on certain critical applications.

Non-real time embedded systems are not time bounded. They keep the embedded characteristics as little or no user intervention, they are small (small memory, limited number of peripherals), they execute a limited number of tasks. Just imagine a weather station places somewhere where human presence is less accesible. This system is built just for one single thing: read information from several sensors and transmit them via a network link to a base station, meaning a desktop PC. This embedded system is required to provide information just several times in a day, so it doesn’t have to continously monitor its inputs and to provide outputs on a fixed pre-established time frame.

About these ads

14 Responses to What is the difference between embedded system and real-time system?

  1. Pingback: Saving the World, One Laptop at a Time – Voice of America : World online computer review

  2. kellogs says:

    Good reading. What can you make of this point of view – hardware does not really matter, it is just a matter of how that hardware is used in order to categorize it appropriately. Think about a regular windows kernel. Of course, in user space you can get bored in front of the computer until it launches your app successfully, but in kernel mode, a microsecond is always a microsecond, no matter what. You just need to take care not to start up encrypting anything during an ISR. For instance, if you move the mouse as fast as possible and have the mouse ISR output the time elapsed from its previous call, you will see some ~ 2500 microseconds resolution (2547 if I am right). No matter what the system load is.

    I have to argue on smartphones – these are not embedded devices, even if they are built around ‘embedded’ ARM processors. Really, the differences between RISC and CISC are next to zero nowadays. Especially between ARM and x86 – complexity-wise. Oh, yes, dumbphones that can only make phone calls and write SMSes – these are embedded systems indeed.

    • Thanks for the appreciations and also for the intervention on this blog!
      I cannot say that I fully agree you. Why do you consider smartphones not being embedded devices? I remember that I had some discussions with some workmates also I was reading some web-columns and virtually every attempt to define and embedded system was sticking to two features: size (embedded systems are small and do not require user intervention). Smartphones perfectly fit first definition, which I consider far from being a professional one, but a correct one, and also they match with second one, just imagine how many times a smartphone user needs to update/reinstall his OSes or how many times does he need to make software developement directly on them (if they were not embedded systems all mobile software development would be done directly on target).
      BTW: target – host pair I think is one of the embedded systems mantra :) as long as it will be required, you can bet that you’re doing embedded programming

      PS: I didn’t get the part with mouse’s ISR…

  3. kellogs says:

    Hi,

    >>size (embedded systems are small and do not require user intervention).

    agreed

    >>Smartphones perfectly fit first definition

    agreed again

    >>and also they match with second one

    nah-uh. Okay, so maybe the programming directly on target example is a good point (carefully chosen :D) – google after the ‘M’ programming language. It comes with an IDE installable on a symbian device. Rofl.

    Ok so no one will actually use it / has actually used it. I am regarding smartphones nowadays as minicomputers. You can do lots with them. GPS routing, voip calls, lot of calculations generally. Even play quake on them. They are definitely not those ultra-specialized devices they used to be. And yes, they do require user input for that matter – lots. As opposed to dumbphones which can only do a couple of things. Such as dialing a phone call and receiving a phone call. Uhm, and I think that the OS does not really have to be reinstalled / upgraded all the time on x86.. unless you are a tech-freak :)

    • kellogs says:

      Hmm…

      >>>>Smartphones perfectly fit first definition

      >>agreed again

      Actually, I think they will stop making such devices with screens smaller than 3″ quite soon.

    • kellogs says:

      Oh, and as for the mouse ISR example – I only wanted to argue about windows kernel being perfectly able to guarantee a time resolution of ~2.5 ms no matter what.

    • you really got me with this M language, but it seems that it is a quite of niche programming language, just to quote you “no one will actually use it / has actually used it.”
      the fact that smartphones are mini-computers (…or I would like more to call them pocket-PCs :)) is definetly true … I do not know what to think about their “relationship” with the “embedded world”. I can say that I am / or at least I was, a pretty big fan and reader of embedded.com (probably the most notorious and professional web-portal about embedded) and I never saw a single column/article about smartphones
      On the other hand it is quite difficult to say about someone writing code for smartphones that is an embedded programmer, I do not think he deals pretty much with stuff like PLL, SPI, PWM, bootloaders (maybe this one is not so far from the smartphones world) which are the ground basis of embedded programming, I would dare to say, on the other hand many embedded programmers that I know do not deal with upper-layer stuff, as GUI programming or game programming
      I ended up in defining embedded system via the embedded programmer profile :)

  4. kellogs says:

    I think the embedded programmer dives that deep because there is no user space in the RTOSes, or even worse, many times an embedded device doesn’t even have an OS. Of course mobile programming nowadays takes care of all these in their kernels, while developers usually only need to concern about the user space.

    Well, I think I have made you regard the smartphones as non-embedded. Horey!

    • I think the embedded programmer dives that deep because there is no user space in the RTOSes, or even worse, many times an embedded device doesn’t even have an OS
      well … right! but I think this is getting the duscussion back to my statement embedded systems (and I think we can consider this as part ot their definition) have far less or no user inter-action, when compared to PC workstations

      smartphones = non-embedded devices … well, well … I would not bet you completely made me have this view

      let’s tackle this differently … do you think any real time system can be consider as an embedded system? if yes, well just “wikipede” for Soft real time systems and you’ll find that

      Live audio-video (smartphones are quite fitting this example) systems are usually soft real-time; violation of constraints results in degraded quality, but the system can continue to operate.

      besides this … almost every Symbian book that I read stressed that Symbian is running on real-time systems

      … and I am still stuck to host-target paradigm, which may replace embedded-system’s definition. The example with the M language and the IDE that comes with, is quite of niche

      … but, this time you owe me an answer :)
      you still did not answered if you really consider that Nokia gonna let Symbian die, they were the biggest shareholder at ex-Symbian OS owner, Symbian Ltd., they really put some money into this SW platform and it is hard to predict that they will abandon it soon
      in addition Symbian along with its developing tools (SDK+IDE), is free, is 100% open-source, this will encourage virtually anyone to pick it and to start writing SW for it (and I think this is a quite important thing, since license costs are a quite big slice from projects costs, especially in those times) … based on this I really regard Symbian (and Android also) as really having a really big advantage on the smartphone SW battleground (the two are actually predicted to be the leaders in 2-3 years)

      the rest …. Apple relies too much on Steve’s genius and they really have to reconsider their relationship with Adobe (I mean .. it is really akward that iPhone does not offer native support for flash movies) and WM … you know better …

  5. kellogs says:

    >>in addition Symbian along with its developing tools (SDK+IDE), is free, is 100% open-source,

    It might be 100% open source but this does not mean that if I wanted to write some driver for the phone that 10 million users currently hold in their hands I would not have to go through all the symbian signed hassle, and through the partener API hassle and costs. I do not care whether it is 100% free as I am not going to put symbian on my own hardware and start selling those symbian flavoured devices.

    Android did this at the right time. They had the momentum, Symbian didn’t catch the right train. Look at the myriad of Android devices coming from Taiwan / China.
    You just tell them what you need – an x inches device, y batteries, w/o wifi, w/o blueetooth, w/o GSM etc etc. They make it and they put an OS onto it. And it is not Symbian, but Android.

    >>this will encourage virtually anyone to pick it and to start writing SW for it.

    AS previously, no! It wown’t. It would have, if they hadn’t been so damn greedy and self centered and have had done this some 4-5 years ago. They are living in the wrong century, thinking that software is an marvelous wonder of the world and we should consider ourselves lucky this piee of **** exists. Well, boom, there goes the sky! No one picks them nowadays. If someone wants to come out with a piece of hardware nowadays they hoose Android. An exception would be Samsung that came out with Bada. No lue to their reasons as they could have stayed on Android or Symbian.

    No, Nokia wown’t probably let Symbian die that easily. It still has its place in the collective memory of smartphone users. But so it does in the memory of developers. Having iPhones, Androids and Badas nowadays users tend to choose them. Little by little. HAving to choose between the same developers also tend to choose the newer platforms, but at a much higher pace. Result = few developers left for Symbian. I know Symbian. If someone new to mobile world asks me for some app for Symbian I tell that:

    - There are not that many devs for this left (there were about 4 mils in 2008, dunno now)
    - Symbian is so damn crappy that it takes 2x – 3x as much time to write an app as compared to other platforms.
    - the platform is so awful that good skills are hard to find for it.

    And then I charge him 30+ $/h. So they will be driven away from the platform as well.

    Nokia wown’t let it die, but the competition will. What they have done so far ? I dont want to recap everything, but the main points are – user experience is still not as good as Android / iPhone, and developer experience is still awful. They need to rethink the whole user space at least. Slow and small steps can be noticed – Qt for UI, developing in the cloud, much better wiki. Not enough. Tic tac tic tac….

  6. Ramyakrishnan says:

    Tabular column is better to understand

  7. miran says:

    can someone tell me the diference between realtime system and other system … but shortly plz thnx … send this to my address (miranamir90@yahoo.com) or in facebook (MiranMH) miran amir

  8. Chaitanya G Kumar. says:

    Other than Embedded systems, Real time operating systems are used any where else ?

    • Maybe at the time of writing this post me neither I did not have a clear idea about the two but in the meantime things slightly improved. I would say that embedded is more a structural denomination, it has to do more with how it looks like that system (how big is it? how independent?), and real-time is more a behavioral denomination (how does it work? how fast is it? – even if personally I do not agree with this, the first thing that comes in mind when speaking about real-time, is that it has to be a fast system). I dare to say that embedded means every computer or system that is self sufficient, that we can find it on cars, consummer electronics, airplanes, military or medical equipments and so on .. Depending on performance of that system, or better said on its requirements, it can be real-time (soft or hard real-time) or not-real time, but I think that every real-time system is exclusively an embedded sys … I cannot imagine a real-time PC (especially the ones running a Wondows OS :) ), or a server (especially due to non-real time nature of ethernet) ..
      Hope it helped!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: