9
$\begingroup$

This clip now circulating on Facebook (YouTube link) shows two pilots playing a game of Pong on the Fokker 70/100 Flight Management System (FMS). The manufacturer is presumably Honeywell.

Does this feature really exist?

Thoughts:

  • I would have hoped they had better code review to catch this, but then again I'm not sure how these work. A few veteran old employees who know ADA or whatever sitting in a dark room down the corridor when the new intern shows up?
  • The hardware is fairly old with corresponding limitations. As much as the flight displays (EICAS) can do decent graphics, the FMC seems pretty 'paginated' and slow to react to button presses.

Update: Thanks for the input. I was fairly certain it was fake but couldn't find the error. It also provoked some interesting software debate :)

Improve this question
$\endgroup$
11
  • 2
    $\begingroup$ Re: the hardware limitations, games like Pong are pretty simple: You could, at least in theory, play it on the Apollo AGS (I mean the display would be all wrong for it but you could certainly run the code. You could program and play play 5-card stud poker on it with the stock display unit if someone wanted to write the software). A quasi-modern FMC certainly has the ability to play pong from a compute-power standpoint, so it's really a question of "Did anyone really write and include that software?" $\endgroup$
    – voretaq7
    Sep 16, 2015 at 18:37
  • 7
    $\begingroup$ I strongly doubt it could happen, and would be interested in the answer. For 2 reasons. Adding useless code is adding possibility of bugs, this is irresponsible when lives are at stake. Giving crews some distraction when flying the aircraft falls in the same stupid category. $\endgroup$
    – mins
    Sep 16, 2015 at 18:59
  • 7
    $\begingroup$ I have no knowledge of the FMS, but the clip is obviously a fabrication. At 0:47 there is frame where the players finger is obscured by the "screen" that is hiding the actual display. $\endgroup$
    – BowlOfRed
    Sep 16, 2015 at 19:04
  • 4
    $\begingroup$ All avionics code is provided by 3 separate groups, independently reviewed by at least one other group, and tested according to the specification by yet another group(s). It is also subject to regulatory oversight. No way this is real. There are no "easter eggs" in safety critical software. It could only get through that stack by being very well hidden and the risk of side effects is just too great. $\endgroup$
    – Simon
    Sep 16, 2015 at 20:02
  • 3
    $\begingroup$ Old hardware? Playing Pong? You realize PONG came to the arcades in 1972 and was released as a home game in 1975? Just how old you think that Fokker is? $\endgroup$
    – FreeMan
    Sep 17, 2015 at 12:19

2 Answers 2

Reset to default
12
$\begingroup$

The 'clip' is obviously a fake. Standards for avionics software development and testing are rigorous, with development of flight critical software being done by separate (independent) groups and legally required to be reviewed by another (independent) group.

After that testing is done by another group/person who's certified by the regulatory authority. It is very very difficult and downright dangerous to have this kind of codes in flight critical system software.

Also, as BowlOfRed says, there is a point in the video where the finger (of copilot?) goes behind the screen.

Screenshot

Also, from the clip, it appears that the two 'players' predict each other's moves pretty accurately. I'm not very sure if that's the way it is played, but I doubt it.

Of course, to prove that something is impossible is not possible, but I'm quite certain that the clip is a fake.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ While this particular clip may be fake, I've personally played Doom on telemetry equipment (doom source code was released and I was curious how much processing power our telemetry system had). Though in such cases the equipment wouldn't actually be installed on a plane. It would be a test unit on a rack in the lab. $\endgroup$
    – slebetman
    Sep 17, 2015 at 3:12
  • 4
    $\begingroup$ @slebetman It is not a question of can it been done, rather one of has it been done. Porting games to the unlikeliness of instruments seems to be a hobby for coders (hell, someone played doom in a calculator). I'm pretty sure that ping pong can be played in most, if not all flight instruments with screen. If someone had shown this on the ground (lab), we'd probably had said 'wow, good job' and gone on our way. That it was shown in an aircraft is what intrigues everyone. $\endgroup$
    – aeroalias
    Sep 17, 2015 at 3:22
6
$\begingroup$

It's probably fake but there's no reason why it couldn't be in and why it couldn't be approved like that.

An (The!) acceptable means of compliance to FAR/CS 23/25.1309 is DO-178. Airborne software is developed to meet a Design Assurance Level (DAL) which is derived from the aircraft level Functional Hazard Analysis and Preliminary System Safety Assessment (see SAE ARP 4761).

Every FMC/FMS I've every worked on has been DAL C which means that the failure is 'Major' defined as the "failure is significant, but has a lesser impact than a Hazardous failure (for example, leads to passenger discomfort rather than injuries) or significantly increases crew workload (safety related)".

For DAL C development, independence is only required for meeting the Software QA aspect. The software verification activity does not have to independent of the developer. However, for DAL C code, there is a requirement to complete full statement structural coverage, i.e. structure has to be tested at least once during the formal verification testing (i.e a decision has to be tested true OR false, not true AND false).

Therefore the Software Verification Cases and Procedures (SVCP) would have to have had a test for the pong game in or else structural coverage would have shown the code to be 'Dead Code' and it would have to be removed.

The certification authority (FAA, EASA or otherwise) would not typically review the SVCP or the results (SVR).

The unit will also, most likely, have a Technical Standard Order (TSO) approval but as long as the performance requirements are met for the applicable TSO (e.g. TSO-C115c) the approval will be granted.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Reposting my comments. Structure has to be tested at least once during the formal verification testing (i.e a decision has to be tested true OR false, not true AND false): I assume you mean both TRUE and FALSE branches have to be tested, else the test coverage would not be complete $\endgroup$
    – mins
    Sep 18, 2015 at 10:54
  • $\begingroup$ I think I understand your point: All statements vs all decisions. However I don't see the point to checking a SWITCH-CASE with 100 CASE blocks of instructions by looking only one CASE block (e.g. if an infinite loop exists in the second CASE block). Using an analogy with an electrical rotary switch with 100 positions, there is little use to check the first position doesn't create a problem, and ignoring the 99 others. $\endgroup$
    – mins
    Sep 18, 2015 at 10:55
  • $\begingroup$ All the cases would generally be covered by the requirements based testing. Also, for reasons of reducing software complexity and improving testability of the software (cyclomatic complexity / McCabe complexity), the number of cases in a switch case should be limited (some compilers struggle with more than 32 anyway). Also, nesting switch cases or nesting conditional statements within the switch should be avoided. The overiding testing is always the requirements based testing. Testing just to meet coverage requirements alone is meaningless. $\endgroup$
    – AJRP
    Sep 18, 2015 at 11:11
  • 1
    $\begingroup$ The premise of all testing for all DO-178 compliant airborne software, regardless of DAL , is requirements based testing. This is done for both for the normal range and robustness (invalid conditions, invalid inputs, out-of-range, over-framing, invalid state transitions etc.) For DAL D (Software that can cause or contribute to a Minor failure condition ), this is all that is required and only for the high level requirements. For DAL C (Major), DAL B (Hazardous/Severe-Major) or DAL A (Catastrophic) requirements based testing on low-level requirements also has to be completed. $\endgroup$
    – AJRP
    Sep 18, 2015 at 11:16
  • $\begingroup$ Additionally for DAL C 100% structural STATEMENT coverage has to be demonstrated (i.e. - yes OR no) Additionally for DAL B 100% structural DECISION coverage has to be demonstrated (i.e. - yes AND no) Additionally for DAL A 100% structural Modified Condition/Decision coverage (MC/DC) has to be demonstrated. Put simply, this tests every path through the software between an entry and an exit point. $\endgroup$
    – AJRP
    Sep 18, 2015 at 11:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .