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.