In a previous post, I introduced the subject of analysing route operations using data from the TTC’s vehicle monitoring system called CIS.
Before I get into comments about any routes, this post is intended as an overview of how the data from CIS works (or doesn’t) and the limitations of any analysis based on it. In a way, this is a gigantic footnote, but the information here is common to everything that will follow in this series, and I don’t want to spend my time answering questions about how the analysis was actually conducted.
For those of you who just want the gory details on the King car, wait for the next post.
CIS (“Communication and Information System”) was designed in the late 1970s and rolled out through the 1980s. It is best known for the radio link back to CIS control, but the system also tracks vehicle movements throughout the city.
CIS technology reflects both the limits of its time and the infamous “not invented here” syndrome from which Toronto, the TTC and the Province of Ontario all suffer. Rather than using an off-the-shelf system proven in other cities and built by an established vendor, the TTC took the roll-your-own approach with the hope of future markets. None ever developed because CIS was limited in its capabilities and it had no integration with other major systems such as traffic lights or passenger information displays.
For the purpose of this discussion, all we are interested in is vehicle location data. How does CIS know where a vehicle is? This requires three pieces of information:
- Route and run number (this is set up when an operator “signs on” to CIS)
- Odometer reading
- Signpost number (see below)
What’s a “signpost”? All over the city, there are short-distance transmitters sending out a code to CIS units on vehicles. Each signpost has its own code, and there are over 30,000 possible codes. We are not in danger of running out soon, and there are less than 1,000 signposts.
When a vehicle passes a transmitter, it updates its signpost reference. A vehicle’s location is calculated relative to the last observed signpost and the change in the odometer value.
Every 20 seconds, the central system polls each vehicle, and the CIS unit returns a collection of status information including, usually, the location data. (For the non technical readers, to “poll” means to ask a system what its current status is. It is much simpler to ask every vehicle now and then what its status is rather than have a continuous flood of data come in from the entire fleet.)
By now, you may have noticed that the location of a signpost and an offset don’t give us an exact location, only a circle some distance from the signpost. That’s where the route and run number come into play. CIS knows where the vehicle should be, and it also knows (or thinks it knows) where it was 20 seconds ago. This information narrows down the location. With an update every 20 seconds, CIS can keep track of vehicles at the resolution level of a city block or two.
There can be some drift between the calculated value (from the changing odometer readings) and the actual location. When a vehicle encounters the next signpost, CIS makes a correction that can cause the reported location to jump backward. If the odometer isn’t working reliably, the location information can bounce all over the place, or it can be simply a series of signposts.
From the schedule information, CIS can generate an early or late indication for the operator, but of course this depends on two things: a reasonable schedule, and a correct location and direction. CIS can be confused when a vehicle goes somewhere unexpected — the odometer is still ticking, but the car or bus is off in never-never land. This is a major problem with CIS. Eventually, CIS figures out that it guessed wrongly, and the vehicle suddenly appears in a different part of the city.
I refer to this as “teleportation”. Alas, this is not a service offered for passengers.
Limitations of the data:
At terminals, resolution of the exact vehicle position is difficult because of multiple signposts and variation in the point at which vehicles register each post (if at all). It is actually easier to analyse terminal movements by looking at round trips from a nearby point where data is reliable.
Some locations appear to be “black holes” for reporting vehicle locations. This is a problem on the east end of the Queen route where vehicles disappear eastbound at Wineva (near the south end of the Main bus) and don’t re-appear until they leave Neville Loop westbound.
Because identification of a vehicle depends on the signon, it is possible to have a vehicle reporting the wrong run number, or to have two vehicles reporting the same run number. This can also happen when a change-off vehicle comes online and, legitimately there are two instances of the same run on the street at the same time. Only the combination of run and vehicle number can be used for a unique vehicle identity.
There is little information on stop service times because the system is designed to report a vehicle’s passage from block to block. There is no way to tell whether the time between reported locations was occupied with loading passengers or sitting in traffic. CIS is designed to report on vehicles, not on loading conditions.
Despite the constraints, it is possible to get a reasonably good view of how routes behave. The following analyses will be discussed in detail when I turn to individual routes:
- A graph of vehicle movements over times giving an overview of a route’s operation for an entire day.
- An “as operated” timetable showing where vehicles actually were rather than the scheduled service.
- Graphs of headways at various points along a route showing the frequency of service actually experienced by waiting customers.
- Graphs of link times (the time taken to move from one point to another) showing the areas and times where changes in traffic congestion or loading delays have the greatest effect.
- Charts of actual vehicle destinations showing the prevalence of short turns.
- Graphs of schedule reliability showing the service operated at one location over many days.
The heart of the process is the conversion of raw CIS data to formats that lend themselves to digestion by a variety of programs. CIS location data (an intersection name or a signpost number) is mapped to a co-ordinate system for each route. For example, in the King analysis, Broadview Station is “100” and a scale of roughly 100 units to 1 kilometre sets the location of intersections all the way to Dundas West.
Although vehicle location records do not exist for every point on the route, they are close enough that we can assume a linear progression from one point to the next. This is not necessarily what happens, but the difference from reality will be small. This process produces a table of locations for every vehicle at every 20-second polling interval.
In turn, that table can be used to obtain the time when each vehicle arrives at and leaves various points of interest on a route (I will discuss the choice of the points when I get into individual route analyses). This gives us the “as operated” timetable.
This timetable generates headway and link time information. Headways are the times between vehicles passing a single point, and link times are the travel times for each vehicle from one point to another.
The timetable also shows where each trip starts and ends. Charts of short turns by time of day and location follows naturally.
Finally, by combining data from many days’ timetables, we can learn when (or if) each run passed a point on a trip. This shows problems such as chronic irregularity of arrival times or missing runs (some runs are not operated on every day due to a shortage of operators or vehicles).
Stay tuned for details.
That was very informative, and I do know what poll means 🙂
Can you also add in how this compares with the GPS other systems mention? How many light years are these 2 methods apart?
Steve: GPS had not been invented when CIS was designed (or if it had, the uses were for high cost and military systems only). With GPS there is no need to calculate where a vehicle is — you know from its co-ordinates where it is “now”, and from recent information you can easily tell the direction it is headed. This would eliminate all of the inaccuracy in reporting vehicle movements.
The other missing piece is the logic of handling vehicles that have gone off route. In some cases this is a diversion, in others it is just a short turn. CIS has no way to figure out what is really going on, and it can misreport a vehicle’s location. This interferes with management of service that is not where CIS thinks it should be.
Just off the top of my head they could go really high tech when Presto is on every bus and the readers could be made to transmit this data from a beam of light from the signposts?
Don’t curse me too loud ok.
Do they plan to upgrade this tracking system at all in our lifetime?
Steve: It’s amazing how much information can be transmitted with simple radio technology. The real problem is storing and digesting all of the data.
The TTC has a Request for Information that just closed. Its intent was to survey the market to see what capabilities are “out there” nominally for a “next bus” announcement at stops, but the same data can also be used for vehicle monitoring.
Just a minor correction: the CIS (through the “TRUMP” unit in the vehicle) doesn’t calculate the odometer reading. Rather it counts axle revolutions from the last signpost registration. There is a sensor on the front axle that contains two magnets that trigger the distance travelled from the last signpost. From my experience as a TTC bus operator, this system is a major source of trouble between operator and supervisors. The CIS display that the supervisors view will show vehicle “deviation from schedule”. Unfortunately, this is not always accurate, so operators are required to know their “timing points”. I have experienced frequent occasions where the TRUMP/CIS shows me operating ahead of or behind schedule, but I am exactly on time according to the timing points. The system can also show locations incorrectly (for example a northbound vehicle can show as going southbound). I look forward to your additional information that TTC has released to you.
Steve: Sorry for the confusion. I should have put in the more detailed explanation to indicate how there can be a discrepancy between the calculated and actual distances depending on variations in the ratio of axle revolutions to distance for each vehicle. It shows up in the CIS data as a “backtracking” effect when passing a signpost that is “behind” the currently calculated position. The wrong way problem also shows up and makes some of the data analysis tricky.
The underlying problem is that GPS didn’t exist when CIS was implemented. Moreover, CIS appears to ignore the evidence of the first “wrong” signpost it sees on the off chance that this is just invalid data, and it only corrects after at least two signposts establish where a vehicle really is. This shows up in some amusing ways. Inbound Lake Shore cars are reported as going along Queen and down Shaw when in fact they go along King. This may be a mapping error left over from the days when the 507 went downtown via Queen, and only after a few King Street signposts does CIS decide that the car really is on King.
The main issue with GPS would be in the downtown core (towers blocking the satellites) and in tunnels – some kind of repeater system would be necessary. A system based on cellular phone signals could be used to carry voice communications, data to/from operator panels and perform triangulation. Either of these would allow the signposts to be decommissioned and provide sufficient resolution to deal with diversions.
The question is are there off the shelf systems which TTC can acquire without going down the “roll your own road” again? Is this something GTTA could do the heavy lifting on with a view to offering it to multiple GTA transit systems?
Steve: The GPS units now being installed on TTC vehicles are “industrial strength” GPS that can deal with the reflections of downtown towers. As for a CIS replacement, the fact that the TTC has issued an RFI that mentions vehicle monitoring as well as stop information systems suggests that they are not going down the roll-your-own path if they can avoid it.
Does the automated announcement system that’s being tested on some buses use CIS? I’ve seen it act strange when it was activated on routes with diversions.
Steve: No, the automated system uses GPS. Also, it is tied not to route but to location. In other words, if you are on a street that has been geocoded into the announcement database, you should get announcements. Many streets are not coded yet.
However, the operator can select “express” or “local” mode so that local stops are not announced on express buses (this happened to me on the 190 Rocket about a month ago).
I worked for Motorola Canada (in beautiful suburban North York) in the mid to late 1980’s. It was rumoured that Motorola always overbid on TTC contracts because they really didn’t want to do business with the TTC. The story was that the TTC was a very “high maintenance” customer and that you had to factor in the additional costs. Motorola specialized in custom two-way radio solutions including data.
As we now know Motorola let someone else supply the TTC. Motorola got the more predictable and reliable police, fire, ambulance business and just about everyone else that needed two-way radio equipment. I wonder who’s laughing now?
Are the CIS signpost machineries visible to passers-by? Boxes hung on poles or something? Is there a map available on-line that shows location of the CIS signposts?
Steve: If you know what you are looking for, they are easy to spot. They are quite small cylinders, usually white, mounted about 3 metres off of the ground. There isn’t a map, although I have a list of them to use in interpreting the CIS data. And, no, I am not going to publish it.
Steve wrote about CIS signposts:
If you know what you are looking for, they are easy to spot. They are quite small cylinders, usually white, mounted about 3 metres off of the ground.
Well, I saw something resembling a small beer keg attached to the light standard at the southeast corner of Bathurst and King this morning. Beer-keg sized doesn’t really jibe with “quite small”, but I expect that signposts would be found at major intersections like this; so I’ll keep looking.
Steve: That “beer keg” is a WiFi transmitter owned by Toronto Hydro Telecom.