Wednesday, July 30, 2014

The Connected Cockpit

The internet of things (IoT) is kind of the current discussion in many publications. The idea behind the internet of things is that everything will be connected to the internet, allowing monitoring and control of those things. As things are going, it is still too expensive to connect everything to the internet, and there many implications of connecting everything to the internet.

Many aircraft are getting WiFi in the cabin, people think the next step is putting an iPad in the cockpit, and connecting to the cabin WiFi and that should do it. Get all the flight plans, updates, weather and other data from headquarters we are all done. The trouble is, and was pointed out in the first post of this blog, there are security thoughts that need to be considered.

On transport aircraft, most of the cockpit is connected. Well connected, in that the FMS talks to the airopilot, and the EFIS may talk to the ACARS system, and the radios share a common bus. The trouble is, the cockpit is not talking IP, so it isn't easy to connect it to the WiFi, and it probably isn't a good idea.

In your GA business jet, it might be OK to connect the cabin to the cockpit. The people in the aircraft are usually well vetted, and may actually own it. They have a serious reason to be riding in the aircraft to the destination. Smaller aircraft may not have the means to get WiFi to the ground, but WiFi or other Ethernet connections could actually be done allowing the GPS to talk to the ADS-B transciever, and the MFD in the panel.

Allowing the cabin WiFi be connected to the cockpit of a part 121 transport aircraft is probably a bad idea. Probably the biggest problem would be if the aircraft were in a place with weak connection to the ground, and bandwidth was limited, who would get priority, the passenger watching Netflix or the cockpit needing a new route around some weather. The marketing department might argue the passengers, but flight operations department might argue the cockpit should have priority.

The other reason connecting the cockpit to the cabin using WiFi is a bad idea would be straight up security. There would be 100 people in the back bored wondering what is going on in the flight. It may be a curiosity for some, or a goal for others, they may just want to look at things, and manage to get access to say the current flight plan, in the FMS, and accidentally adjust it. Sure there could be firewalls and whitelists and other techniques to keep only the cockpit in the cockpit network, but there are ways for others to get in.

Having a separate cockpit connection to the ground is probably the right answer to the security question. having an isolated cockpit will make it harder to keep the cabin people out of the cockpit network.  It will be important to consider all the connections to the cockpit, and how secure they may be. If there is only an unsecured connection to the cockpit, then the cabin can probably still get to it through some ground station. Worse, if the cockpit doesn't have a secure connection to the ground, now there may be thousands of bored people trying to see what is going on in the aircraft.

Security has to be the first thought when building cockpit connected interfaces. Security through obscurity isn't real security, so proprietary standards won't be a long term solution. Bored people look at proprietary standards as a new challenge, and eventually they get figured out. Using industry best practices will be the only way to insure interoperability along with proper security.

It may be that the aircraft cockpits are only connected using one vendor (IE ARINC as things are today), where they provide an isolated network that only they can get to the aircraft. The messages will have to pass though a filter, and have proper originator white lists. All messages would be encrypted such that only known originators and destinations can see and use the messages. Certainly ARINC can't let Southwest Airlines read Delta Airlines messages, as well as some random person on the ground should not be able to sent messages to any aircraft.

It will take a bit of time for things to shake out, but eventually the cockpits will be connected.

Saturday, July 19, 2014

Thoughts On Cockpit Electronics

Recently I was playing an EFB type app. I think I've mentioned it on my other blog, and I am mostly happy with Avare. This app will allow weather downloads, and is a moving map and can display charts of most types (Sectional, WAC, IFR Low and High, etc). It has built in AF/D, can display approach plates, and topographical data.

While using it, I was surprised by a few things, and it occured to me you cannot just buy the latest technology and go out and blindly rely on it. You really need to know how it works, and test it out for a while.

I flew with the Avare app on a Samsung Note 10.1, and found a few anomalies with the system, and I am sure other apps and tablets have similar anomalies. I was testing the app out while riding in the back of a 737, and the GPS was mostly unusable back there. On takeoff it seemed to work well and I could see the acceleration down the runway, and the climbout was displaying nice. But about the first turn, and suddenly the GPS wasn't working at all. No speed, no heading, nothing. Then it was intermittent the rest of the flight.

Avare, like most moving map applications can take another GPS source as the input. There are several manufacturers that offer standalone GPS source devices (IE Garmin). Avare even offers an app you can run on another device (IE phone) to use that GPS source to feed the application. On my next flight, I ran the external app on my phone, and was feeding Avare with the GPS output from my phone. The phone was in my pocket, and I had a window seat, so it worked almost 100% of the flight.

Since the my phone GPS wasn't 100% reliable, it was a good test. I've mentioned Kalman filters in other posts, I wanted to see if this app had any coast mode, where the application would predict the location based on flight plan and last few samples, but it didn't. When the GPS signal was lost, the airplane on the magenta line would point straight north, and stop updating. This by itself was a good thing to know, since GPS isn't 100% reliable in any situation (see the RAIM predication post), and it is good to know what indication is out there when the GPS signal isn't there. When the GPS data was available again, the airplane symbol oriented itself to the flight path the aircraft was following.

Another test I found out about, the hard way, was the chart updating. The charts are generally current for a period of time, some are 28-56 days (IE approach plates) and others up to about 6 months  (IE sectionals). Some of my charts were out of date. The app has a nice feature allowing bulk downloads of charts, but not while out of WiFi range. Most charts are big files, that take a while to download. Even a 737 with WiFi on board isn't the best place to bulk download charts, since most of the flight may have taken place by the time it updates everything (depending on how many plates are out of date). It is best to do the bulk update the day before the trip, to allow time to make sure everything downloads, and the WiFi at the hotel is reliable, the FAA didn't change anything  and everything else works.

Another problem I found, the 10.1 inch tablet might be too big for a cockpit. If I was flying an A380, it might be fine, but even in the seat in the back of the plane, occasionally it got in the way. It would be nice to try an 8 inch tablet next time. The 10.1 inch tablet is about an inch wider than my knee board on all sides. It might be nice to find a knee board adapter for a tablet. Knowing were it is, and what happens when accidentally touched might be a good thing to know. I tapped the screen multiple times on the flight, and sometimes the screen would go off center, I would have to punch the button to set the center again.

Entering a flight plan on the flight was frustrating at best. For the flights I was on, I could look at the route on, and see what waypoints to enter. I was on a flight from DAL to MSP, that stopped in STL. I needed to enter two separate flight plans, which would have worked much better in the terminal rather than in my seat. Then when I got done, I needed to activate the correct one. At first I had forgotten activate the first plan I entered, so the magenta line didn't show up. The Distance Next and Estimated Time Next were updating as if we were flying a single leg flight.

When we began our approach to the middle airport, I thought I could click on the approach plate, and the app would plot the current position on the plate. It didn't, which made sense after I thought about it, since the approach plates aren't always drawn to scale nor have consistent references, and SIDS and STARS never are drawn to scale. The app was smart, since it knew where we were, and punching the "plate" button brought up the correct airport diagram, and I could select the approach, SID or STAR I wanted to use.  A split screen feature might be nice, especially on a STAR.

The weather feature is nice, since it loads most of the standard weather products, (IE METARs, TAFs, PIREPS) for areas along the route. It wouldn't make sense to get a METAR for Chicago if I am going from Dallas to St Louis, and this seems to do a good job. The weather isn't updated if there is no data connection. Some apps will work with a FIS-B receiver, but even those messages may not be as timely as pilots need in a dynamic system. Talking with Flight Service is still the best way in busy weather systems.

I really enjoyed using the app. I can see it being a tool to rely on. I can also see I need to work with it a bit more, and read the manual. Other similar apps are probably just as good, and will need careful integration into any flying procedures. The FAA doesn't allow using handheld GPS devices for primary navigation in IFR conditions, but for VFR, there should be nothing wrong with using this for navigation.

What do you use?