Unfortunately I am not working on any piece of really neat software thats going to go in some high-tech fighter jet, rather I'm writing a test harness to certify a piece of hardware that could potentially go in a number of aircraft. The downside may be that this is less exciting, but the upside is that I have pretty much free reign over the whole application.
So what does the piece of hardware do?
Well the short answer is: anything. It is essentially the heart of an on-board computer responsible for some specific task. The resident OS on the card can execute whatever application a customer puts on it, making it essentially just a very small PowerPC computer. The real benefit of the card, and the main crux of the testing concerns what is on the outer edges of the hardware, the communications interfaces with other on-board systems. 3 standards apply to communications with respect to the project:
- RS-232
- RS-422
- STD-MIL-1553
The first two are relatively straightforward serial communication protocols. If you have a computer with a serial port on the back, that is an RS-232 port. RS-422 differs only in the voltage levels that signal logical 0 and 1. STD-MIL-1553 on the other hand, is an extremely complicated standard that defines how devices onboard an aircraft communicate (in recent years this standard has been revised to include ground systems as well). Wikipedia: STD-MIL-1553
So how does a 1553 bus work?
Systems on the bus are either:
- Bus controller - Controls all communications on the bus. Simplifying this a bit, it has an ordered list of who is to send a message to whom. It takes the first item off the list, asks the sender for the data it wants to send, and routes it to the recipient. Then it gets the next item from the list .. etc, cycling back to the beginning on the last message.
- Remote Terminal - Another computer on the bus. Listens to the bus controller for when to send or recieve data.
Example configuration: A fire-control computer is the bus controller, and the additional computers that run the weapons system itself are the remote terminals.
My actual project..
Although I intend to write on software certification at some point, for now I'm just going to gloss over the process so this post isn't ridiculously lengthy. The idea is that a set of test cases have been developed which extensively exercise all the communications functionality of the hardware, as well as the OS functionality that is exposed to software that might run on it. My job is to write a PC-based application that will allow all that functionality to be exercised.
For some parts this is relatively straightforward: the host application directs the hardware to execute some function, and send back the return value for us to verify. The 1553 functionality is less straightforward, as the hardware is capable of acting as either a bus controller or a remote terminal, and switching dynamically between the two. This means the host must essentially simulate the remainder of the 1553 bus in either situation.
Here is a pretty diagram of how the entire test harness works:
So it is not just a host application. The listener application is the other half of the test harness, which lives on the hardware itself in the place where the real software would be in production. Its job is basically to interpret commands from the host application and turn them into real function calls on the hardware. I was given something that would let me call functions with primitive arguments as long as I provided the address in instruction memory. The rest is up to me.
So theres really what I'm working with. The main challenge is that all we can really send over the RS-232 line to the listener is some text, but the functions have arguments ranging from primitive types to structs and dynamically sized arrays.
