Jump to content

Introducing the ZNY Traffic Management OIS

Recommended Posts

Introducing ZNY’s Traffic Management Unit’s Operational Information System (TMU OIS)




ZNY has developed a web-based application modeled on the FAA’s OIS that provides real-time, up to the minute information about ZNY and partner ARTCC traffic management initiatives; including ground delay programs, ground stops, general airport delay information, in-trail restrictions, reroutes, and deicing operations. This system was designed to be used during periods of high traffic density and severe weather operations. ZNY controllers will monitor this system in order to help efficiently balance demand and capacity. Pilots and dispatchers are also encouraged to monitor the OIS.


For the time being, ZNY controllers will utilize this system to manage intra-ARTCC traffic management initiatives as well as any initiative requested by another ARTCC. Any initiative involving another ARTCC, requested by ZNY, will still be coordinated using the pre-existing channels.


To visit the ZNY TMU OIS go to http://www.nyartcc.org/ois


If you have any questions or comments feel free to contact the Traffic Management Coordinator at [email protected]


For detailed information on how to use the TMU OIS vist http://www.nyartcc.org/bigapple/showthread.php?p=28718#post28718

Alex Evins

Senior Controller, New York ARTCC

Link to post
Share on other sites
I don't get it. What do you need it for? I don't see how this is practical from a VATSIM standpoint. Real world, of course, because they don't have TeamSpeak or communication like on VRC, and this information is vital. It seems like your CIS has a lot of time on his hands, I wish we had that luxury.


This is similar to the ACEIDS system that is in use at NorCal TRACON:




As you can see, this covers the airports in that area's sector, what ATIS information is current, runways in use, NOTAMs that are out, TMU showing the MIT spacing, RVRs, the entire lot.


It would be great to know this so everyone at the TRACON level would know which ATIS info is current at the various airports in their area, plus which runways are in use. Saying this over Teamspeak is okay, but not when you're having to remember it for the entire hour until the ATIS info updates. This would work.


I put together a very primitive PHP version of this with a DB backend, so it can work; I just [Mod - lovely stuff]ped out on time to work on it again..



EDIT: Added Systems Atlanta's IDS5.



Edited by Guest

Brad Littlejohn

ZLA Senior Controller


Link to post
Share on other sites


This is similar to the ACEIDS system that is in use at NorCal TRACON:




As you can see, this covers the airports in that area's sector, what ATIS information is current, runways in use, NOTAMs that are out, TMU showing the MIT spacing, RVRs, the entire lot.




I can see THIS being of practical use, knowing that it displays current pertinent controlling information such as ATIS's and RVR's, etc. What I don't understand is the ZNY script. What if the pilot doesn't want to simulate a ground stop, would they have the option of byp[Mod - Happy Thoughts]ing it?

Link to post
Share on other sites

If it's weather related, then no, pilots are not required to abide by ground stops etc. However, if it is traffic related, then you can have ground stops. If the ATCs want to simulate weather related delays, if the pilot doesn't mind it's okay. If they need to be held for traffic then pilots can't negotiate this.


As for the ZNY TMU "device", I don't think it will really come in handy. Only on unique, extreme traffic situations (Events) will it become useful, but the one that Brad and Steve hinted at can be used in every day controlling use.



Justin A. Martin

Training Administrator




Link to post
Share on other sites

At ZNY we simulate SWAP events and issue Playbook routes. This application provides us a medium to propagate this reroute information to our controllers. Since ZNY has 4 Cl[Mod - Happy Thoughts] Bravo airports in a very small area weather and volume often become a single phenomena that impacts our airspace. Severe weather reduces our capacity, limits our already limited airspace, thus reduces the amount of traffic volume we can handle. This application lets our controllers be on the same page without exhaustive communication and coordination, which helps reduce controller workload. We also have a web-based tool that shows that active runway at all four major airports. Additionally, when weather deteriorates (which is quite often), in-trail separation increases.


Emmanuel Gutierrez (972888)


Link to post
Share on other sites
Just want to toot Cleveland's horn again... Stephen Ogrodowski implemented a version of this in early 2006 to go along with the VATUSA TMU. Speaking of which... is there a VATUSA TMU anymore? I've been out of the loop for a while.





I remember when Stephen did that as we Steven, The TMU along with many other things that were implemented back then are no longer.

Jeff "JU" Turner

US Army Retired




Link to post
Share on other sites

The ZOB system still exists, but is offline. I'm not sure that it's been used for a while. If you go to the zob website (zobartcc.org), hover on Air Traffic Operations and go down to "Status Information" it will pop up. What that does is post some major/important ATIS cycles, MIT/MINIT requirements for any special airports, ARTCCs, or zones, and let's you post NOTAMs or other traffic advisories to cycle. It refreshes every 30 seconds. I wrote it completely in HTML, PHP, and JS.


I think it was about two or three years ago that I developed it (for some reason the post that Steve Perry linked to in our Forum is either gone or blocked off). The idea itself was promising, with a few shortfalls of the time. Some of the webpage interaction was funky. In the original design, it was too difficult to post updates and change data. I redesigned the control panel in a second version, but we slowed down the idea far before. The idea was to use the browser so that people wouldn't need to install a separate computer program, and we could easily maintain everything through the web interface.


1) We had issues on the original system with worrying about the ATIS. Originally, the ATIS was completely static and had to be updated by someone entering data. This made it very unhelpful unless there was someone to constantly update the data, and made it un-useful to use anytime outside of an event.


This actually led to a further idea I had of developing a fully automated, web-based server. I actually developed a PHP system that would automatically download METARs from our servers (for our airports), p[Mod - Happy Thoughts] em and figure out what each piece of data was (APID, time, winds, clouds, etc), then send it to the database if it was a new METAR or data. It would update the current "ATIS" code and data for each airport. Then, on the website portal, you go in, click on the airport you want to see the ATIS for, and it displays it. The idea was that I would have a cron run the script on a timer so that it is always running, completely automated. Unfortunately the huge hitch I ran into there was that our shared web hosting didn't support a real cron program, and I had no way to automate the task.


What I did, though, was interlink that ATIS "program" and my "Status Information" board that I mentioned earlier, so that the ATISes on that board wouldn't need manual updating. That would have actually made it so that I could post the board as active 24/7, any of our ATC could log in, see what their VATSIM airport ATIS was on, then set their network ATIS accordingly.


Right now, that's kind of in limbo as I haven't had any time to do any development.


2) Simple logistical problems. Shortly after we actually had this beast up and running....we realized that there were just a ton of logistical things that we couldn't overcome.


Communication problems are one roadblock. Very simply, we, unlike real facilities, are not in the same room, building, or even county. Most of us don't have personal landlines. The best things we can do are open up an extra voice channel or go on Teamspeak and hope that we can communicate well and relay anything that we need. This makes everything that anyone trying to ATM the event just seconds or minutes slower in response. We can hear someone need help for one minute, try to corral something to help the controller, and not be able to get in touch with the adjacent sector in time. Unfortunately, no traffic board, information system or anything can help with this.


Desktop screen management. This might be one of the biggest problems or smaller problems depending on the staff. Any kind of traffic posting or information board needs more screen space. Do all of our controllers have two monitors, or even enough room to be able to see the bulletin board? It's of little or no use if it's minimized under VRC/ASRC.


Traffic levels plus the communication issues. The last thing is that events take place so quickly (in the span of a couple hours) that half the time, anything we try to manage or plan out actually gets lost in the excitement of the moment. Plans get scrambled up, controllers get completely immersed, and like I mentioned before, the communication issues become very condemning to any coordination we could do. If everyone is on Teamspeak, but six of the ten controllers are muted...how does that help us? We need some way to easily and comfortably conference controllers together. When the traffic starts hitting in hard is where the TMU people should be able to really do some helpful work; but because the ATC are so immersed, our job is really just lost to the hopefully keen prerogative of the controllers.


Finally, there's the ability to keep everyone on the same playing field. The more complex we make this (such as some of the stuff I've touched on), the more uniform we need certain things to be. The deeper we get as managers, the more we need to expect certain things to be done from our volunteer controllers. Using my ramblings above as a hypothetical benchmark, I would need all of my controllers to have a headset...speakers, with separated sound for Teamspeak/Conferencing...they need to run TS or whatever, they need two monitors, or need to have it set up to see the bulletin board. You see where I'm going of course?


And then, like those types of necessities for individual controllers, we'd need more uniformity among ARTCCs and Regions. Each ARTCC would need to have similar TMU ventures, bulletins, information, etc. We would certainly be transforming a bit of how we run our Division as a whole, with TMU even up to the Division-wide level.


I'm not saying that this wouldn't be fun at all; I get a huge kick out of it...but I see pretty much the same traffic levels today that we did three years ago when we started dreaming this stuff up. The VATSIM network itself I think needs to evolve and grow in daily operations a bit more before any of these TMU ideas really would become immersive and as fun as plugging in as ATC.


I didn't stop to proof this beast of a post, so mind any errors. This is actually far more long winded than I intended to write, for that I apologize

Steve Ogrodowski

Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now
  • Create New...