Re: embedded Vs Realtime

From: Paul E. Bennett (peb_at_amleth.demon.co.uk)
Date: 05/28/04 

Date: Fri, 28 May 2004 12:29:53 +0100

George Neuner wrote:

> On Sun, 23 May 2004 19:01:00 +0100, "Paul E. Bennett"
> <peb@amleth.demon.co.uk> wrote:
>
>>George Neuner wrote:
>>
>>> "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.
>>
>>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 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.
 
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]

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

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

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

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

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.

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

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

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. 

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@a...>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Relevant Pages

  • Re: Long missions question
    ... general a systemic or common mode failure. ... >the probe reaches its destination. ... risk in the launch vehicle. ... There are no guarantees and they design to a failure rate that is deemed ...
    (sci.space.shuttle)
  • Re: Cost of Cockpit Instruments
    ... large they are experimental crafts with many possible points of failure. ... attitude is too extreme for the actual risk involved. ... Is it true that if COTS components were used, ... supplied components in an otherwise "well-engineered" design. ...
    (rec.aviation.piloting)
  • Re: Decoupling caps and cold failures
    ... the least risk? ... Really good design, reviewed and checked by really good engineers. ... Failure does not prove something is impossible, ...
    (sci.electronics.design)
  • Re: Do You Need to Be a Genius in Electronics?
    ... I'm an engineer because I like to design stuff. ... and I think it's one of the reasons software today tends to ... manager could really understand how much schedule/technical risk you've just ...
    (sci.electronics.design)
  • Re: embedded Vs Realtime
    ... >Would not the start and end of a transaction also be considered an event ... I personally like to see risk domains enumerated separately, ... the timing implications of a software design are ... >> An engineer dealing with a time aspect system has to understand what ...
    (comp.arch.embedded)