Version IV_V04 1 er novembre CONTENU DU PRÉSENT DOCUMENT DÉFINITIONS ET ABRÉVIATIONS CONDITIONS GÉNÉRALES (F7)...

Transcription

1 Protocole relatif aux modalités de surveillance et de contrôle des jeux de hasard dans les établissements de jeux de hasard de classe IV et les lieux où les paris sont engagés en vertu de l'article 43/4, 5, de la loi du 7 mai 1999 sur les jeux de hasard, les paris, les établissements de jeux de hasard et la protection des joueurs, notamment au moyen d'un système informatique approprié - Texte coordonné - Version : IV_V04 du 1 er novembre 2015

2

3 Table des matières Page 1 CONTENU DU PRÉSENT DOCUMENT DÉFINITIONS ET ABRÉVIATIONS CONDITIONS GÉNÉRALES (F7) CONDITIONS TECHNIQUES RELATIVES AU CABLAGE ET AUX COMPOSANTS PASSIFS DU LAN CONDITIONS TECHNIQUES RELATIVES AUX COMPOSANTS ACTIFS DU LAN CONDITIONS TECHNIQUES RELATIVES AUX CLIENTS ET AUX SERVEURS CONDITIONS TECHNIQUES RELATIVES AU LOCAL DESTINE AU "DATA-RACK" CONDITIONS TECHNIQUES RELATIVES A LA LIAISON DE DONNEES AVEC LA COMMISSION DES JEUX DE HASARD CONDITIONS SUPPLEMENTAIRES RELATIVES AU SYSTEME DE VIDEOSURVEILLANCE CONDITIONS RELATIVES À L INFORMATION COMPTABLE ET FINANCIÈRE (F0, F1, F2 ET F9)18 11 CONDITIONS RELATIVES À L'ENREGISTREMENT (F5) CONDITIONS RELATIVES AU CONTRÔLE TECHNIQUE (F6 ET F10) CONDITIONS RELATIVES À LA DOCUMENTATION CONCERNANT LE SYSTÈME INFORMATIQUE ET LE SYSTÈME DE VIDÉOSURVEILLANCE UTILISATION DES NOUVELLES TECHNOLOGIES DE L'INFORMATION NORMES CONCERNANT LA NOMENCLATURE DES FICHIERS À ENVOYER APPROBATION ANNEXE 1 : DÉFINITIONS XML ANNEXE 2 : PROTOCOLE DE COMMUNICATION STANDARD ANNEXE 3 : TABLE ASCII ANNEXE 4 : ARRÊTÉ ROYAL DU 22 DECEMBRE

4 1 CONTENU DU PRÉSENT DOCUMENT L art. 43/7, 5 de la loi du 7 mai 1999 prévoit que la surveillance et le contrôle des établissements de jeux de hasard de classe IV et des lieux où les paris sont engagés en vertu de l'article 43/4, 5, de la loi du 7 mai 1999 sur les jeux de hasard, les paris, les établissements de jeux de hasard et la protection des joueurs doit se faire au moyen d un système informatique approprié. Le présent document décrit les conditions techniques auxquelles le système précité doit répondre. Le présent protocole constitue l exécution de l art. 11 de l arrêté royal du 22/12/2010 relatif aux modalités de surveillance et de contrôle des jeux de hasard dans les établissements de jeux de hasard de classe IV et les lieux où les paris sont engagés en vertu de l'article 43/4, 5, de la loi du 7 mai 1999 sur les jeux de hasard, les paris, les établissements de jeux de hasard et la protection des joueurs, notamment au moyen d'un système informatique approprié (MB 29/12/2010). -4-

5 2 DÉFINITIONS ET ABRÉVIATIONS Abréviation Définition LAN Local Area Network : le réseau local Client Toute unité électronique, donc tant les pc administratifs que les jeux automatiques. Les jeux automatiques sont soit des terminaux de paris soit des machines automatiques de classe IV. Personne obligée Tout titulaire d'une licence de classe F1 qui met à disposition, sous quelque forme que ce soit, des terminaux de paris chez un titulaire d'une licence de classe F2, ou tout titulaire d'une licence de classe F2 qui possède et exploite ses propres terminaux de paris Tout titulaire d'une licence de classe E qui met à disposition, sous quelque forme que ce soit, des machines automatiques de classe IV chez un titulaire d'une licence de classe F2, ou tout titulaire d'une licence de classe F2 qui possède et exploite ses propres machines automatiques de classe IV On-line Est considéré comme partie intégrante du système on-line, tout ce qui se trouve entre le client et le transfert de données vers la Commission (donc y compris l'application CPU-Switch, le cas échéant) UTP Unshielded Twisted Pair DHCP Dynamic Host Configuration Protocol WINS Windows Internet Naming Service DNS Domain Name System FTP File Transfer Protocol DVD Digital Versatile Disk EPROM Erasable Programmable Read Only Memory Xls-file Format de fichier de Microsoft Excel. XML Une norme du Consortium World Wide Web pour la syntaxe formelle des langages de balisage avec lequel on peut afficher des données structurées sous forme de texte brut RJ45 Registered Jack 45 Propagation Delay Le temps nécessaire à un signal pour se rendre du point A au point B par un canal de transmission donné TCP/IP Transmission Control Protocol / Internet Protocol IPV4 Adresse Internet du Protocole en 4 positions IPV6 Adresse Internet du Protocole en 6 positions SWITCH Un appareil électronique qui organise le flux des messages entre différents segments du LAN SSL Secure sockets layer -5-

6 SSH HTTP DMZ Connection IP ISP IP-adres Secure shell Hypertext transfert protocol. Demilitarized Zone connection basée sur le protocol Internet Internet Service Provider Internet Protocol adres. -6-

7 3 CONDITIONS GÉNÉRALES (F7) A/ Certification : Afin de s assurer que le présent protocole est correctement appliqué et afin de garantir la fiabilité des données reçues, une procédure de certification obligatoire a été établie. Toutes les personnes obligées doivent faire vérifier leur système on line par un organisme indépendant agréé par la (cfr. Art 52, loi 1999). Cet organisme contrôle la conformité de l ENTIERETE DU SYSTEME ONLINE (câblage, éléments passifs et actifs du réseau, software utilisé, protocoles de communication utilisés, les clients et les serveurs) avec l entièreté du protocole d application présent, les AR concernés, les notes informatives émises par la CJH, les notes émises par le service de la Métrologie et la loi sur les Jeux de Hasard de 1999 (y compris tous les changements de cette loi). L interface du jeu automatique doit également faire l objet d une certification. La fiabilité et la disponibilité de la connexion data avec les clients dans les établissements de classe F2 doit également être vérifiée. L organisme mentionné ci-dessus contrôle aussi dans quelle mesure les fichiers XML qui sont AUTOMATIQUEMENT générés par le système on line sont fiables. Il détermine aussi dans quelle mesure et de quelle manière ces données peuvent éventuellement être influencées. Le stockage de ces données dans un fichier temporaire n'est toléré que si les données sont cryptées par une application sécurisée de façon à rendre leur modification impossible ou si le stockage se fait après l'envoi réussi du fichier XML. Les données de base (*) des machines automatiques de classe IV doivent être rassemblées en temps réel et il ne peut donc être fait appel à un fichier présent dans le système online, ceci afin d exclure toute anomalie. Le mode d envoi des données à la Commission des Jeux de Hasard doit aussi être examiné. La Commission des Jeux de Hasard décidera d'accepter ou non la certification sur la base du dossier reçu (et rédigé par l organisme mentionné ci-dessus). En ce qui concerne la date limite de remise des rapports de certification, veuillez vous référer au point 16 : approbation. Les organismes de certification doivent établir un rapport dans une des langues nationales du Royaume dans un format qui peut être imposé par la Commission des jeux de hasard. Tous les coûts inhérents à cette certification ne sont pas supportés par la Commission des jeux de hasard. Le détenteur de licence F1 ou E (placeur) doit de nouveau faire certifier son système s'il y a eu des changements (autres que des upgrades ou correction de bug) dans son système online. Lors d'un upgrade ou d'une correction de bug, le fournisseur de software "on-line" doit transmettre à la les informations suivantes : -/ description détaillée des modifications apportées au système (pour ce qui concerne les éléments qui peuvent avoir une influence sur les données on-line); -/ exemple de chacun des fichiers XML prouvant que les fichiers sont correctement générés. Ces informations doivent être envoyée par à Protocols@gamingcommission.be en mentionnant dans le champ objet : "Upgrade Online_No de licence". Si la Commission l'estime nécessaire, une re-certification du système sera demandée. Le nombre d'upgrades autorisés sans certification doit toutefois rester très limité. -7-

8 B/ Intégrité des données : Le certificateur installe sur le serveur hébergeant le système on-line un service chargé de garantir l'intégrité du système. Ce service doit : -/ Etre sécurisé (impossible à modifier sans que cela soit visible) ; -/ Etre lié au serveur par une signature hardware ; -/ Calculer les signatures des fichiers critiques et les comparer aux signatures certifiées à une cadence aléatoire ; -/ Générer un fichier "signature" reprenant le résultat de la comparaison ainsi qu'un "timestamp" après chaque comparaison et le transmettre à la Commission via le système on-line ; -/ Le fichier "signature" doit être crypté de manière à garantir l'authenticité de l'application qui génère ce fichier. Seule la Commission doit pouvoir décrypter ce fichier. C/ Cashless (machines automatiques de classe IV) : L'enjeu peut être introduit dans la machine via un système cashless répondant aux exigences suivantes : -/ les "Player cards" ne peuvent être chargées que via la caisse et les terminaux de paiement certifiés de l'établissement. Le montant chargé doit être "inscrit" d'une manière cryptée sur la carte et sur le serveur du système cashless. Lors de l'introduction de la carte, s'il n'y a pas correspondance entre le montant "inscrit" sur la carte et le montant enregistré sur le serveur cashless, un message d'erreur doit être enregistré, d'une manière sécurisée dans le système on-line et la carte doit être bloquée. Si des systèmes alternatifs offrent un même niveau de garantie (impossibilité de modifier le montant de la carte sans que cela soit facilement traçable) ils peuvent également être proposés. -/ un fichier "log" reprenant les adresses IP de chaque connexion accédant au serveur cashless doit être enregistrées d'une manière sécurisée sur le serveur cashless (les données doivent être conservées 6 mois). D/ Inventaire des machines automatiques de classe IV (IV_F7) En ce qui concerne la transmission des listes de stock et des mouvements : La Commission des jeux de hasard impose l obligation de transmettre un état mensuel des machines automatiques de classe IV exploitées et de celles en stock dans le magasin. Dans un souci d harmonisation, le règlement suivant entre en vigueur. Les informations demandées sont transmises au format XML vers le serveur de la Commission des jeux de hasard. Inventaire complet à envoyer le 1 er mars de chaque année -/ No d'identification du jeu (No de série de la machine automatique de classe IV) -/ No d'approbation Métrologie -/ Date du "mouvement" -/ No de licence "F2" où la dernière exploitation a eu lieu -/ No de licence "E" concerné (voir informations ci-dessous) -/ No de la vignette de taxe -/ Clé de répartition : % des revenus du titulaire de licence "F2" (exemple : 60) -/ Clé de répartition : % des revenus du titulaire de licence "E" (exemple : 40) -8-

9 Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F7" (Seul l'élément "stock" est envoyé, pour les autres nbofitems est mis à 0) Remarque : Pour les appareils en magasin, le no de licence "F2" est remplacé par Si un billet de taxe est présent, son numéro doit être indiqué. Dans le cas contraire, ces chiffres doivent être remplacés par des 0 en respectant le format requis. Inventaire différentiel: Une fois par mois (au plus tard le 5 du mois), un fichier reprenant toutes les modifications survenues le mois précédent doit être envoyé vers le serveur de la Commission. Pour chaque mouvement de machine (install, uninstall, instalafterbuy, uninstallandsold, uninstallwithkit) : -/ No d'identification du jeu (No de série de la machine automatique de classe IV) -/ No d'approbation Métrologie -/ Date du "mouvement" -/ No de licence "F2" où la dernière exploitation a eu lieu -/ No de licence "E" concerné (voir informations ci-dessous) -/ No de la vignette de taxe -/ Clé de répartition : % des revenus du titulaire de licence "F2" (exemple : 60) -/ Clé de répartition : % des revenus du titulaire de licence "E" (exemple : 40) Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F7" (L'élément "stock" reste vide : nbofitems = 0) Cette structure présente plusieurs listes de données : -/ La liste "install" : concerne les machines automatiques de classe IV placées dans des établissements de jeux de hasard durant la période concernée. -/ La liste "uninstall" : concerne les machines automatiques de classe IV retirées des établissements de jeux de hasard durant la période concernée. -/ La liste "installafterbuy" : concerne les machines automatiques de classe IV placées dans des établissements de jeux de hasard durant la période concernée et achetés à un autre titulaire belge de licence E. -/ La liste "uninstallandsold" : concerne les machines automatiques de classe IV retirées des établissements de jeux de hasard durant la période concernée et vendus à un autre titulaire belge de licence E. -/ La liste "uninstallwithkit" : concerne les machines automatiques de classe IV exploitées dans des établissements de jeux de hasard durant la période concernée et équipés d un Kit de transformation. Remarque : - Pour les machines automatiques de classe IV vendues à un autre titulaire belge de licence, le numéro de licence E de ce dernier doit être précisé (respecter le format). - Les ventes à un acheteur étranger doivent être mentionnées à la Commission des jeux de hasard. Cette dernière actualisera mensuellement la liste de stock dans sa base de données. - Les machines automatiques de classe IV qui sont définitivement hors de fonctionnement doivent être considérées comme vendues à un acheteur étranger. Lorsqu une machine automatique de classe IV est déplacée d un titulaire F2(X) vers un titulaire F2(Y), un record de type "uninstall" (titulaire F2(X)) et un record de type "install" (titulaire F2(Y)) doit être envoyé. -9-

10 Dans le cas d'une transformation (placement d'un kit), un record de type "uninstallwithkit" et un record de type "install" doit être prévus le jour même. Le but du type "uninstallwithkit" est d'informer la Commission que le numéro d'identification de la machine automatique de classe IV avant transformation est radié du parc de machines. Remarque concernant le champ No de licence "E" concerné : Le champ "supplierlicenseid" (no de licence de l'installateur "E") est : -/ dans le cas de la liste "uninstallandsold" : le no de licence "E" de l'installateur qui a acheté la machine automatique de classe IV; -/ dans le cas de la liste "installafterbuy" : le no de licence "E" de l'installateur qui a vendu la machine automatique de classe IV; -/ dans les autres cas : le no de licence "E" de l'installateur qui envoie le fichier. Ce champ fait double emploi avec le champ "DossierId" mais reste utile à des fins de vérification. -10-

11 4 CONDITIONS TECHNIQUES RELATIVES AU CABLAGE ET AUX COMPOSANTS PASSIFS DU LAN La personne obligée est responsable des composants passifs de son LAN et de sa documentation sous forme électronique. Documentation (voir aussi les chapitres 5, 6, 7, 8 et 9) a. "as-built" complet pour le F1 et pour les F2-Bureaux de paris b. Un dossier "proof of concept" est suffisant pour les F2-Librairies c. Un dossier "proof of concept" pour un F2-Bureau de paris peut être présenté et négocié. Le câblage doit être réalisé suivant les normes de câblage, instructions et toutes autres réglementations concernées (AHJ : authority having jurisdiction) Toute norme de câblage est acceptée pour autant que celle-ci puisse supporter les vitesses de données (bande passante) utilisées. Pour les câblages structurés en cuivre, la norme doit être au minimum Cat5 (ANSI/TIA/EIA) ou Cat5E (CENELEC). Normes de câblages : Internationales : ISO/IEC Ed.2:2002: Generic Cabling for Customer Premises ISO/IEC 14763: Implementation and Operation of Customer Premises Cabling Européennes : CENELEC EN50173: Generic Cabling Systems CENELEC EN : Business Premises (Bureaux de paris F2) CENELEC EN : SOHO (F2 librairies), CENELEC EN : Datacenter (F1) Américaines : ANSI/TIA/EIA-568B: Commercial Building Telecommunication Standard Lorsque d'autres appareils ou périphériques sont raccordés sur des appareils actifs leur câblage doit être décrit dans le dossier "as-built" ou "proof of concept". Remarque : Les instructions concernent la sécurité des personnes et des biens, l'électricité, les bâtiments, la sécurité incendie. La cellule ICT de la prend bien évidemment ces instructions en considération. -11-

12 5 CONDITIONS TECHNIQUES RELATIVES AUX COMPOSANTS ACTIFS DU LAN La personne obligée est responsable des composants actifs de son LAN et de sa documentation sous forme électronique. Tout composant actif (description, spécification,...) doit être décrit dans le dossier "as-built" ou "proof of concept". Lorsque d'autres appareils ou périphériques (autres que ceux strictement nécessaires pour l'exploitation des paris ou pour le réseau des machines automatiques de classe IV) sont raccordés, une documentation complète (but de l'appareil, description, spécifications, aspects relatif à la sécurité,...) doit être disponible dans le dossier "as-built" ou "proof of concept". -12-

13 6 CONDITIONS TECHNIQUES RELATIVES AUX CLIENTS ET AUX SERVEURS Généralités : La personne obligée est responsable de son réseau actif et de sa documentation sous forme électronique. Les principes de bases suivants doivent être suivis : a. Le réseau de production comprenant les jeux de hasard doit être physiquement séparé du réseau destiné à l'administration. b. Il ne peut y avoir de connexion sans fil sur le réseau de production. 1. Ces principes s'appliquent aux F1 et aux F2-Bureaux de paris ; 2. Pour les F2-Bureaux de paris et les F2-Librairies, où une intégration des services est implémentée via une liaison à bande unique, cette séparation physique n'est pas toujours possible. Le titulaire de licence F1 doit alors soumettre le dossier de conception à la cellule ICT de la Commission des jeux de hasard pour approbation. La personne obligée doit reprendre cette description de conception dans le dossier "asbuilt" F1/F2 ou dans le dossier "proof of concept". La séparation "logique" des réseaux, la séparation entre les communications internes et externes, le niveau de "sécurité", etc... de la configuration F2 doit être clairement démontrée. Il peut y avoir différents types d'installation mais la documentation doit clairement faire apparaître quel F2 tombe sous quel type d'installation ; Le F1 doit avoir un "contrôle total" du F2 pour ce qui concerne la prise des paris et l'émission des tickets ; L'imprimante à tickets doit être une imprimante indépendante qui sert uniquement à l'impression des tickets ; Si un terminal et/ou une imprimante est également utilisé pour des tâches administratives, cela doit être décrit dans le dossier "as-built" ou "proof of concept"; L'émulation d'un terminal sur un système intelligent est autorisée ; Le F2 ne peut en aucun cas pouvoir générer des tickets de paris sans une connexion F1-F2 active (off-line) ; La doit avoir une supervision du réseau "all-toone" complet ; La doit disposer des données pertinentes et pouvoir à distance contrôler le statut actif ou pas des F2. Exigences spécifiques pour les terminaux de paris : Le serveur gérant les paris doit se trouver en Belgique dans les locaux du titulaire de licence F1 ou sous sa supervision. Le titulaire de licence doit communiquer à la Commission des jeux de hasard l'adresse exacte du serveur. -13-

14 Exigences spécifiques pour les machines automatiques de classe IV : Le serveur destiné aux machines automatiques de classe IV doit se trouver auprès du titulaire de licence "E". La communication entre les machines automatiques de classe IV et le titulaire de licence "E" peut s'effectuer : 1. Via GPRS Le titulaire de licence est responsable de l'envoi des données une fois par jour. Cela doit s'effectuer via GPRS, les données ne peuvent pas être cryptées. Chaque fabricant / placeur doit, au préalable, indiquel quel module GPRS est utilisé. 2. Via le LAN du F2 Le titulaire de licence "F" donne son autorisation, il est responsable de cette configuration et de son intégration dans le dossier "as-built" ou "proof of concept". Protocole de communication Un protocole de communication standard est prévu, lequel uniformisera l échange de données entre l interface et la carte-mère des machines de jeux automatiques (voir Annexe 2) -14-

15 7 CONDITIONS TECHNIQUES RELATIVES AU LOCAL DESTINE AU "DATA-RACK" Pour le F1 : Il y a 3 possibilités : 1. Le F1 dispose de son propre datacenter ; 2. Le F1 utilise un datacenter externe ; 3. Le F1 fait usage des deux. Dans tous les cas, le datacenter doit : -/ Satisfaire aux normes, prescriptions et reglementations existantes ; -/ Pour les datacenter, les normes en usage sont : Tier 1, 2, 3 et 4 Pour le F2 : Pour les bureaux de paris, avec ou sans machine automatique, un dossier "as-built" complet doit être présenté tandis qu'un "proof of concept" doit être présenté et négocié. Pour les F2-Librairies un "proof of concept" peut être utilisé s'il est valable pour toutes les installations ou pour une série (voir aussi le chapitre 4). Un data-rack est normalement de type 19" (ou 10") et il peut être fixé au mur ou être "stand-alone". Chaque rack monté au mur doit se trouver à hauteur d'homme ou être d'accès facile pour le certificateur. Dans tous les cas, chaque rack doit pouvoir être verrouillé. Toutes dérogations à ces règles doivent être évaluées au cas par cas. -15-

16 8 CONDITIONS TECHNIQUES RELATIVES A LA LIAISON DE DONNEES AVEC LA COMMISSION DES JEUX DE HASARD La personne obligée assure une connexion IP adéquate avec la DMZ de la Commission des Jeux de hasard, de préférence par le biais du réseau de l'isp choisi. L'utilisation d'une adresse IP fixe et d'une largeur de bande minimum garantie est souhaitable. La personne obligée est également chargée de l acquisition, de l installation et de la programmation des composants actifs requis du LAN. La personne obligée est responsable de la connexion de la liaison de données à son système informatique. Transmission des fichiers : environnement sécurisé HTTPS. Le nouvel API, disponible en production depuis le 6 mai 2014 doit être utilisé. La transmission via FTP n'est plus autorisée. Les informations techniques se trouvent sur la page "protocoles informatiques" du site Internet de la. Lors de chaque transmission une validation (syntaxe XML + règles Schematron) est effectuée. Le statut de la vérification ("valid" ou "invalid") est renvoyé. Lorsque le statut est "invalid" le fichier est rejeté et donc considéré comme non reçu. Le programmeur du système de transmission de fichiers doit prendre ce statut en compte afin de prendre les mesures correctives nécessaires lorsque le statut est "invalid". Dans ce cas l'exploitant des machines de jeux doit être informé du problème et une solution technique doit être apportée. A l'avenir, une signature digitale pourra être implémentée. -16-

17 9 CONDITIONS SUPPLEMENTAIRES RELATIVES AU SYSTEME DE VIDEOSURVEILLANCE Des caméras doivent être installées au moins aux endroits suivants : - les caisses ; - le lieu d enregistrement et/ou de contrôle du joueur, de sorte que la constitution du fichier des personnes enregistrées puisse être suivi ; - les terminaux de paris - les machines automatiques de classe IV. Sur simple demande, les enregistrements demandés doivent être transmis à la Commission des jeux de hasard. Dans le cas de formats propriétaire le "viewer" adéquat doit être également fourni. Ce viewer doit fonctionner avec toutes les versions disponibles du système d exploitation Windows. Les images vidéo doivent posséder un framerate minimal de 12 images/seconde. La résolution minimale doit être 4SIF (525) 704 x 480 (NTSC) ou 4CIF/SIF (625) 704 x 576 (PAL). La qualité et le choix des caméras doivent tenir compte des conditions spéciales d éclairage prévalant dans l établissement de jeux de hasard. Pour les nouveaux systèmes de surveillance, il y a lieu d'utiliser des caméras couleurs. Le matériel vidéo sera placé de préférence dans le data-rack. Tout autre vidéo-rack sera placé à hauteur d'homme ou rendu accessible lors des contrôles. Dans tous les cas chaque vidéo-rack doit pouvoir être fermé et les responsabilités relatives aux accès doivent être définies. Des adaptations peuvent être présentées, discutées et acceptées. Les enregistrements doivent être conservés pendant quatre semaines. Les images doivent être constamment disponibles. Le titulaire de licence est tenu de notifier immédiatement, à la, tout dérangement technique survenu au niveau de la vidéosurveillance. Les images doivent reprendre la date et l'heure de la prise de vue. -17-

18 10 CONDITIONS RELATIVES À L INFORMATION COMPTABLE ET FINANCIÈRE (F0, F1, F2 ET F9) Généralités : Les informations financières doivent être communiquées à la Commission des jeux de hasard toutes les 24 heures dans le format XML. Ils doivent également être communiqués au SPF Finances (ou aux Services régionaux compétents) lorsqu'il en fait la demande. Tous les montants doivent être mentionnés en euro cents. Ces fichiers doivent être produits automatiquement et doivent être directement transmis par le serveur de la personne obligée à la Commission des jeux de hasard. Exigences pour les terminaux de paris : Informations financières - Détail des paris : -/ Numéro de licence F1 -/ Numéro de licence F2 (il y a un fichier par "F2") Pour chaque prise de pari : -/ Identification du terminal de pari -/ Identification de la catégorie de pari (Sport ; Event ; HorseRace ; Mixed) -/ No d'identification du ticket de pari -/ Sélections du parieur -/ Mise du parieur -/ Gain du parieur -/ TimeStamp de la prise de pari -/ TimeStamp de l'évènement sur lequel porte le pari Remarque : les champs "bettiming/start" et "bettiming/end" ne sont pas toujours chronologiques. Dans certains cas "start" peut être postérieur à "end". Par exemple pour le Live Betting "end" peut être la date du match (ex. 20:00) et "start" la prise de paris pendant le match (ex. 20:22). Dans cette nouvelle version des champs spécifiques : "bettiming/bet" et "bettiming/event" ont été prévus afin de supprimer cette incohérence. Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F0" Remarque : contrairement aux autres fichiers, ces données ne doivent pas être transmises journellement. Les données relatives aux 12 derniers mois doivent être conservées par la personne obligée. Les données relatives à une plage de date fixée doivent pouvoir être transmises, de la même manière que les autres fichiers, sur simple demande de la Commission. Informations financières - Résultats globaux du titulaire de licence F1 : -/ Numéro de licence F1 -/ Identification de la catégorie de pari -/ Total des mises -/ Total des gains attribués -/ Nombre de ticket -/ Numéro de suite du premier ticket de la journée -/ Numéro de suite du dernier ticket de la journée -18-

19 Remarque : pour les "numéro de suite" la procédure est la suivante (lorsque le numérotage n'est pas unique) : -/ le F1 collecte toutes les données de ses F2 ; -/ le F1 regroupe tous les tickets dans une nouvelle table avec un nouvel index (continu et croissant) ; -/ les "numéro de suite" sont générés sur base de ce nouvel index ; -/ le F1 conserve la table de correspondance afin de permettre de retrouver les références d'un ticket quelconque. Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F1" Informations financières - Résultats globaux du titulaire de licence F2 : -/ Numéro de licence F1 -/ Numéro de licence F2 Pour chaque terminal de pari -/ Identification du terminal de pari -/ Identification de la catégorie de pari (Sport ; Event ; HorseRace ; Mixed) -/ Total des mises -/ Total des gains attribués -/ Nombre de ticket Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F2" Etablissements de jeux de hasard mobiles de classe IV (bookmakers) : Pour les titulaires de licence F2 pour un établissement de jeux de hasard mobile de classe IV (bookmakers) les exigences suivantes s'appliquent : -/ Utiliser un PC pour engager des paris et enregistrer les données des paris "en temps réel"; -/ Générer un fichier Excel identique à ce qui est enregistré dans le "livre des contributions" ; -/ Conserver un double des tickets "papiers" chez le titulaire de licence pendant 7 ans afin de permettre les contrôles éventuels (ils doivent être mis à la disposition de la CJH ou du SPF Finances (ou les Services régionaux compétents) sur simple demande). -/ Enregistrer le "time stamp" du début de l'évènement et celui de la prise du pari. -/ Transmettre le fichier Excel, endéans les 24 h après la dernière course, au titulaire de licence F1 ; -/ Le titulaire de licence F1 se charge de convertir ces données en XML et de les transmettre, endéans les 24 h de la réception du fichier Excel, à la Commission des Jeux de hasard selon les modalités prévues par ce protocole. La certification du système via le titulaire de licence F1 concerné doit avoir lieu avant le 1 er janvier 2014 Remarque : ce régime d'exception sera autorisé jusqu'au 01/07/2015 (après quoi des "tickets électroniques" seront demandés). Exigences pour les machines automatiques de classe IV : Informations financières : (*) = données de base, c'est à dire données devant être récoltées en temps réel sur la machine ; voir exigences du point 3/ A Certification. -/ Nombre de machines concernées Pour chaque machine concernée : -/ No d'identification du jeu (No de série) (*) -/ No d'approbation Métrologie -/ No de la vignette de taxe -/ No de licence "F2" -/ Statut de la machine : Connect ou NoConnect -19-

20 -/ Total des mises de la journée -/ Total des gains de la journée -/ Résultat de la journée -/ Nombre de parties jouées (compteur global) (*) -/ Nombre d'ouverture de porte (compteur global) (*) -/ Compteur Total Bet à l'ouverture (*) -/ Compteur Total Bet à la fermeture (*) -/ Compteur Total Win à l'ouverture (*) -/ Compteur Total Win à la fermeture (*) -/ TimeStamp de l'ouverture -/ TimeStamp de la fermeture Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F9" Remarques concernant l envoi des données relatives aux machines automatiques de classe IV manquantes : Les données extraites lors de la fermeture doivent également servir de valeurs de départ pour l exploitation de la journée suivante (ouverture). Pour toutes les machines automatiques de classe IV qui ne répondent pas, un polling continue à courir (p.ex. toutes les 10 ). Toutes les données collectées sont transférées, conformément au protocole, à la Commission des jeux de hasard. Si une machine automatique de classe IV ne répond pas durant plusieurs jours, les données extraites lors du dernier contact sont considérées comme étant les "données de régularisation" à transmettre pour les jours où le contact a été perdu Un fichier doit être transmis pour chaque jour. Le fichier à le statut "connect" si les données proviennent d'une transmission réelle. Le fichier à le statut "NoConnect" s'il s'agit des données de régularisation décrites ci-dessus. -20-

21 11 CONDITIONS RELATIVES À L'ENREGISTREMENT (F5) Il convient de transmettre à la Commission des jeux de hasard, toutes les 24 heures, un fichier en format XML comportant par visiteur à enregistrer (c'est à dire ceux qui prennent des paris pour plus de 1000 ) : -/ Numéro de licence F1 -/ Numéro de licence F2 Pour chaque visiteur : -/ Date et heure de l'enregistrement -/ Nom -/ Prénom(s) -/ Lieu de naissance -/ Date de naissance -/ Profession -/ Adresse -/ Montant de la mise -/ Date de l'opération -/ Détails du pari Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F5" Dans le cas où l'établissement tient uniquement un registre électronique, le programme doit générer une fiche reprenant les données mentionnées ci-dessus plus la date du jour et l'heure et un numéro de suite séquentielle. Le client doit signer cette fiche lors de son enregistrement. Ces fiches doivent être conservées dans les mêmes conditions que le registre traditionnel. Ce fichier doit être généré de façon automatique et envoyé directement à la Commission des jeux de hasard à partir du serveur de la personne obligée. Lors du premier enregistrement, la pièce d'identité doit être immédiatement photocopiée et restituée sans délai. La photocopie de la pièce d'identité doit être conservée pendant cinq ans après le dernier enregistrement. Lors du premier enregistrement, le joueur est tenu d apposer sa signature sur la photocopie de la pièce d'identité. -21-

22 12 CONDITIONS RELATIVES AU CONTRÔLE TECHNIQUE (F6 ET F10) Ces informations doivent être transmises une fois par semaine (le vendredi) à la Commission des jeux de hasard : Pour les terminaux de paris -/ Nombre de terminaux de paris concernées Pour chaque terminal de paris concernée : -/ No d'identification du terminal de paris (No de série) -/ No de licence "F2" Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F6" Pour les machines automatiques de classe IV (*) = données de base, c'est à dire données devant être récoltées en temps réel sur la machine ; voir exigences du point 3/ A Certification. -/ Nombre de machines concernées Pour chaque machine concernée : -/ No d'identification du jeu (No de série de la machine) (*) -/ No de licence "F2" -/ No d'approbation Métrologie (*) -/ Date de la dernière vérification -/ Identification de la version software (*) -/ Clés utilisées pour la Signature software (*) -/ Signature software (*) Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F10" -22-

23 13 CONDITIONS RELATIVES À LA DOCUMENTATION CONCERNANT LE SYSTÈME INFORMATIQUE ET LE SYSTÈME DE VIDÉOSURVEILLANCE La documentation suivante doit être transmise préalablement à la Commission des jeux de hasard : Concernant le système informatique : - nom et adresse du fournisseur et/ou du fabricant ; - numéros d identification et de série ; - description du matériel et du logiciel ; - compilateur utilisé ; - dossier technique et fonctionnel de l application. Concernant le système de vidéo-surveillance : - nom et adresse du fournisseur et/ou du fabricant ; - numéros d identification et de série ; - localisation et plan du poste de contrôle ; - plan technique du système et de son fonctionnement ; - documentation technique relative aux caméras utilisées. -23-

24 14 UTILISATION DES NOUVELLES TECHNOLOGIES DE L'INFORMATION Pas d'exigence au stade actuel. -24-

25 15 NORMES CONCERNANT LA NOMENCLATURE DES FICHIERS À ENVOYER Les noms de fichiers ont la structure suivante : IV_licenceId_Fx_date * _time *.xml ( * : de préférence celle de la création du fichier) Exemple : IV_012345_F5_ _ xml Remarque : Pour les fichiers F0, F2 et F5 il y a un fichier par F2 concerné. Dans ce cas, le nom de fichier doit avoir la structure suivante : IV_organiserId_Fx_F?licenceId_date * _time *.xml Exemple : IV_012345_F2_FB001234_ _ xml ( * : de préférence celle de la création du fichier) -25-

26 16 APPROBATION Le présent protocole a été établi par la Commission des jeux de hasard et approuvé en sa séance du 7 octobre Les constructeurs doivent apporter les modifications nécessaires à leur système online avant le 1 er juillet La certification obtenue pour la version protocole précédente, reste valable. La Commission des jeux de hasard veillera scrupuleusement à la stricte application du présent protocole. Le non-respect des dates mentionnées ci-dessus peut donner lieu à des sanctions. Le Président. E. Marique. -26-

27 17 ANNEXE 1 : DÉFINITIONS XML Les tableaux suivants donnent un aperçu des données à transmettre en XML. Avant transmission, les fichiers doivent être validés sur base des fichiers de définition XSD et du programme de validation disponibles à l'adresse suivante : ; Section <La Loi> <Protocoles> <Informatique>. Définitions du fichier "IV_F0" (Point 10) : /f0/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f0) = IV_V04 generalinfo/licenseid 1 int Le numéro de la licence F2 (un fichier par "F2") generalinfo/filedate 1 date Date du fichier generalinfo/licensetype 1 licensetypetype Type de licence : FB, FC, FD ou FE generalinfo/ 1 type du responsable On-Line generalinfo/organiserid 1 int Le numéro de la licence F1 games/nbofitems 1 int Nombre de paris games/ game 0 n gametype Information détaillées pour chaque pari gametype : /f0/games/ game/ Field Cardinality Data type Description id 1 string Identification du terminal de pari (no de série) gametype 1 gametypetype Catégorie pari (Sport ; Event ; HorseRace ; Mixed) ticketid 1 string No d'identification du ticket gamerselection 1 string Les sélections (elles peuvent être codées) gamerbetamount 1 long Mise du joueur (en eurocents) gamerwonamount 0 long Gain du joueur (en eurocents) (optionnel si inconnu) bettiming/bet 1 datetime Time Stamp prise du pari bettiming/event 1 datetime Time Stamp prise de l'évènement Définitions du fichier "IV_F1" (Point 10) : /f1/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f1) = IV_V04 generalinfo/licenseid 1 int Le numéro de la licence F1 generalinfo/filedate 1 date Date du fichier generalinfo/licensetype 1 licensetypetype Type de licence : FA generalinfo/ 1 type du responsable On-Line games 4 gamestype Information détaillées par catégorie de pari gamestype : /f1/games/ Field Cardinality Data type Description gametype 1 gametypetype Catégorie pari (Sport ; Event ; HorseRace ; Mixed) totalbetamount 1 long Total des mises (en eurocents) totalwonamount 1 long Total des gains attribués (en eurocents) nbtickets 1 long Nombre de ticket firstticketnb 1 integer Numéro de suite du premier ticket de la journée lastticketnb 1 integer Numéro de suite du dernier ticket de la journée -27-

28 Définitions du fichier "IV_F2" (Point 10) : /f2/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f2) = IV_V04 generalinfo/licenseid 1 int Le numéro de la licence F2 (un fichier par "F2") generalinfo/filedate 1 date Date du fichier generalinfo/licensetype 1 licensetypetype Type de licence : FB, FC ou FD generalinfo/ 1 type du responsable On-Line generalinfo/organiserid 1 int Le numéro de la licence F1 games/nbofitems 1 int Nombre de terminaux games/gamedetail 0 n gamedetailtype Informations détaillées par terminal gamedetailtype : /f2/games/gamedetail/ Field Cardinality Data type Description id 1 string Identification du terminal de pari (no de série) gametype 1 gametypetype Catégorie pari (Sport ; Event ; HorseRace ; Mixed) gamerbetamount 1 long Total des mises (en eurocents) gamerwonamount 1 long Total des gains attribués (en eurocents) nbtickets 1 long Nombre de ticket Définitions du fichier "IV_F5" (Point 11) : /f5/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f5) = IV_V04 generalinfo/licenseid 1 int Le numéro de la licence F2 (un fichier par "F2") generalinfo/filedate 1 date Date du fichier generalinfo/licensetype 1 licensetypetype Type de licence : FB, FC ou FD generalinfo/ 1 type du responsable On-Line generalinfo/ organiserid 1 int Le numéro de la licence F1 guests/nbofitems 1 int Nombre de visiteurs guests/guest 0 n guesttype Données des visiteurs guesttype : /f5/guests/guest/ Field Cardinality Data type Description timestamp 1 datetime TimeStamp de l'enregistrement lastname 1 string Nom firstname 1 string Prénom birthday 1 date Date de naissance birthplace 1 string lieu de naissance profession 1 string Profession housenbr 1 string Numéro housebox 1 string Boîte street 1 string Rue zipcode 1 string Code postal city 1 string commune country 1 string pays (2chr conformément ISO alpha-2 code) betamount 1 long Montant de la mise (en eurocents) betdate 1 date Date de l'opération -28-

29 betdetail 1 string Détails du pari Définitions du fichier "IV_F6" (Point 12) : /f6/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f6) = IV_V04 generalinfo/licenseid 1 int Le numéro de la licence F1 generalinfo/filedate 1 date Date du fichier generalinfo/licensetype 1 licensetypetype Type de licence : FA generalinfo/ 1 type du responsable On-Line terminals/nbofitems 1 int Nombre de terminaux concernées terminals/ terminal 0 n terminaltype Informations détaillées par terminal terminaltype : /f6/terminals/terminal/ Field Cardinality Data type Description terminalid 1 string Le numéro d'identification du terminal de paris (no de série) licenseid 1 int Numéro de licence F2 Définitions du fichier "IV_F7" (Point 3 D) : /f7/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f7) = IV_V04 generalinfo/licenseid 1 int Le numéro de la licence E Placeur generalinfo/manufacturerid 0 1 int Le numéro de la licence E Fabricant generalinfo/filedate 1 date Date du fichier generalinfo/licensetype 1 licensetypetype Type de licence : E generalinfo/ 1 type du responsable On-Line stock 1 detailtype Les appareils en magasin install uninstall installafterbuy uninstallandsold uninstallwithkit detailtype : /f7/.../ detailtype detailtype detailtype detailtype detailtype -29- Les machines automatiques de classe IV placés dans des établissements de jeux de hasard durant la période concernée Les machines automatiques de classe IV retirés des établissements de jeux de hasard durant la période concernée Les machines automatiques de classe IV placés dans des établissements de jeux de hasard durant la période concernée et achetés à un autre titulaire belge de licence E Les machines automatiques de classe IV retirés des établissements de jeux de hasard durant la période concernée et vendus à un autre titulaire belge de licence E Les machines automatiques de classe IV exploités dans des établissements de jeux de hasard durant la période concernée et équipés d un Kit de transformation Field Cardinality Data type Description nbofitems 1 int Nombre de machines concernées item 0 n itemtype Informations détaillées par machine itemtype: /f7/.../item/ Field Cardinality Data type Description

30 gameid 1 string Le numéro d'identification unique du jeu (no de série) approvalid 1 string Le numéro de l'approbation de la métrologie operationdate 1 date Date de l'opération operatorlicenseid 1 int Numéro de la licence F2 où la dernière exploitation a eu lieu supplierlicenseid 1 int Numéro de licence "E" concerné (voir Point 3D) taxnumber 1 string Numéro de la vignette de taxe repartitionkey/operator 1 int Clé de répartition : % des revenus du "F2" repartitionkey/supplier 1 int Clé de répartition : % des revenus du "E" Définitions du fichier "IV_F9" (Point 10) : /f9/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f9) = IV_V04 generalinfo/licenseid 1 int Le numéro de la licence E (ou F1) Placeur generalinfo/manufacturerid 0 1 int Le numéro de la licence E Fabricant generalinfo/filedate 1 date Date du fichier generalinfo/licensetype 1 licensetypetype Type de licence : E (ou FB) generalinfo/ 1 type du responsable On-Line details/nbofitems 1 int Nombre de machines concernées details/ detail 0 n detailinfotype Informations détaillées pour chaque machine detailinfotype : /f9/details/detail/ Field Cardinality Data type Description gameid 1 string Numéro d'identification unique du jeu (no de série) (*) approvalid 1 string Numéro d'approbation de la métrologie (*) licenseid 1 string numéro de licence F2 taxnumber 1 string N de la vignette de taxe pour l'année en cours status 1 Connect/NoConnect Statut de la machine : Connect ou NoConnect totalbetamount 1 long Montant total des mises de la journée (en eurocents) totalwinresult 1 long Montant total des gains de la journée (en eurocents) dayresult 1 long Résultat de la journée (en eurocents) nbgamesplayed 1 long Le nombre de parties joués (compteur global) (*) nbdooropen 1 long Nombre d'ouverture de porte (compteur global) (*) totalbetbegin 1 long Compteur Total Bet à l'ouverture (en eurocents) (*) totalbetend 1 long Compteur Total Bet à la fermeture (en eurocents) (*) totalwinbegin 1 long Compteur Total Win à l'ouverture (en eurocents) (*) totalwinend 1 long Compteur Total Win à la fermeture (en eurocents) (*) opening/start 1 datetime Date et l'heure de la récolte des compteurs à l'ouverture opening/end 1 datetime Date et l'heure de la récolte des compteurs à la fermeture (* = données de base, c'est à dire données devant être récoltées en temps réel sur la machine ; voir exigences du point 15 A Certification) Définitions du fichier "IV_F10" (Point 12) : /f10/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f10) = IV_V04 generalinfo/licenseid 1 int Le numéro de la licence E (ou F1) Placeur -30-

31 generalinfo/manufacturerid 0 1 int Le numéro de la licence E Fabricant generalinfo/filedate 1 date Date du fichier generalinfo/licensetype 1 licensetypetype Type de licence : E (ou FB) generalinfo/ 1 type du responsable On-Line details/nbofitems 1 int Nombre de machines concernées details/detail 0 n detailinfotype Informations détaillées par machine detailinfotype : /f10/details/detail/ Field Cardinality Data type Description gameid 1 string Le numéro d'identification unique du jeu (no de série) (*) approvalid 1 string No d'approbation du modèle (*) licenseid 1 int Numéro de licence F2 lastcheckdate 1 date Date de la dernière vérification gamesoftwareversion 1 string Identification de la version software (*) gamekeys 1 string Clés utilisées pour la signature software (*) eprom 1 string Signature software (*) (* = données de base, c'est à dire données devant être récoltées en temps réel sur la machine ; voir exigences du point 15 A Certification) -31-

32 18 ANNEXE 2 : PROTOCOLE DE COMMUNICATION STANDARD De plus, un protocole de communication standard est prévu, lequel uniformisera l échange de données entre l interface et la carte-mère des machines à sous automatiques. A. But : Ce document décrit un protocole de transmission de données entre des machines de jeu et une interface de réseau dans une configuration master - slave où toute communication est amorcée par l'interface de réseau et la machine de jeu envoie une réponse en retour. Toutes les fonctions sont communes pour tous les jeux ce qui signifie que le protocole doit être respecté par toutes les machines de jeu et que l'interface de réseau ne peut pas utiliser des fonctions réservées. Les instituts d'approbation vérifieront que la machine de jeu respecte ce protocole. B. Terminologie. Dans ce document, les termes suivants sont utilisés avec les descriptions ci-dessous : Jeu : Tout type de terminal de jeu qui est soit une machine de jeu autonome soit un membre d'un jeu multi joueurs. Interface : l'interface réseau qui demande l'information au jeu. Master : utilisé pour décrire l interface Slave : le terminal de jeu en tant qu autonome ou membre d'un jeu multi joueurs. C. Connexion physique entre l interface et le jeu. Le lien physique est une connexion RS-232 à la norme V24 et définie comme suit : -/ Baud Rate: 9600 bps -/ Data Bits: 8 -/ Parity: None -/ Stop Bit: 1 -/ RTS/CTS hardware handshaking supporté en option. D. Règles de conversion de données. Dans ce document, un nombre avec le terme '0x' représente un nombre hexadécimal, un nombre sans préfixe est un nombre décimal, un caractère ASCII imprimable est inclus dans des cotations simple (') et une chaîne de caractères est incluse dans des cotations doubles ("). Une table de conversion des valeurs décimales et hexadécimales ASCII est reprise dans l'annexe 3. D.1. Conversion d une série ou d un caractère: Chaque caractère est codifié suivant la table ASCII. Exemple: pour envoyer la chaîne test 1, 6 bytes doivent être envoyées et les notations valables sont : test 1 - t e s t 1-0x74 0x65 0x73 0x74 0x20 0x31 D.2. Conversion de nombre: Tous les nombres sont exprimés dans leur valeur hexadécimale et transmis en codant chaque octet hexadécimal dans leurs 2 octets d'ascii respectifs où la majuscule est utilisée pour les valeurs A à F ; Exemple: pour transmettre 0x07: envoyer les 2 bytes 0x30 0x37 Pour transmettre la valeur compteur = 0x02BB68B8: Envoyer les 8 bytes 0x30 0x32 0x42 0x42 0x36 0x38 0x42 0x38-32-

33 D.3. Termes utilisés: Dans la description de la série de commandes et de réponses, on utilisera les termes suivants : STX: valeur hexadécimale 2 = 0x02 CD: commande envoyée et codée en 2 bytes selon D.2. DATA: terme général pour la série de données et la série de numéros codes suivant D.1. et D.2. CS: checksum de 1 byte codé sur 2 bytes selon D.2. CS est l'octet le moins significatif de la somme de tous les octets de données qui vont (exclu) de l'octet de début STX (exclu) jusqu à la somme et octet de fin EOT. EOT: Valeur hexadécimale 4 = 0x04 D.4. Format date / heure : Les dates et heures doivent être formatées de la manière suivante : Date : aaaa/mm/jj. Heure : hh:mm:ss (format 24 h) E. Communication prototype. Toutes les communications seront initialisées par une commande envoyée du master au slave utilisant un paquet de 4 octets contenant l'octet de début STX, l identificateur de commande CD et l'octet d'arrêt EOT. Chaque fois que le slave reçoit une commande, il envoie en retour une réponse composée de l'octet de début (STX), la commande de réception CD, les DONNÉES, le checksum CS et l'octet d'arrêt (EOT). Si le slave (jeu) ne répond pas après 100ms, la chaîne de commande est envoyée de nouveau par le master. Dans le cas où il n'y a toujours aucune réponse endéans les 100 ms, le master réenvoie la série de commandes de nouveau après 1s, ensuite après 10s si toujours aucune réponse et finalement après 100s si toujours aucune réponse du slave. Après 5 essais échoués, le statut du slave (jeu) devient 'offline'. Le master peut continuer à contrôler le slave en envoyant des fonctions. Si le slave répond valablement, le statut 'offline' est annulé. Si la commande n'est pas reconnue par la machine de jeu, il renvoie une commande nulle utilisant le format STX "00" CS EOT. F. Définition des commandes. Toutes les commandes, qui ne sont pas définies dans la table ci-dessous sont des commandes réservées ne peuvent pas être allouées. -33-