embedded Vs Realtime - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: embedded Vs Realtime
Quoted text here. Click to load it

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

pete
--
snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas"

Re: embedded Vs Realtime


Quoted text here. Click to load it

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.


--
Guy Macon, Electronics Engineer & Project Manager for hire.
Remember Doc Brown from the _Back to the Future_ movies? Do you
We've slightly trimmed the long signature. Click to see the full one.
Re: embedded Vs Realtime

Quoted text here. Click to load it

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.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: embedded Vs Realtime
On Sun, 23 May 2004 01:47:34 +0100, "Paul E. Bennett"

Quoted text here. Click to load it

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

Re: embedded Vs Realtime
On Sun, 23 May 2004 04:31:02 -0400, George Neuner


Quoted text here. Click to load it

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

Quoted text here. Click to load it

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
 

Re: embedded Vs Realtime

Quoted text here. Click to load it

   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.

Quoted text here. Click to load it

   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."

Quoted text here. Click to load it

-----
http://mindspring.com/~benbradley

Re: embedded Vs Realtime

Quoted text here. Click to load it

Which is still useful.  Ie, a product I worked on was real-time in
most ways, but there were no hard time limits.  Instead, the more we
could reduce timing variance the more bandwidth we could produce.
The window size was arbitrary, but everyone knew that smaller was
better, and that it would shrink on successive releases.

Similarly, the "penalty" for missing the timing was arbitrary too.
A failure once an hour wouldn't be noticed without diagnostic tools,
but a failure once a second would have significant degradation of
performance.

--
Darin Johnson
    Caution! Under no circumstances confuse the mesh with the
We've slightly trimmed the long signature. Click to see the full one.
Re: embedded Vs Realtime

[%X]
 
Quoted text here. Click to load it

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.
 
Quoted text here. Click to load it

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.
 
Quoted text here. Click to load it

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.

 
Quoted text here. Click to load it

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.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: embedded Vs Realtime
On Sun, 23 May 2004 19:01:00 +0100, "Paul E. Bennett"

Quoted text here. Click to load it

I would say that the "event" model is too simplistic to describe RT -
although "event driven" is certainly one way to implement such a
system.

I prefer a transactional model for RT system because transactions
easily handle nesting and overlapping processes.  The event model
can't deal with either adequately ... by the time you add the
statefulness necessary to handle nesting and overlapping, you've
either gone most of the way to a transaction model anyway or you've
created something half-assed and very brittle.


Quoted text here. Click to load it

I get the impression (and please correct me if I'm wrong) that you
associate the term "real time" with a mind set that focuses
irrationally on time to the exclusion of other design issues.  That
could not be further from the truth.

It is proper to refer to any system which has time aspects to proper
operation as being "real time".  Such a description only implies that
time is an important aspect of the system's operation.  


Quoted text here. Click to load it

Timeliness is rarely the "utmost importance" of the system.  The
"importance" is usually described by phrases like "pace the patient's
heart", "control pressure in the reaction vessel" or even "pump bits
serially onto wire".


Quoted text here. Click to load it

The holistic approach breaks down rapidly as the number of failure
modes increases.  In a complicated system each failure domain has to
be evaluated separately and then the domain interactions must be
analyzed.


My point is this:

The engineer performing risk analysis or mitigation must understand
the concepts involved separately in order to deal with them mixed.
For example, the timing implications of a software design are
completely unrelated to the EMI risks to the hardware assembly.

An engineer dealing with a time aspect system has to understand what
RT means, both in the abstract to design and understand the system and
in the concrete to deal with actual time aspects of the
implementation.


There is a big difference between the operational understanding that
comes from working in the field and the conceptual understanding that
comes from study of the problem domain.  The two understandings
complement each other and the successful engineer needs both.  

You may not like the concept's model or terminology and you may think
people give it undue mental weight, but those are not excuses to
eschew the concept or to assume that knowledge of a broader concept
somehow obviates the necessity to know the more specific one.

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

Re: embedded Vs Realtime

Quoted text here. Click to load it
 
Would not the start and end of a transaction also be considered an event
pair. I would not say that managing transaction streams is that much of
a complecxity problem. Of course, you will realise, that my experience
revolves around the end-effector end of machine control systems. All
end efectors are monitored to prove the accomplishment of individual
tasks and I usually run several autonomous threads on each processor
dealing with specific aspects of that modules operation (Comms, Machine
Motion, Integrity Monitoring etc).

[%X]

Quoted text here. Click to load it
 
I view "Real Time" as one of those terms that has been ill-defined, over
used in the wrong context too many times and, in some cases, missing a
much more important risk factor than not performing by a deadline. It is
such that I tend to ignore the "Realk Time" aspect in my developments and
concentrate on whole system risk factors and mitigation ploicies that
will mean the whole process is still protected well enough despite any
individual failures of the system.
 
Quoted text here. Click to load it

....and at least one of those in your list implies that system
pre-knowledge of the process behaviour is more important than the time
factors. Prevention is always better than the cure once things are looking
like they are going wrong.
 
Quoted text here. Click to load it

The art of system architecture is in controlling the complexity of the
system structure and keeping sub-systems simple enough to keep such factors
well under control.
 
Quoted text here. Click to load it

More importantly the engineer must understand the process that he is
expected to develop controls for. Unless you understand the dynamics and
risk points in the process you are lacking in the information required
to do a decent design job.
 
Quoted text here. Click to load it

Letting all aspects into the melting pot actually leads you to making
some different choices that tend to assist in simplifiying the system.
Looking for system pre-knowledge opportunities will often lead to being
able to use a slower (most likely cheaper) processor than other system
engineers would normally choose.

Quoted text here. Click to load it

I am of the school that says you need to understand both the conceptual
and the actuality of the field that you are working in. That often means
not only looking at the specs but also talking to the plant operating
personnel to get their viewpoints on how they would prefer to interact
with the system. The most successful systems engineers are as much a
social engineer as they are hardware/software designers. The systems
engineer brief is a very wide arena.
 
Quoted text here. Click to load it

It is not a matter of not liking the concept. It is the realisation from
over thirty years of experience dealing with other (non-system engineering
types) who have mis-used and abused the term for so long, corrupted the
concept and let such mis-conceptions that they have coplour the way they
write their specificsation documents (but that is probably worthy of
another thread than this).

If you want to promote "Real Time" as a concept then you have to fix
that sort of long term abuse by really nailing down the definition
and then geting it well agreed. For me the timeliness of operation
of my systems will continue to be viewed from the event perspective
and performance factors revolving around the event processing of the
system and how it applies to the process/equipment that it is
controlling.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: embedded Vs Realtime
On Fri, 28 May 2004 12:29:53 +0100, "Paul E. Bennett"

Quoted text here. Click to load it

There is nothing magic about transactions - a transaction is just a
series of discrete events related by shared state.  But, unlike an
event, the transaction is, by definition, durational and lends easily
to modeling timed and time related processes.   My point is simply
that, if you start from discrete events, by the time you've enumerated
the events, defined their relationships, and defined the state
required to relate them ... you've reinvented transactions.

I do a lot of sensor, QA and QC applications that frequently have tons
of I/O and multiple compute operations going on simultaneously.  I
find it much easier to model such systems as sets of transactions
rather than as a myriad of time related events.

Again I stress "model" the system ... ie. design.  Implementation
invariably deals directly with discrete events and the state that
relates them - however, I have found that starting from the
transaction model produces simpler designs because it more clearly
identifies operations that can be elided, combined, pipelined, etc.
than does a model involving many sets of inter-related events.


Quoted text here. Click to load it

The fact that many people misuse the term is not evidence that it is
"ill defined".   According to the Oxford Dictionary the English
language has some 800,000 words in the language proper and over 1.1
million words in slang usage.  How many do you know?  Do you think the
words you don't know are not defined?  Do you think it more likely
that the words people misuse are ill defined or that the people who
misuse words are poorly educated?

I agree that the term "real time" is both over used and abused in
context.  That's a matter for better education.

Quoted text here. Click to load it

I agree that this is unacceptable.  I question, however, whether this
is because of some particular "RT mindset" or can be explained more
generally by the lack of ability to think at different abstraction
levels.  Over the years I have had to work with many people who saw
the trees but not the forest ... these are exactly the people who get
stuck on the obvious and can't get past it without help.


Quoted text here. Click to load it

I accept that because you are clearly aware of the problem and are
making certain it is dealt with - albiet in a different way than I
would.  I personally like to see risk domains enumerated separately,
but this is a personal preference - so long as the issues are
addressed adequately I am happy.


Quoted text here. Click to load it

I wasn't trying to be funny.  My point is that RT systems are more
than the sum of their time dependent code and while time is an
important component of their operation, time is almost never what they
are about.


Quoted text here. Click to load it


I think we're in violent agreement here.  We are both advocating
having domain knowledge, the ability to think at multiple abstraction
levels and to view the problem from many angles.  I'm just advocating
a more diciplinary approach and you seem to prefer a more holistic
one.  We both are trying to achieve the same end.

 
Quoted text here. Click to load it

Only 20 years here so I concede that you have more reason to be
annoyed and have a strongly held opinion.

I have a policy of correcting people when they are wrong.  If I know
the person fairly well, I may just stop and correct them on the spot.
Otherwise, I typically point out some subtle thing they overlooked and
try to work an explanation of the concept and proper terminology
involved into the ensuing discussion.  

Both approaches have been known to work on occasion 8-)


Quoted text here. Click to load it

Education is the only answer to that.  

I think there is already pretty good agreement on what RT means - at
least in the theoretical sense - and it's been documented and
discussed fairly well in a number of system and software engineering
text books.  The problem, as I see it, is that many people who work in
the field have never read any of these books.

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

Re: embedded Vs Realtime
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

No, that is another concept entirely in the realm of concurrent
processing.  That is called the indefinite postponement problem.
Still another area is that of fairness.  These all have to do with
what process is selected to run next, i.e. the scheduler.

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
We've slightly trimmed the long signature. Click to see the full one.
Re: embedded Vs Realtime


Quoted text here. Click to load it

also commonly referred to as a 'patch' / no doubt named after the thorny
ones with the berries. the poisonous ones of course.



Re: embedded Vs Realtime

Quoted text here. Click to load it

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


Re: embedded Vs Realtime


Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


--
Guy Macon, Electronics Engineer & Project Manager for hire.
Remember Doc Brown from the _Back to the Future_ movies? Do you
We've slightly trimmed the long signature. Click to see the full one.
Re: embedded Vs Realtime
Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: embedded Vs Realtime

Quoted text here. Click to load it

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


Re: embedded Vs Realtime

Quoted text here. Click to load it

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."


--
Guy Macon, Electronics Engineer & Project Manager for hire.
Remember Doc Brown from the _Back to the Future_ movies? Do you
We've slightly trimmed the long signature. Click to see the full one.
Re: embedded Vs Realtime
On Sat, 22 May 2004 15:53:06 -0700, Guy Macon
<http://www.guymacon.com wrote:

Quoted text here. Click to load it

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


Re: embedded Vs Realtime
Quoted text here. Click to load it

   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.

Site Timeline