MIL-STD-1553: Do we know too much - or too little?
BlogFebruary 28, 2018
MIL-STD-1553 is a very tried and true, well known, serial interface for the space and aviation industry that was originally developed for critical avionics interfaces that were required to solve the problem of connecting the many sensors and controls around an aircraft and relaying information between them and the crew. Key requirements are that information is transmitted reliably and in a timely manner.
Specifically, the protocol needs to be capable not only of reliably transferring commands and data from the crew to the various control points around the aircraft, but also of confirming to the crew that the commands have been received and actioned.
The requirement is the same whether the application is implemented on an airplane, space vehicle or, increasingly, a ground vehicle. In each case, it’s imperative to ensure that multiple paths can support the transport of reliable data over the likely multi-year deployment of the craft whatever the environment in which it finds itself. Developers must know about the system they build and how it interfaces to other devices—and all devices in the system must be tested to the same known requirements.
Widely deployed
A joint development initiated over 30 years ago by the military on the one hand and avionics companies on the other, MIL-STD-1553 was designed to be a joint standard together with a well-known, extensive and exhaustive testing method that worked for all involved. It is now widely deployed and represents one of the most robust and complementary interfaces for its use model, connecting numerous receivers and transmitters of information over a single pair of wires over a long distance.
The 1553 standard has a very extensive documentation set with explanation of usage and test requirements, and has been proven over many systems in production with a pedigree of many millions of flight hours on aircraft and in space systems as well as years of service in ground vehicles, sea going systems, missiles and so on.
However, one of the dangers of well-known interfaces and readily available parts is that engineers start using it like it is trivial. Just plug it in, minimal testing and it communicates. And indeed, it does work very easily and very well.
But: there is a concern about the loss of robustness that we once had. We find many of the same problems in 1553 as we did when it originally got started. We are creating the same problems again. Have we forgotten our history?
Clever engineers
Engineers are very clever, and we can make anything work—but sometimes, unintentionally and unknowingly, we break something else. The fact is that many new engineers have never dealt with 1553, and haven’t yet had the time necessary to build up the required experience or to learn the causes and effects of those little and supposedly innocuous-looking requirements.
The issue is that software has become much bigger than 100 percent testable. We need all the test and verification help that we can get. Many senior engineers do the same as they did before, because it worked! Now, new software can break old hardware in different ways, and we must test at the low level hardware layers and get into the protocol operation.
The hardware has shrunk. We love FPGAs, and they can fit so much more functionality into them. They’re now seen as a "simple" part that we just plug in and it works. The reason it works, of course, is because 1553 was designed with a broad range of different mechanisms that help give it the required robustness.
But that can create a false sense of security. It is still absolutely necessary to confirm that we have built the system correctly to the standard: we must properly test it. The 1553 standard comprises electrical and protocol requirements, and they must be tested together after completion of the device. How certain are we that it will work as expected when it comes to that once in a million shot to the moon (or Mars)?
Complete verification
The rule must be that the system needs to be verified as completely as possible by someone who really knows what needs to be tested and how to test it with the right and proven equipment. One way to get started is to find an easy to use 1553 bus monitoring hardware and software tool that can help new – and experienced – 1553 users easily monitor and debug their 1553 device.
For example, Abaco’s BT3-USB-MON combines three tools into one product: 1553 visualization and recording with user friendly GUI BusTools/1553-BM; 1553 monitoring hardware; and an integrated differential scope output for electrical analysis.
Of course, the technology element is only one piece of the puzzle to ensure your 1553 system is fully vetted and ready for long term deployment. Choosing an experienced 1553 partner – one who can support you from test through deployment – is critical for long term success.
In summary: MIL-STD-1553 was made for vital data interfaces to make sure that critical data has the best chance of getting through to the other end in a timely and controlled manner. It’s been around for what seems like forever—but that familiarity can too easily breed complacency—albeit unintentional. As such, it’s vital that, in planning for new programs, training must be factored in to ensure that engineers are prepared to implement and test the interface to deliver the security and reliability it was designed for.
