10. DATA FORMATS

10.1 The Inmarsat Position Report
10.2 Optimized VMS Position Report
10.3 Extended Format Position Report

Defining data formats is something like devising a filing system: ask a dozen people to design the most efficient way of arranging the categories and you will end up with a dozen different approaches. Defining data formats for VMS has an added level of complexity: several thousand vessels are already participating in VMS schemes, many of them based on priority data formats. Settling upon norms and standards in this area requires from everyone involved, a combination of technical rigor, flexibility and diplomacy.

The vast majority of current VMS systems are based on the Inmarsat-C system and the position data format used for these terminals is, in turn, based upon recommendations from the International Maritime Organization as part of its work related the SOLAS convention and the resulting GMDSS.

In addition, the data is bit-mapped, a process which attributes specific places in the message to specific data sets, thus keeping the size of the message to a minimum. The way that this works can be illustrated, for example, by the way we must communicate that the position in a given report is expressed in either north or south latitude and east or west longitude.

Taking a normal transmission of unspecified data, it would require at least five bits to express the letters N, S, E or W. If however, we predetermine that the information for which hemisphere latitude and longitude will be transmitted in two specific fields within the message, we require only one bit to distinguish between N and S and a second bit to distinguish between E and W. Other fields can be compressed in a similar way. The result is that bit mapped messages are much shorter than those expressed in free data, are better adapted to automated handling within a VMS system, and keep communications costs to a minimum.

Despite these advantages, it must be admitted that the position report format currently used by Inmarsat is not optimised for VMS as it uses a number of fields that are not relevant to VMS operation. It provides, for example, for macro-encoded messages to communicate parameters which require manual input.

However, despite the fact that this format, not having been developed with VMS in mind, is not specifically adapted to the application, it is only reasonable from the perspective of a VMS operator to include it as one of options for a system under development. This is because so many of the vessels currently participating in VMS are already programmed to transmit this format and that discarding the format would require that current VMS participants, and those carrying Inmarsat-C equipment that might be included in future VMS operations, would all have to be reprogrammed.

On the other hand, it would be a missed opportunity, at this early stage of VMS development, not to define a format optimised to provide the data to a VMS system. Furthermore, it is only prudent to establish a format that gives users some flexibility in the organization of the data. Such reports will be inherently longer, but far less restrictive and should therefore be acceptable to any users who, for one reason or another, find that the bit-mapped approaches are not yet compatible with their operations.

So it would seem that the solution is to qualify three formats as acceptable for VMS reporting and for all VMS operators to program their systems to accept reports in any of those three formats. In so limiting the variables, divergence of national authorities and from one another will be restricted and the stage set for convergence upon a single, world standard, format sometime in the future.

It would be both an egregious error and counter productive not to incorporate existing international standards where applicable. Those that find a natural place in our data formats are the ISO 8859.1 character set; ISO 3166 country codes; ISO 8601 representation of dates and times; and ISO 9735 EDIFACT syntax rules.

10.1 The Inmarsat Position Report

Inmarsat data reports are executed in a series of from one to three 15 byte packets. As is the case with all communications systems, the report begins with the header which is proprietary administrative data identifing the type of message, the sender and the addressee. For this reason the first packet has room for less user designated data and, because the first packet of the standard maritime data report ends with nearly three bytes set aside for a micro encoded message, speed and course data, when used, must be carried over to the second packet.

After the header of the first packet, 39 bits are set aside for position data, organized thus:

Table 10.1 Inmarsat position report, position only

Field	Expression	Data
Hemisphere	North or South	1 bit
Degrees of latitude	whole number 0 to 90	7 bits
Minutes	whole number 0 to 60	6 bits
Fraction of minute	multiples of 0.04	5 bits
Hemisphere	East or West	1 bit
Degrees of longitude	whole number 0 to 180	8 bits
Minutes	whole number 0 to 60	6 bits
Fraction of minute	multiples of 0.04	5 bits

The remainder of the first packet is taken up by the designation of a micro encoded message and its attribute, or variable. The second packet then begins, after its header, with speed and then course data thus:

Table 10.2 Inmarsat position report, course and speed addition

Field	Expression	Data
Speed	number with resolution of 0.2 knots	1 byte
Course	whole number 0 to 360	9 bits

Having added speed and course, there remains 8 bytes of user defined data that could be used to transmit, at no additional transmission charge, other data available on board, such a temperature, wind speed, humidity or water surface temperature.

10.2 Optimized VMS Position Report

On a field per field basis it is impossible to transmit position data more economically than is done within the Inmarsat maritime position report. It is, however, possible to remove extraneous data fields and thus to compress the report as a whole.

If, for example, we allow a full six bytes for header information - six bits more than Inmarsat requires and likely to meet the needs of any future system - a 15 byte packet can include all of the data fields, i.e. position, speed and course - still allowing the necessary two bytes at the end for a check sum, or error correction algorithm.

Table 10.3 Recommended optimized VMS position report

Field	Expression	Data
Hemisphere	North or South	1 bit
Degrees of latitude	whole number 0 to 90	7 bits
Minutes	whole number 0 to 60	6 bits
Fraction of minute	multiples of 0.04	5 bits
Hemisphere	East or West	1 bit
Degrees of longitude	whole number 0 to 180	8 bits
Minutes	whole number 0 to 60	6 bits
Fraction of minute	multiples of 0.04	5 bits
Speed	number with resolution of 0.2 knots	8 bits
Course	whole number 0 to 360	9 bits

The result is that decoding is made simpler because once the header is identified by the receiving system, the active data follows, element by element, until its integrity is verified at the end using the check sum. A desirable byproduct of this approach is that transmission costs of a position report including speed and course are reduced by approximately 20% to 50%.

10.3 Extended Format Position Report

In an ideal world, all VMS position reports would be bit-mapped in an effort to optimize both economy and precision. Whilst such an approach must the be ultimate goal of VMS normalization, it is unrealistic to think that everyone will drop what he is doing and align existing practices to some externally proposed norm. The process will far more likely be one of convergence rather than sudden shifting.

For this reason, the VMS community requires, in addition to a rigorously plotted bit by bit approach, a more flexible report format with data expressed in clear characters with each set of data preceded by an indication of the content of the field. Data presented in such a way could easily and automatically be decoded and then entered into a VMS data base in that system’s own, proprietary format.

In recognition of the fact that its member countries had all developed their own, individual preferences for storing data gathered about fishing vessels, the European Commission, as part of its Europe-wide pilot project, developed just such a format which can easily be extended and modified to meet the position requirements covered in the previous sections. Adopting a variant of this format has the advantage of making conformity with it a simple matter for the 13 European Union coastal states as well as those flag states who have vessels fishing in EU waters.

The fields required to compose a report are as follows:

Table 11.4 Extended position report format elements

Element	Code	Width (max characters)	Mandatory	Remarks
Start of record	SR		X
Type of message	TM	3	X	POS for position; CAT for catch; PLL for poll
Internal number	IR	12	X or RC	VMS vessel ID
Radio call sign	RC	7	X or NA	for vessel ID
Vessel name	NA	40	X + FS
Flag state	FS	3		mandatory with NA Alpha-3 ISO code
Time	TI	4	X	position UTC hhmm
Date	DA	6	X	position date yymmdd
Latitude	LA	5	X	degrees and minutes Nddmm or Sddmm
Longitude	LO	6	X	degrees and minutes Edddmm or Wdddmm
Speed	SP	3		knots and tenths kkt
Course	CO	3		degrees ddd
End or record	ER		X

The actual composition of a report is constructed using a double slash (//) and code to indicate the beginning of a field with a single slash (/) separating the code from the data entry.

Expressed using these elements, a position report for an American vessel named Ishmael, reporting its position of 48 degrees 16 minutes North latitude, 33 degrees 51 minutes West longitude, steaming at 9.3 knots on a course of 271 degrees at 8:25 pm on 19 December 1998 would take the following form:

//SR//TM/POS//NA/ISHMAEL//FS/USA//TI/2025//DA/981219//LA/N4816//LO/W3351//SP/093//CO/271//ER

Furthermore, it is a simple matter to add new data sets by defining additional elements with the creation new two letter codes. This, as we shall see, makes the approach a useful one in defining an approach to catch reporting. The validity of this approach was apparent when the Norwegian Directorate of Fisheries, in the context of its VMS obligation toward the Northwest Atlantic Fisheries Organization (NAFO) extended the original EU approach to cover virtually all areas of communications with the vessels.