Radio Technical Commission for Maritime Services s1

RTCM Paper 234-2011-eNav-018Radio Technical Commission for Maritime Services 1800 N. Kent St., Suite 1060 Arlington, Virginia 22209-2109 www.rtcm.org [email protected] Telephone: +1-703-527-2000 Telefax: +1-703-351-9932 December 3, 2011 2012 WORK PROGRAM e-Navigation Steering Committee and Special Committees 109, 112, 121, 129 and 1301. Considering Paper 252-2007-BD-413 which includes the establishment of the e-Navigation Steering Committee, the Committee establishes its 2012 Work Program to: a. Consider whether SC 121 on AIS and Digital Messaging should “certify” or “qualify” ASM.Review Paper 152 - 2011 - eNav - 015.r1 and the 12100 standard CD. Discuss whether RTCM, through SC 121’s ASM TWG should “certify” or “qualify” ASM according to the 12100 standard.Make a recommendation to the Board of Directors for their spring 2012 meeting. b. Consider whether RTCM should develop new standards related to GNSS.Review Paper 154-2011-eNav-016. Discuss whether RTCM should develop new standards for: 1) AIS transceivers as a a component of other systems; 2) GNSS (or GPS) receivers as a component of other systems; 3) RAIM; and/or 4) Interference, jamming and/or spoofing. Discuss whether these should be developed by a new special committee.Make a recommendation to the Board of Directors for their spring 2012 meeting. c. Consider whether RTCM should establish a position/policy related to NMEA interfaces and/or data formats.Review Paper 233 - 2011 - eNav - 017. Discuss whether RTCM standards should: 1) Require both NMEA 0183 and NMEA 2000® interfaces; and RTCM Paper 234-2011-eNav-0182) Address the distribution of data over Ethernet, reference IEC 61162-450 for that purpose and include NMEA 2000® parameter groups (i.e., in addition to the NMEA 0183 sentences required by IEC 61162-450. Discuss whether a change to the RTCM Standards Development Policies (Paper 117 - 2005 - BD - 385) is necessary to provide such guidance.Make a recommendation to the Board of Directors for their spring 2012 meeting. d. Consider whether RTCM should establish a path forward for the implementation of e-Navigation.Review the current technology of e-Navigation systems and infrastructure. Discuss the possibilities of encouraging the use of existing technology to implement e-Navigation capabilities. Discuss the role of RTCM standards toward this goal.Develop a report identifying such a path forward. Coordinate with USCG, NOAA, NGA and USACE, as necessary, if appropriate.Report to the Board of Directors for their autumn 2012 meeting.2. Considering Paper 208-2010-BD-458 and the TORs for SC 109 on Electronic Charting Technology (Paper 197 - 2010 - SC109 - 258), SC 112 on Ship Radar (Paper 201 - 2010 - SC112 - 032), SC 121 on AIS and Digital Messaging (Paper 199 - 2010 - SC121 - 056), : SC 129 on the Portrayal of Navigation-Related Information on Shipboard Displays (Paper 198 - 2010 - SC129 - 001) and SC 130 on EOIS for Maritime Applications (Paper 179 - 2011 - SC130 - 001) to establish liaison and coordinate activities with the e-Navigation Steering Committee and each other, the Committee establishes their 2012 Work Programs as follows:: a. SC 109.Revise the 10900.5 standard on ECS as follows:1) Review Accident Report NTSB/MAR-11/01 PB2011-916401 (Paper 027 - 2011 - SC109 - 266) with a specific focus on their recommendation to require installation of VDRs that will record, at a minimum, the same video, audio, and parametric data specified for S-VDRs in IMO MSC.214(81) Annex 2.Evaluate the 10900.5 standard’s voyage recording requirements (i.e., in clause 4.1.4) against the parametric data specified in IMO MSC.214(81) Annex 2 and IEC 61996-2 (Ed. 2) and consider the incorporation of additional requirements, if applicable. Coordinate directly with the NTSB and the USCG1 as necessary.1 Commercial Regulations and Standards Directorate, Design and Engineering Standards Office, System s Engineering Division (CG-5213); Marine Transportation Systems Management Directorate, Navigation Systems Office, Electronic Navigation Division (CG-5532) RTCM Paper 234-2011-eNav-0182) Review IMO MSC.1/Circ.1389 (Paper 028 - 2011 - SC109 - 267) and IMO SN.1/Circ.266/Rev.1 (Paper 029 - 2011 - SC109 - 268) with a specific focus on software updating.Consider the incorporation of additional requirements, if applicable.3) See 1.c. above. Review the 10900.5 standard with a specific focus on the requirements in clause 4.1.5 to accept data in both NMEA 0183 and NMEA 2000® data formats and IEC 62376 clause 5.4.1.Implement changes according to the Board’s established position/policy related to NMEA interfaces and/or data formats.4) See B.1 below. Review the 10900.5 standard with a specific focus on the requirements in clause 4.1.5 to generate an indication that certain data is of low or doubtful integrity when it has not been received in a certain length of time. Determine whether the IMO and/or USCG specify any values for time to alarm and/or integrity.Evaluate the specification of 6 sec for heading data, and 1 min for all other data. Consider whether 6 sec should be specified for all data in the 10900.6 standard.5) See B.2 below. Review the 10900.5 standard and IEC 62376 with a specific focus on software functionality. Consider the state of the ECS market with respect to software developers and the availability of generic computer hardware.Consider the specification of a generic hardware platform that can be type- certified to IEC 60945 (and any additional hardware requirements in IEC 62376 and the 10900.5 standard) and the separate specification of software requirements. At a minimum, create a cross-reference of software functionality to the multiple standards.Complete the 10900.6 CDV by the 2012 Annual Assembly Meeting and Conference. b. SC 112.1) Review IEC 62388, IEC 62252 and RTCM Paper 71-95/SC112-STD. Develop standard 11200.0 addressing “Radar Equipment Installed on Ships Less Than 150 Tons Gross Tonnage” using IEC 62388 as the normative basis for the new standard.See 1.c. above. Implement requirements according to the Board’s established position/policy related to NMEA interfaces and/or data formats. RTCM Paper 234-2011-eNav-018Complete the 11200.0 CDV by the 2012 Annual Assembly Meeting and Conference.2) Maintain a watching brief on IEC 62388 (Ed.2) / IEC TC80 MT 1. c. SC 121.Review ITU-R M.1371-4 with a specific focus on binary messages/messaging. Review IMO SN.1/Circ.289. Review IALA’s work on the Harmonized Implementation of ASM. Develop RTCM Standard 12100.0 addressing “The Devlopment and Qualification of ASM”.Complete the 12100.0 CDV by the 2012 Annual Assembly Meeting and Conference. d. SC 129.Maintain a watching brief on: 1) RTCM 12100 / SC 121; 2) NMEA OneNet™. 3) IHO S-100; and 4) IEC 62288 (Ed.2) / IEC TC80 MT 5. e. SC 130.Develop RTCM Standard 13000.0 addressing “EOIS for Maritime Applications”. Address requirements for interfacing with EOIS for control (e.g., from a radar or ECS), including the control of position (i.e., train and elevation).Complete the 13000.0 CDV by summer of 2013. RTCM Paper 234-2011-eNav-018Annex A Future Work (Tentative)A.1 2013 A.1.1 SC 1091) Revise the 10900.6 standard as follows:Coordinate with SC 121. Consider the incorporation of additional requirements and/or references to the 12100 standard for ASM, as appropriate, if applicable. At a minimum, restore the requirements deleted during the comment adjudication of the 10900.5 CDV and requirements to support both the creation and the display of ASM.Complete the 10900.7 CDV by the 2013 Annual Assembly Meeting and Conference.2) Maintain a watching brief on IEC 61174 (Ed.3.1).A.1.2 SC 112 1) Revise the 11200.0 standard as follows: a) Review IEC 62388 (Ed. 2). Update the 11200 standard, as appropriate, if applicable. b) Coordinate with SC 121. Consider the incorporation of additional requirements and/or references to the 12100 standard for ASM, as appropriate, if applicable.Complete the 11200.1 CDV by the 2013 Annual Assembly Meeting and Conference.2) Develop standard 11201.0 addressing “Radar Scan Conversion for Overlay on Electronic Chart Data” using IEC 62388 as the normative basis for the new standard.Complete the 11201.0 CDV by the end of the year.A.2 2014 A.2.1 SC 109 Revise the 10900.7 standard as follows:1) Coordinate with NOAA, NGA, USCG and SC 121, as necessary. See A.2.1.1 below. Review IEC 62376 with a specific focus on the allowance to adjust depth information by actual and/or predicted water levels if the electronic chart database provides detailed bathymetric information (i.e., in clause 4.2.1.4). Determine the availability of detailed bathymetric information.Consider the creation of an annex that would provide guidance for implementing tidal adjustment of depth features using actual data provided via [AIS] ASM and accounting for the geographic location of the tide stations.2) Coordinate with SC 130. Incorporate additional requirements and/or references to the 13000 standard for interfacing with EOIS, as appropriate, if applicable. RTCM Paper 234-2011-eNav-0182) Coordinate with SC 112. Incorporate additional requirements and/or references to the 11201 standard for the overlay of radar video images and the display of tracked radar targets, as appropriate, if applicable.4) Review IEC 61174 (Ed.3.1) with a specific focus on the additional tests for ENC. Incorporate additional tests for the ECS Database, as appropriate, if applicable.Complete the 10900.8 CDV by the end of the year. A.2.1.1 Proposed Implementation of Depth Adjustments for Real-time Tidal Data From: Kenneth CirilloSent: Tuesday, August 09, 2011 11:42 AMTo: Robert FeatherSubject: RTCM SC109 Work Program - Request for ModificationHi,Sorry for taking so long to get this to you.Please look this over and let me know if there are any questions or if you need additional information.If you can also pass along an update on the status of the adjudication of the comments received it would be appreciated (might have missed them).And lastly, are there any plans to meet for next week’s RTCM BoD and other committee meetings for the SC109?Thanks,KenSubject :Request an addition to the SC109 Work Program to include guidance on the implementation of depth adjustments in the ECS database for real-time tidal data.It would be preferable to have this included for the next SC109 Work Program; 10900.6 as opposed to 10900.7.Summary :IEC 62376 clause 4.2.1.4 allows that an ECS may adjust the depth information by actual and/or predicted water levels if the electronic chart database provides detailed bathymetric information.In the meetings for RTCM 10900.4, SC109 identified a potential work item to create an annex that would provide guidance on implementing this. Unfortunately, further discussion on this item was postponed due to the adjudication of the comments received on the 10900.4 CDV.As such, this item/section was deleted from the standard (i.e., in favor of simply accepting the IEC clause without any additional requirements or guidance).Anticipated Outcome : RTCM Paper 234-2011-eNav-018SC109 should produce an informative Annex for the RTCM 10900 standard to provide guidance on implementing tidal adjustments for the US using detailed bathymetric data from NOAA in combination with real-time tide data from PORTS (i.e., via AIS/ASM).A.2.2 SC 112 1) Revise the 11200.0 standard as follows: a) Coordinate with SC 130. Incorporate additional requirements and/or references to the 13000 standard for interfacing with EOIS, as appropriate, if applicable. b) Review IEC 62388 (Ed. 2). Update the 11200 standard, as appropriate, if applicable.Complete the 11200.2 CDV by the 2014 Annual Assembly Meeting and Conference.2) Revise the 11201.0 standard as follows:Review IEC 62388 (Ed. 2). Update the 11200 standard, as appropriate, if applicable.Complete the 11201.1 CDV by the 2014 Annual Assembly Meeting and Conference. RTCM Paper 234-2011-eNav-018Annex B SC 109 Reference MaterialB.1 Excerpts from the Comment Adjudication for 10900.5 CDV Date Document: Project: 2011-07-15 054-2011-SC109-272 10900.5 (ECS) CDVMember Clause/ Paragraph Type of Comment/ Adjudication of the Chairman (3) Subclause Figure/ Comment Proposed Change Table (2) Johnson 3.1 Technical The part about binary messages (and ASM is never used or Agreed. mentioned even though this is the current terminology) is very vague - as written I do not know how anyone could prove compliance - or if the intent is that the ECS just be able to Deleted all references to binary messages in this revision. read and write binary data then that is worthless. We need the ECS to be able to display and create ASMs. NOTE: References to ASM will be added to this standard after SC 121 and SC 129 publish their 12100 and 12900 standards... hopefully for revision 6. The current SC 109 work program reflects this. Johnson 4.1.5.2 Technical Why is the timeout value for position and other data 1 min Not agreed. and for heading 6 sec? I would think that the alarm should be 6 sec for all data. This The 1 min value was agreed to by the Committee as a would be more in line with CG and IMO values for time to general indication of loss of data across an interface. Where alarm/integrity. the standard expects NMEA 0183-HS data, the Committee agreed to the 6 sec value. The Committee is not aware of any IMO guidance on this matter.No action taken.NOTE: Will be added to the SC 109 work program as a discussion item for revision 6.2 General, technical or editorial. 3 For each comment. RTCM Paper 234-2011-eNav-018Member Clause/ Paragraph Type of Comment/ Adjudication of the Chairman () Subclause Figure/ Comment Proposed Change Table () Johnson 4.1.5.3 Technical Why is the timeout value for position and other data 1 min Not agreed. and for heading 6 sec? I would think that the alarm should be 6 sec for all data. This The 1 min value was agreed to by the Committee as a would be more in line with CG and IMO values for time to general indication of loss of data across an interface. Where alarm/integrity. the standard expects NMEA 0183-HS data, the Committee agreed to the 6 sec value. The Committee is not aware of any IMO guidance on this matter.No action taken.NOTE: Will be added to the SC 109 work program as a discussion item for revision 6. Johnson 4.1.5.5 Technical Why is the timeout value for position and other data 1 min Not agreed. and for heading 6 sec? I would think that the alarm should be 6 sec for all data. This The 1 min value was agreed to by the Committee as a would be more in line with CG and IMO values for time to general indication of loss of data across an interface. Where alarm/integrity. the standard expects NMEA 0183-HS data, the Committee agreed to the 6 sec value. The Committee is not aware of any IMO guidance on this matter.No action taken.NOTE: Will be added to the SC 109 work program as a discussion item for revision 6. Johnson 4.1.5.7 Technical The part about binary messages (and ASM is never used or Agreed. mentioned even though this is the current terminology) is very vague - as written I do not know how anyone could prove compliance - or if the intent is that the ECS just be able to Deleted all references to binary messages in this revision. read and write binary data then that is worthless. We need the ECS to be able to display and create ASMs. NOTE: References to ASM will be added to this standard after SC 121 and SC 129 publish their 12100 and 12900 standards... hopefully for revision 6. The current SC 109 work program reflects this. RTCM Paper 234-2011-eNav-018Member Clause/ Paragraph Type of Comment/ Adjudication of the Chairman () Subclause Figure/ Comment Proposed Change Table () Johnson 5.3.2 Technical Why is the timeout value for position and other data 1 min Not agreed. and for heading 6 sec? I would think that the alarm should be 6 sec for all data. This The 1 min value was agreed to by the Committee as a would be more in line with CG and IMO values for time to general indication of loss of data across an interface. Where alarm/integrity. the standard expects NMEA 0183-HS data, the Committee agreed to the 6 sec value. The Committee is not aware of any IMO guidance on this matter.No action taken.NOTE: Will be added to the SC 109 work program as a discussion item for revision 6. Johnson 5.3.3 Technical Why is the timeout value for position and other data 1 min Not agreed. and for heading 6 sec? I would think that the alarm should be 6 sec for all data. This The 1 min value was agreed to by the Committee as a would be more in line with CG and IMO values for time to general indication of loss of data across an interface. Where alarm/integrity. the standard expects NMEA 0183-HS data, the Committee agreed to the 6 sec value. The Committee is not aware of any IMO guidance on this matter.No action taken.NOTE: Will be added to the SC 109 work program as a discussion item for revision 6. Johnson 5.3.5 Technical Why is the timeout value for position and other data 1 min Not agreed. and for heading 6 sec? I would think that the alarm should be 6 sec for all data. This The 1 min value was agreed to by the Committee as a would be more in line with CG and IMO values for time to general indication of loss of data across an interface. Where alarm/integrity. the standard expects NMEA 0183-HS data, the Committee agreed to the 6 sec value. The Committee is not aware of any IMO guidance on this matter.No action taken.NOTE: Will be added to the SC 109 work program as a discussion item for revision 6. RTCM Paper 234-2011-eNav-018Member Clause/ Paragraph Type of Comment/ Adjudication of the Chairman () Subclause Figure/ Comment Proposed Change Table () Johnson 5.3.7.2 Technical The part about binary messages (and ASM is never used or Agreed. mentioned even though this is the current terminology) is very vague - as written I do not know how anyone could prove compliance - or if the intent is that the ECS just be able to Deleted all references to binary messages in this revision. read and write binary data then that is worthless. We need the ECS to be able to display and create ASMs. NOTE: References to ASM will be added to this standard after SC 121 and SC 129 publish their 12100 and 12900 standards... hopefully for revision 6. The current SC 109 work program reflects this. RTCM Paper 234-2011-eNav-018B.2 Proposed Separation of Hardware and Software for ECSFrom: Brice Pryszo Sent: Wednesday, July 27, 2011 10:27 AM To: RTCM - Bob Markle Cc: Joseph Ryan Subject: SC 109 Work Program Dear Bob, Hopefully it is not too late (I was quite busy and travelling) but I would like to support a revision of SC 109 to reopen the issue of separating ECS software and hardware for test purposes. You’ll recall that this was originally discussed at the first meeting of IEC TC80 WG7A (AI01- 03), but at the 5th meeting, the WG declared the AI to be OBE by the AI to “relax” the 60945 requirements for Class B ECS and allow for portable hardware (AI04-05). Given the state of the ECS market with respect to software developers and the availability of generic computer hardware meeting 60945 requirements, WG7A’s decision only serves to make ECS more like ECDIS… and therefore may defeat to primary purpose of a separate ECS standard. RTCM SC 109 should re-establish its leadership role in ECS and take on the original WG7A AI to “specify a generic hardware platform that can be type-certified to 60945 (and the hardware requirements of the ECS standard), and propose a separation of hardware and software” for test purposes in 10900.6.” Best regardsBrice Pryszo www.maxsea.com RTCM Paper XXX-2011-eNav-018Annex C 13

Radio Technical Commission for Maritime Services s1

Details

Download

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

Support