USPS looks to rush in delivering with smart city technology
USPS looks to rush in delivering with smart city technology
The United States Postal Service would like to aid in the expansion of smart city technology, according to a recent report from the Office of Inspector General. Proposed are five programs that would focus on how the USPS can help improve smart city technology.
The concept of an “Internet of Postal Things” was first described in a 2015 white paper that explored how connected technologies could both help cities, while at the same time improving the USPS, in regards to its own operational efficiency. This new report explains how the Postal Service can harness IoT to speed up the adoption of smart city technology.
See also: Will smart cities need AI to truly flourish?
Out of the five possible pilot programs, two of these would occur in Pittsburgh, partnering with Carnegie Mellon University. One of the projects would be placing CMU-developed software and cameras in some USPS vehicles, to study road conditions and identify potholes and cracks. The other would attach accelerometers to postal transportation, in order to detect vibrations during bridge crossings on normal vehicle routes. The data collected would assist in monitoring conditions of the infrastructure. The city’s light rail actually already uses this technology.
“We put the whole postal physical infrastructure on the table for people to use,” states Jacob Thomases, a public policy analyst with the Risk Analysis Research Center, which made the report. “Cities very quickly came back to us with the vehicle over and over again because it has a power supply and you can attach a sensor and not have any involvement by the letter carrier.”
Moving on to Montgomery County, MD, the proposed pilot program would use USPS vehicles to gather data from sensors on water pipes and fire hydrants in order to determine problems in underground water infrastructure. Furthermore, a program in Portland, OR would connect air quality monitors to the vehicles.
There is a slightly different spin put on the New York project idea. It would be based on the postal carriers’ knowledge of the neighborhoods they serve. “An application could be created for the carrier’s device to capture this knowledge to allow more consistent input of information about properties in order to detect early signs of blight. For example, the carrier could report that a house is falling into disrepair or that a mailbox has not been emptied for a long time,” states the report.
USPS needs further research to begin
Through this research, the United States Postal Service hopes to gain better understanding of the value in the existing infrastructure, possibly adding to the agency’s bottom line. Last year, USPS requested information for the next-generation postal vehicle, according to Piscioneri. The request specifically mentions data collection, along with drones, she states, though they are not the main focus.
USPS’s Vice President of Delivery Operations, Kevin McAdams, said, in response to this report, that he is in favor of the projects but wanted more clarity in three topics not addressed by the paper: fleet modification, privacy and bandwidth issues associated with data collection and the workforce.
“We support opportunities for new potential sources of USPS revenue and the ability to copartner with local government agencies which may earn ’good will‘ for the Postal Service,” McAdams explains. “However, it is important that any service we may end up providing is properly costed and that all potential liabilities are fully explored.”
Through these types of programs and partnerships with local government, suppliers and customers, the Postal Service can experiment with new business ideas such as connected mailboxes and other new services for communities. The answer to successful implementation of an IoPT will be the creation of an open platform where data is managed, stored and shared, along with solid privacy and security policies.
The post USPS looks to rush in delivering with smart city technology appeared first on ReadWrite.
(42)
