
Node.js running in the new Airbus A350 inflight servers - monkeyshelli
http://reaktor.com/blog/aircraft-customer-experience-on-a-new-level/
======
vonklaus
There are a lot of jokes here and I appreciate them. It isn't breaking news
that js has some bad parts, but why are people who aren't joking concerned?

* What makes nodejs running on an entertainment system dangerous?

* Outside of bias, how strong of a case is there to use another language?

* why _shouldn 't_ we use high level languages, even for avionics? Obviously not JS because numbers aren't transitive and it just isn't the usecase, but we don't need to optimize for 1kb of memory anymore. C family languages are the backbone of many things and that makes sense but do we need to keep using java and C-like languages or could we use python or something of similar nature where memory isn't manually allocated.

~~~
boomlinde
I'm sure that you could use a high level language like Java or Python for some
non-critical tasks. For more critical software you likely have hard real-time
requirements, and you need to be able to reason about memory use and time in
ways that obviously isn't suitable for anything that could "pause the world"
for an arbitrary amount of time to collect garbage.

~~~
nmrm2
Exactly this.

It's not that there's anything wrong with using a high-level language for
safety-critical systems with real-time requirements and limited hardware. It's
just that every high-level language that's remotely appropriate for this set
of requirements wasn't production ready (or even conceived of) 10-20 years
ago.

Hopefully the next generation (or the one after that) of control software for
aircraft will be written in beautiful code :-)

------
doublerebel
What struck me was most is the ability to iterate quickly on features and
bugs. They didnt just bring Node to the plane, they also brought a more modern
software dev mentality. Node's ease of use and ecosystem are a definite asset
there.

Most airlines are stuck with static, slow, and outdated in-flight systems.
This will help them compete as consumers' devices have become embarrassingly
better than the typical in-flight UX. Not to mention consumer devices are much
heavier on bandwidth and power usage.

In regards to the other unsubstantiated comments in this thread, I would
assume as an airline they also brought modern security practices along with
the rest of the deployment.

------
joegreen
Fast-forward 20 years, a plane crashes, they find and open the black box and
in the flight logs they can see the cause clearly:

"undefined is not a function".

~~~
stevebygane
Did you read the article? It's about the inflight entertainment system, and
has nothing to do with the flight recorders.

~~~
verelo
In flight entertainment systems have certainly been the cause of crashes in
the past:
[https://en.wikipedia.org/wiki/Swissair_Flight_111](https://en.wikipedia.org/wiki/Swissair_Flight_111)

"the crash was generally believed to have been caused by faulty wiring in the
cockpit after the entertainment system in the plane started to overheat"

It's not too far fetched to think you could end up with an infinite loop (or
other random issue) in some inflight entertainment system code, causing it to
overhead and potentially ignite. I'm sure there are plenty of safeguards, but
they too could fail...and this is why we still have circuit breakers and a
master switch in planes that a human can control. Sadly humans too can (and
often do...) fail to make the right decision.

Any system other than flight surfaces, avionics and the source of propulsion
to an aircraft add some degree of risk that we could otherwise fly without.

Edits: Spelling and general sillyness.

~~~
pkaye
This seems to be a hardware issue.

~~~
verelo
People seem to be missing my point. To be clear, i'm trying to suggest that
there is a high chance that the hardware fault that was triggered by
overheating, was potentially caused by a software fault.

~~~
pkaye
It is not good that the software malfunctioned but it should be totally
isolated from rest of airplane function. Also if software could cause
overheating, someone should have redesigned the hardware (heatsink/fan for
example) because it was already marginal.

~~~
verelo
Yep. Likely multiple failures. The software shouldn't cause extra heat, the
hardware should be able to handle it, the insulation in the plane shouldn't
have caught fire, the pilot should have pulled the circuit breaker
sooner...the list goes on.

------
andy_ppp
I hope they got their system thoroughly pen tested...

I bet you there are not two satellite aerials on the plane and you can bet
that the important navigation systems are in some way connected to the
network. Hopefully this just the aerial connected to two routers but it's
probably a single router. I think I want to fly on this and start running nmap
;-) I suppose that would be considered hacking though.

~~~
davb
Internet access via IFE (in-flight entertainment) systems and WiFi has been a
thing for a good while now. There's no new attack vector or failure mode in
that respect.

------
jt2190
Interesting points:

    
    
      * in-flight entertainment system devs allowed to run 
        open source
      * system is "online" via aircrafts satellite 
        internet connection
      * devs pushed fixes mid-flight
    

(Edit: The article headline is _Aircraft customer experience on a new level_ )

~~~
jcsnv
> devs pushed fixes mid-flight

Scary, even if the entertainment system is not connected to the flight
equipment.

~~~
stpe
The article says the issue, discussed with Yle (the content provider), was
fixed mid-flight - it doesn't say anything about a fix being pushed. For all
with know it might not even be the code, maybe it was a property in the JSON-
data of a news article that was changed from left-aligned to right-aligned?

Also - no matter if it is relevant or not in the case - being able to deploy
and update fixes to a system in production without anyone noticing is a
testament to good system design - and even a requirement in many cases.

------
jacquesm
So, it runs nodejs. Any idea on what hardware it runs on, what kind of
interface(s) it has to the aircraft, what kind of OS it runs?

~~~
joezydeco
A little bit of Googling mentions that the Panasonic EX systems are VIA
embedded x86 boards (perhaps Atom-based?) running Linux.

~~~
dorfsmay
VIA boards typically run either ARM processor or their own (VIA) x86
compatible processors:

[http://www.viatech.com/en/boards/](http://www.viatech.com/en/boards/)

I run a couple of servers using VIA processors, they consume very little
electricity, I run storage, web and mail servers on them. When Intel came out
with the Atom, it used a little bit more electricity but was significantly
more performant than the VIA. VIA has had new processors since but I don't
know how they compare to the Intel low-power line.

~~~
joezydeco
Is VIA what is left of the Cyrix/NatSemi MediaGX cores?

~~~
jacquesm
Yes, I think it is. The x86 version at least. They had a neat little board
that I used to control a plasmacutter torch in 3 dimensions.

~~~
joezydeco
I had a neat little project on that setup as well. It was way too early for
its audience, which is kind of a shame.

~~~
jacquesm
[http://pics.camarades.com/v/jacques/trips/jansvisit/dscn4017...](http://pics.camarades.com/v/jacques/trips/jansvisit/dscn4017.jpg.html?g2_imageViewsIndex=1)

Extremely ugly first day prototype of that plasma cutter controller, the VIA
board sits in the hard drive enclosure on the right hand side, you can just
about make it out.

What did you build?

~~~
joezydeco
This contraption:

[https://www.youtube.com/watch?v=dAyBz8XIMsU](https://www.youtube.com/watch?v=dAyBz8XIMsU)

[http://www.silverball.net/images_martin/tech_pc_case.jpg](http://www.silverball.net/images_martin/tech_pc_case.jpg)

It was a MediaGX 5520 (233Mhz) motherboard with a custom PCI board holding an
array of 8mbit ROMs + flash memory and a DSP for sound playback. Douglas
Comer's XINU was used as an operating system and ran from ROM.

The "too early for it's time" was less about the pinball machine and more
about the MediaGX. A small Geode board + Linux could have been a really nice
platform. I think a lot of ATMs are actually using this formula.

~~~
jacquesm
Super nice work.

I've worked on some coin op stuff as well but more video game oriented. The
original software ran on Windows, I did a linux port to show that 'it could be
done' without windows. The hardest part was to switch from one game to another
(multi game console) without a video mode reset.

Another application for that board is on-board computer for cars. I've got a
very similar board in a nice little case that just fits under the passenger
seat and wires into the car by running cables to the side of the transmission
tunnel. Boot times are short (runs off a flash disk) and media are stored on a
small 2.5" hard drive. I like these little systems.

------
Yhippa
Would this be the farthest from Earth JS has been run?

~~~
kevinchen
ISS has laptops. I've heard that they do everything by using Remote Desktop to
a NASA box on the ground, but presumably there's some part of the client that
uses a web view with some JS e.g. to show formatted text.

~~~
TeMPOraL
If the laptops run Windows between 95 and 7, then there's likely a lot of
JScript and JavaScript running in things like Active Desktop, desktop widgets,
possibly startup scripts and obviously inside IE. I'm not sure if all this
stuff is still around in Win8+ though.

Also, please don't give them any ideas. It's enough that every other JS webdev
company uses rocket-related imagery on their site, we don't want them to
design _actual_ rockets.

;).

~~~
tracker1
Most automation scripts these days tend to center around PowerShell. That
said, JS is an option for integrated applications in Windows 8+, not to
mention electron, nwjs, firefox/xulrunner, and the like.

------
vans
JS in airflights, ok that's official now, we are doomed.

~~~
JUsr
Correct me if I'm mistaken, but the avionics software would probably be
written in C or Assembler.

Neither of those have SloppyDevTypeCheckComfortBlankie either, do they?

~~~
larry_pi
Sloppy dev is a sloppy dev - whichever the language:
[http://www.safetyresearch.net/blog/articles/toyota-
unintende...](http://www.safetyresearch.net/blog/articles/toyota-unintended-
acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code)

------
dtjohnnymonkey
I worked on IFE systems at Panasonic for several years. The so-called "head-
end" (server-side) services my team worked on were written in C++ or PHP. I
saw a lot PHP going on there. The server limitations weren't as strict as you
would think.

The interfaces between the avionics which held actual flight data and the IFE
were read-only IIRC, and otherwise fairly isolated.

------
wangii
JS is the new assembly, and React will be the next Visual Basic.

I'm surprised nobody mentioned the Atwood's Law yet.

~~~
tracker1
JS is a language like just about any other.. and, like VB the ubiquity of new
developers starting out with it yeilds some pretty bad code. I've seen bad
code in a great many languages.. and some of the worst JS code I've seen has
tended come from language snobs who favor other languages, and bring in
patterns that just aren't appropriate for the environment.

------
anon6_
In my opinion using a language that doesn't compile into a binary with native
type safety is a step backwards if it's integrated with any mission-critical
system.

Love node.js and happy to see it succeed. I'm not sure if I'm a big fan of
seeing it used in places where it's not, because it gives the wrong
impression.

I wouldn't use node.js everywhere. I'd say python can wear more hats, but if
it came down to something you can't update regularly and would cause big
ramification if it'd fail. You're just making a gamble.

If you have a JS bug which wasn't caught, which could have been caught via
static analysis, you're going to either go into flight with broken
entertainment or wait for a mechanic to update the system.

So to reiterate. Happy for node.js, I don't think I agree with where you
applied it. I hope that customers, the airline companies and node.js doesn't
suffer unduly because the wrong tool was picked for the job.

~~~
luisrudge
typescript?

~~~
TazeTSchnitzel
TypeScript's safety is limited: its type annotations do not exist at runtime,
so if it interacts with dynamic code, its type safety is violated.

------
tasnimreza
What if somebody try to write 'flight control system' in node.js and
'settimeout' doesn't get fired on time !

------
sandworm101
Setting the physical safety issues aside, I cannot escape the comical image of
a plane-turned-rave after the cabin mood lighting gets hacked by the bored
teenager who doesn't want to read news from the airline-approved news source.

Pre-recorded safety announcements get replaced by S-Club-7 on a perpetual
loop? Siren noise ever time the seatbelt sign turns on? Or how about altering
the hosts file so that the official news source points to hustler,com? There
is something to be said for some systems not being so heavily networked.

~~~
swang
this makes the assumption that previous software was more robust at preventing
this than running node.js as a backend.

~~~
sandworm101
It's not about the software, but the entire package. The soft/firmware can be
total junk, but if it isn't networked to other systems then it isn't going to
be hacked.

Take the mood lighting. Once upon a time such LEDs would be tied to a
controller with three knobs, three rehostats, to set the RGB values. Done. No
networking, just knobs. Hacking would require digging holes into the wall.
Anyone willing to do that would just turn the knobs. But now it's connected to
a tablet app. The software on that networked tablet is always, always, going
to be more of a risk than the software behind those not-networked RGB knobs.
It's a physicality problem.

------
fenollp
Whatever. It doesn't talk with anything essential so who cares.

~~~
joosters
I wish that people who didn't care about a news article would learn to care
even less about it, in fact they should care so little that they don't bother
to write their pointless "who cares" comments at all.

------
notacoward
Shouldn't all software in a plane be written in a _higher level_ language?

Yeah, I rolled my eyes too. That was so bad I just had to share.

------
nyan4
Node.js seems to be popular only here. [http://cbcg.net/blog/2012/02/03/if-
youre-using-nodejs-youre-...](http://cbcg.net/blog/2012/02/03/if-youre-using-
nodejs-youre-doing-life-wrong/)

~~~
untog
_On a larger note, using JavaScript on the server-side seems kind of
ridiculous. If Linden Labs came out with a server-side framework in
LindenScript, would you use that? How about if Apple came out with a framework
based on AppleScript?_

Stopped reading right there. Well, actually, I read the next header "Callback
spaghetti is about the last pattern with which you’d ever want to write
anything" and realized that the author has absolutely no idea what they are
talking about.

~~~
striking
Callback hell used to be a real concern, until Promises and structural guides
came into use. As a 2012 article, I understand where it was coming from. But
it's far less relevant today.

~~~
nandsch
Not really, callback hell is as avoidable as anything else.

------
4ad
> Through the WiFi, passengers will have access to an in-flight portal which
> serves customers content without the need to purchase an internet
> connection.

Isn't this just great!

/sarcasm

------
iamleppert
Node.js is running on an airplane! So frightening this is allowed! Definitely
don't want to be risking my life on that plane!!

Why couldn't they use Scala instead?

~~~
kintamanimatt
I'm not sure if you're being sarcastic, but this is for the entertainment
system, not avionics or other mission-critical systems.

~~~
djsumdog
You'd hope. You'd really hope. Flight engineering is an intense, "We don't
fuck around field." ... But every industry has it's "good idea at the time"
and there's always a chance of these systems sharing a bus with something
critical.

~~~
kintamanimatt
There's no chance these systems share a bus with something critical. Critical
systems are separated by way of an air gap. There's no way they'd meet
regulatory safety standards set by the FAA or EASA standards if they didn't.

~~~
jacquesm
You keep saying that but it has already been proven not to be the case.

Wired article related to this:

[http://www.wired.com/2015/05/possible-passengers-hack-
commer...](http://www.wired.com/2015/05/possible-passengers-hack-commercial-
aircraft/)

States that there _is_ a connection but it is supposedly one-way only. So no
airgap. The article then goes on to note that a 777 uses a two-way bus but
requires further authentication.

~~~
notzorbo2
You keep quoting this article, but ..

The sources are dubious (wired and telegraph). Experts quoted in the article
claim its impossible, including the lead engineer of the boeing thrust
management system:

> Whether it’s possible to create this condition by issuing a command from a
> passenger seat is a different matter, however. Soucie and others who WIRED
> spoke to agree with Boeing that this isn’t possible. But unlike Boeing, they
> provided clearer details explaining why. > >Peter Lemme, who was a lead
> engineer on Boeing’s thrust-management system for eight years until 1989,
> says the system provides the auto-throttle function that actually controls
> the engine thrust, and doesn’t allow the throttles for the engines to
> operate independently of one another.

You claim it's been "proven not to be the case". Extraordinary claims require
extraordinary evidence. So far I've seen nothing from this Roberts guy. Sounds
like he's just full of shit.

~~~
jacquesm
Agreed on the Roberts guy being full of shit. But there is this passage in the
wired piece:

"A connection between the avionics system and the IFE does exist. But there’s
a caveat.

Soucie and Lemme say the connection allows for one-way data communication
only. The systems are connected through an ARINC 429 data bus that feeds
information from the avionics to the IFE about the plane’s latitude, longitude
and speed. The IFE uses this to populate the animated map passenger’s can use
to track the plane’s movement.

“On every airplane it’s done a little differently and is done in a proprietary
way,” Lemme says. But in each case, the ARINC 429 is an output-only hub that
allows data to flow out from the avionics system but not back to it, he says.
To talk back would require a second input bus. “I can’t think of why there
would ever be an interface like this. If it’s out there, I haven’t heard of
it.”

This would seem to be what Boeing was describing in its statement when it said
that although inflight systems “receive position data and have communication
links” to other systems on the plane, they are “isolated” from systems that
perform critical functions."

So there is a link.

An airgap simply means this: the two systems are not connected. Not in any
way, no physical connection exists between the two and any output from the one
goes through an optical bridge into the other.

The only way air-gapped systems are possibly connected is via power rails but
presumably those do not carry data nor do they have the possibility to do so.

[https://en.wikipedia.org/wiki/ARINC_429](https://en.wikipedia.org/wiki/ARINC_429)

Suggests it is an electrical bus, not optically insulated.

