Smart parking is one of the first applications that comes to mind when most people think of smart cities. The concept of smart parking just makes sense:

  • People are less frustrated, and they don’t have to spend hours driving in circles.
  • Traffic congestion improves, which is a benefit for the city.
  • It’s environmentally friendly, because it lessens smog buildup and carbon dioxide emissions.
  • There are economic benefits for businesses, because people can easily shop at stores, and for the municipality, which can increase revenue through parking and ticketing.

With this list of benefits, it sounds like a no-brainer for all cities. But in practice, it’s much more difficult to implement. And if you’re an application developer, you likely already know that entering the smart parking market isn’t a walk in the park...ing lot. (To see the evolution of smart parking, take a look at this Mother Jones.)

Below, we’ll explore a few things you’ll want to keep in mind about smart parking applications and questions you’ll want to ask before development and deployment.

Cities: Consider The Following Before Launching A Citywide Smart Parking Application

There are real upfront costs.

Both the hardware and the network can have hidden costs that you may not have thought through. For example, most smart parking systems have some kind of in-ground sensors, which are more reliable than using smart parking sensors on a parking meter. But if you build on a mesh network and you’re operating in a dynamic radio frequency (RF) environment, a car parking over the sensor can break your mesh. To solve this, you can have the parking meter talk to the sensor in the ground—but then you’re effectively paying for two parking systems. So, if you want the mesh to perform, you will likely have to overengineer it to ensure you don’t deal with blackouts.

There can be complications brought on by the network.

Low power, wide-area networks (LPWANs) don’t always work as well as they’re initially designed to work. For example, if you put an RF device on the parking meter, you can easily create a solid mesh network. However, the sensor on the meter may not be able to determine whether or not something is in the parking space, which makes it fairly unreliable. What’s more, a system like this would be able to tell you only if a spot had been paid for or not; it couldn’t alert you to where cars actually are. Thus, you might get a lot of false positives in terms of open spaces.

Enforcement can be an issue.

Some parking applications don’t do anything to help with piggybacking, which can lead to enforcement issues. Let’s say someone pays for two hours of parking and stays only 20 minutes. Depending on the application used, someone else might be able to park there without the meter registering that the previous car left the spot. If your municipality wants to leverage the revenue benefit of parking—both from a metering and enforcement perspective—you need to be able to determine who paid for the parking space and when the individual leaves the parking spot.

There can be dilemmas with replacing the current system.

If your city has any kind of metered parking, there’s likely an infrastructure around coin collection, credit card processing, enforcement, and more already in place. So a more difficult question you’ll have to dig into is whether or not you can and should replace a workforce of people. If you do replace these jobs with technology, what role will these employees move to? You can see how on the surface, smart parking seems like a no-brainer—but once you dig into the limitations, some issues will come up.

What about the convenience factor?

If you need a smartphone app to pay for parking, you’ll need to consider your demographic. Does everyone in your city have a smartphone? If you’re in a large city you can probably get away with this, but it’s going to be a lot more difficult in smaller cities. Additionally, you have to think about your city’s tourism industry. Do tourists need to download an app and enter their credit card information just to park for a day, or is there a more streamlined method available to visitors? This is a good example of how parking applications look great on paper but can be more difficult in practice.

Developers: Ask Yourself These Questions Before Creating A Smart Parking System

Many developers are working their way into the smart parking space, but only a few have succeeded. This is largely because there are more intricacies involved in smart parking applications than meet the eye. We’ve outlined a few of the questions you’ll have to deal with below.

What is the goal of your smart parking system?

If your goal is to develop a smart parking system for an airport, you know it’s important to deploy a system that helps people park faster, know when garages and lots are full, and make their  flights on time. You also know that it isn’t a big deal to have a few false positives, because the driver can likely find another spot with ease. But if your goal is to develop a municipally focused parking application—where citizens use their smartphones to find parking spots to go shopping—a false positive could be a big problem. The point is, it’s important to focus on the goal of your system before designing it.

Who will be using the application?

You can (obviously) be a lot more flexible if you have to cover a smaller area. If you wanted to create a parking solution for theme parks, you could have people download the theme park app or have a central kiosk with a QR code reader they can scan. But if you’re trying to cover an entire city, you have to create a solution that works for all of the citizens. Thus, determining who’s parking and what they’re using parking spaces for is an important step.

How big is the network?

If your goal is to create an application to cover a parking garage, you can easily put up the necessary repeaters, gateways, and collectors. But if you’re trying to deploy in a city, you’ll have to determine where you’ll actually put these devices so the network is operational in a busy RF environment. Even with all the cool low power, wide-area network (LPWAN) technologies out there, a lot of people underestimate how hard it is to deploy a network in an urban area. Determining the size of the network you’ll need to deploy is vital.

How will people pay?

Will people use Apple Pay or Google Wallet? Will they use a meter credit card reader or a multi-space payment machine? Will they scan a QR code with their phones? Is there an app they have to download in order to park and pay? All of these questions will need to be answered before product engineering begins.

Can you gain the traction to adopt and implement your system before you go out of business?

Municipalities typically work on very long budget cycles, so this is a legitimate question you’ll need to answer. It’s worth considering that some smart parking application companies have raised tens of millions of dollars and have still run out of money. To mitigate this risk, consider solving an issue on a smaller scale before taking on municipal work.

Cities: Selecting A Vendor

If you’re ready to move forward and select your technology and vendor, you’ll want to first consider the following questions.

Do they have an understanding of the challenges specific to parking? Can they serve complex applications? Before selecting your software vendor, you’ll want to take a look at their developmental history and use cases to see if they’ve built or deployed a system similar to yours.

Do they have the ability to do firmware over-the-air?> Once your system is in place, you likely won’t replace it for at least five years—so you should look for a technology that you can easily update without having physical access to the device.

Do they have a robust system of identity management? In other words, does the vendor have a system in place that allows you to know when your devices are deployed and where they are?

Do they offer a secure system? You’ll want your new system to include top-of-the-line over-the-air security, gateway security, and cloud-side security.

Is the installation relatively easy from a technology standpoint? Remember, most of the people who will be installing these types of IoT systems are construction workers—not wireless engineers. So you’ll want the installation to be as simple as possible.

Developers: What To Keep In Mind During Smart Parking System Creation

Developers typically look for a system that answers as many of a city’s challenges as possible, so they have to take on less of them (i.e., device management and firmware over the air). Many of these challenges are outside the expertise of the application developers. Most developers are good at iPhone apps or some basic web portals, but aren’t as great at the embedded development side.

So devs should choose a technology that requires the least amount of customization to meet the city’s needs.

The real question is: What are your customers’ needs? What are cities looking for? You can get an initial idea based on the advice we’ve given thus far in this article. Your technology needs to be able to do the things we’ve outlined—and the best way for that to happen is to select a wireless technology that already has a lot of those features included within the system.

Cities: What To Keep In Mind For Your Municipal Deployment

Have a solid pilot plan. Because your new system might have flaws or kinks to work out—or it may have behaviors consumers will have to learn—we highly suggest incorporating your pilot plan into the most technologically friendly area of your city. If you try to deploy the system across the entire municipality too quickly, you won’t be able to fix issues early on or understand how consumers work with the devices in place.

Take citizen feedback into consideration. Engaging your citizens to find out what they do or do not like about the new system can help you make the changes you need early on.

Once you’ve selected a vendor, don’t look back. It’s critical to remember that there will always be a newer and “cooler” technology out there—but deploying something new every six months can be very frustrating for a customer. If the system is functional and offers a decent user experience, try to improve the system you already have instead.

>Developers: A Note On Application Deployment

Working with a municipality on a city-wide article deployment is significantly different than simply creating an iPhone app. When Angry Birds is down for a few hours, it’s frustrating—but if a citizen gets a parking ticket because of a glitch in your software, or doesn’t know how to use the parking application because the user interface is too confusing, that is a real frustration. Keep this in mind when you go to creation your smart parking application.

Use Case Calculations For Smart City Parking Applications

Let’s say the city of Parkington is looking to make some changes. Ironically, parking is a challenge around Parkington, so city officials have set out to improve the on-street parking experience. Historically, it has been up to the driver to find an open spot, but city officials know that finding a spot is a hassle for their citizens—and that an updated smart parking system would help improve the flow of traffic and attract consumers for restaurants, shopping, and events.

Parkington has done enough research to know they need the following:

  • A sensor tied into each parking meter in order to track if a spot is in use or not.
  • An app that shows open spots.
  • A way for the sensors to communicate with the app.

With these parameters in mind, the city of Parkington is in search of a smart city parking solution (or a smart parking meter solution, if you will).

To allow for the sensors to communicate with the application, simple information needs to be exchanged that tells the end user whether the spot is in use. Since it would be too complicated and expensive to cover the city in a wired network from one parking meter to the next, Parkington decides to start testing out wireless technologies. They come up with four possible choices—Bluetooth Low Energy (BLE), ZigBee, 6LoWPAN, and Symphony Link—and decide to pull together some wireless range calculations to see which solution is best for Parkington.

Here is the situation:

  • The antenna is placed on the second floor of a city building (a block-wall building).
  • The receiver is placed at the height of a parking meter (one meter off the ground).

Below are the wireless range calculations by technology for the parking use case:

    BLE   ZigBee   6LoWPAN   Symphony
  TX Antenna Height (m)   6   6   6   6
  TX Power (dBm)   4   18   3   18
  TX Antenna Gain (dB)   0   0   0   0
  Frequency (MHz)   2400   2400   2400   915
  RX Antenna Height (m)   1   1   1   1
  RX Antenna Gain (dB)   -6   -6   -6   -6
  Structure Loss (dB)   11   11   11   11
  Sensitivity (dBm)   -93   -102   -101   -140
  Margin (dB)   20   20   20   20
  Range   77   291   116   2594


(Note: 11dB structure loss consistent with propagation through an 8″ masonry block wall.)

Whereas the other technologies have great uses for a vast array of projects, Symphony Link fits perfectly for a smart city parking project with its ability to cover a wide area while consuming little power. That means the sensors in Parkington will be able to run for years on one tiny battery, and the information will be able to transmit over a few thousand meters.

Some Advice Moving Forward

For cities: Don’t take the challenge on by yourself. If you don’t have someone on your team who has deployed a mobile network in an urban area or have a consultant that’s helping you, it’s probably not a good idea to take on smart parking by yourself. Be sure that you’re prepared for what’s to come before launching a citywide smart parking application.

For developers: Despite all of these considerations, smart parking still has huge market potential. We suggest you begin thinking of something others haven’t thought of when it comes to smart parking applications. Use the considerations above as your guideline for a head start.

For both: Have great communication. Municipalities need to convey their requirements early, often, and explicitly—and developers need to repeat back the requirements along the way so both parties know what they’re getting into. {{cta('c6ad0840-fa8c-42bd-9fa3-a6bd85218561')}

Jennifer Halstead

Written by Jennifer Halstead

Jennifer Halstead, MBA, CPA brings more than 20 years financial industry experience to Link Labs. She began her career in finance within the pharmaceutical industry and has continued in both public accounting and private companies. She passed the CPA exam with the 3rd highest score in the state and completed her MBA with an accounting concentration (summa cum laude). Jennifer has worked with several software companies and has led multiple venture financing, merger and acquisitions deals. She has helped companies expand internationally and has managed the finance department of a startup to 33 consecutive quarters of growth prior to acquisition. After the acquisition, she served as the Controller of Dell Software Group’s Data Protection Division where she managed a portfolio of multiple hardware and software products to scale and achieve over triple-digit growth worldwide in 18 months. Jennifer brings a depth of finance experience to the Link Labs team.

Related Blogs

Asset Tracking, BLE Asset Management

How To Use GPS Tracking to Improve Fleet Efficiency

Asset Tracking, BLE Asset Management

How To Leverage Fleet Tracking For Success

Asset Tracking, BLE Asset Management

How Asset Tracking Transforms the Future of Your Company

Subscribe to Link Labs' blog weekly update!

Subscribe

Subscribe to Link Labs' blog weekly update!