MODIFICATION DES CODES DETERMINES PAR DES TABLE - PROCEDURES 6 septembre 2007 (Joël Martellet, WMO, World Weather Watch, Data Processing and Forecasting.

Présentation au sujet: "MODIFICATION DES CODES DETERMINES PAR DES TABLE - PROCEDURES 6 septembre 2007 (Joël Martellet, WMO, World Weather Watch, Data Processing and Forecasting."— Transcription de la présentation:

1 MODIFICATION DES CODES DETERMINES PAR DES TABLE - PROCEDURES 6 septembre 2007 (Joël Martellet, WMO, World Weather Watch, Data Processing and Forecasting Systems)

2 AMENDER LES CODES DETERMINES PAR DES TABLES Procédures Générales Tous les amendements à BUFR, CREX et GRIB doivent être proposés par écrit au Secrétariat de l OMM. La proposition doit spécifier les besoins, les objectifs et les implications des amendements et donner le nom d un point de contact pour les aspects techniques. L Équipe d Experts sur la Représentation des données et des Codes sous la Commission des Systèmes de Base (CSB), soutenu par le Secrétariat, valide ensuite la proposition exprimée et répond aux besoins d une manière appropriée. Ce qui arrive ensuite dépends du fait que la proposition qui conduit à un projet de recommandation implique un/des changement(s) à la structure du code ou des additions dans les tables.

3 Changement de la Structure : exemple Section 1 BUFR Nouveau format proposé pour la date

4 Changer la Structure Quand la solution recommandée développée par l'EE/RDC nécessite des changements à la structure de BUFR ou CREX, la recommandation doit être acceptée par la session de la CSB et ensuite approuvée par le Conseil Exécutif de l'OMM. Cependant, elle doit d'abord être acceptée par le président du GASO sur les Systèmes et Services d'Information, qui s'assurera (avec l'aide de la EE/RDC) de la validation (encodage/décodage des messages par deux systèmes indépendants) (e.g. ECMWF et NCEP-USA) avant toute considération par la CSB. Ceci doit être fait assez en avance afin que la recommandation proposée puisse être publiée dans un document de pré-session au moins 3 mois avant la Session de la CSB.

5 Autres changements importants Addition dans la Table C de BUFR ou de CREX dun nouvel opérateur : –Ceci implique une nouvelle fonction pour lencodeur et le décodeur, et donc des modifications de programmes.

6 Amendements qui ne nécessitent pas un changement sérieux des programmes encodeurs/décodeurs Type de changements concernés –Additions aux Tables B (BUFR/CREX), D (BUFR/CREX) et Tables de Code ou d'Indicateurs Ajustement des Applications –le logiciel Encodeur doit avoir accès à la nouvelle version des Tables de Code ou d'Indicateurs. Il doit être changé pour insérer la nouvelle valeur si elle doit être utilisée –le logiciel Décodeur doit avoir accès à la nouvelle version des Tables (A, B, D) de Code ou d'Indicateurs, mais le programme lui-même n'a pas à être changé –Les applications en aval (au-delà du décodeur) doivent être mises à jour pour utiliser (ou ignorer) la nouvelle donnée

7 Amendements qui nécessitent un changement sérieux des programmes encodeurs/décodeurs Type de changements concernés –Changements de la structure du code (nouvelle édition) ou introduction de nouveaux opérateurs dans la Table C Approbation et mise en oeuvre –Forcément par la session de la CSB et Le Conseil Exécutif –Fréquence maximum: tous les deux ans Ajustement des Applications –L'encodeur doit être modifié et utiliser si besoin le/les nouveaux opérateurs –Le décodeur doit être modifie –Les applications en aval (au-delà du décodeur) doivent être mises à jour pour utiliser (ou ignorer) les nouvelles données

8 Additions aux Tables(1) En principe on ne fait que des ajouts aux tables, on ne modifie pas les entrées. Pourquoi? A cause des archives, on veut toujours garder la facilité de décoder les vieux paramètres. Les additions aux Tables peuvent, en principe, suivre le même processus d'acceptation que pour les changements à la structure du code. Cependant, les additions aux tables, sont de bien loin, moins dérangeantes que les changements à la structure des codes. Elles sont aussi demandées plus souvent et avec beaucoup plus d'urgence. Pour cela une procédure spéciale a été développée par le Secrétariat de l'OMM pour offrir une nécessaire flexibilité afin de répondre avec urgence aux besoins des usagers entre les Sessions de la CSB. Ce système d'approbation s'appelle la "Fast Track". Avec cette procédure, la recommandation n'a pas besoin d'être approuvée par toute la CSB et le Conseil Exécutif, pour être utilisée pré- opérationnellement. Il suffit de l'approbation des présidents de l'EE/RDC et GASO/SSI, et du président de la CSB au nom de toute la CSB.

9 Additions aux Tables (2) De nouvelles entrées dans les Tables sont allouées après considération de la demande par le Secrétariat, et approbation par les présidents de l'EE/RDC et GASO/SSI Puis ces nouvelles entrées sont listées dans un fichier du serveur Web OMM appelé: New entries awaiting validation Puis la validation de ces nouvelles entrées doit être effectuée et démontrée aux présidents de l'EE/RDC et GASO/SSI qui recommanderont au Président de la CSB de déclarer ces nouvelles entrées pré-opérationnelles Validation = encodage/décodage de messages avec les nouvelles entrées par deux systèmes indépendants (e.g. ECMWF et NCEP-USA) Puis les entrées validées (descripteurs d'élément, de séquence, codes dans une table) sont conservées dans un autre fichier sur le Web OMM: pre-operational entries, et elles peuvent être utilisées pour échanges expérimentaux pré-opérationnels entre centres. Finalement, tout ceci sera approuvé à la première session de la CSB et par le CE pour mise en œuvre opérationnelle tous les deux ans.

10 Dans tous les cas, les Membres de l'OMM doivent être prévenus des amendements approuvés suffisamment tôt pour avoir au moins une période de trois mois entre la réception de la notification et la date de la mise en œuvre opérationnelle.

11 Comment approuver des additions aux Tables de Codes (résumé - exemple) Le groupe OMM des codes (ETDRC) se réunit une fois par an ( et aussi beaucoup d'échanges par email) Les amendements sont validés, puis approuvés et déclarés pre-opérationnels au moins une fois par an La CSB recommande tous les deux ans (e.g. Automne 2008) Le Conseil Exécutive approuve (Printemps 2009), puis: Opérationnel le premier mercredi après le 1er novembre (2009 ou 2010) (donc, il y a toujours une année de délai après la Recommandation par la CSB) Les Codes traditionnels (SYNOP, SATOB, etc.) ne doivent plus être modifiés (excepte pour laviation!) Les nouveaux besoins doivent être satisfaits par la migration à BUFR ( CREX si nécessaire)

12 MERCI POUR VOTRE ATTENTION Questions???