embedded Vs Realtime

You seem to be under the impression that something isn't real-time if it's done by 100 clerks using PCs. From this I can only conclude that you have somehow gotten the definition of "real-time" wrong. I suggest that you start listening to the many people who are telling you that payroll is indeed real-time rather than arguing with them. Real-time is about deadlines, not methods.

If that is your criteria, most of us have never built a real-time system. Real-time means late=failure. Th failure doesn't have to be bankruptcy.

An airline ticketing system that fails to get any tickets into the hands of willing buyers before the airplane takes off is a failure, which makes the airline ticketing system hard real-time.

Real-time is not the same as "Real Fast."

Neither is late fire service. The Phoenix Fire Department has an average response time was 4 minutes, 56 seconds. They would love to get to every fire in one or two minutes, but is getting to a fire in seven minutes a "disaster?"

How about if your paycheck is over seven years late? (This actually happened to me; an employer went belly up and missed the last payroll, and seven years later a court sent me a check for te cents on the dollar with a promise of more if they found any other assetts. I am still waiting after twenty years...) Would that be a "disaster?" The definition of real time does not include "disaster." It includes "failure." The definition of "failure" is for the person buying the real-time design to decide.

Most batch systems I've worked with were all about time and time limits and deadlines and priorities, etc. Very real-time, but at a macro level.

Quite a lot of real-time systems don't result in disaster or total failure if time constraints are missed occasionally. Ie, the time division MAC protocol slot is missed and I lose a short sequence of packets, but things are resent and the network resynchronizes.

Nice one. Q: How do you decide if a system is real-time A: What happens if it's not ?

After that is decided, the exponent used to measure the time is secondary. Oscar Wilde is said to have made a similar point years ago ....

-jg

If it has a deadline that, if missed, constitutes a failure.

Q: What is a failure?

Ask the person paying for the real-time system. It's his call.

Failure recovery. This could be as simple as trying again or as complicated as evacuating a city and pouring concrete over the smoking, radioactive crater.

Indeed. I once worked on a real-time heater that kept the wax in a tank hot enough to be liquid but not hot enough to vaporize and catch fire. We figured that the deadline for responding to the temperature-too-high signal was well over eight hours and the deadline for responding to the temperature-too-low signal was well over ten hours. The too-hot condition was a very, very hard deadline. For the heaters to go on and stay on for even four hours would have required failures in the control system and six different emergency cutoff systems that measured with six technologies (Bimetallic contact, thermistor, thermocouple, excessive fuel use, IR, meltable link) and which shut off the heaters by cutting off the fuel (four valves in series, all from different manufacturers and using a variety of technologies) dumping the fuel into a holding tank, and cutting off the air to the heaters. In addition, the operator manually checked the temperature once per hour, and the security security guard checked another temperature gage during his rounds. And we had a couple of really loud sirens.

Real-time? Yes, Fast? No.

I guess that it all boils down to your definition of failure. In my earlier (first on this topic) post I did state that I consider time itself to totally unreal (it is decidely warped and kinked). So, now we can get down to the real issuea;

what is the difference between a failure and an inconvenience. what is so disasterous about an inconvenience. if a single point failure is so much of a problem wouldn't you iinvest in back-up systems or mitigation procedures.

Now, I know that Guy knows me over a large number of years through this and other fora. I never claim any expertise in realtime systems just in the High Integirty Embedded Systems area. In that world time is just another event that happens. I get more concerned with whether or not my systems behave despite un-expected stimuli.

Yes. Others have given this a try so let me.

Embedded systems are dedicated rather than general purpose.

Realtime systems have to deal with events that happen in real time. A program that reads a file in one format and creates a new file in a different format might be run whenever. The original file isn't going to go away. (Well let's assume it is archived and backed up.) So the program can run whenever someone wants to run it.

On the other hand, a program that receives a serial message over a wire has to deal with events that happen in real time. If the machine is turned off when the message gets sent then the message is lost. Oh sure there may be some buffers somewhere in the system that ease the timing demands of the real time program, but the events happen in real time.

If a program is suppose to read keystrokes and respond within the time that a user will accept then it has to deal with events in real time. Sure there might be some buffering in a processor, or there might not. If the computer is running another program and there is no buffer it will miss keystrokes and fail to do its job.

The timing demands may be relatively easy to meet or very tight. Most computers can deal with keystrokes at a human typist speed. (Of course some time in the past people were warned that if they wanted to use MS Word on a Mac that they needed to get a 68030 machine because using that software a 68020 was too slow to keep up with a fast typist. ;-)

If a program is receiving and decoding radio signals the events may come and go away in real time on the order of a few hundred picoseconds or less. If the computer is away doing something else they are lost.

Realtime means things will be lost if not processed when events actually happen. Embedded means dedicated and although most people associate them with the billions of tiny embedded processors very large computers have also been used as dedicated/embedded processors. The term embedded comes from being 'inside of' and we tend to think of the tiny computers inside of so many things today that serve a specialized rather than general purpose function.

Best wishes

You are conflating concepts.

"Real time" means the result must occur within a defined time window - in some situations "too soon" is just as wrong as "too late". The definition of "real time" does not take into account the penalties for missing the window, it only stipulates that missing the window is a failure.

The penalty for failure generally categorizes a real time system as "hard" or "soft". "Hard" real time systems have no use for the result if it does not appear within the specified window. "Soft" real time systems aim to have a result within a specified window, but if the window is missed the result *may* still have value. Many soft systems are really a mix of hard and soft in which an "ideal" soft window is embedded within a larger hard window. Then there are the really soft systems where the answer is valued even if can't be used (logged for posterity maybe).

Discussions of "inconvenience" and "points of failure" are simply not relevent. Inconvenience is in the eye of the user and not for you to determine. Whether any particular "failure" mode counts as critical to the system is an orthagonal concept having nothing to do with whether the system is real time.

George ============================================= Send real email to GNEUNER2 at COMCAST o NET

Is the paycheck invalid or useless if it is printed one day late ?

In that case it would be hard real time.

Paul

By your definition practically every system can be declared real time.

If you are running an ice-cream shop on a hot summer day and a lot of customers are queuing up trying to buy an ice-cream. After waiting for a while and the queue does not seem to move fast enough, the potential customer decides that the ice-cream is not worth the wait and leaves the queue and you have lost a customer.

This is clearly a time related failure, but is it real time for that ? The basic problem in this case is the _average_ throughput (customers/minute) than the longest serving time of an irresolute customer trying to decide what to buy.

Paul

That's for the person who purchases the real-time system to decide.

The basic concept is this; whether a deadline makes sense, whether missing a deadline is a failure, and where to set the deadline are not decisions that an embedded systems engineer makes. They are customer requirements. Yes, we all negotiate customer requirements along with other factors, but in the end the customer decides, just as he decides how much he is willing to pay and how long we have to do the job. (We, of course, then decide whether to take the job and possibly suggest alternative requiremnts, cost and schedule that would result in us taking the job.)

If you do not have a penalty for missing the window, then the deadline is simply a arbitrary value.

One example would be a polled non-FIFO UART receiving characters in an unidirectional link at 9600 bit/s. The UART must be polled at least every 1 ms, otherwise, the next character will overwrite the unprocessed character. That would be a hard real time system.

However, if for some reason, the specification calls for 0.5 ms poll cycle, but missing this (but staying within 1.0 ms) would have no ill effect. Is this 0.5 ms a soft real time deadline or just an arbitrary value ?

Paul

If you settle on a maximum allowable wait time and write that into the spec, then you're specifying a real-time system.

Most document prep systems are non-real-time. Payroll is an exception because of the "time is of the essence" contracts and laws that have grown up around it.

On the computerized concert organs I worked on, keyboard scanning was soft real-time: occasional missed timing would affect the music, but people would usually accept the result. The system that dumped dozens or hundreds of kilobytes of config information out the MIDI port was non-real-time: you didn't start it unless you knew you could spare the minute or so it would take. The system that reloaded that config information was hard real-time: if a new block came in while the EEPROM was still updating stuff from the last block, you had a mis-configured organ.

Regards. Mel.

Possibly. It may mean that the company who didn't get the check sent out is in breach of a contract and subject to penalties, leins, etc.

Not really. It is merely probing what others are really thinking when they speak on this subject. The definition of "real time" has always seemed a tad wooly to me. Now, through all this discussion I can see that there are those who are trying to firm it up somewhat. Keep going and I am sure we will end up with a much better definition. Be prepared for the scope of that definition to become more encompasing of other aspects though.

Now, with my idea that time is just another event, what a real time system has to guarantee to not miss any events. In the broader context, this is events on a wider scope than just time events.

I can deal with consequences as part of an event/consequence risk assessment tree. It would be wrong to be hung up on just time factors. You need to assess the system over much wider risk areas than just time.

We are, for the most part, building systems for our clients and you are correct that the failure criteria are for the customer to define. However, I had hoped that someone who thought that the timeliness criteria was of utmost importance would have been able to have produced a better definition for failure in their terms.

I know of only one way to analyse systems failure criteria which is from a broad based assessment of all hazards and risk factors. I then develop whatever mitigation mechanisms are required to ensure that the level of risk is kept as low as is reasonably practicable.

I have a customer with a 3-axis servo system controlled by an industrial pentium PC with Windows NT (real time extension) with vision software, ethernet etc. They also call this embedded because it is embedded in their machine. This is the future by the way: many MB's of code in machines, also in simple machines.

A system with predictable timing is called "deterministic".

Real time means that is reacts fast enough to control your process.

Pieter

Either that or (the way most would write it) the UART Interrupt's ISR must complete the processing of each received character within one millisecond of it being received.

That sounds like an arbitrary value specified by someone who doesn't know much about engineering, overspecifying the system to "make sure" it will work at his/her own, less stringient specs. "We'll tell the engineers that the bridge must take a 10 ton load so that we can be SURE it will take the 5 ton load we need it to take."

-----