FR 2809510 A1 20011130 FR 0006623 A 20000524 PROCEDE DE FORMATION ET D'UTILISATION D'UNE BASE DE DONNEES D'EVENEMENTS. DESCRIPTION Domaine technique L'invention se situe dans le domaine du recueil et de l'exploitation de données numériques relatives à des événements de chaînes ou services de télévisions. Elle concerne plus particulièrement un procédé utilisé pour conspruire urië--base de données sur...,``'c1é `:.tels événer#ents ainsi que l'emploi de la base de Description de l'arrière plan technologique Les fournisseurs ou diffuseurs de service (c'est-à-dire d'émissions) de télévision ou radio diffusent des tables de données relatives aux événements qui peuvent être captées par un utilisateur d'un appareil de réception de ces événements, par exemple un récepteur de télévision muni d'un décodeur numérique ou d'un décodeur numérique alimentant un récepteur de télévision. Avant de décrire d'avantage l'art antérieur il convient de faire quelques rappels sur le vocabulaire et le genre de normes qu'il est préférable de connaître pour bien comprendre ce qui sera expliqué ensuite. Les diffuseurs de services par exemple les diffuseurs d'émissions de télévision diffusent non seulement des événements qu encore programmes de télévisions, tels que des films, des matchs, des émissions de variété, mais aussi d'autres informations notamment sur les programmes prévus d'émissions, en principe selon un standard préétabli. Par exemple en Europe la norme DVB-SI ETS 300 468 et le rapport technique ETR 211, prévoient un format pour des tables d'information sur les événements, (évent information tables, EIT). Dans les explications qui vont suivre, les exemples seront, pour fixer les idées, tirés de cette norme. De même, le vocabulaire employé aura la définition prévue par cette norme et ce rapport. I1 est cependant évident que l'invention n'est pas dédiée uniquement,->à une application utilisant cette nôrmë`:. Dans la suite de la descrip,ton _# on s'int:éréssera aux EIT dites "schedule" c'est-à-dire relatives aux programmes. Ces tables EIT programmes permettent de décrire jusqu'à 31 jours de programme pour un service. Les informations spécifiques à un programme sont par exemple son titre, la durée de celui-ci, son genre etc. Les données SI permettent de réaliser des applications de type Guide Electronique de Programme. La norme DVB-SI ETS 300 468 définit des informations hors descripteur, des informations facultatives associées aux descripteurs et des informations privées contenues dans des descripteurs privés. Les descripteurs sont des informations de longueur variables telles que par exemple un titre de film ou d'émission ou encore un résumé décrivant le programme. Des informations hors descripteur sont présentes pour chaque événement. Quelques exemples en sont donnés ci- dessous. Event Id : Identifiant unique d'un événement pour un service ayant une identification "service Id" donnée (une chaîne). StartTime : Instant de début de diffusion de l'événement (format UTC GMT). Duration : Durée de l'événement. FreeCaMode : Critère d'accès à l'événement. Des exemples d'informations facultatives associées aux descripteurs DVB-SI sont citées ci- dessous short_eventdéscr-iptor : Titre et résumé de 1 `-événement . @.`.. _ '-côntent descriptor : ce descripteur correspond à une classification de l'événement. Enfin des informations associées aux descripteurs sont privés c'est à dire spécifiques d'un diffuseur. A titre d'exemple, un descripteur spécifique au contrôle d'accès peut être utilisé pour décrire des événements couramment appelé PPV (pay per view), exigeant, pour être vu, un paiement de l'utilisateur Des informations plus complètes sur les descripteurs de tables EIT figurent au paragraphe 4.2.4 du rapport ETSI ETR 211. Les informations EIT "schedule" relatives aux programmes d'un même diffuseur peuvent être envoyées par exemple, sur le flux MPEG-2 sur une ou plusieurs tables ou sous tables chacune de ces tables ou sous tables ayant un identifiant de table "table id" (Tid) en fenêtres fixes ou glissants. En fenêtre glissante les données transmises sur la première des tables identifiée par son Tid correspondent au jour courant. En fenêtre fixe les données transmises sur la première des tables identifiée par son Tid correspondent au premier jour du mois. La norme DVB-SI recommande que les événements soient transmis dans l'ordre chronologique. Les tables des différents diffuseurs sont diffusées périodiquement, avec des fréquences de répétition dont les minima.-'sont fixés- au-paragraphe 4.4 de lariorrmé' ETR 211.. 11e recommande également que la descriZ des événémeïts soit organisée en sections -comportant chacune un maximum de 4096 octets avec au minimum une section par période de trois heures de programme. Huit sections forment un segment. Une sous table ne comporte pas plus de 32 segments, soit 256 sections au total. On entend par application un logiciel permettant d'exécuter des fonctions, par exemple de recherche et de présentation d'informations. Les applications de guide de programme (connues aussi sous le nom d'EPG pour Electronic Program Guide) sont installées sur des décodeurs qui disposent de peu de mémoire. Aussi il n'est pas possible de récupérer l'ensemble des informations d'un seul coup et de les mémoriser avant de les parcourir. La solution de saisie au vol (catch on the fly) est alors retenue. Cette solution consiste à ne récupérer sur le flux de données diffusées que l'information nécessaire pour une application donnée, en fonction de l'application et des paramètres de cette application. Par exemple si un spectateur souhaite savoir ce qui sera diffusé le jour courant sur une chaîne, à partir de 20 heures, seules ces informations seront recherchées sur le flux, mémorisées et exploitées pour être présentées de façon ordonnée et compréhensible pour le spectateur. De ce fait la quantité de mémoire utilisée est réduite. En revanche, le temps d'accès à de nouvelles informations est long puisqu'il faut attendre que les informations recherchées soient diffusées, recueillies et traitées. L'exploitation des requêtes du spectateur est alors très ralentie. Ce choix a également amené à ne _pas utiliser les tables dë#f-nies par la normes DV1=1SI, mais des.tables privées plus légères que les "EIT s.ched#le". _ :On voit maintenant apparaître des- décodeurs appelés aussi "set top box, STB) " dotés d'une mémoire limitée, par exemple 8 Mega-octets et il devient possible de mémoriser des données relatives aux programmes et de les exploiter pour délivrer rapidement les informations souhaitées, par exemple par un téléspectateur. Brève description de l'invention. On constate que malgré la présence d'une capacité mémoire non négligeable, cette capacité est encore largement insuffisante pour stocker toutes les tables d'information sur les événements et que par conséquent il importe de sélectionner les informations que l'on va mémoriser, et de les organiser pour occuper au mieux la place mémoire disponible. L'invention vise donc un procédé de recueil, dans une mémoire, d'informations relatives aux programmes qui permette une utilisation optimale d'une capacité de cette mémoire de recueil. Elle vise à permettre le recueil de ces données en parallèle. Elle vise aussi à organiser cette mémoire en base de données qui soit d'un accès rapide et facile. On veut dire par là que la présentation au spectateur des données les plus couramment recherchées ne nécessite que peu d'instructions, ceci en raison de la façon dont la base est organisée. Dans un mode préféré de réalisation, le procédé selon l'invention permet d'une part de détecter très rapidement qu'une information stockée en mémoire n'est pas à jour et d'autre part de la corriger. A ;toutes ces ---fins, l'invention est ré-#1âtive à un--,, pVocédé de construction d'une base de@---@ddnnées relativë --à des information d'événements- diffusées périodiquement sous forme d'un flux de données par un ou plusieurs fournisseurs de services dans lequel a) on constitue un fichier de différents services identifiés susceptibles de diffuser des informations d'événement, b) on extrait et on stocke temporairement une partie au moins d'une série d'informations sur les événements diffusés par chaque service, c) on sélectionne pour chaque événement les informations que l'on souhaite stocker pour une longue durée, d) on détermine le nombre d'ôctets contenus dans les informations sélectionnées pour chaque événement ainsi que la somme de ces quantités d'informations pour l'ensemble des événements de chaque service, e) on recherche une zone d'adresses mémoire de taille suffisante pour y stocker de façon non fragmentée toutes les informations sélectionnées relatives à tous les événements d'un premier service les uns à la suite des autres, f) on recopie dans les zones d'adresses non fragmentées trouvées à l'étape e) chacun des événements du premier service les uns à la suite des autres, g)on complète le fichier des services par l'adjonction, dans une fiche de ce fichier correspondant audit premier service d'un pointeur donnant l'adresse du premier événement de ce service, h) on recommence les étapes d) à g) pour chacun des services du fichier des services, i) on efface de la mémoire les informations extraites- à l'étape.b) . __ De préférence, on complète l'étape d) #en_Ï#énant un conpEe du nombre d'événements pour déf finir la place mémoire nécessaire à la création d'un tableau de pointeurs donnant chacun l'adresse du début d'un événement de ce service, on complète l'étape e) en recherchant également un autre groupe d'adresses mémoire pour y loger le tableau de pointeurs dont chaque pointeur donne l'adresse du début d'un événement, et enfin lors de l'étape f) on inscrit dans le tableau des pointeurs, pour chaque événement, l'adresse du début des informations relatives à cet événement. Lorsque les opérations a) à i) ci-dessus décrites sont terminées, on dispose en mémoire de l'information utile à un téléspectateur pour connaitre par service les événements auxquels il peut avoir accès, et sélectionner ceux qui l'intéressent. Il sera vu plus loin qu'il lui est possible aussi de réaliser facilement une sélection parmi des événements de plusieurs services, ces événements ayant une qualité commune identifiable au moyen des informations sur les événements, par exemple une information par genre d'événement, films, sports, variétés. La place occupée par les informations sélectionnées est minimum puisque l'on a ôté des informations reçues toutes les informations non directement utiles au téléspectateur ou à une application pour faire des recherches ou des sélections parmi les événements. En addition aux informations propres aux événements on utilise pour l'exploitation de ces informations uniquement les pointeurs à raison de un pointeur par événëment. On remarque que, par exemple en envi-r-ônrèment JAVA -.on-,-à- une paire de poignées, correspondant l'une à une adresse logique et l'autre à l'adresse physique. Selon l'invention on a une seule adresse ou pointeur par service ou dans le cas où l'on a créé un tableau de pointeurs par événement, une seule adresse ou pointeur par évènement. Les avantages de ce tableau de pointeurs, consommateur d'un peu de mémoire apparaîtront plus tard, lors de la description d'un mode d'utilisation de la mémoire. On gagne donc aussi la place mémoire correspondant dans le cas le plus défavorable à une adresse par événement. On remarque aussi que les opérations a) à i) peuvent être exécutées de façon différente sans que le résultat final soit changé. Ainsi par exemple on peut ne recueillir que les informations sur les événements relatives à un seul service, traiter ces informations selon les étapes a) à i) à l'exception de l'étape h), puis recommencer le même traitement pour chacun des autres services. L'avantage de cette dernière solution est que le volume instantané de mémoire nécessaire est moindre, ce qui peut être utile. L'inconvénient de cette dernière façon de faire est que l'on ne dispose pas dès le départ de l'information quant à tout le volume nécessaire au stockage des informations. De préférence les fiches individuelles relatives à chaque service sont chaînées, cela veut dire que chaque fiche contient un pointeur donnant l'adresse d'un service suivant, une dernière fiche ayant un pointeur donnant l'adresse d'une première fiche. Dans le mode préféré de réalisation les fiches individuelles rela-tivës- à chaque serviéë :: sont doublement chaînées. Cela veut dire que cha#mLe-L`_f-iche contën't-- en outre un pointeur donnant l'adresse d'un service précédant une première fiche ayant un pointeur donnant l'adresse d'une dernière fiche. De la sorte on peut parcourir la liste des services dans un sens croissant ou décroissant. Ainsi dans le mode préféré de réalisation chaque fiche de serveur contient trois pointeurs, un pointeur donnant l'adresse du premier événement du service, un pointeur donnant l'adresse du début de la fiche du service suivant et un pointeur donnant l'adresse du début de la fiche du service précédant. Dans un mode avantageux de réalisation, on simplifie la mise à jour des données de la façon suivante. Tout d'abord il est nécessaire, pour ce mode de réalisation que le ou les fournisseurs de service, ou au moins certains d'entre eux, diffusent une table de mise à jour. Cette table, outre des données d'identification, contient, essentiellement des indicateurs relatifs à des numéros de version du service et de chaque événement. Pour distinguer l'un de l'autre ces numéros de version, les numéros de version du service sont appelés "compteur de version du service" ou "compteur de version" et le numéro de version de l'événement est appelé numéro de version. Evidemment, lorsque les informations sur un événement changent, le numéro de version de l'événement change et aussi en conséquence le compteur de version du service. La comparaison du compteur de version de service actuellement diffusé avec un compteur de version de service précédemment stocké permet de savoir s'il -est nécessaire,-, *ou non (le faire un nouvel enregistrement de données de ce service. Avec le numéro de ve#s.ô_n de l'événetient on sait quelle ou quelles données d'événement ont changé. On évite ainsi de repeigner systématiquement toutes les données. La table privée de mise à jour peut aussi contenir un drapeau de mise à jour générale indiquant qu'un grand nombre de données ont changé, d'où suit un réenregistrement des données de ce service. Brève description des dessins L'invention sera maintenant décrite en regard des schémas annexés destinés à illustrer et faciliter la compréhension du procédé selon l'invention et de variantes de réalisation. Dans ces schémas la figure 1 représente une partie d'une base de données constituée selon l'invention, la figure 2 représente la constitution d'une zone compacte d'événements d'une base de données constituée selon l'invention,, la figure 3 représente une autre partie d'une base de données constituée selon l'invention, la figure 4 représente une zone compacte et un tableau associé d'une base de données constituée selon l'invention, la figure 5 illustre l'organisation d'un service dans une base de données constituée selon l'invention, les figures 6 et 7 illustrent des étapes de la constitution d'un fichier des services les figures 8 et 9 illustrent des étapes de la constitution d'une liste chaînée d'événements la @ figure 10 - illustre des étapes" `de - la constitution d'une succession de listes -- éh -nées d' événements les figures 11 à 13 illustrent des étapes de la constitution d'une zone compacte d'événements et d'un tableau de pointeurs associés et l'aspect final de cette zone et des liens associés, les figures 14 à 16 illustrent des étapes de la constitution d'une succession de zones compactes d'événements et de tableaux de pointeurs associés et l'aspect final de cette succession de zones et des liens associés, les figures 17 et 18 illustrent des étapes de la constitution d'un tableau de pointeurs pour une consultation sur critères déterminés et l'aspect final de ce tableau et de ses liens avec les événements sélectionnés. Dans les figures les mêmes éléments portent le même numéro de référence éventuellement associé avec un indice prime ou seconde s'Ll s'agit du même élément dans une phase de construction. Description d'un mode de réalisation de l'invention. Un exemple de système destiné à réaliser le procédé selon l'invention va être maintenant décrit. Le système qui va être décrit est composé de quatre modules distincts Un moteur d'acquisition de tables d'informations sur les événements SI (EIT schedule) - un module analyseur de tables (EIT) - un module gestionnaire de mémoire - un module de consultation de mémoire La` fonction de chacun de ces mddulès en relâtion avec les autres modules sera touE--`cTT#ibord décrite" puis chacun des modules sera décrit de façon plus détaillée. Le module moteur d'acquisition de table SI (EIT schedule). fait l'acquisition des EITs de l'ensemble des services afin que les données soient disponibles auprès des applications le plus rapidement possible. Pour ce faire le chargement en parallèle est privilégié. Le module analyseur de table est chargé de parcourir les tables EITs et d'en extraire les données pertinentes qui sont formatées pour être stockées en mémoire. Le module de gestion de mémoire est chargé de la gestion du stockage des unités élémentaires représentant un programme ainsi que de l'organisation de la mémoire. Le module de consultation de mémoire est chargé de donner aux applications une 'bibliothèque de fonctions destinées à parcourir la base de données d'événements et d'établir des listes triées suivant certains critères. La mise en #uvre de ces quatre éléments au sein d'un décodeur ou "set top box" permet d'avoir un outil complet garantissant l'accès à l'ensemble des informations SI d'un bouquet tout en reposant sur le standard DVB-SI. Chacun de ces quatre éléments sera examiné plus en détail ci-après. Le module moteur d'acquisition des tables EIT gère l'acquisition sur le flux des tables _EIT "Schedule",,# leur anâ-lysë (via l'analyseur)leur stockage .en mémoire via le gestionnaire de mémô@irë: Ce moteur.: gére également, selon une caractéristique avantageuse de l'invention, la mise à jour des informations contenues dans la mémoire lorsque des modifications à ces informations ou de nouveaux événements sont transmis sur le flux. Les tables EIT "Schedule" peuvent représenter un débit important de données en fonction du nombre d'événements et du nombre de services présents. Il s'ensuit que, surveiller en permanence l'ensemble des tables EIT pour détecter des évolutions, représente un temps relativement long. Pour raccourcir le temps de détection avantageusement, l'acquisition des données des tables EIT Schedule est basée sur l'utilisation d'une table privée intitulée GUT (Guide Update Table). Cette table est établie essentiellement à partir des tables de description de service (SDT). Ces tables donnent pour chaque service présent sur ,un flux de transport des informations générales sur le service, en particulier une identification du service et un numéro de version (version number) sur 5 bits qui est augmenté de 1 chaque fois qu'il y a une modification dans une sous table représentant un service. Elle est complétée ensuite par un compteur de version (service counter) qui est modifié chaque fois qu'il est détecté que les informations relatives à un événement ont été changée. Ce compteur de version est tiré d'une table d'information sur les événements (EIT) qui comporte un numéro de version sur 5 bits (version number), qui est incrémenté de 1 lorsque les informations relatives à un événement dnt été changéés. En conséquence, la table GUT contient=ia.-.lîste de tous` les services contenant des événements présents sur le flux de transport des tables de données (transport streams). Ces services contenant des événements sont identifiés par leurs identifications de service (service_id). Cette table GUT permet de surveiller les évolutions de l'ensemble des événements présents sur le flux de transport en ne surveillant que cette seule table. A chaque service présent dans la table GUT est associé, comme indiqué ci-dessus, un compteur de version du service (service counter), un numéro de version (version number), ainsi qu'un drapeau de mise à jour général (full update_counter). Lorsque les événements d'un service donné sont modifiés sur le flux, il y a changement du compteur de version (service çounter) du service correspondant et du numéro de version (version number) de la table GUT. Lorsque des services contenant des événements sont ajoutés sur le flux, cils sont ajoutés dans la table GUT et le numéro de version (version number) de la table GUT est changé. Les services retirés du flux de transport ne disparaissent de la table GUT que lors d'une mise à jour générale de cette table. (modification du drapeau de mise à jour générale "full update_counter"). Lorsque l'ensemble (ou une grande partie) des services sont modifiés, il est préférable d'indiquer ce changement par une modification de la valeur du "full update_counter" (bien qu'il soit possible de ne modifier que le numéro de version de la table (version number), ceci pour des raisons -.de performances. Afin d'optimiser le temps de chargemërit-` des données"'des tables d'informations sur les services (EIT) présentes sur le flux, plusieurs requêtes de tables EIT sont gérées en parallèle. On distingue le nombre de requêtes utilisées pour une acquisition complète des données présentes sur le flux lors d'un premier chargement ou après modification du drapeau de mise à jour général (full update_counter) du nombre de requêtes utilisées pour des mises à jour partielles des données de la mémoire. L'application fixera ces valeurs au moteur d'acquisition de données. La machine d'état du module moteur d'acquisition de données est séquencée par des pilotes de démultiplexeurs. Le fonctionnement général est géré par deux drapeaux internes : un drapeau commun sur le type d'acquisition, intitulé "EngineMode" et un drapeau pour chaque instance de filtre, intitulé EngineState. Le drapeau commun sur le type d'acquisition, intitulé "EngineMode" a un état initial appelé "engineModeInit" "engineModeInit" correspond à la première acquisition après l'initialisation. Un autre état "engineModeBuild" correspond à un chargement complet de la mémoire suite à une modification complète de la diffusion des tables EITs, détectée par une nouvelle valeur du drapeau de mise à jour générale "full update çounter" dans la table privée GUT sur le flux par le fournisseur du service. Un autre état de ce drapeau intitulé "enginemodeUpdate" correspond à une mise à jour de la mémoire suite à une modification des données de certains services, cette modification étant détectée @' par un nouveau numéro de-.7' version (version number) de la table GUT alors que lje#_dr_apeau de mise, -à jour générale (full update çounter)* ne change pas de valeur et par des nouvelles valeurs de compteur de service "service counter" aux niveaux de descripteurs de service "service descriptors" contenus dans la table privée GUT transmise sur le flux. Le drapeau pour chaque instance de filtre, intitulé "EngineState" a un état initial appelé "engineStateI-nit": "engineStateInit" correspond à un état initial précédant la pose d'une requête de filtrage. Un état "engineStateInAcq" de ce drapeau correspond à la réception d'un événement suite à une requête de filtrage. Un état "engineStateRetry" de ce drapeau correspond à un traitement de nouvel essais suite à un échec de chargement Les EIT schedule peuvent être envoyées sur le flux MPEG-2 sur plusieurs tables ou sous-tables ayant des identifications de table, table id (plusieurs tables EIT pour un même service). Les identités, tables-id, des tables à charger dépendent du nombre de jours de données à mémoriser dans la mémoire et de la table des segments (selon qu'elle est utilisée en fenêtre fixe ou glissante). Si les EIT doivent être récupérées sur plusieurs tables identifiées par leur identification de table Tid, l'ordre de chargement est "Pour le Service id courant Pour le Tid courant Chargement de l'EIT Passage au prochain TableId (Tid) du service courant FiriPour Passage service suivant dans la GUT - @FinPour" Cet ordre correspond à un chargement de toutes les tables d'un service courant avant de passer au chargement du service suivant selon l'ordre définit par la table GUT. La norme DVB-SI imposant que les événements soient transmis dans l'ordre chronologique, les événements seront mémorisés dans l'ordre chronologique dans la mémoire. Cet ordre a son importance dans la mesure où une extraction chronologique des différents événements d'une chaîne évite une étape de tri des informations. Ainsi, les événements sont dans la mémoire dans l'ordre logique de leur diffusion. Le fonctionnement de l'ordonnanceur d'acquisition du moteur est décrit ci-dessous. Les traitements des cas d'erreur n'apparaissent pas dans cette description. 0) Initialisation duimoteur d'acquisition , le drapeau commun sur le type d'acquisition est mis sur son état initial "encqineModeInit". 1- Acquisition de la table guide de l'utilisateur GUT 2- Table guide GUT acquise mémorisation du numéro de version de la table "version number" et du drapeau de mise à jour général "full update_counter" 3- Construction de la liste des services et mémorisation des valeurs de compteur de service "service counter". Tous les services sont marqués "à acquérir. 4- Acquisition des tables d'information sur -les événements-'= pour les services marqués 'à acqùérir'. Si on vient de (3), n filtres (-xé=`@ar l'application, ou 10 par défaut) sont utilisés car il s'agit d'une acquisition complète. Si on vient de (7) ou (8), (qui seront décrites ci-après) n filtres (fixé par l'application, ou 3 par défaut) sont utilisés car il s'agit d'une mise à jour. Pour chaque table d'information sur les événements EIT, on fait jusqu'à 3 tentatives "retry" en cas d'échec de la première tentative. L'acquisition se termine lorsque toutes les EIT ont été acquises (ou échecs après 3 tentatives "retry") pour une EIT ayant un table-id donné. Les tables EIT d'information sur les événements EIT non acquises après 3 tentatives "retry" restent marquées "à acquérir". Elles seront donc réacquises lors d'une prochaine version de table GUT, voir ci- dessous. Si toutes les tables à acquérir ont été acquises, on passe en (5) décrit ci-après. Sinon retour en (4)_ pour l'acquisition de la table suivante et le même filtre. 5- Acquisition de la table guide d'utilisateur GUT 6- table guide d'utilisateur GUT acquise Si la table de mise à jour du guide GUT courante a le même numéro de version "version number" et la même valeur de drapeau de mise à jour général "full update_counter" qu'une table guide d'utilisateur GUT précédente, on revient en (5) après par exemple 30 secondes (sondage de la table GUT toutes les 30 secondes.). - Y .e. Si-*'la table guidè d'utilisateur GUT côürânte a lé-,---même numéro de version "version number"#@ .-'une valeurs de drapeau de mise à jour général "full update_counter", différente de celui d'une table précédente on passe en (7) décrit ci-après. Si la valeur du drapeau de mise à jour général "full update_counter" de la table guide d'utilisateur GUT courante, est différente de celle d'une table précédente, on passe en (8) décrit plus loin. 7- On met à jour les service_counter des services. On complète la liste des services si de nouveaux services apparaissent en fin de GUT. Si au moins un "service counter" est différent du précédent ou si un nouveau service est apparu dans la liste, les services correspondants sont marqués "à acquérir", et l'on revient en (4). Il est rappelé que les EIT précédemment non acquises après tentative sont déjà marquées 'à acquérir'. 8- Reconstruction de la liste des services et mémorisation des "service counter". Tous les services sont marqués "à acquérir". La mémoire EPG n'est pas réinitialisée Retour en (3). On peut résumer l'organigramme qui vient d'être décrit en disant que après une étape d'initialisation - on crée une table de suivi des mises à jour listant les services et leur associant un numéro de version de service "service counter" et un numéro de version "version number" des événements. - on acquiert les tables d'information sur les événements. correspondant aux services figurant dans la table de mise à jour GUT---- - on renouvelle périodiquement l' acque:i:L:.Qh de la table de mise à jour GUT, et on compare la table courante à la table précédente, - si la table est inchangée et que tous les services ont été acquis précédemment on renouvelle l'acquisition de la table GUT jusqu'à ce que l'on remarque un changement avec la table GUT précédente, - si la table GUT est changée ou si des tables d'information sur les événements n'ont pas été acquises on fait les acqusitions nécessaires pour compléter les informations sur les services, - si un grand nombre de changements sont intervenus, on refait une acquisition complète de la table GUT et des tables d'information sur les événements. Le module analyseur de table d'information sur les programmes EITs sera maintenant examiné. Ce module permet l'analyse des descripteurs contenus dans une section EIT. Le module Engine demande l'analyse section par section dans l'ordre chronologique. Le module moteur d'acquisition Engine passe à l'analyseur une section d'EIT et reçoit en retour les informations sur les événements contenus dans cet EIT. Trois types d'informations sont extraites pour un événement donné, les informations DVB-SI standard hors descripteur, les informations associées aux descripteurs DVB-SI et les informations associées aux descriteurs privés. - les' informations DVB-SI standard `'hors dëbcripteur sont présentes pour chaque événeme-ft-:-ëlles sont définies par la norme DVB-SI ETS 300 468, en voici une liste pour exemple L'Event Id : Identifiant unique d'un événement pour un service Id donné (une chaîne). StartTime : Date de début de diffusion de l'événement (format UTC GMT). Duration : Durée de l'événement. FreeCaMode : Critère d'accès à l'événement. Les informations associées aux descripteurs DVB-SI sont facultatives. Tous les descripteurs facultatifs associés à la norme DVB-SI sont supportés. On peut citer à titre d'exemple short_event descriptor : Titre et résumé de l'événement. content descriptor : genre de l'événement. Les informations associées aux descripteurs privés, une fois spécifiées, n'importe quel descripteur privé peut être supporté per le module d'analyse. A titre d'exemple, un descripteur spécifique au contrôle d'accès est utilisé pour décrire des événements de .type PPV (pay per view). Les informations extraites pour chaque événement sont regroupées dans une structure spécifique qui sert de structure d'échange avec le module chargé de la mémorisation des données. on parle alors de cellule d'échange. Chaque cellule d'échange contient l'ensemble des informations correspondant à un événement. Les cellules d'échange varient d'un projet à l'autre selon qu'elles intègrent des données associées à des descripteurs privés ou non. -- Voici à titre d'exemple quelques does-=`qui peuvent-,t'être associées et retenues pour figurer dans une telle cellule d'échange. event_id 2 octets identité de l'événement */ start_time ; /* 5 octets heure de début de l'événement */ eventFlags ; /* 1 octet drapeau pour les événements payants/ content nibble 1 octet (obits pour un premier niveau et 4 bits pour un second niveau) descriptif de genre 1 et 2 */ duration ; /* 3 octets durée de l'événement Parental_rating ; /* 1 octet code d'information pour les parents */ title_id ; /* 2 octets identité du titre */ prise ; /* 4 octets indication de montant/ evtTitleLen ; /* 2 octets longueur du titre en octets */ Certaines information ne figurent qu'à titre conditionnel, l'une des conditions étant que cette information soit contenue dans le descriptif figurant dans la table. On peut citer à titre d'exemple non limitatif ppvSession ; /* 2 octets numéro de cession purchase win ; /* 1 octet fenêtre d'achat*/ evtSummaryLen ; /*longueur en octets du résumé de l'événement*/ - La-' description chu module mémoire de'- données (SICache) sera maintenant effectuée. -"------ La mémoire de données SI (SICache) est chargée de stocker en mémoire les informations extraites des tables d'informations sur les événements EIT. La solution la plus simple pour stocker ces informations serait de mémoriser les sections de chaque table EIT de chaque service. Une telle solution requiert comme expliqué plus haut beaucoup de mémoire, et ne peut être mise en ceuvre dans un environnement embarqué de type STB 8 Mo. Aussi le module SICache propose une mise en mémoire de façon compacte des informations. Le principe de stockage retenu garantit la compacité des informations, donc l'allocation à l'octet près de ce qui doit être mémorisé. Afin de mettre en #uvre le principe de stockage la mise en mémoire s'effectue en trois étapes. Avant d'exposer la dynamique de construction du cache, rapellons les différents types de données manipulées. La mémoire représente une base de données contenant des services (chaînes), contenant elles mêmes une suite d'événements. Ces notions ont été expliquées plus haut. L'ensemble de la base de données est donc constitué d'un nombre donné de couples, informations sur les services - informations sur les événements de ces services, ou dit d'une façon abrégée couples services/listes d'événements. Un schéma succinct de ces couples, service - liste d'événements, est représenté figure 1. -A chaque service numérotés 1p, p allant- de 1 à @ixn' nombre entier n représentant le rtô'é@_ de services, 11, 12, 1p 1n est associée une zone mémoire compacte 21, 22, 2p 2n. Chaque élément service contient trois pointeurs, deux pointeurs dont l'un donne l'adresse d'un élément service précédent et l'autre l'adresse d'un élément service suivant, afin de définir une liste doublement chaînée entre les différents services, un troisième pointeur donne l'adresse du début d'une zone de données contenant les informations propres à la description des événements de ce service. Naturellement il serait possible de n'avoir qu'un pointeur donnant l'adresse d'un service par exemple un service suivant au lieu des deux pointeurs précédent et suivant. Il sera vu plus loin que ce choix de deux pointeurs facilite le parcours des services sans consommer beaucoup de place mémoire. outre ces trois pointeurs chaque élément service contient des informations appelées ServiceInfo". Ufi exemple d'information figurant dans ServiceInfo est donné ci-après: OnId identité initiale du réseau. du service TsId identité du flux de transport (Transport Stream Id) du service ServId identité du service (Service Id) ServNum Numéro du service ServKey Clé du service nbOfEvent Nombre d'événements que contient ce service signature Signature du service *buildEvents Pointeur vers u né-=-- --liste chaînée d'événements (lors de la construction sinon null) sizeOfBuild : Taille en octets de la totalité des événements mis bout à bout. *eventsDataBase base de données d'événements mis bout à bout **events Tableau contenant les pointeurs vers les événements. La structure de données correspondant à l'événement est composée de deux parties. Une partie contenant des données qui lorsqu'elles figurent sont de longueur (nombre d'octets) constante et une partie dont la longueur est variable d'un événement à l'autre. Certaines des données de longueur constante dites à ce stade facultatives peuvent être présentes ou non. De même, les données de longueur variable peuvent être présentes ou non. Des exemples de données de longueur constante qui figurent dans tous les événements et qui pour cette raison sont dites communes à tous les événements .sont données ci-après event_id 2 octets identité de l'événement */ start_time ; /* 5 octets heure de début de l'événement */ eventFlags ; /* 1 octet drapeau pour les événements payants/ content nibble ; /* 1 octet (obits pour un premier niveau et 4 bits pour un second niveau) descriptif` de genre 1 et 2 */ duration ; /* 3 octets durée de l'-éitézrément Parental_rating ; /* 1 octet code d'information pour les parents */ evtTitleLen ; /* 2 octets longueur du titre en octets */ evtSummaryLen ; /*longueur en octets du résumé de l'événement. Certaines données facultatives ont une longueur constante mais ne figurent pas nécessairement. Si par exemple un événement est de type ppv (pay per view) des données supplémentaires seront associées à cet événement telles que son prix, sa référence etc. title_id ; /* 2 octets identité du titre */ price ; /* 4 octets indication de montant/ ppvSession ; /* 2 octets numéro de cession */ purchase win ; /* 1 octet fenêtre d'achat. Sans surprise, on retrouve dans les exemples de données communes et de donnéés facultatives des données déjà citées plus haut lors de la description du moteur d'extraction. Les données facultatives sont celles qui ne sont présentes sur le flux que si certaines conditions sont remplies. Le moteur d'extraction n'extrait ces données du flux que si les conditions sont remplies, ce qui fait qu'au niveau de la mémoire de données, ces .données facultatives peuvent ou non être présentes. Les données de longueur variable qui peuvent ou non être présentes sont par exemple le titre de l'événement ou son résumé qui comportent un nombre variable de caractères et sont donc représentées par ce même nombre variable d'octets. Dans le mode préféré de réalisÉî#@-an=` de l'invention chaque zone compacte 2 comporte comme représenté en figure 2, une première sous zone compacte 3 contenant les données communes à tous les événements, cette première sous zone 3 qui groupe des données toujours présentes de longueur constante est elle même de capacité constante. Immédiatement adjacente à cette première sous zone vient une seconde sous zone 4 groupant toutes les données facultatives de longueur constante et enfin une troisième sous zone 5 immédiatement adjacente à la seconde sous zone groupant toutes les données de longueur variable. Afin de rendre l'utilisation de la base la plus souple possible, les données de petite taille, par exemple les services nécessitant une capacité de 20 octets environ, sont chaînées les unes aux autres et les données de plus grandes taille par exemple celles relative aux événements dont la taille est souvent supérieure à 120 octets 'sont stockées de façon compacte, c'est à dire dans une zone mémoire continue. Les éléments service sont doublements chaînés les uns aux autres. Ce double chaînage assure une navigation plus rapide entre les différents services. Une représentation schématique de ce double chaînage est représentée figure 3 pour un nombre n égal à 4. Chaque service 11, 12, 13, 1n = 14 est lié par deux pointeurs matérialisés par des flèches 6 et 7 au service suivant et au service précédent respectivement. Sur la figure 3 chaque flèche 6 est référencée par le numéro 6 suivi du numéro du service suivant, ainsi la flèche 61-2 symbolise le pointeur du sérvicë 11 désignant le service 12, et le dernier servi cé@@-4--ây-ant un pôiriteur 611 désignant le premier service 11. De même chaque flèche 7 est référencée par le numéro 7 suivi du numéro du service précédant, ainsi la flèche 713 symbolise le pointeur du service 14 désignant le service 13, et le premier service ayant un pointeur 714 désignant le dernier service 14. Les éléments événement sont de grande taille (>120 octets). Aussi afin de ne pas fragmenter la mémoire, il sont chaînés ou rangés bout à bout dans une zone mémoire qui leur a, tout spécialement, été allouée. Pour garder l'information de pointage de chaque événement, des pointeurs les référençant sont également mémorisés dans un tableau adjacent. Un tel tableau 8 est représenté figure 4 avec la zone compacte mémoire événement 2 qui lui est associée. Sur la figure 4 le tableau a été référencé 8p et la zone compacte mémoire 2 a été référencé 2p pour marquer qu'il y a un tableau 8p associé à chaque' zone compacte 2p. Si la zone compacte 2p représentée figure 4 contient des informations sur 5 événements 2p1, 2p2, 2p3 2p5, le tableau 8 contient autant de pointeurs que la zone 2 contient d'événements, dans le cas représenté 5 référencés 8p1 à 8p5 pointant vers le début de chaque événement 2p1 à 2p5 du service 2p. Ce tableau de pointeurs permet l'accès direct aux différents événements du service 2p. I1 y a une correspondance bi univoque entre chaque pointeur épi du tableau 8p et l'adresse du début d'un événement. Par exemple le pointeur numéro 8p5 du tableau 8p pointe vers le cinquième .événement 2p5 du service 2p associé .à- ce tableau 8p. I1 est également créé un lien éntre's les éléments service et les éléments événement. Cëi7#'reri_est schématisé figure 5 par deux pointeurs, un pointeur 9p1 pointant du service 1p vers le début de la zone mémoire 2p et un pointeur 9p2 pointant vers le début de la zone mémoire 8p contenant le tableau de pointeurs 8p1 à 8p5. A chaque élément de type service 1p, correspond une zone mémoire compacte 2p contenant les événements 2p1 à 2p5 et un tableau 8p de pointeurs 8p1 à 8p5 pointant chacun des événements 2p1 à2p5. Il n'est pas réservé de la mémoire en prévoyant le pire. On alloue à l'octet près la mémoire dont on a besoin. De plus les structures sont suffisamment accessibles pour consultation, puisque le but du cache est de restituer les informations le plus rapidement possible. La construction s'opère donc en trois temps. Une chaîne ou un service est repéré par son triplet DVB. Ce triplet est constitué par l'identification du réseau initial sur lequel la chaîne est diffusée "network Id", l''identification du flux de transport utilisé par le service "stream Id" et l'identification du service "service Id". Une fois le cache initialisé, une chaîne peut être ajoutée dans le cache. Les paramètres à donner au moteur d'acquisition de tables sont l'original "network Id", le "transport stream Id", et le "service Id". Plusieurs chaînes peuvent être créées en même temps. Comme représenté figure 6 une première chaîne 11 est créée. Cette chaîne 11 ne contient, à ce stade, aucun événement et la taille des événements est nulle. Les pointeurs 911 et 912 sont vides. Le chargement des tables EIT sur le flux s'effectue en parallèle. Aussi le cache donne-la possibilité de construire plusieurs services en:` même temps: La construction suit alors le même modèf`ë-qûé le chargbmënt des données: le parallélisme. Comme représenté sur la figure 7 des chaînes 12, 13 peuvent être ajoutées à la première 11, chacune des chaînes 12, 13 ajoutées est dans une première phase vide et se présente donc de la même façon que la première chaîne illustrée figure 6. Lorsqu'une table EIT est reçue et que son analyse est en cours, les informations correspondant aux événements sont extraites et insérées dans le cache. L'analyse de la table EIT n'est réalisée qu'une seule fois. L'application SICache ne connaît pas à l'avance la quantité de mémoire qu'il lui faut allouer pour recevoir les informations des événements. De ce fait, une liste chaînée d'événements est réalisée. Cette liste sert uniquement pendant la phase de construction du cache. Lorsque tous les événements auront été ajoutés, son contenu sera recopié dans une zone mémoire compacte 2p comme expliqué plus haut puis la liste chaînée d'événéments disparaîtra. Des événements peuvent être ajoutés à une chaîne. A chaque ajout d'événement la taille en octets de celui-ci est calculée et un cumul des tailles d'événements permet de savoir quelle quantité de mémoire il faudra allouer lorsque le dernier événement sera inséré. L'ajout d'un événement à une chaîne est représenté figure 8. Les informations sur le premier événement par exemple du service 13 sont insérées dans un élément 2'31 d'une liste chaînée temporaire 2'3, l'élément service 13 reçoit l'information relative au nombre cumulé d'événements et à la taille de chaque événement. La liste chaînée des événements du service par exemple 13 est constituée comme représenté figure 9, par addtions successives des différents événements 2'32 e@@#-3-à- de la chaîne. Un calcul de la somme des tailles est effectué. Les mêmes opérations sont effectuées pour chacune des n chaînes comme représenté figure 10. Cette figure représente une liste chaînée de services 11 à 14. Chaque service contient des informations relatives aux nombres d'événements qui ont été ajoutés dans ce service et sur la taille de la somme des informations relatives à chaque événement. Les éléments événement par exemple 2'11, 2'12, 2'13 de la première chaîne 2'1 sont comme ceux des autres chaînes, chaînés entre eux. Lorsque l'ensemble des événements d'une chaîne a été extrait de la table EIT correspondant à cette chaîne et simultanément inséré dans la liste chaînée servant à la construction, le cache peut alors formater les données afin de les "cacher" définitivement. Cette opération est réalisée sur appel d'une fonction de formatage des données appelée "fitChannel". A la fin de la phdse de construction, pour chaque service on est en possession des informations suivantes . le nombre d'événements composant le service. la taille cumulée de l'ensemble des événements. Le nombre d'événements sert à calculer la taille du tableau de pointeurs référençant les événements formatés. La taille cumulée des informations sur les événements permet l'allocation nécessaire et suffisante de mémoire pour la recopie de la liste chaînée. La zone compacte de mémoire allouée contiendra alors les événements mis bout à bout. Pour une chaîne composée de N événements. dont la taille" cumulée est T K octets on réalisera:-, les allôcàtions suivantes : --- - `N x 4 pour le tableau de pointeurs (1 pointeur = 4 octets) K octets pour la zone compacte et continue de mémoire. K est un nombre entier représentant la somme du nombre d'octets des informations relatives à chaque événement. Un schéma pour une chaîne par exemple 14 diffusant 4 événements est représenté figure 11. A ce stade de la création du cache i1 est réservé dans la mémoire un tableau vide 8'4 contenant juste l'espace mémoire nécessaire au stockage des quatre pointeurs et une zone vide compacte 2"4 juste assez grande pour contenir le nombre k d'octets représentant la somme des quantités d'information en octets contenues dans le descriptif des 4 événements. On procède ensuite comme représenté figure 12, par exemple pour le service 14 à la recopie des événements de la liste chaînée temporaire vers la zone 2"4' compacte et continue de mémoire. Cette zone lorsqu'elle est remplie est référencée 24. Elle comporte les informations sur les premiers à 4eme événement de la chaîne. Ces informations sont stockées dans des zones adjacentes de la zone compacte 24, 241, 242.... Le tableau 8'4 de pointeurs est rempli puisqu'on connaît l'adresse du début de chaque événement et prend la référence 84. A ce stade la liste 2'4 chaînée d'événements est , toujours présente. Cette liste chaînée, qui a servi à la construction du cache, est ensuite effacée, libérant la place mémoire correspondante, en sorte que la structure chaîne et- événements associés prend l'aspect. final rebrésenté`figure 13. Cet aspect correspond à celui de la fi"ure 5 déjà décrite. A titre d'exemple non limitatif, l'aspect matériel de la mémoire utilisée sera maintenant commenté. I1 a été utilisé une mémoire de type Mediahighway cTm>. Cette mémoire est divisée en trois parties . Une partie réservée à des poignées de manipulation, cette partie permet d'associer à chaque adresse logique une adresse physique dans la mémoire. Cette partie de la mémoire est réservée à la manipulation des objets. Une partie dynamique, il s'agit d'une partie de 1a mémoire dans laquelle les objets sont utilisés via les poignées. Cette partie de la mémoire est défragmentée par un logiciel fourni avec la mémoire par un processus dit de récupération des gaspillages (garbage collecting). Une partie statique, cette partie est une mémoire conventionnelle que l'on utilise via des pointeurs). Le cache de données SI utilise la mémoire dynamique et statique. Cette double utilisation permet de garantir un minimum de fragmentation et une consommation réduite de mémoire. Par définition un pointeur dans une zone de données mémoire dynamique est une poignée, c'est à dire comme expliqué plus haut un double pointeur. Il consomme donc le double en mémoire que son équivalent constitué d'un pointeur simple, en mémoire statique (8 octets au lieu de 4). Donc plus il y a de pointeurs plus on a intérêt à utiliser de la mémoire stâtiquë_. De même afin de minimiser la fragment-ati@ri,- il convient que les petites données ( 1Ko) aillent dans la mémoire statique. La construction du cache et la localisation des éléments dans les parties statique 100 et dynamique 10 de la mémoire sera succinctement revue ci-après en précisant à chaque fois les localisations. Sur les figures 14 à 16, les parties dynamique 10 et statique 100 de la mémoire sont séparées l'unE de l'autre par une ligne pointillée. Comme représenté figure 14 les listes 11, à 1n chaînées des services définit plus haut se trouvent dans une zone 10 de mémoire dynamique. En effet l'élément chaîne ne consomme que peu d'octets. De plus, d'une construction du cache à une autre, le nombre de chaînes peut varier. Une utilisation de la mémoire dynamique évite la fragmentation de la partie statique de la mémoire. Les listes représentées à titre d'exemple 2'n à 2'15 et 2'n1 à 2'n7 chaînée d'événements qui, on le rappelle sont un outil intermédiaire de construction de la mémoire statique, se trouvent en zone mémoire dynamique 10. Dans la mesure où elle est temporaire, une fois effacée la récupération de gaspillage "garbage collecting" garantit une défragmentation de l'ensemble de la mémoire dynamique précédemment utilisée. Après la recopie des chaînes et comme représenté figure 15 les zones 2 (21, 2n) compactes d'événements se trouvent dans une partie 100. de la mémoire correspondant à de la mémoire statique -puisque ces zones sont souvent de taille importante è-t`-pëuvent rester `stables pendant des durées de l'ordre de 48 heures. De plus dans cette partie 100 chaque événement est référencé par un pointeur et non une poignée. L'économie de 4 octets par événement est non négligeable. Les tableaux 81 à 8n de pointeurs d'événements se trouvent également dans la partie 100 correspondant à de la mémoire statique. Dans la mesure où un tableau vide 8" de pointeurs (non représenté vide) est alloué dans le même temps qu'une zone vide 2" compacte d'événements, peu de risques de fragmentation sont à prévoir. Après effacement des listes chaînées 2'1 à 2'n le cache présente l'aspect représenté figure 16 où la partie 10 de mémoire dynamique ne contient plus que la liste chaînée des services 11 à 1n. Les tableaux 8 de pointeurs et les zones compactes 2 se trouvent dans la zone 100 de mémoire statique tandis que la liste chaînée 1 des services se trouve dans la partie 10 de mémoire dynamique. Dans le mode préféré de réalisation . une protection contre la saturation mémoire est prévue. Du fait de son modèle entièrement dynamique, le cache de données SI peut, si un trop grand nombre d'informations est diffusé, saturer la mémoire du décodeur ou de la "Set Top Box". Aussi, afin d'assurer une protection contre ce phénomène, un système de bornes permet de limiter le nombre d'éléments cachés. Les bornes sont configurables à l'initialisation du cache. Les bornes possibles sont les suivantes Nombre maximum de chaînes ou services. 'Nombre maximum d'événements par service. Nombre maximum de caractères pour le titre de l'événement. Nombre maximum de caractères pour le résumé de l'événement. Ce système de borne permet d'évaluer la taille du cache une fois qu'il est constitué. Prenons par exemple un élément chaîne donc stocké dans la partie de mémoire dynamique, dont les données ont une taille de N octets. La taille des données de cet élément chaîne est donc de N+2*8 octets (+2*8 pour les deux poignées qui assurent le double chaînage) soit N+16. Supposons que les événements aient une taille moyenne de M octets. Pour chaque événement il faut compter son pointeur associé donc on a M+4 octet par événement. Le calcul de la taille de la base est Taille Cache = (NbMaxChaînes*(N+16) + NbMaxChaînes*NbMaxEvtParChaîné*(M+4))/ 1024 kilooctets. Exemple chiffré : 200 chaînes, 80 événements par chaîne, (3 jours de programme en moyenne) avec 20 octets pour les données chaînées d'une chaîne et. une moyenne de 140 octets pour un événement. Taille cache =(200*(20+16) + 200*80*(140+4))/1024 Taille cache = (7200 + 2.304.000)/1024 Taille cache = 2257 Ko Taille cache = 2.2 Mo on voit qu'il est important de bien définir les limites du système. Il convient aussi de noter que, 99,99 % de la base est en mémoire statique et :que La mémoire statique accueille également les cl`âsses téléchargées donc si celle-ci est satïzr'é-ë; -- le téléchargement d'applications n'est plus possible. Le module de consultation de mémoire, "browser de données" SI (package eventbrowser) sera maintenant décrit. Dès que des données sont disponibles dans le cache de SI, elles peuvent être récupérées à l'aide d'un consulteur de mémoire. Le cache n'a pas besoin d'être complet, même partiellement rempli, il peut faire l'objet de consultations de la part des applications. Cependant, il faut au moins qu'une chaîne ait été formatée pour qu'il puisse y avoir une consultation. L'accès aux données s'effectue au moyen d'itérateurs. On distingue deux types d'itérateurs Un itérateur sur la base des chaînes ou services Un itérateur sur la base des événements. L'itérateur de chaînés parcourt ("browse") la liste doublement chaînée se trouvant dans la partie de mémoire dynamique décrite plus haut. Du fait de son chaînage double les mouvements arrière et avant sont simples et rapides. Les fonctions "lit et passe au suivant" (readAndGoNext) et "lit et passe au précédant" (readAndGoPrevious) permettent de récupérer des informations sur chacune des chaînes parcourues (browsées). Les informations sont incluses dans un objet de la classe chaîne. De multiples fonctionnalités sont également disponibles, telles que la recherche d'une chaîne, le positionnement d'un mode loupe. L'itérateur d'événements permet, ,:comme l'itérateur de chaînes, de renvoyer des instances;. (des objètsJ de la classe événement DVBEvent qui côn'tlênnent chacun l'ensemble des informations se reportant à un événement. Cependant il faut distinguer deux types distincts d'itérateurs, l'itérateur d'événements associés à une chaîne et l'itérateur d'événements triés par genre. L'itérateur d'événements associés à une chaîne permet de parcourir ("browser") les événements associés à une chaîne. Ce type d'itérateur est notamment utilisé dans la construction des grilles de programmes. L'itérateur d'événements triés par genre permet comme son nom l'indique de trier les événements sur un critère bien précis que les événements triés remplissent. De tels itérateurs sont utilisés par exemple pour construire des listes triées par genre telles que l'ensemble des films ou l'ensemble des événements sportifs etc. Lors de la construction d'un tel itérateur il y a mémorisation des pointeurs d'événements dans un tableau de pointeurs annexes. Ce tableau est construit en deux temps comme représenté schématiquement figure 17. L'ensemble des zones compactes 2 d'événements de l'ensemble des chaînes est parcouru et analysé. Si l'événement remplit la condition de filtrage, il est marqué par un drapeau ("taggé") puis un compteur est incrémenté. Le marquage de l'événement est représenté figure 17 par une première flèche f dirigée vers un événement de la zone 2. Dans l'exemple représenté figure 17 la première zone 21 d'événement comporte deux films, les zones compactes 22 , 23, 24, 25, 26, 210, 211 comportent un seul film, les zones compactes,-27, 28, 29 ne`comportent r pas l'événement recherché. 'I1 a été- trouvé 9 événements remplissant le critèrë-@è-~-tri et donc ' le compteur d'événements est à 9. Une fois que l'ensemble de la base a été parcouru, on affecte la mémoire statique nécessaire pour recopier les pointeurs des événements marqués. Dans l'exemple représenté il s'agit d'un tableau 200 vide à ce stade contenant juste la place mémoire nécessaire à l'inscription de 9 pointeurs 2001 à 2009 Enfin un deuxième parcourt de la base permet de copier les pointeurs des événements marqués dans l'espace de mémoire statique fraîchement créée et de démarquer ces événements. La recopie des pointeurs est matérialisée par une deuxième flèche g dirigée vers le pointeur d'un événement marqué. Une fois les pointeurs recopiés, un accès direct à tous les événements marqués est construit. Suivant les critères de construction de l'itérateur, un tri par ordre chronologique et/ou par ordre alphabétique peut ensuite être réalisé. Une illustration d'un tel usage d'itérateur est donnée par la figure 18 dans laquelle le tableau 200 est représenté avec une flèche par pointeur pointant chacune sur l'un des événements triés Dans le mode préféré de réalisation de l'invention le module de consultation de mémoire comporte une fonction de vérification de la pertinence des données parcourues de façon à s'assurer que les informations sont à jour au moment où on les consulte. Cette fonction sera décrite ci-après. Une donnée SI est dite ''pertinente'' si elle est identique dans le cache en mémoire ou dans le flot MPEG de diffusion. Le cache de données SI est pertinent s'il reflète exactement les données diffusées à#rzs -leur ensemble. Il doit donc être capable de détecter les mises à jour dynamique faite sur le flux (cf Le moteur d'acquisition des EIT) Lorsqu'une instance d'une classe chaîne ou événement est créée via le module de consultation de mémoire (browser) de données SI, celle-ci contient une copie des informations contenue dans le cache. Ces informations sont susceptibles de changer dans la mesure où le cache peut évoluer. Une chaîne peut être reprogrammée, c'est à dire effacée du cache puis rechargée. Les données java représentatives de cette chaîne avant la reprogrammation sont obsolètes. De même un itérateur spécifique d'événement est susceptible d'être mis à jour. Il convient donc de prévenir l'utilisateur. Ceci est accompli via le mécanisme des exceptions. Dès que les données associées à une chaîne diffusée sur un flux de transport sont formatées, la chaîne mémorise une signature. Cette signature est délivrée par un serveur de signature. Ce serveur garantit de ne jamais donner deux signatures identiques après chaque construction d'une même chaîne. Chaque instance de la classe chaîne recopie cette signature au sein de ses données internes. A chaque appel de méthodes sur cet objet chaîne les signatures sont comparées. Si elles sont identiques les données de la chaîne sont pertinentes et peuvent être parcourues (browsées). Dans le cas contraire, une exception est levée indiquant à l'application que l'objet chaîne qu'elle utilise est obsolète. I1 convient donc que l'application demande une nouvelle instance dë la classe, chaîne ou qu'elle demande la mise à joûr--âëïs on objet Dès que les données d'une chaîne sont mises à jour, il faut invalider (rendre obsolète) les itérateurs spécifiques d'événements. Un itérateur contient des adresses d'événements. Il faut donc garantir à chaque opération de consultation (browsing) sur un itérateur que les adresses qu'il contient pointent bien vers des événements actuels et non vers des données obsolètes. Pour ce faire chaque itérateur est validé par un booléen. A chaque modification de la base aussi infime soit-elle, ce booléen sous forme d'un drapeau est positionné à une position d'invalidation "false" afin d'invalider l'itérateur. De la même façon que pour les données d'une chaîne, à chaque opération de consultation (browsing) sur un itérateur, une vérification est faite sur sa validité. S'il est invalide, une exception est levée. Il convient donc que l'application demande une nouvelle instance d'itérateur ou qu'elle demande une mise à jour de celui-ci. Les demandes de mise à jour sont adressées par le module de consultation au module moteur. Une autre particularité avantageuse de l'invention sera maintenant examinée. Le cache selon l'invention exploite les parties statique et dynamique de la mémoire. Les données SI cohabitent avec des données liées aux fonctionnements basiques du système (fonctionnement machine virtuelle, chargement des classes ... ). Dans le cas d'un fonctionnement prolongé, la mémoire statique; se fragmente.' Ceci est inévitable car l'exploitation du cachè :_. permet l'effacement partiel voir tôt-à-r-- -des données' SI. Le gestionnaire de mémoire n'effectue aucune opération de défragmentation sur la partie statique de la mémoire. Ce problème de fragmentation de la zone statique peut conduire à l'impossibilité de charger de nouvelles chaînes en mémoire bien que la place existe physiquement. Pour remédier à ce problème, selon cette caractéristique de l'invention on définit une zone de mémoire spécifique pour le cache de données SI. Seul dans cet espace, le cache SI peut évaluer à tout moment son degré de fragmentation. De même il peut réordonner les blocks de données SI et défragmenter sa mémoire lorsque le système le lui permet : veille ou système non actif depuis un certain temps. Ce mécanisme est en tous points similaire à la gestion de la défragmentation d'un disque dur sur PC. Les deux avantages de cette zone spécifique de mémoire sont la garantie de non-fragmentation du cache de données SI d'une part et la non-interférence avec le fonctionnement nominal du système d'autre part. On notera que l'on peut utiliser à cette fin le logiciel implanté de défragmentation de la partie de mémoire dynamique. Pour cela il convient de modifier périodiquement ou sur requête le paramétrage de la partie de mémoire dynamique et de la partie spécifique de mémoire statique, pour rendre dynamique la totalité de la mémoire statique dédiée aux applications SI, puis de fixer à nouveau une limite une fois la défragmentation faites. On peut aussi pour gérer au mieux les données si utiliser un disque dur. Naturellement.. le gestiônnaire de fichiers (file system) doit in-té g---r- un outil de défragmentation. Le procédé de construction de la base de données relative aux informations sur les programmes et le procédé de consultation de cette base, sont sous forme de logiciel implanté dans une mémoire d'un appareil, par exemple une télévision, un décodeur ou un magnétoscope. Le logiciel peut aussi être importé par exemple sous forme d'un support contenant le logiciel à introduire dans l'appareil ou encore par téléchargement. REVENDICATIONS 1. Procédé de construction d'une base de données relative à des informations d'événements diffusées périodiquement sous forme de flux de données par un ou plusieurs fournisseurs de services dans lequel a) on constitue un fichier de différents services identifiés susceptibles de diffuser des informations d'événement, b) on extrait et on stocke temporairement une partzë au --moins d'une série d'informations sur les événements diffûsés par chaque service, c) on sélectionne pour chaque événement les informations que l'on souhaite stocker pour une longue durée, d) on détermine le nombre d'octets contenus dans les informations sélectionnées pour chaque événement ainsi que la somme de ces quantités d'informations pour l'ensemble des événements de chaque service, e) on recherche une zone d'adresses mémoire de taille suffisante pour y stocker de façon non fragmentée toutes les informations sélectionnées relatives à tous les événements d'un premier service les uns à la suite des autres, f) on recopie dans les zones d'adresses non fragmentées trouvées à l'étape e) chacun des événements du premier service les uns à la suite des autres, g)on complète le fichier des services par l'adjonction, dans une fiche de ce fichier correspondant audit premier service d'un pointeur donnant l'adresse du pointeur, du premier événement de ce service, h) on recommence les étapes d) à g) pour chacun des services du fichier des services, i) on efface de la mémoire les informations extraites à l'étape b). 2. Procédé de construction selon la revendication 1, caractérisé en ce qu'à l'étape d) on tient en outre un compte du nombre d'événements pour définir la place mémoire nécessaire à la création d'un tableau de pointeurs donnant chacun l'adresse du début d'un événement et en ce qu'à l'étape e) on constitue en outre une zone mémoire compacte de taille ;juste suffisante pour y loger ledit tableau de poin-tëùrs,-et enfin en ce qu'à l'étape f) on inscrit dans le tableau des pointeurs, pour chaque événement, l'adresse du début des informations relatives à cet évènement. 3. Procédé de construction selon la revendication 1, caractérisé en ce que les éléments services du fichier des services sont chaînées. 4. Procédé de construction selon l'une quelconque des revendications 1 ou 2, caractérisé en ce que les éléments services du fichier des services sont doublement chaînés. 5. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que pour exécuter les étapes d) à e) à partir des informations extraites à l'étape b) . on commence par créer, pour chaque service, un ensemble temporaire d'éléments (2'1,....2'n) événements chaînés, chaque élément événement contenant les informations sélectionnées (2'11 ....2'n1 ....2'n4) relatives à un événement, cet ensemble d'éléments événements chaînés, étant créé par ajouts successifs d'événements (2'41-2'44) à la chaîne (2'4) au fur et à mesure de la réception des informations relatives à chacun de ces événements, jusqu'à réception d'un dernier événement (2'44) relatif à ce service, en ce qu'un compte du nombre d'événements est incrémenté de 1 à chaque ajout d'événement, en ce que le nombre d'octets contenus dans les informations sélectionnées est incrémenté du nombre d'octets décrivant l'événement, pour chacun des événements ajoutés, le compte du nombre d'événements étant la valeur; de ce compte après ajout du dernier événement, la valeur du nombrè_.d'octets nécessaire au stockage des inf-ormâtions relatives aux événements de ce service étant ladite valeur après ajout du dernier événement du service. 6. Procédé selon la revendication 5, caractérisé en ce que les informations effacées à l'étape i) sont celles (2'11-2'44) qui -constituent l'ensemble temporaire chaîné. 7. Procédé selon l'une des revendications 3 ou 4, caractérisé en ce que la base de données est construite sur une mémoire comportant un logiciel de gestion de la mémoire, ce logiciel réservant - une première partie (10) de la mémoire dans laquelle est effectuée une gestion dynamique des éléments qui y sont contenus, au moyen de deux poignées par élément, l'une donnant une adresse logique du début de l'élément et l'autre une adresse physique, cette gestion dynamique comportant une fonction de défragmentation par récupération des gaspillages ; - une seconde partie (100) de la mémoire dans laquelle est effectuée une gestion statique, et en ce que - la liste chaînée des services (11-1n) est stockée dans la partie dynamique (10) de la mémoire et en ce que les zones (21-2n) compactes d'événements et éventuellement leurs tableaux de pointeurs (81-8n) associés sont stockés dans la partie statique (100) de la mémoire. 8. Procédé de construction d'une base de données selon l'une des revendications précédentes caractérisé en ce que on définit préalablement, à la constitution de la base, une ou plusieurs, bornes portârit sur le nombre de services ou sur ré.- nombre d'événements par service ou encore sur d'autres données et en ce que les données dont la quantité excède la borne fixée pour cette donnée ne sont pas chargées dans la zone compacte (21_2n). 9. Procédé selon l'une des revendications précédentes caractérisé en ce qu'on stocke des données diffusées par les fournisseurs de service, et donnant un compteur de service et un numéro de version d'événement, on compare périodiquement ces données aux données de même nature actuellement diffusées, on utilise les résultats de la comparaison pour déterminer les services pour lesquels une nouvelle acquisition de données doit être effectuée ou les services qui n'ont pas été enregistrés auparavant. Procédé de consultation d'une base de données constituée selon l'une des revendications précédentes comportant une liste chaînée de service et autant de zones compacte d'événements que de services, ces zones compactes étant associées à un tableau de pointeurs dont chaque pointeur désigne le début de l'adresse d'un événement contenu dans la zone compacte, caractérisé en ce que il comporte une fonction de parcours service par service dans laquelle on extrait et présente des données relatives aux événements d'un service sélectionné. 11. Procédé selon la revendication 10, caractérisé en ce que il comporte en outre une fonction de présentation de données sur des événements sélectionnés en fonction de un ou plusieurs critères identifiables dans les données contenues dans- les événements répertoriés dans l'ensemble des. .zones compactes de stockage de données relativës aux événements des différents services, la sélection étant faite selon les étapes ci-après on fait un premier parcours de repérage et marquage des événements répondant au critère de sélection et on incrémente un compteur initialisé à zéro de 1 chaque fois qu'un événement répondant au critère ou aux critères est marqué, on constitue un tableau vide de pointeurs pouvant contenir un nombre de pointeurs égal à la valeur du compteur après parcours de toutes les zones compactes, on effectue un deuxième parcours pour recopier dans le tableau vide les adresses des événements marqués et effacer les marquages, on parcours les données sélectionnées par déplacement dans le tableau de pointeurs. 12. Appareil, notamment décodeur ou récepteur r de télévision ou magnétoscope contenant au moins une mémoire et un logiciel résidant ou importable permettant de mettre en #uvre un procédé de construction d'une base de données et/ou de consultation de cette base selon l'une des revendications 1 à 11.