If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
"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 |
#13
|
|||
|
|||
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. |
#14
|
|||
|
|||
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. |
|
Thread Tools | |
Display Modes | |
|
|