Hacker News Reader

Comment by benigeri | Hacker News Reader

I wonder how much of that is actually necessary nowadays.

All of it. The pilot is going through a checklist. The checklist is not going to have unnecessary steps in it. When pilots don't follow the checklist sometimes they die, so they are pretty religious about following the checklist.

That is a pretty new 737 (someone speculated 737-800). Note the flat panel primary displays (color LCDs), that is the tip-off that this is pretty new.

P.S. There is a small piece of me in the FMS.

> Note the flat panel primary displays (color LCDs), that is the tip-off that this is pretty new.

Glass cockpits have been around for some time now. Also many older 737s (at least with US-based airlines) have been retrofitted with newer equipment. For example, all of SWA's 737-300 series aircraft (the oldest in their fleet) have been upgraded to glass cockpit controls.

Out of interest: which part of the fms did you build? And thanks: I lovend working with it.

I wrote a lot of the "Dual FMS" BootROM and also the cross-FMS data link communications handling (TCP/IP originally over a high baud rate async serial channel). Most of my code is deeply embedded.

Awesome!!! Never knew it actually operates over TCP/IP, I always assumed some custom protocol/ARINC interop between the two units. Can you perhaps elaborate in some way on the dev environment When working on "stuff like that"? :)

New systems (not the 737 FMS) use ARINC-664[1] - UDP/TCP/IP/ethernet with all the good parts disallowed. :-) The original Dual FMS predates ARINC-664.

The original Dual FMS was a Motorola 68040 (the predecessor FMS was the TI TMS9900 architecture implemented in bit-slice processors(!), later an ASIC, because the TI 9900 was a bust. The original code was Fortran, with the Dual FMS it was ported to Ada.

The development environments back in the late 1980s, early 1990s was custom hardware and in circuit emulators (ICEs). The ICE plugged into the processor socket and emulated the processor but with breakpoints and trace. The 68040 was about the end of the line where this worked (the head of the 68040 ICE was pretty large. There were no "eval" boards to develop code on... we wrote code and waited for the hardware guys to get the first article built. When the hardware guys got done with the initial checkout on the first article, we got the system and started making the code work.

Once we got the hardware, software development was a lot like now: start with basic functionality, cross your fingers, burn and learn. With the ICE, "burning" was faster because you substituted ICE RAM for the target flash and the trace of the ICE was a lot more useful than today's JTAG-based debuggers - you could see everything for the last 1K-4K instructions, including the actual states of the pins of the processor.

The development lab had real equipment (e.g. the Control Display Units (CDUs)) and a lot of simulated I/O. The simulated I/O was driven by a flight simulator running on a Dec MicroVAX. The flight simulator simulated the flight characteristics of the 737, responding to the commands given by the FMS. Since I was mostly low-level, I didn't do much with the flight simulators, but I could enter flight plans (typically "company routes" which are pre-canned airports, runways, and waypoints) and go through all the motions of flying. The simulator could speed up time to save time waiting for things to happen. IIRC, 4x real time was about as fast as you could go because the systems would go wonky.

[1] http://en.wikipedia.org/wiki/Avionics_Full-Duplex_Switched_E...

You sir, completely made my day! Both of my nerd personalities envy you :)

Reply on news.ycombinator.com