All,
I’m writing you from ASA603 headed back home from vacation so easy on the meter times 😂. Since I’ve been out for a week, I don’t have much for you.
Matt Dippe attended a briefing on DATA Comm for me last week and I have attached his notes below under the DATACOMM header. Sounds like interesting stuff. Be sure to ask him with any questions regarding DATACOMM.
Meter Arcs
Having 3 metering arcs between the D and B areas has caused a few issues recently. TMU would like to look into making this one arc. They can make segments of each arc that can be sent to different sectors. Would you guys rather extend OP1 or OP3? The issue for us would be that 15 will be metering to an arc inside the B area with OP3, or that 14 and 13 will have less time to meet their delay if OP1 is extended. Let me know what you guys think.
DATACOMM
The system is slated to go active 11/22/2019, and there will be a lot of training leading up to launch. ZSE is the last facility to go active so they feel that it'll be pretty straight forward as most of the kinks will already be worked out. Also most air carriers and corporate will be equipped, and up to speed on the system by the time we go active, so hopefully it'll be painless for us and the air crews. The major airports in the US have been using CPDLC for over a year now and they've had great success with it. The agency gave 3 years to implement 61 towers with CPDLC, and they activated all of them within 1 year, saving 90 million in funds. They then took those funds and began working on the enroute implementation. CPDLC airports are called TDLS (Tower Data Link Service), that'll be important later. Currently SEA and PDX are TDLS equipped. There are two companies providing service coverage for use of CPDLC, and they are AIRINC and SITA (think of them like ATT and Verizon). Both companies provide three levels of bandwidth, VDL-2 (the best), SAT, and 1X (the worst). VDL-2 and SAT will be the two signals our aircraft will be using, but in an emergency 1X can send data but it'll be spotty and slow. There is a program that monitors these coverage signals called NIS, and either OM's, SUP's, CIC's or all will have access to verify that data link coverage is working for the area. If there is an outage, AIRINC or SITA will be financially penalized for every outage lasting longer than four hours, so the agency feels that the system will stay up.
CPDLC Capabilities
With CPDLC we'll be able to send climb/descend clearances, direct fixes/reroutes, crossing restrictions (with speed assignments), transfer of coms, and termination of radar. The climb/descend function will also have a subset option for PD, expedite, immediately, for WX, for restriction, for traffic. We cannot assign headings, speeds, and free text won't be available until later updates, once the system is 100% developed. When you descend an aircraft via CPDLC below FL180, then data link will issue the altimeter with the descent message. It uses one of the two altimeters from the sort box where the aircraft will be expected to descend below FL180. Routes get a little more complicated. It's easy to send an aircraft direct a fix on their route or issue a reroute that rejoins the original flight plan. It's also easy to uplink a track ball picked route, then tie that route back into the flight plan. But when you try to do a route amend function, or uplink a 6 7 10 message the system will reject it. Arrivals have another issue that'll affect the other areas, I'll show you that in person. The route function with CPDLC is probably going to be the best part for enroute. We uplink RYANN.J92.BTY, the pilot selects "WILCO", our system then shows that as the aircraft's new route, the pilot then selects "LOAD" on the FMS, and the new route is automatically loaded into the aircraft's FMS route structure.
CPDLC Comms
This will probably be the most used function for us. The controller can elect to send a CPDLC message to the flight crew to transfer communication to the next sector once the receiving controller has accepted the handoff. Lets say sector 46 flashes ASA140 to sector 13. When sector 13 takes the handoff, the 46 controller can now send ASA140 over via CPDLC. Based on the sector 13 controllers pref-sets, one of two things will happen. One, the 13 controller wants the plane to use voice to check in, so ASA140 gets this message, "contact Seattle center on freq 135.35". ASA140 gets the message, "Rogers" it via the FMS, sector 46's VCI and data link icons disappears from the data block. Sector 13's data link icon appears in the data block, and the pilot checks on using voice. Now the 13 controller needs to click on the VCI indicating that ASA140 is on freq. The other pref-set option goes like this. Sector 46 flashes ASA140 to sector 13, 13 takes it, the aircraft gets this message, "monitor Seattle center on freq 135.35 and verify assigned altitude". Now sector 46's data link and VCI icons disappear, sector 13's data link and VCI populate, and the pilot doesn't check on, but is there. The pilot must also select one more button on the FMS verifying the aircraft's altitude. If for some reason the aircraft and our radar doesn't match, we'll get an indication on the data block indication that we need to use voice to verify ASA140's altitude.
DATA Blocks
The data blocks will have a bunch more symbology, however most are there to inform either the pilot or the controller to take action. The only new constant symbol will be a white square above the VCI indicating that data link is connected and functioning. We cant use data link to a coast track, but we can use it if the target was tracked at one point in the sector and then went radar lost. If this is that case the controller will have to use a logic override to send a CPDLC message to the aircraft. The developers said that they wanted ADSB or radar monitoring of aircraft while issuing CPDLC clearances, that's why the logic check for a radar lost aircraft.
Oceanic/ATOPS
We will be able to use CPDLC for all oceanic aircraft, and send a termination message with the HF freq's to the aircraft. This was of some concern during the meeting because they said that only one sector can use CPDLC at a time, and ZOA 7 usually needs to be connected to our oceanic aircraft to use D10/30. The techs said that it's ok because they still get ADSB data allowing them to calculate oceanic separation. this should be a total game changer for mid ops.
Local Ops
A lot was left for us to determine at the local level with regard as to how data com is used. There are some serious items that need to get sorted out such as the keyboard. All data com uplinks (to the plane) can be done from wither the D-side or the R-side via a few clicks or a /U message. We have the option to swap out one of the space keys above the numbers for a "/U" crud input. If we use that, the controller will need to type the message hit the "/U" key and then hit "enter". The other option will be to use the muti-func F12 key. This key is different in that once it's pressed it'll apply "enter" automatically sending the control instruction to the plane. We have two TDLS airports in our center, all other airports don't have CPDLC capabilities off the ground. They will be changing the 7110 to prevent use of data com during critical phases of flight. So what do we do about all those other airports? We'll have to determine a hard deck for the entire center where a data com aircraft will be able to link to the system. This could be 8,000MSL or 10,000MSL. A controller can force a connection to any capable aircraft even if below the data com deck altitude. An aircraft below the deck just wont show on the glass that that aircraft is data com capable. Another one is the Waiver Altitude function, and this was a complicated one that we will be talking more about later on
Coverage
We reviewed worst case scenario coverage maps for each area, and they can guarantee 100% coverage for all high altitude sectors, and coverage down to the approach controls for low altitude. They did tell us that the actual coverage is much better than what was shown to us.
Training
The training for this will be a lot like the implementation for ERAM. Four hours of CBIs, three days of class and labs that must be consecutive. If a controller misses a day or lab problem, then that controller can't advance without retaking the class or lab. Controllers become stale after 45 days, and must then complete a refresher course. The ghost pilots and SGET guys will have to have additional training before being allowed to ghost or make data com problems. Once the SGET person is trained, it'll take that person 3-4 weeks to make the required lab scenarios. For the training cadre, that's a 3 day class, and will have to be trained by national data com personnel. The ERAM drop that'll allow ZSE to begin training will be installed Sep 20th 2018. We can then begin the process of training the workforce then, by Oct 2019 the final workforce training should be closing in preparation for IOC. Once we go live, ZSE will be using CPDLC and air crews will be notamed to respond via voice until the center feels confident that they messages are working appropriately.
Matt’s Thoughts 💭
This system is gonna be bitch'n. Lots of very cool features and capabilities. I personally have some safety concerns about how we are going to locally adapt protocol for using CPDLC. For instance using the keyboard /U function to uplink instructions seems like an easy way to fat finger a CID and send the message to another aircraft you have track control of. What about training? how is the instructor going to make sure the R trainee knows how to control via voice, or prevent a D-side from issuing a dangerous altitude change to a random aircraft. They system goes online in two weeks in ATL i think, and they said that they'll be keeping everyone informed of what they see happening.
Again, big thanks to Matt for doing that briefing for us. Feel free to ask him any questions. I’ll be trying to get up to speed on it all soon as well.
In Solidarity,
Drew