|
|
(72 intermediate revisions by the same user not shown) |
Line 1: |
Line 1: |
| [[File:InfoGraphic.png]]
| | <!--{{Chapter |
| =Introduction= | | | blueprint = Transportation |
| | | | sectors = Transportation |
| A SuperCluster is a multi-city, multi-stakeholder collaboration organized around common project objectives and shared solutions. Committed cities/communities and partners jointly | | | authors = Wilfred Pinfold, Skip Newberry, Jeff Allen, Ken Montler, Timothy Smith, Joe Cortright, Greta Knappenberger, Jill Sorensen, John Feo, Corey Marshall, Jose Gonzalez, Geoffrey Urbach |
| tackle shared issues, develop and deploy shared solutions to create economies of scale. | | | poc = Wilfred Pinfold |
| | | | email = wilfred.pinfold@opencommons.org |
| | | document = TransportationBlueprintFeb18.pdf |
| | | chapter = 700 |
| | | image = Transportation1Chapter.jpg |
| | | summary = A SuperCluster is a multi-city, multi-stakeholder collaboration organized around common project objectives and shared solutions. Committed cities/communities and partners jointly tackle shared issues, develop and deploy shared solutions to create economies of scale. |
| | }}--> |
| The Transportation SuperCluster (TSC) was formed and is managed by forward looking municipalities interested in preparing their infrastructure for new technologies that look set | | The Transportation SuperCluster (TSC) was formed and is managed by forward looking municipalities interested in preparing their infrastructure for new technologies that look set |
| to provide better, more equitable services at lower cost. The TSC mission is to: | | to provide better, more equitable services at lower cost. The TSC mission is to: |
Line 24: |
Line 29: |
| We are interested in addressing transport issues between urban environments in a future version of the blueprint. | | We are interested in addressing transport issues between urban environments in a future version of the blueprint. |
|
| |
|
| =Pilot Programs for AV Technologies=
| | ;Pilot Programs for ACES Technologies |
| In the last few years we have seen three significant shifts in urban mobility, | | In the last few years we have seen three significant shifts in urban mobility, |
| #sharing, | | #Autonemous |
| #electrification, and | | #Connected |
| #autonomy.
| | #Electric |
| While this document is nominally focused on Autonomous Vehicles many of the desired community benefits can be gained by implementing first and last mile
| | #and Shared |
| | These technologies are collectevly known as ACES. Many desired community benefits can be gained by implementing first and last mile |
| solutions with a shared electric fleet. Further, by running pilots of shared electric fleets that are autonomous ready or partially autonomous we will gain | | solutions with a shared electric fleet. Further, by running pilots of shared electric fleets that are autonomous ready or partially autonomous we will gain |
| considerable insight into how to deploy autonomous vehicles when the technology is ready for full operation. | | considerable insight into how to deploy autonomous vehicles when the technology is ready for full operation. |
Line 47: |
Line 53: |
| the process could be: | | the process could be: |
|
| |
|
| ==Transit Station to Company Campus: ==
| | ;Transit Station to Company Campus: |
|
| |
|
| As an example of transit to company campus a number of large companies in the Portland area are served by TriMet stations that are somewhat distant from | | As an example of transit to company campus a number of large companies in the Portland area are served by TriMet stations that are somewhat distant from |
Line 57: |
Line 63: |
| access to campus. Unidentified passengers could be identified and connected to the company security officer for access or denial of access to campus. | | access to campus. Unidentified passengers could be identified and connected to the company security officer for access or denial of access to campus. |
|
| |
|
| ==Transit Station to College Campus: ==
| | ;Transit Station to College Campus: |
|
| |
|
| Like the previous pilot but with lower identification requirements due to the open nature of campuses, a similar transit station to campus pilot can be | | Like the previous pilot but with lower identification requirements due to the open nature of campuses, a similar transit station to campus pilot can be |
Line 63: |
Line 69: |
| many locations. | | many locations. |
|
| |
|
| ==Transit Station to Public Place (e.g. shopping mall): ==
| | ;Transit Station to Public Place (e.g. shopping mall): |
|
| |
|
| Unlike the more homogeneous employee and student pilots, a transit station to public place pilot is more like regular bus service and provides the | | Unlike the more homogeneous employee and student pilots, a transit station to public place pilot is more like regular bus service and provides the |
Line 69: |
Line 75: |
| (including ID card, facial recognition technology, biometric ID, etc.) should be investigated. In-vehicle monitored cameras may be used. | | (including ID card, facial recognition technology, biometric ID, etc.) should be investigated. In-vehicle monitored cameras may be used. |
|
| |
|
| ==Residence to Transit Station: ==
| | ;Residence to Transit Station: |
|
| |
|
| For this pilot we could use a bus or car. If the bus is relatively small and picks up only passengers in a local neighborhood they may feel safe. With a | | For this pilot we could use a bus or car. If the bus is relatively small and picks up only passengers in a local neighborhood they may feel safe. With a |
| car which carries 2, 4, or 6 passengers and only collects passengers at one stop this issue is removed. | | car which carries 2, 4, or 6 passengers and only collects passengers at one stop this issue is removed. |
|
| |
|
| =Shared Mobility Vehicles =
| | ;Electric Vehicle Charging Infrastructure |
| [[File:ResortCar.png|left]]
| |
| We can and do share a wide range of vehicles. Most of these rideshare options use conventional high speed gasoline vehicles. The use of traditional
| |
| gasoline vehicles is driven by the expectation that the rides will use highways. For a last mile solution this capability is not necessary. Urban
| |
| Speed Vehicles (USVs) are a federally-approved, street-legal vehicle classification under the Federal Motor Vehicle Safety Standard (“FMVSS <sup>1</sup> 500”)
| |
| passed in 1998. Their popularity has grown in niche markets with improvements in battery technology and a broader
| |
| acceptance of electric vehicles.
| |
| [[File:ElectricBus.png|400px|right]]City leaders and transportation planners are now incorporating USVs as a critical part of the mass transit solution.
| |
| Electric USVs are also the ideal starting point for autonomous vehicles because of their capital and operational cost, safety, and versatility.USVs
| |
| offer an environmentally friendly approach to first and last mile challenges, expanding the distance most people will travel without a car from ¼
| |
| miles to 2 miles. Adding autonomy makes them economical as a door to transit option in all neighborhoods. One major advantage of the FMVSS 500 law is
| |
| that it does not require the extensive crash testing mandated for high speed vehicles. The lower speed allows the vehicles to use lighter weight
| |
| construction, modular assembly techniques, and fewer parts. The lower barrier to entrance created by FMVSS 500 law provides companies the ability for
| |
| greater customization, faster innovation, and shorter time to market. The result is an affordable, practical and sustainable “link” in the transportation
| |
| system that blends with walking, biking, and mass transit. Further the modularity makes local maintenance and repair possible. As reliable automation
| |
| becomes available these vehicles will be able to charge themselves and arrive at a customer's door ready for a trip to a transit stop or local business.
| |
| | |
| Urban Speed Vehicles are not subject to the same crash test and safety regulations making is possible to offer a variety of cab modules on a simple chassis
| |
| platform. The modular design makes it possible to purpose design and build vehicles to meet fleet requirements. Utilizing standard high quality drive
| |
| components, including lithium iron phosphate batteries and high end drive train components allows Mobility Cubed to build an affordable, reliable and
| |
| sustainable electric vehicle. A low parts count combined with design modularity means the vehicle can be “kitted” for local assembly and shipped cost
| |
| effectively all over the world.
| |
| | |
| =Freight=
| |
| | |
| [[File:ElectricTruck.png|left]]Freight has many vehicle options including drones for dropping off packages and driverless delivery vehicles. These driverless delivery vehicles could
| |
| ferry groceries and other packages to your front door on demand for a low cost per trip. Building out mixed, hub-and-spoke delivery systems, optimizing
| |
| freight routes, and scheduling deliveries to minimize congestion can significantly reduce costs and improve quality of life. Reducing dwell time of freight
| |
| vehicles at delivery points is a complex problem requiring close coordination of public and private concerns --- zoning officials, parking authorities,
| |
| freight services, and building/site managers.
| |
| | |
| =Mobility Hubs=
| |
| Any transit stop can be turned into a Mobility hub where the first and last mile vehicles are serviced, charged and stored when not in service. At these
| |
| hubs passenger experience can be improved with digital information signs that respond to real-time conditions, improved lighting, improved pedestrian
| |
| safety, bike racks, improved safety including CCTV cameras, and much more.
| |
| | |
| Using technology to increase safety and security at transportation hubs improves ridership and reduces cost. Transit hubs can become business hubs where
| |
| people stop for food and coffee, to pick up and drop off packages, and to do some local shopping on their way to and from work. Attachment A of this
| |
| document offers an “EV-Ready Transit Hubs White Paper” exploring this topic in more detail.
| |
| | |
| ==Electric Vehicle Charging Infrastructure==
| |
|
| |
|
| We plan to work with Forth Mobility on demonstration projects to advance electric, smart and shared transportation. We plan to work with Portland General | | We plan to work with Forth Mobility on demonstration projects to advance electric, smart and shared transportation. We plan to work with Portland General |
| Electric Company (PGE) and their efforts to accelerate transportation electrification. | | Electric Company (PGE) and their efforts to accelerate transportation electrification. |
|
| |
|
| ==Maintenance and System Operation==
| | ;Maintenance and System Operation |
|
| |
|
| Urban Speed Electric Vehicles like Mobility Cubed’s World Bus are constructed with less than 300 major parts, compared to over 2,500 parts for a typical | | Urban Speed Electric Vehicles like Mobility Cubed’s World Bus are constructed with less than 300 major parts, compared to over 2,500 parts for a typical |
Line 126: |
Line 92: |
| vehicles. The vehicles can be assembled and maintained at facilities near their operation, thereby providing local jobs, supporting the local economy, | | vehicles. The vehicles can be assembled and maintained at facilities near their operation, thereby providing local jobs, supporting the local economy, |
| reducing shipping and logistics costs. | | reducing shipping and logistics costs. |
|
| |
| =Right-of-way Management=
| |
|
| |
| Urban Speed electric vehicles can interact with the current built environment in new ways. For example, rather than consider curb pick-up and drop-off
| |
| these vehicles can come into building spaces without polluting the environment. Picking up directly from transit stops and dropping off in schools,
| |
| hospitals, universities and offices protects passengers from the elements in ways that have not been possible before. Covered transfer facilitates better
| |
| protection for patients and people with disabilities.
| |
|
| |
| Similarly last mile freight carried by vehicles that can come into warehouses and factories offers many benefits including clearing the streets. These
| |
| driverless delivery vehicles and small autonomous drones can ferry groceries and other packages to customer’s front doors on demand for a low cost.
| |
| Building hub-and-spoke delivery systems, optimizing freight routes, and scheduling deliveries to minimize congestion can significantly reduce costs and
| |
| improve convenience. Reducing dwell and idle time or getting vehicles off the street completely during delivery requires coordination with public and
| |
| private concerns, zoning officials, parking authorities, freight services, and building/site managers.
| |
|
| |
| One advantage of autonomous urban speed electric vehicles is that there is no reduction in efficiency, increase in cost or increase in pollution for a
| |
| larger number of small vehicles. The vehicle can therefore be sized for the appropriate purpose. For example picking people up or dropping packages
| |
|
| |
| at home can be done with a small vehicle whereas taking people or deliveries to a work campus like Intel or Nike can be done with a bus or delivery truck.
| |
|
| |
| =Connected Vehicle=
| |
|
| |
| Connected urban speed electric AVs can operate without traffic signals. They can synchronize their behavior through vehicle-to-vehicle (V2V) communications
| |
| at junctions and can operate at safe speeds that change by location and road conditions. Vehicle-to-infrastructure (V2I) communications can be used to
| |
| activate street lights, get updated route information, open doors, and receive scheduling information.
| |
|
| |
| ==Transaction Platform==
| |
|
| |
| As a citizen moves through a city they interact with city services, transit, schools, parks, and shops. Each of these interactions contains information
| |
| that can be used to deliver better services. In a smart city each interaction creates a digital transaction informing both the citizen and the city service
| |
| providers. These transactions should be simple and secure. Ideally they should happen invisibly to the citizen while respecting a citizen's expectations of
| |
| privacy. For example, as a commuter gets on light rail for the morning commute, there is an interaction between something the commuter carries and the train
| |
| that completes the ticketing transaction. If the commuter chooses that this transaction be anonymous then the city will know that a passenger stepped onto
| |
| light rail at one station, off at another and paid the appropriate fare. If the commuter chooses to share personal data with the city then the city will be
| |
| able to track progress from home to work thus better understanding connections and opportunities to improve the overall commute.
| |
|
| |
| We plan to test such a transactional platform that facilitates low friction data exchange and a personal policy engine that allows each citizen to manage
| |
| and control how and if to share personal information. We will also test capabilities that allow a service provider to create incentives for citizens to
| |
| share personal information ensuring the optimal balance between openness and privacy.
| |
|
| |
| ==CityWeb ==
| |
|
| |
| Technology becomes more pervasive everyday, and cheaper, faster and easier to use. We expect more from it with every new generation. Two significant
| |
| technology trends, namely Internet of Things (IoT) and open data, are promising innovation and change at an even greater pace than the usual rapid-fire
| |
| deployment and adoption of technology. Increased funding in the Smart Cities, Transportation, Grid and Energy sectors, which seek to exploit these trends,
| |
| are driving the need for greater software development. So are Federal Government initiatives requiring compliance. With IoT and open data, it is becoming
| |
| increasingly possible to build complex, interoperable software ecosystems that provide us with a richer, more time-efficient, cost-efficient, more
| |
| energy-efficient and human-friendly digital quality of life.
| |
|
| |
| However, the cost to develop, deploy and maintain these complex technology projects isn't getting correspondingly cheaper or easier. The burden of
| |
| achieving these goals is still difficult for those in the public sector, academia, or even commercial organizations who might not have deep emerging
| |
| technology skills. Writing "Smart City" applications can be hard. Often, the software and tooling environment is proprietary and the resulting
| |
| applications fail to interoperate with applications developed elsewhere. It can also be expensive due to a lack of in-house knowledge, skills and
| |
| tools for such software.
| |
|
| |
| There is an understandable hesitation in adopting closed, proprietary solutions or even application programming interfaces (API) that are pushed
| |
| forward by commercial vendors. Even if the API is open, the code supporting it often is not, and locks the consumer into the ecosystem of the
| |
| commercial vendor, without the ability to interoperate with others. The vertical software stack supporting such alternatives only results in the
| |
| use case or application sector getting siloed into fragmented ecosystems. There are significant cost and adoption advantages when APIs are not only
| |
| open but backed by open source communities. Leveraging such available resources (or getting them to cooperate with each other) would be valuable. It
| |
| would also align with the Federal initiative for a "City Web", which encourages the adoption of common and proven approaches to the Smart City mission.
| |
|
| |
| The President's Council of Advisors on Science and Technology (PCAST) issued a report in 2016 on "Technology and the Future of Cities" , in which they
| |
| identify the need for more effective approaches <sup>2</sup> to data integration and sharing to solve problems in cities. They point out the:
| |
| * Lack of universally accepted platforms and standards.
| |
| * City incentives that drive a focus on local issues.
| |
| * Incomplete awareness of available solutions.
| |
| * Lengthy procurement processes that are unsuitable for agile, iterative, technology-based solutions.
| |
| * and resulting:
| |
| * Uneven distribution of solutions.
| |
| * Idiosyncratic implementations.
| |
| * Rarely re-usable software for other cities.
| |
| * Expensive implementations.
| |
| * Disadvantages to smaller cities with fewer resources, less capacity for innovation who fall further behind in the digital quality of life offered to their residents.
| |
|
| |
| There are few private and no public mechanisms today to distribute the new knowledge and data associated with innovations comprehensively across the
| |
| nation's cities. There is no "app store" specific to city applications...".
| |
|
| |
| Hence they recommend the concept of a comprehensive information infrastructure for cities to use and share, the notion of a "City Web", an
| |
| formation-sharing platform benefiting all cities, especially those with fewer resources. This would include information on solutions, best
| |
| practices which have been tried and tested, and had the benefit of experience. "The goal of the City Web is to allow the accumulation and replication
| |
| of urban solutions and associated data and technologies in ways that benefit cities with different sizes, different technological know-how, and
| |
| different financial capabilities."
| |
|
| |
| We use the above concept of a "City Web" from the PCAST report to build upon and address these issues and more. To that end, we propose the
| |
| implementation of "CityWeb", an open data platform and smart city solutions resource. CityWeb can be built and implemented for any locality or
| |
| Smart City, supplemented by collaboration amongst participants and cities, domain experts and users, and strong open source development communities
| |
| working in the Smart City technology fields. NIST and US Ignite are working to establish a "CityWeb" project, which has as its goal the implementation
| |
| and definition of an integrated data management portal and information-sharing platform for Smart City solutions. It is both a resource for Smart City
| |
| technology solutions as well as a locality-specific portal with links and and archives of information that are relevant to the community. A CityWeb
| |
| stance can be implemented for each Smart City, with city-specific information. These CityWeb instances are intended to be bolstered by additional
| |
| resources in the form of an open source software development community contributing to a Software Development Kit (a "CitySDK") for Smart City
| |
| technologies. Below are some key principles of a CityWeb as we envision it, namely:
| |
| * Information Sharing and Community
| |
| ** Leveraging the experience and knowledge of previous projects and work done in this space as noted previously to benefit all.
| |
| * Open Data Portal
| |
| ** Having data generated by Smart City infrastructure and participants be open and available to users and 3rd party developers.
| |
| * Privacy and Control
| |
| ** Adhering to "MyData" principles, giving users control over and information about the information that is collected about them, whom it is shared
| |
| with, and how it is used, and being transparent about such activity.
| |
| * Smart Technology Solutions and Resources
| |
| ** Sensors and IoT solutions.
| |
| ** A Software Development Kit for Smart City Solutions (CitySDK) and an Open Source project for its development.
| |
| * Interoperability
| |
| ** Standards and APIs.
| |
|
| |
| There is a complete description of CityWeb - A Smart City Information-Sharing Platform and Urban Solutions Resource on the GCTC wiki
| |
|
| |
| ==Interoperability ==
| |
|
| |
| Development and adoption of commonly-used Standards and APIs to ensure applications and services can work together to provide more powerful features
| |
| and convenience to all users. The GCTC superclusters provide a forum for public sector, private sector, academia and nonprofit organizations to work
| |
| together on this goal.
| |
|
| |
| =Autonomous Driving Systems Technology=
| |
| In the last few years, there has been a major shift in the outlook for autonomous vehicles, not just in the headlines, but with investment and a serious
| |
| development effort from almost every player in the auto and industrial technology industries. It has become clear that a significant trend has now made
| |
| its way into a full commitment from stakeholders. Predictions on the future size of the autonomous industry have ranged from the billions to the hundreds
| |
| of billions of dollars. Contributing technologies such as sensors, navigation, location services and positioning software have all matured just enough to
| |
| have autonomous vehicles reach road testing stage with success.
| |
|
| |
| Autonomous vehicles are a key component of the “transportation as a service” vision of the future. Its advantages in providing greater safety, efficiency,
| |
| cost-effectiveness and flexibility drive its development. It will be easier to provide more economically viable transportation solutions and products while
| |
| being more sensitive to environmental concerns and complying with or exceeding existing environmental laws. In addition to those factors, its potential
| |
| enabling of a large eco-system built around connected technologies to improve user experience, reduce congestion and environmental impact, build on
| |
| lucrative software, media and infotainment market spaces contribute to the perfect storm of motivating drivers behind autonomous vehicles.
| |
|
| |
| Urban areas wanting to transform into smart cities see the potential of urban speed electric transport as the energy-responsible, efficient and connected
| |
| public transport vehicle of the future.
| |
|
| |
| ==Not All Autonomous Vehicles Are Driverless==
| |
|
| |
| Although the term “Autonomous” has become synonymous with “driver-less”, it is only the last category, Level 5 Autonomous, that can do away with the driver
| |
| altogether. As defined by the SAE International standard , adopted by the USDOT, there are six levels of Automation for Driving:
| |
| <div style='text-align: center;'>Figure 2: SAE Automation Levels
| |
|
| |
| [[File:SAEAutomationLevels.png|Source: National Highway Traffic Safety Administration]]
| |
|
| |
| Source: National Highway Traffic Safety Administration</div>
| |
|
| |
| Autonomous operations are being developed for all vehicle form-factors from passenger vehicles to buses, shuttles, freight carriers, long-haul trucks,
| |
| industrial equipment and cargo movers. They include high-speed as well as urban speed vehicles.
| |
|
| |
| Most modern cars have some level of driver assistance such as sensor information, ABS brakes, collision detection, vehicle vicinity mapping, and even
| |
| collision avoidance (the vehicle automatically brakes to avoid a collision without requiring the driver). Cruise control has been available on many cars
| |
| and trucks for a long time. With a tremendous increase in the capabilities of the software stack
| |
|
| |
| present in modern cars, greater automation and sophisticated control and monitoring are becoming easier and cheaper.
| |
|
| |
| ==Fully Autonomous Capabilities - Open Road and Controlled Environments==
| |
|
| |
| Autonomous vehicles operating without a driver (Level 4 and Level 5) require at least the ability to determine the location of the vehicle, determine
| |
| and follow a route to a destination, determine immediate obstacles and potential collisions in the vicinity of the vehicle and take steps to safely move
| |
| forward or stop as needed. They also require the ability to navigate on open roads, follow routes, obey street signs and traffic signals, coexist with
| |
| other vehicles on the road, perform operations such as turns and lane changes, and comply with all traffic laws. The level of redundancy, safety,
| |
| performance and data handling required to deliver these capabilities means complex and software and advanced hardware and sensors. These technologies
| |
| are still in the early stages of development and maturity.
| |
|
| |
| When fully autonomous vehicles are operated in strictly controlled environments (Level 4) such as on special lanes and on private campuses the software
| |
| and hardware required is simpler, cheaper and easier to test and produce. Manufacturers can use simpler location technologies and do not need the
| |
| complexity and risk management of street navigation, with its high liability and complex performance requirements. Such use cases are more likely to be
| |
| deployed much earlier than with full Level 5 autonomy.
| |
|
| |
| ==Autonomous Vendors ==
| |
|
| |
| There are several categories of providers of autonomous vehicles and components. At a high-level, we observe three distinct types of vendors:
| |
|
| |
| *'''Full solution vendors:''' Vehicle + all the software and other hardware necessary (integrated solution).
| |
| *'''Autonomous software stack only:''' Vendors who provide an autonomous software stack to hardware (vehicle) manufacturers (these include closed, proprietary solution providers as well as open source solution providers).
| |
| *'''Component providers:''' Vendors who provide only autonomous components (whether software or hardware).
| |
|
| |
| A survey of the industry shows that the above are made up of:
| |
| *'''Traditional auto manufacturers:''' Almost every automaker is performing research and development into autonomous vehicles, and is converting their current offerings into autonomous-capable versions. Most expect to have an autonomous vehicle on the road by 2020-2025.
| |
| *'''Traditional Suppliers:''' Quite a few have transitioned into providing or planning to provide autonomous versions of their components. These include hardware and software, ECU suppliers, by-wire programmable units such as by-wire-brake controllers, etc.
| |
| *'''Autonomous Software Suppliers:''' Companies who provide a full autonomous software solution to deploy on any vehicle (with certain hardware requirements).
| |
| *'''Autonomous Component Suppliers:''' New companies like Mobileye who are industry leaders in deploying sensors for localization and positioning, Quanergy, a LIDAR (Laser RADAR) supplier, etc.
| |
|
| |
| Related industries and tech companies moving into the autonomous vehicle provider business: Companies such as Google, Uber, Lyft have entered the
| |
| autonomous vehicle provider market. Ride-sharing companies like Uber and Lyft need such vehicles for their future fleet. Tech companies such as Google
| |
| and Apple have entered the market because of their software skills. Google is road-testing their own autonomous vehicles while Apple has said they will
| |
| be providing a full autonomous software solution to their partner manufacturer companies.
| |
|
| |
| Two important points should be understood from this list: # 1in.2799There are many options for deploying robust commercial last mile
| |
| solutions today. These solutions can address city objectives on sustainability, safety and equity without any new innovations.
| |
| # Any legislation should recognize that these technologies exist and all efforts should be be made to deploy them rather than constructing legislation that
| |
| would delay this deployment. Now let's look at the promise of full autonomy, or National Highway Traffic Safety Administration (NHTSA) level 5 autonomy.
| |
| NHTSA considers this to be complete driver replacement in all situations including off road. Many in the general public believe this technology is just
| |
| around the corner. It is not. However, deployment in the urban environment with limited usage is possible today with legislative support.
| |
|
| |
| Currently for ride services such as Uber and Lyft approximately 80% of the operating cost is for the driver. This cost puts these services out of reach of
| |
| many low income families. For first mile last mile solution to be equitable we must reduce the cost per ride. We believe Level 4 autonomous (driverless)
| |
| operation in controlled environments will meet the needs of first mile last mile transit without the risk, time and cost required to develop level 5.
| |
|
| |
| We intend to conduct trials of these technologies to assess readiness for addressing selected sustainable, vision zero and equity goals and intends to
| |
| conduct a set of trials in districts that introduce the public to these vehicles and learn how people respond.
| |
|
| |
| =Sensor Technology=
| |
|
| |
| We define a smart city as one that has purpose (sustainability, equity, traffic safety) to its planning and measures results of its actions towards
| |
| achieving that purpose. For this reason we consider three elements fundamental to a smart city: (1) A planning process based on a deep understanding
| |
| of the needs of the community, (2) A set of metrics to measure progress, and (3) A data platform to enable data collection and measurement against
| |
| metrics. A smart city is therefore a dynamic city that makes living in a dense urban environment more civil and more rewarding. A smart city is not
| |
| only attractive to people who live there, but to people who visit and companies doing business there. As already explained, we consider a data platform
| |
| to enable data collection and measurement against planning metrics to be fundamental to a smart city. The goal is to make decisions based on data.
| |
| Such a platform would enable a real time response to demand, events and emergencies. It would allow planners to make sure the city’s budget is used
| |
| as effectively and efficiently as possible to meet the city's goals. This represents one way that cities can break down silos and use data intelligently
| |
| so that government operates as a true enterprise, rather than as a series of loosely linked departments and agencies.
| |
|
| |
| Through greater data availability citizens can be better engaged, and system managers can see further and more holistically.
| |
|
| |
| =Mobile Device and Communications Networks =
| |
|
| |
| We propose working with partners to build out the necessary communication networks and mobile device applications. We have had discussions with US
| |
| Ignite about joining their Smart Gigabit Communities (SGC) program. This program seeks to enable communities to accelerate the development and deployment
| |
| of next-generation gigabit applications and services. We have worked with FIWARE in developing the FIWARE GCTC Challenge which aims to make forward-looking
| |
| <sup>5</sup> partnerships between cities and communities in North America with organizations currently providing solutions in Europe and create Smart
| |
| City pilot trials designed to be replicable and scalable at global scale.
| |
|
| |
| Both these activities have received significant support from PSU and OHSU and we look forward to working with all these organizations to build the
| |
| necessary mobile device and communications networks.
| |
|
| |
| =Business Models =
| |
| In October of 2016, Citigroup released a report (Infrastructure: The $59 Trillion Opportunity to Kickstart Global Growth ) estimating that the global
| |
| market for infrastructure investments will reach <sup>6</sup> $59 trillion within the next fifteen years. The report observed that transportation
| |
| infrastructure would account for a large portion of this market. Cities that are able to establish themselves as viable “living laboratories” where new
| |
| infrastructure and technologies can be deployed and tested will capture a larger portion of this economic pie.
| |
|
| |
| Open architectures and interoperability among different technologies will be essential to ensuring this economic opportunity is accessible to companies
| |
| at a variety of stages and sizes. Similarly, enabling open access to certain data will enable companies to develop technology solutions that utilize and
| |
| deliver this data to constituents and other companies in engaging and innovative ways. Aside from access to a large global market and open technology
| |
| infrastructure, creating opportunities for talent development will be important to ensure economic opportunity is broadly distributed within the Portland
| |
| region. Hack Oregon is a local nonprofit that provides training opportunities for <sup>7</sup> people interested in learning how to develop software and
| |
| work with data to address civic challenges. Hack Oregon has already successfully worked with the City of Portland on open data projects and will be a key
| |
| partner in developing transportation-related data solutions while training local talent.
| |
|
| |
| The realization of the potential benefits of AVs, in terms of the impact on transportation access, equity, congestion and pollution reduction and safety
| |
| is likely to hinge directly on important public policies set or controlled by local and state governments. In particular, how vehicles are licensed and
| |
| taxed and how roads are financed will be critical. It is clear that the existing fuel tax and vehicle registration fees will not provide sufficient funding
| |
| or the correct incentives for optimal deployment of AVs.
| |
|
| |
| In addition, city parking policy can play a key role in encouraging the development and use of AV fleets. Pricing strategies for parking can encourage
| |
| households to reduce or eliminate the number of cars they own, and to rely more heavily on other modes of transportation, including transit, bikes, walking
| |
| and ride-hailed vehicles. Smart parking policies that adjust parking rates in real time can be an important complement to AVs.
| |
|
| |
| Impresa and City Observatory have extensively explored urban transportation policy and the role of <sup>8</sup> AVs. We have also written about the
| |
| economics of AVs and how public policy, especially road pricing and parking policies, is likely to influence AV adoption. Impresa regularly communicates
| |
| with colleagues at the Brookings Institution, major providers of parking and traffic data, leading ride-hailing firms, and other institutions studying AV
| |
| employment.
| |
|
| |
| City Observatory is a virtual think tank on urban policy founded with support from the John S. and James L. Knight Foundation. Impresa is an economic
| |
| consulting firm based in Portland, specializing in economic development, transportation and housing policy.
| |
|
| |
| ==Community Engagement ==
| |
|
| |
| The policy outcomes that are most important to cities as being safety, equity, climate impacts, job creation and congestion relief. Moreover, the City
| |
| has expressed that the Smart Autonomous Vehicles Initiative (SAVI) initiative must spur innovation and guide the Smart Autonomous emerging <sup>9</sup>
| |
| technology to serve community goals and, in particular to benefit low and moderate income Portlanders. This emphasis on equity and inclusion is what makes
| |
| Portland unique as a City. Toward these ends SERA/Civic Ecology Institute proposes to conduct a series of Civic Ecology <sup>10</sup> workshops in target
| |
| communities that will enable technology experts and citizens to engage in designing future smart autonomous systems that are accessible to a variety of
| |
| come levels in these target communities. These systems could include such ideas as accessible deployment technologies through training on mobile device
| |
| and communication networks, small business entrepreneurial opportunities, integration of charging stations into community fabric, integration with bicycle,
| |
| transit and other existing mobility systems and a host of other equity building ideas. These systems and relationships will then be broken down into
| |
| specific project and policy initiatives that can be undertaken in collaboration with the community, the City and technology vendors through a Civic
| |
| Public-Private partnership (CP3). The process will yield a co-created vision for deployment that is shared by the community, the City and vendors, a
| |
| statement of shared values, systems conceived to achieve the vision, specific projects and metrics by which to measure successful deployment.
| |
|
| |
| ==Urban Form ==
| |
|
| |
| As part of the above process, SERA/Civic Ecology institute will advise on the impacts of deploying this emerging technology on future urban form
| |
| in these target communities. Such questions as how do we rethink transportation corridors, intersections, vehicle pick-ups/drop-offs, the interaction
| |
| with existing and future transit stations, stops and lines, and other aspects of the public environment to ensure equitable pedestrian access and comfort?
| |
| Longer term, what might be the impact on community form if there is less of a need for parking facilities? How to redevelop surface parking lots?
| |
| How to repurpose existing structured parking in a sustainable way? Do these redevelopment opportunities offer possibilities for neighborhood densification
| |
| of housing and employment, thus reducing pressure to expand the urban growth boundary? Any of these issues are central to the mission of Prosper Portland
| |
| and its Neighborhood Prosperity Initiative suggesting that target deployment areas should coincide with these Prosper Portland neighborhoods. SERA/Civic
| |
| Ecology Institute will address these issues in the above described workshops in order to provide a coherent understanding of all of these issues which the
| |
| City has expressed are of great concern if the emerging technology is going to contribute to a prosperous, equitable City.
| |
|
| |
| ==Modeling ==
| |
|
| |
| Predictive modeling software provides the tools needed to manage the city as events unfold, from unexpected traffic jams and sudden rainstorms.
| |
| Improving parking and traffic; effectively managing energy in schools, buildings and street lights; increasing the efficiency of waste collection
| |
| and water management; as well as improving citizen services, such as information about public transit and shopping.
| |
|
| |
| <div style='text-align: center;'>[[File:modeling.png]]</div>
| |
|
| |
| Transit oriented design can help by reducing private cars as much as possible and encouraging the use of public transport and bicycles.
| |
| The platforms time horizons are limited to real-time, near-term, or long-term leaving operators and city planners blind to the consequences of their
| |
| actions at different time-scale with devastating consequences given the cost of mis-directed transportation decisions.
| |
|
| |
| =Policies and Procedures =
| |
|
| |
| ==State Level Policy ==
| |
|
| |
| Since 2012, 41 states and the District of Columbia have considered legislation relating to AVs. 21 states and the District of Columbia have passed AV
| |
| legislation. Additionally, the governors of Arizona, Massachusetts, Washington, and Wisconsin have signed executive orders relating to AVs.
| |
| While <sup>11</sup> each piece of legislation attempts to ensure public safety while encouraging innovation, they all vary in approach, creating
| |
| challenges for AV developers operating or planning to operate across state lines. This patchwork of legislation ranges from basic to robust requirements
| |
| for automated vehicles which has resulted in the AV industry advocating for federal (rather than state-by-state) regulation of autonomous vehicles to
| |
| ensure consistency and encourage innovation.
| |
|
| |
| ==Federal Role ==
| |
| In September 2017, the U.S. Department of Transportation (USDOT) released “<u>Automated Driving</u> <u>Systems 2.0: A Vision for Safety</u>”(2.0). The policy updates the<u> Federal Automated Vehicles Policy</u> <u>(FAVP) </u>released in September 2016 by the National Highway Transportation Safety Administration (NHTSA) under the Obama administration.
| |
|
| |
| The FAVP released in 2016 was the federal government’s first attempt to set up a centralized regulatory framework for AVs. The guidance is divided into four sections: Vehicle Performance Guidance for Automated Vehicles, the Model State Policy, NHTSA’s Current Regulatory Tools, and New Tools and Authorities. It established a 15-point safety assessment for manufacturers, outlined state and federal roles in regulating AVs, and explained how NHTSA would and could use existing regulatory tools to manage AV testing and deployment. NHTSA’s updated 2017 guidance eliminates three recommendations from the FAVP concerning privacy; registration and certification; and ethical considerations revising the safety assessment for manufacturers to 12 points. 2.0 generally includes less stringent regulations. It seeks to make the “regulatory processes more nimble” and remove “barriers to innovation.” One of the AV industry’s major concerns with the <sup>12</sup> FAVP had to do with the mandatory safety assessment letter (SAL) addressing each performance guideline. The 2.0 policy suggests companies submit a voluntary safety self-assessment. While the two policies take different approaches to federal regulation, they take a similar view on the delineation of federal and state regulatory responsibilities. Historically, the federal government has regulated motor vehicles and motor vehicle equipment, while states have been responsible for regulating the driver. 2.0, like the FAVP, suggests this division of regulatory responsibilities should remain.
| |
|
| |
| The 2.0 policy emphasizes DOT should maintain responsibility over the nation’s infrastructure system, interstate motor carriers, commercial vehicle drivers, and registration and insurance requirements. The policy specifies that states should “allow DOT alone to regulate the safety design and performance aspects of ADS [automated driving system] technology.”<sup>13</sup>
| |
|
| |
| Another important element of the 2.0 policy is it outlines best practices for state legislatures. These include providing a ‘technology-neutral’ environment, providing licensing and registration procedures, reporting and communications methods for public safety officials, and reviewing traffic laws and regulations that may serve as barriers to AV deployment.<sup>14</sup>
| |
|
| |
| Considering the pace of autonomous vehicle innovation, DOT anticipates that it will continue to update its regulatory guidance on an annual basis. In fact, Version 3.0 is already underway. NHTSA published a notice for public comment on “Removing Regulatory Barriers for Automated Vehicles” on January 10, 2018. In addition to its existing authority to issue federal vehicle safety standards and order recalls of defective vehicles, NHTSA has other tools it can use to address the introduction of new technologies: letters of interpretation, exemptions from current standards, and rulemakings to issue new standards or amend existing standards.
| |
|
| |
| Look for 3.0 to be released in September if historical trends hold. The previous policy guidelines were published in the same month.
| |
|
| |
| ==Congressional Action ==
| |
|
| |
| ===SELF DRIVE Act ===
| |
|
| |
| On September 6, 2017 the House of Representative passed its first piece of AV legislation, the Safely Ensuring Lives Future Deployment and Research in Vehicle Evolution (SELF DRIVE) Act, H.R.3388. The SELF DRIVE Act seeks to outline a clear federal regulatory path for developing, testing, and deploying AVs. The bill focuses on the following:
| |
|
| |
| * '''State Preemption:''' States may continue to regulate licensing, registration, liability, safety inspections and certain other aspects of vehicles and their operation. However, states would be preempted from passing laws regulating the design, construction, or performance of AVs and their component parts unless they are identical to a standard prescribed under federal law. The preemption language should begin pushing toward a regulatory regime that avoids a patchwork of differing requirements that could stifle the rollout of AVs.
| |
| * '''Safety Standards:''' Under the legislation, USDOT must issue a final rule requiring AV developers to submit certificates explaining how they are addressing safety concerns every five years. However, USDOT may not condition AV deployment based on the certificate.
| |
| * '''Safety Priority Plan:''' The bill would require USDOT to create a safety priority plan that outlines which federal safety standards need to be updated to reflect AV technology.
| |
| * '''Cybersecurity:''' The legislation requires manufacturers to develop and publicize to consumers their cybersecurity and data privacy plans.
| |
| * '''Exemption Authority:''' The bill would exempt 100,000 vehicles per manufacturer per year from current safety standards for testing purposes. Currently that number is 2,500. To qualify for an exemption, the petitioning manufacturer must demonstrate that the safety level of the system or feature at least equals the safety level of the standard for which exemption is sought or that the vehicle provides an overall safety level at least equal to the overall safety level of non exempt vehicles. Manufacturers would be required to provide information about all crashes involving exempted vehicles of which the manufacturer becomes aware. The bill would also require NHTSA to create a searchable public database of exempted vehicles.
| |
| * '''Highly Automated Vehicle Advisory Council:''' The legislation would require NHTSA to create a new advisory group made up of 30 members from business, academia, states and localities, and labor, environmental, and consumer groups.
| |
|
| |
| ===AV START Act ===
| |
|
| |
| On October 4, the Senate Commerce, Science and Transportation Committee passed<u> S. 1885</u>, the AV START Act out of committee. Despite concern from both parties, AV START passed with bipartisan support. The AV START Act is the first piece of AV legislation passed by the Senate and mirrors much of what is included in the House SELF DRIVE Act. Where the two pieces of legislation differ is on preemption of state laws, exemptions to FMVSS, and other topics that would need to be resolved in conference.
| |
|
| |
| ==Other Transport Oriented Smart City Legislation ==
| |
|
| |
| ==Grant/IOT/Smart Infrastructure Legislation ==
| |
|
| |
| Legislation to develop grant programs, promote smart technologies and systems and generally advance IOT have been introduced in the 115<sup>th</sup> Congress. The Moving FIRST Act (H.R. 3901) would require USDOT to establish the Strengthening Mobility and Revolutionizing Transportation (SMART) Challenge Grant Program to promote technological innovation in US Cities. The Smart Cities and Communities Act of 2017 (S. 1904) would promote smart technologies and systems by improving Federal Government coordination, promote quality and performance of smart city/community technologies, demonstrate value and utility through development and implementation of performance standards, provide technical assistance, aid workforce development, and expand international cooperation and trade.
| |
|
| |
| ==2018 Outlook ==
| |
| In should result in increased federal action on CAVs. Congress is likely to pass an AV bill. Informal pre-conference meetings have begun in the House and Senate to reconcile differences in the AV Start and SELF DRIVE Act which is an optimistic sign legislation could pass before the summer. This year should also see USDOT expand its role in AV development. The agencies 3.0 guidance will go beyond AV design and performance to address actual implementation of autonomous driving technologies.
| |
|
| |
|
| |
| <sup>1 </sup>"TP-500-02 - NHTSA." 19 Apr. 2006,
| |
|
| |
| [https://www.nhtsa.gov/DOT/NHTSA/Vehicle%20Safety/Test%20Procedures/Associated%20Files/TP-500-02.pd]. Accessed 12 Aug. 2017.
| |
|
| |
| <sup>2 </sup>"Technology and the Future of Cities - The White House."
| |
|
| |
| [https://www.whitehouse.gov/sites/whitehouse.gov/files/images/Blog/PCAST%20Cities%20Report%20_%20FINAL.pdf]. Accessed 16 Aug. 2017.
| |
|
| |
| <sup>4 </sup>"automated driving - SAE International." [https://www.sae.org/misc/pdfs/automated_driving.pdf]. Accessed 12 Aug. 2017.
| |
|
| |
| <sup>5 </sup>"FIWARE GCTC Challenge 2017: cross-border cooperation USA ...." 13 Jul. 2017,
| |
|
| |
| [https://www.fiware.org/2017/07/13/fiware-gctc-challenge-2017-cross-border-cooperation-usa-europe/]. Accessed 16 Aug. 2017.
| |
|
| |
| <sup>6 </sup>"New Citi Report: Infrastructure – The $59 Trillion Opportunity to ...." 20 Oct. 2016,
| |
|
| |
| [http://www.citigroup.com/citi/news/2016/161020a.htm<]. Accessed 12 Aug. 2017.
| |
|
| |
| <sup>7 </sup>
| |
|
| |
| [http://www.hackoregon.org/]. Accessed 16 Aug. 2017.
| |
|
| |
| <sup>8 </sup>"About | City Observatory." [http://cityobservatory.org/about/]. Accessed 16 Aug. 2017.
| |
|
| |
| <sup>9 </sup>"Smart Autonomous Vehicles Initiative (SAVI) | The City of Portland ...."
| |
|
| |
| [https://www.portlandoregon.gov/transportation/73493]. Accessed 16 Aug. 2017.
| |
|
| |
| <sup>10 </sup>"SERA launches the Institute for Civic Ecology - SERA ArchitectsSERA ...." 6 Jan. 2017,
| |
|
| |
| [http://seradesign.com/2017/01/sera-launches-institute-civic-ecology/]. Accessed 16 Aug. 2017.
| |
|
| |
| <sup>11 </sup>"Autonomous Vehicles | Self-Driving Vehicles Enacted Legislation."
| |
|
| |
| [http://www.ncsl.org/research/transportation/autonomous-vehicles-self-driving-vehicles-enacted-legislation.aspx]. Accessed 9 Nov. 2017.
| |
|
| |
| <sup>12 </sup>"U.S. DOT releases new Automated Driving Systems guidance | NHTSA." 12 Sep. 2017,
| |
|
| |
| [https://www.nhtsa.gov/press-releases/us-dot-releases-new-automated-driving-systems-guidance]. Accessed 9 Nov. 2017.
| |
|
| |
| <sup>13 </sup>"Federal Register :: Automated Driving Systems: Voluntary Safety Self ...." 17 Oct. 2017,
| |
|
| |
| [https://www.federalregister.gov/documents/2017/10/17/2017-22058/automated-driving-systems-voluntary-safety-self-assessments-public-workshop]. Accessed 9 Nov. 2017.
| |
|
| |
| <sup>14 </sup>"Issues in Autonomous Vehicle Deployment - Federation of American ...." 6 Sep. 2017,
| |
|
| |
| [https://fas.org/sgp/crs/misc/R44940.pdf]. Accessed 9 Nov. 2017.
| |
|
| |
| ==Questions and Answers ==
| |
| Answers to these questions are based on best current understanding. However, much is unknown and we expect answers to change as we progress towards
| |
| operational systems. We recommend the City of Portland establish an Advisory Working Group to review the Connected and Autonomous Vehicles Policy,
| |
| the current Interim Administrative Rule and be ready to guide future questions and opportunities as they arrive.
| |
|
| |
| Q: What are you proposing to test?
| |
|
| |
| A: Three key tests:
| |
| #Community engagement: SERA/Civic Ecology Institute proposes to conduct a series of Civic Ecology workshops in target communities that will enable technology experts and citizens to engage in designing future smart autonomous systems that are accessible to a variety of income levels in these target communities.
| |
| #Technology: urban.systems intends to conduct trials of connected urban speed electric vehicles and autonomous technologies to assess readiness for addressing selected sustainable, vision zero and equity goals.
| |
| #Operations: urban.systems intends to conduct pilots to introduce the public to connected urban speed electric vehicles and autonomous vehicles and learn how people respond.
| |
|
| |
| Q: Will your tests require any hardware, connectivity or other infrastructure upgrades or investment?
| |
|
| |
| A: Yes
| |
| #High Bandwidth short range and low bandwidth long range connectivity possibly 5G and LoRa respectively. We will work with organizations like US Ignite and FIWARE to ensure we are delivering well tested hardware and software infrastructure.
| |
| #High accuracy geolocation either through either:
| |
| ##Real Time Kinematic (RTK) satellite navigation: a technique used to enhance the precision of position data derived from satellite-based positioning systems such as GPS. It relies on a reference stations to provide real-time corrections, providing up to centimetre-level accuracy. Or
| |
| ##Ultra-Wideband (UWB). ultra-wideband technology is several times better than traditional positioning systems based on WiFi or GPS. Furthermore, the signals can penetrate walls and make it suitable for indoor environments or urban canyons.
| |
|
| |
| Q: In what type of terrain/environment do you hope to test ?
| |
|
| |
| A: We are interested in first mile last mile challenges, testing in urban retail, industrial and residential and in all seasons.
| |
|
| |
| Q: What streets or blocks in Portland do you propose testing?
| |
|
| |
| A: We are looking for a variety of environments that meet the city planning goals. We are particularly interested in Neighborhood Prosperity Initiative Districts like 42nd Ave, Cully Blvd Alliance, Rosewood, Division-Midway Alliance, Jade District, Historic Parkrose and Main Street Districts like St. John’s Center for Opportunity, Alberta Main Street. While we intend to step
| |
| through Tests (1), (2), (3) in that order we believe the Neighborhood Prosperity Initiative Districts will be particularly valuable in understanding ways to address equity and prosperity with Community engagement while the main street districts will be ideal Technology testbeds.
| |
|
| |
| Q: If you plan to use AVs, how many will be in use for your pilot? What is the maximum number of AVs that would be operating in the pilot program simultaneously?
| |
|
| |
| A: Mobility Cubed is capable of deploying 1-2 vehicles now for tests and has developed an alliance with Gunderson LLC to build the assembly line. With this assembly line the supply of AVs is essentially unlimited. Gunderson is member of the Greenbrier Companies headquartered in Lake Oswego, Oregon and is a leading international supplier of equipment and services to the freight rail transportation markets. They are currently providing space and purchasing power, giving Mobility Cubed the ability to scale very rapidly as orders grow. urban.systems works closely with a number of electric vehicle companies including Easy Mile, Navya, Local Motors, Innova, and others
| |
|
| |
| Q: How is success measured for your pilot program?
| |
|
| |
| A: As we explore community needs with civic engagement we will develop a plan for data collection and use this data to measure progress against the City’s Comprehensive Plan, Vision Zero Action Plan, and Climate Action Plan
| |
|
| |
| Q: What data will be produced by the test(s)? Could such data be collected and shared on the following outputs during the program and at full deployment origin, destination, route, and VMT; speeds; emissions, etc.? If not, why?
| |
|
| |
| A: In line with the PCAST report we recommend the concept of a comprehensive information infrastructure for Portland. This "City Web", would provide an information-sharing platform between many cities. We would use our strong relationship with NIST and the Global City Teams Challenge to engage other cities in this data sharing information on solutions, best practices and experience. Although there may be exceptions for reasons of security or privacy, the default position is that transportation data should be open to encourage the widest possible range of potential innovation.
| |
|
| |
| Q: How would your service(s)/product(s) address Portland’s goals, which are outlined in Chapter 9 of the City’s Comprehensive Plan?
| |
|
| |
| A: Safety and specifically Vision Zero : AV ready urban speed electric vehicles will have advanced crash avoidance technologies, this combined with the urban appropriate seed would play a significant role in achieving the Vision Zero goals. Note that a 12 mph vehicle can be brought to a full stop in 6 feet. Ensuring equity : Addressing the last mile will go a long way to eliminating transportation deserts. Further removing cars and freeing up parking space will open streets to people and l spaces. Civic Engagement workshops will ensure community participation addressing concerns for equitable access and benefit.
| |
| Congestion reduction : Shared vehicles will remove parked cars from streets and eliminate the need for cars to spend time looking for parking. Increased use of transit will take many cars of the road. Making streets safer for walking will mean more trips are taken by foot and bike.
| |
| Reducing climate pollution : This will be potentially eliminating thousands of gasoline burning vehicles from Portland streets. Creating great places : Freeing up parking spaces and making streets safer for walking will greatly increase public space for community building. Generating economic prosperity : By leading this new era of urban transportation the City of Portland will bring an enlarged share of a $59 trillion over the next fifteen years transportation infrastructure business to the region.
| |
|
| |
| Q: What do you need for the pilot program to be successful? Specifically, what do you need from the City of Portland?
| |
|
| |
| A: We will need coordination and cooperation among City of Portland, TriMet and pilot site owners.
| |
|
| |
| Q: Is a partnership with the City of Portland contemplated for your pilot program?
| |
|
| |
| A: Yes we believe the City of Portland should establish an Advisory Working Group to ensure support from the city for projects that use city infrastructure whenever possible and that reviews Connected and Autonomous Vehicles Policy prior to their being adopted to weigh factors that impact sustainability, equity, safety, prosperity, and innovation.
| |
|
| |
| Q: If so, would such a partnership require a financial investment by the City?
| |
|
| |
| A: We expect providing the above level of partnership on pilot programs, but we do not anticipate any major city funding.
| |
|
| |
| Q: Has the technology been previously tested? If so, when and where did those test take place?
| |
|
| |
| A: The driver versions of the Mobility Cubed vehicles have been in operation for three years with several hundred thousand hours of operation. Drive-by-wire operation of the bus has been tested at the Gunderson facility on 4350 NW Front Ave since July 2017 and a preliminary demonstration has been shown to Portland’s TriMet and Columbus OH US DOT winning team.
| |
|
| |
| Q: What were the results of these tests?
| |
|
| |
| A: There were three results
| |
| #The transportation priorities of key neighborhoods around Portland.
| |
| #The readiness of key technologies to improving safety, etc.
| |
| #The social acceptance of these technologies in key neighborhoods around Portland.
| |
|
| |
| =Contributors=
| |
| {|
| |
| |-
| |
| |style="width:30%; text-align:left;"|
| |
| :Wilfred Pinfold, urban.systems Inc.
| |
| :2004 NW Irving St. Unit 3
| |
| :Portland, OR 7209
| |
| :(503)709-2975
| |
| :wilfred.pinfold@urban.systems
| |
| |
| |
| urban.systems builds vibrant smart communities using technology to facilitate civic engagement, deliver services and share resources.
| |
|
| |
| urban.systems considers three elements fundamental to a smart community:
| |
| # A planning process based on a deep understanding of the needs of the community,
| |
| # A set of metrics against which to measure progress, and
| |
| # A data platform to enable data collection and measurement against metrics.
| |
| |-
| |
| |
| |
| :Skip Newberry, Technology Association of Oregon
| |
| :NE 3rd Ave #210
| |
| :Portland, OR 97232
| |
| :(503) 228-5416
| |
| :skip.newberry@techoregon.org
| |
| |
| |
| Technology Association of Oregon is a local nonprofit working to build opportunities, better our economy and unify a voice for innovation in Oregon and
| |
| beyond. A recognized leader in shaping and growing technology and business communities, TAO empowers businesses and entrepreneurs through networks,
| |
| events, advocacy, resources and more. With over 400 member-companies, TAO’s network brings together some of the largest companies in the world, small
| |
| startups, and tech-enabled companies that are using technology to drive growth and innovation.
| |
| |-
| |
| |
| |
| :Jeff Allen, Forth
| |
| :SW 4th Ave, Suite 620
| |
| :Portland, OR 97201
| |
| :(503)724-8670
| |
| :jeffa@forthmobility.org
| |
| |
| |
| Forth’s mission is to advance electric, smart and shared transportation and eventually autonomous mobility solutions in the Pacific Northwest and
| |
| beyond through innovation, demonstration projects, advocacy, and engagement. Forth has over 120 members representing automakers, EVSE suppliers,
| |
| dustry partners, utilities, local governments, and nonprofits and many other stakeholders within the transportation “ecosystem”.
| |
| |-
| |
| |
| |
| :Ken Montler, Mobility Cubed Inc.
| |
| :The "Q" Hut Gunderson, LLC
| |
| :NW Front Ave,
| |
| :Portland, OR 97210
| |
| :(971) 404 -5308
| |
| :ken.montler@mobilitycubed.com
| |
| |
| |
| Mobility Cubed builds electric vehicles relying on a common set of chassis frame and subcomponent parts. From these common parts, we build a range of
| |
| vehicles from a sixteen seat bus to a two person car. Vehicle types include light delivery vehicles and industrial specialty vehicles. The Mobility
| |
| Cubed buses have been in operation in the Philippines with an estimated 200,000 hrs. of operation.
| |
| |-
| |
| |
| |
| :Tim Smith, Civic Ecology Institute Sera Architects
| |
| :NW 5th Ave
| |
| :Portland, OR 97209
| |
| :tims@serapdx.com
| |
| |
| |
| SERA is a 100% employee-owned Architecture, Interior Design and Urban Design & Planning firm specializing in sustainable placemaking at all scales.
| |
| Founded in 1968, SERA holds a key role in the development of the city’s national reputation for livability. Tim and SERA founded the Civic Ecology Institute to address community resilience by empowering citizens to create strongly democratic and systemic solutions to neighborhood, city and regional resource allocation issues.
| |
| |-
| |
| |
| |
| :Joe Cortright, Impresa
| |
| :NE Knott St,
| |
| :Portland, OR 97212
| |
| :(503) 213-4443
| |
| :jcortright@impresaconsulting.com
| |
| |
| |
| Impresa is a Portland based consulting firm specializing in metropolitan economies and knowledge-based industries, and education policy. Founded in 1995, Impresa has a two-decade track record of providing solid analysis and policy advice that addresses the key challenges confronting communities around the nation.
| |
| |-
| |
| |
| |
| :Greta Knappenberger, iSoftStone North America
| |
| :Lake Washington Blvd. #400 Kirkland, WA 98033
| |
| :(425) 216-6300
| |
| :gretak@isoftstone.com
| |
| |
| |
| iSoftStone North America is a technology consulting firm partnering with our clients to bring best in class digital transformation services and create innovative solutions that improve business process and performance
| |
| |-
| |
| |
| |
| :Jill Sorensen, Baltimore Electric Vehicle Initiative
| |
| :S. Calvert Street
| |
| :Suite 2310
| |
| :Baltimore, Maryland 21202 (443)514-7122
| |
| :jats@bilyan.com
| |
| |
| |
| Baltimore-Washington Electric Vehicle Initiative, is a non-profit focused on electric vehicle education and outreach.
| |
| |-
| |
| |
| |
| :John Feo, Pacific Northwest National Laboratory
| |
| :Battelle Blvd.
| |
| :Richland, WA 99354
| |
| :(509) 375-3768
| |
| :john.feo@pnnl.gov
| |
| |
| |
| Pacific Northwest National Laboratory is one of the United States Department of Energy national laboratories, managed by the Department of Energy's Office of Science.
| |
| |-
| |
| |
| |
| :Cory Marshall, Splunk
| |
| :Brannan St,
| |
| :San Francisco, CA 94107
| |
| :(415) 968-9005
| |
| :cmarshall@splunk.com
| |
| |
| |
| Splunk takes your machine data and make sense of it. IT sense. Security sense. Business sense. Common sense. Splunk products deliver visibility and insights for IT and the business. Splunk was founded to pursue a disruptive new vision: make machine data accessible, usable and valuable to everyone
| |
| |-
| |
| |
| |
| :Jose Gonzalez, FIWARE
| |
| :rue Paul Bourget
| |
| :Antony - France
| |
| :+34 644 297 507
| |
| :jgonzalez@interinnov.eu
| |
| |
| |
| The FIWARE Community is an independent open community whose members are committed to materialise the FIWARE mission, that is: “to build an open sustainable ecosystem around public, royalty-free and implementation-driven software platform standards that will ease the development of new Smart Applications in multiple sectors”.
| |
| |-
| |
| |
| |
| :Geoffrey Urbach, Summit Strategies
| |
| :1st St., N.W. Suite 440 Washington, DC 20001
| |
| :(202)638 3307
| |
| :geoffreyu@summitstrategies.us
| |
| |
| |
| Summit Strategies is a national strategic government affairs consulting firm working with government and federal agency leaders to serve clients across a wide range of industries and political interests.
| |
| |}
| |
|
| |
| =Attachment A: EV-Ready Transit Hubs White Paper=
| |
| <div style="text-align:center;">'''11 August 2017'''</div>
| |
|
| |
| <div style="text-align:center;">Baltimore-Washington Electric Vehicle Initiative (BEVI) 111 S. </div>
| |
|
| |
| <div style="text-align:center;">Calvert Street </div>
| |
|
| |
| <div style="text-align:center;">Suite 2310 </div>
| |
|
| |
| <div style="text-align:center;">Baltimore, Maryland 21202 </div>
| |
|
| |
| <div style="text-align:center;"><u>www.marylandEV.org</u></div>
| |
|
| |
| <div style="text-align:center;">(cover Hub-to-Hub artwork by 2015 summer EV intern and MICA art student, Sara Klementovic) </div>
| |
|
| |
|
| |
| ==INTRODUCTION – Mobility Hubs in Baltimore ==
| |
|
| |
| In 2015, BEVI published a Whitepaper advocating for the siting of EV-ready transit hubs throughout Maryland, starting in Baltimore City.
| |
| We worked with key stakeholders to study, socialize and implement this concept, combining it with smart city initiatives and infrastructure
| |
| development. The work became known as the Baltimore Smart City initiative or “B’Smart” Project, a smart city planning construct that addresses
| |
| the interdisciplinary nature of this infrastructure development work, crossing clean energy, clean transportation and Internet of Things applications.
| |
| Community safety, public WiFi, health, wellness and economic opportunity are included in the smart city planning mix.
| |
|
| |
| <div style='text-align: center;'>[[File:ProposedMarylandTransitHubs.png]]</div>
| |
|
| |
| B’Smart stakeholders include City and State units of government, our local utility, area nonprofits, university researchers and smart city industry
| |
| partners. The B’Smart consensus is to focus our efforts on low-income communities in the City hardest hit with transportation access challenges,
| |
| such as West Baltimore. This meant we needed the input and cooperation of the community.
| |
|
| |
| B’Smart has become a call to action for mobility. Our Maryland Transit Administration (MTA) has been leading the charge with its <u>BaltimoreLink</u> plan. First announced in October of 2015,
| |
| the BaltimoreLink plan embraces the concept of transit hubs. Actually creating the hubs in a way that embraces clean energy and smart city planning
| |
| challenges boundaries of agency jurisdiction, policy, politics, practice. Still, MTA and the Baltimore City Department of Transportation are making progress. Under the leadership of Mayor Catherine Pugh, and in close cooperation with State Governor Larry Hogan and his administration, the first of the new transit hubs is emerging as the <span style="color:#0000ff;"><u>new West Baltimore MARC Station</u></span>. A new Smart City Counsel for Baltimore City has been announced, and will continue to advance the multi-modal transportation options such as bike-sharing, car sharing and electric vehicle charging to be available at each one of these locations to support commuters. Favoring zero emission vehicles will help reduce pollution from the transportation sector, improve City health, wellness and mobility.
| |
|
| |
| ==TRANSIT HUB PRINCIPLE ==
| |
|
| |
| A Transit Hub is a location that coordinates existing public transportation options like bus or rail with multi-modal transportation resources like pedestrian, cycling, bike-share and car-share. More than just a rail station or a bus stop, a Transit Hub enables someone to get to and from public transportation using a connecting bus, shuttle, bike or car-share service, thus eliminating the need to own a car in order to get to and from work or around town. Transit facilities and services are an essential element of the social, economic, and cultural fabric of every city and region in Maryland. Presently, Maryland’s transit resources are distributed, overlapping, and inefficient. Greater coordination would save operating and capital expenses, reduce energy consumption, pollution and traffic congestion. Too many citizens continue to drive. We need to improve our transit culture and transit options as a compelling complement and preferred option to cars, especially for urban transportation. A high quality transit system will bring communities together, enhance public safety, provide local business opportunities and improve quality of life. A Maryland Transit Hub system would achieve the following objectives: * 1.5in.6409Streamline transit planning, land use patterns and infrastructure by defining strategic Transit Hub locations across the State
| |
| * Facilitate the development of Greenway routes between Transit Hubs for faster, safer and more efficiently transportation, especially from Hub to Hub
| |
| * Reduce traffic congestion management
| |
| * Improve air quality by promoting electric vehicles (zero emission) and active transportation (cycling and walking) to Hubs
| |
| * Reduce energy consumption and, therefore, produce transportation-related energy savings
| |
| * Form the backbone for managing travel demand
| |
| * Provide essential mobility for those who do not operate a private vehicle
| |
| * Build community space
| |
| * Design and operate each Hub as a microgrid capable of operating in power outages, fortifying the grid with back-up power
| |
| * Promote Smart City design by incorporating broadband conduit and free wireless internet access as part of each Transit Hub and Greenway.
| |
|
| |
|
| |
|
| |
| ==THE NEW TRANSIT VISION FOR MARYLAND, starting with BaltimoreLink ==
| |
|
| |
| The new transit vision for Maryland creates a more user friendly, attractive, efficient and reliable transit system for the State.
| |
| The keys to this new transit vision are these: * 1.5in;margin-right:1.0929Site design and active transportation improvements,
| |
| pedestrian and cycling in particular, are critical to supporting transit use
| |
| * Enhancing existing services can offer large benefits, particularly smart phone and related digital support
| |
| * Defining EV-ready Transit Hubs as strategic transit assets across the State, connected by express routes for electric buses, cycling and walking to promote active, clean transportation from Hub to Hub
| |
| * Connecting Transit Hubs by express electric buses and promoting cycling and walking
| |
| * Broad regional support
| |
| * Increasing transit ridership and revenue by improving the quality of all transit services
| |
| * Aligning transit services with demand
| |
| * Improving existing and develop new partnerships with public and private stakeholders
| |
| * Re-emphasizing the need for transit supportive built environments (TOD – transit-oriented development) which can be achieved through design guideline development
| |
| * Continued performance monitoring to guide service development This new transit vision for Maryland has two primary components:
| |
|
| |
|
| |
|
| |
| <u>'''Bus Rapid Transit (BRT) service designed around current critical transit connection sites to be re-defined as Transit Hubs</u>'''
| |
|
| |
| This component emphasizes the use of transit as a key transportation mode complemented by transit oriented development. Bus Rapid Transit (BRT), preferably electric, is a high performance transit service that functions more like light rail than a local bus. In the preferred Transit Hub matrix for Maryland, Hub to Hub BRTs run express on dedicated “greenway” routes from Hub to Hub, incorporating elements such as priority treatment at traffic signals, reduced, restricted or eliminated car access, station amenities such as real time arrival/departure information, attractive shelters, free wifi, park-and-ride lots, benches and in some cases restrooms and other services. BRT systems are complemented by local buses, sometimes referred to as feeders, to bring passengers to the high performance BRT routes.
| |
|
| |
| To further encourage transit use, Transit Oriented Development (TOD) is encouraged at BRT or other transit service stations. Transit Oriented Development is generally defined as mixed-use development (development that mixes residential, retail, office, open space, and public uses) within walking distance of a transit stop that encourages travel on foot or by public transportation instead of by car.
| |
|
| |
| <u>'''Greenways Corridors to allow express, active transportation from Transit Hub to Transit Hub</u>'''
| |
| Greenways would be dedicated routes from Hub to Hub that provide for express buses, preferably electric, cycling and pedestrian movement. Greenways, combination with Transit Oriented Development (TOD), will create communities that on a regional scale preserve open space and reduce the need for travel by car, thus reducing congestion and vehicle emissions. Transit Oriented Development is generally defined as mixed-use development (mixing residential, retail,office, open space, and public uses) within walking distance of a transit stop that encourages travel on foot or by public
| |
| transportation instead of by car. The “permanent” nature of Greenways contributes to greater development along a corridor than that stimulated by
| |
| local bus service in mixed traffic.
| |
|
| |
|
| |
| MARYLAND NEW TRANSIT VISION COMPONENTS
| |
| * <u>Bus-only travel lane</u>
| |
| * Greenways, including pedestrian and bike paths
| |
| * Bike-share and Car-share at every Transit Hub location
| |
| * Greenway transit signal priority, energy saving LED streetlights and accompanying digital signage
| |
| * ADA compliant Transit Hub shelters,
| |
| * EV-ready Park and Ride lots with Level 1 and Level 2 charging
| |
| * Smart Card and mobile application transportation mode interoperability
| |
| * Free wifi at all Transit Hubs
| |
| * Transit Hubs as microgrids
| |
|
| |
|
| |
|
| |
| RECOMMENDATIONS (next 5 years)
| |
|
| |
| # Continue to support MTA in implementing its 2015 Transit Development Plan and BaltimoreLink a. Expand BRT around a Transit Hub Master Plan
| |
| ## Strengthen the system beginning with express routes from Hub to Hub, preferably on defined Greenway Corridors, and local routes.
| |
| ## Improve the fleet by reintroducing electric buses on BRT routes, providing commuter coaches on all express routes, and installed Intelligent Transportation System components on all vehicles.
| |
| ## Plan for and begin to construct Transit Hubs starting with key strategic locations .
| |
| ## Improve transit infrastructure by implementing BRT infrastructure throughout the MTA system, bus only lanes, pedestrian access, more shelters, universal Smart Card and Smart Phone access, a new Computer Aided Dispatch and Automatic Vehicle Location systems, and a new fare collection system.
| |
| ## Better integrate pedestrian, transit, and bicycle infrastructure using Greenways.
| |
| # Investigate new funding mechanisms to support MTA, Baltimore and regional transit operations
| |
| ## Energy and monetary savings by converting to electric buses and LED street lights.
| |
| ## Appropriate level of fare increase for base fare on fixed route services to increase the share of revenue provided by transit customers.
| |
| ## New and expanded transit access agreements for Smart Card or device users, service personnel (military, police, firemen, educators and students, non- profit sectors).
| |
| # Revise the Transportation Improvement Program project evaluation process to ensure that transit is being considered in the benefit/cost ratio developed for all projects. Support the State’s goals to reduce greenhouse gas emission impacts during project selection and development.
| |
| # Explore the potential for bus/transit only travel lanes, beyond those planned for the BRT routes, in various locations throughout the region.
| |
| # Use established national criteria to identify transit corridors that may have the potential to support streetcar or light rail transit.
| |
| # Coordinate with municipalities, the counties and the state in the development of Complete Street design guidelines, standards and/or ordinances that incorporate the needs of the regional transit system (including articulated buses). Encourage inclusion of transit access for pedestrians in state and municipal ADA conformance plans (universal design elements such as sidewalks in good condition, curb ramps, etc.).
| |
| # Ensure that ADA (Americans with Disabilities Act) requirements are being met adjacent to all transit routes, on regular route vehicles and on paratransit vehicles through the implementation of universal design techniques (those that accommodate the widest range of users). Explore further use of audio and video based technologies on buses.
| |
| # Continue to work with and promote integrated land use and transportation planning that supports transit oriented development and land use projects that encourage transit use (especially forseniors and lower income housing). Improve local understanding of development finance in real estate markets for transit oriented development.
| |
| # Encourage improved intermodal connections among transit providers including Amtrak, intercity, county, university and independent bus carriers, and the Baltimore-Washington International Airport as well as walking, bicycling, and driving. Work with MTA and regional transit carriers, including Amtrak, on the development of shared intermodal stations.
| |
| # Continue to engage major public and private stakeholders in transportation demand management initiatives and monitor significant new development in order to structure future transit service, transit access agreements (employer/institution financial partnerships with MTA), and opportunities to influence development in transit supportive ways.
| |
| # Develop marketing or education materials targeted to elected officials, developers, financers, etc. about the benefits of transit and the cost to provide transit service.
| |
| # Continue to encourage open communication between State agencies and non-State transit providers.
| |
|
| |
| <div style='text-align: center;'>[[File:Phase II Transit Hub Dev.png]]
| |
|
| |
| '''Phase II Transit Hub Dev'''
| |
|
| |
| [[File:Phase III Transit Hub Dev.png]]
| |
|
| |
| '''Phase III Transit Hub Dev'''
| |
|
| |
| [[File:TransformingExistingTransitHubs.png]]</div>
| |
|
| |
| =Attachment B: Recommendations for the Development & Implementation of Distributed Sensor Networks=
| |
| <div style='text-align: center;'>Recommendations for the DEVELOPMENT & IMPLEMENTATION of Distributed Sensor Networks
| |
|
| |
| LEADS:
| |
|
| |
| """Christine Kendrick, PhD''', Air Quality Lead/Smart Cities Coordinator,
| |
|
| |
| ''City of Portland Bureau of Planning and Sustainability ''
| |
|
| |
| '''Andrew Rodgers''', Research and Applications Development,
| |
|
| |
| ''The Enterprise Center ''
| |
|
| |
| CONTRIBUTORS:
| |
|
| |
| '''Khalid Elgazzar, PhD''', Assistant Professor,
| |
|
| |
| ''School of Computing and Informatics, University of Louisiana at Lafayette ''
| |
|
| |
| '''Brian Miles, PhD''', Senior Consultant U.S. Federal Market, ''CGI''
| |
|
| |
| '''Recommendations for the Development and Implementation of Distributed Sensor Networks'''</div>
| |
|
| |
| '''ABSTRACT'''
| |
|
| |
| In nearly every modern civic infrastructure initiative, there are compelling reasons to leverage data and analytics to deliver the most value and impact to citizens. However, few resources are available that help communities understand the critical nature of the underlying sensors and infrastructure that support these applications, especially in a cross-sector, vendor agnostic way. This document strives to provide a robust orientation for those tasked with assessing, planning or deploying these advanced sensor networks. This document is not a prescriptive, step-by-step guide to a successful deployment, as the topical scope is far too large, and community and project variability far too broad to provide a monolithic solution. Instead, we seek to challenge the reader to discover the critical aspects of their project through coordinated effort with the appropriate stakeholders, and with full appreciation for the cultural, technical and resource constraints of their community.
| |
|
| |
| We’ve divided our blueprint into 12 key project stages, ranging from problem identification to hardware end of life. These project stages were identified through two facilitated workshops in Washington DC and Portland, OR as part of the National Institute of Standards and Technology (NIST) Global Cities Team Challenge (GCTC) Transportation SuperCluster. Sensors, as discussed here, could represent a variety of specific applications such as devices for traffic counts, pedestrian activity, light metering, noise, air quality, water quality, climate-related measurements, etc.
| |
|
| |
| For each project stage, key considerations are discussed and summarized. These considerations include lessons learned from other projects and questions
| |
| to ask yourself when designing or planning a project to address common issues and major challenges. Communities may find themselves well beyond stage
| |
| one, or even that certain stages are not appropriate for their specific scope and context, and we hope that each stage offers helpful insight regardless
| |
| of your starting point.
| |
|
| |
| A recurring theme you will find is the absolute dependency on good communication with stakeholders, and a realistic view of the limitations in expertise
| |
| and resources within that group that you should seek to augment for maximum efficacy. As the available technologies and community needs evolve, we hope
| |
| that keeping this theme in mind while addressing the various considerations identified here will help support successful planning and implementation of sensor networks.
| |
|
| |
| =Introduction =
| |
|
| |
| creasing accessibility to sensors, computer processing units, and remote communication technologies has led to a large growth in the availability of sensor devices that can be deployed to create sensor networks across a variety of landscapes. These technologies combined into networks is also commonly referred to as the Internet of Things (IoT). Many communities are interested in exploring how these technologies and increased availability of data can be used to meet the needs for data-driven decisions, expansion of citizen science and civic technology communities and to spur economic opportunities.
| |
|
| |
| Pilot deployments funded by combinations of grants and/or partnerships with private sector companies currently dominate the state of implementation for community based sensor network projects. This blueprint document is aimed at pulling together lessons learned, best management practices, and research questions revealed based on existing pilot projects for sensor network development and implementation. This blueprint can be used to help inform current and ongoing projects, provide
| |
|
| |
| material for the planning of an upcoming project, or in the preparation of writing project grant proposals or other funding requests. As discussed in this document, sensors could represent a variety of specific applications such as devices for traffic counts, pedestrian activity, light metering, noise, air quality, water quality, climate-related measurements, etc.
| |
|
| |
| This blueprint is authored by a working group of individuals with experience in academic research, public sector roles, and the private sector. The author working group was formed through engagement in the National Institute of Standards and Technology (NIST) Global Cities Team Challenge (GCTC) Smart Cities program. Through two facilitated GCTC workshops, we have identified 12 project stages for developing and implementing a sensor network project. In the subsequent sections, these project stages will be discussed along with the key considerations/questions that need to be addressed for each. We hope this blueprint is one of many collections of best practices for sensor networks as the number of deployments increase and the available technologies and community needs evolve.
| |
|
| |
| = Project Stages =
| |
|
| |
| == Overview ==
| |
|
| |
| A blueprint for sensor network development was the topic of two facilitated workshops through the GCTC program and as a subsection of the Transportation SuperCluster. These workshops combined people with experience and stakes in research, private, and public roles. The first workshop occurred in Washington DC in October 2016 and the second in Portland, OR in February 2017. A basic outline was developed and a list of the critical project stages was identified. These sensor blueprint discussions did occur under the umbrella of the Transportation Supercluster because many (but not all) sensor pilots are occurring with deployments in the public right of way. However, we kept the project stages and key considerations broad so that these best practices and questions can be applied to sensors with uses cases and deployments outside of the transportation environment. The workshop consensus found the following twelve project stages to be common and critical when developing and implementing a sensor network:
| |
|
| |
| # THE PROBLEM | Use Case identification: Determine the root of the issue your city/community is facing and if sensors are the best method to solve the issue
| |
| # THE SOLUTION | Identify the right sensor package with specifications that meet your needs based on the use cases identified.
| |
| # THE SENSOR IMPLEMENTATION STAGES:
| |
| ## Privacy issues
| |
| ## Community engagement plan
| |
| ## Local procurement processes
| |
| ## Installation considerations
| |
| ## Data communication and management plan
| |
| ## Data standards
| |
| ## Data integration
| |
| ## Data validation
| |
| ## Funding (public/private/integration with other technology & systems)
| |
| ## Sensor end of life considerations (technology transitions & advancements)
| |
|
| |
| Metrics and evaluating project performance are important elements across all the project stages so these will be discussed throughout rather
| |
| than fall under its own section. The stages identified under (C) Implementation are not in a linear order. Some of these project stages may
| |
| occur in parallel or occur in a completely different order than the list above. Any best practices identified that do require a specific order
| |
| of project stages or recommendations to make implementation smoother will be noted in the following sections. For each project stage, key
| |
| considerations are discussed and summarized. These considerations include lessons learned from other projects and questions to ask yourself when
| |
| designing or planning a project to address common issues and major challenges.
| |
|
| |
| == Problem Identification ==
| |
|
| |
| To set a sensor network project on the path towards the most useful outcomes, it is recommended to begin by spending some time determining the root of the issue(s) your city/community is facing. The next step would be brainstorming and discussing how and if sensors are the best method to solve this issue. Use case identification before searching for sensors may allow you to find the most applicable technology and avoid the pathway of technology for technology’s sake.
| |
|
| |
| However, the authors also acknowledge that there are benefits to communities to create technology testbeds such as creating new economic drivers and the need for exploration to find the best technology for your community’s needs before committing to products and providers. Additionally, sensor workshop participants have pointed out that a common path to getting a sensor deployment project off the ground is through a product life cycle replacement or packaged as part of a larger infrastructure project. In these cases, there may not be a lot of discussion, community engagement, and investigation of use cases before deciding on a sensor installation. When sensors are an incorporated piece of a larger product replacement or infrastructure project, a city/community should still rely on existing community plans and needs assessments to help make decisions. Such plans typically have incorporated a rigorous evaluation and community engagement process to create community vision, goals and objectives.
| |
|
| |
| A hybrid model of deployment can be one option to help facilitate a technology pilot while also making sure the project is focused on meeting public needs and expanding a community’s access to technology. If a sensor device comes with five different features but only three of these align with existing city needs/goals, the community can leverage this with the provider. A community can emphasize there is only an existing need for three of the features, or we already have a system in place for one of the features and then a new agreement could be made on contracts to pilot the other two features to further understand needs and use cases.
| |
|
| |
| When evaluating use cases, problem identification and how sensor systems fit in, people familiar with the problems and subject matter need to be involved.
| |
| Sensor technology providers do not necessarily have knowledge in the field they are now offering measurement devices in. Those with subject matter expertise
| |
| will not necessarily have knowledge in communication protocols and/or city policy of how to deploy and set up maintenance contracts. Use case identification
| |
| and assessing the potential of sensor networks to provide data and information for those use cases will take a creative, interdisciplinary team with a
| |
| range of expertise. This is not an easy step to get everyone in the same room but could be key to avoid deploying a system that does not provide the
| |
| needed data for the problem you are trying to solve.
| |
|
| |
| The initiation of a sensor network project may begin in several different ways; through an interest in sensors and trying new technologies, packaged as part of an infrastructure or product replacement project, a grant award, or a public-private partnership to help fund. No matter how a sensor network project discussion begins, use case evaluation involving a multi-faceted team with subject matter experts relative to your community problem and needed measurements is key.
| |
|
| |
| === Summary of Key Considerations ===
| |
|
| |
| # What public need are you serving or what specific problem are you trying to solve?
| |
| # What existing data sources could be leveraged to address the issue?
| |
| # What gaps in existing visibility for the problem exist?
| |
| # Who are the stakeholders that are currently addressing this issue? Do they see the value in additional data?
| |
| ## How can you create a multi-disciplinary team to help with use case development and evaluate how sensors can achieve solutions for the issue and data needs identified?
| |
| #Do you have the political capital or buy in from the stakeholders to ensure the data you collect is used to address the issue?
| |
| # What policies are in place within the city that may hamper the effectiveness of your deployment? Will the deployment be worthwhile without addressing those policies? G. Identify methods, resources, and stakeholders for data analysis ahead of time to ensure the data collected can address the issue.
| |
|
| |
| == Sensor Selection ==
| |
|
| |
| Within the same measurement application, sensor packages can have huge cost differentials. Some sensors are $10, some $2500 and some can even be called
| |
| lower-cost at a price tag of $10,000. There are a range of reasons for such cost differentials; sensor quality and limits of detection, communication
| |
| platforms, computer processing units, sensor packaging and enclosures, and/or research and development for the device.
| |
|
| |
| A multi-disciplinary team with subject matter experts of your measurement application will again be key to understand these cost differences and select
| |
| the sensor package that works best for your use case and project budget. To evaluate the range of selections out there, you will need to develop sensor
| |
| selection criteria that is based on your project needs and use cases. If you only need a coarse measurement value, then you may be able to choose a sensor
| |
| with less sensitive limits of detection and that could mean a lower price. If you do not need real-time data for your project and can have the data sent
| |
| to you once a week or even monthly, then you can choose different communication platforms and may need a larger data logging capacity.
| |
|
| |
| Thinking about future data needs for a project can also be helpful in selecting a sensor package. The ability to upgrade or add additional measurement
| |
| capabilities later could help increase support for the project and potentially save money further down the road.
| |
|
| |
| === Summary of Key Considerations ===
| |
|
| |
| # Use a multi-disciplinary team with subject matter experts of the measurement application to design sensor selection criteria based on your project/use case needs.
| |
| # What sensor data would be actionable for your issue, and also more broadly applicable for other city needs?
| |
| # What subset or superset of the data needed does each package address?
| |
| # Can you identify other stakeholders that may be willing to support the deployment if you include a key metric for them in your package?
| |
| # What economic development outcomes can be realized with the availability of this new data, and how does each sensor package or platform support that outcome?
| |
|
| |
| ===Case Study- City of Portland Air Quality Sensor Device Pilot ===
| |
|
| |
| The City of Portland was awarded a NIST Replicable Smart Cities Technologies cooperative grant in August 2016 for a project called A Framework for Low-Cost Urban Air Quality Measurements. The project’s objectives were to improve understanding about the types of use cases possible with low-cost air quality sensors through a three-phase deployment involving lab testing, field comparisons at the state Department of Environmental Quality station and field comparisons at the roadside at signalized intersections.
| |
|
| |
| In order to select which sensor(s) to purchase for this project’s deployments, the team put together a list of questions and specifications that could be used to review the growing list of low-cost air quality sensor devices that were available at the start of the project period. Table 1 lists some examples of the criteria developed and used to select the final sensors for the project.
| |
|
| |
| ==Table 1 ==
| |
| <div style='text-align: center;'>Sensor Selection Criteria Examples from City of Portland’s Air Quality Sensor Pilot
| |
|
| |
|
| |
| {| style="border-spacing:0;width:6.4993in;"
| |
| |- style="border:1pt solid #000000;padding:0.0694in;"
| |
| | align=center style="color:#000000;" | Device Requirements
| |
| | align=center style="color:#000000;" | Background Information for Criteria
| |
| |- style="border:1pt solid #000000;padding:0.0694in;"
| |
| || Device should be able to measure at least 3 of the following pollutants: CO, NO, NO<sub>2</sub>, CO<sub>2</sub>, O<sub>3</sub>, PM2.5
| |
| ||
| |
| * Study objectives focused on transportation-related pollutants
| |
| * Transportation emissions are a mix of pollutants so did not want a device designed for only 1 pollutant at a time
| |
| |- style="border:1pt solid #000000;padding:0.0694in;"
| |
| | style="color:#000000;" | Minimum and maximum detection limits to align with expected ambient pollution levels
| |
| | align=right style="color:#000000;" |
| |
| * Refer to expected ranges in Table 2-2 Summary of some common air pollutants in 2014 US EPA Air Sensor Guidebook (1)
| |
| |- style="border:1pt solid #000000;padding:0.0694in;"
| |
| | style="color:#000000;" | No metal oxide sensors are used for gas measurements
| |
| ||
| |
| *Based on previous sensor testing, metal oxide sensors were either non-functional or stopped working quickly once deployed in ambient conditions
| |
| |-
| |
| |}
| |
|
| |
| {| style="border-spacing:0;width:6.4993in;"
| |
| |- style="border:1pt solid #000000;padding:0.0694in;"
| |
| | style="color:#000000;" | Cellphone modems with data plans for data communications or similar capabilities to transfer data frequently
| |
| ||
| |
| *Wanted the potential for real-time communication and at least the ability to send stored data hourly
| |
| |- style="border:1pt solid #000000;padding:0.0694in;"
| |
| | style="color:#1a1a1a;" | Additional calibrations (beyond factory), willingness to participate in comparison testing, and/or evaluation data from
| |
| previous studies
| |
| ||
| |
| *Looking for some type of additional validation data for the devices beyond the original sensor manufacturer’s factory calibration sheet which are
| |
| typically performed for only a certain set of temperatures and relative humidity conditions. Those calibrations are also not performed for sensors in
| |
| their final housing or device configuration
| |
| |- style="border:1pt solid #000000;padding:0.0694in;"
| |
| | style="color:#000000;" | Ready to be deployed in weather-proof housing
| |
| ||
| |
| *We did not want to build or construct any enclosures ourselves so the device needed to be outdoor deployment ready
| |
| |- style="border:1pt solid #000000;padding:0.0694in;"
| |
| | style="color:#000000;" | Other unique characteristics or specifications
| |
| ||
| |
| * Outdoor, ambient air quality measurements are an emerging use for lower-cost sensor devices so we left these open criteria to be able to consider
| |
| unique or novel features such as creative sampling inlet designs, ability to upgrade as sensor technology advances, etc.
| |
| |-
| |
| |}
| |
| </div>
| |
|
| |
| == Privacy Issues ==
| |
|
| |
| As deployment of sensor networks in cities accelerates, privacy and protection of citizen interests is becoming a key discussion point during the
| |
| planning and implementation process.
| |
|
| |
| As established above, projects where the sensor networks are designed and implemented based on a deep understanding of the problem space, and how the
| |
| data will affect citizen quality of life will have the greatest chance of success. Even if sensor networks are not initiated from a robust needs evaluation
| |
| process, special care should be taken to have open communication with citizens around the types of data you will be collecting, how it will be used and
| |
| how those uses will deliver value to those citizens. If private vendors will be involved in managing the data and analytics performed on the data, the
| |
| scope of their access and the policies controlling their access should be clearly communicated as well.
| |
|
| |
| It’s important to understand several contributing factors to assure privacy is appropriately addressed in your project. Privacy, in this context is the assurance that data collected or observed can only be used for the intended purpose and will not be used to identify patterns and behaviors at an individual level. For privacy to be protected, your system will need to address trust, security and access control. * 1in.5165Trust is the concept that an agent or actor within the system will continue to perform its prescribed function and will not begin to exhibit harmful behavior without being detected by other actors in the system.
| |
| * Security means that agents that have established trust can communicate with each other without fear of unknown actors observing or recording their communication, this is typically achieved through encrypted communication channels.
| |
| * Access control means that there is an established and understood process by which new actors, whether human users, new sensors or additional compute resources gain trust and begin to communicate within the system.
| |
|
| |
| Starting from a position of communicating the value that can be realized for the citizen, and engaging in an open process that allows them to feel ownership in the project will go a long way towards ensuring privacy concerns are understood early in the project and addressed in a manner that still provides the data and insight required to solve the target problem. The perception of privacy can be as important or more important than the actual policies governing privacy. Ensure that you have an effective communications plan that provides clear, honest insight into the policies established for your project.
| |
|
| |
| === Summary of Key Considerations ===
| |
|
| |
| # Communication is key, providing clear, concise information to concerned citizens about how data will be collected, transmitted, and stored will provide citizens with assurance, and ensure that you’ve asked critical questions of the stakeholders around privacy.
| |
| # Connecting the data collected or observed with the services citizens consume clearly is essential for effective buy in.
| |
| # If data is required for a citizen service and must be available in vendor custody, ensure the policies protecting that data are clearly understood by all parties.
| |
| # As data breaches in the private and public sectors are an almost daily occurrence, be sure you have a breach mitigation plan in effect, and that you’ve communicated how such a breach will be handled to your citizens.
| |
| # Creating policies that are both effective and realistic is a delicate balance, made even more so by the rapid iteration of the technologies at play, inevitably there will be cases your policy does not deal with effectively arise. Ensure you have a clearly communicated conflict resolution process that can resolve such situations.
| |
|
| |
| ===2.4.2 Case Study- Array of Things Governance and Operating Policies ===
| |
| Governance and privacy policies for the Array of Things, an urban sensing project in Chicago, were developed in cooperation between the operators of Array of Things- the Urban Center for Computation and Data (UrbanCCD) (a research initiative of the Computation Institute at the University of Chicago and Argonne National Laboratory) and the City of Chicago plus input from the American Civil Liberties Union, the Electronic Frontier Foundation, and the Center for Applied Cybersecurity Research (2). Gathering input on the governance and privacy policies was a key objective of the civic engagement process, see Section 2.5.2 for more details on the process and links to documentation of all feedback.
| |
|
| |
| The Array of Things governance and privacy policies can be found here:
| |
|
| |
| <u>https://arrayofthings.github.io/final-policies.html</u>
| |
|
| |
|
| |
| Summary of feedback related to privacy issues are listed below and come from the detailed Array of Things Civic Engagement Report (2): <u>https://arrayofthings.github.io/engagement-report.html#page_10</u>
| |
|
| |
| Residents, institutions, and commenters asked for more details and/or clarity on: ● The Array of Things partners and their roles such as who is accountable and who owns the data? ● Image Management- What will or will not be captured in the images? How will data be
| |
| encrypted? Who will have access? How long will images be stored? How will images be deleted? ● Made recommendations that the privacy policy include a clear process for when residents believe their personally identifiable information (PII) has been publicly shared accidentally and would like it removed.
| |
|
| |
| * Who are the potential third party researchers who would have access to raw, calibration data? What systems of accountability would govern their work?
| |
| * What extent would any PII collected be subject to Freedom of Information Act disclosure requests?
| |
| * How would data collected from Array of Things sensors interact with Chicago’s law enforcement and other third parties, specifically related to warrants?
| |
|
| |
| == Community Engagement Plans ==
| |
|
| |
| Community engagement strategies need to be implemented before sensors are deployed and throughout the lifetime of the sensor network. Sensor networks may involve installing new infrastructure, collecting data about the community and their surrounding environment, and creating new datasets and knowledge that the community will want to use. Engagement, feedback, input, and responsiveness with the community is at the center of creating a successful sensor network project.
| |
|
| |
| To develop such a comprehensive strategy, sensor network project teams should find partners with established public engagement experience and connections with the communities you are trying to engage. This could include public sector employees who specialize in community engagement, community groups, non-profit organizations, private firms who specialize in community engagement and facilitation, and civic technology organizations. For example, the City of Portland’s Bureau of Planning and Sustainability District Liaison Program has a City Planner assigned to each of the city districts to help listen, connect and problem-solve with the neighborhood on a variety of topics. The district liaisons could be helpful contacts to involve in developing a community engagement plan for a sensor deployment project.
| |
|
| |
| Community engagement for sensor network projects may need to occur in multiple stages. First, there is technical background information to share such as
| |
| what the sensors can and cannot measure, how data will be collected and aesthetic and infrastructure information such as what the devices will look like
| |
| and how it will be installed in your neighborhood. Feedback from the community on these topics then needs to be gathered and any other additional questions
| |
| or comments from residents. For the urban sensing project in Chicago called Array of Things, a broad civic engagement strategy was key because the
| |
| engagement’s purpose was to not only inform residents about the devices but also to identify public concerns and questions, and provide answers with
| |
| responsive solutions to these questions such as revising the governance and privacy policies for the sensor nodes(2). The Array of Things Civic Engagement
| |
| report does note lessons learned on how informing and engaging at the same time was a challenge, See the case study below in Section 2.5.2 for more details
| |
| (2).
| |
|
| |
| Working with community liaisons and community engagement specialists will help to identify the residents whom you need to engage with. To get representative engagement, there needs to be more than one avenue or opportunity for community members to learn and provide feedback. Not all residents will have the time or ability to physically attend a public meeting, not all residents will have access to get online, and there are many other reasons or lack of resources that could inhibit engagement. The Array of Things civic engagement report notes that having multiple platforms to collect feedback was more complicated to manage, but the various options including offline and anonymous options was important to create accessible modes of engagement (2).
| |
|
| |
| For smaller stakeholder engagement meetings, providing stipend resources, food, or childcare can be very helpful to encourage and show the value the team places in community member’s time and inputs. Providing trainings of how to access and use the online tools as well as providing forms and tools in multiple languages is also critical to creating accessible modes of engagement.
| |
|
| |
| Tracking feedback and comments is an important deliverable. Questions, answers, and comments may be ongoing for a sensor technology project especially as interaction with the data collected occurs. Using an online tool or repository to consolidate feedback can be helpful to allow residents to understand the full history of a project and ask new questions. There are many municipalities, public-private-academic partnerships working on developing such civic technology tools. The Array of Things project used the OpenGov Foundation’s Madison tool which is a government policy co-creation platform that collects public edits on policy or legislation (2). If access to such a tool is not possible, creating and posting timely reports on publicly available websites and keeping an active or updated frequently asked question section is another route. Trainings on how to use digital tools or access content available online is another consideration to enhance community engagement.
| |
|
| |
| ===2.5.1 Summary of Key Considerations ===
| |
| # Sensor project teams should partner with existing community liaisons, individuals or groups with established community engagement experience to develop a comprehensive strategy.
| |
| ## Examples include community and nonprofit organizations, private sector firms specializing in engagement and facilitation, civic technology organizations, and public sector employees who specialize in community engagement
| |
| # Community engagement strategies will have multiple stages.
| |
| ## Inform the community on the technical, measurement capabilities, aesthetic and deployment logistics of the infrastructure, and background information on data access.
| |
| ## Solicit feedback and responses on the informative pieces and new questions/comments.
| |
| ## Respond to feedback and offer changes and solutions to address questions/comments.
| |
| ## Continue these informative and responsive channels as sensors are installed, data is collected, and residents begin to view and use the data collected.
| |
| # An informative and responsive engagement process requires multiple channels through which the community can participate, including options that are offline and online, anonymous, and other methods to address the resource limitations that could inhibit your community members from participating in any one of the channels you set up.
| |
| ## Providing food, child-care, ensuring good transportation access to public meetings and even stipends for smaller stakeholder engagement processes will make the engagement process more successful for all involved.
| |
| ## For in-person or online channels, try to offer translating services and multiple language options.
| |
| ## For digital and online tools, think about education and training opportunities to help create more access for residents who speak various languages, have varying digital literacy skills, and disabilities.
| |
| # Documentation tracking feedback, comments, and responses is a key deliverable for community engagement processes. Using online tools or repositories may be a good option to maintain updated documentation.
| |
| ## Work with community members to explore other non-digital options for documentation as well. If online and digital reports are the only option, think about training that can be provided to help the community know how to access this material.
| |
|
| |
|
| |
|
| |
| ===Case Study- Array of Things Civic Engagement Process ===
| |
|
| |
| The Array of Things Civic Engagement Report is available online and provides a full, detailed summary of public feedback and the civic engagement process (2). The case study below is a summary of the content from this report (<u>https://arrayofthings.github.io/engagement-report.html</u>).
| |
|
| |
| ==Project: ==
| |
|
| |
| Array of Things- Urban sensing project to place sensors in Chicago to measure livability factors such as climate, pedestrian traffic, air quality, and flooding. The data collected about the city will be released publicly for residents and researchers.
| |
|
| |
| ==Project Operators: ==
| |
|
| |
| The project is operated by the Urban Center for Computation and Data (UrbanCCD)- a research initiative of the Computation Institute at the University of Chicago and Argonne National Laboratory. The project is implemented in partnership with the City of Chicago.
| |
|
| |
| The civic engagement work was implemented in partnership with the Smart Chicago Collaborative which is a civic organization devoted to improving lives in Chicago through technology with the guiding principles of technology, open, everyone, and Chicago. The organization is guided by three organizations: City of Chicago, the MacArthur Foundation, and the Chicago Community Trust.
| |
|
| |
| '''Goals of Engagement Work:'''
| |
| # Build citywide awareness around Array of Things
| |
| # Aid the operators of Array of Things in their research to address community needs
| |
| # Aid the City of Chicago in gathering input on Array of Things governance and privacy policies
| |
|
| |
| '''Multiple methods to collect public feedback and create accessible modes of engagement including offline and anonymous modes: '''
| |
| # Public meetings
| |
| ## Occurred at library locations close to sensor deployments. Library locations selected because:
| |
| ### Close to public transportation
| |
| ### Regularly host community programming
| |
| ### Are trusted, familiar neighborhood institutions
| |
| ### Beacons of information in communities
| |
| ## Meeting Components
| |
| ### Presentation on Array of Things from project operators
| |
| ### Community discussion and Q&A
| |
| ### Resources for further action
| |
| ### Food
| |
| ### Spanish language support and/or support for how to sign up for MyMadison.io user account
| |
| ## Advertisement
| |
| ### Online
| |
| ### Flyers at public computing centers, coffee shops, anchor institutions, small businesses, Alderman offices, and other community organizations
| |
| ## Documentation of responses to questions can be found here: <u>https://arrayofthings.github.io/policy-responses.html</u>
| |
| # Online forms
| |
| ## An anonymous, low-barrier channel to provide feedback
| |
| ## PDF of the form: <u>https://drive.google.com/file/d/0B75hXlxAwjAZNWVHVy1DaDI3bU0/view</u>
| |
| ## All responses can be found here: <u>https://drive.google.com/drive/folders/0B75hXlxAwjAZeU5TN21JVVRpems</u>
| |
| # OpenGov Foundation tool MyMadison.io
| |
| ## The draft Array of Things Privacy and Governance Policies was posted here. There was a 2-week online comment period where the public could post comments and edits or annotations to the document.
| |
| ## All feedback collected in person and online during the public comment period can be seen here <u>https://mymadison.io/documents/array-of-things-privacy-policy</u>
| |
|
| |
|
| |
|
| |
| ==Lessons Learned ==
| |
| # Informing and engaging at the same time is a challenge. ==Because there was so much background information on the Array of Things to share in the public meeting, there was not much time left in the meetings to spend on public feedback.
| |
| ## <u>Recommendation: </u>Undergo a wider awareness campaign to inform residents of the who, what, where, when, and why of the project before asking residents to react to it.
| |
| # There are trade-offs between technical transparency and accessibility. ==Some commenters called for less technical language while others called for more to increase transparency.
| |
| ## <u>Recommendation: </u>One solution could be to layer the public policies. Publish a transparent, technical policy that is very thorough. Also publish a second policy document with a glossary and summary points that is more accessible.
| |
| # It’s just as important to communicate what the sensors cannot do. ==
| |
| # Be tool agnostic when it comes to public feedback collection. ==
| |
|
| |
|
| |
|
| |
| ==2.6 Local Procurement Processes ==
| |
|
| |
| Creating a sensor network will involve hardware, software, and data communication plans that are unlike previous purchases for a local municipality and involve technologies that are evolving rapidly. These elements can create difficulties for traditional procurement processes. The following discussion highlights certain issues that need to be thought through so that you can work with your procurement office to develop an appropriate procurement process for your sensor application.
| |
|
| |
| The variability in sensor packages is high. The elements developed by the interdisciplinary project team for sensor selection discussed in section 2.3 should be closely integrated into the procurement process to ensure the product purchased will provide the best overall outcome. Purchases based solely on the lowest bid will not necessarily be able to meet your project’s objectives due to the current state of technology for sensors and range of use cases.
| |
|
| |
| An important criterion to include in the procurement review is the ability to upgrade a sensor package or modify the device as technologies change. This element could increase the price but the value it provides in terms of sustainability to produce less waste, increase the lifetime of a device, and potentially save money over time needs to have a higher value in procurement review over lowest bid.
| |
|
| |
| Unfortunately, even with clearly defined sensor selection criteria, it is not a straightforward process to evaluate if a sensor package does or does not actually meet that criteria. A procurement officer performing a review would need to be able to identify what is marketing cruft versus tangible assets. If possible, project team members should work closely with procurement officers in the review process or develop an education process or material to help procurement officers navigate this issue.
| |
|
| |
| Another difficulty for municipal procurement offices working with these rapidly evolving technologies is managing the much shorter lifetimes of these products versus traditional civic infrastructure. Project budgets may need additional allocations for maintenance and staff time to remove, replace, and keep track of sensor products in the established asset management systems. Project team members should also work with procurement offices ahead of time to let them know of these different lifetimes and pathways compared to other civic and technology infrastructure projects and see if it is possible to create new mechanisms for pilots.
| |
|
| |
|
| |
| ==2.6.1 Summary of Key Considerations ==# 1in.4665The sensor selection criteria (Section 2.3) designed for your sensor project should be closely integrated into the procurement review & selection process to ensure the product purchased leads to the best overall project outcome and purchasing decisions are not made based solely on the lowest bid.
| |
| # Can the sensor device be upgraded or modified as technologies change?
| |
| # 1in.5429Project team members need to be a part of the review process with procurement officers or create an educational process on how to evaluate the sensor selection criteria to make sure actual sensor parameters are met and marketing material does not incorrectly meet criteria.
| |
| # 1in.5862Can you allocate additional funds in your project budget to help with maintenance and staff time to remove, replace, and keep track of sensor products in existing asset management systems?
| |
| # 1in.3118Work with procurement offices ahead of time to discuss alternative pathways of purchasing and management for pilots because the rapidly evolving technologies in sensor networks will have shorter lifetimes versus traditional civic infrastructure purchases and contracts.
| |
|
| |
|
| |
|
| |
| ==2.7 Installation Considerations ==
| |
|
| |
| Location is one of the most important considerations for sensor deployment, after all, the technical capabilities of your sensors won’t matter if they don’t have access to the phenomena they’re intended to measure. Equally significant are the costs of installation, and the accessibility costs for ongoing maintenance. As IoT and sensor technologies progress, there is the real possibility that the installation and maintenance costs will eclipse the actual hardware cost for your project. Having a comprehensive understanding of the sensor environmental requirements, location optimization, and location-type installation costs will ensure your project is successful and within budget.
| |
|
| |
| Scoping installation costs and potential issues requires fully understanding the location requirements of your project. You will want to understand the required proximity to the measurement target, hardware durability, access and frequency of maintenance, and the requirements for power, communications, etc.
| |
|
| |
| You will also need to establish what entity is responsible for installation and maintenance, and whether that entity controls available locations that fit the above criteria. If the responsible entity does not have control of those locations, you will need to determine what entity does, and establish agreements that
| |
|
| |
| permit their use. These access needs underscore the requirement for having strong community engagement and ensuring all stakeholders needs are considered during the planning process.
| |
|
| |
| With installation representing such a large portion of the cost of sensor initiatives, preemptively creating infrastructure to host sensors during other infrastructure projects can be worth it. Many cities are adopting permitting processes for commercial small cell deployments that require the commercial entity to provide “service ports” for municipal projects that provide a mounting point, power, and communications capacity at each node of the small cell deployment.
| |
|
| |
| ==2.7.1 Summary of Key Considerations: ==
| |
|
| |
| A. What are the technical location requirements?
| |
|
| |
| <div style="text-align:right;color:#000000;margin-left:0in.7098a. Does the vendor have requirements relating to mounting, location, elevation etc.?
| |
|
| |
| <div style="text-align:right;color:#000000;margin-left:0in.320113
| |
|
| |
| b. Do candidate locations have proper access to observable phenomena? Do these observable phenomena correlate with the location of the problem you’re trying to solve?
| |
|
| |
| B. What are the accessible locations in the context of your project?
| |
|
| |
| a. What is the Mean Time Between Failure (MTBF) for hardware you’re installing, as established in a real-world deployment?
| |
|
| |
| b. If unknown, or not suitably tested to a certain confidence level, are there opportunities for pilot scale installations in easy, low-cost locations to evaluate longevity for yourself?
| |
|
| |
| ==2.8 Data Communication and Management Plans ==
| |
|
| |
| Proper planning for data retrieval and management is key for successful deployments. Understanding both the type and amount of data generated by your sensors, as well as the requirements of your applications will ensure that the right infrastructure is deployed the first time to operate a sensor platform that delivers value to your citizens reliably.
| |
|
| |
| The first step is understanding your proposed use cases for the data, and the latency and bandwidth implications of those use cases. This will set the baseline for what your data transmission, storage, and management systems must deliver.
| |
|
| |
| Next you need to understand the infrastructure and assets available to your city for communications. Does your city have a municipal fiber network? What LTE carriers does your city have existing contracts with? This is also constrained by your deployment location; what services are available at your ideal deployment points? What existing city services that require communications are deployed that you can leverage?
| |
|
| |
| For data storage you can deploy to on premise city IT infrastructure, cloud infrastructure, or hybrid. How you will make use of the data and what systems already exist are important factors in choosing your storage system. If you are primarily integrating with existing systems it may make sense to deploy to the same infrastructure those systems reside in.
| |
|
| |
| If you are building primarily new services on your platform, you may want to use existing standardized cloud services that will allow easy interoperation with future systems, as well as attract entrepreneurs to build new services on your platform. Your use cases and data format will dictate what type of storage you need, and what workload it is optimized for.
| |
|
| |
| With careful consideration and understanding of the use case, infrastructure and expertise available, and strategic long-term goals, this data infrastructure can support projects in your city into the future.
| |
|
| |
| ==2.8.1 Summary of Key Considerations: ==
| |
|
| |
| A. Technical implications of proposed use cases
| |
|
| |
| a. Bandwidth
| |
|
| |
| i. What is the minimum interval you will need?
| |
|
| |
| ii. How much data does each sample require?
| |
|
| |
| b. Latency
| |
|
| |
| i. How soon do you need to know that an observed condition has changed?
| |
|
| |
| ii. Do you need streaming data or are batch downloads ok?
| |
|
| |
| c. Data format
| |
|
| |
| i. What metadata needs to be available in real time?
| |
|
| |
| ii. What other systems will need access to this data and with what level of incontext?
| |
|
| |
| d. Engineering
| |
|
| |
| i. Is the deployment environment compatible with the proposed communications system?
| |
|
| |
| ii. What systems will be in place to measure the performance of the network and prove network reliability in the case of a vendor blaming the network for
| |
| an application issue?
| |
|
| |
| B. Policy implications of proposed use cases
| |
| a. Networks
| |
| i. Can the data from this deployment coexist on a network deployed for other services?
| |
| ii. If sharing a network deployed for other services, how will you ensure the necessary partners for your project have sufficient access?
| |
| iii. What specific privacy concerns need to be addressed at the network level? iv. Is the application Service Level Agreement(SLA) compatible with the proposed network resource SLA?
| |
|
| |
| ==2.9 Data Standards ==
| |
|
| |
| Assessing the existing and developing standards before starting a sensor project can help support interoperability with other sensor systems within your community, allow for sharing and comparisons of data across communities, and enhance data integrity as technologies and systems change. Identifying the appropriate and applicable data standards for your project can also enhance data management and communications processes.
| |
|
| |
| If you are planning to use the data from the sensor network for regulatory purposes, there may be accuracy, calibration, validation, or other quality assurance/control standards or protocols required by regulatory agencies to whom you will submit the data. This includes standards or protocols for assessing and correcting for sensor calibration drift over time. Because the application of regulatory data quality protocols may be resource intensive (e.g. staff time, access to a laboratory for calibration), you should apply these protocols only to those phenomena that are essential for current or anticipated regulatory needs.
| |
|
| |
| There may be data representation (i.e. serialization formats) and access (i.e. application programming interfaces; APIs) standards that you can take advantage of as part of the data management hardware/software solution you plan to use and/or hardware and software solutions you will want to integrate datasets with. This can include official standards ratified by standards bodies (e.g. OGC, ISO, etc.) as well as ''de facto ''standards developed by government agencies (e.g. NWS Mesonet, USGS NWIS). Further, some standards are applicable to data from arbitrary phenomena (e.g. OGC SOS, OGC SensorThings), while others are domain specific (e.g. OGC SOS Hydrology Profile; OGC WaterML, GroundwaterML).
| |
|
| |
| The advantage of using established data representation and access standards is that they allow for the development and use of data management, visualization, analysis, and quality control tools across members of a community. This can be especially true when using official standards, which may lend themselves to larger communities of interest. Having access to these common data management tools can drastically reduce the cost of developing your own sensor network. Additionally, contributing standards-based data management tools that you have developed to a broader community helps to build and sustain that community, which helps ensure the sustainability of your project (i.e. you won’t be going it alone), and helps to ensure that sensor network data management systems evolve in ways that align with the strategic interests of your sensor network.
| |
|
| |
| Next, you will need to consider how the data management solution provides data integrity guarantees for both data in motion (i.e. when being transmitted) and data at rest (i.e. when being stored). Data integrity is especially important for data that will be submitted to regulators, and for data that may be subject to evidentiary requirements of civil or criminal legal proceedings. The key question to ask in these cases is: does your data management solution allow data chain of custody and integrity to be verified by a third party?
| |
|
| |
| ==2.9.1 Summary of Key Considerations ==
| |
|
| |
| A. What are the best practices in industry for the type of data you’re collecting? B. Do you plan to use the data from the sensor network for regulatory purposes? If so, identify the accuracy, calibration, validation, or other quality assurance/control standards or protocols required by regulatory agencies to whom you will submit the data.
| |
|
| |
| C. Are there data representation (i.e. serialization formats) and access (i.e. application programming interfaces; APIs) standards that you can take advantage of as part of the data management hardware/software solution you plan to use?
| |
|
| |
| D. Are the standards for real time streaming formats the same as the batch download formats? E. Contributing standards-based data management tools that you have developed to a broader community can help build and sustain that community and your project’s sustainability. F. How does the data management solution provide data integrity guarantees for both data in motion (i.e. when being transmitted) and data at rest (i.e. when being stored)?
| |
|
| |
| G. For data to be used for regulatory or legal purposes, does your data management solution allow data chain of custody and integrity to be verified by a third party?
| |
|
| |
| H. What features do the standards you adopt need to support to address your vision for future deployments?
| |
|
| |
| I. Are the data standards comprehensive enough to become a policy to ensure interoperability for future projects?
| |
|
| |
| <div style="text-align:right;color:#000000;margin-left:0in.3228J. If creating a data standard policy, is it written to allow superseding technologies to be deployed?
| |
|
| |
| ==2.10 Data Validation ==
| |
|
| |
| Data validation is a critical step to ensure usable data for your identified use cases or applications for sensor measurements. Lower-cost sensors can be affected by a wide range of variables including power for connectivity and communication, orientation of the sensor, temperature, and installation issues such as a loose wire. A method will need to be planned for how you will validate data initially as well as measure and maintain data validity over time. Data validation may need to occur seasonally as other environmental variables change.
| |
|
| |
| To help decide the level of validation required, you can consider the level of resistance that may occur to the decisions that are based off the data. Similar to data standards, if the data is to be used for regulatory or legal purposes, a strict level of data validation will be required and there are standard procedures you can refer to develop your methods. Community engagement strategies may also be able to help inform you of what the community would look for to understand and trust the data measurements are valid.
| |
|
| |
| Leveraging relationships with research/university partners, other local or state agencies, and/or private partners to provide resources such as higher cost instruments and other sets of data may be needed for validating certain kinds of sensors such as low-cost air quality sensors. Comparing sensors to the existing
| |
|
| |
| forms of measurement, for example a traffic camera compared to inductive-loop counts, can be a helpful method of validation and address a common question you may get from other practitioners and the community.
| |
|
| |
| If working with a private company providing the sensors, figure out a plan during contracting to make sure you have all the data needed to conduct ground-truth or validation studies on your own. For example, if using video cameras and machine learning algorithms for pedestrian, traffic, and bicycle counts and the company is not providing any type of validation or error information then you need to make sure you have access to some of the actual images with the ability to overlay the counting/detection zones on the images. Validation projects can be useful applied research projects for students as well as the data users and sensor device developers.
| |
|
| |
| Planning data validation alongside data standards can also help tackle issues such as addressing drift and accuracy in sensor measurements and supporting data integrity throughout the life cycle of the data and sensors. When planning these methods, think ahead about methods of how to correct data after data validation tests are applied and what other proofs will be required for the data users and community to return the system to an operating level of trust.
| |
|
| |
| ==2.10.1 Summary of Key Considerations ==# 1in.5661How will you validate the data initially, and how will you measure and maintain data validity over time?
| |
| # 1in.3307What level of validation is required based on the level of resistance the decisions that are based off the data will face?
| |
| # 1in.4409How will you manage situations where the data is proved to be unreliable, what proofs will be required to return the system to an operating level of trust?
| |
| # 1in.7146How can you leverage relationships with research/university partners, other local or state agencies, and/or private partners to help provide data and other needed resources for validating the sensors?
| |
|
| |
|
| |
|
| |
|
| |
|
| |
| ==2.11 Data Integration ==
| |
|
| |
| A pitfall for many smart community projects, data integration if not properly planned for can cause cost overruns, reduced usability, delayed return on investment (ROI) and even complete failure of a project. Integration of a new data source into existing or externally scoped systems is a complex process. While
| |
|
| |
| immense value can be obtained from a well-integrated system, special care must be taken at the planning stage to ensure success.
| |
|
| |
| During the planning process for your project, be sure to spend adequate resources scoping the data integration requirements. Ensure you know the exact level of integration and specific value streams the stakeholders are looking to unlock through these integrations.
| |
|
| |
| Ensure all platforms that you will be integrating have the required features and APIs to successfully integrate into the final solution. Be sure you are connecting your integrations team with respective vendor technology teams so that you get beyond a sales executive saying yes to everything.
| |
|
| |
| Some sensor platforms are better suited for specific types of integrations than others. If your value proposal has a real-time component to it, you may need to select a sensor platform that can support that requirement, based on its integration capability rather than its sensing domain performance.
| |
|
| |
| ==2.11.1 Summary of Key Considerations ==
| |
|
| |
| A. Who will own the process of integrating data for the final application?
| |
|
| |
| a. Does the responsible party have the required legal agreements in place to access all the data required?
| |
|
| |
| b. Will the city retain access to all data for future integrations?
| |
|
| |
| c. Do you have an agreed upon technical plan created with the vendor engineering teams before making the investment?
| |
|
| |
| B. Who owns the operation of the sensor platform?
| |
|
| |
| a. Is it compatible with systems already in place in your civic technology infrastructure? b. Do you need a new platform, or can existing platforms be used to provide the solution? C. Do all relevant city agencies understand the application requirements and the data integration process?
| |
|
| |
| a. Are there missed opportunities to address secondary issues by adding minimal additional integrations?
| |
|
| |
| ==2.12 Funding ==
| |
|
| |
| Project funding can be a daunting challenge, especially when deploying a new or unproven technology. There are many ways to fund a smart city sensor network. The right funding mechanism for your project will be determined by many external factors. This section will help you understand some of those factors, and the key questions you can ask to understand the right funding model in your community.
| |
|
| |
| Public-Private-Partnerships (PPPs) are a popular model for sensor network deployments. However, much of this document warns of the importance of maintaining control of the collected data and its derived value in the public realm. Balancing this concern for privacy with a PPP deployment can be challenging, and the success will most likely rest on the sensitivity of the specific data you’re addressing.
| |
|
| |
| Wrapping sensor networks into larger infrastructure projects is another common tool for funding projects. These can be highly effective, representing not just a strong ROI, but actually reducing the capital outlay cost of the total infrastructure project by using a sensor network to maximize its efficiency from day one. Care should be taken to communicate exactly how the sensor network benefits the community and the project. Infrastructure projects are large and complex, and often subject to delays and cost overruns. Without a strong understanding within the community of the value the sensor network provides, it will be all too easy to cut from the project when difficulties arise.
| |
|
| |
| Standalone projects are certainly possible, and if the public awareness of the problem to be solved is great enough, can be the easiest to generate support for. Successful projects will likely address an immediate need with an immediate solution, and a project narrative that citizens can clearly understand.
| |
|
| |
| Pilot projects can often be easier to get off the ground than fully scoped solutions. However special care should be taken that resources are budgeted to communicate the success of the pilot to help build support for the larger funding required for full deployment. Ideally budget will also be allocated to support some amount of pivoting of approach in case assumptions made in the pilot proposal are proven false during the course of the pilot.
| |
|
| |
| For any of the above funding formats, you will still need to have a thorough understanding of your network’s business model; including the costs of ongoing operations, maintenance (replacement, upgrades), and lifecycle costs. While a sensor network that generates income for the city is a great asset, it’s not required or desirable in all situations. The goal is to create a sensor network that delivers more value than the resources it consumes. That value can spread across multiple departments and services, and documenting that value is one of the key reasons to engage as many stakeholders as possible.
| |
|
| |
| As you begin to develop a budget for your project, reducing the cost of operation and deployment is critical. While grant funding can be an appropriate source of capital costs, the operation and maintenance needs are what the community will be living with on an ongoing basis. Ensuring sustainability will require true operationalization of the resulting services and data delivered by the network, ideally from multiple stakeholders.
| |
|
| |
| ==2.12.1 Summary of Key Considerations ==
| |
|
| |
| A. What funding model is most compatible with the primary use cases?
| |
|
| |
| a. P3’s may be appropriate for some networks and not for others, based on security, privacy and other public responsibilities
| |
|
| |
| b. Is the project ROI driven, or based on political priorities?
| |
|
| |
| c. If ROI driven, does the network need to be revenue positive on its own, or can the value be delivered through other channels?
| |
|
| |
| B. Have you engaged other city agencies to determine additional value streams that can be generated by the network?
| |
|
| |
| a. Are those value streams compatible from a security, privacy and technology standpoint with your primary use case?
| |
|
| |
| C. If pursuing grants to start a project, are you engaging the public and other agencies early to ensure sustainability and adoption beyond the
| |
| grant-funded scope?
| |
|
| |
| a. What are the ongoing operations costs that need to be offset after the grant term?
| |
|
| |
|
| |
| ==2.12.2 Case Study: Lincoln Nebraska Small Cell Deployment ==
| |
|
| |
| The City of Lincoln was faced with a familiar challenge to most communities in this era. With multiple wireless carriers pushing to deploy their m
| |
| odern small cell services within the public realm, how could the City ensure that these deployments delivered maximum value for the public, and not
| |
| ust each carrier’s subscribers? By crafting legislation that required the permitted carriers to take on operations and maintenance costs of the public
| |
| assets they were utilizing, as well as deploying communications and infrastructure for city services at no cost, the city ensured that these assets were
| |
| a benefit to all citizens of Lincoln, not just the users of the carrier networks.
| |
|
| |
| Learn more about this approach and find links to samples contracts, drawings of agreed on pole designs, and more at Community Broadband Networks,
| |
| posted on February 1, 2017:
| |
|
| |
| [https://muninetworks.org/content/small-cells-yield-big-results-lincoln-community-broadband-bits podcast-238]
| |
|
| |
| ==2.13 Sensor End of Life Considerations ==
| |
|
| |
| Lifecycle management and planning will be a key component of a successful sensor deployment, and will need special attention during the procurement process detailed in 2.6. Unlike many public realm assets, sensors, their associated infrastructure and communications hardware as well as the software systems that integrate with them are evolving rapidly. While a typical asset like a light pole or street sign may expect lifecycles measured in decades, many of these systems will not be relevant technologies within 5- 7 years. It’s important to understand this reality of working on the bleeding edge of technology, and the implications for deployment and planning that these much shorter lifecycles have.
| |
|
| |
| Budgeting for replacement of components in your original project scoping is a key step in effective lifecycle management for a sensor network. You need to understand the direct hardware costs associated with replacing a failed component, as well as the indirect costs, such as labor, mounting materials, calibration, or any external services required to restore the system functionality after a component failure. Understanding the Mean Time Between Failures (MTBF) for the various components of the system will help you accurately model the replacement costs over the planned lifetime of the system. A detailed deployment plan will help you understand the indirect costs of installation, and eventual deinstallation at the project’s end.
| |
|
| |
| Aside from budgetary concerns with lifecycle management, environmental impact is an important consideration that will vary with the type of sensors deployed. Some sensors that collect physical samples will even obtain enough of the targeted pollutant that they will require special disposal considerations at end-of-life. Many sensors are made with rare earth materials that should be responsibly recycled, but may require special processes. Understanding and making provisions for those processes should be undertaken at the beginning of the project, while all the necessary stakeholders and expertise are engaged.
| |
|
| |
| ==2.13.1 Summary of Key Considerations ==
| |
|
| |
| What are the reasonable expectations for the lifetime of your sensors?
| |
|
| |
| What critical services will be relying on your sensor network, and how will you manage the transition to the next generation of technology at end-of-life?
| |
|
| |
| What costs are associated with replacing a sensor, outside of the hardware itself?
| |
|
| |
| How will you fund the selection process for the next generation of sensors at the end of your project’s lifecycle?
| |
|
| |
| How will you ensure data integrity as you replace hardware?
| |
|
| |
| Are there standards for the type of sensor you are selecting that will give you confidence you can find an equivalent sensor after the original design
| |
| is end-of-life? b. What mechanisms does your network have for managing records of sensor replacement, calibration and other integrity affecting lifecycle
| |
| events?
| |
|
| |
| ==3 Conclusions ==
| |
|
| |
| The compiled information in this document strives to provide a robust orientation for those tasked with assessing, planning or deploying advanced distributed sensor networks in communities. Twelve project stages for a distributed sensor network were identified through two facilitated workshops in Washington, DC and Portland, OR as part of the NIST GCTC program. The discussion of key considerations for each project stage help to identify common issues and lessons learned from existing projects while challenging the reader to discover the critical aspects of their project through coordinated effort with the appropriate stakeholders, and with full appreciation for the cultural, technical and resource constraints of their community.
| |
|
| |
| A recurring theme throughout this document is the absolute dependency on good communication with stakeholders, and a realistic view of the limitations in expertise and resources within that group that you should seek to augment for maximum efficacy. As the available technologies and community needs evolve, we hope that keeping this theme in mind while addressing the various considerations identified here will help support successful planning and implementation of sensor networks.
| |
|
| |
| ==References ==
| |
|
| |
| Williams, R., Vasu Kilaru, E. Snyder, A. Kaufman, T. Dye, A. Rutter, A. Russell, AND H. Hafner. Air Sensor Guidebook. U.S. Environmental Protection Agency, Washington, DC, EPA/600/R-14/159 (NTIS PB2015-100610), 2014
| |
|
| |
| <u>https://cfpub.epa.gov/si/si_public_record_report.cfm?dirEntryId=277996</u>
| |
|
| |
| Array of Things Civic Engagement Report, A summary of Public Feedback & the Civic Engagement Process. Prepared by Smart Chicago Collaborative and the Urban Center for Computation and Data (Computation Institute at the University of Chicago and Argonne National Laboratory). Available online at: <u>https://arrayofthings.github.io/engagement report.html</u>
| |