embedded Vs Realtime

There's a difference.

What course is this for?

Casey

An embedded system is one that is dedicated to performing a function, such as making toast or adjusting fuel/air mixture or running a kiosk that helps people find information. The opposite would be a general-purpose system, e.g., a desktop computer running multiple applications.

The def> Hi,

I need to give a presentation on 'OS for embedded systems'. I searched the web for embedded, but found references for RealTime Systems like QNX.

Yes. The two concepts are orthogonal.

Sometimes they are, but doing so is a mistake.

Take a look at my webpage (see below) and then, at your convenience, give me a call. A 15 minite conversation will be enough for me to map out all of the alternatives (including the big one; no OS at all) that are currently in use for ebedded systems.

There are embedded systems, and there are real time systems, and there are realtime embedded systems. It would not be a stretch to say that the two concepts are found most often together.

Suggest you study what is embedded, and then what is realtime, then it will become obvious.

You have had some interesting responses and I have seen that you are expected to give a presentation on this topic.

Firstly, one ought to question whether or not time is "Real". Einstein has proved that it is definitely kinky or curved. What that means to us as observers I am not too sure about but it can seem pretty real and etherial at the same instant. Time remaining can certainly dissapear at extraordinarily high rates or appear to stretch into a very far flung future depending on whether one is enjoying ones self or not. For myself I have determined that time is definitely not real.

That said, and within the definitions we all usually assume on this topic, embedded systems are not always realtime systems but usually are. Similarly realtime systems may or may not be embedded.

What determines whether or not the system is realtime and/or embedded is purley down to what the application requirements are. If the application demands that the functions are performed within hard and fast time limits then the system is realtime. If the timescales are a not important then the system is not realtime.

Embedded systems are fully dedicated to the function of the equipment it is connected to. They do not allow games, or other office applications, to be run while controlling that machine equipment. Many embedded systems are also "Safety Critical" or "MIssion Critical". Some of these may also be realtime systems.

Do any of these systems require an operating system? Not necessarily. In my 30+ years I have designed and built many systems. Most of them have used no OS at all. These are certainly my most successful ones. Those that used an OS always had some problem with the uinderlying OS that needed quite in depth exploration and examination to resolve fundamental design flaws in the OS (not QNX, Linux or WinCE as these were not in the consideration mix at that time). Latterly I start from Forth as my OS and Application Specific Language development base.

Good luck in your presentation.

A common example of a non-embedded real-time system is Payroll.

Regards. Mel.

In article , Mel Wilson writes

I doubt it. Payroll used to be batch processing.

An airline ticketing system or a phone billing system is real time.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

Are you under the impression that batch systems cannot be real-time systems? A batch payroll system is still a real-time system. We tend to think of real-time systems with fixed weekly deadlines as being other than real-time, but in reality they are real-time systems with easy-to-meet deadlines that don't require the specialized techniques we use for millisecond or microsecond deadlines.

You have obviously never run a payroll system where the hardware failed before printing the checks.

If you don't consider payroll to have realtime constraints, perhaps you'd allow me to put your next six months' wages in *my* bank account, earn interest on them and then give the principal back to you? ;)

Admittedly payroll is *soft* realtime in that there is some scope for missed deadlines occasionally, but there *are* noticeable effects if the deadlines are missed!

pete

I don't

So?

Do you have any idea what happens when payroll processing isn't completed on time? All hell breaks loose.

That's more-or-less the definition of real time.

Payroll is hardly anything like real time. Unless it is done in batch mode on a mainframe it is never down to a single machine. Even for a company of 200,000 employees it equates to processing only 5,500 records per hour, a task easily accomplished by about 100 payclerks (enter hours worked, run calculation suite, print payslip, print cheque). These days, 100 payclerks will have 100 PC's networked to a central system that performs the cheque printing/BACS transfer tasks.

I would imagine that an emergency situation control room (fire department etc) will be more like a non-embedded real-time system. It will handle things like report writing as well as kicking in all the database look-up when an emergency call is received (map location info, fire hazards to be expected, key-holder info, special resource requirements all have to be at hand when the crews are despatched.

So what? What would batch processing vs. continued background handling have to do with whether its a real-time operation?

Let's recall the largely agreed definition of real-time requirements: "late results are always wrong, regardless how correct they may be." How would payroll processing fail to match that?

I'd say phone billing is less stringently real-time than payroll by a potentially large margin, because of the difference between the time a private household can delay paying its bills if the paycheck comes in late, compared to the same margin the banks will be willing to grant a multi-million-dollar phone company. And that's before you even begin to consider that phone bills will remain unpaid for several days at least, and that some of the costs charge will be a month or more old by that time, anyway --- it really doesn't matter much if you get them out a day (or even a couple days) late.

If you consider these systems real time, then they are quite soft real time. Failing the deadline just results in higher costs or some lost revenues.

For these systems to be hard real time, you would have to beforehand establish an exact deadline, if missed, would result in a bankruptcy.

Paul

I don't see what that has to do with the question at hand.

The most common definition of real-time is that a task must be accomplished by a pre-defined deadline, or it's considered a failure. Payroll meets that definition. If a company doesn't make payroll, there can be very serious consequences.

I still don't see your point. If that system doesn't get the approprate records calculated and transferred to the right destinations by the required deadline, it's considered a failure.

Yes, that's another example with different deadlines and different consequences for failure to meet those deadlines. Payroll _is_ real-time. Just because the timeframe for the deadline for completion may be days or weeks, it doesn't meet the system is considered to be operating correctly when those deadlines aren't met.

I can tolerate my pay being slightly late on occassions (and it has on more than one) but I will not tolerate the fire department not getting out to my call within reasonable time of me dfialling 999 (911 for you guys in the USA). Sure late pay is an inconvenience but it is not a disaster.

This has nothing to do with "realtime". Sure, it's not "real fast", but there are deadlines.

pete