Aviation Instruments Encrypt Engine-Monitor Data

kitplane01 writes "Airplanes engines need to always work, and are monitored by engine monitors. JP Instruments' engine-monitor units have begun to encrypt the data output of its monitors so it can't be read by third-party software. Whether this is to protect itself liability-wise or to discourage competitors is unclear. It seems the company is working on a fix, which may require a fee from users to translate the file format."

Comments

Terrorism

[Anonymous Coward]

I think its to prevent terrorists from listening in on engine data.....God Bless America

It sounds like...

[uberdave]

It sounds like propriety lock-in to me. There is no other reason to encrypt diagnostic data.

Auto industry

[doormat]

As long as the auto industry doesnt follow. There was a big deal over the use of car makers to provide info to third parties for the onboard electronics. I dont know what the status is now, I heard a while ago that the information is disorganized and hard to utilize. Auto dealers love it because it forces you to use their facilities at highly marked up prices, and puts 3rd party auto mechanics into a corner.

Re:Auto industry

[Richard_at_work]

Or, if a two-engine plane were to lose an engine in the middle of the ocean, that would increase drag as the plane would slip due to mismatched thrust, and might not have enough fuel to make it to land. Hopefully they plan for this, and provide enough extra fuel for this kind of emergency.

Yes they do, its called ETOPS (Extended-range Twin-engine Operation Performance Standards) and it governs how far a twin engined commercial airliner can be from an alternate airport at any given moment, usually in minutes and reachable on a single engine within that time. Standard ETOPS times are 180 minutes for nearly all major twin engine aircraft, including the A330 and 767, while the 777 gets 207 minutes due to uprated engines and higher safety statistics.

Private jets are excluded in the FAA jurisdiction, but must stick to 120 minutes in the JAA jurisdiction.

But yes -- pretty much most 2+ engine airplanes can maintain altitude and even climb slightly if they lose one engine in a `normal' way. (Exploding/disintegrating engines don't really count. Fortunately they're very rare.)

Again, all civilian airliners are required to be able to loose an engine on takeoff, be able to complete the takeoff and the go around without issue and land again.

Re:proprietary lock in?

[Jorkapp]

this seems like an incredibly stupid and public way of locking customers into paying for information they were already previously getting for free.

We can still get it for free. Just set a camcorder in front of the instrument panels and press "RECORD".

Just like Auto Engine Computers and Lexmark

[Tangurena]

The auto companies did something similar with OBD2 compliant engine computers. As a result, the association that represented independant repair shops had to sue the automakers and SAE to get the diagnostic information released.

You should also take a look at Lexmark and how they used DMCA to sue Static Control Corp, an aftermarket inkject cartridge manufacturer. Earlier Slashdot story

PACE AP

[yroJJory]

Not really a whole lot different that PACE Anti-Piracy's latest crap.

I use some software that is protected using PACE's Interlok system. Unfortunately, the anti-piracy software is stopping me from legitimately using the software, refusing me the ability to serialize it on my machine.

PACE's response? Send us the encrypted log file! They won't tell me what's in the log file, nor will they allow me to see it before sending it.

Any amount of personal information could be in there, so I refuse to send it to them.

Since when doesn't everything need to be encrypted to keep legitimate users from reading it?

Also the Gemini:

[Monf]

This is from AOPA's review of the JPI model and the Insight model - the blurb below refers to the Insight Gemini. Maybe this is what JPI is now doing and why:

The Gemini goes about data-logging quite differently. When you want to see what's been happening, simply point the supplied Hewlett-Packard HP200LX palmtop at the Gemini's faceplate and the information will be transferred by infrared link. The information remains encrypted in the HP200LX--it cannot be altered by the user- -so it may be more useful to resolve a warranty dispute or to see how renter-pilots are treating your leaseback bird.

Re:Also the Gemini:

[VidEdit]

It would seem that JPI is using data integrity as an excuse for DMCA lock in. All they really need for integrity is a signature. Since their are federal regulations about engine overhauls for aircraft, I would think that there is a state interest in the data being accessible, but signed. This is a clear case of the miss-use of encryption.

ACARS telemetery data

[AndroidCat]

ACARS is an aircraft data telemetery system that transmits data, sometimes including engine performance, and can be receive with a simple scanner/computer setup.

In this series of two messages, we see a takeoff (TO) engine performance report.

ACARS mode: 2 Aircraft reg: .N651UA
Message label: H1 Block id: 5 Msg. no: D89C
Flight id: UA0978
Message content:-
#DFB97418853250111173 5541565144173614933782162 261527 15
0201 89 -2 0 0 671 146 27 A6F4039C8000080000D32000000000000000000000423

Not that the unencoded info makes much sense, but I guess this will be another thing hidden away from view of nosey geeks. Poot!

Aircraft crash data?

[Aphrika]

I don't know much about these kinds of systems, but I would've always assumed that partial unencrypted data would be much easier to recover in a plane crash situation. I guess it would pretty much instantaneously stop transmitting from the engine in question when the system failed.

However, wouldn't encrypted data bring with it the risk that you couldn't get the data back? What happens if you have partial encrypted data in the system? Is there a risk that the encryption could make piecing together accidents more time-consuming or render the data useless to the investigation?

In theory, could it even assist denying responsibility if the engine itself was the cause of a crash?

There's no practical reason?

[Perryman]

Why would engine monitor data need to be encrypted? All it is is fuel flow rates, its pressure and temperature, FTIT, etc. The pilot needs to see this data anyway to monitor in-flight. Maybe they're talking about when this information goes through engine diagnostics or is stored for looking at later? Oh, and do these guys just do civilian aircraft, or military too? I'd think no one would buy their engine monitor units if they couldn't look at the logs to monitor their own aircraft statistics [think nascar]. Could be a good way to lose customers. What do you think?

Well, I know it's illegal for cars

[Weaselmancer]

I know there are laws in place to keep automobile manufacturers from doing the same thing (since I make auto scantools for a living). That's one of the main reasons why the industry moved towards OBDII - to be compliant with the disclosure law.

Maybe the rules apply to aircraft as well, and there's already a legal fix?

I won't be able to ask anyone at work about which laws are in place until Monday, but this article has me curious about the legality of encrypting this kind of data for non-automobiles. If I find anything out, I'll post it here.

Encoded (Not Encrypted)

[dubner]

Typical inept Slashdot editing: the data is *encoded* (as the original AvWeb article states), not encrypted. Sure, JPI is an evil company with a history of slimey dealings as shown here http://home.earthlink.net/~timrv6a/jpi.html but lets be accurate about what they've done. If JPI (or someone else) was to provide info on the format of the encoded data there would be no news story.

Re:proprietary lock in?

[hsenag]

The right way to achieve that would be a digital signature, not encryption.

The encryption is for MSOffice-style lock in

[Anonymous Coward]

I own a JPI Engine analyzer in my plane. To respond to some misinformation above, they make various model of engine analyzers used in piston engine planes. The plane does not depend on the JPI to fly. It's used to gather the parameters from the engine as it runs for instant and with some models, stored for later analysis. It does warn of problems with the engine like overheating. The major feature is assisting with leaning the air/fuel mixture going to the engine, which pilots must do manually.

In a nutshell JPI's owner has some vendetta against a competing company that was selling software to read and analyze the data from the JPI analyzer. JPI changed the format of the data output from the serial port of the device, and the format it was stored in the device's non-volatile RAM.

JPI had sold software for Palm OS that would connect to the serial port and display the data in graphical format in real time on a Palm Pilot. Since the data stream was ASCII text you could do the same with any laptop.

JPI had also supplied what at first they sold, but later became a free DOS utility called EZ-Save that would download the data and uncompress it to a comma separated plain text file. They also made available some Excel spreadsheets with macros that would turn the data into some nice charts for easy analysis.

At some point recently the owner got bug up his backside about some competitor that is selling a competing program to analyze the data. JPI changed the steam and the stored data on current products to use encryption and removed all traces of the utilities on their web site. Of course this did not affect the 1000s of products already installed in planes. What they were doing though, was updating the firmware on any that came in service to have the encryption. Based on that, I vowed I wouldn't send mine in for repair if it burst into flames.

Some excerpts from a aircraft owner mail list:

JPI has recently made a decision to prevent the download of raw data from their EDM series of engine monitors. In the past, an EDM user could use a free piece of software, called EZSave, to transfer all the saved engine performance data from an EDM to a PC. The information was decoded and then stored in a plain text file as numerical values separated by commas (commonly called "CSV" format). This simple format made it possible to import this data in to most any software product, including Excel or any other graphing program. But recently support for EZSave was withdrawn and the program disappeared from JPI's website. In its place was a free version of JPI's fancy engine data graphing program, EZPlot. At the same time this was done, the firmware on new EDM units was updated to alter the data transfer format (from EDM to PC) so that existing copies of EZSave would no longer work. The result is that only EZPlot can talk to new EDM units, and EZPlot does not provide any way to save the raw data. This locks the user in to viewing the data only in ways that EZPlot allows. If you don't like the way EZPlot shows data, you are pretty much out of luck. Existing units in the field continue to work the way they always have, of course. But should you ever send your unit in for repair, it is likely that it will be "upgraded" with the latest firmware and EZSave functionality will be lost.

This change puzzled me a bit, as it seemed to have no purpose other than secure an additional revenue stream for JPI (the feature-full version of EZPlot costs money) at the expense of interoperability. It also seemed designed to intentionally shut out a competing engine analysis program called EGTrends. Personally I don't care for either of those programs: I want the raw data so that I can graph it in a manner than makes sense to me. Oddly enough, the way in which I like to view the data is very similar to the way used by EZPlot's predecessor: a primitive (but effective) Excel template that JPI distributed years ago. So I decided that while I was at Sun 'n' Fun I would go talk to someo