By Cardin Pelletier 1098471
#512570
Ross Carlson 887155 wrote:
Cardin Pelletier 1098471 wrote:Any thoughts?


My thoughts are that this is mainly a side-effect of users doing something they shouldn't. They shouldn't connect using callsigns with a hyphen, and they shouldn't connect using callsigns with invalid airline code prefixes.

I suppose I could modify the clients so that if you assign a code with "QB UAL123" and then later a target appears with some other callsign (such as UNITED123) squawking the assigned code, and that callsign (UNITED123) doesn't already have a code assigned, it would grab UAL123's code and assign it to UNITED123, and then the track would auto-initiate. I haven't thought this through enough to say whether or not it could cause unexpected problems such as with pilot's accidentally (or willfully) "stealing" each other's beacon codes.

Thoughts?


Ross,

I agree. Having users sign on to the network with the proper 3-letter airline ID would certainly reduce the amount of occurrences. However, there would still be the issue with tactical callsigns and callsigns from fictitious organizations. For example, if an aircraft calls me up as "Guard 245", I would most certainly enter the callsign as "G245" if I didn't know that the aircraft callsign was part of the Northwest Air Guard unit and uses the "NWAG" callsign and, thus, should be entered as "NWAG245".

Out of curiosity, Ross, would it even be possible to have a controller client completely ignore the callsign that the pilot signed on to the network with? For example, if the system does not find a flight plan for a QB'd ACID, the system would create a FP for that callsign, assign a beacon code to it, and simply look for and begin tracking the aircraft squawking that code? The next logical question would be, "What if two aircraft are then squawking the same computer-assigned code?" I'm not sure exactly how the real-world system handles that. I assume the first aircraft the system picks up will acquire and "CODE" will be displayed in the DB, signaling that there is a code conflict.
By Ross Carlson 887155
#512592 Yeah, it's certainly possible to correlate a target with a callsign strictly by beacon code, but I do think it would cause problems in some cases, one of which you described. I'm not sure how the real system behaves in these situations where there isn't also a flight plan to help predict the location of the aircraft.
By Dhruv Kalra 878508
#512624
Ross Carlson 887155 wrote:I'm not sure how the real system behaves in these situations where there isn't also a flight plan to help predict the location of the aircraft.

You get a free track instead of a FLAT. If a free track goes into CST status at any point, it coasts along on the last computed track and ground speed, as opposed to a FLAT going CST, which coasts along the flight plan route at the last computed ground speed.
By Ross Carlson 887155
#512678
Dhruv Kalra 878508 wrote:
Ross Carlson 887155 wrote:I'm not sure how the real system behaves in these situations where there isn't also a flight plan to help predict the location of the aircraft.

You get a free track instead of a FLAT. If a free track goes into CST status at any point, it coasts along on the last computed track and ground speed, as opposed to a FLAT going CST, which coasts along the flight plan route at the last computed ground speed.


Yeah I figured it would be a free track since you can't have a flat track without a flight plan. What I'm wondering about is the track correlation logic. As I understand it, if a callsign has a flight plan, it will only auto-acquire a track if the target is squawking the assigned code and it appears to be on or near the flight plan route. Without a flight plan, is there any position-related logic, or will it auto-acquire to ANY target within range of ANY radar site in the entire ARTCC as long as it is squawking the right code? Maybe it only acquires targets that are within the airspace for the sector that assigned the beacon code?
By Dhruv Kalra 878508
#512682
Ross Carlson 887155 wrote:Without a flight plan, is there any position-related logic, or will it auto-acquire to ANY target within range of ANY radar site in the entire ARTCC as long as it is squawking the right code? Maybe it only acquires targets that are within the airspace for the sector that assigned the beacon code?

As far as I know, ERAM will search the entire center's AOR for the beacon code.
By Ross Carlson 887155
#512683 Cool ... so the question is whether or not we want to have vERAM associate tracks with targets where the callsign doesn't match.

And once the beacon code correlates the track with the target, should vERAM update the ACID on the track to match the callsign of the target? If not, vERAM will need to maintain an internal mapping of controller-entered callsigns to the actual pilot-entered callsigns so that it can translate when doing things like sending a flight plan, starting track, sending a handoff, etc.
By Dhruv Kalra 878508
#512684
Ross Carlson 887155 wrote:And once the beacon code correlates the track with the target, should vERAM update the ACID on the track to match the callsign of the target? If not, vERAM will need to maintain an internal mapping of controller-entered callsigns to the actual pilot-entered callsigns so that it can translate when doing things like sending a flight plan, starting track, sending a handoff, etc.

I suspect that having it do the internal mapping would be nice in that it would pave the way towards such things as being able to synchronize ACID/CID data across vSTARS/vERAM clients as well as allowing us to rid our scopes of the DELTA123s of the world :P
By Ross Carlson 887155
#512685 It doesn't pave the way for those things ... those things are still just as complicated with or without this sort of mapping.

I'm also wondering if having a mismatch between what the controller sees and what the rest of the world sees could cause problems such as when coordinating with other controllers or when hailing a SUP.

I'm definitely leaning toward having it change the ACID within vERAM.
By Cardin Pelletier 1098471
#512770
Ross Carlson 887155 wrote:I'm also wondering if having a mismatch between what the controller sees and what the rest of the world sees could cause problems such as when coordinating with other controllers or when hailing a SUP.


This is what immediately came to mind as one of the challenges of having a controller client work in this manner. I would say, a vast majority of the time coordination would not be affected as most of the time we are dealing with the difference between a DAL123 and DELTA123. Regardless of whether the next controller sees "DELTA" or "DAL", we're both going to be on the same page. I'm not sure about how it would work with the SUPS either -- that's another thing. Having the system automatically correct an incorrectly-entered ACID based on squawk code and flight plan correlation sounds like a good compromise. The only issue I would imagine could come from that is if the system corrected the ACID mismatch to one that a controller didn't recognize. I'll use "NWAG" as an example again because it's one of the more obscure callsigns used. Assuming I'm not familiar with the callsign, I'll assign "G" as the ACID when the aircraft calls up as "Guard". If I get a track with NWAG, I may be left scratching my head especially if I'm busy and I'm subconsciously keeping an eye out for a "G".
I suppose one way to resolve this issue would be to allow the callsign the pilot signs on to the network with to be only a 'preferred callsign'. The callsigns would have to be editable by the controllers. The preferred callsign could be kept in the background so that SUPs and other controllers could reference the aircraft by it. When a controller QBs for a ACID, the system would look for an aircraft squawking the associated code with the FP. Once it sees that code, it would change the aircraft callsign to whatever the ACID associated with that code is and start a track. The system would keep the preferred callsign in the background so it can be referenced by SUPS or other controllers. Once a preferred callsign is changed, the new callsign would be displayed.
By Ross Carlson 887155
#512776 The different proposed solutions each have their advantages and disadvantages, but I think that any solution that involves changing the actual callsign to the one the controller entered with the QB is going to have consequences that are hard to predict ... things we can't even think of right now. So I think that if I make any change at all here, it will be to have the displayed callsign be the one that the pilot actually entered. So there may be cases where the controller is confused by the change (such as your guard example) but I think those will be few and far between, and such issues are isolated only to the controller ... they don't spill out to other controllers, sups, etc.