Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany
2:58 p.m.
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
________________________________
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
________________________________
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
________________________________
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
10:41 a.m.
New subject: 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
________________________________
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
________________________________
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
________________________________
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
5:47 a.m.
New subject: 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>
Reply-To: <ccglrit-gcclrit(a)lists.ncf.ca>
Date: Wed, 6 Jun 2007 18:41:48 +0400
To: <ccglrit-gcclrit(a)lists.ncf.ca>
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
7:59 a.m.
New subject: June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany
Hi Sergey,
Thank you for your comments... Are you planning on attending the LRIT
meeting in Hamburg? I am interested in hearing additional details
pertaining to your suggestion.
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 Cherepanov
Sergey
Sent: Thursday, June 07, 2007 7:18 AM
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
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>
Reply-To: <ccglrit-gcclrit(a)lists.ncf.ca>
Date: Wed, 6 Jun 2007 18:41:48 +0400
To: <ccglrit-gcclrit(a)lists.ncf.ca>
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 MailScanner has detected a possible fraud attempt from
"www.inmarsat.com" claiming to be <http://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 MailScanner has detected a possible fraud attempt from
"www.inmarsat.com" claiming to be <http://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 MailScanner has detected a possible fraud attempt from
"www.inmarsat.com" claiming to be <http://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
11:45 a.m.
New subject: June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany
Dear Craig,
Unfortunately due to earlier appointment I can not attend LRIT meeting in
Hamburg. Paul Morter will represent Transas in Hamburg.
Best regards
Sergey Cherepanov
Shore Based Systems Unit Director
Transas
From: "Hayley, Craig" <HayleyCR(a)DFO-MPO.GC.CA>
Reply-To: <ccglrit-gcclrit(a)lists.ncf.ca>
Date: Thu, 7 Jun 2007 15:59:27 +0400
To: <ccglrit-gcclrit(a)lists.ncf.ca>
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
Hi Sergey,
Thank you for your comments... Are you planning on attending the LRIT
meeting in Hamburg? I am interested in hearing additional details pertaining
to your suggestion.
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 Cherepanov Sergey
Sent: Thursday, June 07, 2007 7:18 AM
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
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>
Reply-To: <ccglrit-gcclrit(a)lists.ncf.ca>
Date: Wed, 6 Jun 2007 18:41:48 +0400
To: <ccglrit-gcclrit(a)lists.ncf.ca>
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 MailScanner has detected a possible fraud attempt from
"www.inmarsat.com" claiming to be <http://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 MailScanner has detected a possible fraud attempt from
"www.inmarsat.com" claiming to be <http://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 MailScanner has detected a possible fraud attempt from
"www.inmarsat.com" claiming to be <http://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
_______________________________________________
Ccglrit-gcclrit mailing list
Ccglrit-gcclrit(a)lists.ncf.ca
http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit
6602
days inactive
6608
days old
4 comments
3 participants
participants (3)
-
Cherepanov Sergey -
Chris Snowdon -
Hayley, Craig