comp.lang.ada
 help / color / mirror / Atom feed
From: Marin David Condic <condicma@bogon.pwfl.com>
Subject: Re: Processor Synchronization
Date: 1999/01/21
Date: 1999-01-21T00:00:00+00:00	[thread overview]
Message-ID: <36A73C17.64B2B79E@pwfl.com> (raw)
In-Reply-To: 36A65D72.EDED6643@west.raytheon.com

Ken Keys wrote:
> I have never seen multiple processors coupled that closely. Usually,
> processors are tied to some external event through interrupts or
> whatever. Where the events themselves are unavailable, the input data
> are given a timestamp that is referenced to some common clock--not
> necessarily a time of day clock. Sometimes this timestamping requires
> you to do some interpolation to get the data to line up as in, for
> instance, the case of merging information from a Radar sensor with that
> from an IR sensor where there are different amounts of processing delay
> and differing update rates. Besides, if the data is coming from
> something like a video raster, deciding just where in the elapsed time
> covered by that raster the data occurs requires some interpretation.

In this application, you wouldn't want to tie the processors together
with a common interrupt or clock. That creates a single point failure
and the reason for having the two processors is to minimize risk if
something breaks. 

The reason for tightly aligning both channels is because you want them
operating on essentially the same data at the same time so that if one
goes down, the other takes over and there isn't a skipped beat. When
we're reading A/Ds or F/Ds that are monitoring LVDTs or RVDTs or rotor
speeds, data can get old very fast. Loop closure on stale data can get
unstable.

> 
> Are your processors in some kind of redundant voting arrangement where
> they are executing the exact same code on the same inputs? If so, that
> probably represents a fairly specialized case. You might be able to find
> some information on that type of case in some NASA pubs.
> 
The processors are doing exactly what you describe. As to how uncommon
that is, I'm afraid I couldn't say. I know it is fairly common to go
with dual redundant systems in a number of mission critical
applications. The Ariane 5 disaster (please! not that again!) was an
example of the dual redundancy not succeeding, but that hasn't stopped
us from building them that way.

I know that tight synchronization between two or more radios is another
case. Your basic frequency hopping radio (cell phones and classified
military stuff) have to agree pretty accurately on what time it is so
that they can all change frequencies at the same time. (And that's just
about all I want to say on *that* subject in a public forum!)

It may be specialized enough that nobody has done any theoretical
research into various algorithms. I may be SOL in hoping to find
something like this. But it seemed like a good idea to ask and see what
comes up.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Airplanes are interesting toys but of no military value."

        --  Marechal Ferdinand Foch, Professor of Strategy,
            Ecole Superieure de Guerre.




  reply	other threads:[~1999-01-21  0:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-19  0:00 Processor Synchronization Marin David Condic
1999-01-19  0:00 ` Ken Keys
1999-01-20  0:00   ` Marin David Condic
1999-01-20  0:00     ` Ken Keys
1999-01-21  0:00       ` Marin David Condic [this message]
1999-01-21  0:00     ` Sune Falck
1999-01-21  0:00       ` Marin David Condic
     [not found]     ` <36a83fe3.3666942@news.geccs.gecm.com>
1999-01-22  0:00       ` Marin David Condic
1999-01-20  0:00 ` dennison
1999-01-21  0:00 ` Peter Jensen
1999-01-21  0:00 ` The Bohemian Monk
1999-01-21  0:00   ` Marin David Condic
1999-01-22  0:00     ` Tom Ziomek
1999-01-22  0:00 ` Al Mok
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox