After about 20 years with an unchanged ACARS network (at
https://www.hoppie.nl/acars/), it may be time to consider some minor technical changes that nonetheless feel like a landslide.
When I built this ACARS system it was predominantly for the WorldFlight events, and only for Aerowinx PS1. As WorldFlight started to expand, the air traffic controllers and dispatch offices started to serve plenty more aircraft and of course only a small minority could use the PS1 ACARS. So I provided some non-PS1 assistance programs. With ACARS still being considered a nerdy backward system compared to the all-new voice comms (remember RogerWilco?), pickup was slow, but it started to grow. The unavailability of dedicated in-sim support for MSFS was of course not helpful.
Twenty years later things look different. On a normal weekend, the system processes easily over 15,000 messages and with over 6,000 active accounts (active in the last three months) it can be considered quite alive and kicking. Nearly all ACARS access is through client programs that I did not write myself, and it is becoming a completely accepted and embedded way to do dispatching and CPDLC. I know that the virtual airspace networks are all thinking about their own ACARS subnet, but developments are slow, probably because it already works so well (the network effect).
That is, until the virtual airspaces start to overlap. I explicitly did not build support for more than one subnet within the same system, as WorldFlight was on VATSIM, and deep within myself I hated having to support multiple subnetworks just because people could not agree on one open sky. My attempts to keep SB747 (R.I.P.) alive for both VATSIM and IVAO stranded after a year or two of hopelessly running after two diverging server backends. I just gave up.
However the last year saw a multiplication of ACARS use, probably driven by the pickup of CPDLC both in the US and in Europe, and now it happens just a bit too often that the same FIR or airport is online with more than one virtual subnet and thus controllers step on each other. And since neither subnet will consider merging their airspace with the other subnets, I think this can be solved by a minor addition to the ACARS system: an
affiliation per account.
PROPOSALAn ACARS account (logon code, in my ACARS terminology -- not to be confused with the CPDLC logon that came later) can be affiliated with at most one virtual airspace subnet.
The default for each existing and new account is
no affiliation. This changes nothing so it is safe.
A new web page will be created to manage an ACARS account. After login, using the normal logon code and the associated name and e-mail address, the only choice will be the virtual airspace subnet to affiliate with. The selection can be left or made blank, which means no change to the current situation.
In the future I may add options to change name or e-mail, and to request a new logon code, etc. but these are not currently required to make the system move.
If an account (logon code) is affiliated with a virtual airspace subnet, then two things happen:
1. The account will only see messages that come from that virtual airspace subnet.
2. Only stations within that virtual airspace subnet will see the messages from the account.
This implies that now two stations may have the same callsign, as long as they are not affiliated with the same subnet.
Before I start breaking code, I would like to invite comments on this proposal.
Hoppie
