Charlene Wilder: Okay. Before starting our question and answer session, we'd like to thank our speakers today for today's webinar, Thomas Guggisberg, David Gehrs, and Michael Haynes for a job well done. We hope you can use their lessons learned in managing your data information systems and other pertinent advanced technology systems. Let's start answering questions.
Q: What are the challenges with including staffing for ITS in operating budget?
A: Haynes:: Oh, gosh, well not being in the hiring position ever, it is hard to attract and retain IT staff. We could always use more DBA support, database administration. And given budget and things that are very tight, it's sometimes hard to attract and retain those individuals.
Q: I see another question there about skill sets - What special skill sets would you look for when staffing an ITS department? Do analysts face new problems that need new experience?
A: Haynes: I would say folks who have a lot of skills in Oracle analysis and Oracle development is very important to build complex SQL statements to turn this raw data into these kinds of reports. Thomas, I don't know what experience you've had. [The following was submitted after the webinar.] I would look for motivation and a background in Transportation Engineering or Systems Engineering or at least Computer Science. Having staff that understands how transit works is hard to come by but many may have years of field experience but not understand computers and data. You really need to find people who know SQL (Structured Query Language), Oracle (or SQL Server) programming development, development in Visual Basic or Active Server Pages is important to develop web-based applications. Knowledge of GIS is also critical for developing geographic output. We need more analysts who can dive into the data and help turn data into information and applications that allow users to access the information in a logical manor. [Thomas Guggisberg additionally submitted the following] Strong management skills and experience maintaining systems would be a plus.
Guggisberg: Yeah. I would add that on the more high level side, that one approach we took in terms of making sure that staffing was included in the budget was we actually put in our RFP staffing recommendations requirement by the vendors, so that they would give some insight into how much time would be necessary now to manage this system, so we could start figuring that out. What we found though is that the vendors didn't want to shoot themselves in the foot by saying, "Yeah, we want to sell you this system, but it's also going to cost you all this kind of money on the operating side." So in that case, they're probably not going to get the award. So it was really a difficult situation for us. But what we found to be helpful was that by looking at the system and the requirements and how it affects operations, that's the easy part. The more difficult part is where Mike's coming from. The operations side, we did not find that we needed to add any additional staff to keep the system going. The maintenance agreement and what was included on that side seemed to work pretty well. It was really on the other end, on the data side that it was really a challenge. With that said, I would strongly recommend that folks look at the reality of administrating this system, not only from an IT perspective, but also from a planning and data analysis perspective. If you truly want to receive a return on your investment, that's where you want to put some money in. If you look at some of our bullets in terms of the challenges and you see the things that need to happen, those are them. I want to be sensitive to the question in terms of budgeting. In our case, we ended up having to do a post implementation staffing plan that involved looking at each key department--planning, scheduling, IT, operations, transportation, maintenance--and really look at our real staffing needs within these areas as it relates now to this new system being in place. We came up with a three year phased in approach for making changes, if that's any help.
Q: How did you overcome the staffing and skill set issues?
A: Haynes:: We still have many staffing and skill set issues here at the CTA. We did form a group called the Transit Systems Support group, which I am on staff and we work to support and keep all transit related systems running. The advantage of being in technology is we can attempt to leverage the knowledge base of the agency IT staff, which tends to focus on the ERP system.
Guggisberg: User group meetings, creative training options such as webinars, phone support, quality documentation and of course, outside formal training in Crystal Reports and other programs/technologies. Although comprehensive, the initial training provided as part of project implementation was not enough.
Q: I've been scanning through the questions, Thomas and Charlene. I think I can address a few of them by combining them. I noticed a few questions about our announcement system.
A: Haynes: We do support 100% stop announcements in our system. I would categorize it as a very successful implementation. It was one of the most successful ITS projects we've ever deployed here.
Q: How do we address stops that are very close to each other?
A: Haynes: Our system is just smart enough. It pulls up to the stop. Sometimes if the stop is really close, as soon as the doors close, it recognizes that it's within the stop window of the next stop and the next announcement will come right away. I will add that we do have some problems sometimes with early stop announcements or late stop announcements. But that's sometimes due to how the route was initialized. The routing is smart enough that if a bus comes into a route mid-route, it'll pick itself up and figure out what routes it needs to do.
Q: There was a question very similar to that. It was: Do we use GPS/AVL vehicle mileage information as our official mileage for preventative maintenance?
A: Haynes: Not at this time. We are still using HUB odometers. But we are looking at trying to use the AVAS data to populate that.
Q: There was a question also related to CTA GPS.
A: Haynes: I believe it's both GPS location and ordered list of bus stops by route. That is correct. As Thomas mentioned, we have to have a data collection band. His system is no different, where we drive all of the routes of a bus stop change. So it a listing of stops, and the system knows what stop it needs to call out next, based on both odometer and GPS data.
Q: There was a question on the peer-to-peer program. The question was asked: Do you use just particular consultants?
A: Wilder: For the Federal Transit Administration, I've used the peer-to-peer program many times for my grantees. The peer-to-peer program offers, they have a list of experts across the nation to choose from. It's not just one consultant. There's a list to choose from. That's how I'm answering your question on that.
Gehrs: Actually, I would like to comment on that question, if you don't mind. The peer-to-peer program, in the past, has relied heavily on the use of state and federal ITS expertise, with some use of consultants. Now that the program is in cooperation with the ITS America, there's a new push to find more consultants who can participate as peers in the program. It's a little tricky because they're private consultants doing work for the public. There's some additional review that we have to do. But we are planning on using additional consultants. If anybody has questions about that, I would recommend they contact Terry Reagan. His name is on a slide at the end of the presentation. He is the peer-to-peer program manager.
Haynes [submitted after the webinar]: I've used the program a number of times and found it an easy way to travel to another transit agency and discuss how we are analyzing data and implementing ITS.
Q: I see that both CTA and CDTA have all these systems presumably provided by different vendors. How far have the ITS standards for transit, i.e., the transit communications interface profile, been specified to ensure vendor independence in creation of standardized interfaces between the vertical systems?
A: Haynes: Well, our system does use the onboard SAE J1708 communications protocol for communicating between onboard devices. I'll admit I'm not as familiar with the TCIP interface for perhaps reporting or other kinds of information like that. But at least onboard the bus, it's a J1708 compliant system, which is what's allowing us to put a J1708 compliant Opticon TSP device and try to integrate that with the AVAS system.
Wilder: This is Charlene. I would like to say that as part of AVL systems, there are travel information systems and, for example, we have a travel information multimodal door-to-door trip planning project with the Chicago RTA. We are using the TCIP standards with XML format. So it is being used.
Guggisber: This is Thomas at CDTA. I just want to add that we also are using the same J1708 centered interface. The question I'm reading here looks like it's more geared around how did you ensure that? The way we ensured it was we did include TCPIP compliance. Actually, we put New York State ITS standards, which were consistent with the federal standards, in our RFP, to make sure that there was compliance there. Then we reviewed that intently with the vendors prior to award. [The following was submitted after the webinar]: We put language in the RFP to ensure compliance. As an example, for data transmission, conformance to the National ITS Architecture Standards for center to center communications, we specified at the time, 2002, that this would be NTCIP Standard 2304 NTCIP-AP-DATEX-ASN. If the standard could not be met an explanation why and a proposed alternative must be provided.
Q: Is there a reason why the agencies did not use the TCIP Standards?
A: Haynes: We did not state that we are NOT using TCIP Standards; we simply stated that we are using J1708 on-vehicle communication standards.
Q: What is "INIT" in the previous slides that were discussed?
Guggisberg: I-N-I-T is an acronym. It is a company acronym standing for innovations in transportation. That is a company that we have been working with, who we are in contract with, who we love for our CAD/AVL system.
Q: How did the actions of the mobile supervisors change when you got the CAD/AVL systems? Do you use the information for service restoration?
A: Guggisberg: Good question. Mike, do you mind if I take this?
Haynes: You have to, because we don't have it.
Guggisberg: The CAD/AVL system did change the actions of the supervisors quite a bit. The second part of the question is service restoration. But before I get to that, the supervisors, previous to the CAD/AVL system that we purchased, they had an actual AVL system in front of them before this. They had information coming across with data coming across our radio system regarding alarms and driver who would actually leave the garage and there would be a radio transmission on that kind of thing, pull in pull out, but very limited. Now, with all the information, the supervisors are fully engaged. We totally redefined the field operations or dispatching operation at CDTA as a result of this system. We've created a new division, if you will, headed up by a new superintendent of field operations. We have retrained all of our staff repeatedly to make sure that they are fully using all of the capability within the CAD/AVL system, from looking at vehicle information to schedule adherence to alarm information to events to communicating through the radio system and just voice. So dramatic change really occurred. I could talk for hours about that. So I'm just going to suffice it to say that in terms of service restoration, that was the biggest challenge. That's why I say it was a good question. Service restoration, there are means by which you can actually log out and log in a vehicle and make changes that way. It's been the hardest thing to deal with, because of detours and other kinds of things that need to be programmed in the system. My point is I just want to mention that is not indicative of how we're using all of the other functionalities. But the service restoration was definitely one of the bigger challenges, because it was so unpredictable. I think that the guys down there or the girls down there are just very focused in on "this is how you do something." It's very standard. This is an area that varies and changes every day.
I will add that another piece of this that may be helpful to agencies is that what we came up with is a transportation alert procedure, which really has nothing to do with CAD/AVL other than it gives them information about what's going on in the street. That information we've now been able to log in an email that is now disseminated not only internally and to our website in the way of service detours, service cuts, delays, even when service operates normally, we send out now information to just about everyone in the organization. We now post it on our website to give the public information. We also send that information out to the traffic management centers in our region to coordinate with them as well as through the throughway authority. So they've taken on the dispatching system so much that that kind of application is coming out of it. Hopefully, that sort of gives you a sense of how the supervisors like this change with the CAD/AVL.
Q: How happy are you with the init AVL system? We had one vendor that we used and they were not happy with starting a procurement with that particular vendor.
A: Guggisberg: Well, it depends on who you ask. We, obviously, are committed with this vendor and have been. We are happy with them. I don't want to speak for the entire agency though. There are challenges that you go through with these systems and we certainly have them. I don't necessarily believe they're specific to init. I think that every CAD/AVL vendor is going to bring those same set of challenges that we've experienced. But the one thing I will say is that init has been just as committed as we are to success and that certainly helps in making things happen. To this day, I will say that as the system has been in now for a couple of years, there are still many challenges that continue to come up that we work very closely with them on.
Haynes: I would echo the same thing in terms of the challenges of working with vendors and vendor management is every bit a part of it. What we are very happy with is the data that we're provided with on a daily basis and the processes of that and then getting that data into a database where we pick up and build the report.
Q: Tom mentioned ITS data supporting marketing. What do you see as the most promising uses of ITS data for marketing and marketing research?
A: Guggisberg: Interesting question. In our case, I think I would answer that by looking at new service. The ITS system, the AVL system, it gives us a lot of new information regarding how we could potentially roll out new service. For example, we could put routes up in our north country region are actually just getting ready to be unveiled. We have four new routes happening in Saratoga Springs, which is one of our northern cities. That service I think will be enhanced by the fact that we have this CAD/AVL system. When we roll it out, we'll be able to get a lot more information about what's going on with it, to see how well it's doing so that we can make adjustments early on, rather than have to wait years before something changes. In addition to that, adding new service, we needed to figure out where we put stops, where we put amenities and things of that nature. With buses going up into the service with automatic passenger counters, we could figure out exactly where people are getting on and getting off to figure out where we can place bus stops. Initially, it's a little bit of a crap shoot, for lack of a better word, to take some chances on where we should put service. But after a certain period of time, we'll be able to make some significant changes there. That all ties into how we market the service. In our case with Saratoga, it's an historic city, a lot of challenges on where we can place service as well as put stops and what kind of frequency we can provide. It's a matter of coverage versus frequency. They have to kind of choose what they want. With the AVL system, we'll be able to make better decisions there and be better able to market the service. But on top of all of that, of course, getting all of the information out of the AVL system will yield a number of demographic kinds of things that we can get into on a spatial side. Where are we boarding and alighting the most? What's the population in those areas? How does that relate to providing new fare cards? Do we want to put a fare outlet in that location? We can market that way. Those are just a few examples, but there are many, many other ways as well. And we do a lot of that work with our AVAS data as well. I'd also like to mention that our fare card data, our automatic fare transaction data, AFC data, we do an awful lot with trying to match ridership patterns and geographically to find out demographic patterns and things like that, as well as with our GIS software.
Haynes [submitted after the webinar]: CTA is working to use our AFC data in conjunction with our APC data.
Q: The next question for CTA: Do you do 100% stop announcement? If so, how successful is its implementation?
A: Haynes: Yes, ALL Stops! On the Rail as well, although the rail is a different system and is manually controlled, it is automatic only in the sense that the operator logs in and the stops and announcements are listed sequentially for manual playback.
Q: Have you had any issues with the accuracy of data that APCs provide?
A: Haynes: I did quite a bit of study with APC accuracy when we first got our system. I would say that it's accurate enough for planning level analysis. We do have an ongoing project right now where we're validating the accuracy of APC and the processes and the statistical validation of such to support our NTD, National Transit Database, reporting. So we are working on trying to get the APC data to a point where we can turn it around and make it our basis for the NTD reporting. I imagine, Thomas, you can speak to your accuracy as well. I'm not sure.
Gehrs: Actually, Michael, this is Dave. I was going to concur to your exact points, maintaining and calibrating the systems for the APC units is critical for that. But it is something you have to constantly check. As far as having faith in the data, we're certainly within the 95% accuracy.
Wilder: This is Charlene. That's really good, because some agencies only have like 90% accuracy. That's very good.
Haynes: I would say that ours is at that level.
Q: Please confirm this data is accumulated and supplies the NTD reporting? E.g. for demand responsive & the questions that include: trip to kidney dialysis, etc.
A: Haynes: We are working with a vendor to validate our APC reporting processing to support NTD reporting. We are not using the data to look into demand responsive service.
Q: Okay. How does your test route of 35 intersections work with signalized intersections?
A: Haynes: We have coordinated the traffic signal priority equipment that is provided to us by our AVL vendor with the traffic controllers that exist with each of the municipalities. So we have equipment in each of the controller boxes at each of the intersections. So how does it work in terms of the details of it? I can't speak to that. But we had three different types of controllers on our corridor and we were able to work with them by coordinating with the actual municipality and their engineers to have space in their actual boxes at the intersections to interface our equipment with the traffic controller. In terms of priority, we're definitely not anywhere high on the list. Obviously, emergency vehicles will take precedent as well as other kinds of traffic issues that may come up due to problems that I am just completely unaware of, because I'm in transit and they're in traffic. But that overall is how we coordinated that and did that.
Wilder: Would you say that your AVL enhances transit signal priority while detecting buses as they approach intersections and the impact on cross traffic is minimized? I think that's what you had said in the past.
Guggisberg: Yes, that is true. The cross traffic is definitely minimized. [The following was submitted after the webinar] The solution is not yet available as this is in the early design stages.
Q: Farebox data provides boarding information, not alightings, only at best. Therefore, farebox data can't be used to calculate max flow, which is one of the most important planning numbers needed for farebox data, because it can't be used to calculate max load.
A: Guggisberg: This is where the APCs come in.
Haynes: That's where the APCs come in, but what we do at least here is we take the AFC data and use it to scale up the APC data. That is, APC data is only available on 42% of our fleet, which is close to 1,000 buses. But what we do is we find out what stops are being used the most and then go and use our AFC data to scale up the values that we get and distribute the FC boardings across the route, based on the APC data that comes in for both boardings and alightings, which is an effective way of complementary systems and tying that in. Whereas you can get a lot of information out of your APC system, even if you don't have it on all of your buses, because you use it in conjunction with your AFC data. [The following was submitted after the webinar] Noted, however, it is important to note that using fare-box data WITH APC data allows the agency to leverage a system that is more costly and typically only installed on a percentage of the fleet with a system-wide data collection device that collects more data.
Q: I did see one question that I wanted to address. Somebody mentioned how important the TCRP reports are for both real-time bus arrival information system and archiving.
A: Haynes: The Transit Cooperative Research Program does have many reports. For example, they did a TCRP Synthesis 48 report on real-time bus arrival and they did a synthesis of transit practice, 24 AVL systems for bus transit. If you look at their website, there are many reports that can help you with your system. I saw this was one of the questions.
Gehrs: Charlene, this is Dave speaking. Just so you know, we do have a library of those reports and we do use them pretty regularly.
Q: We're looking for support to analyze accuracy of predictions, looking for references to documents/publications, contact information of agencies that already performed such tests.
A: Haynes: Please contact me off-line, and I can put you in contact with two staff members here at CTA who can address the study we did on the accuracy of predictions and some findings from a customer satisfaction of the BusTime pilot project.
Q: Is real-time bus arrival data available to the public?
A: Haynes: I actually discussed that in my project. We're only doing that on one route right now as a pilot. I would ask David or Thomas to address that from CDTA. [The following was additionally submitted after the webinar] For CTA, only on one route, on a pilot bases - a project is on-going to expand the real-time system.
Wilder: This is Charlene. I do want to address it from a public view point. On the FTA website, there is next bus real-time information return on investment study recently done by Booz Allen that addresses this question. There's also a synthesis report on real-time bus arrival systems done by the Transportation Research Board. I'm just telling you two reports on this. Do you have anything else to add, Tom or Mike?
Gehrs: Thomas, do you guys provide real-time information?
Guggisberg: We do not currently provide real-time information, only on one wayside information sign, which is in a test environment right now. We do plan to roll that out further later this year. [The following was additionally submitted after the webinar] For CDTA, this is only available for one stop at a wayside sign, which is undergoing testing.
Wilder: Which relates to the AVL systems. The multimodal door-to-door trip planner systems with the Chicago RTA, we're going to be adding arterial systems, so it's going to be real-time in the second phase. The first phase is going to be rolled out late this summer. We also used real-time information, WiFi systems with our ferry systems. We had a demonstration that was totally successful. Parsons Corporation has now bought the system and is using it for travel information systems for passengers on ferries.
Q: Operator logging is a problem. The ultimate goal should be to eliminate all operator logging for best quality. Can you address operator logging?
A: Guggisberg: Mike answered that before with trying to streamline it through the proximity card and an interface with the farebox system. In our case, although we would like to do that, we have found that by simply better managing our people, it's been able to work fairly well. We initially had I'll say about out of 200 vehicles going out each day, we had about 120 drivers actually logging in properly. That has now changed dramatically through better management of the drivers, them understanding that this system is their friend and it helps them. As time has gone on, they've gotten that message. They understand that message. The more training they've received on the mobile data terminal to see where they are, to keep themselves on schedule, to manage the announcement system and so on, they've become much more understanding of that. So it's improved. We do not currently have a plan to automate that, although we are looking at an interface between our farebox system and our AVL system to have it be one logon. It may be an ID card as well for that. But there are risks to that in our case. We don't really see it as being that reliable, because there are many points of failure there as well. It comes down to how can you minimize your points of failure? In our case, we haven't seen the benefit yet, but we are looking at it.
[The following was submitted after the Webinar] The operator logon is a problem. The ultimate goal should be to eliminate all operator logon for best quality. What we're looking at doing, it's a long term project, is when we would get new fareboxes, we're hoping that maybe we could have a logon where the driver would simply tap his ID badge to the farebox. The farebox would be integrated with the onboard AVAS AVL system and would log him in directly through all of that and that maybe his badge number would have his work and that would all be tied together. That could take some time, as you can imagine, integrating those systems.
Haynes: We at least looked into developing a fully integrated log-on with our fare-box to improve data log on quality, however we are not currently procuring a new fare-box.
Q: From Caller #1: We are looking for information on agencies that have done testing of accuracy of real-time predictions. Any kind of reference, documents, or agencies who have a person whose contact would be available to help us figure out how to do this?
A: Haynes: Thomas, did you guys do any of that?
Guggisberg: We are working directly with the vendor to see what's possible through their solution, because we can only work with the tools we have. We didn't go out and look at others, because we wanted to go with an integrated system. I can't really offer a whole lot.
Haynes: We did a little bit just in our pilot and you're Pace, so you're right next door to us. If you send me an email, my contact information, I'll try to put you in contact with the project managers who looked at some of that accuracy. We did do some testing where we put people in the field and monitored with web-enabled phones. They were looking at the pilot project website and trying to do some of that evaluation. But again, it was not published or anything. It was just in-house evaluation of the pilot project. Feel free to send me an email and I will put you in contact with individuals at CTA who performed that work.
Wilder: This is Charlene again. I do know of a case study in Seattle, Washington. I can send you a copy of their report that was done. In King County, they had an AVL system that was linked to an automatic passenger counter for BusView, a real-time passenger information system. This worked very well. Customers were able to view scaled maps of all buses and zoom in on the region surrounding their homes, etc. They said the original cost of the system was $15 million. With additional capital costs for providing real-time information and hardware, that was an additional $250,000. They said it was very successful. I can send you a link that talks about the system snapshot of King County AVL system. There's an actual report that came out on it. In Denver, Colorado, the regional transportation district, RTD, they have an operational AVL system that was one of the first public transportation systems using the AVL. They said that it's greatly improved their response system to emergencies and provides real-time information to customers through the Internet and so forth. They said that the total capital cost of the system was $171,000 and they actually used 20 vehicles. Also, Transit Tracker system, which is mentioned in the report that I mentioned to you on the FTA website, which is next bus arrival return on investment study real-time information by Booz Allen, they actually used the Transit Tracker system that was done to archive AVL system and real-time system with Oregon State DOT. These are some of the systems mentioned.
Q: From Caller #2: How difficult was it to train individuals who had no computer experience and how did you get over it?
A: Haynes:Oh gosh, that's still a challenge. Even to the extent for our operators, training them in using the system just in the logging in and getting familiar with a new login system was one side, but certainly our field staff, I still get calls and I walk through my website and have them, "Okay, click here, click here. Here's the information." In general, they get it kind of from the other people who are around them. But that's why I can't stress enough the value of making these things web based, so they're platform independent and they work across the agency and letting them get into the data as easily as possible. I don't know, Thomas, similar for you?
Guggisberg: Yeah. I certainly echo your comments. I think that they're spot on. I think I would add that on the CAD/AVL side, although we received a lot of training up front with the project, it was difficult to transition with only that training. So we found we needed to do follow-up training on top of it. We designed internal training that was presented by internal staff to give folks a little more detail and an opportunity to get refresher training if they needed it and so on, rather than just rely on the one or two weeks or so that was given up front. We formalized it and then we actually integrated it into our full scale dispatcher training that happens every three years or so. We do that internally. So we took it very seriously and made sure that there was formal presentation and a very well laid out format and forum for that. We continue to do so, as I said. It took a lot of extra effort beyond the initial project training.
Q: From Caller #3: I just wanted to know, what is the coordination between the FTA project that you talked about with RTA and CTA?
A: Haynes: I'm not actually aware of that project.
Wilder: This is Charlene. I do have a project that I discussed. We have a multimodal trip planner system. It's going to be rolled out at the end of the summer. It's managed by me and it's with the Chicago RTA. The funding came from the ITS Joint Program Office, now RITA. We had a partnership with the Chicago RTA. Actually, the way it was done is that we went out and had an RFP. We did a long selection process. There were about 12 transit agencies that applied for the cooperative agreement.
Q: From Caller #4: This question is regarding transit signal priority for CDTA. I was just wondering what kind of detection system you used and what kind of communication technology you used between bus and signal controller?
A: Guggisberg: I can't speak specifically about the detection system. I have to follow up on that. In terms of the communication between the controller and the bus, it is using radio technology, RF communication. Again, to be truly accurate in this response, I'd much prefer to follow up with you on that question, if we can submit that and get it to you offline. [The following was submitted after the webinar] Since TSP is still in the implementation stage, this question is still under discussion with the vendor.
Q: Do you use the GPS systems for detection systems/rail systems? Are you using that?
A: Guggisberg: No, not for TSP. There's a different technology that's used for that. I just don't want to speak out of turn. But I know it's not GPS.
Haynes: The technology that we are investigating is an Opticon infrared system emitter on the bus, emitter or receiver on the light mast arm pole. That's what we've been looking for integrating. We did look at GPS. There's also other ways of doing it with WiFi combo GPS. But neither of us is really at the point where we've got a full blown TSP out there. So I think we'd like to defer those to discuss with maybe the agencies that have TSP and have had more success in it, such as LA County Metro, King County Metro, as well as a number of others.
Wilder: That sounds good.
Guggisberg: Yeah, I would echo that. For our purposes, too, as we are not quite complete with it. We are getting ready to get into some discussion about potentially even changing what we originally planned for that. I hope that's okay with the gentleman who asked it, but that's going to be my preference as well. I echo Mike's comments.
Haynes [submitted after the webinar concerning GPS and rail systems]: No, we use a network of way-side track circuit sensors fed back to our control center via relay houses and a fiber-optic backbone.
Q: The examples shared have dealt with fixed-route service. How have the ITS tools been used to support demand-response paratransit service?
A: Haynes: We do not have ITS tools for demand-response Paratransit service, our Paratransit service is now part of the Pace Suburban Bus System in the Chicago region.
Guggisberg: CDTA uses data and voice communications, CAD/AVL mobile data terminals for text messaging, on-time performance tracking, diagnostics and emergency alarms, as well as, general information messages. We are reviewing new MDT's for manifest transfer, directional routing and mapping functionality.
Q: CDTA, are you planning wire internet onboard your buses?
A: Guggisberg:We are reviewing the feasibility of WiFi. However, the maintenance and coverage of such service may prove to be a much larger challenge.
Q: Is automated fare collection system and data analysis going to be covered here?
A: Haynes:No, due to time constraints.
Q: What are the costs (person and $) to develop and maintain these systems?
A: Haynes: We have about four data analyst developers working with AVAS data two in Planning and two in Technology. We also have a Database Administrator, but that individual is responsible for all Oracle Databases at the entire Authority. We also have a radio/destination sign technician at each garage, as well as a technical lead in our Bus Engineering Division. Finally, we have a staff of three who work in our Data Collection group to maintain the data that are sent down to the buses. Costs are not known.
Guggisberg: We have one full time application/systems administrator and one full time maintenance technician and it is not enough. Ideally, we would have another full time data analyst/report writer and a supporting project manager for new features, upgrades, enhancements, etc. Costs are not available.
Q: For CTA: You mentioned HASTUS schedule software, and bus stop announcement system (Clever Devices?). How are bus stop locations (geo info), and stops by route info (ordered list) maintained? In HASTUS, in Clever Devices, in both, in a 3rd system? I would guess that there are small changes all the time...
A: Haynes: Stops are maintained in the vendor supplied "BusTools" software which creates the distribution sent down to the fleet, and also loaded to the Oracle reporting database. We send out changes to the schedule four times per year (unless we find a mistake!) and changes to the routes/patterns/stops data about every three weeks.
Guggisberg: All data is maintained in Hastus, this includes stops, routes, distances, variants, patterns, etc. The scheduling group is responsible for the quality of this information.
Q: What are the challenges with including staffing for ITS in operating budgets?
A: Haynes: Finding the funds to keep IT and ITS staff in an ever shrinking operating budget!
Guggisberg: The major challenge is to justify a new position for a system that is intended to bring efficiencies to the organization. We have also found that adding a new position does not always solve the problem and can also create a whole new set of problems that were previously unknown. This compounded by each ITS component bringing its own unique set of maintenance challenges. For example, SMS real time information exporting to a web page/PDA requires extensive testing on the device and data sides along with coordination with Marketing and the user community to ensure usability and accuracy.
[General Comments Received from a Participant on TCRP]: TCRP reports on APCs and Data Analysis are very helpful. They suggest Farebox systems are not designed to do passenger counts. Starting with reporting needs is great. Reporting might be driven by National Transit Database reporting requirements. www.ntdprogram.com. TCRP has good reports on Performance Measurement that might be useful.
Q: What is the relationship of ITS data collection & the regional MMTPS (multi-modal project)? Did the MMTPS affect your data collection formatting and reporting outputs?
A: Haynes: I am not aware of this project.
Comment: J1708 (serial communications) is useful, but should start to look at more modern standards that use Ethernet communications.
A: Haynes:The on-board bus communications protocol is quite versatile and allows for devices in a rugged environment to communicate. Ethernet communications are more suited for communicating data off of the vehicle to servers on a network. Significant programming at the application layer is required to have on-board systems communicate to each other via the Ethernet network layer.
Q: Have you had any issues with the accuracy of data that APC's provide/Can you provide more information on validating APC data?
A: Haynes: Yes. Off-line please contact me directly.
Q: For real-time arrivals, how do you inform the public when a vehicle turn backs or a prediction disappears due to operational changes?
A: Haynes: For our pilot system, the predictions expire in a set time if the bus is turned around on a short-turn. I can put you in contact with the staff working on full deployment for more information.
Guggisberg: We are still in the testing stage.
Q: Rather than bus arrival prediction, might just present deviation from schedule. Also, what many passengers want is not RTBI, especially when headways are under 15 minutes. They want to know about disruptions of service the most.
A: Haynes: Noted. Actually what we are finding is that customers really want are the time to the next bus or the bus interval. People do not really care if buses are never on schedule (for headways less than 15-minutes) so long as those vehicles maintain a consistent interval.
Q: To what extent, if any, do you develop ConOps for use of the data? The classical systems engineering approach would be to use a ConOps to define the users of data, their needs, and then develop the data and outputs based upon those needs. A more bottoms-up approach would be to collect data that sensors readily provide, come up with creative ways of presenting it, showing it to users, and working with them to apply the data for their needs, or to refine the data to better meet their needs.
A: Haynes: I would say we clearly take the bottoms-up approach as we take the data that comes from the AVAS and play with it until we can make a meaningful report that addresses a need and apply the data to meet new needs. Our users do not know what they want nor do they understand what is available or how to turn data into information. We also simply do not have the time or resources to have users define the needs as they do not know how to translate those needs into a request. In a way it may seem like we are years behind the systems engineering process, however once a product is made we do work to getting the queries into procedures that run monthly.
Resources Mentioned During Webinar
http://onlinepubs.trb.org/onlinepubs/tcrp/tsyn24.pdf - Transit Cooperative Research Program (TCRP Synthesis 24), AVL Systems for Bus Transit, A Synthesis of Transportation Publication, sponsored by the Federal Transit Administration (FTA).
The following are selected resources from the ITS Lessons Learned Knowledge Resource database. Visit the database at:http://www.itslessons.its.dot.gov
Consider the pros and cons of performance bonds as they may not be appropriate for all types of procurements.
The Riverside Transit Agency experience with the terms and conditions for procuring equipment and software for automatic vehicle location (AVL) and computer-aided dispatch (CAD).
Consider issuing separate awards for specific project components when procuring divergent technologies, equipment, or services.
The Riverside Transit Agency experience with the methods used to procure equipment and software for automatic vehicle location (AVL) and computer-aided dispatch (CAD).
Exercise careful planning in preparation for issuing an RFP to help mitigate cost, schedule, and performance risks.
The Riverside Transit Agency experience with the methods of award and terms and conditions used to procure equipment and software for automatic vehicle location (AVL) and computer-aided dispatch (CAD).
Adjust bus schedules to assure adequate time to accomplish rail-to-bus connections, given the risk of late train arrivals at connecting stations.
Experience of the Utah Transit Authority in implementing a Connection Protection program for rail-to-bus passenger transfers in Salt Lake City.
Incorporate real-time bus and train location information in the Connection Protection algorithm.
Experience of the Utah Transit Authority in implementing a Connection Protection program for rail-to-bus passenger transfers in Salt Lake City.
Develop ways to raise awareness among businesses to promote advanced traveler information sources to their customers.
An Acadia National Park experience in ITS deployment.
Design the system to withstand the demands of the physical environment in which it will be deployed.
Virginia's experience implementing a pilot automatic vehicle location (AVL) system in an urban winter maintenance operations setting.
Improve demand response transit using ITS technology, including CAD/AVL, with Mobile Data Terminals (MDT), electronic ID cards, and Geographic Information Systems (GIS).
Different paratransit agency experiences with CAD/AVL, Mobile Data Terminals, electronic ID cards and GIS, all to accomplish improved operational goals, is outlined.
Involve and collaborate with a broad range of users during software design, development, testing, and deployment to increase the return on investment.
New Mexico Department of Transportation's experience in designing and deploying a web-based software application to simplify the increasing complexity of coordinating rural transit funding.
Recognize the value of other agencies' experiences when planning an ITS project.
TriMet's experience with the deployment of Transit Tracker in Portland Oregon.
Minimize technical issues encountered with integrating ITS components by planning for issues and developing solutions prior to project implementation.
TriMet's experience with the deployment of Transit Tracker in Portland Oregon.
