Planning ahead for retiring VRC

[Ross Carlson]

I've considered adding a plugin system, and that may happen at some point in the future, when the client is well out of the beta testing phase. Giving plugins access to things like the flight plan database would be pretty easy. Providing access to draw on the scope gets a little more tricky, given that the client is multi-mode (ERAM, STARS, ASDEX, Generic) and there can be any number of displays in any of those modes, each one potentially using a different facility definition. The plugin API would have to include some deterministic way for plugins to directly address a specific radar display. It's certainly doable, just needs some thought and creativity. :)

[Karl Mathias Moberg]

Yeah, a plugin interface is what has made Euroscope so incredibly useful in a lot of situations and will give it life for a long time. Things like being able to have a plugin to interface with the HOPPIE ACARS network would be my absolute biggest reason to want to move to this new client in a heartbeat. As a pilot flying in Europe, I love being able to get PDCs and use CPDLC in the air, but having to use the 3rd party client now with ERAM and STARS, it's just not doable. Having a plugin for it, like they have in Europe would be amazing.

[Richard McDonald Woods]

Karl,

I believe that both PDC and CPDLC will be available once pilot clients, scopes and aircraft are equipped, using GFO or equivalents. There may be less incentive in developing plugins to Hoppie ACARS with such developments on the horizon.😃  

[Adam Victoria]

I hate to ask Ross, but any updates on CRC? I know it's been a few months and this kind of thing takes a lot of time to code, but I'm dying for an update! Have you thought of making a thread dedicated to CRC and its progression? I think a lot of people are interested in CRC, I know I am!!

Edited February 10, 2022 at 08:32 PM by Adam Victoria

[Ross Carlson]

It's still progressing, slowly. Still months away from any sort of testing phase.

[Alex Ying]

Something to add to the eventual feature request list: Would there be a way to temporarily store tracks after an unintentional disconnect (dropped by network or a server crashes) to make recovering from them easier, or at least have an "easy mode" like in VRC to rapidly pick tracks back up? We've run into issues before where someone using vERAM gets dropped by the network and it just takes a very long time to try to recover all of your tracks while still trying to work traffic.

[Ross Carlson]

7 minutes ago, Alex Ying said:

Something to add to the eventual feature request list: Would there be a way to temporarily store tracks after an unintentional disconnect (dropped by network or a server crashes) to make recovering from them easier, or at least have an "easy mode" like in VRC to rapidly pick tracks back up? We've run into issues before where someone using vERAM gets dropped by the network and it just takes a very long time to try to recover all of your tracks while still trying to work traffic.

That has been discussed. Most likely a one-click track option will be the way to go.

Note that I will not be reviewing this thread after CRC releases, looking for feature requests, so any feature requests here will be lost.

[Daniel Kormendy]

Hey Ross, 

 

Are you planning on developing a MEARTS function of CRC when it officially comes out? I know both Alaska and San Juan utilize these as their primary source of radar in their respect facilities.

[Ross Carlson]

8 minutes ago, Daniel Kormendy said:

Are you planning on developing a MEARTS function of CRC when it officially comes out? I know both Alaska and San Juan utilize these as their primary source of radar in their respect facilities.

I am not, no.

[Bernardo Reis]

Are you planning on an oceanic part for the folks in the oceanic facilities?

[Ross Carlson]

3 minutes ago, Bernardo Reis said:

Are you planning on an oceanic part for the folks in the oceanic facilities?

What do you mean by "an oceanic part" ?

[Bernardo Reis]

3 minutes ago, Ross Carlson said:

What do you mean by "an oceanic part" ?

Mainly oceanic tools. I assume this software would be more directed towards the US, so a set of tools similar to those of FAA's Ocean 21 software used in New York, Oakland and Anchorage Oceanic.

I'm sure there are plenty of guys in the US with knowledge of it (I don't control in the US so it wouldn't be me benefiting directly from it, but as an oceanic controller, I feel the lack of builtin robust tools to help us manage airspaces with increased seperation minima and reduced communication/surveillance capability) that can tell you more than this presentation I could find: https://present5.com/nextgen-now-ocean-21-the-future-of-oceanic/

[Ross Carlson]

Ahh, no, I have no plans for that.

[Jake Saw]

9 hours ago, Bernardo Reis said:

Mainly oceanic tools. I assume this software would be more directed towards the US, so a set of tools similar to those of FAA's Ocean 21 software used in New York, Oakland and Anchorage Oceanic.

I'm sure there are plenty of guys in the US with knowledge of it (I don't control in the US so it wouldn't be me benefiting directly from it, but as an oceanic controller, I feel the lack of builtin robust tools to help us manage airspaces with increased seperation minima and reduced communication/surveillance capability) that can tell you more than this presentation I could find: https://present5.com/nextgen-now-ocean-21-the-future-of-oceanic/

There are profiles for ATOP Anchorage and Oakland available for vatSys (and being actively developed). vatSys has a suite of procedural separation tools and is well suited for oceanic

[Ross Carlson]

Time for an update on CRC design and development progress:

I've been making a lot of progress over the last couple months. Here's what is currently complete:

• The ability to create profiles and add/remove displays.
• All the UI for configuration/settings.
• The ability to import ARTCC configuration data from the ARTCC web site with a single click.
• Automatic updating of ARTCC configuration data when the FE releases a new version.
• Automatic updating of nav data and aircraft data.
• The ERAM, STARS, and ASDE-X radar modes.
• STARS fusion mode. (Still 5 second update rate though.)
• The controller list.
• The tabbed messages area.
• The flight plan editor.
• Assigning CIDs from the "CRC Server" so that everyone in an ARTCC sees the same CID for a given aircraft.

Here's what is currently under development:

• Assigning beacon codes from the CRC Server from the NBCAP or from beacon code banks that are internal to a given terminal facility. (FEs will maintain these code banks by uploading a data file through the ARTCC Editor.) This will eliminate issues we've had in the past with duplicate beacon codes due to non-overlapping vis ranges. I'm about 50% done with this feature.

Here's what remains to be done:

• Aircraft list. This was originally going to show arrivals and departures, but it will likely only show departures since that is what is most needed operationally. (Some users said they like to see arrivals in the aircraft list in VRC so that they can gauge upcoming traffic levels, but there are other tools for that like any of the mapping tools.) The aircraft list will also show anyone that is on your reminder list or that have a countdown timer running.
• One second update rate in STARS and ASDE-X modes.
• Flight strip bay.
• Tower Cab display mode. (More on this below.)
• Tower view proxy server.

A big change, design-wise, is that I've decided not to have a Generic display mode in CRC. The original reason for including a Generic mode was for situations where it wouldn't make sense to use ERAM, STARS, or ASDEX mode, such as when you're working a cab position (DEL/GND/TWR) at an airport where there is no ASDE-X in the real world. 

However, as I started to think about how the Generic mode would work, and how to make it flexible enough for use across all levels of controlling from DEL up to CTR, with all the varying needs for video maps, data blocks, etc, I realized that it would be a lot of work for not much payoff in the long run, because a lot of the work would be duplicating functionality that already exists in the other radar modes.

So, instead of Generic mode, I'll be making a Tower Cab mode that is focused specifically on providing whatever a controller needs when working a cab position. The design concept is that it replaces the real-world controller's ability to look out the window and actually see the aircraft. As such, it will have aircraft icons (similar to ASDE-X) so that you can see which direction the aircraft is facing. It will have a 1 second update rate initially, and ultimately it will have a real-time update rate using Velocity data. I'm not sure yet what the data blocks will look like, but I might provide a few options that the user can choose from, such as the Simple, Ground, and Tower data block types from VRC.

When creating and maintaining ARTCC data files for CRC, FEs will create a video map for each towered airport in their ARTCC. This video map will include the ground diagram (either in outline form or using filled polygons, at the FE's discretion) as well as any surrounding features such as coastlines, visual reporting points, extended centerlines, etc. This video map will be used when the user selects Tower Cab mode for the display.

This all means that ERAM will be the only option for working center positions, and STARS will be the only option for working Approach/Departure positions. I know there are a few users that won't be happy about that fact, and they just want to use VRC and don't care about the realism of ERAM/STARS. I've heard from one or two such users already since I announced that VRC will be retired. However, I've heard from a far larger number of users that have reluctantly moved to vERAM/vSTARS and found it to be nowhere near as difficult as they assumed it would be. I am confident that any controller that has progressed to the ability to work APP and CTR will have no problem getting used to the ERAM/STARS interfaces for working traffic. Indeed, the syntax for the most common functions is nearly the same as VRC.

This leaves the issue that vSTARS and vERAM can be a little clunky when working top down. I was planning to address that through new/modified functionality in the ERAM and STARS modes in CRC. That has not changed. It remains a primary design goal of CRC for it to be suitable for comfortably and efficiently working top down from a single screen. For example, you'll be able to see ground targets in top down mode anywhere, not just ones that are near one of the airports in the STARS airport list. You'll be able to call up the flight plan editor for any aircraft, even ones that are airborne and not yet squawking their assigned code. And you'll have the aircraft list which doesn't exist in vERAM/vSTARS.

Lastly, I'll be adding functionality to make it easier to start track on aircraft when you first plug in on a position, or if you come back after an unintentional disconnect. I'm not sure yet how this will work exactly, but it's definitely an issue that needs to be addressed. There will be some way to do a single-click track similar to VRC, regardless of whether or not the aircraft is squawking its assigned code.

That's it for now ... feedback welcome!

[Dominic Nguyen]

On 3/20/2022 at 11:26 AM, Bernardo Reis said:

Mainly oceanic tools. I assume this software would be more directed towards the US, so a set of tools similar to those of FAA's Ocean 21 software used in New York, Oakland and Anchorage Oceanic.

I'm sure there are plenty of guys in the US with knowledge of it (I don't control in the US so it wouldn't be me benefiting directly from it, but as an oceanic controller, I feel the lack of builtin robust tools to help us manage airspaces with increased seperation minima and reduced communication/surveillance capability) that can tell you more than this presentation I could find: https://present5.com/nextgen-now-ocean-21-the-future-of-oceanic/

A New York one is in the works.

[Bernardo Reis]

6 hours ago, Dominic Nguyen said:

A New York one is in the works.

You have to teach me, I would go and do one for Santa Maria 😄

[Dominic Nguyen]

14 hours ago, Bernardo Reis said:

You have to teach me, I would go and do one for Santa Maria 😄

I'm not too sure what Santa Maria/Gander uses, but I'm sure it's similar and has ATC concepts that are modeled in vatSys. Jake does a pretty good job on that. I don't want to steal the limelight from this thread, but you can start here https://github.com/vatSys https://virtualairtrafficsystem.com/

[Ross Carlson]

I've made another major design change for CRC, this one even more impactful than the last. So it's time for another development update.

Ever since I developed vSTARS and vERAM and learned a lot about how the real STARS/ERAM systems work, I've wanted to build my own server that the clients would connect to, instead of connecting directly to the VATSIM FSD network. This server would in turn connect to the FSD network in order to get a feed of all aircraft locations and their flight plans. This architecture would allow me to simulate how the real systems work to a far greater degree of fidelity.

After numerous discussions with other developers that are helping with this project, and discussions with many VATUSA ARTCC staff members, I've decided that I'm going to take this approach with CRC. All logic for radar data processing, flight data processing, controller command message processing, conflict detection, etc. will be moved to the server. The CRC client will not have any "logic" at all, it will just be a UI showing the state of things on the server.

The following is a list of some of the main benefits that this new approach will provide:

• Users will sign into positions, not callsigns. - FEs will define positions within each of their facilities, and CRC users will choose which position they are signing into. Users will not need to type in a callsign or primary frequency, as those things will be determined automatically by the server, based on the selected position.
• Multiple users can be signed into the same position. - This is to facilitate shift change, observing, and student/instructor scenarios. When one user makes a change such as initiating/accepting a handoff, that will be reflected on any other scope for the same position. Even small changes like the position of a data block will be mirrored across all scopes for the same position. Just like how the real systems work.
• Shift change will not require handoffs. - When you sign into a position to relieve another controller, you automatically have track control of all their aircraft, because it's the same position. No need for the first controller to hand off aircraft.  All data blocks will be in exactly the same position for the incoming controller as they are for the outgoing controller. When the incoming controller is ready to take the position, they will enter a command or press a button to declare "my control". It'll be just like the real world when a relieving controller sits down at the same physical scope for the relief briefing.
• Track state will be properly shared. - All track state data (ERAM CID, scratchpads, ERAM 4th line data, temporary altitudes, handoff state, pointout state, etc.) will be stored on the server, within the simulated STARS/ERAM "computer". Track state data will be shared among positions within the same simulated computer, and will only transfer to other facility computers where it is appropriate and realistic for that to happen. You will be able to see a handoff occurring between two other controllers, just like you can in the real systems.
• Realistic beacon code assignments. - The server will assign beacon codes based on the real world NBCAP. (National Beacon Code Allocation Plan.) TRACON facilities will have their own internal code banks for flights originating and terminating within the facility.
• Recovery after unintentional disconnect. - If you lose your connection due to a client crash, brief power failure, etc. you will be able to reconnect and all your tracks with all their state will be intact, because it will be maintained on the server while you were disconnected. If you aren't able to reconnect and sign back in, another controller can sign into your position and take over, or the system will automatically drop your tracks after a certain period of time.
• Third-party tools can connect to the server. - Tools such as a simulated EDST or FDIO can connect to the server and sign into a position, allowing e.g. ERAM controllers to have a "D-Side" console using software external to CRC. You will even be able to provide D-Side services to another controller. The third-party applications will have full access to the server data, without needing a regular FSD connection.
• Server-based radar simulation. - The server will have a map of radar coverage for each facility. This map will be pre-generated based on real world radar site locations, facility surveillance coverage areas, and terrain. If an aircraft is flying in a valley where there is no radar coverage, you won't see it. This surveillance coverage map will also incorporate real world ADS-B coverage.

That's a list of things that will be in the initial release version, and this new architecture will pave the way for many more highly-realistic features in the future.

This probably goes without saying, but this is a very significant increase in the scope of work required to bring CRC to an initial release version. I was originally targeting an initial release date some time in the summer of this year, but with this change, I think an initial release is more likely to be toward the end of the year or even early 2023. It's very hard to say how long this will all take, because it's such a major change, but late 2022 or early 2023 is a good guess as to the absolute earliest time frame for anyone to expect release. As with any sizable software project, that date is likely to slip multiple times. I hope you'll all agree that the benefits listed above will make it worth the wait!

[Bernardo Reis]

Incredible @Ross Carlson, exactly what the network needs to keep moving forward and keep being relevant for years to come!

I think I know the answer, but do you see any possibility in using the same baseline you are developing for a next-gen ATC client for Europe? That is, someone develops an European CRC alternative that connects to the same server.

[Ross Carlson]

1 hour ago, Bernardo Reis said:

I think I know the answer, but do you see any possibility in using the same baseline you are developing for a next-gen ATC client for Europe? That is, someone develops an European CRC alternative that connects to the same server.

Since the server is going to be based heavily on the real world ERAM and STARS systems, I don't think it would make any sense to connect a European client to the server. That being said, there may be some opportunities for code sharing. For example, the Virtual NAS server (that's the working title) will be compartmentalized such that one component talks to the FSD network and receives aircraft positions and flight plans, and another component handles flowing data back and forth between CRC clients (and third party clients) and another component handles emulating all the data processing that happens within a single ERAM or STARS computer. It would be fairly straightforward to just change that last part and instead of emulating ERAM or STARS, it emulates TopSky or some other system.

We could put all of these different emulation layers into one big server that covers all of VATSIM, but it would probably make more sense for each region/division to have its own server. They could still communicate with each other at their boundaries if there was some data flow between those regional systems in the real world.

[Bernardo Reis]

2 minutes ago, Ross Carlson said:

Since the server is going to be based heavily on the real world ERAM and STARS systems, I don't think it would make any sense to connect a European client to the server. That being said, there may be some opportunities for code sharing. For example, the Virtual NAS server (that's the working title) will be compartmentalized such that one component talks to the FSD network and receives aircraft positions and flight plans, and another component handles flowing data back and forth between CRC clients (and third party clients) and another component handles emulating all the data processing that happens within a single ERAM or STARS computer. It would be fairly straightforward to just change that last part and instead of emulating ERAM or STARS, it emulates TopSky or some other system.

We could put all of these different emulation layers into one big server that covers all of VATSIM, but it would probably make more sense for each region/division to have its own server. They could still communicate with each other at their boundaries if there was some data flow between those regional systems in the real world.

Promising for sure. Just need some devs to take it further now 😅

[Zachary Beard]

What a cool roadmap! 

[Harry Sugden]

This sounds awesome, and it will also leave the rest of the world behind in the dark ages! 😞

A few ramblings…

How does this all fit into the existing network architecture, as I remember there being a slight headache coming up with a solution for pseudo callsigns, which was floated as an idea alongside AFV cross coupling?

I noticed some informal comments relating to a future FSD in Discord (https://discord.com/channels/703923823887515720/743651318828105788/963185556785868921). How can the ideas for CRC either influence or be shaped alongside conversations around a network-wide change in architecture? Can we move the whole network forward and not just a region, whilst keeping legacy clients compatible before everywhere has people who are working on ‘clients for the future’?

I’m glad you mentioned code sharing! From my position as a non-developer in Europe, I see so many fragmented plugins with similar features that could, I’m sure, be shared and coordinated rather than started on from scratch!

[Ross Carlson]

Big questions there, Harry. Would take an essay to answer. 😀