T3 Webinar Question and Answer Transcript

Clearing the Dispatcher's Queue: Using a Transit Operations Decision Support System (TODSS) to Improve Real-time Incident Response (October 21, 2009)

Back to Webinar Files


Q. Was the Transit Communications Interface Profiles (TCIPs) or Transit Cooperative Research Program Report TCRP-113 using archived Automatic Vehicle Location/Automatic Passenger Counters (AVL/APC) data used in the development of TODSS (Transit Operations Decision Support Systems)? If we are using the TCIP for guidance, will we lose our efforts in going to a TODSS-type system?
A.

David Jackson: It wasn't used specifically during the development, but we didn't do anything that would preclude any of the efforts that have been done so far. We really added onto the top of the system, and what we're doing is not changing any of the data internally—the historical data—but what we are doing really is filtering out to the dispatchers and making that easier so they can do their job better.

Bill Hiller: And just to follow-up on that, the traffic.com interface is through a Really Simple Syndication (RSS) feed, but it was always envisioned that if there were TCIP applications that we would have an interface for that, as well as to bring in the center-to-center-type communications. So that's a future direction of TODSS.

Yehuda Gross: I want to sum those two up in one short comment; remember: TCIP is much easier to implement when we are moving forward. This is a legacy system, so it was much harder to do it, but at least you have taken steps so that you can be incorporated into original.

Q. Where are weather-related events considered? Freezing rain, severe storm and flooding information can severely affect bus operations, demanding immediate responses.
A.

John Braband: Bill had talked earlier about the RSS feeds for the traffic alert. We've created one for weather alerts, so that we'll get an incident in the cue that will indicate, like for instance, a tornado warning or alert, or a flash flooding. Those incidents will have their own set of research and action plans associated by them. And something that I didn't say before, but we can have three different sets of incident queues in the application at one time. So in the event there is a major weather-related incident, we can dedicate all of those feeds coming into one set of incident queues, so that the dispatcher can handle not only-- or we can maybe assign a special dispatcher to handle the RSS feeds that are weather related, while the other dispatcher is handling the regular Request to Talk and alerts. And Melinda wants to comment on that also.

Melissa Metzger: The one other comment that I wanted to make, in the past, before we had TODSS in place, all of our operators would call in and say, "We're running late because of weather." All of that voice communication has been eliminated. As John has stated, we can put that in a file on the screen so we know there's weather-related incidents, as opposed to having drivers call in telling us they're late because of these weather-related incidents.

Q. Is TODSS structured to run from a history database for planning and for dispatcher training?
A.

Bill Hiller: There's a lot of details we didn't get into, but there are two different techniques within the TODSS configurations. One is query statistics, where you actually graphically build a sequel statement that actually looks at the current incident queue and up to the last 12 hours, to be able to have-- for instance, you may want to have an incident come in the queue for a supervisor in the dispatch center that says, "Do I have more than five Requests to Talk (RTTs) that haven't been responded to in the last two minutes?" And that way, with those kinds of queries, you can then be notified if the dispatchers are getting backed up. The other one is called a canned query, which allows you to go back into historical data, run queries, and find some thresholds that then become the events that you then can trigger your incident off of. So you actually can use the historical data in the last 24 hours, say, or the last two days, in order to determine, "Have I had eight mechanical alarms in this fare box," because that's the threshold where the maintenance mechanics want to-- or say three alarms. That's the threshold want to know that that needs to be brought in to be looked at. So you can look at historical data, and you can look at the real-time queue and build up information.

Q. What is the timeframe for the pre-TODSS and post-TODSS response? Before and after numbers.
A.

Steve Mortensen: I believe it was a-- I think what you mean is the evaluation period, and it was a relatively short evaluation period. It was like 30 days. Bill, do you want to expand on that? Bill Hiller?

Bill Hiller: Well, the evaluation period was 60 days, where we were actually on-site and looking at things and evaluating data, if that's the response time they were after.

Yehuda Gross: We assume.

Steve Mortensen: Yeah, I think that's what that means. Yeah, it was a 60-day evaluation period.

Q. This question is addressed to John Braband. How much opposition and pushback did you encounter with senior dispatchers and controllers, who may have argued that the TODSS process takes longer than just completing the task at hand? Did you find that TODSS helped to level the playing field between senior and new dispatchers and controllers?
A.

John Braband: That's a good question. We used some of most senior dispatchers on our TODSS team to begin with, so there was some instant buy-back right there. I think what we found, and I think Bill showed afterwards, is I think most dispatchers, because they're only seeing incidents that they really need or really have a chance or any value to even answer, has reduced the labor of having all these things thrown at them. Now, you're right, it takes probably longer for them to complete an RTT because they're creating an incident from that RTT, in some of the cases, so that they have the action plan associated with what's really happening. I don't think there has been any fallout from the senior dispatchers because I think they've found that it's at least as easy or easier now that TODSS is in.

Melissa Metzger: This is Melinda Metzger. I'd just like to add to that. We've had very good buy-in by all of our dispatch staff, both senior and less senior dispatch staff, as well as our operators. That might be a question coming up, because a lot of properties have the issue that the operators don't want to buy in to the Big Brother watching. But after a period of time and our operators and dispatchers realizing how much the system can help them do their jobs, we've had very good buy-in by everyone.

John Braband: And finally, I just wanted to mention, one of the responsibilities of a dispatcher on a service-related incident is to notify our travel center, and that was done by first logging down what the driver said over the Request to Talk, then calling the travel center, and then having to deal that way. I don't know if you saw it, because we didn't have a schedule-related incident in the queue to show, but there's an email link that provides all of the data that's provided by the bus at the time the incident was called in, to email right directly to our passenger services. So there's no phone calling and there's no interaction other than a quick link directly over to it, and it gets out to our public. So that has sped that up considerably. And we've increased the number of calls or information to our passenger centers by almost 500 percent.

Q. This was a demonstration on a small fleet—question mark. How would you manage a very large fleet? How would multiple dispatchers coordinate?
A.

Steve Mortensen: I'll take this. This is Steve, and then I'll hand it over to PACE Suburban Bus Company. This was a demonstration on a large fleet, actually, as the presentation given by John said. I do know that PACE implemented this system in an incremental fashion just to make sure that-- they first implemented it in one division with a few types of service disruptions and then expanded the capability in its other divisions also. Melinda or John, would you like to expand on that?

Melissa Metzger: Yes, I would definitely like to expand. PACE is a very large system. You're absolutely correct. We started with our smaller properties and then expanded it to other properties. But we're also a very complex system, and I think that goes along with the question. We have 10–11 different centers that are dispatching, and what TODSS has been able to do is, we used to have to have a dispatcher on at every one of our garages. We cover a 3000 square mile area. So in 10 locations, we would have a dispatcher on duty. With TODSS, at night, we're able-and on weekends-we're able to shut down our different dispatch offices earlier, when they don't have a lot of vehicles on the street, and have one main dispatch center handle all the vehicles on the street. So TODSS has given us this ability to switch around who is monitoring the service, who is dispatching the service, and in emergency situations, if we have one dispatch center go down, another one can pick it up immediately. So we never have a loss of communication with our operators.

Q. Will this be commercially available from the Computer Aided Dispatch (CAD) vendors? Is it available to companies other than Continental?
A.

Yehuda Gross: What we did here, in fact, the requirements are open to the public. Anyone can take the requirements for TODSS. Continental has really helped in the development of this because of the legacy systems that PACE had. Continental was Siemens before, so it was natural that they would get this. We had a workshop during this past summer at PACE, and other vendors have been invited and showed up. So they're aware that a system exists, and the core requirements are up for the public to use, and at least what I've heard from them is that they have a lot of intentions—and I haven't seen a product yet-- to adopt it into their own systems. So as a summary, it will probably be available, and if there is a demand, it will definitely be available.

Q. Does TODSS have any use in paratransit operations?
A.

Steve Mortensen: The way the core requirements are written, it just applies to fixed route bus service. So that's why, when we did the demonstration, it only applied to fixed route service. This is a very good question, because it's come up in our conversations. I think that TODSS does have a place in paratransit operations, and that may potentially be in the next phase. If the USDOT decides to expand the core to an outer ring, we think that paratransit operations would be a part of the core requirements. Yehuda, do you have...?

Melissa Metzger: PACE is one of the largest paratransit carriers, if not the largest paratransit carrier in the world, and we definitely see an application that we would like to see TODSS, in the paratransit realm. Right now we have two separate systems running. We have a Trapeze system running in our environment in Chicago as well as the TODSS environment for our fixed route system. If I was doing this all over again, being responsible for both the paratransit side of the house and the fixed route side of the house, I definitely would have put TODSS in first in the paratransit side of the house. It is that useful a tool.

Yehuda Gross: So I will sum up. I spoke to one of the vendors that focusing their attention into the paratransit service, and they told me—and again, I don't mention their name—they told me that this is something very interesting to add to their system.

Q. Can you talk about the interaction with the maintenance department?
A.

John Braband: Well, first of all, even prior to TODSS, our maintenance superintendents and even some of the foremen had a direct connect with the canned AVL system through our Citrix program here at PACE. So they were able to see the incidents as they came in. But now with TODSS, again, as I say, we can create work assignments, and we could have a work assignment called "Maintenance," and then each maintenance manager will only see incidents for his vehicles, and he can filter them by the type that he wants to see. You also saw the application that may be coming soon-we're testing it now at PACE-is the BlackBerry application, where maintenance superintendents can carry that when they're around, or down on the floor. So there is a big future interaction for our maintenance department with TODSS.

Q. What was the cost of the TODSS system as a percentage of the Computer Aided Dispatch/Automatic Vehicle Location (CAD/AVL)?
A.

Steve Mortensen: I can answer a part of that question. The demonstration project cost a total of 750 thousand dollars. The federal share was 600 thousand. I realize this is a demonstration project, so it probably would be more expensive than a commercial system. I will let PACE answer the rest of the question, if they desire, or if they have the information.

John Braband: Well, I mean, it really comes down to a pretty small percentage. If you're looking at the 750, a good portion of that was project management. And believe me, without that, we would not have been the success that it was. And I think—and maybe Dan can answer more. I don't want to give up what we paid for our Intelligent Bus System.

David Jackson: Basically this thing cost about 5 percent of the cost of the entire system. But if you look at it—and I was involved in the original procurement—if you look at the customization that was added there, I think this was probably less than the customization that was required.

John Braband: Oh, no question.

Q. How many in-house PACE developers and system administrators are needed to start, and then maintain the system? What is the recommended ratio of system administrators to controllers, and how many controllers per scheduled vehicle on the street?
A.

Yehuda Gross: , that's a follow-up to the previous question. John, do you want to answer?

John Braband: Well, I don't know. Maybe we'll provide that—since it's a multi-part, I'd have to get my calculator out. We could provide that in an email link or something. But I can tell you one thing though. Basically here at PACE, we had our management team from Booz Allen, and me and TJ in the next room, that did all of the TODSS implementation of the development.

Melissa Metzger: And I will add from a management perspective, we're very mean and lean, and we certainly don't have the capability to have a lot of Mangement Inforation Systems (MIS) and technical people available to us. We had to do it using the outside consultants as well as our own internal operations staff, and our MIS department. But it is small, and we'll get you numbers.

Q. Is there the ability to audit action plans for review?
A.

Bill Hiller: Okay. Well, there is an audit history application that goes along with this that John wanted to show, but we axed it out for time. But you will have the ability to actually trace all of the steps that were taken in an action plan related to an event, and you can trace all the events that were mapped to a single incident. A good example would be like an emergency alarm, where there could be several events. It could be an initial covert alarm, it could be the RTT that downgraded it. All of that history is available and for the prototype we were able to go back I believe only five or six days that, as we go forward with the full-blown application we are talking about being able to go back as far as we want to be able to look at trends and patterns. I was able to use audit history to identify some spectacular actions and behavior by dispatchers that I then went and interviewed the people. But I was able to sit in Iowa and watch them working through the audit history, and see the good things they were doing, and also identifying things that weren't working well as well.

Q. Could you envision this system functioning with a system of private and public buses, i.e., different companies and city buses?
A.

Steve Mortensen: Yes, we do envision that this could function with multiple transit providers. Yehuda talked a little bit about the (Integrated Corridor Management (ICM) initiative. I'm involved in that initiative, and we are working with eight pioneer sites. And several of our pioneer sites have indicated that they would like to create a multi-modal decision support system. So we would see, as Yehuda indicated, that TODSS probably would be just for the transit operators, and then the multi-modal decision support system would make the recommended strategies to implement based on operational conditions, and then TODSS could be used to implement what the transit agencies need to do as a part of that. Anybody else want to jump in?

Melissa Metzger: PACE is unique in that we have all these different operating divisions with, number one, different operating rules. So they act semi-independently, as well as we use private contractors to do some of our work. So the way it is set up for us could very well fit into a multi-modal or different transit companies utilizing it, because that's basically what we do now.

Yehuda Gross: Which leaves it to a decision by different elements to get together and work together.

Q. Could TODSS be used in field environments, like supervisor cars?
A.

Bill Hiller: John Braband might want to talk about this, but some of the-- there's a mobile dispatching application that PACE has that uses the Citrix connection on a ruggedized laptop. And a couple of their mobile dispatchers were using the Intelligent Decision Support (IDS) out on the field, and they just really took to it, and offloaded-- an awful lot of the work that was being handled by the dispatcher in the South Division was handled by that mobile dispatcher in a supporting role, and just really took off with it. John?

John Braband: Yeah, that's true, Bill. I talked about the wheelchair violations. Before, our supervisors actually had to go and visually watch the drivers that they logged in to confirm that they didn't cycle their lift, so that we can confirm that there was a violation. And now they're sitting in their car and assisting the dispatcher with the violations as they come into TODSS. And there's a text message that's associated with that wheelchair incident that reminds the driver to-- text message back to the driver to remind him to cycle his lift. And that's just one. I mean, there's schedule adherence. All these tabs that I showed earlier are available through that mobile application. And I think, because of that laptop can be a little cumbersome, I think the BlackBerry is really, really going to be great in the field.

Q. How does the system function with existing scheduling software exports and imports, such as HASTUS.
A.

John Braband: The process hasn't changed at all from our pre-TODSS. Giro's HASTUS scheduling system is integrated into IBS and there really never has been an issue.

back to top





RITA's privacy policies and procedures do not necessarily apply to external web sites.
We suggest contacting these sites directly for information on their data collection and distribution policies.