Unique Challenges of Parking Technology on a University Campus


Unique Challenges of Parking Technology on a University Campus

Campuses present many unique challenges in the management of their parking assets. A diverse population—from freshmen to faculty—with diverse communication preferences. Garages and surface lots. Myriad ways to pay. Different permits for different zones. Add to that mix a large medical center with 24/7 patient (transient) parking and proximate parking for medical personnel providing urgent services. Quite a mix.

 But there’s more. We must accommodate demand for reduced rates and the associated vouchers. And those vouchers better work—efficiently and every time—in garages with a PARCS system as well as surface lots without. We have to maintain a keen eye for permit abuses, whether intentional or accidental. And we must be “at the table” with the university’s planning to increase the likelihood that parking is adequately accounted for.

Proper enforcement must take into account the various ways a customer can be allowed to park. Scanning a plate with an associated permit that does not allow parking in a particular zone is only part of the story. Did they pay a transient rate with another method? Are they on a validation list for a particular department (e.g., new medical center staff orientation)? Or are they in a valid zone, but attempting to use a permit that is already in use elsewhere? These checks require information from varied sources to be evaluated to determine an outcome.

Sounds like a daunting task, and it is, but it is all solved with the same solution: communication. Communication between the varied sources of data is not a nicety, but a necessity to running the parking operations and optimizing the customer experience. And there are lots of communications. (Pun intended.)


Today there are software applications affecting almost every facet in our lives. Parking is no exception. Payments, permits, enforcement, and gate operations all have some software component in their operations. As an operator, you must ensure that the applications are not only open—allowing for other software applications to send and receive information—but also able to communicate effectively.

First, they need to be speaking the same language. Fluent French is wasted on those who do not understand the language. Same for applications. Translators can help, but much like the game of telephone as a child, they can present opportunities for errors.

Second, they need to agree on what level of security will be needed for the integration. Rightfully so, there is high sensitivity with personal data requiring applications passing such data to have it encrypted (scrambled). Each application needs to know how to scramble and decipher the information it communicates with others. 

Third, applications must have the pieces of data that are required by the other applications. Imagine an enforcement application that requires a license plate and a garage application that does not capture it. Even though they talk the same language and have the same scramble technique, if the data is not there, it does no good. Having the communication language, method, and the data is only the start. 


For the applications to understand what they are communicating (e.g., individual or license plate), the element needs to have a common way of being identified between the applications. 

If one system has me as Bob Murray and another has me as Robert Murray, they will not easily—if at all—be able to recognize this as the same. If one system has license plates with spaces and another does not, it has to be agreed which one will be used and ensure both applications are formatting the data correctly. (Hint: Removing a space is much easier than trying to figure out where one has to be added.) 

Data Sharing

Data sharing can be achieved by allowing the applications to communicate directly with centralized monitoring. While this distributes the work, it also burdens each application with being able to communicate with all other applications. 

A more common option is to have all of the applications communicate with a centralized application that is responsible for collecting and redistributing data as defined. This allows for augmenting data from more than one system and ensures all of the systems are getting their data from a centralized source. Another advantage is all of that data is there for analysis. (But that’s for another article!)


All of this communication must occur securely over varied networks. We have wireless and wired (both serial and Ethernet) networks in play. You need to create secure channels for the various applications to communicate. This will require knowing where—the address—to whom the data will be sent and by whom it will be received. If there is a third party involved, you will need to connect with their IT department to create the communication channel. 

And Don’t Forget the Human Aspect

You have to interface with your IT supplier (either in-house or outsourced) to ensure all of the systems are correctly sized and monitored. You must communicate what the expected load will be on the servers and the network so it can be properly planned for. You also must work with the university to understand the considerations that go into defining parking demand. Be sure to work closely with the administration to ensure parking is at least considered in every major decision. And with a medical center, as medical technology changes, so does the stay profile of patients…and, therefore, parking demand.Planning is your friend here. Determine what each application will be sending and receiving. Lay out what the language will be, what the encryption will be (could be none), and what is the common piece of data that will tie the information from one system with the information in the other. Work with your IT department to set up the appropriate systems. 

Of course, many of challenges of parking technology transcend the nature of the customer. But few introduce the challenges and complexity of a university campus. Walking into a football stadium on a crisp autumn afternoon seems to make it all worthwhile!

Bob Murray is Chief Technology Officer for CampusParc, which operates and manages the parking assets of the Ohio State University parking system under the terms of a 50-year Concession Agreement, and a big Buckeye fan. He can be reached at bmurray@campusparc.com


Article contributed by:
Bob Murray
Only show results from:

Recent Articles

Send message to

    We use cookies to monitor our website and support our customers. View our Privacy Policy