Intelligent Transportation Systems (ITS) Joint Program ... · C-ITS: V2V, V2I, V2x ... SAE J2945/3 - Weather related communication IEEE 1609 - Revisions based on experience ETSI TS

Intelligent Transportation Systems (ITS)Joint Program Office (JPO)

ITS Architecture and Standards Updates&

Interoperable Integration of Automation into the Transportation System

Steve SillITS Architecture and Standards Program Manager

March, 2019

2U.S. Department of Transportation

Overview

I. US DOT ITS Architecture & Standards (A&S) Programs

II. International Cooperation: Architecture-wide Standards Assessment

III. Looking Forward to Automation

IV. Future Opportunities


US DOT ITS Architecture & Standards Programs

Provides tools to help Infrastructure Owner - Operators (IOO) deploy ITS systems and support interoperable interfaces with mobile participants in the transportation system and other infrastructures:□ ITS Architectures provide frameworks to guide planning and

interoperable deployment of ITS and identify candidate interfaces for standardization

□ ITS Voluntary Technical Standards define interfaces within architectures to enable desired interoperability and support efficient implementation

□ International Cooperation to leverage global resources and expertise to (1) maximize commonality of ITS implementations, (2) share labor resources and (3) access best-available expertise in order to facilitate ITS implementation and efficient markets.


ITS as a System of Subsystems Connectivity with/among mobile participants in the transportation

system – a rapidly evolving opportunity:□ Allows safety and mobility benefits□ Supports automation□ Requires interoperability, functionality, security

►System architectures, standards are essential!

ITS Architecture describes information flows between subsystems▪ Identifies candidate standard for information flows

– Specific set of standards where interoperability is required– The ITS architecture reference identifies choices whenever viable

▪ Does not address architecture within subsystems– E.g., “inside the vehicle”, “inside the traffic signal controller”

▪ Reference architecture with tools– Supports tailoring for local needs


ITS Architecture Reference: ARC-IT

Transportation Planning

Project Development

FundedProjects

Operations & Maintenance

Implemented Projects

Monitoring& Evaluation

Supports system-wide/regional planning for ITS

Supports technical and institutional integration and interoperability

Supports ITS project development, design/operations/maintenance

Architecture Reference for Cooperative and Intelligent Transportation (“ARC-IT”, www.arc-it.org) establishes a common language and framework to assist investment decisions:

http://www.arc-it.org/


ARC-IT

ARC-IT software tools Regional Architecture Development for Intelligent Transportation (RAD-IT): Turbo

Architecture updated with modern interface, ARC-IT database Project Architectures - Systems Engineering Tool for Intelligent Transportation

(SET-IT): Functionality tailored to implementation and project specification.

ARC-IT structure defined around four views Enterprise – institutional relationships Functional capabilities and relationships Physical objects and their interconnections Communications media and standards

Multiple views address different stakeholders Business relationships and user expectations Performance measures, services and system goals Functionality, security, interface characteristics Physical configurations


Levels of Detail for Different Audiences


Harmonized Architecture Reference for Technical Standards (HARTS)

HARTS integrates established C-ITS architectures: Different ITS reference architectures across

regions are actually quite similar.

Used as a basis for analysis:

□ “Snapshot” at point in time (~2016)

□ Identify suitable ICT and ITS-unique standards

□ Identify gaps and overlaps for further action.

HARTS is an internationally harmonisedreference architecture based on:• National ITS Architecture Framework

(NIAF) from Australia• EU’s Framework Architecture (FRAME)

from Europe• C-ITS architecture constructs from

Japan• Connected Vehicle Reference

Implementation Architecture (CVRIA)from the US

HTG7.org


130+ ITS services: 1,600 + interfaces between ~130 types of systems)

Systems include centers (e.g.: traffic management centers), field devices (e.g.: traffic signal controllers), vehicle fleets, devices such as smartphones □ Interfaces include data/information exchanges necessary to provide ITS services, from

security credential distribution (SCMS) to field device control to traveler information

ARC-IT

□ Most interfaces satisfied by Information and Communications Technology (ICT) standards – select

□ For ITS-unique needs, specify available standards or identify gaps for future cooperative development work

□ Cooperating with Australia, Europe, Japan to recommend standards, identify gaps.


Examples of Connectivity Interfaces


US DOT ITS Standards Program Cooperate with SDOs for broadly acceptable ITS consensus standards

□ Good practice ... and legislatively directed

Facilitate consensus to support interoperable, efficient ITS deployment□ Limited funding support, Federal leadership when beneficial□ Most resources contributed by participating stakeholders□ IEEE 802/1609, ITE, SAE, ISO TC204, AASHTO, NEMA …▪ Specify or adapt when able, develop when needed (ITS-unique)

Primary standards development areas supported by ITS JPO□ C-ITS: V2V, V2I, V2x – SAE J2735/2945, IEEE 1609/802.11□ ITS C2C – TMDD, C2F – NTCIP, ATC□ Automation/connected automation – initial roadmap completed, more coming□ ITS-relevant: 3GPP, oneM2M, ETSI, CEN, UN WP29, ISO TC22, ITU, IETF.


Available ITS Standards – US Examples

Connected Vehicle (CV) SAE J2945/0 - DSRC SEP Guidance SAE J2945/2 - V2V safety awareness SAE J2945/3 - Weather related communication IEEE 1609 - Revisions based on experience ETSI TS 103097 - Harmonization with 1609.2 ISO 19091 - Intersection applications

Center-to-Field (C2F) ITE-SAE RSU – Backhaul to center, distribution

C2F / Center-to-Center (C2C) NTCIP 1202 Actuated Signal Controller - Controls intersection signals (SPaT, MAP) NTCIP 1204 Environmental Sensor Systems – Roadway weather, air quality sensors NTCIP 1213 Electrical and Lighting Management Systems C2C Reference Implementation - Tool verifies conformance to C2C standards Test Procedure Generator (TPG) - Automates the development of test procedures for

NTCIP standards.


THE THREE PILOT SITES

Reduce the number and severity of adverse weather-related incidents in the I-80 Corridor in order to improve safety and reduce incident-related delays.

Focused on the needs of commercial vehicle operators in the State of Wyoming.

Alleviate congestion and improve safety during morning commuting hours.

Deploy a variety of connected vehicle technologies on and in the vicinity of reversible express lanes and three major arterials in downtown Tampa to solve the transportation challenges.

Improve safety and mobility of travelers in New York City through connected vehicle technologies.

Vehicle to vehicle (V2V) technology installed in up to 8,000 vehicles in Midtown Manhattan, and vehicle to infrastructure (V2I) technology installed along high-accident rate arterials in Manhattan and Central Brooklyn.

WYDOT

New York City DOT

ITS as a System of Systems

• Integration of connectivity with and among mobile participants in the transportation system – a rapidly emerging opportunity:□ Allows safety and mobility benefits□ Supports automation□ Requires interoperability, functionality, security

• System architecture describes information flows□ Standards define information flows

• Multiple standards for each information flow• Multiple standards options for many information flows• Specific set of standards where interoperability is required between/among

mobile participants and ITS infrastructure• Identification of suitable standards is essential for interoperability, security

and system performance.

How an ITS System Fits Together … e.g., HARTS 15

FIXED <<< >>> MOBILE

Multiple Standards for Every Information Flow 16

Flexibility Wherever Viable 17

• Beneficial for implementers to be able to choose from many standards:□ Need to choose the standards that result in the desired outcome□ Often viable within system e.g., center to field□ Security, technical performance, cost ...

Standards options for signal control status

Rigor Wherever Interoperability Needed 18

• Interoperability at system boundaries requires all parties to agree upon a specific set of standards – e.g., V2V, I2V, V2Ped., C2C, etc.□ Security, technical performance, cost ... all still matter□ Often multiple options … but everyone must choose the same for interoperability

Alternate architecture – via e.g., LTE

Signal Status to Vehicle

International Collaboration Opportunity 19

• Technical Challenge:□ Architecture superset

□ AU, EU, JP, US connectivity services□ Harmonized Architecture Reference for Technical

Standards – “HARTS”□ 1,700 information flows□ ~12,000 needs to identify standards

• Many similar flows, but …□ Lots of work!

• Opportunity – common interest:□ Needed by all C-ITS implementers□ Many (most?) envisioned services common□ Global expertise and experience

• Institutional Challenge:□ Much work underway□ Diverse mechanisms□ Large public interest□ But, successful model for past cooperation

• Had developed excellent working relationships

Process

Cooperation Model: Consensus-Based, Flexible 20

Situation:• Multiple regions/countries interested, each with significant expertise□ Each participant has own approach to execution

• Different mix of governmental and private participants• Diverse funding and control mechanisms

Approach: Leverage past successes and adapt/expand□ Governmentally co-led by SME program managers□ Consensus on work description, scope, schedule, management approach□ Each participant brought own staffing resources – many types No funds co-mingled

□ Unified agreement on work description, but no binding division of labor No party obligated to any other party

□ “HTG7” evolved as “short name” for project (7th cooperative standards effort under EU-US ITS agreement)

Summary of Results 21

• Standards Issues Identified as a Type: Either a Gap or an Overlap□ For ~1,700 information flows, analysis identified:

• 43 issue types• ~1,000 issue assignments• ~5,000 issue instances• 112 Proposed Resolutions

• Standards Issues Categorized□ Criticality of timing to resolve issue for deployments

• Urgent, Near-Term, Medium-Term, Future□ Geographic Applicability

• Multi-Regional, AU, EU, JP, US□ Area of Impact

• Foundational, Security, Centre-to-Centre, Field, Vehicle-Local, Centre-Vehicle, Many

Findings

• For the 1,700 information flows, there are approximately 5,000 standards issues (gaps or standards overlaps that lead to uncertainty for deployers) that affect:

□ Gaps:• Foundational• Security• Centre-Centre (C-C)• Field• Centre-Vehicle (C-V)• Vehicle-Local (V-L)

□ Overlaps

22

Examples

Proposed resolutions are written at high-level to describe the proposed outcome needed; details left to governments, deployers, standards organizations, and experts to determine the actions and timing

Class Name Description of Proposed Resolution

Foundational Develop standard for electronic distribution of traffic regulations

Develop an internationally acceptable standard to enable the provision andmanagement of electronic traffic regulations to enable proper operation ofvehicles as they cross jurisdictional boundaries.

Foundational Develop map messaging structures

Develop a model for exchanging detailed map information throughout the ITSenvironment.

Security Core authorization - base services

Develop an internationally acceptable standard for the user permission sets,permission request, permission update request, permission request received, anddevice identification information triples contained within the Core AuthorizationService Package.

Security Secure and accurate location and time standards

Develop/adopt an internationally acceptable standard/solution for synchronisingand continuously maintaining location and time information throughout the ITSenvironment in a secure and reliable manner with sufficient accuracy (includingleap seconds) and confidence.

Center C-C: System monitoring Develop an internationally acceptable ITS application specification for the ServiceMonitor System to monitor other centres and support systems and to reportissues.

Field I-F: Signal conflict prevention

Develop an internationally acceptable ITS application specification for monitoringintersection status information to prevent conflicts between physical displays andbroadcast information.

Vehicle V-L: Environmental data sharing

Develop an internationally acceptable ITS application specification for sharingenvironmental data from vehicles to other local entities. The effort shouldconsider efforts to date under both J2735 and DENM.

23

Product: HARTS Website

Integrate established C-ITS architectures:

• Different ITS reference architectures across regions are actually quite similar.

• Industry trends are driving ITS architectures to become more similar, including: The C-ITS equipment marketplace increasingly global

Core communication technologies are expected to be deployed worldwide

Many regions are now expanding their architectures to include automated technologies.

Similar analyses on standards needed to support connected and automated environments

HARTS is an internationally harmonisedreference architecture based on:• National ITS Architecture Framework

(NIAF) from Australia• EU’s Framework Architecture (FRAME)

from Europe• C-ITS architecture constructs from

Japan• Connected Vehicle Reference

Implementation Architecture (CVRIA)from the US

HTG7.org

24

Products: Reports & Tools

1. Executive Overview (HTG7-1)2. Analysis Methodology (HTG7-2)3. Issues and Proposed Resolutions (HTG7-3): Summarizes standards issues identified

within HARTS, Proposes actions to resolve these issues. Includes:□ Results: Solution Perspective (HTG7-3-1-<R>): Addresses standards issues from perspective of

development or implementation teams in planning and procurement processes. This detailed report is divided into 4 regional reports.

□ Results: Resolution Perspective (HTG7-3-2): Assists standards development community in planning and work processes.

□ Results: Service Package Perspective (HTG7-3-3-<R>): Offers IOOs opportunity to evaluate the “readiness” of services. This detailed report is divided into 4 regional reports.

4. HARTS Website Overview (HTG7-4)5. HARTS Reference Compendium (HTG7-5):

□ Glossary of terms and associated definitions□ Acronyms and associated meanings□ Graphic symbols and associated meanings□ Explanations of key terms and their inter-relationships

25

Next Steps, Lessons Learned 26

• Publish reports ~ Spring, 2019

• Resulting actions?□ IOOs/governments decide on their own next steps, prioritization

• Cooperation when beneficial?□ Standards development organizations can include in near-term plans

• Lessons learned include:□ Reaffirmed benefits of cooperation when interests common□ Significant cost, time saving vs. individual action□ Access to best global expertise > better products□ Scope schedule may have been too large – subdivide?□ Institutional risks exceed technical challenges

• Seemingly minor issues can disrupt


US DOT Automation Principles

1. We will prioritize safety2. We will remain technology neutral3. We will modernize regulations4. We will encourage a consistent regulatory and operational

environment5. We will prepare proactively for automation6. We will protect and enhance the freedoms enjoyed by Americans.

Clear and consistent US Federal approach to shaping policy for automated vehicles, based on the following six principles.

US DOT has released Automated Vehicles 3.0 (“AV 3.0”):

PREPARING FOR THE FUTURE OF TRANSPORTATIONAvailable at: www.transportation.gov/av

28U.S. Department of Transportationwww.transportation.gov/av

US Federal Role in Automation Research

US DOT’s Automation research focuses on three key areas:

1. Removing barriers to innovation2. Evaluating impacts of technology,

particularly with regard to safety3. Addressing market failures and

other compelling public needs.

29U.S. Department of Transportationwww.transportation.gov/av

Cooperative Automation and Connectivity

Figure 2


AV 3.0 and Standards

US DOT will cooperate in the development of voluntary technical standards:

• Voluntary standards offer flexibility and responsiveness to the rapid pace of innovation

• Areas where industry can support standards development include—but are not limited to—topics such as definitions, taxonomy, testing, interoperability, and performance characteristic definitions

• The Department supports the development and continuing evolution of stakeholder-driven voluntary standards.


Cooperative, Interoperable Integration?

Automated systems can – and often do – operate without any communication or coordination with the transportation system IOO□ Similar to other mobile participants in the system today□ Is this optimal?

Increased communication and opt-in cooperation can potentially benefit both safety and mobility

Interoperable integration between infrastructure and mobile participants in the transportation system requires agreement on architecture and key ITS standards … and many other things.


Interoperability in the Automation Context

The ability of two or more systems or components to exchange information and use the information that has been exchanged □ IEEE Std. 610.12-1990

How important is interoperability with the ITS Infrastructure for efficient large-scale integration of automated vehicles?□ Research indicates likely substantial value□ At minimum, improved situational awareness almost certainly beneficial

In the context of automated vehicles, interoperability might be defined as using a common set of interfaces to interact with ITS infrastructure across jurisdictional boundaries within a region/ country□ Are multiple approaches supportable? Beneficial? When?


Introducing new capabilities while supporting existing systems can be challenging – how to assure benefits for all users?

Life-cycle mismatch:□ ITS infrastructure may be expected to be in place for decades□ Light vehicles in service 1-2 decades, heavy vehicles longer□ Devices can be obsolete in only a few years

How/when/whether to break interoperability?□ Better to have a plan…□ Transition periods?□ Hardware/firmware/software solutions?□ Multiple approaches in service indefinitely?▪ How to support obsolete systems?

Ownership mismatch – multiple parties in control:□ IOOs and vehicle operators each control only parts of the system□ Both may be dependent on communications service providers.

Balancing Interoperability with Innovation


Challenges Facilitate consensus voluntary technical standards

□ Avoid impeding innovation□ But meet Transportation Systems Management and Operations (TSMO) and

interoperability needs

Maintain security

Protect privacy and anonymity□ Must be legally and publicly acceptable, adaptable across jurisdictions

All of this in the context of a global marketplace ….□ … yet cognizant of local needs □ … and interoperable anywhere travelers may go▪ Regionally for vehicles, globally for devices

Easy? Not really …


Examples … CACC vs. ACC – capacity increase vs. decrease

Need for dissemination of “rules of the road”□ Recognition technologies can “read” signs in some cases▪ However, what about dynamic information?

Need for IOOs to understand state of their and neighboring networks□ Some information available via infrastructure ▪ Loop detectors, cameras at high cost with limited coverage

□ Likely far more detailed and timely from beacons on vehicles

Need for travelers to understand state of the network and likely travel times, modal options and costs□ Support required standardization while not impeding competition in the marketplace or

impairing privacy expectations.


Potential Challenges Diversity of automation technologies and capabilities likely to be great …

how to accommodate all users … automated or not? For example: How to provide a speed limit?

□ Assume automation can read the sign? Provide via broadcast also?▪ Then how to synchronize?▪ Can broadcast variable speed limits … then how to assure all vehicle receive

the information?▪ More than one technology?

Manage Minimal Risk Condition (MRC) fallback without disrupting mobility?□ Might human drivers handle this better than some automated systems?□ Additional guidance in certain areas?

▪ “Avoid stopping on bridge”?▪ “Stop only on the left in this segment”?

Advance notice of road conditions?□ “Snow covered road beyond MP ##” – disseminate how?

▪ If vehicle automation cannot accommodate, vehicle can refuse trip unless driver agrees to manual control? Preferable to interrupting trip and vehicle stopping …


Key Questions

What do vehicle manufacturers, owners and operators want? Expect?

What do IOOs want that the ITS architecture doesn’t currently provide? Expect?

New architectural elements? New user services? Additional levels of detail? Different information?

Technical standards?


Automation: Candidate Approach … Near-term candidate approach in US?

□ Analogous to C-ITS architecture effort (CVRIA)

Plan for at most minimal regulation - not necessarily a disadvantage □ Forces reaching broad consensus, high quality A&S products

Facilitate broad stakeholder agreement on candidate architecture□ Identify candidate interfaces for standardization▪ Accommodate multiple/future technologies whenever possible▪ Balance interoperability needs with competitive marketplace, need for IOOs to meet

their unique needs□ Identify other interface requirements ▪ e.g. policies

ITS Architecture views to guide development

Likely large benefit from harmonization – global vehicle, device market after all□ Lots of work to do – best to cooperate.


FHWA National DialogueThe Federal Highway Administration held a series of workshops in 20018 on automation integration:

Goals:

1. Focus attention on highway automation readiness2. Catalyze nationwide engagement3. Evolve the US national highway automation community4. Complement related US DOT summits

Reports to be released shortly….


Looking forward … We will cooperate with

stakeholders to reach consensus on a reference architecture to integrate automation into the infrastructure and allow Nationwide and, when viable, multi-regional interoperability

We will support development of voluntary technical standards in cooperation with SDOs

We will cooperate internationally on matters of common interest.

Near-Term Cooperation Opportunities … 41

• Via ETSI Memorandum of Cooperation with US DOT – IEEE 1609? SAE?

• Architecture for Automation (“A4A”): Logical follow-on to successful “HTG7”□ Expand ITS architecture services, reference architecture(s) and software tools

• More fully accommodate automation into the existing references/services• Add new services to take advantage of automation’s unique capabilities

– e.g. automation-only lanes

• “Management for Electronic Traffic Regulations” or METR: – CEN started, also identified via HTG7, now in cooperation with ISO TC204 WG19□ Standards for secure, trusted management of operational information □ US working term: “Connected Rules of the Road” (CROR)□ Means to assure to complete, correct, trusted and timely delivery of operational information

(e.g., variable speed limits, road conditions, routing information) from controlling authority• High value for automation• Not to set the rules, but rather a means to universally provide them via wireless communications in an at least

Nationally interoperable way

□ Take advantage of both ETSI/IEEE and/or ISO 21177 security

Thank you!

Questions / Discussion?

www.its.dot.gov Steve Sill, PEstandards.its.dot.gov ITS Architecture and Standards Program Manager

www.arc-it.org US DOT / ITS JPO

www.arc-it.org [email protected]

http://www.its.dot.gov/

http://standards.its.dot.gov/



mailto:%[email protected]

Documents

Intelligent Transportation Systems (ITS) Joint Program ... · C-ITS: V2V, V2I, V2x ... SAE J2945/3 - Weather related communication IEEE 1609 - Revisions based on experience ETSI TS