Last Mile/First Mile EVA Blueprint

Links and Section Status Information

mediawiki-help -- If you have any wiki editing questions, please see this page.

Urban Mobility -- Urban Mobility Workshop Main Page

This blueprint document is to be submitted in March, 2017. See the parent Urban Mobility workshop page for more information.

Section Title	Volunteer Editor	Complete?	Comments
Intro	Nivedita Singhvi	Yes
Design Pilot Concept	Daniel Frye	Underway
Choose System Components	Nivedita Singhvi	Underway
Build Out Partner Ecosystem		Not yet
Build, Integrate and Test		Not yet
Operate Pilot & Learn		Not yet
Manage Optics and Community Perceptions		Not yet
Municipality		Not yet
Integration of solution into existing system		Not yet
Summary	Nivedita Singhvi	Not yet	Needs other sections complete

Feel free to add yourself to the table above as an editor, or simply edit the document below directly.

The Low Speed Electric Autonomous Vehicle (EAV) System

The deployment of an operational low-speed, EAV system for a real-world, useful deployment requires much more than finding an electric vehicle, choosing autonomous software and combining them on a street, but rather there is an entire mini-ecosystem that needs to be incubated and managed. This blueprint will describe those various steps and elements and weave them together into a both a timeline and a description of an integrated system that better enables and supports vibrant communities.

The blueprint leading to the deployment of a real-world, useful pilot contains roughly the following major steps:

• Identify the problem (gather community requirements)
• Create a solution vision & study/choose/map a site
• Design pilot concept
• Choose system components (vehicle, autonomous solution, system tester…)
• Build out partner ecosystem
• Build, integrate, and test system
• Operate pilot and learn from experience
• Manage optics & long-term community perception

The following sections are each of those elements, taken one by one. In addition, there is a separate section on the varied interactions likely with the municipality involved.

Identify the problem (gather community requirements)

The first step is to identify at least one real world problem whose solution or mitigation is the goal of the eventual production deployment. A demonstration of technical capabilities without a target problem might be of fleeting interest but the wide range of options becoming available for each of the major technical & operational components (Vehicle, Autonomous Systems, ticketing, communities served, geographic restrictions, etc.) makes it very unlikely that an arbitrarily chosen set of system components suitable for a demo will be readily deployable for an eventual end solution. Key elements to consider in creating the larger strategic goal include:

• Key objective(s) desired: Reduction in traffic congestion? Reduction in carbon footprint? Creating a new mobility option for an underserved community?
• Moving people or goods?
  • If people, why, when, and how often are they moving.
    • Commuting to/from work/school/shopping/etc.?
    • Transport within a facility?
    • Scenic loop?
  • If people, what is the profile of the user base?
    • Working adults?
    • School children?
    • Physically challenged?
    • Military personnel on a base?
  • If goods, why/when are they moving? How often? How large are deliveries?
    • Deliveries of supplies to commercial entities?
    • Tight commercial center?
    • Movement within a distribution center?

The net result should be a relatively high-level, concise statement of purpose that can be used to drive the selection of key components and solution elements.

Create vision & study/choose/map a site

Describe considerations

• Public, semi-public, or private roads. Generally speaking, public roads will tend to provide the most comprehensive test of an EAV pilot and private roads the least comprehensive test. Public roads often have the most heterogeneous set of traffic participants (private vehicles, public transit, freight, bikes, and pedestrians as well as the higher level of public scrutiny. However, private and semi-private roads often have fewer (or no) regulatory barriers and often more of a homogeneous traffic pattern (all trucks or all cars for example) where simpler pilots with less comprehensive Autonomous function can still perform a valuable function.
• Distance, geography, hours of operation, speed and other road considerations.
• Regulatory barriers. Regulatory barriers come in multiple forms Most common are the laws and standards that vehicle manufacturers must adhere to when constructing vehicles to be used on public roads. These include standards for private vehicles, low-speed vehicles, freight vehicles, buses, etc. A few key standards to be aware of are collected here Standards for EAVs. There are many fewer regulatory barriers around Autonomous operation of vehicles, but those are increasing as well and more are expected as more countries, states, and municipalities grapple with the emerging EAV market.
• Communities to be served.

Design Pilot concept

Once a site is chosen and mapped, decide on the outline of the pilot, making choices for the following considerations:

• Size of pilot (number of vehicles, hours of service, types of service, length of pilot)
• Attended or unattended vehicles.
• Paid or unpaid service.
• Distance, geography, hours of operation, speed and other road considerations?
• Regulatory barriers.
• Is the service subsidized or for profit?
  • If for profit, is there a need for on-board ticketing?

Put the elements in place and execute….

Choose system components

• Vehicle provider

There is a significant range of EAVs already in the market with more coming. Create a system to execute the vision and choose the right combination of technology. The table below will list applicable vehicle along with pointers to where more information can be found. It is intended that all vehicles here are or can be electric only and are capable of being operated at least at Autonomous Level 3 or higher (there can be a driver-required mode, but there has to be a operational mode that has some level of Autonomous capability).

Company Name	Model	Type of vehicle	Number of seats	Autonomous or autonomous ready?	Active pilots
Navya	Navya Arma	Autonomous Electric Bus	Upto 15	Yes	Yes
Mobility Cubed	Mobility Cubed Bus	Electric Bus	Configurable	Not Standard	Yes
Local Motors	Ollie	Self-Driving Electric Bus	Configurable	Yes	Yes

• Autonomous software

There are several independent companies who create and manage the software to run an autonomous vehicle. These can be small electric 2-seater cart-type vehicles to large 16-passenger electric shuttle buses. Typically, the autonomous software vendor works with the automobile manufacturer or vendor and converts a standard vehicle to run in autonomous fashion. Changes might require not just the integration of software components but also manual, physical changes to the vehicle structure.

Company	Product Info	Pilots	Comments
Meridian	Autonomous software for electric vehicles of various types.	Yes	Members from predecessor to the Navya AEV company
Oxbotica	Autonomous software for electric vehicles of various types.	Unknown	Oxford University offshoot
Bosch	Vehicle software of all types	Yes	Tier 1 Supplier in auto industry

• Routing software

This includes software which manages and displays transit vehicle routes and schedules, stops, and possibly updates in real-time with information about delays, changes, and so on. There are a very large number of such transit apps both free and open source, as well as commercial software packages. They can be bundled with "fleet management" software, which includes information about the transit vehicles such as hours in operation, maintenance schedule, state of components, etc. It is recommended that the software provide and comply with the industry-standard, widely-used open specifications for its routing and scheduling. Relevant API specifications for transit include GTFS and GTFS-RT shown below.

Feature	Description	Standard/Specification	Use	Comments
General Transit Feed Specification (GTFS)	Specification to define static transit vehicle routes, schedules, stops	Yes	Many applications support GTFS. Google Transit Support allows you to upload your GTFS feed for display on Google Maps.
General Transit Feed Specification Real Time (GTFS-RT)	Dynamic update enhancement of the GTFS Specification for real-time data	Yes	Google Transit Support allows you to upload GTFS-RT data for consumption by Google apps. Many applications support GTFS-RT to show transit updates in real-time.

A comprehensive look at transit specifications and apps is available at the TransitWiki page on GTFS.

• Other software & services

In addition to the autonomous software to operate the vehicle and route scheduling software, there are other categories of software that might be required.

Feature	Description	Solutions
Vehicle tracking	Real-time tracking of vehicle location (possibly via GPS). Other parameters could also be tracked such as speed, remaining battery, hours in operation, etc. This might get bundled by the vehicle provider with the autonomous software for vehicle, or more frequently, is provided separately.	A variety of open source and free options are available, along with commercial solutions.
Vehicle operations	Maintaining individual vehicle records (subsystem parameters, servicing history, repairs, scheduled maintenance, charging, component replacement, etc.) for servicing.	There are a large number of free, open source and commercial solutions available.
Fleet Management	Usually, this category of software provides solutions for individual vehicle management as well as broader fleet management. Fleet capacity, categories of vehicles, suppliers, components, and so on. Often all of the vehicle tracking, operations and fleet management is bundled together.	There are a large number of free, open source and commercial solutions available.
Ticketing of passengers
In-vehicle wifi and internet access solutions	routing, firewalls, vpns, backend storage, cloud services, etc.
In-vehicle and external advertising	Electronic banners and displays and other software-driven solutions (marketing in/on the vehicle as well as at stops, stations).

• System tester
  • Test tracks, on-street testing…
• System integrator
  • Describe range of solutions.

Build out partner ecosystem

With a strategic vision & a technical solution in place, build a partner ecosystem with both elements. Common partners that should be identified early in the process are:

• Solution beneficiary, such as a city or urban renewal district or military base or commercial entity such as a warehouse or a consortium of restaurants looking for nightly supply deliveries
• Vehicle provider: Vehicle manufacturers are now developing and selling a wide range of electric vehicles suitable for autonomous deployments: cars, mini-trucks/vans, buses small and not so small
• Autonomous software provider (if not integrated in the vehicle)
• Solution Integrator
• Product deployment operator – the entity that will be operating the eventual solution on a permanent basis.
• Local regulatory authority – may or may not be the same as the solution beneficiary.

Not all partners are necessary in all phases, but identifying the key players upfront is critical. Of particular importance is engaging with the local regulatory authority early in the process. Most early autonomous deployments will need to resolve barriers, force the creation of new policies, gain buy-in around traffic and safety concerns.

Build, integrate & test solution

Put the elements in place and execute….

Operate pilot & learn from experience

Operating an autonomous vehicle transit system in production (regular, reliable transit of goods or people for a useful reason) requires the system operator to resolve a unique set of issues and to provide a broad set of services, many of which are different for an autonomous system than a system that is staffed. Some of those key differential items are:

• Regulatory compliance - In many cases, regulations for operating autonomous vehicles will not exist or will be explicitly forbidden. Early work with local regulatory bodies is highly recommended.
• People/goods security -
• Cyber security -
• Insurance & liability -
• Secure ticketing -
• Optics - Making sure that the communities the system operates in are well-informed and educated about the safety of the system.
• Interoperating with other last mile/first solution components (bikes, walking, rideshare, public transit, etc.)
• Reporting

Success will be measured….

Manage optics and long-term community perception

There is likely to be upfront and, potentially ongoing, resistance and concerns about AV pilots and product deployments. Concerns about safety are a given and will need to be managed upfront, through a pilot, and well into production phase. It is necessary….

Municipality

Municipalities, generally speaking, can have any combination of four roles in a last mile/first mile solution. BTW, in this context, “municipality” includes both traditionally defined such as cities, counties, and metro areas, but also could be military complexes, urban renewal districts, master-planned communities, airports, and/or tightly-knit neighborhoods. They can be any combination of

• Solution beneficiary - The municipality is one of the principal beneficiaries of the solution (it does not have to be only one).
• Solution operator - Municipal employees operate the system.
• Regulatory provider - The municipality creates the regulations.
• Compliance monitor - The municipality monitors compliance with the regulations.

In many cases, each of these roles may exist in different parts of the municipality organization and, if so, will require different, and potentially, unique approaches. Working with the local municipality may be one of the longer set of processes to be established and should start early in the planning process..

Integration of the system into the existing Last Mile/First Mile existing solutions.

Describe how the resulting production system leverages and links to other Last Mile/First Mile elements. Describe potential commercial exploitation.

Summary

Tie it together…