Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Current Project

Sign in to follow this  


Alright, so an update about what I'm doing at work, while I enjoy not being there due to this lovely holiday:

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.
Sign in to follow this  


Recommended Comments

Actually the OS on the card is VxWorks. It'd be cool if we used some derivative of Unix, but OS's like VxWorks and Green Hill's INTEGRITY were built with these sorts of problems in mind (I think VxWorks is running on the Mars rovers). Mainly that means the operating system is real-time (RTOS), which guarantees if you write the software correctly that you can meet execution deadlines within some minimal margin of error. (i.e., you write some piece of software that for example, operates some sort of autopilot mode. A real-time OS will guarantee you (with correctly written software) that if you recieve an event saying something to the effect of "pull up", that the event will be recieved and responded to within some defined time, every single time the event occurs no matter what)

Also, it's neccesary to certify not only any application you run on the operating system, but the OS itself. Wind River, the people that make VxWorks, have done that and for some outrageous price will provide you with the documentation that says so to be used in your own certification process.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!