USDOT Integrated Corridor Management (ICM) Initiative
Transit Data Gap Action Plan Workshop Notes
February 10, 2009
U.S. Department of Transportation
Research and Innovative Technology Administration
Federal Transit Administration
Federal Highway Administration
Download the Printable Version [PDF,
404 KB]
You will need the Adobe Acrobat Reader to view this PDF.
Form DOT F 1700.7
1. Report No. EDL 14490 |
2. Government Accession No. |
3. Recipient's Catalog No. |
|
4. Title and Subtitle USDOT Integrated Corridor Management (ICM) Initiative Transit Data Gaps for Bus Transit Systems Initial Planning Workshop Notes |
5. Report Date February 10, 2009 |
||
6. Performing Organization Code |
|||
7. Author(s) Steve Mortensen |
8. Performing Organization Report No. |
||
9. Performing Organization Name and Address U.S. Department of Transportation |
10. Work Unit No. (TRAIS) |
||
11. Contract or Grant No.
|
|||
12. Sponsoring Agency Name and Address U.S. Department of Transportation |
13. Type of Report and Period Covered
|
||
14. Sponsoring Agency Code
|
|||
15. Supplementary Notes
|
|||
16. Abstract This document contains the notes from a workshop that gathered feedback about the Integrated Corridor Management (ICM) transit data gap action plan. This document also describes different methods for counting passengers that the participants in the workshop thought would be feasible. In addition to feasibility, potential manufacturers, and barriers to real-time data collection of passenger numbers were also discussed. The need for a dedicated communications infrastructure for transit communications was also posited by the attendees at the workshop. |
|||
17. Key Words ICM, ransit, data gap, action plan, passenger counts, transit communications |
18. Distribution Statement |
||
19. Security Classification (of this report) Unclassified |
20. Security Classification (of this page) Unclassified |
21. No of Pages 8 |
22. Price
|
Notice
The U.S. Department of Transportation provides high-quality information to serve Government, industry, and the public in a manner that promotes public understanding. Standards and policies are used to ensure and maximize the quality, objectivity, utility, and integrity of its information. USDOT periodically reviews quality issues and adjusts its programs and processes to ensure continuous quality improvements.
Notes
Tuesday, February 10, 2009
Facilitated by Steve Mortensen
Participants:
| Name | Agency |
|---|---|
| Alan Gorman | Dallas Area Rapid Transit (DART) |
| Bob Sheehan | USDOT, FHWA |
| Brendon Hemily | ITS America |
| Brian Kary | MnDOT |
| Bruce Chapman | Caltrans |
| Chris Hill | Mixon Hill |
| Danielle Stanislaus | Metropolitan Transportation Commission (MTC), San Francisco Bay Area |
| David Ridgley | ITS America |
| Dean Deeter | Athey Creek Consultants |
| Doug Jamison | Central Florida Regional Transportation Authority (Lynx), Orlando |
| Ed Fok | USDOT, FHWA |
| Faiza Azmi | ITS America |
| Gary Nyberg | Metro Transit, Minneapolis |
| Jim Kemp | New Jersey Transit |
| John Braband | Pace Suburban Bus, Arlington Heights, IL |
| Josh Bigelow | Synchromatics |
| Kevin Salmi | Pace Suburban Bus, Arlington Heights, IL |
| Kevin Sederstrom | Metro Transit, Minneapolis |
| Michael Bolton | Pace Suburban Bus, Arlington Heights, IL |
| Michael Dillon | Metro Tech Partners |
| Mike Baltes | USDOT, FTA |
| Minh Le | Texas Transportation Institute (TTI) |
| Paul Olson | USDOT, FHWA |
| Roberto Macias | Texas Transportation Institute (TTI) |
| Steve Mortensen | USDOT, FTA |
| Tariq Khan | Pace Suburban Bus, Arlington Heights, IL |
Opening remarks were made by Steve Mortensen, from the Federal Transit Administration Office of Research, Demonstration, and Innovation, and the USDOT ICM Management Team. Steve gave an overview of the agenda, background, and purpose of the Webinar. He also gave a PowerPoint presentation on Integrated Corridor Management (ICM) and the ICM Initiative.
David Ridgley gave instructions on how to participate in the Webinar and the participants introduced themselves.
Chris Hill, contractor from Mixon Hill, gave a PowerPoint presentation on the ICM Transit Data Gap Action Plan.
Steve Mortensen (in reference to slide 7 of the ICM Transit Data Gap Action Plan – recommended ICM data transmission rates for transit vehicle locations and speeds, transit vehicle passenger loads, and parking lot utilization) asked for feedback from the participants on whether the speeds, AVL data, or any other topic pertaining to this discussion are feasible.
__________: Between 30 and 120 seconds for AVL is absolutely feasible today.
Gary Nyberg: As I look at the slide here, I think all of these are feasible - the industry is probably doing them already.
Kevin Sederstrom: The speed would be calculated. That doesn't come through on our AVL but we could do it.
Bruce Chapman: A lot of systems can do that for you based off the GPS signal - give you heading and speed. You can do passenger counts on a real-time basis. I'm not sure if we have clear information on the accuracy but generally speaking that is available and can be done; and is being done in some cases. But obviously there are some communication needs that need to be considered.
Josh Bigelow: We (Synchromatics) are an AVL provider and presently we're doing 6 second updates of information. A lot of agencies don't need that kind of frequency but it is available. I would also echo what Bruce said - that GPS can get reasonably accurate readings on speed. On the subject of real-time passenger counts, you can take real-time passenger counts through APC data and with respect to a particular door cycle your frequency is probably going to be fairly accurate, somewhere around 95%, but the aggregate of your errors over a longer period of time can produce funny results with estimating the passengers. So usually we err on the side of providing an approximate percentage as opposed to an exact count because we feel more comfortable with that and we've had success at probably four or five sites. I have to admit we haven't measured it statistically but I would have to say the customers have been pretty pleased with the results that they're getting on real-time passenger counts.
__________: I guess the one thing on the vehicle passenger count is, if you're talking small volume of vehicles with passenger counts it's more feasible. If you're talking about a huge fleet of vehicles with passenger counters and data being transmitted real-time could potentially be a problem for communications because that's a huge amount of communication that would be coming back from the system, along with all the updated vehicle location messages. So that's just something to keep in mind.
Steve: That's what we heard from the transit stakeholders earlier, that that is a limitation - the communication bandwidth, number of vehicles and all that.
Jim Kemp: We're doing passenger counting on rail now. To do passenger counting on rail is difficult with so many doors and the ability to move between cars. What we're actually doing is load monitoring, which is really what you need. How much spare room is there on a rail car? We're doing that now and we're not at the point where we're transmitting it yet, but it's perfectly feasible. We're just taking data from automatic suspension on the cars. We've done some similar experiments on buses. All of our next fleet of 1200 coming in the next few years, they're all equipped with APCs. We've been through that thing with the accuracy and we've looked at how often we've tried to send the passenger count data and that just comes along with the speed and everything else. We're very glad that you put the parking lot monitoring back in because that's a big deal if you're trying to take people who are already in their car off the road, you need a place to park them. That's important.
Steve: That's definitely been identified as key traveler information and also for the transit agencies, for operational purposes - a component for mode shifting to transit.
Brendon: Steve, are you talking theoretically or are you talking about the specifics of the pioneer sites, in terms of the technological feasibility?
Steve: No, we're talking about in reality, will transit agencies across the country be able to have these type of reporting rates to support ICM. In particular the pioneer sites, but other transit agencies out there that might participate, be a partner in ICM in other corridors across the country.
Brendon: If you bought a system today and specified these kinds of response rates, you would get them. But many systems that are out there now, and will be out there for a long time, cannot do these things. They do not have 100% APCs, they do not have the polling rates because they don't have the channels or it's too expensive, they're using cellular.
Chris: That's an excellent point. Part of the purpose of this exercise, and what we found is that while we got general agreements from talking to people that this was what was needed, we heard exactly what you just said, which is many of the existing systems out there, either they're AVL-type systems or APC systems or existing park-and-ride facilities, they don't have these capabilities. So the purpose within the ICM Initiative is that as we move into the demonstration phase and the existing pioneer sites will be solicited to become potential demonstration sites, that part of their ICM demonstration concept should address these issues and should plan to include these types of capabilities. That way, if we see these things actually operating in one or more of the sites, we can then actually determine whether this is truly the data that is needed to support these different types of ICM strategies. So we're trying to answer the question of "If we had this data, could we provide the types of strategies that we believe are necessary?" So yes, we're very conscious of the fact that this may not be the case in many existing systems and locations.
Bruce: You know I think a lot of these issues are dealing with legacy and proprietary system issues but I think this group could also be an advocate for open interface connectivity issues - make sure the hooks are available so that these could be added on later without having to replace your entire system.
Question via Chat Window: Reasonable qualitative statements from rail operators, such as "Standing room only," "at capacity," "½ sitting load," can be helpful. Must assume even spread in multi-car consists in lieu of APCs with uplinks.
Alan Gorman: What we're thinking of trying, in the interim at least, in the absence of a lot of automated and electronic communication systems to communicate passenger loads and parking lot utilizations, is to actually employ the folks in the field – the bus operators and the train operators who are at those locations at some regular interval, certainly probably within 300 seconds during the rush hour - to let us know what our parking lot capacity is, relay that back to dispatch, who would then disseminate that information through a common network.
Chris: That's an excellent point. One of the things we've included, because we heard it so strongly from the transit providers, was that we should anticipate using that type of capability, certainly either in the very short-term or even in the future for smaller transit properties or properties with less sophisticated systems on board their vehicles.Jim: It's actually more important for the large agencies. You can throw some money at a small agency and they can instrument their fleet and it's not a big deal. A larger agency - in our case 2200-2300 vehicles, just on the bus side, plus another 1000 rail cars - it's a huge proposition to instrument everything. And so the ability to just have an operator periodically hit some kind of a key that gives you some idea as to how loaded the car is, or the bus is, without spending a whole lot of money, may mean a lot to you.
Michael Dillon: Are folks seeing the use of cameras or anything, as far as getting the passenger counts from inside? I've worked on a number of projects where video is being put on buses for security reasons but analytics could certainly, perceivably take a head count.
Steve: That hasn't come up in the past. Does anybody, especially the transit operators out there, know of anyone using cameras for passenger counting?
Michael Bolton: I actually had a discussion with two separate manufacturers of systems, and as of right now, that doesn't seem to be one of the things in their pipeline. Essentially, it's something they might like but they don't see there's a big market for it.
Alan: I think that's an excellent idea on a snapshot/poll basis. I think you would certainly run into bandwidth issues if you tried to do it on any kind of regular interval or stream it.
Jim: We started researching this maybe 14 years ago, when technology wasn't nearly what it is now. Now what I find is that it still takes a pretty hefty processing load that is normally not in these devices - the video processing boards just aren't in the components you buy for a bus. As Michael Bolton said, I haven't seen any vendors being able to step up to that one yet.
Josh: The comment was made that passenger count information isn't, generally speaking, transmitted in real-time and I would agree with that. I would think that only more recently has passenger counting technology gotten to a point where people would want that and it's practical. I would tend to disagree that it would be bandwidth intensive. I'd agree with the comment that was made earlier that passenger counts and other integers can be transmitted along with a GPS feed like a larger amount of data, maybe a GPS update, would be. So I think that it's technically feasible and we do it presently over cellular and it isn't a bandwidth concern for us. But I would agree that it's not generally being done right now, it's more of a newer interest.
Steve: What size of fleets are you currently doing that with?
Josh: Probably the largest we're working with is 63. We've only had experience with it on a smaller fleet size and I do recognize the comment that was made earlier about that it may have trouble scaling to much larger fleets – we haven't really taken a stab at that yet.
The participants then viewed slide 8 of the PowerPoint presentation and, after a brief explanation from Chris Hill, gave feedback on whether or not they concurred with the results shown in the slide (slide 8 identifies the data needed to support/implement various ICM strategies).
Jim: I have a comment about parking management. Maybe video for on-board passenger counts is difficult, but in a parking lot, even those places that don't have a conventional parking management system, it's not at all a big deal for the video analytics in the recording systems that you put in a parking lot, to be able to tell you how much load there is or how much space there is in the parking lot.
Steve: In Montgomery County at the Glenmont Metro Rail station they are currently doing that to monitor parking space availability there and to provide that information to drivers. In Chicago, for Metra, the commuter rail, there's a demonstration where they're using loop detectors to count the vehicles coming in and out of the park-and-ride lots at two stations.
__________: I recommend adding vehicle location and vehicle speed as data required to implement the strategy, direct travelers to alternate networks.
At this time, Chris moved on to the next slide of the presentation.
__________ (In reference to slide 10 – Summary): I wanted to ask on the communications piece, where you say it's the biggest barrier to the collection of real-time data. Is that to presume that a network would have to be constructed?
Chris: Not necessarily. When we talked to people to identify these gaps, this was one of the comments that came out. That is, if we were using our existing systems, for example if we were trying to piggyback this on existing communication systems from the vehicle that are part of our AVL systems or if we're having to rely on our radio systems, potentially we're adding a lot of information that we're trying to communicate back to our dispatch centers and we're just not sure we have the capacity to do that. It wasn't necessarily a suggestion – perhaps it was being interpreted as a suggestion – that we would need some sort of additional dedicated communications infrastructure to support that. If that's the case, then probably from a cost standpoint alone, it is a significant impediment. So this was just one of the points that kept coming out when we talked to people and that we wanted to capture in the documents.
Chris then continued with the PowerPoint presentation. At the conclusion of the presentation, the participants were asked to discuss the proposed short and long-term solutions for addressing the ICM transit data gaps.
Gary: I have a question about potential next steps. I know in previous discussions, in talking about the inclusion of additional hardware in the demonstration phase – I don't know if it's a mixed message or maybe it's confirmation that could be had. If we're going to try to demonstrate the short-term solution for park-and-ride utilization and to install a parking management system at major park-and-ride facilities, is that hardware installation going to be then possible to have in the proposal for the demonstration phase?
Steve: The USDOT has received approval from upper-level management that your costs as a part of integrating your various existing systems for ICM, your costs to add equipment/infrastructure to fill the current arterial and transit data gaps, those are eligible costs. But the total amount that's available for the demonstration sites, which is $14 million, that has not changed.
Michael Dillon: Will there be an opportunity for any public/private partnership type arrangements on any of these demonstrations?
Steve: Yes, there are. You would need to contact the pioneer site you're interested in partnering with and have a discussion with them.
Jim: I thought I heard about some decision support that was required to know what to do with this information but I don't remember seeing any presentations or work on that end of things. Is there a parallel effort along with this data gap thing to sort out what decision support is required?
Steve: Cambridge Systematic is working on an action plan for decision support systems or decision support tools for ICM but there hasn't been a whole lot of results yet on that.
Chris: Essentially what has been done is a somewhat parallel effort, in that for the purposes of the demonstration phase there's been an exercise gone through to identify the different styles of decision support systems that might be appropriate for the demonstration sites, up to quite sophisticated decision support using forecasting and modeling capabilities to support the decision-making environment.
Jim: If you haven't already, I would urge you to get some transit and highway operator participation in the scoping of that decision support, at least in a QA mode, if not in a direct input mode.
Chris: I'm not sure to what extent they've gone through the same exercise that we have in this component on the data gaps, but I'll pass that along.
Steve: So far we have touched on the decision support tools topic with the pioneer sites. We've kind of gone over the different levels of decision support. So that provided some input into this whitepaper that Cambridge Systematics is working on. Our pioneer sites are proposing systems that range from coordination to a full decision support system, but details are lacking at this point. I also wanted to add that, although it's not a decision support system, necessarily, for Integrated Corridor Management, there's a project that we're working on called the Transit Operations Decision Support System (TODSS). It's a prototype demonstration that helps transit agencies identify and prioritize service disruptions and then provides a list of options to address those disruptions and provide restoration in service.
Jim: That was the model I was referring to. I was involved with some of the early TODSS work and some of the partnerships between government agencies, vendors, whatever seemed to work well, and I hope you do the same thing for the ICM decision support.
Steve: We are going to convene a group of the ICM transit stakeholders to review the TODSS system and our partner for that effort is Pace Suburban Bus System.
Brendon: You mentioned Wi-Max communications but shouldn't you add DSRC and Vehicle Infrastructure Integration?
Chris: Good point. I know on the arterial side we definitely had that. I'm not quite sure why we didn't on the transit side but I will go back and look at that.
Brendon: This will be an ideal application for that since it's corridor-specific and you could use the DSRC network, if it was established, to have much more frequent downloading of information.
Michael Dillon: They're calling what was VII, IntelliDrive now and if you look at the definition of IntelliDrive it's all-encompassing of the range – everything from traffic management, commercial, transit, safety, tolling. Definitely want to take a look at it.
Brendon: I had another comment. It's more related to a traffic data gap, but I know Steve's slides of the presentation mentioned buses as probes. There's some efforts underway to do that. Do you have that captured on the traffic data gap side?
Chris: We do, yes. Specifically for the arterial data gap we included a variety of probe techniques as being potential, including using buses, and we talked to a number of people who had done experimental work in that area.
Brendon: Including the FTA-funded project that's going on at Ohio State right now?
Chris: We spoke to one that was in Oregon but I'm not sure about the one in Ohio State.
Brendon: Raj Wagley is the FTA project manager for the Ohio State bus probe project.
Steve: The recommended action is to include probe vehicles, not limited to just transit vehicles/buses, but also maintenance vehicles and things like that. That's in the Data Gap Action Plan. One problem with limiting probes to just transit vehicles is that you'd probably have to have high frequency bus service on that arterial in order to get the data transmission rates that you would need to support arterial data for ICM (e.g., arterial traffic speeds).
Doug Jamison: We just recently in Orlando did signal timing across jurisdictions and found one of the major problems to be that nobody's on the same system clock. That's something that I think at least needs to be noted in here – if you have multiple agencies, you have to come down to a common clock if you're going to go down to real small latencies.
Steve explained to the participants that the comments and recommendations from this discussion would be reviewed and incorporated into the ICM Data Gap Action Plan. Steve also invited any additional comments to be emailed to him by February 17, 2009. The Action Plan, which incorporates both arterial and transit data gaps, is set to be completed by the end of February. It will then be distributed to the pioneer sites, the transit stakeholders, and the arterial stakeholders. Steve closed the meeting by thanking everyone for their participation.