ZTS, CLIC, SPINS… what system did MP use?

[Ray Swanson]

I’m looking for information on track numbering used by MP. I know UP used (uses?) ZTS but I can’t find anything on MP. Are any track diagrams, specifically industry diagrams, available? I’m not finding anything on ebay, but without knowing the best search terms to use I am probably just missing it.

[Dennis Faircloth]

Hi Ryan,

MP used ZTS (Zone-Track-Spot) system and published books for each territory covered by a particular customer service center. They were all in 4.25″ x 11″ format with orange covers. After the UP merger, the books continued to be published, with a UP herald replacing the MP herald on the covers.

The MPHS digital archives group is working toward offering a set of ZTS diagrams, probably on CD, that covers the entire MP system. We are currently compiling what is in the collection, and what portions of the system we are missing.

Ted Ferkenhoff
Flagstaff, AZ

[Ray Swanson]

Far out! I would definitely be interested in acquiring a copy in whatever format you wish to offer.

Would you know if UP still uses this system today? We (BNSF) spot a couple legacy industries on former BN track that’s now UP track and a dispatcher asked us for the track ID. I don’t remember the term used, but we figured it was similar to the CLIC system we use.

[clemmie_doris12]

Ryan, the computer system that UP uses was developed by the MP. It was named Transportation Control System, TCS, and it was first begun with federal assistance in the early 1970s. It was and is a very good system. It can be argued that one of the reasons that UP sought to merge with MP was this system. It survives in an updated state, but it is very much a part of the MP legacy. UP’s COIN, Computer Operated Information Network, was dropped like a hot rock after the merger.

UP is moving toward a PC based interface, but the old mainframe TCS system keeps chugging along in the background. Some argue that the base TCS system was difficult to use, but I “grew up” with it and had no problem. I would stack TCS up against any other system in current use. Zone-Track-Spot was an integral part of TCS and was MP all the way. It could have changed, recently, but a lot of UP’s IT development is still carried out in the old MP headquarters building in St. Louis.

There are several “power users” of TCS that are on this forum. That includes me and the moderator. We would be happy to answer any questions.

[annisheyne3828]

Would it be possible or useful (i.e., sufficient interest) to build a scaled-down version of the basic functionality for running on a PC, with some MP distinctives, for use in model layout operations?

Dana+ Jackson

[clemmie_doris12]

Dana,

I will let Charlie Duckworth chime in on this issue. He is more familiar with both the programming aspect and the modeling aspect than I am.

[peggyrothschild]

For someone wanting to build a scaled down version of TCS here’s some 30,000 foot remarks. These steps loosely resemble how the Mopac implemented the system.
1. Build a station master with city state and circular seven numbers. Mopac had many, many other details but for a model RR this would be a start.
2. Build a customer master (customer name, city, state) we had both an online and offline customer master as it drove sales revenue and car scheduling.
3. Build a Zone-Track-Spot (ZTS) file that is linked to the Customer Master. This also supports team track (99 spot) and exact spots for certain commodities
4. Build a waybill file. In model railroading you probably don’t need a shipper name but destination city, state and consignee.

These four allow Mopac to implement Car Scheduling in December 1975 where once a waybill was entered on a load or empty or a pool was made for empties, or special instructions entered for an empty the car was scheduled all the way to destination or the interchange junction based on the circular seven number and commodity code and any special conditions listed on the waybill. Blocking tables were built to schedule to car to a train (and future trains) down to the industry job spotting the car to a customer.

[clemmie_doris12]

To build on Charlie’s comments, the main driver behind car scheduling in TCS was the trip plan. When a car was released for movement, TCS developed a trip plan for that car from origin to destination. It would take into account the day and time released and determine the first job available to move the car and then determine each subsequent move based on the schedule of the previous train or yard job. Determining the scheduling for each potential move would seem to be the biggest issue in creating the program.

[Ray Swanson]

That’s some great information. Amazing that it’s been around so long.

So, if you don’t mind, indulge me in a little scenario: a customer releases a car in zone 3, and the 64 job works zone 3, would the car automatically be assigned to the next day’s work on the 64 job? Was car routing to its destination also automated once the 64 job brought the car to the yard?

[Dennis Faircloth]

How about a shot of a TCS screen for this discussion……

This image was cropped out of a slide used to illustrate either a presentation or an annual report. It has some pixelation from application of a sharpening filter in Photoshop. Disclaimer: I am a student of TCS, not a practitioner. Hopefully Kevin and Charlie can correct me where I derail, and fill in any holes.

The screen is a car inquiry screen showing origin, destination and its trip plan. The top line shows the car initials and number (MP 253558), L=loaded, L50 is a car type code for a boxcar equipped with load restraining devices. It is carrying “BRICK”, but the more descriptive STCC code follows that, 3255110 being the STCC code for Fire Brick. (STCC is Standard Transportation Commodity Code, and this is the classification that matches up with the proper rate for billing the cost of the movement.)

The second line shows the waybill number, date waybill created, and location where the car was waybilled. Next lines show origin station and shipper, destination station and receiver. Company names made up for demo purposes. OFF indicates the car goes offline, in this case interchanged to FW&D at Ft Worth. ETA=I/C is the interchange ETA at TP250 (station code for Ft Worth).

Next is the trip plan. Each line is an event. SA=station arrival, SS=station setout, SD=station departure, SP=station pickup, RL=released. The trip events are read from bottom upwards, with past events under the dashed line, and scheduled events above the dashed line. This trip plan shows the car released at ZTS location 04-851-01. It is scheduled to be picked up by yard job YM38-16 (Job M38 of the 16th of the month), then it leaves Memphis on train MLS-17 (Memphis-Little Rock-Southern, a runthrough off the Southern Rwy at Memphis), and at Little Rock it is classified to Train LF (Little Rock-Ft Worth) for the trip to Ft Worth. Scheduled dates and times for each event.

I have been working with JMRI to see if I can duplicate the MP train consist formats generated from TCS, for use on my model railroad. Still a very early work-in-progress.

[attachment=0:3o696nns]Demo TCS screen.jpg[/attachment:3o696nns]

[luisflierl26]

Some of this material is covered in the MPHS 5 DVD set

http://www.mopac.org/store/cd-s-dvd-s/item/41-mphs-5-dvd-collectors-set

[peggyrothschild]

@[email protected] wrote:

That’s some great information. Amazing that it’s been around so long.

So, if you don’t mind, indulge me in a little scenario: a customer releases a car in zone 3, and the 64 job works zone 3, would the car automatically be assigned to the next day’s work on the 64 job? Was car routing to its destination also automated once the 64 job brought the car to the yard?

Ryan
Customers were given a cutoff times for the train serving their plant. So if the cutoff was 1:00 pm and the crew went on duty at 3:00 pm if the car was way billed or released empty by 12:59 pm the car would be on their work order scheduled to be pulled by the 3:00 job. If the customer released the car after the cutoff it would be scheduled to the next day’s job, Terminals were measured on a report ‘Right Day Right Train’ so management could tell if customers were being served timely. If a crew couldn’t get to a car they would report the car ‘not done’ with a whole list of coded reason codes (gate locked, ran out of time, etc). When this happened the car would roll to the next day.

[Ray Swanson]

I like your example, Ted. It’s similar to what I’m used to seeing on BNSF’s TSS, although the information is presented in a different way.

I’m pretty sure that the station code for Fort Worth is still the same; I seem to recall having TP250 on my UP track warrants. I’ve worked as an engineer on that MP to FW&D transfer job many times in its modern UP to BNSF form working as the YA110J (inbound) and YFW63 (outbound), so I’ve seen many wheel reports but never this side of things.

The car kind and STCC load kind are interesting. BNSF uses a different car kind code, and places the L/E information after the car kind, but I’m assuming the STCC code and descriptor are universal. Is there a master list of car kinds and STCC codes available for browsing?

Thanks very much for the breakdown on the trip plan!

[Ray Swanson]

@dhuelsing wrote:

Some of this material is covered in the MPHS 5 DVD set

http://www.mopac.org/store/cd-s-dvd-s/item/41-mphs-5-dvd-collectors-set

Thank you! Bookmarked for after Christmas…

[Ray Swanson]

Thanks Charlie. That sounds very much like what I deal with at BNSF.

We had a car turn up lost (whoops!) and one of the yardmasters was showing me all the different reasons the work hadn’t been done/car hadn’t been delivered while the search was on. Management was having to get pretty creative for awhile according to the list of delay reasons. Not sure if they ever found that car.

[Author]

Posts