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.
An 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.
Seems a sensible approach, one suggestion would be as 99% of users are using it for VATSIM, that becomes the default with an option to change to another network in the users profile? This would mean that every user wouldn't have to go and choose a network and we end up with a split of users with default and VATSIM selected.
Having had a quick google it would appear that IVAO only jumped on the Hoppie bandwagon in January of this year, hence why it has not been a problem for nearly 20 years.
I would suggest allowing their users to swap to the ivao subnet is needed, but again I would vote for VATSIM to be the default option for existing accounts.... new accounts should get to choose none/VATSIM/IVAO
Amazing how many rely on your network. I also saw it when i bought the A320 from FSlabs, If i see that correctly, their whole ACARS relies on your network in the background as well. Mabe you should send them a hint before you change anything, so they can check if it will affect their systems and have time to react if so...
FSLabs in particular is in contact, I have built an underground auto-registration system for them, and for a few others. As more and more products start building ACARS functionality into the core, they tend to first connect to the "Hoppie" ACARS service as that is probably the easiest and the most used one, to date.
As far as I can see there is not going to be anything at all that clients need to change in their software. I intend to broadcast a few all-stations messages when people can select a subnetwork.
Other issues pop up now, too: the long-forgotten PDC auto-answer function, that was used for busy Worldflight airfields where the controllers had to issue the same clearance with squawk+1 for a few hundred times. It still answers for a few fields :-/
Appreciate you're diving into upgrading the system. I'm coming from the controller side of things, active on VATSIM. I think your proposal to split for different networks is a great step. Although what would really help in our case would be verification of the users that are allowed to open a station. As we've talked about, we've had some reports of unknown people manning a Hoppie station and giving incorrect information to pilots.
VATSIM offers a few ways this can be done.
1) VATSIM Connect
The single sign on system that allows any application/organization to verify if the user has an active VATSIM account and request their ratings. https://github.com/vatsimnetwork/documentation/blob/master/connect.md
> You could consider to do this once when the member affiliates his account to a certain network.
2) Live network data
A more complex, but more precise way to check if the CID that opens a station on Hoppie also has an active network connection on VATSIM. This would allow you to associate a 'station session' to a controller session on the network but would require parsing the live data every x seconds to see if the session is still valid. JSON feed available via https://status.vatsim.net/.
> Although callsign on vatsim and preffered station name on hoppie do not always match.
3) Only allow CID's with a controller rating
Using single sign on and the auth user api to see if the CID holds at least an S1 rating before they are allowed to open a station on Hoppie.
> Simpler to do compared to 2.
I'm not that familiar with IVAO's systems, but i'm sure they have something similar. The challenge is to make sure it remains easy and hassle free for pilots to connect, but putting some steps in place to avoid abuse of the system by random people would be nice.
Hi Hoppie !
Sounds really good and your suggested approach could be a real "game changer".
I'm in charge of the tech part of the French vACC on VATSIM, and we developped our own ATC client for CPDLC. To avoid any subnet issue, we ping/collect 24/7 "LFXX" server-side, and then broadcast and re-route all CPDLC/TELEX messages to the concerned ATCs. So France has a unique ATSU for all enroute CPDLC ops (like KUSA). We were about to adapt this logic to the DCL (PDC).
Niels pointed out a real problem with the actual structure : abuses. Sometimes nasty guys/trolls have fun with creating fake CPDLC messages, and putting trouble in pilot/atc ops.
@Niels, i totally agree with your technical suggestions.
The option 2, could be the most "secure", but always requires a VATSIM active connection, which can block some use cases (like our own use case, described above).
@Hoppie, are you planning to keep the "web form" for sending CPDLC/ACARS messages ? I guess it's the major entry point for abuses, due to the ease of access.
Keeping in mind that these are just discussions for the moment, many thanks for opening the brainstorming about adding a subnet dimension !
At your disposal and open to any related discussions :D
I'll for now just await a bit more feedback, to avoid the rabbit hole of technical design before we have a good grip on the requirements.
This looks like a great change! Datalink usage is growing at a strong rate. At the same time, so is the amount of 'spoofing': pilots claiming they already received a clearance, that doesn't make any sense at all. It seems as if someone is issuing random clearances. So, a more robust user validation service would be more than welcome.
(From a VACC perspective: it is no problem at all to offer an API endpoint to validate if a user is a member. Obviously the VATSIM API offers the same functionality.)
There were a few dozen auto-PDC-s still active, that were never deleted after the controllers left their positions, and there was no expiration date set on them. I manually wiped them all off the system and changed the controller password so nobody can add any auto-reply PDC for now.
I think this will stop most ghost clearances (not all).
Sorry for the delay... real world work got in the way big time.
Today I added the first code towards having the network affiliation as a per-user setting. It is not useful yet but the core of the system now knows the concept.
By sheer coincidence the first user to get this feature was...
Network Affiliation Changes
If there are already people that want to try, please e-mail me and I will manually switch you over from VATSIM to whatever. Note that this does not mean it will immediately filter, but it should get progressively better over the next days. Weeks. Months. You get the point.
Ongoing story. There is a specific user out there who is building an auto-reply system based on real-world data:
AUTOMATED OCEANIC CLEARANCE DELIVERY IS AVAILABLE. IF USING REAL WORLD FLIGHT
CALLSIGN, CLEARANCE IS BASED ON PULISHED ROUTE ON FLIGHTAWARE, ELSE CLEARANCE
ROUTE IS PREDICTED BASED ON ENTRYPOINT ENTERED IN THE CLEARANCE REQUEST.
AVAILABLE EXTRA COMMANDS
(SHOULD BE SENT AS FREE TEXT MSG TO CZQX or EGGX. USE a REAL WORLD CALLSIGN
FOR RFS AND RFR REQUESTS:
RFS: RETURNS REAL FLIGHT STATUS
FLP: RETURNS YOUR COMPUTED FLIGHT PLAN
Obviously this is not an attempt to frustrate everybody else out there, yet it does disrupt operations as there are now multiple competitors for the same ATC position.
I am attempting to contact the person behind this, and hopefully we can solve this issue by declaring another network next to VATSIM and IVAO, or something else.
After you change your affiliation, look at the message log for the effect. Only messages sent by somebody affiliated to the same network should get through to you, and vice versa.
My tests indicate it all works... but...
A most pleasing solution, even better that 99% of users won't have to change anything.
The owner of the automatic clearance delivery bots has been found and is apologizing for any disturbance. As always it was not intentional and it took several months before the problem caused enough smoke for people to notice it. The root cause seems to be a disconnect between the way some VACCs man their stations and the way the bots determined there was a real controller and backed out. There really was an effort made to prevent a station clash.
So consider this issue solved for now, with the network affiliation filter yet another tool in the box, and we're ready for another 20 years of ACARS :-)
Any comments welcome. I had a fun day yesterday digging into this old system again. Should do this more often.
Really appreciate it! Let's hope these strange clearances are a thing of the past. A lot of addon dev's have picked up on your system and have implemented it into their Aircraft. Would be good if the defacto standard acars for online networks can further grow into this new role :).
Many thanks Jeroen for diggingand changing the system.
I know I am a stressy guy, but all we need now is a stand alone VATSIM client for PSX, right? :-)
And a painted Balcony!
Is that one still on your bucket list Gary? BTW, i am still working on your inputs to the guide, but It'll be finished soon...
Simple addition to the system web interface: stations online, grouped by network.
I have little clue what monitor pages are actually useful for ops; so I am not very motivated to spend time on it :-)
If there are Worldflight things that could be fixed/improved on ACARS, let me know.
With the rising popularity of this ACARS simulation, I need to set the record straight for its name...
It is called: "Hoppie's ACARS".
Hoppie is not a system. It's an engineer :-)