Possible Hazards of Software Controlled Systems (Ex. Airline GPS/Elevator)?

Question

I am currently reading through a book on Software Engineering principles, with a lot of the content having to do with proper approaches to software development methodologies and project management approaches. After reading through the chapter on risk assessment and management, one of the review questions caught my eye.

The question asks me to to examine the GPS navigation system of a commercial aircraft as well as the elevator in a high-rise building, and to identify 3 hazards that could become linked to software failures. For the elevator one I foresee several hazards such as the Elevator Doors not opening, the system stopping the elevator between floors, the system failing to the point of "dropping" the elevator from the 217th floor, and so forth.

The commercial airline GPS system though is leaving me stumped. With a car you run the risk of out-dated maps attempting to take you through/over/across hazards or nonexistent routes. While trying to research, I found that apparently radar only works about 100-150 miles past the coast, from there pilots will radio in at checkpoints with location, altitude etc. Aside from the GPS outright failing (picture over the ocean, no landmarks at all or falling off course if the GPS is tied into the AutoPilot), I'm not seeing many other hazards that could arise from software failure in a commercial airline GPS.

Would anyone care to offer their thoughts on this? I feel as if I am either over looking something or way over thinking this.

---

EDIT:

Also, how can issues such as in an aircraft GPS be prevented? With an elevator you have the Governor and "drop-locks", but how do you avoid GPS failures/errors in an aircraft?

---

EDIT2:

After thinking it over some more I put the following together:

Commercial Aircraft GPS Navigation:

Hazard 1: If the GPS outright fails, the plane can become lost due to unfamiliar terrain or lack of landmarks (picture over the ocean). Even with an old fashioned compass or use of the sun for direction, there are concerns of fuel quantities.

Preventative Measure 1: While certainly not fool-proof, the best preventative measure I can think of is to ensure a backup GPS is available on all aircraft should the first one completely fail.

Hazard 2: Should the GPS navigation in the aircraft fail (but appear to be functioning correctly) there is the chance of 2 planes encountering a mid-air collision as they enter into the same flight path and altitude.

Preventative Measure 2: Having either a second GPS system available to check against or by conducting check points after the flight path has been established, falling so far off course should be avoided. I am not familiar with aviation standards, but I like to assume that most aircraft have some kind of proximity alarm.

Hazard 3: If the GPS is tied into the Auto-Pilot system (which I believe is the case with most commercial aircraft today), then a GPS failure (but seemingly functioning) event could cause the aircraft to rise and stall or to enter into a catastrophic path such as straight into a mountain side.

Preventative Measure 3: Other than building in a method to force the auto-pilot function to disengage, I am unsure of what measure could be taken on this particular event (though it should not occur on a commercial aircraft with the pilots monitoring systems even if not actually “flying” the aircraft).

---

High-Rise Elevator:

Hazard 1: There is the risk of the software failing and thus causing the doors to remain closed, trapping passengers.

Preventative Measure 1: I believe most modern elevators have methods in place to prevent this, but my method would be to build a backup or exception catch which would allow passengers to open the door.

Hazard 2: Similar to the above, a software failure could lead an elevator to become stuck between floors – this is often seen in movies but does actually happen. Depending upon the amount of building material separating building floors, this can also lead to passengers being thoroughly trapped.

Preventative Measure 2: There are different issues which could cause this particular hazard situation – the cable could become snagged, cable locks deploy, etc. If this is due to governor, the best measure I think of is for a governor failure to go ahead and trigger the cable locks, keeping the elevator in place, but stopping it from plunging down (or up). From there, the standard call button can be used to contact emergency services.

Hazard 3: Then there is the most concerning hazard of a high-rise elevator: a software failure which causes the governor to malfunction and the elevator to drop straight down at the mercy of gravity and its own weight. Doing so from say the 82nd floor would almost assuredly result in expiration of the passengers on board.

Preventative Measure 3: In this particular scenario, the best measure I can think of is to build into the system where if the governor fails and the elevator begins to move [X] number of feet per second, engage the cable locks to stop the elevator before serious injury causing speed can be built up.

---

Is there something further I'm overlooking? I feel as if I'm grasping at straws with my current ideas for preventative measures. Besides back-ups to the main system in most of the hazard situations, I'm not seeing many other measures that can be taken to prevent or handle their occurrence.

Answer 1

Commercial air traffic is in pretty constant contact with air traffic control, and GPS is not the primary method of tracking aircraft position. This article, written in the wake of the MH370 disappearance, gives a pretty good rundown of how planes are tracked currently.

The essence of it is that most air traffic control systems still rely on radar, whether primary (bouncing radio signals off of objects) or secondary (using a transponder to get more accurate data and computing position/velocity using successive pings.) However, most modern aircraft has GPS installed on it, it's more for pilot reference than anything else. At this point, we have 3 systems to track position, one of which is entirely separate from the plane, so the entire tower would have to go down in order for it to fail.

Also, considering the ubiquity of cell phones, if a plane's entire navigation system falls apart simultaneously, there will still be dozens or hundreds of GPS capable devices on board. In this sort of emergency, the GPS only needs to function well enough to get you below the cloud ceiling and into a position to fly VFR (using sight instead of instruments) and land safely at a close airfield.

And really, what this means is that the question is based on a flawed premise. If the GPS on a plane cuts out, the pilot probably goes "Damnit, that sucks. Gotta get that fixed later." and continues about his day as if nothing happened, because he's relying on the transponder for position tracking.

Answer 2

The question relates to the functions of GPS related software, and not the loss of GPS signals or functions.

Therefore, the algorithmic software errors related to GPS related computations or communications must be reviewed.

This handling occurs in two different levels:

1. GPS position calculation (which is conducted by a GPS-receiver card)
2. GPS handling on the Aircraft system side, which reads position data from the GPS position card (or device).

1) For the position calculation card, refer to patents and the calculation methodologies of GPS position. Functionally, software error (due to hardware or due to software program) can occur at this level, and may cause erroneous position calculation. Handling of GPS Satellite almanacs, or World Coordinate system conversion could be potential failure scenarios. I do not mean that these failures could happen in a particular device. Rather, these can be possible software errors to consider and verify against.

2) GPS data is used by some autopilots and also for navigation systems. In order to use the current position of the aircraft, the flight control system talks to the GPS card or position Equipment (can be GPS/INS integrated, or not). While talking to the GPS Equipment, software errors could hypothetically occur at 2.a) interface handling (message failure) 2.b) mis-interpretation (message is misunderstood, e.g. the position is given as 34.5323423 but it is parsed as 34deg53'23", etc.)

I guess this answers the chain of thoughts that the author of the book was askig for: "to identify 3 hazards that could become linked to software failures".

In practice, these scenarios would be caught by the use of complex system development process guidebooks (i.e. SAE-ARP-4754A (Guidelines For Development Of Civil Aircraft and Systems), or DO-178C Software Considerations in Airborne Systems and Equipment Certification, etc.) or by reusing existing and proven software/equipment.