Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany

Dear Graig, I support your opinion regarding ASP - IDC interface to be specified to make all IDC to ASPs connections identical and similarly testable. I suggest that last version of ³Technical Specifications for Communication in the LRIT System² (revised for Hamburg) has to be extended  by adding of  higher level ASP-IDC protocol based on SOAP messages. Specification which is based on a request and response paradigm, with the ASP instructing the IDC to perform some operation and return an appropriate result. This addition shall contain the description of format for: * command ³ASP ­ request² (submit message, request status, cancel message, query waiting, request delivery); * command ³IDC - response² (status report, messages waiting, message delivery);       * error messages ³fault² ( to be generated as result of the sending of command and absence of response); * table of status/error codes;    Best Regards Sergey Cherepanov Shore Based Systems Unit Director Transas From: "Hayley, Craig" <HayleyCR(a)DFO-MPO.GC.CA&gt; Reply-To: <ccglrit-gcclrit(a)lists.ncf.ca&gt; Date: Wed, 6 Jun 2007 18:41:48 +0400 To: <ccglrit-gcclrit(a)lists.ncf.ca&gt; Conversation: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working GrouponEngineering Aspects of LRIT, Hamburg Germany Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Chris, Thanks for participating in the discussion... As I have stated in my previous e-mail, I will be modifying the communications document to ensure the CSP to ASP interface (for the IDC case) is open (no grey areas) and thus no prescriptive text. Contracting governments, as stated before (and in the document), are free to do what ever they wish with respect to the Ship-CSP-ASP-NDC interface when we are referring to national data centers or regional data centers. They are responsible for ensuring they have the appropriate interface into the IDE. The ASP to IDC interface should be described in the communications document and should have clear boundaries assigned. There has been some good points raised with respect to not prescribing the interface between the CSP and ASP entities. I believe that there could be a relatively large number of companies that wish to offer the services of the ASP (maybe I'm wrong but an ASP requires minimal resources as opposed to a CSP). If we leave the ASP - IDC interface open, as you suggest, than the IDC will be responsible for complying with what ever interface the ASP chooses. The R&D expense involved with such an option would fall clearly on the shoulders of the IDC and the International community. SOAP was discussed at the LRIT meetings and decided to be the delivery mechanism between the ASP and IDC. I recall that CIRM members recommended SOAP as the ideal choice for the communication protocol between the ASP and IDC as well as between the DCs and IDE. I will leave this in place in the document. Regarding the position and time stamp out of the shipborne equipment... The communication document will not (and never did) prescribe a particular format out of the shipborne equipment. However it does have to describe the format of this information in the LRIT messages that communicate between the DCs and the ASP to IDC interface. Regards, Craig Hayley From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Chris Snowdon Sent: Friday, June 01, 2007 4:28 PM To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Craig, all I've been following this with much interest, but also with some concern. I'd like to suggest that we simplify the communications document to make it less prescriptive. The ad hoc group's terms of reference require us to develop "technical specifications for communications within the LRIT system network (i.e. between the LRIT Data Centers and International LRIT Data Exchange and with the LRIT Data Distribution plan". Therefore, the scope of the communications document should be confined to these components. To prescribe rigid requirements for how the other components work - including the shipborne equipment, CSPs and ASPs - takes us outside of our terms of reference and there is a danger that what we recommend would be unrealistic or impractical so we shouldn't do it. Perhaps with the exception of the security requirements and XML message format (schema), as these apply to the international parts of the system, everything else should be normative or illustrative. As Andy notes, we must remember that there are norms, conventions and standards beyond the field of maritime communications and if we are over-prescriptive, we may contravene these and produce internal contradictions. The immediate consequence of this could be increased cost, but is more likely to be delay caused by development difficulties, or a lack of interoperability. Brian's original point about not prescribing the format of the geographic position, or the time-stamp, is perfectly valid and should be followed: the requirement is that the ship transmits its position according to WGS84, and the date and time in UTC, and we should not be more prescriptive than this. Degrees/minutes/seconds (DMS), degrees/minutes/decimal minutes (DM) and degrees/decimal degrees (DD), are all universally-accepted ways of expressing geographic co-ordinates. There are standard methods for converting between these formats, and we should neither prescribe nor proscribe any of them. The co-ordinates of UNLOCODEs - to which we refer in the the comms document - are often expressed in yet another format, so some on-shore data-conversion is probably going to be necessary anyway. It is more difficult to convert between different geodetic models (eg, from WGS84 to a UTM or ETRS89). The document describing the technical specifications for the International Data Centre should probably include a section on how ASPs will provide data to the IDC, but perhaps the practical purpose of this would really be as much as guidance for those performing the ASP role as those establishing the IDC? The role of the CSP in that context probably does not matter so long as they "provide services which link the various parts of the LRIT system using communications protocols in order to ensure the end-to-end secure transfer of the LRIT information". If the CSP also acts as an ASP, they should be regarded as an ASP rather than a CSP. These distinctions - CSP, ASP, DC - describe functions, rather than tangible components. An entity performing the CSP role can also perform the ASP role, and could even perform the DC role. Further, the ship-ASP-Data Centre path could include more than one CSP, both of which are "blind" to the data they carry. The main relationship would probably be between the IDC and the ASP, with the ASP managing the secondary relationship(s) with the CSP(s) or even acting as a CSP itself. The relationship between national DCs and the IDE would probably be similar, so this should be reflected in the IDE and testing documents. Ultimately this system is going to be derived from current commercial offerings and from the actions of individual and groups of sovereign states. The factors to tie all of this together are the IDE, IDC and DDP, and we must concentrate on making that happen as smoothly as possible. Clarity and simplicity are of paramount importance. Thanks to everyone who's contributed so far. regards Christopher Snowdon, Access Partnership, for Iridium Satellite LLC From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Hayley, Craig Sent: 01 June 2007 14:43 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany You make a fair point... I would suggest other interested parties (such as ASPs wishing to bid on the ASP function for the IDC case) voice their position. If we allow CSPs to send the shipborne data to the ASP based upon any "format" or protocol than the ASP will have to absorb the cost of supporting multiple "formats" and communication protocols. The extra expense, of course, would likely be pushed back to the customers (contracting governments). This topic affects only ASPs and CSPs wishing to form the communication path to the International Data Centre (not national or regional data centers). Based upon e-mails written on this reflector and the discussion in the Hamburg meeting, the document will be aligned with the "consensus" view. Regards, Craig Hayley System Engineer Canadian Coast Guard From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Brian Mullan Sent: Friday, June 01, 2007 10:37 AM To: Hayley, Craig Cc: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Thanks, Craig Good clarification on the data format from the ships. However, you now infer that CSPs will perhaps be asked to format messages from ships ­ but not all CSPs have signed up to do this (I know of only one). It is the understanding of many CSPs that the manipulation of the ³raw² data from ships starts at the ASP level. Also, the LRIT coordinator has said in the past that coordination (³oversight²) starts at the ASP level. The CSP has largely been seen (until now) as purely the comms pipe that provides the LRIT data from ships to the ASP and to start involving CSPs in manipulating LRIT data would extend the oversight role. Writing in specifications for all CSPs would therefore appear to be premature! Kind regards Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com <http://www.inmarsat.com> From: Hayley, Craig [mailto:HayleyCR@DFO-MPO.GC.CA] Sent: 01 June 2007 13:52 To: Brian Mullan Cc: ccglrit-gcclrit(a)lists.ncf.ca Subject: RE: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi All, I'm please to see a good discussion has developed around this topic. Hopefully, more discussion on other topics in the documents will be initiated over the coming week before we meet in Hamburg. Given the e-mails on this topic, the text (including wording in the table) should be altered to eliminate any confusion. I agree that the specific data elements (latititude, longitude, year, month, day, hour, minute, unique equipment identifier) that the shipborne equipment transmits is the important information. The "format" of how those elements are displayed is accomplished by land based software (not shipborne equipment software). Essentially, an application piece of software will take those data elements, process them and display them in a given "format". It has been decided that SOAP messages (using XML format) will be the back bone of the LRIT communication system. Thus, the various data elements contained in a given LRIT message will have to be "formatted" as such. The question of whether application software residing at the CSP or ASP (not software on the shipborne equipment) begins to format the data elements into an LRIT message (SOAP using XML) as defined in the communications document is another issue. Currently, the document is written such that the CSP (for the International Data Centre case) begins to build SOAP messages and pass them to the ASP. We have to define an interface between the ASP and the CSP for the International Data Centre case. If we allowed CSPs to transmit information to the ASP using different formats, protocols, etc than it wouldn't be fair to the ASP. This would add an extra cost burden on the ASPs given that they would have to support multiple formats, protocols, etc. Please note that national data centers and regional data centers are free to define and allow different formats, protocols, etc from the CSP to the ASP. The intention of the LRIT communications document shall be to specify the data elements transmitted by the shipborne equipment as stated in Brian's previous e-mail: Shipborne Data Elements: Latitude -> degrees, minutes and decimal minutes to two decimal places N / S Longitude ->degrees, minutes and decimal minutes to two decimal places E / W Unique equipment ID -> number Year -> 4 digit year number Month -> 2 digit month number Day -> 2 digit day number Hour -> 2 digit hour number Minute -> 2 digit minute number Regards, Craig Hayley From: Brian Mullan [mailto:Brian_Mullan@inmarsat.com] Sent: Friday, June 01, 2007 6:18 AM To: Hayley, Craig Cc: ccglrit-gcclrit(a)lists.ncf.ca Subject: RE: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi, Hayley Many thanks for your email. I can agree that the text of the document is clear; but that the wording in the table is not consistent and appears even to contradict the text you quote. My copy of the document shows wording for 1.1.1.1 that is different: ³The intent of this document is to outline the technical specifications for communication within the international Long-Range Identification and Tracking (LRIT) system as stated in the terms of reference of resolution MSC.211(81).² Your reference is new text in 2.2.2.4 in the copy that I received (15-02-2007 LRIT ad hoc WG) In Table 2, the heading indicates ³Parameter provided by LRIT Shipborne Equipment² and then describes the various elements, including specifying the format. It is clear to me and others that this method of presenting the information in the table means that the information transmitted by the shipborne equipment *must* follow the format written in the table. This is where the difficulty lies ­ the wording is over-prescriptive and does not accord with the wording in 2.2.2.4. My original email showed how, in Inmarsat C position reporting at least, the way the information is transmitted. Other shipborne systems probably will have their own format for presenting data to the ASP. May I suggest, please, that we stick to requiring that the specific data elements (unique identifier, latitude/longitude and date/time of the position) are transmitted from the ship and then only start to prescribe the format for onward transmission from the ASP? In other words, as long as the shipborne equipment transmits, as a minimum, the required elements, any format is acceptable. This allows for all approved shipborne LRIT systems to be offered, no matter in which order or format the data is presented. This approach will also allow the table to be in accord with the new wording in 2.2.2.4 I hope that this is clear. Your hard work is very much appreciated and it is clearly understood that the document remains a ³work in progress². Please don¹t take my input as criticism ­ it is not! All I seek is clarity of the wording for all. With best wishes Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com <http://www.inmarsat.com> From: Hayley, Craig [mailto:HayleyCR@DFO-MPO.GC.CA] Sent: 31 May 2007 19:05 To: ccglrit-gcclrit(a)lists.ncf.ca Cc: Brian Mullan Subject: RE: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi Brian, Thanks for the e-mail. I hope more people will take the time to read the documents and provide comments. I assume you are referring to the LRIT communication document. Please note the following text in the LRIT communications document: 1.1.1.1 The parameters added by the LRIT shipborne equipment include the latitude, longitude, Time Stamp when the position was generated, and the shipborne equipment identifier. The ³Format² of these parameters as outlined in table 2 indicates how the parameters shall be formatted while the information is contained within the LRIT message and does not specify the format of how the shipborne equipment transmits the information. Regarding your concerns with the format of the date/time... The only difference that I can detect between the date/time you state and what is in Table 2 of the LRIT communications document is the separators ("-" versus ":") for the year, month, day, hour and minute. The separator used to separate the year, month, etc in the date stated in table 2 is not important and in no way linked to the format coming out of the shipborne equipment. The format is with respect to SOAP messages communicated along the various LRIT communication segments. CSPs for the IDC shall have to "build" SOAP messages complying with table 2 in the communications document using the format from the ship borne equipment. The important thing with the time stamp is that seconds are not transmitted. Regarding your concerns with the format for latitude... We had a discussion on your e-mail and the intention was to implement your recommendation. I can't recall why the "seconds" component of the latitude didn't change to decimal minutes with a precision of 2 decimal places. The most likely reason is that I forgot to incorporate this change in the document due to the numerous requests. My apologies on this topic. I will make the change for latitude to decimal minutes unless someone raises a compelling reason not to change. Any body from the Communications group recall if there was a specific reason why we didn't make the change (Jilian, Guy, etc.)??? I would like to high light to everyone that these documents are in constant flux as a result of many requests from different inputs at the Ad Hoc meeting. Thus, it is important to fully read the documents that come out of each meeting to ensure that any particular topic of interest is addressed in a satisfactory manner. Thanks, Craig Hayley System Engineer Canadian Coast Guard 709-772-7740 From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Brian Mullan Sent: Thursday, May 31, 2007 12:35 PM To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Thanks, Tracy In table 2 I note that the format of date/time is still shown as YYYY-MM-DD-HH-MM. My earlier email (attached) made comment on this. Also in Table 2, note appears to have been taken of my comments regarding latitude/longitude position for Longitude only, but ignores Latitude. We must not start requiring reformatting for transmitted data that is already designed into existing shipboard equipment ­ PLEASE! Many thanks Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com <http://www.inmarsat.com> From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Peverett, Tracy Sent: 29 May 2007 22:27 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Second of two e-mails As promised, attached please find the updated LRIT Communications specification. Best regards Tracy Tracy Peverett Senior Policy Analyst Canadian Coast Guard Tel: 1-613-990-4046 Fax: 1-613-998-3255 e-mail: peverettT(a)dfo-mpo.gc.ca This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. In accordance with Inmarsat Information Security Policy and Guidelines on Computer use, emails sent or received may be monitored. Inmarsat plc, Registered No 4886072 and Inmarsat Global Limited, Registered No. 3675885. Both Registered in England and Wales with Registered Office at 99 City Road, London EC1Y 1AX. _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _______________________________________________ Ccglrit-gcclrit mailing list Ccglrit-gcclrit(a)lists.ncf.ca http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit