Knowledge Resources

Project teams should consider the effects of custom versus semi-custom hardware and software technology based on their operational capabilities and processes. Projects deploying customized technology build hardware/software that meets specific design requirements. However, building technology is often more expensive in terms of time and money than purchasing commercial off-the-shelf (COTS) technology. Also, custom technology typically requires thorough testing to identify and correct problems. COTS technology, on the other hand, typically has already undergone rigorous testing, but often does not have all the operational features desired for a specific project. Consequently, these trade-offs, as well as budget constraints, can compel project developers to make decisions that minimize costs without compromising operational capability.

The following lessons learned are based on the experiences of the Chicago, Illinois and Montgomery County, Maryland teams in selecting and adapting COTS technology to develop their respective parking information systems:

• Understand that budgets have a major impact on the selection of the technology procured for a project. At the time that Montgomery County began their project, they were not aware of any software product on the market that served all of their needs. Since they did not have a large enough budget to have software designed for the specific purpose of this project, they had to modify COTS traffic control software to adapt it to meet their needs. As a result the operational capabilities were limited.
• Be aware that budget constraints can affect operational efficiency. In order to change the messages displayed and to set the thresholds for when the messages display, the software for the Montgomery County system communicates with the variable message signs via a cellular modem. Due to budget limitations, the system relies on only one cellular modem. As a result, the single modem must call the signs one at a time when relaying information, which leads to moderate delays in updating the information on the signs.
• Anticipate customized COTS software to require the same rigorous testing as customized software. Since there was no test set for the Montgomery County's COTS system, it was difficult to determine if the software had a bug in the testing phase. In other words, the only way for the project team to test the software was to do so with the live system. This required them to set up a test site where they could operate the signs in test-mode without displaying them to the public.
• Consider the adaptability of the technology to specific project needs. Montgomery County's system only allows for two modes (i.e., the lot is either available, or the lot is full recommending an alternative), and all three signs in the system must be in the same mode at all times. This has been a limitation for the project. First, it would be preferable to have more than two modes to allow the system to refer motorists to different parking alternatives depending on the time of day. Second, because of the location of the signs relative to the station, it would be preferable to have the ability to display a unique message on each particular sign as needed. The best example of this is that the bus route between the Norbeck park-and-ride lot and the Glenmont Metro Station ends morning service at 8:55 AM, so it is important that the two signs that refer motorists to Norbeck after the Glenmont parking is full, no longer do so after this time. It would be desirable for these two signs to begin referring to motorists to Wheaton, an alternative Metro Station, thereby exercising a third mode beyond the two that currently exist. As a result of the limitations of the system, Montgomery County had to make the decision to not display parking information on any signs after 9:00 AM.
• Consider the adaptability of the technology to real-world conditions that might arise. Montgomery County's system does not allow for built-in "thresholds" to vary by day of week. This can pose a challenge since the number of vehicles remaining overnight in the lots tends to vary by day of week and because the fill rate also tends to vary by day of week. They found that the fill rate on Fridays is significantly lower than on other weekdays, and as a result, the algorithm that works on other weekdays does not apply on Fridays. As a result, the county had to make the decision to not operate the signs on Fridays.
• Consider the weather-related limitations of the video detection technology. In the case of the Montgomery County project, the team knew that the video detection technology they were using would have weather-related limitations. They have found that heavy rain results in erratic counts, and during the winter season the team found that snow plows dumped snow onto pedestrian walkways, causing pedestrians to enter the detection zone and be mistakenly counted as vehicles. The Chicago stakeholders also experienced challenges with snow conditions. They have found that when some of the parking spaces in the lot become blocked with snow piles following a sizable Chicago snow storm, the system will report that there are more available spaces than there actually are since many are in fact unusable.
• Be flexible to using new operational processes to achieve new operational capabilities. The Chicago stakeholders did find that special events can be accommodated with their system. For example, every summer a carnival takes place at the Hickory Creek station. To accommodate this, the Mokena police contact Metra in advance with an estimate of the number of spaces that will be occupied. Metra then adjusts the baseline "threshold" within the system and the system adjusts the occupancy numbers accordingly.
• Consider technology that will allow for growth and expansion of the system. In retrospect, the Chicago project stakeholders feel that they should have selected a full matrix sign instead of the limited numeric dynamic signs that were selected. A full matrix sign would have provided the capability to display information beyond parking space availability.

In deploying a parking information system, project stakeholders looking to purchase COTS software should be aware that the software may not support all of the desired project requirements. Also, tailoring COTS software will require additional costs to develop and test the new functionality. Finally, when implementing such systems, stakeholders should consider the limitations in selecting and adapting the technology as adaptations can result in changes to operational capabilities and processes. The lessons learned above, if applied in designing new systems, are expected to improve operational efficiency and motorist mobility at transit parking facilities.