Last Mile/First Mile EVA Blueprint: Difference between revisions
From Modelado Foundation
imported>Niveditasinghvi No edit summary |
imported>Niveditasinghvi No edit summary |
||
Line 188: | Line 188: | ||
* '''Routing software''' | * '''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 | 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. | ||
{| class="wikitable" style="color:darkblue;background-color:#B8CDD2;" cellpadding="10" | {| class="wikitable" style="color:darkblue;background-color:#B8CDD2;" cellpadding="10" | ||
Line 210: | Line 210: | ||
|} | |} | ||
A comprehensive look at transit specifications and apps is available at the [http://www.transitwiki.org/TransitWiki/index.php/General_Transit_Feed_Specification TransitWiki page on GTFS]. | |||
* '''Other software & services''' | * '''Other software & services''' |
Revision as of 21:57, February 17, 2017
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?
- If people, why, when, and how often are they moving.
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 |
- 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
- Describe range of solutions.
- 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…