10. FORMAT DES DONNÉES

La définition de formats de données s’apparente à la conception d’une méthode de classement: demandez à une douzaine de personnes de concevoir la méthode la plus efficace pour combiner les catégories et vous finirez avec une douzaine d’approches différentes. La définition de formats de données pour le SSN possède un degré supplémentaire de complexité: plusieurs milliers de navires sont déjà impliqués dans des schémas de SSN, la plupart d’entre eux fondés sur des formats de données prioritaires. L’établissement de normes et de standards, dans ce contexte, réclame de chaque partie impliquée une rigueur technique mêlée à des qualités de souplesse et de diplomatie.

La vaste majorité des systèmes SSN actuels est basée sur le système Inmarsat-C et le format des données de position utilisé par ces terminaux est alternativement basé sur les recommandations de l’Organisation maritime internationale dans sa partie relative à la convention SOLAS et sur l’actuel SMDSM.

De plus, les données sont condensées selon un procédé qui attribue des positions spécifiques dans le message à des ensembles spécifiques de données, restreignant ainsi la taille du message au minimum. On peut illustrer ce type de fonctionnement par exemple, par les modalités de transmission de la position, dans un rapport donné, qui est exprimée en latitude nord ou sud, et en longitude est ou ouest.

Une transmission normale de données non spécifiées nécessiterait au minimum cinq bits pour exprimer les lettres N, S, E ou W. Si toutefois, nous programmons que l’information pour communiquer la latitude et la longitude sera transmise en deux champs spécifiques pour un message donné, nous n’avons besoin que d’un bit pour faire la différence entre le nord et le sud, et un second bit pour distinguer l’est de l’ouest. Les autres champs peuvent être compressés de la même façon. Le résultat est que les messages sous forme de données condensées sont beaucoup plus courts que ceux exprimés en données brutes, qu’ils sont mieux adaptés à l’automatisation du traitement des données au sein d’un système de SSN, et induisent un coût des communications minimal.

En dépit de ces avantages, il faut admettre que le format des rapports de position actuellement utilisé par Inmarsat n’est pas optimisé pour le SSN dans la mesure où il utilise un certain nombre de champs qui ne concernent pas les opérations de SSN. Il permet, par exemple, pour les messages macro codés, la communication de paramètres qui nécessitent une saisie manuelle.

Néanmoins, en dépit du fait que ce format, qui n’a pas été développé dans la perspective d’une utilisation SSN, ne soit pas spécifiquement adapté à cette application, c’est à raison qu’un opérateur SSN l’intégrera comme l’une des options d’un système évolutif. C’est pourquoi de nombreux navires qui participent actuellement au SSN sont déjà programmés pour transmettre ce format. Sa mise au rebut signifierait que les participants à l’actuel SSN et ceux qui sont équipés d’Inmarsat-C et susceptibles d’être intégrés dans un futur système SSN, devraient faire l’objet d’une reprogrammation.

D’un autre côté, à ce stade précoce de développement du SSN, ce serait une opportunité manquée que de ne pas définir un format optimisé de données SSN. De surcroît, c’est faire montre de prudence que d’établir un format qui donne aux usagers de la flexibilité dans l’organisation des données.

De tels rapports seraient de façon inhérente, plus longs, mais beaucoup moins restrictifs et par conséquent, pourraient être acceptés par tout utilisateur qui, pour une raison ou pour une autre, trouverait que les approches faisant appel à des données condensées ne sont pas encore compatibles avec leurs opérations.

Il semblerait donc que la solution soit de déclarer trois formats recevables pour les rapports SSN, et que tous les opérateurs SSN programment leur système afin d’accepter des rapports dans n’importe lequel de ces trois formats. En limitant ainsi les variables, les divergences entre les autorités nationales et de l’une à l’autre seraient limitées et le terrain préparé pour la convergence vers un futur format standard unique et universel.

Ce serait à la fois une grave erreur et contre productif de ne pas incorporer les standards internationaux existants là où ils sont applicables. Ceux qui trouvent une place naturelle dans nos formats de données sont le jeu de caractères ISO 8859.1, le code pays ISO 3166, la représentation des dates et heures ISO 8601 et les règles de syntaxe ISO 9735 EDIFACT.

10.1 Le rapport de position Inmarsat

Les rapports de position Inmarsat sont exécutés selon des séries de un à trois paquets de 15 octets. Comme c’est le cas avec tous les systèmes de communication, le rapport commence avec l’en-tête constitué de données spécifiquement administratives identifiant le type de message, l’expéditeur et l’adresse. Pour cette raison, le premier paquet a moins de place pour les données requises par l’utilisateur, et parce que ce premier paquet se termine, conformément au standard maritime, par presque trois octets réservés à un message codé, les données de cap et vitesse, lorsqu’elles sont transmises, doivent l’être au sein d’un second paquet.

Après l’en-tête du premier paquet, 39 bits sont mis à part pour la position des données, organisés comme suit:

Tableau 10.1 Rapport de position Inmarsat, position seule

Le reliquat du premier paquet est utilisé pour la définition d’un message codé et son attribut ou variable. Le deuxième paquet commence alors, après l’en-tête, avec les données de vitesse puis cap de la façon suivante:

Tableau 10.2 Rapport de position Inmarsat, ajout du cap et de la vitesse

Après l’ajout du cap et de la vitesse, huit octets sont disponibles pour des données définies par l’utilisateur, qui peuvent être utilisées pour la transmission, sans coût additionnel, d’autres éléments disponibles à bord tels que la température, la vitesse du vent, l’humidité ou la température des eaux de surface.

10.2 Le rapport de position SSN optimisé

Sur une base de transmission champ par champ, il est impossible de transmettre des données de position de façon plus économique que celle effectuée au sein du rapport de position maritime d'Inmarsat. Il est, néanmoins, possible d'éliminer des champs de données superflues et de compresser le rapport en un seul ensemble.

Si, par exemple, nous attribuons un six octets entier pour l’information de l’en-tête - soit six bits de plus ce que requiert Inmarsat - ce qui permet de répondre aux besoins de tout système ultérieur, un paquet de 15 octets peut intégrer tous les champs de données, c’est à dire la position la vitesse et le cap, laissant encore la place aux deux octets nécessaires à la fin pour une somme de contrôle ou un algorithme de correction d’erreur.

Tableau 10.3 Rapport de position SSN optimisé préconisé

Le résultat est que le décodage devient plus simple parce qu’une fois que l’en-tête est identifié par le système récepteur, les données actives suivent, élément par élément, jusqu’à ce que leur intégrité soit vérifiée à la fin, en utilisant la somme de contrôle. Un effet dérivé très positif de cette approche est que le coût de la transmission d’un rapport de position incluant le cap et la vitesse est réduit approximativement de 20 à 50 pour cent.

10.3 Le rapport de position au format étendu

Dans un système idéal, tous les rapports de position SSN seraient condensés dans un souci d’une économie des moyens et d’une précision optimales. Bien qu’une telle approche doive constituer le but ultime d’une normalisation du SSN, il est irréaliste de songer que chacun va abandonner sa méthode et aligner ses pratiques existantes sur une norme imposée par une autorité extérieure. Il s’agira plus vraisemblablement d’un procédé de convergence plutôt que d’un basculement soudain.

Pour cette raison, la communautarisation du SSN nécessite, en plus d’une approche rigoureuse de relevés bit par bit, un format de rapport plus souple, avec des données exprimées en caractères clairs et des groupes de données précédées d’une indication du contenu du champ. Une telle présentation des données permet un décodage aisé et automatique, puis un stockage dans une base de données SSN formatée selon ce propre système spécifique.

Se fondant sur la reconnaissance du fait que ses Etats membres ont tous mis en œuvre leurs propres préférences individuelles pour stocker les données accumulées sur des navires de pêche, la Commission européenne, dans le cadre de son projet pilote européen, vient de développer un format de la sorte, qui peut aisément être étendu et modifié pour se conformer aux exigences des rapports de position explicitées dans les sections antérieures. L’adoption d’une variante de ce format a l’avantage de permettre aux 13 Etats côtiers membres de l’Union européenne ainsi qu’aux Etats tiers dont les navires pêchent dans les eaux communautaires, d’être en conformité avec ce format de façon simple.

Les champs requis pour la constitution d’un rapport sont les suivants:

Tableau 11.4 Eléments du format de rapport de position étendu

La composition actuelle d’un rapport est formée en utilisant une double barre oblique (//) et un code pour indiquer le début d’un champ, une simple barre oblique (/) marquant la séparation entre le code et la donnée.

Exprimé de telle sorte, voici est la forme que prendrait le rapport de position d’un navire américain appelé Ishmael, émettant un rapport de position à 48 degrés, 16 minutes de latitude nord, 33 degrés 51 minutes de longitude ouest, faisant route à 9,3 nœuds avec un cap de 271 degrés, à 20 h 25 mn, le 19 décembre 1998:

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

Malgré une taille de message substantiellement plus importante, - en données ASCII, il utilise approximativement 92 octets, soit environ trois fois le rapport de position Inmarsat et six fois le rapport de position SSN optimisé -, il a le bénéfice de la souplesse et de l’universalité. Même si l’ordre des éléments est modifié, le rapport reste facilement décodable. Il est également à noter que, pour peu que les opérateurs SSN soient simplement capables de s’accorder sur l’ordre des éléments, une certaine économie pourrait être réalisée en éliminant les champs du code de désignation.

De plus, c’est chose aisée que d’ajouter de nouvelles données en définissant de nouveaux éléments additionnels avec la création de nouveaux codes à deux lettres. Ceci, comme nous le verrons, rend cette conception utile dans la définition d’une approche pour les rapports de capture. La validité de cette approche s’est manifestée lorsque la Direction des Pêches norvégienne, afin de s’acquitter de ses obligations en matière de SSN au sein de l’Organisation des pêches de l’Atlantique du Nord-Ouest (OPANO), a utilisé l’approche européenne originelle en l’étendant afin de couvrir virtuellement tous les champs de communication avec les navires.