>SMRSQKX 6OZK\^WOX^ 2742:;8BC C> 34B86=0C4 0A40B >5 AKQO * YP +
A ?A>?>B0;
C7BF;D;E;@? ?F>47C 6F7 63E7 E;>7 6F7 2795 07/29/19 noon est >6@E AC@<75E >3?397C <@4 ?F>47C "
<3>C ?A>942C <0=064A. 5ROMU KVV S^OW] ^Y LO SXMV_NON 2>=BD;C0=C. A\Y`SNO YXVc MROMUON S^OW] LOVYa SX SX& H:;E7 1 C7BF;C76 Z\YZY]KV =63: /<<871/083# (3>? -/8@3 >1;=7:5 1=7?3=7/ 7> 87>?32 >3 ;1. &$') (973.,; &*6*0.9# 5ROMU ^RO KZZ\YZ\SK^O ESO\ SX ^RO LYb LOVYa
C84A * C84A 88 C84A 888 #"$#)%))) & "%,)%)))$ #"%,)%)))&"*%&))%)))$ #/"*%&))%)))$ FXNO\]^KXNSXQ YP DO\`SMO $$ ?(3 9QQRYEWMRQV @\QKXSdK^SYXKV 5RK\^ B_KVSPSMK^SYX] YP EOKW
?(3 ?(3 B_KVS^c 3]]_\KXMO(B_KVS^c 5YX^\YV $$ ;SHFXNSR. ERO ZO\MOX^KQO YP aY\U ZO\PY\WON SX >SMRSQKX aSVV LO _]ON PY\ KVV ]OVOM^SYX] _XVO]] ^RO Z\YTOM^ S] PY\ YX&]S^O SX]ZOM^SYX Y\ ]_\`Oc KM^S`S^SO]% ^ROX VYMK^SYX ]RY_VN LO ]MY\ON _]SXQ ^RO NS]^KXMO P\YW ^RO MYX]_V^KX^ YPPSMO ^Y ^RO YX&]S^O SX]ZOM^SYX Y\ ]_\`Oc KM^S`S^c' ?(3 ?(3 A\O]OX^K^SYX $$ ?(3 ?(3 EOMRXSMKV A\YZY]KV "SP A\O]OX^K^SYX S] \O[_S\ON# + SEKIV ":5;? / ZKQO] ">6@E *- ZKQO] ">6@E EY^KV WKbSW_W ZKQO] PY\ C8A RSX NRHPYINRL OJ] TJVWSRRJP 7RUPV QRW GRXQWIH# 8Y\W] XY^ MY_X^ON# %Y\W] XY^ MY_X^ON# VJWYQJW' CO]_WO] VSWS^ON ^Y + ZKQO] ZO\ UOc ]^KPP =IVXPIV ZMOO RQO\ ZO\]YXXOV' FI EGGISWIH JRU 3IVW AEOXI >IOIGWMRQV' ?A>?>B0; 0=3 183 B744C 4"<08; 033A4BB ^ WNY^&\PZ&\O]ZYX]O2WSMRSQKX'QY` ?LI 4RQVXOWEQWV ZMOO UIGIMYI EQ I%PEMO UISO\'QRWMJMGEWMRQ JURP :5;? ZLIQ WLI SURSRVEO MV UIGIMYIH&
>6@E S] KX O[_KV YZZY\^_XS^c OWZVYcO\ KXN >6@E 647 PS\W] K\O OXMY_\KQON ^Y KZZVc' ERO ZK\^SMSZK^SXQ 647 PS\W% K] M_\\OX^Vc MO\^SPSON Lc >6@Eh] @PPSMO YP 7[_KV @ZZY\^_XS^c% ]RKVV LO VS]^ON SX ^RO A\YZY]KV'
<3>C 5>A5 ?A>?>B0; BD1<8BB8>=
,*))3 e CO[_O]^ PY\ A\YZY]KV 5Y`O\ DROO^ ,*))9 e 5YX]_V^KX^ 6K^K KXN DSQXK^_\O DROO^ "CO[_S\ON =EH 8BB =@HCI F #CMJWJ KSVQW FVJ RSX NRHPYIJI NR XMJ TVSTSWFP QF\NQYQ TFLJ HSYRX'$ >6@E .*))4 "%#&($# */53 + YP + ERO >SMRSQKX 6OZK\^WOX^ YP E\KX]ZY\^K^SYX ">6@E# S] ]OOUSXQ Z\YPO]]SYXKV ]O\`SMO] PY\ ^RO Z\YTOM^ MYX^KSXON SX ^RO K^^KMRON ]MYZO YP ]O\`SMO]' ;P cY_\ PS\W S] SX^O\O]^ON SX Z\Y`SNSXQ ]O\`SMO]% ZVOK]O SXNSMK^O cY_\ SX^O\O]^ Lc ]_LWS^^SXQ K A\YZY]KV% A\YZY]KV(4SN DROO^ Y\ 4SN DROO^ K] SXNSMK^ON LOVYa' ERO NYM_WOX^] W_]^ LO -.<.478.- *6- ]_LWS^^ON SX KMMY\NKXMO aS^R ^RO VK^O]^ -EX]_V^KX^( GOXNY\ DOVOM^SYX 9_SNOVSXO] PY\ DO\`SMO] 5YX^\KM^]$g A5? B?428582 8=5>A<0C8>= 7?9;?77C;?9 D7CG;57D 4FC73F @8 EC3?DA@CE3E;@? A=3??;?9 @E:7C E:7 D7CG;57 H3D A@DE76 @? E:7 3?E;5;A3E76 BF3CE7C=I C7BF7DED 8@C AC@A@D3=D ?@ I7D 63E76 JJJJJJJJJJJJJJJJJJJJ E:C@F9: JJJJJDDJJJJJJJJJJJ ?VJUYFPNKNJI BJVZNHJW e DOO ^RO K^^KMRON DMYZO YP =SR&?VJUYFPNKNJI BJVZNHJW e ;P ]OVOM^ON% ^RO `OXNY\ DO\`SMO] PY\ \O[_S\ON A\O[_KVSPSMK^SYX 5VK]]SPSMK^SYX]' W_]^ WKUO ]_\O ^RK^ M_\\OX^ PSXKXMSKV SXPY\WK^SYX% SXMV_NSXQ VKLY\ \K^O]% Y`O\ROKN MYWZ_^K^SYX]% KXN PSXKXMSKV ]^K^OWOX^]% S] YX PSVO aS^R >6@Eh] @PPSMO YP 5ECC@II@ED ,K;@JI# ERS] SXPY\WK^SYX W_]^ LO YX PSVO PY\ ^RO FH@C< L 5SV FPP @YFPNKNHFXNSRW 1FWJI BJPJHXNSRW% ^RO ]OVOM^SYX ^OKW aSVV \O`SOa ^RO SXPY\WK^SYX ]_LWS^^ON KXN aSVV ]OVOM^ ^RO PS\W MYX]SNO\ON WY]^ [_KVSPSON ^Y ZO\PY\W ^RO ]O\`SMO] LK]ON YX ^RO Z\YZY]KV]' ERO ]OVOM^ON PS\W aSVV LO K]UON ^Y Z\OZK\O K Z\SMON Z\YZY]KV' ?OQY^SK^SYX] aSVV LO MYXN_M^ON aS^R ^RO PS\W ]OVOM^ON' 5SV F HSWX TPYW KN\JI KJJ HSRXVFHX% ^RO ]OVOM^ON `OXNY\ W_]^ RK`O K MY]^ KMMY_X^SXQ ]c]^OW ^Y ]_ZZY\^ K MY]^ ZV_] PSbON POO MYX^\KM^' ERS] ^cZO YP ]c]^OW RK] K TYL&Y\NO\ MY]^ KMMY_X^SXQ ]c]^OW PY\ ^RO \OMY\NSXQ KXN KMM_W_VK^SYX YP MY]^] SXM_\\ON _XNO\ S^] MYX^\KM^]' 7KMR Z\YTOM^ S] K]]SQXON K TYL X_WLO\ ]Y ^RK^ MY]^] WKc LO ]OQ\OQK^ON KXN KMM_W_VK^ON SX ^RO `OXNY\h] TYL&Y\NO\ KMMY_X^SXQ ]c]^OW' @YFPNKNHFXNSR 1FWJI BJPJHXNSR ( ;S[ 1NI e F]O 5YX]_V^KX^(GOXNY\ DOVOM^SYX 9_SNOVSXO]' DOO 4SN DROO^ SX]^\_M^SYX] PY\ KNNS^SYXKV SXPY\WK^SYX' 8Y\ B_KVSPSMK^SYX CO`SOa(=Ya 4SN ]OVOM^SYX]% ^RO ]OVOM^SYX ^OKW aSVV \O`SOa ^RO Z\YZY]KV] ]_LWS^^ON' ERO `OXNY\ ^RK^ RK] WO^ O]^KLVS]RON [_KVSPSMK^SYX ^R\O]RYVN KXN aS^R ^RO VYaO]^ LSN aSVV LO ]OVOM^ON' 1JWX EFPYJ e F]O 5YX]_V^KX^(GOXNY\ DOVOM^SYX 9_SNOVSXO]% DOO 4SN DROO^ ;X]^\_M^SYX] LOVYa PY\ KNNS^SYXKV SXPY\WK^SYX' ERO LSN KWY_X^ S] K MYWZYXOX^ YP ^RO ^Y^KV Z\YZY]KV ]MY\O% XY^ ^RO NO^O\WSXSXQ PKM^Y\ YP ^RO ]OVOM^SYX' ;S[ 1NI "XY [_KVSPSMK^SYX] \O`SOa \O[_S\ON e XY Z\YZY]KV \O[_S\ON'# 183 B744C 8=BCAD2C8>=B 4SN DROO^"]# K\O VYMK^ON K^ ^RO OXN YP ^RO DMYZO YP DO\`SMO]' D_LWS^ LSN ]ROO^"]# aS^R ^RO Z\YZY]KV% ^Y ^RO O"WKSV KNN\O]]0 :5;?%=7"&=O]ZYX]O2WSMRSQKX'QY`' 8KSV_\O ^Y MYWZVc aS^R ^RS] Z\YMON_\O WKc \O]_V^ SX cY_\ LSN LOSXQ \OTOM^ON /975 P\YW MYX]SNO\K^SYX# &$') 9.:.9<.: ;1. 9201; ;7 9.3.,; *6> *6- *44 +2-:' +"-/*%-.'(+ $'"-/%- "&-%%)%*/ >6@E KXN 3575 M\OK^ON K AK\^XO\]RSZ 5RK\^O\ 3Q\OOWOX^ aRSMR O]^KLVS]RO] Q_SNOVSXO] ^Y K]]S]^ >6@E KXN 5YX]_V^KX^] SX ]_MMO]]P_V ZK\^XO\SXQ' 4Y^R ^RO 5YX]_V^KX^ KXN >6@E A\YTOM^ >KXKQO\ K\O \OWSXNON ^Y \O`SOa ^RO ()+)# ,*-/.0>@;3>?67= )60>@3> (5>33:3;@ 0;2 0>3 0?832 @< 4<993?<9A@7<; 0;2 <@63> =><132A>3? 0;2 5_SNKXMOh] 1<;@07;32 @63>37;$ PROPOSAL REQUIREMENTS Proposals must be submitted for this project electronically. Proposal submittal requirements are listed in PART IV – INSTRUCTION FOR SUBMITTING PROPOSALS at the following link Selection Guidelines for Service Contracts FINANCIAL REQUIREMENTS FOR NON-PREQUALIFIED VENDORS Financial Requirements for Non‐Prequalified Consultants/Vendors E-VERIFY REQUIREMENTS E-Verify is an Internet based system that allows an employer, using information reported on an employee’s Form I-9, Employment Eligibility Verification, to determine the eligibility of that employee to work in the United States. There is no charge to employers to use E-Verify. The E- Verify system is operated by the Department of Homeland Security (DHS) in partnership with the Social Security Administration. E-Verify is available in Spanish. The State of Michigan is requiring, under Public Act 200 of 2012, Section 381, that as a condition of each contract or subcontract for construction, maintenance, or engineering services that the pre- qualified contractor or subcontractor agree to use the E-Verify system to verify that all persons hired during the contract term by the contractor or subcontractor are legally present and authorized to work in the United States. Information on registration for and use of the E-Verify program can be obtained via the Internet at the DHS Web site: http://www.dhs.gov/E-Verify. The documentation supporting the usage of the E-Verify system must be maintained by each consultant and be made available to MDOT upon request. It is the responsibility of the prime consultant to include the E-Verify requirement documented in this NOTIFICATION in all tiers of subcontracts. DIGITAL SIGNATURE OF CONTRACTS On January 4, 2018, Contract Services Division implemented the use of CoSign as the exclusive software for digitally signing all consultant contracts and consultant contract related documents. All other digital signing methods are no longer accepted. Prior to using CoSign, all external partners must apply for a free digital signature user account by submitting a MDOT Digital Signature Certificate Request Form. MDOT INSURANCE UPDATED 3.9.17 At a minimum, the insurance types and limits identified below, may be required from the selected consultant, prior to contract award. Required Limits Additional Requirements Commercial General Liability Insurance Minimal Limits: Consultants must have their policy endorsed $1,000,000 Each Occurrence Limit to add “the State of Michigan, its $1,000,000 Personal & Advertising Injury Limit departments, divisions, agencies, offices, $2,000,000 General Aggregate Limit commissions, officers, employees, and $2,000,000 Products/Completed Operations agents” as additional insureds Automobile Liability Insurance Minimal Limits: $1,000,000 Per Occurrence Workers' Compensation Insurance Minimal Limits: Waiver of subrogation, except where waiver is Coverage according to applicable laws prohibited by law. governing work activities. Employers Liability Insurance Minimal Limits: $500,000 Each Accident $500,000 Each Employee by Disease $500,000 Aggregate Disease Professional Liability (Errors and Omissions) Insurance Minimal Limits: $1,000,000 Per Claim The Insurer shall provide at least thirty (30) days written notice of cancellation. The Prime Consultant will be responsible to verify subconsultant(s) compliance with MDOT’s insurance requirements. Michigan Department of Transportation SCOPE OF SERVICE FOR SPECIALTY SERVICES Autonomous Vehicle Mobility Solutions North American International Auto Show (NAIAS) 2020 Michigan Mobility Challenge Revised 7/15/2019 CONTROL SECTION: 84900 JOB NUMBER: TBD PROJECT LOCATION: The project is located on multiple routes within Wayne County and the City of Detroit. PROJECT DESCRIPTION: The NAIAS 2020 Michigan Mobility Challenge (NMMC) is calling upon industry innovators to propose new and dynamic technology deployments that embody how autonomous vehicle (AV) technology can transform how we live, work, and play. As part of the NMMC, the Michigan Department of Transportation (MDOT) with the Michigan Economic Development Corporation’s (MEDC) PlanetM program and the Governor’s Office is soliciting proposals for two new autonomous vehicle demonstrations (referred to herein as AV Mobility Solutions) for use during the June 2020 North American International Auto Show (NAIAS) in Detroit, Michigan. The State is seeking proposals that provide and demonstrate innovative solutions and cutting- edge technologies that can showcase autonomous vehicle capabilities. AV Mobility Solutions that provide innovative, dynamic AV technology deployments in response to this RFP. The demonstration will provide autonomous transportation for NAIAS attendees to places of interest in downtown Detroit and for select attendees from the Detroit Metropolitan Wayne County Airport (DTW) to the City of Detroit. Based upon available funding, MDOT anticipates selecting multiple solutions. The NMMC will further solidify the NAIAS and the Motor City as the preeminent environment for new transportation solutions. More information can be found at the project website: www.mi.gov/NAIASMobilityChallenge Revised Final Posted Scope: 7/15/2019 1 ANTICIPATED START DATE: July 2019 ANTICIPATED COMPLETION DATE: July 2020 PRIMARY PREQUALIFICATION CLASSIFICATION(S): N/A SECONDARY PREQUALIFICATION CLASSIFICATION(S): N/A DBE REQUIREMENT: There is no DBE requirement for this project. PREFERRED QUALIFICATIONS AND CRITERIA (FOR NON-CLASSIFIED SERVICES): As minimum qualifications, the Proposer’s Team must show previous experience, proving they are capable to plan, test, execute, and deliver the AV Mobility Solution services being proposed. The Proposer’s Team must be able to display AV experience on public roadways and integration with a mobile application. Safety drivers/concierge shall be qualified individuals with the appropriate motor vehicle operating endorsement. Revised Final Posted Scope: 7/15/2019 2 MDOT CONTRACT MANAGER: Elise Feldpausch, P.E. Connected Vehicle Specialist ITS Program Office – MDOT 8885 Ricks Rd. Lansing MI, 48909 Cell: 517/388-2371 Email: [email protected] MDOT PROJECT MANAGER: Michele R. Mueller Sr. Project Manager Connected and Automated Vehicles 18101 W. Nine Mile Road Southfield, MI 48075 [email protected] 248-431-1443 All correspondence related to this Request for Proposals should be directed to Elise Feldpausch and Michele Mueller using the contact information provided above. GENERAL INFORMATION: The AV Mobility Solution provider shall furnish all services and labor necessary to plan, test, conduct, and complete the services described herein. The AV Mobility Solution provider shall also furnish all materials, equipment, supplies, and incidentals necessary to perform the services (other than those designated in writing to be furnished by MDOT), and check and/or test the materials, equipment, supplies, and incidentals as necessary in carrying out this work. The services shall be performed to the satisfaction of MDOT consistent with applicable professional standards. Moovit Inc. (“Moovit”)A vendor has been is being selected, through a separate RFP, to provide a customized Mobility as a Service (MaaS) application to integrate the AV Mobility Solution services within a single interface, hereby called the “NMMC application”. AV Mobility Solution providers selected as part of this RFP will be required to integrate with the NMMC application. The NMMC application functional requirements are provided in Attachment C for reference. The Moovit TOD (Transit on Demand) Application Programming Interface (API) is the preferred method of integration, as provided in Attachment D. Other integration methodologies may be proposed by AV Mobility Solution providers for consideration. The AV Mobility Solution provider shall comply with all applicable federal and state laws, rules, and regulations. The AV Mobility Solution provider shall perform field operations in accordance with MIOSHA regulations and accepted safety practices. The AV Mobility Solution provider staff shall conduct themselves with professionalism in carrying out their duties. Revised Final Posted Scope: 7/15/2019 3 The AV Mobility Solution Provider will notify the MDOT Project Manager, in writing, prior to any personnel changes from those specified in the AV Mobility Solution provider’s original approved proposal. Any personnel substitutions are subject to review and approval of the MDOT Project Manager. REQUIRED MDOT GUIDELINES AND STANDARDS: Work shall conform to current MDOT, FHWA, USDOT, NHTSA, and AASHTO practices, guidelines, policies, and standards. AV Mobility Solution providers must adhere to Michigan Public Act No. 332 of 2016 - http://www.legislature.mi.gov/documents/2015-2016/publicact/pdf/2016-PA-0332.pdf. MANDATORY PRE-PROPOSAL WORKSHOP A mandatory Pre-Proposal Workshop is being held on June 17, 2019, from 8:30 AM to 5:00 PM at the Shinola Hotel in Detroit, MI. Attendance by interested teams (at least one member of the team) is required at the Pre-Proposal Workshop. Please register for the Pre-Proposal Workshop using the following link: https://planetm.connect.space/mobilitychallenge . The NMMC application vendor will also be in attendance to discuss the application interface. BACKGROUND INFORMATION As we restore Michigan’s existing infrastructure, it is essential that our state continues to be a global leader in developing the infrastructure of tomorrow. Smart infrastructure pushes the future of mobility by creating safe and seamless travel experiences around our cities, adding a new chapter to Michigan’s storied automotive heritage. Staying true to this commitment, our state’s transportation and economic development leaders have developed this NMMC to showcase the potential of autonomous transportation systems in Detroit during the 2020 NAIAS. OVERVIEW The NMMC AV demonstration will be showcasing cutting-edge technologies by providing new, innovative mobility solutions between downtown Detroit and destinations of interest such as the Detroit Metropolitan Wayne County Airport (DTW), Cobo/TCF center, hotels, restaurants and local event venues. There will not be a fee charged to riders as part of the NMMC The NMMC will include AV demonstration trips within the following two operational domains: 1. Airport Shuttle (See Figure 1) - The Airport Shuttle will operate from DTW to a centralized location in downtown Detroit during press days of the 2020 NAIAS. The Airport Shuttle will be limited to select individuals who have been provided a unique code for use within the NMMC application. 2. Downtown Detroit Circulator (See Figure 2) – The Downtown Detroit Circulator will operate within a predefined boundary. The downtown Detroit points of interest may have predetermined locations and trip frequency, or services may be provided on-demand by the AV Mobility Solution providers. The Downtown Detroit Circulator will be open to 2020 NAIAS attendees. Services for each of the two operational domains will be evaluated and selected separately. Revised Final Posted Scope: 7/15/2019 4 Therefore, proposals must identify the operational domain(s) being submitted on and complete the appropriate Bid Sheet(s) for consideration. Revised Final Posted Scope: 7/15/2019 5 Below is the framework envisioned for each of the operational domains. AV Mobility Solution providers should clearly identify the service being proposed within the operational domain, how it provides innovative solutions within the framework of the challenge and note any additional functionality or cutting-edge technologies that could be demonstrated if the project requirements were adjusted. Figure 1 – Airport Shuttle OPERATIONAL DOMAIN 1 – Airport Shuttle Provide minimum Level 3 AV services per the SAE J3016 Levels of Driving Automation for select NAIAS media attendees from DTW to the City of Detroit. Please describe how the proposed AV service meets SAE Level 3 or greater driving automation. o Pick-up locations at DTW will be defined as directed by MDOT and drop off locations within the City of Detroit will be defined by the rider. o The focus of this operational domain is to transport riders from DTW to the City of Detroit. However, trips from the City of Detroit to DTW is an option. Please indicate if the proposed service is one- or two-way. Revised Final Posted Scope: 7/15/2019 6 Route Options: o Route 1: . DTW pick-up location (TBD) to John Dingell Dr to Merriman Rd to eastbound I-94 to John R St (Exit 215) to Palmer St to M-1 to City of Detroit drop-off location as defined by the rider. o Route 2: . DTW pick-up location (TBD) to John Dingell Dr to Merriman Rd to eastbound I-94 to US-12 (Exit 210) to City of Detroit drop-off location as defined by the rider. o Other routes may be proposed by AV Mobility Solution providers for consideration. The “Airport Shuttle” is a term being used to describe transportation service from DTW to the City of Detroit. The term is not meant to define the vehicle type used as part of the AV Mobility Solution. The Airport Shuttle can include any AV that has the capacity to carry one or more riders. AVs may be required to navigate airport roadways to/from a defined pick-up/drop-off location. Traffic signals, pavement markings, and signing within the route segments will be provided in their existing condition. MDOT is evaluating potential infrastructure improvements before commencement of the NMMC. MDOT will coordinate infrastructure improvements with selected NMMC providers. o Please identify any specific infrastructure improvements that are requested as part of proposed service, and if they are optional or mandatory. Operational period will occur during NAIAS media/press days (June 8-11, 2020). Expected number of trips throughout the service period is anticipated to be approximately 1,000. Please identify the capacity of the proposed service, such as number of vehicles in fleet, number of seats/riders per vehicle, vehicle type, number of trips, etc. Service will operate on-demand. Pre-scheduled trips and advance reservation services are not required. Revised Final Posted Scope: 7/15/2019 7 Figure 2 - Downtown Detroit Circulator Boundaries Revised Final Posted Scope: 7/15/2019 8 OPERATIONAL DOMAIN 2 – Downtown Detroit Circulator Provide minimum SAE Level 3 AV services per the SAE J3016 Levels of Driving Automation for NAIAS attendees and the general public within a defined boundary made up of Warren Ave (to the North), I-75 and I-375 (to the East), Jefferson Avenue (to the South), and M-10 (to the West). Please describe how the proposed AV service meets SAE Level 3 or greater driving automation. o The focus of this operational domain is to transport riders to/from the Cobo/TCF Center and points of interest such as but not limited to hotels, restaurants, carpool lots, and local event venues. Downtown Detroit Circulator can be provided as a fixed route or point-to-point service. Please indicate the type of service being proposed. Traffic signals, pavement markings, and signing within the defined boundary will be provided in their existing condition. MDOT is evaluating potential infrastructure improvements before commencement of the NMMC. MDOT will coordinate infrastructure improvements with selected NMMC providers. o Please identify any specific infrastructure improvements that are requested as part of proposed service, and if they are optional or mandatory. Operational period is anticipated to occur from June 6 through June 21 of 2020 between 8:00A.M. to 12:00A.M. daily. AV Mobility Solution providers are not expected to operate during the entire hours of operation. Please identify the capacity of the proposed service, such as number of vehicles in fleet, number of seats/riders per vehicle, vehicle type, number of trips, etc. Service will operate on-demand; pre-scheduled trips and advanced reservation services are not required. APPLICATION INTERFACE Each selected team will be required to interface with the NMMC application, provided by Moovit, to provide a seamless rider experience. The functional requirements of the NMMC application are provided in Attachment C for reference. The Moovit TOD API is the preferred method of integration, as provided in Attachment D. Other integration methodologies may be proposed by AV Mobility Solution providers for consideration. The NMMC application vendor will be available at the Pre-Proposal Workshop to answer questions and discuss the application interface. Outside of the workshop, NMMC application questions should be submitted to the MDOT Project Manager during the RFP process. It is anticipated that regular project coordination meetings will be scheduled to facilitate team communications. CONNECTED VEHICLES While AV technology is the focus for the NMMC demonstration, the ability to showcase connected vehicles technologies that demonstrates the sharing of transportation information between vehicles, roadways, infrastructure, and other devices is encourage. SUSTAINABILITY While operation during future events beyond June 2020 is not included, teams should demonstrate and consider how their solutions could be sustained and fit within the region’s Revised Final Posted Scope: 7/15/2019 9 mobility ecosystem absent an ongoing state subsidy. Sustainability may include an event-based or fully operational system. SUMMARY REPORT All teams must include a Michigan-based academic institution to provide a summary report of the services provided as part of the NMMC. The summary report should document the services provided, use of innovative technologies, testing results, operational summary, successes of the demonstration against the operational objectives, and the sustainability of the services moving forward. INNOVATIONS Describe innovations being proposed as part of the service that will contribute to and support the NMMC, NAIAS, and Motor City as the preeminent environment for new transportation solutions. Innovations may include, but not be limited to: First-of-its-kind technology, application, and/or demonstration Ability to expedite implementation Ability to provide enhanced user experience Partnership opportunities not included in bid (staff, equipment, research, etc.) ANTICIPATED SERVICE SCHEDULE The NMMC AV demonstration will occur during the 2020 NAIAS, for a sixteen-day period in June of 2020. More specifically, the Airport Shuttle will operate during press days from June 8 to June 11, 2020 while the Downtown Detroit Circulator will operate from June 6 to June 21, 2020. The below table provides the anticipated timeline for the NMMC AV demonstrations. Proposals should identify an implementation plan with the ability to meet major milestones. Milestone Date Anticipated Contract Execution September 2019 AV Demonstration Design, Programming, and Development September 2019 – April 2020 Final Road Testing (Group 1)* April 2020 – May 2020 Final Road Testing (Group 2)* May 2020 Production Ready May 28, 2020 Airport Shuttle Operational Period June 8 to June 11, 2020 Downtown Detroit Circulator Operational Period June 6 to June 21, 2020 *Groups to be defined following selection. To be based on complexity of service being provided. AV MOBILITY SOLUTION PROVIDER RESPONSIBILITIES: A. Meet with MDOT to review project, contact persons, and review relevant information. Provider should review and clarify project issues, data needs, and sequence of events and team meetings that are essential to complete testing by the established deadline. B. Provide solutions to unique problems that may arise during the project. C. Attend project and stakeholder meetings as directed by the MDOT Project Manager D. Work with the NMMC application provider to deliver complete solution E. Develop Implementation Plan F. Develop Testing Plan G. Develop Standard Operating Procedure (SOP) Revised Final Posted Scope: 7/15/2019 10 H. Develop Maintenance Plan I. Conduct Testing J. Perform operations during defined operational period K. Partner with an academic institution to provide a summary report of the operational AV demonstrations. L. The MDOT Project Manager shall be the official MDOT contact person and shall be made aware of all communications regarding this project M. Submit a monthly project progress report N. AV and associated equipment storage, maintenance, gas/charging, etc. O. Additional responsibilities are provided within the AV Mobility Solution Requirements (Attachment A) MDOT RESPONSIBILITIES: MDOT responsibilities will include: A. Schedule and/or conduct the following: 1. Project related meetings 2. Stakeholder engagement meetings (DTW, City of Detroit, Wayne County, NAIAS) B. Make decisions or provide input to support resolving issues C. Review and approve all budget, schedule, and design aspects D. Review and approve all external communications E. MDOT shall provide relevant documentation needed to complete the tasks assigned and approved by the MDOT Project Manager F. Administer oversight of testing and operations SCORING POINT ASSIGNMENT Total Points = 160 Points Proposed Selection Criteria and Total Possible Points: Understanding of Services – 30 points Identify the operational domain being submitted for Describe desire to be included in the NMMC Describe the level of autonomy that will be provided Describe high-level quality control plan for development, testing, and operational phases Technical Approach to the Challenge – 40 points Describe the service that will be offered: . Ridership capacity, description, level of autonomy, and limitations of each AV Mobility Solution type (if applicable) . Number of each AV Mobility Solutions type provided . Operational design domain limitations . Other considerations Provide a high-level implementation plan displaying capability to deliver the AV demonstration in advance of the June 2020 NAIAS Describe the approach to cybersecurity and what steps will be taken to restrict access from outside parties Revised Final Posted Scope: 7/15/2019 11 Describe any required infrastructure elements necessary that have not been identified in this RFP Describe any existing contracts and/or agreements that may impact, limit, or prohibit involvement in this demonstration. Provide a response to each requirement within the AV Mobility Solution Requirements (see Attachment A) and include as an appendix to the proposal (this will not count towards the proposal page limit) . Response should indicate ability to meet the requirement . Requirements are preferred; inability to meet requirement will not result in disqualification Describe First-of-its-kind technology, applications, and/or demonstrations that will be showcased. Qualifications of Team – 20 points Provide an organizational chart of the key personnel who will be involved in this proposed project, including the structure of the project team and any sub vendors. At a minimum, Contract Administrator, Project Manager, Service Manager, and Quality Manager need to be identified. Include resumes of the key staff and any sub vendor showing applicable qualifications to serve in the subject role, experience on similar projects or products, years of overall experience, and years with the firm Complete Attachment B – Proposing Team Questions Worksheet as an appendix to the proposal (this will not count towards the proposal page limit) Location – 5 points Indicate the percentage of work that will be performed in Michigan. Price – 40 points Provide a project bid on attached bid sheet to deliver all services in turnkey fashion. Bid Price Per Trip (BPPT) = (Bid / Total Number of trips being provided) + $1.00 Scoring Formula: (Lowest BPPT) / (BPPT ) * points assigned Presentation-25 points Presentations may be requested to those that receive 65 points or more. This score will be added to the original score from the short-listing to determine the most qualified consultant./vendor. Revised Final Posted Scope: 7/15/2019 12 AV MOBILITY SOLUTION PROVIDER PAYMENT - Milestone: Compensation for this project shall be on a milestone basis. Compensation shall be divided into payments for the successful completion of a portion of the services (deliverables) as identified below. Deliverables are subject to MDOT review and revisions by the NMMC AV Mobility Solution provider. Milestone Milestone Event Description Payment Implementation Plan Identify project tasks, including inputs, approach and outputs, constraints and critical path items. Develop Work Breakdown Structure (WBS) in chart format illustrating tasks, sub-tasks, predecessors, and deliverables on a timeline. 10% Systems Plan Provide detailed plan of the AV Mobility Solution components. Describe physical, functional, and content characteristics of external interfaces to the system, and the responsibilities of the organizations on both sides of the interface. Risk Management Plan Utilize NIST Guide for Conducting Risk Assessments (Special Publication 800-30 Revision 1) Identify risks and review conformance to AV operating rules and MIOSHA regulations. Assess the relative level of risk as either: likely, probable, improbable, and impossible. Identify risk mitigation and develop Safety Plan. Define methods for monitoring risks. Perform a Preliminary Hazard Assessment for the autonomous vehicle operations. The 10% assessment will identify apparent hazards, assess the severity of potential accidents that could occur involving the hazards, and identify safeguards for reducing the risks associated with the hazards Standard Operating Identify operations, safety, and security Procedures (SOP) procedure and processes as well as handling of exceptions, emergencies and recovery in a variety of scenarios. Clearly distinguish the roles and responsibilities of MDOT, NMMC Application, and AV Mobility Solution Revised Final Posted Scope: 7/15/2019 13 Milestone Milestone Event Description Payment Provider as part of the SOP. Maintenance Plan Describe routine and emergency maintenance strategies, as well as a cleaning schedule and strategies for keeping the interior clean. Testing Plan Develop testing plan that includes the approach, methodology, assumptions, risks, contingency plan, schedule, testing environment, and a testing checklist. 5% Clearly distinguish the roles and responsibilities of MDOT, NMMC application, and AV Mobility Solution provider. Road Testing Conduct pre-test meeting. Conduct route testing without passengers for chosen operational domain. 20% Conduct route testing with passengers for chosen operational domain. Operational Period Conduct pre-operations meeting. Perform operations associated with 50% operational domain and according to SOP and Risk Management Plan. Summary Report Provide Summary Report documenting the services provided, use of innovative technologies, testing results, operational 5% summary, successes of the demonstration against the operational objectives, and the sustainability of the services moving forward. The MDOT Project Manager may authorize payment if a milestone is delayed due to circumstances beyond the AV Mobility Provider’s control. All billings for services must be directed to the Department and follow the current guidelines. The latest copy of the "Professional Engineering Service Reimbursement Guidelines for Bureau of Highways" is available on MDOT's website. This document contains instructions and forms that must be followed and used for billing. Payment may be delayed or decreased if the instructions are not followed. Payment for Services rendered shall not exceed the maximum amount unless an increase is approved in accordance with the contract. Typically, billings must be submitted within 60 days after the completion of services for the current billing. The final billing must be received within 60 days of the completion of services. Refer to your contract for your specific contract terms. Revised Final Posted Scope: 7/15/2019 14 CONSULTANT BID SHEET - MILESTONE OPERATIONAL DOMAIN 1 – AIRPORT SHUTTLE It is required that this bid sheet be completed and submitted with the response to the Request for Proposal. All entries on this page must be handwritten in ink or computer generated. When price is a component of the selection process it will be considered along with several other selection criterion for determining overall score. Priced proposal costs will be required after selection, in accordance with the MDOT Priced Proposal Guidelines (Guidelines). Note: MDOT reserves the right to reject any or all bids. PROJECT DESCRIPTION: MILESTONE/DELIVERABLES PRICE Milestone/Deliverable, Task 1 (10%) Total: $______Implementation and Systems Plan Milestone/Deliverable, Task 2 (10%) Total: $______Risk Mgmt, SOP and Maintenance Plans Milestone/Deliverable, Task 3 (5%) Total: $______Testing Plan Milestone/Deliverable, Task 4 (20%) Total: $______Road Testing Milestone/Deliverable, Task 5 (50%) Total: $______Operational Period Milestone/Deliverable, Task 6 (5%) Total: $______Summary Report TOTAL BID PRICE: $______(All Milestones/Deliverables of Project) ------ Consultant Name: Consultants Authorized Legal Signer: Consultant Address: Date: Revised Final Posted Scope: 7/15/2019 15 CONSULTANT BID SHEET - MILESTONE OPERATIONAL DOMAIN 2 – DOWNTOWN DETROIT CIRCULATOR It is required that this bid sheet be completed and submitted with the response to the Request for Proposal. All entries on this page must be handwritten in ink or computer generated. When price is a component of the selection process it will be considered along with several other selection criterion for determining overall score. Priced proposal costs will be required after selection, in accordance with the MDOT Priced Proposal Guidelines (Guidelines). Note: MDOT reserves the right to reject any or all bids. PROJECT DESCRIPTION: MILESTONE/DELIVERABLES PRICE Milestone/Deliverable, Task 1 (10%) Total: $______Implementation and Systems Plan Milestone/Deliverable, Task 2 (10%) Total: $______Risk Mgmt, SOP and Maintenance Plans Milestone/Deliverable, Task 3 (5%) Total: $______Testing Plan Milestone/Deliverable, Task 4 (20%) Total: $______Road Testing Milestone/Deliverable, Task 5 (50%) Total: $______Operational Period Milestone/Deliverable, Task 6 (5%) Total: $______Summary Report TOTAL BID PRICE: $______(All Milestones/Deliverables of Project) ------ Consultant Name: Consultants Authorized Legal Signer: Consultant Address: Date: Revised Final Posted Scope: 7/15/2019 16 RFP Attachments ATTACHMENT A – Requirements Table; MS Excel Spreadsheet {Required} ATTACHMENT B – Proposing Team Questions; MS Excel Spreadsheet {Required} ATTACHMENT C – Application Functional Requirements; PDF {For Reference Only} Revised Final Posted Scope: 7/15/2019 17 Attachment A Instructions: Proposing Teams shall complete the non-shaded cells on this document and return them Y/N = Yes or no response only. Select from drop down list. as part of their proposal, as instructed in the RFP. The requirements are preferred and if not met will Y = proposed solution satisfies this requirement not result in disqualification. If Proposing Team cannot meet the requirement as written, but meets N = proposed solution does not satisfy this requirement functionality using another method, response should describe. Comments Section – use only to clarify response if necessary (maximum 250 characters per response) Use appropriate Operational Domain Y/N column if proposing on one or both operational domains. Company Name Completed By Phone Date: Email Operational Operational General Domain 1 Domain 2 Comments Y/N Y/N GEN 1 Fleet of deployed vehicles is managed by AV service providers Supply a trained concierge/safety driver that is always on-board each AV Mobility GEN 2 Solution vehicle during operation GEN 3 Keep AV trips within the physical operational domains boundaries/routes GEN 4 Operate at a Level 3 Autonomy or higher as defined by SAE. Ability to travel and transport riders from Detroit Metro Airport (DTW) to GEN 5 Downtown Detroit (if proposal is for Operational Domain 1) Ability to travel and transport riders to/from points of interest such as hotels, restaurants, and local event venues within Downtown Detroit Circulator boundaries (if proposal is for Operational Domain 2) Transport riders along access corridors shared with transit buses and emergency GEN 6 vehicles with public traffic crossing signalized intersections, a light rail crossing, and pedestrian traffic. Operate in mixed traffic conditions on public roadways within the prevailing GEN 7 weather conditions expected for the Detroit Metropolitan Area in June. Vendor is responsible for all coordination, permitting, insurance, special license GEN 8 plates, and fees to operate within the operational domain(s). Personally Identifiable Information (PII) that is entered by riders shall be secure and GEN 9 protected GEN 10 Trip data shall not include PII AV Mobility Solutions that operate with a fixed route in Operational Domain 2 GEN 11 shall allow boarding and alighting riders safely at predefined stop locations that allows mobility impaired individuals to access and egress the vehicle. For Operational Domain 2 provide a seating area for handicapped/wheelchair equipped via movement of the seat into a suitable stowage configuration or via a GEN 12 separate floor area dedicated for this function. This can be a designated vehicle within Proposing Team’s fleet. Application Interface / Data Feed Provide a variety of static data fields to the NMC application, including but not AI 1 limited to, vehicle type, capacity, description, image, etc Interface with NMC application using GTFS and update near real-time with GTFS AI 2 Real-time Communicate service availability status in order to display available options in the AI 3 NMC application. Make trip data available through an API for performance measurement and AI 4 analytics. Trip data shall include, but not be limited to, origin, destination, start time, finish time, mode, and date AI 5 Provide a list of preferred questions to be included in the NMC application for Provide promotional material consisting of text and images to NMC application AI 6 vendor Work with MDOT management team to establish content and guidelines for AI 7 including promotional material in the NMC application Vehicle Requirements AV Mobility Solution shall allow for vehicle decal with space for NMC AV 1 identification The interior and exterior of the AV Mobility Solution shall be kept clean, meaning AV 2 remain free of vandalism, clutter, bodily fluids, hazardous materials, and other contaminates. AV Mobility Solutions shall have 4G or better wireless connectivity with the ability AV 3 to stream ridership data and other operation and maintenance data in real-time to the remote location (Operations Center). AV Mobility Solution shall detect, identify, and react to moving and non-moving roadway users and obstructions, include vulnerable road users and non-permanent AV 4 roadway features (i.e., construction cones). Vulnerable road users would include pedestrians, scooterists, and cyclists. Vehicles shall be capable of Route Deviation (The ability to deviate from the AV 5 specified route when necessary and safe within the defined operational domain boundary) Vehicles shall be capable of Crash Avoidance (The ability to detect an imminent AV 6 collision and respond to avoid the collision or minimize the impact) Vehicles shall be capable of Detection Arbitration (The ability to arbitrate between AV 7 detected concurrent regulatory signs, pavement markings, traffic signals, human traffic control gestures, and object detections) Vehicles shall be capable of Uncertainty in the Course of Action (The ability to AV 8 decrease speed and pull over, if safe, when there is uncertainty regarding which action to take or request the concierge/safety driver to intervene) Vehicles shall be capable of Law Following – Open Traffic Environment (The AV 9 ability to detect/react to other objects, vehicles, bicycles, scooters, pedestrians, light rail on the controlled access roadway) Vehicles shall be capable of Law Following – Regulatory (Have knowledge of and AV 10 the ability to follow local, state, and federal driving laws; detect and understand regulatory signs, pavement markings, and traffic signals) Vehicles shall be capable of Law Following – Temporary Traffic Control (The AV 11 ability to detect and respond to detours, human traffic control gestures, and other temporary changes in traffic pattern) Vehicles shall be capable of performing the traffic maneuvers required to safely and AV 12 efficiently operate within the respective operational domain AV Mobility Solution system shall be designed to be resistant to attempted access AV 13 by outside parties for modifying system operations or otherwise accessing data governing the system. If the AV Mobility Solution is a hybrid or electric vehicle, then it shall emit a noise AV 14 that adheres to NHTSA’s minimum sound requirements for hybrid and electric vehicles. In-vehicle messaging shall include at least one screen with the capability to display data and video such as route map, local attractions, etc. Minimum size is to be at AV 15 least 7.9 inches (diagonal). The screen or screens should be easily viewable by all riders. The basic default message on the screen shall be the route map. The default language shall be English. AV Mobility Solution shall have an override and/or shut off button, so operations AV 16 staff can safely stop and turn off the AV Mobility Solution. AV Mobility Solution shall have a way for the concierge/safety driver to contact AV 17 the remote operations personnel in event of an issue. The suggested method is an emergency button and/or intercom system. AV 18 AV Mobility Solution shall be climate controlled for rider comfort AV Mobility Solution shall have a first aid kit, fire extinguisher, and printed AV 19 procedure to follow in case of emergency. AV Mobility Solution provider shall maintain the latest vehicle software update at AV 20 all times at no additional cost to NMC Operating Requirements Operate between 8:00 AM and 12:00 AM (midnight) for the Downtown Detroit OP 1 Circulator (if proposal is for Operational Domain 2) AV Mobility Solution shall have the ability to have a human take manual control OP 2 when deemed necessary Maintain an Operations Center responsible for overseeing the AV Mobility OP 3 Solution operations and monitoring AV Mobility Solution Ability to send origin/destination suggestions if original locations are close but not OP 4 reachable OP 5 Provide estimated time of AV Mobility Solution arrival at origin or fixed stop OP 6 Update estimated time until vehicle arrival at origin in near real-time OP 7 Provide updated trip times while trip is in progress OP 8 Provide estimated arrival time of destination in local time zone format OP 9 Receive trip on-demand requests from NMC application via agreed format OP 10 Provide ability to send trip request response Do not accept a schedule request if either origin or destination is outside of OP 11 operational domains Provide updates to NMC application if changes in scheduling services occur for any OP 12 reason. This can include traffic, autonomous failure, etc. which result in changes such as schedule changes, service disruptions, detours, delays, cancelation, etc OP 13 Provide vehicle specific access instructions/requirements if necessary OP 14 Alert NMC application if trip goes outside of operational domain Provide updates to NMC application of trip milestones which can be automated or OP 15 manually entered Trip milestones include, but are not limited to, AV Mobility Solution arrival at origin, rider is now in the AV Mobility Solution, AV Mobility Solution has arrived OP 16 at destination, rider has completely exited the AV Mobility Solution, trip is complete OP 17 Provide notification to rider if vehicle becomes unable to reach destination OP 18 Allow rider to end trip early and exit vehicle in safe location Capacity of Proposed Service CAP 1 Number of vehicles in fleet CAP 2 Number of seats/riders per vehicle CAP 3 Frequency of trips CAP 4 Total number of hours of operation CAP 5 Total days of operations CAP 6 Time range of operation CAP 7 Minimum number of vehicles in operation CAP 8 Number of trips per day CAP 9 Number of riders per day Total number of trips being provided during proposed service (to be used in bid CAP 10 pricing formula) CAP 11 Type of vehicle CAP 12 Operational limits such as required down time for maintenance, charging, refueling Attachment B Instructions: Proposing Teams shall complete the non-shaded cells on this document and return them as part of their proposal, as instructed in the RFP. Proposing Teams must provide a detailed response to each question. Attach any supplemental information and appropriately reference within your response. Information Sought Proposing Team’s Response Contact Information Proposing Team’s sole contact person during the RFP process. Include name, title, address, email, and phone number. Person authorized to receive and sign a resulting contract. Include name, title, address, email, and phone number. Company Background Information Legal business name and address. Include business entity designation, e.g., sole proprietor, Inc., LLC, or LLP. What state was the company formed in? Phone number Website address Number of years in business and number of employees Legal business name and address of parent company, if any Has there been a recent change in organizational structure (e.g., management team) or control (e.g., merger or acquisition) of your company? If the answer is yes: (a) explain why the change occurred and (b) how this change has affected your company. Discuss your company’s history. Has growth been organic, through mergers and acquisitions, or both? Has Proposing Team (or any affiliates) ever been debarred, suspended, or disqualified from bidding or contracting with any entity, including the State of Michigan? If yes, provide the date, the entity, and details about the situation. Has your company (or any affiliates) been a party to litigation against the State of Michigan? If the answer is yes, then state the date of initial filing, case name and court number, and jurisdiction. Within the last 5 years, has your company (or any affiliates) defaulted on a contract or had a contract terminated for cause? If yes, provide the date, contracting entity, type of contract, and details about the termination or default. State your gross annual sales for the last 5 years. If receiving a contract under this RFP will increase your gross revenue by more than 25% from last year’s sales, explain how the company will scale-up to manage this increase. Describe partnerships and strategic relationships you think will bring significant value to the State. State the physical address of the place of business that would have primary responsibility for this account if Proposing Team is awarded a contract under this RFP. Qualified Disabled Veteran Under MCL 18.1261, a “qualified disabled veteran” means a business entity that is 51% or more owned by 1 or more veterans with a service-connected disability. A “service- connected disability” means a disability incurred or aggravated Enter YES or NO. in the line of duty in the active military, naval, or air service as described in 38 USC 101(16). Are you a qualified disabled veteran? To demonstrate qualification as a qualified disabled veteran, you must provide: (a) Proof of service and conditions of discharge (DD214 or equivalent); (b) Proof of service-connected disability (DD214 if the disability was documented at discharge or Veterans Enter the names of documents submitted with your Administration Rating Decision Letter or equivalent if the proposal to demonstrate status as a qualified disabled disability was documented after discharge); and veteran. (c) Legal documents setting forth the ownership of the business entity. In lieu of the documentation identified above, you may provide proof of certification by the National Veterans Business Development Council. Participation in RFP Development or Evaluation Did your company, or an employee, agent, or representative of If you entered “YES”, you are not eligible for contract your company, participate in developing any component of this award or to work as a subcontractor for the awarded RFP? vendor. If you entered “YES,” you are not eligible for contract If you are awarded a contract under this solicitation, in order to award. An awarded vendor may not partner or provide the goods or services required under a resulting subcontract with anyone to provide goods and services contract, do you intend to partner or subcontract with a person required under a resulting contract if that subcontractor or entity that assisted in the development of this solicitation? or partner assisted in the development of this solicitation. Will your company, or an employee, agent, or representative of If you entered “YES”, you are not eligible for contract your company, participate in the evaluation of the proposals award or to work as a subcontractor for the awarded received in response to this RFP? vendor. Experience Does your company have experience working with the State of Michigan? If so, please provide a list (including the contract number) of the contracts you hold or have held with the State for the last 10 years. Describe at least 3 relevant experiences from the last 5 years supporting your ability to successfully manage a contract of similar size and scope for the work described in this RFP. Experience 1 Company name Contact name Contact role at time of project Contact phone Contact email City State Zip 1. Project name and description of the scope of the project 2. What role did your company play? 3. How is this project experience relevant to the subject of this RFP? Dollar value Start and end date (mm/yy – mm/yy) Status (completed, live, other – specify phase) Results obtained Experience 2 Company name Contact name Contact role at time of project Contact phone Contact email City State Zip 1. Project name and description of the scope of the project 2. What role did your company play? 3. How is this project experience relevant to the subject of this RFP? Dollar value Start and end date (mm/yy – mm/yy) Status (completed, live, other – specify phase) Results obtained Experience 3 Company name Contact name Contact role at time of project Contact phone Contact email City State Zip 1. Project name and description of the scope of the project 2. What role did your company play? 3. How is this project experience relevant to the subject of this RFP? Dollar value Start and end date (mm/yy – mm/yy) Status (completed, live, other – specify phase) Results obtained ATTACHMENT C NMC Application Functional Requirements (For Reference Only) Table C-1 provides the functional requirements expected of the MaaS application for reference. Table C-1: MaaS App Functional Requirements (For Reference Only) General Operational Period is one month, June of 2020 GEN 1 The MaaS application must end service at the end of June 2020 Operate across multiple platforms and device types (iOS and Android | iPhone, GEN 2 Samsung, LG latest versions) GEN 3 Ability to interface with the 2020 NAIAS event mobile application GEN 4 Include basic instructions for using the MaaS application Accessible to users 24 hours/day, 7 days/week for the duration of the demonstration, GEN 5 with no or minimum downtime Provide platform for promotional material consisting of text and images with GEN 6 oversight of MDOT management team GEN 7 Use the GPS device of the user’s smartphone to determine the user’s current location Access open General Transit Feed Specification (GTFS) data feeds for interface with existing local mobility options if applicable GEN 8 Develop and access customized interfaces data feed for existing local mobility options as needed Include all potential mobility solutions, such as: 1) MDOT AV Mobility Solution Providers - Regional and On-Demand Shuttles 2) Existing Local Mobility Options - QLine, People Mover, transit, bike share, GEN 9 scooters, etc. 3) Existing Ridesourcing services - Uber, Lyft, taxi, etc. Develop algorithm for multi-modal trip planner for existing local mobility options and AV Mobility Solutions. This can include combinations of existing local mobility GEN 10 options and combinations of AV Mobility Solutions (on-demand or shuttle) with existing local mobility options Keep the AV Mobility Solution trip/leg of trip inside the defined operational GEN 11 boundaries GEN 12 Keep the AV Mobility Solution trips to local trips only GEN 13 Integrate existing local mobility providers' payment process (preferred) Application Deep Links and Web Links to process payments from existing local GEN 14 mobility providers Do not process payment or charge any fee for AV Mobility Solution trips The vendor shall make trip data available through an API for performance GEN 15 measurement and analytics (Trip data shall include, but not be limited to, origin, destination, start time, finish time, mode, date, cost) GEN 16 Personal information that is entered by users shall be secure and protected GEN 17 Trip data shall not include Personally Identifiable Information (PII) Perform with little-to-no discernible latency (response time of roughly 150ms or less, GEN 18 excluding delays in internet service not controlled by the vendor) when performing basic functions such as navigating or searching 1 Work with MDOT management team to support MaaS application during the road GEN 19 testing and operation Work with MDOT management team and comply with communication strategies for GEN 20 public outreach and media GEN 21 Comply with ADA Section 508 standards for accessibility GEN 22 Comply with WCAG 2.0 guidelines for mobile applications The vendor shall be responsible for submitting the completed MaaS application, and GEN 23 updates as needed, to the Apple App Store and Google Play Store The MaaS application must be free to download and without a premium option GEN 24 Default to an English language user interface GEN 25 Open TripPlanner is preferred, but not required GEN 26 Open Maps is preferred, but not required User Interface UI 1 Provide an intuitive user interface UI 2 Display Origin/Destination Use user's current location to determine pick-up location UI 3 Allow user to modify/move this pick-up location Allow users to search for trip options by entering a street address, business name, UI 4 popular points of interest, and by selecting from pre-determined destinations determined by project team Display available mobility options - all AV Mobility Solutions providers for desired UI 5 type of trip, existing local mobility options, and multi-modal combinations based on the origin/destination Display notice in list of available option if all AV Mobility Solutions are not available UI 6 Lack of availability can be cause from, but not limited to, the trip is outside of operational boundaries, the available options reject trip request, the time until AV Mobility Solution arrival to trip origin is above 15 minutes Display only the presented available mobility options on a map with near real-time UI 7 updated locations with user's location UI 8 Suggest nearby locations for origin/destination if applicable Display estimated time until vehicle arrival at origin UI 9 Update estimated time until vehicle arrival at origin in near real-time Display estimated trip times UI 10 Update trip times while trip is in progress Display estimated trip departure time UI 11 Display estimated trip departure time in local time zone format if trip is pre-scheduled UI 12 Display estimated arrival times in local time zone format UI 13 Display cost of each mobility option Update the availability of the mobility options which can include estimated time of UI 14 departure, trip time, AV unit, etc. Provide a filter function with criteria such as: time to pick up, capacity, brand, cost, UI 15 mode of transportation, etc. UI 16 Schedule trip (on-demand and pre-planned) with selected option UI 17 Display trip confirmation number, details, and AV Mobility Solution (if applicable) Use push notifications to notify users of changes to scheduled service UI 18 Push notification shall include, but are not limited to, schedule changes, service disruptions, detours, delays, and cancellations of scheduled service 2 Notify user that the AV Mobility Solution or other mode of transportation has arrived UI 19 at the origin point Allow the user to notify support staff if assistance is needed Assistance may include, but not be limited to, unable to request trip through UI 20 application, lack of confirmation after trip request, not being picked up/dropped off according to scheduled trip information, etc. Provide an interactive map display, which includes AV location updates in near real- time UI 21 If other modes are displayed in the MaaS application then the AV routes and providers should be highlighted separately from the other modes Allow users to store preferences including maximum walking distance and maximum UI 22 trip duration UI 23 Allow the user to contact the vendor in case of complaints UI 24 Allow the user to submit user feedback AV Interface Interface with AV Mobility Solution providers through GTFS and update near real- AVI 1 time with GTFS Real-time AVI 2 Send Trip requests to selected mobility solution provider via agreed upon formats Ability to send and receive trip milestone completion requests Trip milestones may include, but not be limited to, AV Mobility Solution provider AVI 3 confirmation, AV Mobility Solution arrival at origin, passenger pickup, destination arrival, passenger drop-off, trip complete Work with MDOT management team to define any custom AV data feed AVI 4 requirements for the AV vendors Work with MDOT management team to establish content and guidelines for including AVI 5 promotional material in the MaaS application 3 TOD Backend APIs for AV [Last update: 11/6/2019] 1 Overview 3 2 Flow 3 2.1 Itinerary Types 4 2.2 Itinerary Structure 4 2.2.1 Location 4 2.2.2 Transit Point 4 2.2.3 Virtual Stop 5 2.2.4 Ride Request 5 2.2.5 State 5 2.2.6 Itinerary 6 2.2.7 Itinerary State Report 7 2.2.8 Pickup Report 7 3 TOD.AV Reporting APIs 8 3.1 General Settings 8 3.1.1 Request Headers 8 3.1.2 Response Codes 8 3.1.3 Protocol 9 3.2 Vehicle Login 9 3.2.1 Input Parameters 9 3.2.2 Return Value 9 3.3 Report Trip Location 9 3.3.1 Input Parameters 9 3.3.2 Return Value 10 3.4 Report Stop Arrival 10 3.4.1 Input Parameters 10 3.4.2 Return Value 10 3.5 Report Stop Departure 10 3.5.1 Input Parameters 11 3.5.2 Return Value 11 3.6 Report Orders Passengers Status 11 3.6.1 Input Parameters 11 3.6.2 Return Value 12 3.7 Vehicle Logout 12 1 Overview Moovit TOD (Transit On Demand) is a holistic solution for managing a Ride Share fleet, including the passenger front and the dynamic routing management. TOD for AV (autonomous vehicles) is a flavor of the above solution aimed at autonomous vehicles automation. This document describes the high-level flow of this process, and details all APIs that are part of this flow. 2 Vehicle Flow Control API Flow Chart The diagram below illustrates the TOD.AV flow, in terms of API calls. 2.1 Itinerary Types An Itinerary object is used in order to control the vehicles. All APIs (except for Logout) return an itinerary object. There are 3 modes that an itinerary can represent, as detailed below: 1. Passengers Itinerary - Will contain a route including at least two stops and one passenger to pickup. 2. Hover itinerary - Will contain a single stop, to which the vehicle should arrive to, which will be located in the ideal position in order to wait for potential passengers 3. Empty itinerary - Vehicle should wait in its current location 2.2 Itinerary Structure The subsections below define the various structures comprising and describing itineraries. 2.2.1 Location A latitude, longitude pair, describing a GPS location (in degrees). Field Type Nullable Description lat float No Latitude in degrees lon float No Longitude in degrees 2.2.2 Transit Point Represent a physical location within an itinerary Field Type Nullable Description id String No caption String Yes A descriptive name of the transit point location Location No azimuth double The azimuth in degrees in which the Yes vehicle should arrive to the transit point 2.2.3 Virtual Stop Represents a location in which the vehicle should stop in order to drop off or pickup passengers, or in order to hover. Field Type Nullable Description transitPoint TransitPoint No pickupRequestIds List dropOffRequestIds List 2.2.4 Ride Request Represents a single order for a ride. An order can contain multiple passengers. Field Type Nullable Description rideRequestId int No validationCode String This code should be used in order to validate that the correct passenger has No boarded the vehicle, it will be also received from the passenger application. numberOfPassengers int The total number of passengers that will No board as part of this request (between 1 and the vehicle’s capacity) 2.2.5 State Represents the current state of an itinerary (according to the server’s “understanding”, along with immediate instructions. Field Type Nullable Description currentStop VirtualStop Yes The current stop in which the vehicle is known and expected to be at, if any. latestDepartureTime String If present, the latest time (in ISO Time format) until which the vehicle should wait at its current stop. In case all Yes expected passengers have boarded prior to this time, the vehicle is allowed to leave. lastLocationTimestamp String The timestamp (in ISO Time format), in which the last location was received from the vehicle. In case the vehicle recognizes that this timestamp is outdated (due to communication failure, No for instance), it should immediately resend the ordered updates since this timestamp. Otherwise, it should remove from its updates stack (or equivalent) all updates older than this timestamp. 2.2.6 Itinerary An itinerary represents the full route (defined by stops sequence) that the vehicle should take. In case the vehicle observes that the itinerary’s ID has changed, this signifies that the stops’ sequence has changed and that the vehicle has been re-routed. An itinerary can change without having its ID changed, in case the stops sequence hasn’t changed, but other data items (e.g. ride requests) have. This is with one exception - in case an itinerary is refreshed, and its ID remains unchanged, stops which are already in the past won’t be returned. Field Type Nullable Description itineraryId int No stops List rideRequests List currentState State No The currently known vehicle state 2.2.7 Itinerary State Report This structure represents a progress report from the vehicle Field Type Nullable Description location Location No The current vehicle location timestamp String The timestamp in which this state object was generated. It is crucial No that the vehicle’s time will be as precise as possible. accuracy double If available, the location’s accuracy Yes in meters bearing double If available, the vehicle’s bearing in Yes degrees speed double If available, the vehicle’s speed in Yes m/sec altitude double If available, the vehicle’s altitude in Yes meters currentItineraryId int The ID of the last itinerary received No from the server 2.2.8 Pickup Report This structure represents a progress report from the vehicle Field Type Nullable Description rideRequestId int No A reference to the ride request this report is relevant for actualNumberOfPassengers int The actual number of passengers that boarded. This can be different No (equal to or less than) the number of passengers in the ride request. 3 TOD.AV Reporting APIs The subsections below describe all the APIs comprising the TOD.AV service. All of these APIs are exposed by Moovit backend, and are expected to be called by the AV backend, not by the vehicles themselves. Specific endpoints will be delivered per customer. 3.1 General Settings All APIs have certain prerequisites and follow certain standards, as described in the subsections below. 3.1.1 Request Headers All of the APIs receive a set of HTTP headers. The table below lists them. Header Type Required Description API_KEY String Yes The API key provided from Moovit in order to use Moovit’s APIs SESSION_TOKEN String The token returned by the last call to Yes Vehicle Login 3.1.2 Response Codes The table below lists the response codes that all APIs may return HTTP Status Description 200 Positive response 400 Specified parameters violate the protocol 401 Should call Vehicle Login in order to refresh the session token 403 Specified vehicle ID is not recognized or authorized 424 A logical error has occurred. The operation should be retried. 429 API quota limit exceeded 5xx Unexpected error. The operation should be retried. 3.1.3 Protocol All APIs use HTTPS POST. All APIs accept and return a JSON payload, and support GZIP, according to request header directives. 3.2 Vehicle Login Accepts the vehicle’s ID and changes its status to “in service”. Returns the current itinerary that the vehicle should proceed with. 3.2.1 Input Parameters Parameter Type Required Description vehicleId String The vehicle ID will be configured Yes as part of the vehicle setup in the Admin Console 3.2.2 Return Value Field Type Nullable Description sessionToken String The session token that should be used in all No requests according to the table described under Request Headers tokenExpiry Sting The time (in ISO time format) in which the token No will expire, after which an additional call to this API is required in order to generate a new token. itinerary Itinerary No The current itinerary that the vehicle should use 3.3 Report Trip Location Reports the current vehicle state within a trip 3.3.1 Input Parameters Parameter Type Required Description stateReport ItineraryStateReport Yes 3.3.2 Return Value Field Type Nullable Description itinerary Itinerary No The current itinerary that the vehicle should use 3.4 Report Stop Arrival Reports the vehicle’s arrival to a stop 3.4.1 Input Parameters Parameter Type Required Description transitPointId int The ID of the transit point the Yes vehicle arrived to arrivalTime String The time (in ISO time format) in Yes which the vehicle arrived at the stop stateReport ItineraryStateReport Yes 3.4.2 Return Value Field Type Nullable Description itinerary Itinerary No The current itinerary that the vehicle should use 3.5 Report Stop Departure Reports the vehicle’s departure from a stop 3.5.1 Input Parameters Parameter Type Required Description transitPointId int The ID of the transit point the Yes vehicle arrived to departureTime String The time (in ISO time format) in Yes which the vehicle has left the stop stateReport ItineraryStateReport Yes 3.5.2 Return Value Field Type Nullable Description itinerary Itinerary No The current itinerary that the vehicle should use 3.6 Report Orders Passengers Status Reports status change due to passenger pick up and/or drop off 3.6.1 Input Parameters Parameter Type Required Description transitPointId int The ID of the transit point the Yes vehicle arrived to timestamp String The time (in ISO time format) in Yes which the pick up / drop off took place stateReport ItineraryStateReport Yes pickupStatus List dropOffStatus List 3.6.2 Return Value Field Type Nullable Description itinerary Itinerary No The current itinerary that the vehicle should use 3.7 Vehicle Logout Transitions the vehicle’s state to inactive and invalidates its session token. Accepts no parameters and has no return value.