RSU Standardization Working Group Virtual Meeting Log … · 2020. 8. 18. · Roadside Unit...

RSU Standardization Working Group Virtual Meeting Log Information Start time-11:30AM -5:30PM Eastern Mon. 6.1 Meeting number (access code): 477 220 588, Meeting password: MPqm7tpPR42 CLICK THIS LINK| Join meeting Join by phone:1-844-740-1264 USA Toll Free Tue. 6.2 Meeting number (access code): 473 639 447 Meeting password: Awu9PpNTm29 CLICK THIS LINK | Join meeting Join by phone -844-740-1264 USA Toll Free Wed. 6.3 Meeting number (access code): 475 278 787 Meeting password: 42YmUAbjJX6 CLICK THIS LINK I Join meeting Join by phone 1-844-740-1264 USA Toll Free Thurs. 6.4 Meeting number (access code): 479 294 730 Meeting password: P5Yq93pF7Dd CLICK THIS LINK I Join meeting Join by phone:1-844-740-1264 USA Toll Free Agenda for Road Side Unit (RSU) Standard v1.0 ConOps Walkthrough 1. Introductions/Call to Order/Welcome (McNew/Leonard/Narla) 2. Opening Statements (Curtis/McNew/Leonard) 3. Project Goals and Objectives (McNew/Leonard) 4. Quorum Determination & Antitrust Guidance (Tavares) 5. Review and Approve Agenda (McNew/Leonard) 6. Meeting Conduct and Robert Rules (ITE/McNew/Leonard) 7. Discussion on Terminology (McNew/Leonard) 8. Walkthrough Presentation (Boaz) 9. Perform Walkthrough (Boaz) 10. Plan Next Meeting (McNew/Leonard/Narla) 11. Other Business (time permitting) (McNew/Leonard) 12. Adjourn

https://noblis.webex.com/noblis/j.php?MTID=m00cebc8c3f3576b9e1b4f40d49db8b69

https://noblis.webex.com/noblis/j.php?MTID=m00cebc8c3f3576b9e1b4f40d49db8b69

https://noblis.webex.com/noblis/j.php?MTID=m616db0344a8cbe9b75a5730fb19fb985

https://noblis.webex.com/noblis/j.php?MTID=maefac691219b9a8c2bd40b7c3faebf71

https://noblis.webex.com/noblis/j.php?MTID=maefac691219b9a8c2bd40b7c3faebf71

https://noblis.webex.com/noblis/j.php?MTID=m10fc692370666c67ff210475610b73ce

Roadside Unit Standardization Project 1

CVAG Draft

Roadside Unit (RSU) StandardConcept of Operations (ConOps)

Walkthrough

June 1-4, 2020, 11:30 AM – 5:30 PM EDT


Introductions / Call to Order / Welcome (McNew/Leonard/Narla)


Opening Statements (Curtis/McNew/Leonard)


Project Goals and Objectives (McNew/Leonard)

The primary objectives of this project are to:a) deliver, approve and publish a non-proprietary,

industry-based consensus driven RSU Standardb) incorporate manufacturer input based on actual product

development

Develop using a systems engineering process (discussed later)

Broad base of stakeholders in RSU Working Group


Quorum Determination & Antitrust Guidance (Narla)


Voting Members of RSU Working Group (WG)

Alan Davis, Georgia DOT

Blaine Leonard, Utah DOT *

Joe Gorman, Michigan DOT

Ahmad Jawad, RCOC

Faisal Saleem, Maricopa County DOT

Joanna Wadsworth, City of Las Vegas

Alan Clelland, Applied Information

Dave Miller, Siemens

Tim McCall, Eberle Design

Aravind Kailas, Volvo Group NA

Jason Graves, DENSO Intl. America

John Kenney, Toyota Info Tech Labs

Justin McNew, JMC Rota (IEEE/SAE) *

Lee Mixon, Mixon Hill

Ehsan Moradi Pari, Honda

* Indicates Co-Chair


The Institute of Transportation Engineers is committed to compliance with antitrust laws and all meetings will be conducted in strict compliance with these antitrust guidelines. Further if an item comes up for which you have conflict of interest, please declare that you have a conflict of interest on the matter and recuse yourself from action on that item.

The following discussions and/or exchanges of information by or among competitors concerning are prohibited:• Prices, price changes, price quotations, pricing policies, discounts, payment terms,

credit, allowances or terms or conditions of sale;• Profits, profit margins or cost data;• Market shares, sales territories or markets;• The allocation of customer territories;• Selection, rejection or termination of customers or suppliers;• Restricting the territory or markets in which a company may sell services or

products;• Restricting the customers to whom a company may sell;• Unreasonable restrictions on the development or use of technologies; or• Any matter which is inconsistent with the proposition that each company must

exercise its independent business judgement in pricing its service or products, dealing with its customers and suppliers and choosing the markets in which it will compete.

Antitrust Guidance


Review and Approve Agenda (McNew/Leonard)

1. Introductions / Call to Order / Welcome (McNew/Leonard/Narla)

2. Opening Statements (Curtis/McNew/Leonard)

3. Project Goals and Objectives (McNew/Leonard)

4. Quorum Determination & Antitrust Guidance (Siva)

5. Review and Approve Agenda (McNew/Leonard)

6. Meeting Conduct and Robert Rules (McNew/Leonard)

7. Discussion on Terminology (McNew/Leonard)


Agenda (cont.)

8. Walkthrough Presentation (Boaz)

9. Perform Walkthrough (Boaz)

10. Plan Next Meeting (McNew/Leonard/Narla)

11. Other Business (McNew/Leonard)

12. Adjourn


Meeting Conduct and Robert Rules (McNew/Leonard)

Using Robert’s Rules of Order to conduct meeting Quorum is needed Parliamentary procedures Call the Question (State the outcome, record the

outcome, follow up as necessary, move on) Let all members speak once before allowing anyone to

speak a second time Use consensus (majority rules)


Meeting Conduct (cont.)

Additional Meeting Rules Contribute to meeting goals Let everyone participate Listen with an open mind Think before speaking Attack the problem, not the person


Discussion on Terminology (McNew/Leonard)


Walkthrough Presentation (Boaz)


What is a ConOps?

A user-oriented document that describes system characteristics for a proposed system from the users' viewpoint

Identifies user needs


ConOps Requirements Design Details

Traceability Traceability

Systems Engineering Standard Development Process

Newer ITS Standards Contain All Three Definition Phases


Purpose of the Walkthrough

Find anomalies

Improve the ConOps

Consider alternatives

Ensure completeness

Gain a consensus on the user needs and the other material within ConOps


Well-Written User Needs Uniquely Identifiable

The need is assigned a unique number and title

Major Desired Capability (MDC) The need expresses a major desired capability in the system

Solution Free The need does not contain the manner in which to achieve the

capability Allows flexibility to discover the best feasible solution

Captures Rationale The need captures the reason for the major desired capability


Perform Walkthrough (Boaz)


Plan Next Meeting (McNew/Leonard/Narla)1) Tavares to post project documents as they are ready in

Basecamp.2) Action items from the Walkthrough are to be completed by

Thursday, June 4 COB.3) A revised ConOps that is based on this walkthrough is to be sent

out Friday, June 5.4) Please do not send new comments until after Friday, June 5.5) Comments on the new ConOps will be accepted through Friday,

June 12 COB. Please post comments using the comment form in Basecamp. Append your name to the end of the filename.

6) Narla/Chairs to discuss next step.7) The schedule is to be updated.8) An example requirement is to be sent out.


Other Business (McNew/Leonard)


Adjourn (McNew/Leonard)

RSU_min200601_draft (1).docx Page 1

RSU Standardization Working Group ConOps Walkthrough

The following are meeting notes from Day 1 of a Concept of Operations (ConOps) walkthrough for the RSU Standardization Working Group (WG). The meeting was a web conference on Monday, June 1, 2020 scheduled from 11:30 AM EDT to 5:30 PM EDT.

The meeting was called to order at 11:32 PM EDT and began with an introduction by the co-chairs, Blain Leonard and Justin McNew.

Deborah Curtis from USDOT provided an opening statement. USDOT is aware of the NEMA TS 10 effort - and they have graciously offered their work. The SDOs and different stakeholders are represented in this effort. This is intended to be an ANSI, open standards development effort, so if a stakeholder group is missing, they are welcome to join.

The intention of this project is to develop a standard from a specification, with manufacturer and user input.

Siva Narla noted that a quorum was present.

89 Participants included:

Blaine Leonard, UDOT (co-chair) Justin McNew, JMCRota (co-chair) Alan Clelland, Applied Information (member) Alan Davis, Georgia DOT (member) Jason Graves, DENSO (member) Joe Gorman, Michigan DOT (member) Ahmad Jawad, ITE (member) John Kenney, Toyota (member) Dave Miller, Siemens (member) Stephen Orens, Volvo (member) Christopher Poe, Mixon-Hill (member) Faisal Saleem, Maricopa County (member) Danyang Tian, Honda (member) Joanna Wadsworth, City of Las Vegas (member) Steve Sill, USDOT

Deborah Curtis, USDOT Kingsley Azubike, USDOT Suzanne Sloan, USDOT Justin Anderson, Noblis Linda Nana, Noblis Kellen Shain, Noblis Jean Johnson, NEMA Tom Kurihara, TK Standards Venkat Nallamothu, AASHTO Siva Narla, ITE Nicola Tavares, ITE Sue Bai, Honda Rob Baily, Kapsch Ralph Boaz, Pillar Consulting Wolfgang Buckel, Siemens Patrick Chan, ConSysTec Bronwen Crowe, ConSysTec Chuck Felice, Utah DOT Anthony Gasiorowski, WSP Hideki Hada, Toyota Zhitong Huang, Leidos

Manny Insignares, ConSysTec Michael Ippoliti, Volvo Haydar Issa, Transport Canada Peter Jager, Utah DOT Dmitri Khijniak, Parsons Ed Leslie, Leidos Iouri Nemirovski, Siemens Whitney Nottage, Q-Free Jonathan Parent Jay Parikh, CAMP Bob Rausch, TransCore Randy Roebuck, OmniAir Jesus Ruiz, McCain Ted Sadler, Integral Blue Mike Schagrin, McCain Michael Stelts, Panasonic Alan Toppen, Kimley-Horn Walt Townsend, Applied Information Jingcheng Wu Ken Yang, AECOM

Siva Narla reviewed the Anti-trust Guidance.

Review of the agenda by Justin McNew. Asked for any objections to approving the agenda. None heard, so agenda is approved.


Review of Meeting Conduct/Robert's Rules by Justin McNew.

Discussion on Terminology (Blaine Leonard)

- Change: Going with Version 01 idea (replace 4.1) - RSU & OBU: Mutually exclusive terms

o Both senders as well as receivers o Agreed on use of OBU/MU (On-Board Unit/Mobile Unit)

Walkthrough Presentation (Ralph Boaz)

*10-Minute Break at 12:45 AM EDT*

Perform Walkthrough (Ralph Boaz)

1.1 Scope

- Suggestion: The ConOps should remain accessible to users. - “This version of the document contains the Concept of Operations”. - Consensus (from the chairs): Leave it as is. First paragraph removed. - Suggestion for addition (John Kenney): Devices that are not part of the road infrastructure, such

as cellular base stations and satellites are not RSUs. o [Action Item: Boaz] Add to definition section.

1.2 References

- Rows out of order. o Corrected.

- Add reference to FCC rule. - Make sure all references in the document are included.

1.3 Terms

- Skipping for now. - Comments for IEEE specifications can be dealt with offline.

1.4 Abbreviations

- Skipping for now.

2.2 Current Situation and Problem Statement (Informative)

- Change: Make “present tense”. - Suggestion: Introduce term “V2X” (Justin to assist).

o Or “CV Technology” - Remove broadcast. Use consistent terms. - Need to look at terms V2I, I2V, V2X, etc. - Context diagram to be amended.


- [Action Item: Boaz] Remove footnotes.

2.3 Operational Architecture (Informative)

- [Action Item: Boaz] Change GPS to GNSS. Check terminology Radio/Receiver. Do document scrub.

*10- Minute Break at 2:20 EDT*

2.5.1.2 Extreme Environmental Conditions

- These are just examples to give us a rationale for why the need exists. - Suggestion (Jean): Remove “must” from this need.

2.3.1.3 Power Protection and Filtering

- Question (Dmitri): When we say RSU, are we referring to every external piece that goes along with the RSU?

- Consensus (from chairs): Delete the phrase “in RSUs” present here. - [Action Item: Boaz] Consensus (from chairs): Change all needs to be “RSU needs”.

2.5.1.4 Withstand Vibration and Shock

- Amended to be “RSU need” and for present tense.

2.5.1.5 Resistant to Electronic Emissions

- We need a rationale for the RFI. o Discussion (Justin McNew): Should we even include radio frequency interference here at

all? Kind of a separate topic. - Renamed to “Resistant to Electromagnetic Interferences” - Action Item: Add another, separate need “Resistant to Out of Band Interference”

2.5.1.6 Electrostatic Discharge Resistant

- Suggestion (Jean): Combine the last two sentences of this need.

2.5.1.7 Limit Electronic Emission

- Suggestion (Randy): Cite the FCC CFR Part 15b.

2.5.1.8 Mounting

- Suggestion: Change the “and” to “or” in the first sentence. - Change: “Some RSU configurations may involve antennae and radios that are operating

remotely from the RSU processor” added to need.

2.5.1.13 Interchangeable

- Change “different” to “an equivalent”.


- Justin: We could ask that the RSU must always be provided with antennas.

2.5.1.14 Software Upgradeable

- O/S, application - Suggestion (Walt Townsend): Change name to “Remote Firmware Upgradeable”. - Suggestion (Justin): “Needs to be able to be loaded locally or remotely”. - Suggestion: We need to include both software and firmware.

o Ralph: Then we will have to define both software and firmware. (See IEEE definitions). - Justin: Change the need instead.

o John Kenney: Do we need this at all? - Have operational requirements for remote upgrades. - Name Change Decision: “Software and Firmware Updates”

2.5.2.2.2 Time Source

- Jean: Requests some rewording of this need. - Examples could be included (GNSS or an NTP server).

2.5.2.3 Determine Current Location

- Jean: Proposed Rationale: This feature allows the system to determine whether the RSU has moved from its location and allows the system to rely on location specific information.

- Another need covers the broadcast piece of this need.

2.5.2.6 RSU Clustering

- Change: “The RSU needs to be capable of operating with other RSUs within a cluster”. - Justin and Bob: “This increases the RF coverage and the number of channels available to be used

by applications”. - Steve Orens: For simple RSUs, will this actually be a requirement? - Might turn this into an optional requirement.

2.5.2.7 Message Handling

- Skipped for now.

2.5.2.7.1.2 Forwarding of Messages Received by the RSU

- Justin to write rationale. - In the diagnostics requirements, we need to be able to turn off verification. - Possibly set up separate Test Mode as a need (using a test PID?).

Ralph captured many of the changes to the text within the document, itself. This document will be posted on Basecamp for further review.

We will start with 2.5.2.8 Applications tomorrow, and probably revisit some of the changes made based on comments received. Ralph will send out a copy of the marked-up walkthrough workbook tonight.

Day 1 of the ConOps walkthrough adjourned at 5:27 PM EDT.

RSU_min200602_draft.docx Page 1

RSU Standardization Working Group ConOps Walkthrough

The following are meeting notes from Day 2 of a Concept of Operations (ConOps) walkthrough for the RSU Standardization Working Group (WG). The meeting was a web conference on Tuesday, June 2, 2020 scheduled from 11:30 AM EDT to 5:30 PM EDT.

The meeting was called to order at 11:32 AM EDT. Siva announced that a quorum was present.

Nicola provided a tutorial on how to use Basecamp for the project and project materials.

Ralph Boaz presented the Anti-Trust Guidelines.

Siva Narla thanked the subject matter experts that helped put together the ConOps document.

82 In attendance were:Blaine Leonard, UDOT (co-chair) Justin McNew, JMCRota (co-chair) Alan Clelland, Applied Information (member) Alan Davis, Georgia DOT (member) Jason Graves, DENSO (member) Joe Gorman, Michigan DOT (member) Ahmad Jawad, ITE (member) John Kenney, Toyota (member) Dave Miller, Siemens (member) Michael Ippoliti, Volvo (member) Christopher Poe, Mixon-Hill (member) Faisal Saleem, Maricopa County (member) Danyang Tian, Honda (member) Joanna Wadsworth, City of Las Vegas (member) Steve Sill, USDOT Deborah Curtis, USDOT Kingsley Azubike, USDOT Suzanne Sloan, USDOT

Justin Anderson, Noblis Linda Nana, Noblis Kellen Shain, Noblis Jean Johnson, NEMA Tom Kurihara, TK Standards Venkat Nallamothu, AASHTO Siva Narla, ITE Nicola Tavares, ITE Tony Ahmad, ITS Roads Sue Bai, Honda Rob Baily, Kapsch Ralph Boaz, Pillar Consulting Wolfgang Buckel, Siemens Patrick Chan, ConSysTec Bronwen Crowe, ConSysTec Julie Evans, ITS Roads Chuck Felice, Utah DOT Anthony Gasiorowski, WSP Hideki Hada, Toyota Zhitong Huang, Leidos Manny Insignares, ConSysTec Haydar Issa, Transport Canada Peter Jager, Utah DOT Dmitri Khijniak, Parsons

KRECHM AJ Lahiri, ConSysTec Ed Leslie, Leidos Jim Misener, Qualcomm Iouri Nemirovski, Siemens Whitney Nottage, Q-Free Jonathan Parent, Transport Canada Jay Parikh, CAMP Pierre Rasoldier, Transport Canada Bob Rausch, TransCore Randy Roebuck, OmniAir Jesus Ruiz, McCain Ted Sadler, Integral Blue Nick Spatola, Faller Davis & Co. Michael Stelts, Panasonic Alan Toppen, Kimley-Horn Walt Townsend, Applied Information April Wire, Maricopa County Ken Yang, AECOM

Ralph Boaz continued the walkthrough of the ConOps document, starting with 2.5.2.8 Applications.

2.5.2.8.1 SPaT Processing

- Question (Bob): Reference specific standards here. These are very specific requirements. - Suggestion (Jean): NTCIP 1202 v03A needs to be referenced. She is concerned that the second

and third sentences here belong in the requirements, not here.


- Suggestion (Justin): If you need rationale, say “This allows the RSU to provide SpaT to the OBUs/MUs”.

o It is a user need in J2735 format. It’s fine to start out this way.

2.5.2.8.2 MAP Messages

- Justin added rationale: “This enables the OBU/MU to accurately use SPaT information”.

2.5.2.8.3 Traveler Information Messages

- Justin added rationale: “This enables the RSU to provide traveler information to OBU/Mu”. - Tony Ahmad: Can we put in anything for static v. dynamic messages?

o Justin: Dynamic messaging should be done offline using the forwarding feature. - Note: We inform the reader that the TIM is dynamic and needs to be provided through the

forwarding interface.

2.5.2.8.4 Position Correction Messages

- Justin: Not a native need for the RSU, but we didn’t want to lose this. - Jay: Change mobile device to OBU. - Allan Clelland: Should this be in the appendix? - [Action Item: Boaz] Move to informative annex.

2.5.3.1 Configuration and Management

- Alan: Need to be more specific about which section of NTCIP 1218 is relevant. - Justin: The whole thing is relevant but maybe this could be addressed in requirements. - Note: If someone is procuring an RSU, they should fill out a PRL for NTCIP 1218. Possibly specify

specific requirements.

2.5.3.2 Health and Status Monitoring

- Note: If someone is procuring an RSU, they should fill out a PRL for NTCIP 1218. Possibly specify specific requirements.

2.5.4.1 Back Office

- Tony: Could be more than just status messages…data exchange? - “Data exchange” added.

2.5.4.2.1 Receive Data from Local Field Devices

- Bob: This is really broad. - Justin: Store and forward interfaces almost cover this, this does feel duplicated. - Motion to remove this need and add clarification to the forwarding section?

o Wolfgang objects. Isn’t this the only requirement that talks about SPaT information? o Justin: There is a requirement for SPaT. o Tony: Are we saying we are going to have two separate interfaces? o Justin: Highly unlikely. One ethernet interface to the RSU that everyone will share. There

will be logical separation. Will be decided when we write the requirements. Does this alleviate Wolfgang’s concerns?


o Siva: Rationale is reasonable. o Bob: Is there a rationale for keeping it (contact closures)? Is there somebody that really

had something in mind to write this in the first place? o Blaine: Are roadway weather conditions and traffic warnings covered in TIMS? o Justin: Yes. Covered in forwarding interface or a specific application user need. o Motion accepted. Need removed. o Rationale added to the forwarding interfaces user needs (2.5.2.7.1.1.2).

2.5.4.2.2 Provide Data to Local Field Devices

- Justin: If we want to be more specific we can note SAE J2735. - Motion to remove this need and add another application user need to support signal priority and

preemption? o Blaine: We’re not saying it HAS to process this information. o Motion accepted. Need Removed. o Add an application user need to support signal priority, wrong-way driver, and BSM pre-

processing. o [ACTION ITEM: McNew/Boaz] Justin to draft. Review by other SMEs.

2.5.4.3.1.1 Radio Interfaces

- Rational added: This allows the RSU to exchange data with the OBU/MU.

2.5.4.3.1.2 Multi-Channel Operation

- Rational added: This allows the RSU to exchange data with the OBU/MU on multiple channels.

2.5.4.3.1.3 Network and Transport Layers

- Rational added: This allows the RSU to exchange data with the OBU/MU.

*10-Minute Break at 12:55 PM EDT*

2.5.5.1.2 Secure Sessions

- [Action Item: Boaz] Move to informative annex.

2.5.5.2 Local and Back Office Interface Security

- Details of achieving security need to be expanded in the requirements.

2.5.5.3 Data Integrity

- Addition: NTCIP 1218 v01 specified here. - [Action Item: Anderson] Provide rationale.

2.5.5.4 Availability

- [Action Item: Anderson] Provide rationale.


2.5.5.5 Confidentiality

- [Action Item: Anderson] Provide rationale. - Section 2.6.4 add to requirements.

2.5.5.6 Tamper Evident

- Note that there are different ways to do this.

2.5.5.7 Physical Requirement for Certificate Storage

- Define level of protection in requirements. - Suggestion (Jean): Make paragraphs notes.

2.5.5.8 SCMS

- Randy: Will RSUs work with all SCMS providers? - Justin Anderson: In an ideal world, yes. That is the hope for sometime in the future. - Randy: You may want to separate those requirements. - Wording change: (paragraph C) “prevent” ”protect”

2.5.5.8.3 Store Certificate

- Do we need the last sentence? o Removed.

- Jean: The second sentence isn’t a rationale. Suggested “to prevent unauthorized access to an RSU’s private keys and certificates”.

o Accepted.

2.5.5.8.4 Download CRL

- Jean (on second sentence): The purpose of the CRL is to clarify certificates that have been revoked?

- Justin A: If the device’s certificate IS NOT in the CRL, it is not valid.

2.5.5.8.5 Download SCMS Files

- Rationale added (Justin A): This feature allows for deployment specific certificate configurations and trust between certificate authorities.

2.5.5.8.6 Detect Misbehavior

- Search and replace term “to be able to” and “in order to”. - Consider other terms V2X for CV Communications. - Blaine: Isn’t it the RSU that detects the misbehavior? - Justin A: This could be an optional requirement area. USDOT worked on developing misbehavior

detection at RSU or OBU or even if you collect enough BSMs at the TMC. Just want the option to be there for anyone trying to detect misbehavior at a specific location.

- Jean suggests the term: “be capable of” o Patrick disagrees.


2.5.5.8.7 Report Misbehavior

- Randy: Is there anything set for any other type of mobile devices? - Change: “Vehicles” “Connected devices”

2.5.6 Certification

- Tony: What defines acceptance of this requirement? - Does second sentence belong?

o Made into a note. - Note: This is not meant to be an installation/integration test. - Note: Traffic controller interfaces include NTCIP 1202 v02, NTCIP 1202 v03A, and NTCIP 1218

v01. - Tony to Randy: How does the testing procedure for certification work? - Randy: Current RSU is tested against a couple OBUs that have already undergone certification.

o Randy requests we tell him how many devices would be reasonable to test with an RSU. 2-3?

- RSU WG should look at this during requirements development. - Name change: “Verify Conformance”

*12-Minute Break at 3:08*

2.6 Relationship to the ITS National Architecture

- OBU/MU changes. - [Action Item: Chan] Update diagram, then summarize the section to make it useful. - Patrick: If we don’t see any value, we can remove the third bullet under ARC-IT Physical View

and the table of interfaces and flows. o Bullet removed.

- Justin: RSU Map Management doesn’t sound like it’s a functional object that belongs to the RSU. - Wolfgang: The RSU needs to read the information contained in the map and configure itself to

send out the SPaT information correctly. - Bob: The result of this standard should define the interface the Connected Vehicle software

talks to. o Jean Disagrees: This is the logical successor to the relationship to National ITS

Architecture. What does DOT think? Patrick: If you’re asking for federal money, your project should be in the ITS

architecture. This will help you find where your project belongs…cannot be ignored.

Justin A: As the RSU evolves, if the architecture needs to change, that can happen. It is important to provide this mapping.

Comments Spreadsheet Walkthrough

2.5.2.1 Startup


- [Action Item: Justin M] Add a new need for Recovery: o The RSU needs to have a restart capability with all of the following configurations:

Factory Settings, Default, and Last Saved. This allows the RSU to resume operation or be reconfigured after a power outage or other anomaly.

- This will be reinvestigated when we write the requirement.

*The remainder of the comments resolution and discussion took place in the Comments Spreadsheet (edited by Ralph) to be posted on basecamp.

Discussion of Next Steps:

- Submit any comments and action items between now and COB Thursday (6/4). - Ralph to post revised document (based on this walkthrough) on Friday (6/5). - Instructions and comments sheet are to be sent out on Friday (6/5). - We will allow one week for comments (6/12). - Meetings have been canceled for tomorrow and following day (6/3, 6/4).

Siva will re-evaluate the project schedule by Friday with Patrick. Send out the requirements outline.

The next meeting will be a Requirements Walkthrough.

Day 2 of the ConOps walkthrough adjourned at 4:46 PM EDT.

RSU Standardization Working Group Virtual Meeting Log … · 2020. 8. 18. · Roadside Unit...

Documents

Transcript of RSU Standardization Working Group Virtual Meeting Log … · 2020. 8. 18. · Roadside Unit...