What is the difference between embedded system and real-time system?
February 23, 2010 14 Comments
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.