TK Convener for meeting, absence of KK and CC. Document distribution.

1. P1512/29 Comments, Sorted into Issues/Action Items, Prioritized (1 of 1)
2. Attendees List
3. Barrett Comments
4. ICS Position Descriptions and Responsibilities, October 1994
5. ICS National Training Curriculum, ICS Glossary, October 1994
6. Relationship Chart, EMS adapted from the pending update from the ITS NA.
7. Tip’s Comments
8. John Lathrop, Response to Comments Revised, June 12, 1998 (31 pages)
9. Table XX, Requirements-Based Message Taxonomy, (2 pages)
10. Message: IDX, 05/13/98
11. IEEE P1512 Draft, D0.0.4, June 9, 1998, cleaned version
12. IEEE P1512 Draft, D0.0.4, June 9, 1998, line-in,line-out version

MINUTES

AGENDA

ACTION ITEMS

WORKING GROUP SESSION

Spreadsheet list for working session structure

JLathrop: Summarized and described the spreadsheet contents. Ron Ice not here to discuss NA issues. Meaning of PSAPs inside IM domain. Attempt to settle the issues, significant accomplishment.

KBrooke: Led discussion on "scope," identified various aspects of scope as illustrated in the following table, future work, relationship to architecture. Use guide or white paper to include work that provides consideration for the scope issues. JL: Revisions removed most of the scope considerations. May be part of a program plan or supplemental document. ASchoka: Guides are appropriate to accompany standards because they are very high level and cryptic when attempting to apply the standard. Put in some guidance information and as work progressed, that the material differs in conformance and informational content from the proposed standards. Background is useful, but not as part of the standard. [My adaptation of the table that made sense to me, slightly different from what was on the board.]
 

SCOPE	STD DOC	GUIDE	IEEE PAR	PROJECT PLAN	WHITE PAPERS
Document, Scope	XX	X	X	X	X
Committee	X	X	XX	X
Phase II	X	X	XX	X
PAR REVISION		XX	X	X
Point to Other Standards	XX	X	X	X
Liaisons			X	XX
XX = Principal place for scope and purpose statements; X = Must be consistent with principal scope source in same column.

 

Discussed scope of the EMS effort. LS: TMDD includes 6 or so C2C interfaces. Originally assumed that ere would be a unique set of messages for each interface, with some for the other interfaces. Changed view so that the effort focuses on the dynamic status of the traffic network. Information will be offered at the interface and not a unique set of messages supporting an interface. MS/ETMCC is describes the hierarchy or tree that supports the TMS data flows from the NA. MS/ETMCC draft will be available in June and will incorporate comments and input from the IEEE MST. Moving toward a common set of messages. Presuming that security and data integrity will be handled on a local level. Basically a peer-to-peer level relationships among centers. Use and access issues will be local agreements, assumption is that information will be available, and will be provided on a request basis. No agreement among various groups. A message sets as was done by the data elements. LSaxton: No funded requirement for a guide document. Reasonable amount of concept of operations in the standard, but not how to apply, and briefings are available to understand the work in progress. DKelly: Scope is the collection of dark arrows on the relationship diagram distributed. Can be creative with the flows on the relationship chart.

JL: Some flow developed through WG discussion. Relationship diagram issue of what is covered and what is not by this WG and what is being done by the other groups.

ACTION: look at relationship diagram and identify the work being done by others and there will be more flows based on knowledge of the WG.

Dave Helman DH. NA is evolving. DK: Tie to NA, but get the work done. Recognize that the work needs tog et done, and WG will work on the details as needed. EMark: Feedback to JPO and proposal for next effort. DK: Identified SAE work; CVISN and HAZMAT and MAYDAY. AS: advocates limited the content of the standard, and judgement made about the amount of informative material in the annexes. Relationships to other standards or background, could be included in preface, foreword, etc.

Check web site for documentation. San Antonio URL. www.transguide.tx.us

Table YY in front of standard, XX in informative annex and guide. YY will be reduced to cover the items in the standard. Staple Guide, but not run it through consensus process. Available on the web. ACTION: What is the sense of IEEE to provide the information without formal balloting. NTCIP will be copyrighted, but made freely available. Requirements for IM. Provide information to help reader understand the standard. Tables XX and YY to be discussed later.

Reference source and include entire definition. TMDD will include ID, Name, and Description, and citing NTCIP DE definitions that are not yet defined.

Agreement on the flows between EM and TM, ETS and EM, and Other EM to EM TBD later. Consolidate ETS flows (no messages from PSAP to EM since PSAP is within the EM). What about TMC to TMC? Some covered by TMDD, but a more comprehensive level of detail needed from IM so there will be a TMC to TMC flow.

Architecture flows. Should there be a EM to other EM? EM to ES and TMC. Need to understand what come from the TMC and What should come from EM. TMDD complete list of messages will be available by July. Question of the placement of the ESO in respect to EM.

Should standard include EM to other EM. No. Include as needed, but consider for future work.

Terms and acronyms included are done so because it is used in the document. LS: Assumed that EM data elements would be derived from the IM group. JMona: issues is what is unclear as to what is going to be sent between EM and TM. IM = generic messages, TM = detail messages.

Summary of discussion. TMDD discussion to include all other DDs. TMDD noted that IM has defined generalized message into which data can be added. That was unexpected and expected more explicit identification of IM data and more complete message bodies. MST set of sequence of data elements or data structures will be included in the body of the message. ASN module is a collection of messages. EMS messages will be created that includes legacy systems and that there are many different ways of exchanging information. National reporting systems have some agreements. KB assumes that there a common basis for communication method in real time.

DH: Agreement to get data from different DDs to populate messages. What is the value of leaving it the way it is. ID process, identify recommended set of messages including the data elements. EMark: Presentation on various framework, thoughts behind, and how apply it to a scenario and how the wrap arounds are applied within the scenario.

First step what went into the draft.

Second step to get input from the group to see if the draft is sufficient.

Third step is to populate the messages with the data elements by the WG members.

MO: Cover the technical aspects related to the envelopes. Critical to developing operations and system integration, an important part of the standard. Fleshing out the shells with the data elements. Consider all sources that are important. How it operates. How it would working the real world. AGREEMENT: Look at TMDD as the initial source. Look at use of source in the context of the scenario or data flows.

Message envelopes based on scenarios reviewed. Message context in establishing center. Seen in PSAPs and small towns that have established hours of operations and not manned every hour of every day.

JL provided the background for the draft documents and relationship among the documents distributed.

80619

Document distribution

Attendees List from 06/18/98

Message Inventory, ETMCC Message Inventory

IM Message Inventory

TCIP Messages, ST-ITS-TCIP-IM, Version 1.0

TMDD Section 2, March 16, 1998, DE Definitions, L. Saxton

TMDD Section 2, March 16, 1998, DE List, AASHTO

Prototype Message Set, TMC to ISP, Table of Contents, DEA, March 25, 1998

Different message categories

Steps:

Identify a Center in the field extending their architecture. Address issue and bridge to the next process. ACTION: KB will prepare a White Paper on ITS Emergency Services. Will provide by July 1.

Agreed that the work to be completed by DK/JL within about three weeks and then circulated to the WG for review, complete that draft before the August meeting.

John Lau: Location Reference Information Report. IM needs to pick a profile that is moving forward. Cross-streets maturing, geographic profile more useful for IM domain. Where should the profile work that needs tob e done? Can IEEE do it? Geographic profile home? ISP ATIS vehicle = SAE. ACTION: Ggeographic profile needed for incident management, supports traffic management. Basic input to be from the SAE location reference information report. Impact on State and local jurisdictions and organizational entities involved in mitigating the incident. Develop an information interchange method to described location in multiple ways.

ACTION: TK Send to ITE information about the next meeting, three days in Seattle. Sunday August 16 – 19, 1998. Proposed to have one more meeting and one more workshop in addition tot he August meeting.

ACTION: KB will provide to DK/JL a description of the IM location data element attributes using ASN.1 notation. Submit to NA and to others.

Draft proposal for new work. On-scene data flows, incident commanders linked, medical, write guide document, response plans, NENA, routing, EMDD. Closure for phase 1.

Location important.

Ed Mark: will provide information about the relative priorities.

Meeting adjourned 1300?

Respectfully submitted,

Ken Brooke
IMWG Secretary
20 July 1998