1553 bus on the C-130?

[David Harper]

Does the C-130 have two 1553 buses onboard? One for flight control
and one for EW/mission systems?

Thanks in advance,
Dave

[M.H.Greaves]

I thought it was the No.1 via kings cross!!? lol

--
"Fire at will"
Which one's will?! Do you know these people????
"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?
>
> Thanks in advance,
> Dave

[Simon Robbins]

"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

[Harry Andreas]

In article >,
(David Harper) wrote:

> Does the C-130 have two 1553 buses onboard? One for flight control
> and one for EW/mission systems?

Depends on the model of C-130.
Some have 1553 for non-essential avionics such as ECCM and Comms.

--
Harry Andreas
Engineering raconteur

[Harry Andreas]

In article >, "Simon Robbins"
> wrote:

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

1553 has no inherent connection with dual-redundancy.
In fact, 1553 is usually used as a single bus.

--
Harry Andreas
Engineering raconteur

[matheson31]

Definitely not used for flight controls. If you have ever been in a 130
and looked up you saw lots of cables that connect to actuators that run the
flight controls. Now the MC-130E has a 1553 bus for systems. I suspect the
MC-130H has two, for redundant systems. The C-130J might have more than
one, because of the FADEC and all the systems.

Les Matheson
F-4C(WW)/D/E/G(WW), AC-130A, MC-130E WSO/EWO (ret)

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


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.703 / Virus Database: 459 - Release Date: 6/10/2004

[Paul Hirose]

Simon Robbins wrote:
>
> I don't think 1553 is used for flight control since the latency and speed
> isn't sufficient.

It is sufficient for the B-2 flight control system, which is totally
dependent on MIL-STD-1553B data buses for reading the air data ports
and commanding the hydraulic actuators. (The stick and pedal position
transducers are not on the buses; they are wired directly to the
flight control computers.)

During ground testing I've transferred 700,000 bps through a 1553 bus
from the B-2 cockpit area out to a flight control actuator terminal in
one of the wings. That figure is net data throughput, i.e., it doesn't
count the command and status words, parity bits, etc. And it's not
necessarily the maximum capacity. I never had an opportunity to
experiment and find the limits of the bus, though I believe 700,000
bps must be pretty close.

That throughput was attained between test sets connected to the bus; I
have no idea how much bandwidth the B-2 flight control system uses in
normal operation.

There are about 32 MIL-STD-1553B data buses on a B-2. Four are
dedicated to flight controls.

I've never even been aboard a C-130, except maybe at an air show
static display, so I can't answer the original poster's question. But
I can confirm that the 1553 bus does have enough speed for fly by wire
flight controls on a large airplane.

--

Paul Hirose >
To reply by email delete INVALID from address.

[Alisha's Addict]

On Fri, 11 Jun 2004 14:06:45 -0700, (Harry
Andreas) wrote:

>In article >, "Simon Robbins"
> wrote:
>
>> "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.
>
>1553 has no inherent connection with dual-redundancy.
>In fact, 1553 is usually used as a single bus.

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.

Pete Lilleyman

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

[Arie Kazachin]

In message > - "Simon Robbins"
> writes:
>
>"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
>
>

In flight control systems tolerable delays are so large by todays computers
standards than it's hardly an issue: for example, such an agile fighter as
F-16 feels OK with about 1/2 second delay between the stick input and control
surface movement. The fastest type of signal is stabilization augmentation -
the control surface can oscilate at frequencies from somewhat below 8Hz in
F-4E to something like 20Hz in F-15 (not having F-15 experience the last
figure is taken from someone else's words). A delay of the order of 0.1 sec
is HUGE by even a modest computer network standard. I don't remember by heart
the 1553 standard but I'm sure 0.1 sec delay is well within limits.

BTW, one of the replys was dealing with 1553 throughput in B-2. Please note
that throughput and delay are not the same and quite often they're
contradictory desigh trends: a design optimized for min. delay will have
lower throughput and vise virsa (assuming same cost). So, measuring a
throughput from one network point to another is irrelevant to FLCS tolerable
delay. What should be measured is the worst case max. delay, usually at top
throughput and in some particular "pathologic" case of network traffic.



************************************************** ****************************
* Arie Kazachin, Israel, e-mail: *
************************************************** ****************************
NOTE: before replying, leave only letters in my domain-name. Sorry, SPAM trap.
___
.__/ |
| O /
_/ /
| | I HAVE NOWHERE ELSE TO GO !!!
| |
| | |
| | /O\
| _ \_______[|(.)|]_______/
| * / \ o ++ O ++ o
| | |
| |<
\ \_)
\ |
\ |
\ |
\ |
\ |
\ |
\ |
\_|

[Tony]

"Harry Andreas" > wrote in message
...
> In article >, "Simon Robbins"
> > wrote:
>
> > "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.
>
> 1553 has no inherent connection with dual-redundancy.
> In fact, 1553 is usually used as a single bus.
>
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.

Tony S.

[David Harper]

"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

[Alisha's Addict]

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 ;-)

[Paul Hirose]

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.

[Howard Berkowitz]

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.