1553 bus on the C-130?

"Simon Robbins" wrote in message ...
"David Harper" wrote in message
om...
Does the C-130 have two 1553 buses onboard? One for flight control
and one for EW/mission systems?

I don't think 1553 is used for flight control since the latency and speed
isn't sufficient. Mission systems may well use it though. I think by nature
1553 is dual-redundant so that's where you might get the idea of two from.
Not familiar with the C-130 personally though.

Si

Thanks for the info. So none of the flight controls interface with
the 1553 at all? I'm just now getting familiar with Mil-HDBK-516
(airworthiness criteria) for my new job and not sure if some of the
equipment we are installing on the 1553 bus would affect/cause latency
for flight control. From what you've said, apparently that's a
non-issue then...

I guess on a non-related note, how exactly does equipment on the 1553
bus manage communications to prevent them from overlapping / "stepping
on" each other? Is there something in the data sentence once a unit
begins transmitting that puts all other equipment on "hold" until it
is done sending data? Wouldn't there be interrupts needed for
critical equipment to override less critical sentences?

Thanks again!
Dave

On 14 Jun 2004 08:56:27 -0700, (David Harper)
wrote:

"Simon Robbins" wrote in message ...
"David Harper" wrote in message
om...
Does the C-130 have two 1553 buses onboard? One for flight control
and one for EW/mission systems?

I don't think 1553 is used for flight control since the latency and speed
isn't sufficient. Mission systems may well use it though. I think by nature
1553 is dual-redundant so that's where you might get the idea of two from.
Not familiar with the C-130 personally though.

Si

Thanks for the info. So none of the flight controls interface with
the 1553 at all? I'm just now getting familiar with Mil-HDBK-516
(airworthiness criteria) for my new job and not sure if some of the
equipment we are installing on the 1553 bus would affect/cause latency
for flight control. From what you've said, apparently that's a
non-issue then...

First thing to think about is that it isn't a peer to peer networking
system like Ethernet ... it's tightly controlled by a Bus Controller.
The RT to RT (receiver transmitter) communication is handled through
command response. BC tells RT to transmit, RT needs a response from
the destination before it is sure that the message passed ok. The
latencies are reasonably strict ... The BCs can also be
multi-redundant. There's even scope for every RT to have BC
functionality (getting into gold-plate territory there).

On the flight controls - there will be data passing around the bus,
but I'd expect it to be measurement type information. IAS, Altitude,
pressure, Mach type information. I wouldn't want to see
joystick/throttle control data being passed around on 1553B. It's only
a 1MHz bus ... with performance that isn't 1Mbit/s. Just make sure
that the RTs are up to the job of buffering data.

I guess on a non-related note, how exactly does equipment on the 1553
bus manage communications to prevent them from overlapping / "stepping
on" each other? Is there something in the data sentence once a unit
begins transmitting that puts all other equipment on "hold" until it
is done sending data? Wouldn't there be interrupts needed for
critical equipment to override less critical sentences?

RTs will only transmit on a command from the Bus Controller. Each RT
has a unique ID on the network, so transmit commands are only actioned
by one RT. The transmission is done with a command - response -
senddata - response protocol that makes sure that something will
happen on command. After the end of a data transmission sequence, a
status word must be sent back to acknowledge receipt. All the bits
should be anticipating that status bit. (or they are non-compliant).

For contrast, the Ethernet protocol works on the Aloha principle.
Anything on the network can transmit at any time, collisions are
detected instead of being prevented. For a time critical bus, the
1553B command-response protocol works much better.

Unfortunately my knowledge has eroded a fair bit ... I produced a
generic model of 1553B about 6 years ago on a 3 month placement but
have only touched it once since (conditions of the placement mean I
don't own the model). I've also dropped out of contact (about 6 years
ago!) with the people I did the model for. The model is out there
though and if you have the right to see it :-) then you should be able
to track down the people in control of the model. Alternately, the
MIL-STD-1553B handbook is pretty decent, when you break into the
mindset required to read it. Just try to decode the order in which it
does things and how it does its stuff.

PS This placement is where I helped the local team in the organisation
win the cricket trophy for that year :-) I had fun in that 3 months.
Produced something of use ... and won a trophy :-)

Pete Lilleyman

(please get rid of ".getrid" to reply direct)
(don't get rid of the dontspam though ;-)

David Harper wrote:

I guess on a non-related note, how exactly does equipment on the 1553
bus manage communications to prevent them from overlapping / "stepping
on" each other? Is there something in the data sentence once a unit
begins transmitting that puts all other equipment on "hold" until it
is done sending data? Wouldn't there be interrupts needed for
critical equipment to override less critical sentences?

Collisions don't occur because the bus operates like a classroom where
the "pupils" (remote terminals) never speak unless the "teacher" (bus
controller) calls on them. It does so by transmitting a command word
with the RT's address. The command word also contains a transmit bit
in the high state and the number of words to transmit (32 words max).
The RT transmits the words, followed by a status word, then goes quiet
until it receives another transmit command.

There's no way for a remote terminal to bypass this protocol when it's
desperate for attention. The standard suggests such emergencies could
be handled with a dedicated interrrupt line to the bus controller.


Tony wrote:

The 1553B bus is, by definition, dual redundant. Each
bus has an A and B side. Data is transmitted on one
or the other - never both at the same time.

That's true for Air Force avionics, but the standard has no blanket
requirement for redundancy, does it? MIL-STD-1553B (1978) says, "If
redundant data buses are used, the requirements as specified in the
following shall apply..."

In Notice 2 (1986) a requirement for redundancy was added:

"30.2 Application. Section 30 of this appendix shall apply to all
dual standby redundant applications for the Army, Navy, and Air Force.
All Air Force aircraft internal avionics aplications shall be dual
standby redundant, except where safety critical or flight critical
requirments dictate a higher level of redundancy."

I infer from that paragraph that applications other than "Air Force
aircraft internal avionics" can use single buses.


By the way, the 1553B standard was titled "Aircraft Internal Time
Division Command/Response Multiplex Data Bus" until Notice 2 changed
it to "Digital Time Division Command/Response Multiplex Data Bus". The
language was slightly revised so it no longer sounded like the
standard was only for aircraft.

--

Paul Hirose
To reply by email delete INVALID from address.

In article , Alisha's
Addict wrote:

..

Yep - the spec allows for x-redundancy. Although you'd want to keep a
lid on the amount of redundancy :

More redundancy = more resilience
More redundancy = more bits = more cost.

After a while, the law of diminishing returns comes in, making it daft
to have too many redundant legs. Dual would make a big improvement in
resilience, Triple would be a partial improvement over dual but after
triple, you're probably getting into gold-plating levels. It also
depends on how much space there is. If you do your dual redundance
with the cables in the same runs, you're only effectively getting
single redundancy cos a cut in one place will cut both cables.

Increasing redundancy to high levels can have subtle benefits and subtle
problems. Lots of telephone switches and utterly mission-critical
computers have triple-redundant elements, so you can take one element
out of service for maintenance while still having a hot standby failover
element.

As redundancy increases, you may start imposing significant overhead
keeping all the elements synchronized. Even worse is what is called the
Byzantine Corruption Problem, where some of your elements are giving you
incorrect information.

Voting logic is one of the ways to approach Byzantine Corruption.
Depending on your system policy, you can let the minority or majority
control. For example, in a medical radiation treatment system, if any of
the three processors indicates an unsafe condition, it immediately
closes the shutter on the radioactive element. Better to stop the
treatment and have a human check, than nuke the patient.

In other systems, the majority rules, on the assumption that corruption
is the exception case. Even more complex systems may have redundant
monitoring devices that independently agree that the working elements
are operating correctly, using modeling and the like.