Version III_V11 1 er novembre CONTENU DU PRÉSENT DOCUMENT DÉFINITIONS ET ABRÉVIATIONS... 5

Transcription

1 Protocole relatif aux règles de contrôle et de surveillance des jeux de hasard dans les établissements de jeux de hasard de classe III au moyen d un système informatique approprié. (Horeca) - Texte coordonné - Version : III_V11 du 1 er novembre 2015

2

3 Table des matières Page 1 CONTENU DU PRÉSENT DOCUMENT DÉFINITIONS ET ABRÉVIATIONS CONDITIONS TECHNIQUES RELATIVES AU CÂBLAGE ET AUX COMPOSANTS PASSIFS DU LAN CHEZ LA PERSONNE OBLIGÉE CONDITIONS TECHNIQUES RELATIVES AUX COMPOSANTS ACTIFS DU LAN CHEZ LA PERSONNE OBLIGÉE CONDITIONS TECHNIQUES RELATIVES AUX CLIENTS ET AUX SERVEURS CHEZ LA PERSONNE OBLIGÉE (F11) CONDITIONS TECHNIQUES RELATIVES AU LOCAL DESTINÉ AU "DATA-RACK" CHEZ LA PERSONNE OBLIGÉE CONDITIONS TECHNIQUES RELATIVES À LA LIAISON DE DONNÉES DE LA PERSONNE OBLIGÉE AVEC LA COMMISSION DES JEUX DE HASARD CONDITIONS RELATIVES À LA LIAISON ENTRE LE TITULAIRE D'UNE LICENCE DE CLASSE C ET LA PERSONNE OBLIGÉE CONDITIONS RELATIVES À L INFORMATION COMPTABLE ET FINANCIÈRE (F9) CONDITIONS RELATIVES AU CONTRÔLE TECHNIQUE CHEZ LA PERSONNE OBLIGÉE (F10) CONDITIONS RELATIVES À LA DOCUMENTATION CONCERNANT LE SYSTÈME INFORMATIQUE CHEZ LA PERSONNE OBLIGÉE UTILISATION DES NOUVELLES TECHNOLOGIES DE L'INFORMATION CONDITIONS GÉNÉRALES, NI SPÉCIFIQUE, NI LIÉES AUX SUJETS PRÉCÉDENTS (F7) NORMES CONCERNANT LA NOMENCLATURE DES FICHIERS À ENVOYER PAR LA PERSONNE OBLIGÉE CERTIFICATION APPROBATION ANNEXE 1 : DÉFINITIONS XML ANNEXE 2 : PROTOCOLE DE COMMUNICATION STANDARD ANNEXE 3 : TABLE ASCII ANNEXE 4 : ARRÊTÉ ROYAL DU 23 MAI

4 1 CONTENU DU PRÉSENT DOCUMENT L art. 43, 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 III 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. 7 de l arrêté royal du 23/05/2003 relatif aux modalités de surveillance et de contrôle des jeux de hasard dans les établissements de jeux de hasard de classe III, au moyen d'un système informatique approprié (M.B. 04/06/2003). -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 Personne obligée Tout titulaire d'une licence de classe E qui met à disposition, sous quelque forme que ce soit, des appareils de jeux de hasard chez un titulaire d'une licence de classe C, ou tout titulaire d'une licence de classe C qui possède et exploite ses propres appareils de jeux de hasard On-line Est considéré comme partie intégrante du système on-line, tout ce qui se trouve entre la machine de jeu 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 SSH Secure shell HTTP Hypertext transfert protocol. DMZ Demilitarized Zone Connection IP connection basée sur le protocol Internet ISP Internet Service Provider IP-adres Internet Protocol adres. -5-

6 3 CONDITIONS TECHNIQUES RELATIVES AU CÂBLAGE ET AUX COMPOSANTS PASSIFS DU LAN CHEZ LA PERSONNE OBLIGÉE Il convient d utiliser du câble UTP, minimum CAT5, 100 ohm, à 8 fils et des connecteurs RJ45. Les 8 fils doivent être connectés. Les câbles doivent être installés de manière correcte. Lors de la réalisation du point central de ce réseau en étoile, il convient d utiliser un data-rack 19 et des panneaux patch rackmounted. Ce rack servira uniquement à loger des composantes du LAN. Un PC peut faire office de serveur avec l approbation de la. Tous les points terminaux doivent être identifiés de manière univoque et la même identification sera apposée sur les panneaux patch centraux. Le LAN doit au moins être compatible avec les standards LAN suivants : 10BASE-T, 100BASE-T, 100BASE-TX, 100BASE-T4. Une documentation de qualité doit être présente sur place. Elle doit être adaptée soigneusement lors de chaque adaptation et comprend au moins les informations suivantes : - identification de l installateur ; - plan de l installation, indication des points terminaux, y compris l identification univoque ; - une représentation schématique du data-rack avec placement des composants actifs et passifs du LAN ; - une liste détaillée de tous les câbles UTP mis en place accompagnée de la date d installation, du code d identification et de la longueur exprimée en mètres ; - un rapport test de tous les câblages horizontaux. Pour chaque point terminal, il convient de joindre un rapport séparé contenant au moins les données suivantes : - date et heure du test ; - appareils de test utilisés ; - schéma du câblage ; - résultats du test, tels que Propagation delay, résistance, facteur d amortissement ; - liste des standards réseaux compatibles pour ce point terminal. Cette documentation doit être également disponible sous forme électronique. -6-

7 4 CONDITIONS TECHNIQUES RELATIVES AUX COMPOSANTS ACTIFS DU LAN CHEZ LA PERSONNE OBLIGÉE. Il convient d utiliser, au choix, un hub ou un switch compatible avec les standards réseaux précités. La connexion de la liaison de données avec la Commission des jeux de hasard doit être exécutée de manière correcte. En général, l utilisation des connexions de type "wireless" est interdite. Uniquement dans des cas exceptionnels et après avis favorable de la Commission des Jeux de Hasard, une dérogation sur ce principe peut être accordée. -7-

8 5 CONDITIONS TECHNIQUES RELATIVES AUX CLIENTS ET AUX SERVEURS CHEZ LA PERSONNE OBLIGÉE (F11) Tous les clients et serveurs doivent être équipés d une carte de réseau avec connexion RJ45. Tous les clients et serveurs doivent soutenir le Protocole TCP/IP IPV4 et/ou IPV6, disposer d une adresse IP fixe et être joignables directement par TCP/IP. Aucun autre mode de connexion n est autorisé. Des adresses IP dynamiques correspondant aux DNS dynamiques ne sont pas autorisées Les systèmes de gestion doit être une version de Windows, d Unix ou de Linux. Une documentation à jour relative aux adresses IP attribuées et les adresses mac correspondantes, accompagnées de l identification univoque du point terminal auquel est connecté le client ou le serveur sera conservée. Cette documentation doit être également disponible sous forme électronique. Si des serveurs DHCP, WINS ou DNS sont utilisés, une documentation complète concernant ces serveurs doit également être présente. Cette documentation doit être également disponible sous forme électronique. Remarque : Les exigences reprises ci-dessus ne s'appliquent pas aux bingos mais uniquement aux clients qui constituent le "système on-line". Polling Un système de polling doit être prévu sur chaque appareil de jeu automatique dont l exploitation est autorisée dans un établissement de classe III. Le logiciel installé sur ces appareils doit être adapté de telle sorte que, lors du démarrage, un premier polling de l appareil de jeu soit automatiquement exécuté avant que l appareil soit mis à la disposition de la clientèle. Le polling est ensuite effectué 24 h sur 24, 7 jours sur 7, à raison de 1 polling par heure. Afin de devoir modifier le moins possible le hardware, la procédure suivante est prévue : - Si un polling est négatif le module GPRS enregistre la date et l heure de la tentative ; - Si 10 pollings consécutifs sont négatifs, le bingo peut rester en exploitation pour autant que lors du polling positif suivant un message (voir ci-dessous) soit préparé et conservé en mémoire. - Si un polling positif est réalisé avant d atteindre 10 pollings négatifs, la liste est détruite et l envoi d un message n est pas nécessaire. - Il n y a pas de différence entre un polling négatif au démarrage d un bingo et durant l exploitation. - S il n y a pas de polling positif durant les 48 heures après le premier polling négatif, le bingo doit être rendu indisponible pour les joueurs et il ne peut être remis en exploitation qu après un polling positif. - 1x par mois le titulaire de licence classe E envoie un relevé des interruptions à la Commission. Les données à transmettre sont : -/ Nombre de machines concernées Pour chaque machine concernée : -/ No d'identification du jeu (No de série de la machine) -/ No d'approbation Métrologie -/ No de licence "C" -/ IMEI -8-

9 -/ LOCI -/ TimeStamp 1 er polling négatif -/ TimeStamp du polling positif Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "III_F11" 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). -9-

10 6 CONDITIONS TECHNIQUES RELATIVES AU LOCAL DESTINÉ AU "DATA-RACK" CHEZ LA PERSONNE OBLIGÉE Le data-rack doit être disposé de telle manière que l avant et l arrière soient facilement accessibles pour l entretien. Le cas échéant, il convient de prévoir un système de refroidissement adéquat afin que l appareillage électronique puisse fonctionner dans des conditions optimales. -10-

11 7 CONDITIONS TECHNIQUES RELATIVES À LA LIAISON DE DONNÉES DE LA PERSONNE OBLIGÉE 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. -11-

12 8 CONDITIONS RELATIVES À LA LIAISON ENTRE LE TITULAIRE D'UNE LICENCE DE CLASSE C ET LA PERSONNE OBLIGÉE Les jeux automatiques au sein des établissements de jeux de hasard de classe III peuvent fonctionner de manière autonome pendant maximum 48 heures. La personne obligée est responsable de la transmission des données à raison d une fois toutes les 24 heures. Cet envoi doit être exécuté via GPRS (ou via un système considéré comme équivalent par le certificateur). Le contenu des messages ne peut PAS être codé. Tout fabricant/installateur doit préciser au préalable le module GPRS incorporé. Tous les bingos doivent envoyer des données au serveur via un module GPRS, même si celui-ci se trouve dans le même lieu (par exemple, locaux privés dans le même bâtiment que le café). Chaque ensemble de données envoyé à un serveur contient un nouveau champ de données "IMEI" (la valeur est lue à partir du module GPRS) et un nouveau champ de données "LOCI" (la valeur est lue depuis la carte SIM). Ces données sont enregistrées dans la base de données. Lorsque la transmission n est pas possible dans le délai donné, les jeux automatiques doivent être arrêtés (voir Point 5 - Polling). -12-

13 9 CONDITIONS RELATIVES À L INFORMATION COMPTABLE ET FINANCIÈRE (F9) Les informations financières doivent être communiquées à la Commission des jeux de hasard toutes les 24 heures dans le format XML. 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. L heure d ouverture et de fermeture d un débit de boissons a été fixée de commun accord à 24h lors de la réunion sectorielle du 22/11/2006. 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 15/ 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 licence "C" -/ No de la vignette de taxe pour l'année en cours -/ Statut de la machine : Connect ou NoConnect -/ 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) (*) -/ Nombre d'ouverture de glace (compteur global) (*) -/ Compteur Total Bet à l'ouverture (*) -/ Compteur Total Bet à la fermeture (*) -/ Compteur Total Win à l'ouverture (*) -/ Compteur Total Win à la fermeture (*) -/ Date et l'heure de la récolte des compteurs à l'ouverture -/ Date et l'heure de la récolte des compteurs à la fermeture -/ IMEI -/ LOCI Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "III_F9" Remarque concernant l envoi des données relatives à des appareils de jeux de hasard manquants : 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 tous les bingos 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 un bingo 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 a le statut "connect" si les -13-

14 données proviennent d'une transmission réelle. Le fichier a le statut "NoConnect" s'il s'agit des données de régularisation décrites ci-dessus. -14-

15 10 CONDITIONS RELATIVES AU CONTRÔLE TECHNIQUE CHEZ LA PERSONNE OBLIGÉE (F10) Ces informations doivent être transmises une fois par semaine (le vendredi) à la Commission des jeux de hasard : (*) = 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. -/ Nombre de machines concernées Pour chaque machine concernée : -/ No d'identification du jeu (No de série de la machine) (*) -/ No d'approbation Métrologie (*) -/ No de licence "C" -/ 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 "III_F10" -15-

16 11 CONDITIONS RELATIVES À LA DOCUMENTATION CONCERNANT LE SYSTÈME INFORMATIQUE CHEZ LA PERSONNE OBLIGÉE 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. -16-

17 12 UTILISATION DES NOUVELLES TECHNOLOGIES DE L'INFORMATION Pas d'exigences au stade actuel. -17-

18 13 CONDITIONS GÉNÉRALES, NI SPÉCIFIQUE, NI LIÉES AUX SUJETS PRÉCÉDENTS (F7) INVENTAIRE DES MACHINES (III_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 III 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) -/ No d'approbation Métrologie -/ Date du "mouvement" -/ No de licence "C" 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 "C" (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 "III_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 "C" 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) -/ No d'approbation Métrologie -/ Date du "mouvement" -/ No de licence "C" 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 "C" (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 "III_F7" (L'élément "stock" reste vide : nbofitems = 0) Cette structure présente plusieurs éléments : -/ Elément "install" : concerne les jeux de hasard placés dans des établissements de jeux de hasard durant la période concernée. -/ Elément "uninstall" : concerne les jeux de hasard retirés des établissements de jeux de hasard durant la période concernée. -18-

19 -/ Elément "installafterbuy" : concerne les jeux de hasard 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. -/ Elément "uninstallandsold" : concerne les jeux de hasard retirés des établissements de jeux de hasard durant la période concernée et vendus à un autre titulaire belge de licence E. -/ Elément "uninstallwithkit" : concerne les jeux de hasard exploités dans des établissements de jeux de hasard durant la période concernée et équipés d un Kit de transformation. Remarque : - Pour les appareils vendus à 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 appareils qui sont définitivement hors de fonctionnement doivent être considérés comme vendus à un acheteur étranger. Lorsqu un appareil de jeu automatique est déplacé d un titulaire X vers un titulaire Y, un élément de type "uninstall" (titulaire X) et un élément de type "install" (titulaire Y) doit être envoyé. Dans le cas d'une transformation (placement d'un kit), un élément de type "uninstallwithkit" et un élément 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 avant transformation est radié du parc de machines. Remarque concernant le champ No de licence "E" concerné : Le champ "installerdossiereid" (no de licence de l'installateur "E") est : -/ dans le cas de l'élément "uninstallandsold" : le no de licence "E" de l'installateur qui a acheté la machine ; -/ dans le cas de l'élément "installafterbuy" : le no de licence "E" de l'installateur qui a vendu la machine ; -/ 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. -19-

20 14 NORMES CONCERNANT LA NOMENCLATURE DES FICHIERS À ENVOYER PAR LA PERSONNE OBLIGÉE Les noms de fichiers ont la structure suivante : III_licenceId_Fx_date * _time *.xml ( * : de préférence celle de la création du fichier) Exemple : III_012345_F9_ _ xml -20-

21 15 CERTIFICATION 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. Le détenteur de licence E (placeur) doit de nouveau certifier son système s'il y a eu des changements (autres que les upgrades software on-line) dans son système on-line. La fiabilité et la disponibilité de la connexion data avec les jeux automatiques dans les établissements de classe III 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 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 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 on-line. 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 ; -/ 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 E". 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é. -21-

22 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 : 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/ Détection glace : Le gestionnaire du système on-line doit tenir à jour, sur son serveur, l'historique des changements de glace (time stamp + signature de la glace). La Commission doit pouvoir accéder à ces données sur simple demande. -22-

23 16 APPROBATION Le présent protocole a été établi par la Commission des jeux de hasard et approuvé en sa séance du 1 er octobre Les constructeurs doivent apporter les modifications nécessaires à leur système online avant le 1 er juillet La certification obtenue, au plus tard le 1 er janvier 2015 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. -23-

24 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 "III_F7" (Point 13) : /f7/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f7) = III_V11 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 Les jeux de hasard placés dans des établissements de jeux de hasard durant la période concernée Les jeux de hasard retirés des établissements de jeux de hasard durant la période concernée Les jeux de hasard 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 jeux de hasard retirés des établissements de jeux de hasard durant la période concernée et vendus à un autre titulaire belge de licence E Les jeux de hasard 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 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 "C" où la dernière exploitation a eu lieu supplierlicenseid 1 int Numéro de licence "E" concerné (voir Point 13) taxnumber 1 string Numéro de la vignette de taxe repartitionkey/operator 1 int Clé de répartition : % des revenus du "C" repartitionkey/supplier 1 int Clé de répartition : % des revenus du "E" -24-

25 Définitions du fichier "III_F9" (Point 9) : /f9/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f9) = III_V11 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 details/nbofitems 1 int Nombre de machines concernées details/ detail 0 n detailinfotype Informations détaillées par 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 int numéro de licence "C" 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) (*) nbglassopen 1 long Nombre d'ouverture de glace (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 IMEI 1 string IMEI LOCI 1 string LOCI (* = 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 "III_F10" (Point 10) : /f10/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f10) = III_V11 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 details/nbofitems 1 int Nombre de machines concernées -25-

26 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 "C" 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) Définitions du fichier "III_F11" (Point 5) : /f11/ Field Cardinality Data type Description protocolversion 1 string Version du protocole (attribut de f11) = III_V11 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 details/nbofitems 1 int Nombre de machines concernées details/detail 0 n detailinfotype Informations détaillées par machine detailinfotype : /f11/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 N d'approbation de la métrologie licenseid 1 int Le numéro de licence "C" imeivalue 1 string valeur IMEI locivalue 1 string valeur LOCI firstnegativepollingdate 1 datetime TimeStamp du 1 er polling négatif positivepollingdate 1 datetime TimeStamp du polling positif -26-

27 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-27-

28 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. -28-

29 CD Description Rb(*1) 0x00 Null 6 0x01 Get game identification (identification jeu) 31 0x02 Get general counters (compteurs généraux) 70 0x03 Get Credit in counter (compteur Cash in ) 14 0x04 Get Credit out counter (compteur Cash out ) 14 0x05 Get Hand pay counter (compteur comptant ) 14 0x06 Get Total bet counter (compteur total In ) 14 0x07 Get Total win counter (compteur total Out ) 14 0x08 Get number of played games (nombre de parties 14 jouées) 0x09 Get number of interrupts (nombre d interruptions) 14 0x0A Get Door open counter (compteur ouverture de 14 porte ) 0x0B Get Change in counter (compteur change in ) 14 0x0C Get Change out counter (compteur change 14 out ) 0x0D Get game software version 16 0x0E Get checksum (signature software) 17 0x0F Download eid-logfile 10+Len 0x80 Get F9 Data 208 0x81 Get F10 Data 117 0x82 Get Extra Counters 116 (*1) = Nombre d'octets de retour du slave au master pour une commande donnée La machine doit obligatoirement répondre aux commandes 0x80, 0x81, 0x82 et 0x0F. Les autres commandes sont optionnelles. G. Description détaillée de la série des retours du slave Dans ce qui suit, le terme 'TxPrototype' signifie la description mnémonique de la commande envoyée du master au slave et le terme 'TxCmd' donne la série de commandes, le terme 'RxPrototype' signifie la réponse prototype du slave au master. "Exemple" donne un exemple typique de la série reçue et le terme 'Hex' montre le retour de la série exprimée en tant que valeurs hexadécimales. G.0. 0x00: Null TxPrototype: STX 00 EOT TxCmd: STX 0x30 0x30 EOT RxPrototype: STX 00 CS EOT Exemple: 0x02 0x30 0x30 0x36 0x30 0x04 G.1. 0x01: Visualisation de l identification du jeu Rend le numéro d approbation de la Métrologie sous un format B-xx-xxxxxx/xx suivi du séparateur ; et le numéro de série du jeu codé en 10 charactères completé par des 0 à gauche. Si le numéro de série ne peut pas être transmis pour des raisons techniques, le jeu retourne la chaîne nulle TxPrototype: STX 01 EOT TxCmd: STX 0x30 0x31 EOT RxPrototype: STX 01 B-xx-xxxxxx/xx;ssssssssss CS EOT Exemple: STX 01 B /01;V R0 1B EOT -29-

30 Hex: 0x02 0x30 0x31 0x42 0x2D 0x30 0x33 0x2D 0x30 0x30 0x37 0x30 0x30 0x34 0x2F 0x30 0x31 0x3B 0x56 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x52 0x30 0x31 0x42 0x04 G.2. 0x02: Visualisation des compteurs généraux Les compteurs sont des nombres hexadécimaux de 32 bits codés en 8 octets comme décrit au paragraphe D.2. Les compteurs sont donnés dans l ordre suivant : Credit in, Credit out, Hand pay, Total bets, Total wins, Number of played games, Number of game interrupts, Number of door open events. Les cinq premiers compteurs, qui donnent les montants sont exprimés en Euro cent. TxPrototype: STX 02 EOT TxCmd: STX 0x30 0x32 EOT RxPrototype: STX 02 credit in credit out handpay total bets total wins games interrupts door CS EOT Exemple: STX F A D EOT Hex: 0x02 0x30 0x32 0x30 0x30 0x30 0x30 0x30 0x30 0x32 0x46 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x41 0x30 0x30 0x30 0x30 0x31 0x32 0x33 0x34 0x30 0x30 0x30 0x30 0x35 0x36 0x37 0x38 0x31 0x32 0x33 0x34 0x33 0x32 0x31 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x32 0x30 0x30 0x30 0x30 0x39 0x38 0x37 0x36 0x39 0x38 0x37 0x36 0x35 0x34 0x33 0x32 0x30 0x44 0x04 G.3. 0x03: Visualisation du compteur Credit in Le compteur Credit in est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant total introduit dans la machine via le monnayeur, le système cashless ou autre et exprimé en Euro cent. TxPrototype: STX 03 EOT TxCmd: STX 0x30 0x33 0x36 0x33 EOT RxPrototype: STX 03 credit in CS EOT Exemple: STX F FB EOT Hex: 0x02 0x30 0x33 0x30 0x30 0x30 0x30 0x30 0x30 0x32 0x46 0x46 0x42 0x04 G.4. 0x04: Visualisation du compteur Credit out Le compteur Credit out est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant total payé par le jeu via le hopper, le handpay ou autre système et exprimé en Euro cent. TxPrototype: STX 04 EOT TxCmd: STX 0x30 0x34 0x36 0x34 EOT RxPrototype: STX 04 credit out CS EOT Exemple: STX A F6 EOT Hex: 0x02 0x30 0x34 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x41 0x46 0x36 0x04 G.5. 0x05: Visualisation du compteur Hand pay Le compteur Hand pay est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant payé manuellement et exprimé en Euro cent. Parfois, ce compteur est également appelé Drop ou Keyout TxPrototype: STX 05 EOT TxCmd: STX 0x30 0x35 EOT RxPrototype: STX 05 handpay CS EOT Exemple: STX E6 EOT Hex: 0x02 0x30 0x35 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x45 0x36 0x04-30-

31 G.6. 0x06: Visualisation du compteur Total bet Le compteur Total bet est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant total des mises sur le jeu et exprimé en Euro cent. TxPrototype: STX 06 EOT TxCmd: STX 0x30 0x36 EOT RxPrototype: STX 06 total bet CS EOT Exemple: STX E7 EOT Hex: 0x02 0x30 0x36 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 G.7. 0x07: Visualisation du compteur Total win Le compteur Total win est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant total de l argent gagné sur le jeu et exprimé en Euro cent. TxPrototype: STX 07 EOT TxCmd: STX 0x30 0x37 EOT RxPrototype: STX 07 total win CS EOT Exemple: STX E8 EOT Hex: 0x02 0x30 0x37 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x45 0x38 0x04 G.8. 0x08: Visualisation du nombre de parties jouées Le compteur Number of played games est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur est incrémenté au début de chaque nouvelle partie. TxPrototype: STX 08 EOT TxCmd: STX 0x30 0x38 EOT RxPrototype: STX 08 games CS EOT Exemple: STX E9 EOT Hex: 0x02 0x30 0x38 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x45 0x39 0x04 G.9. 0x09: Visualisation du nombre d interruptions Le compteur Number of interrupts est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur est incrémenté à chaque interruption de jeu. TxPrototype: STX 09 EOT TxCmd: STX 0x30 0x39 EOT RxPrototype: STX 09 interrupts CS EOT Exemple: STX EA EOT Hex: 0x02 0x30 0x39 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x45 0x41 0x04 G.10. 0x0A: Visualisation du compteur Door open Le compteur Door open est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2.counter. Ce compteur est incrémenté chaque fois que la porte principale est ouverte. TxPrototype: STX 0A EOT TxCmd: STX 0x30 0x41 EOT RxPrototype: STX 0A Door CS EOT Exemple: STX 0A F2 EOT Hex: 0x02 0x30 0x41 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x46 0x42 0x04-31-

32 G.11. 0x0B: Visualisation du compteur Change in Le compteur Change in est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant en Euro cent introduits dans le changeur de monnaie. TxPrototype: STX 0B EOT TxCmd: STX 0x30 0x42 EOT RxPrototype: STX 0B changein CS EOT Exemple: STX 0B F7 EOT Hex: 0x02 0x30 0x42 0x30 0x30 0x30 0x30 0x30 0x30 0x33 0x32 0x46 0x37 0x04 G.12. 0x0C: Visualisation du compteur Change out Le compteur Change out est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant en Euro cent payé suite à l introduction d un billet de banque introduit dans le changeur de monnaie. TxPrototype: STX 0C EOT TxCmd: STX 0x30 0x43 EOT RxPrototype: STX 0C changeout CS EOT Exemple: STX 0C F8 EOT Hex: 0x02 0x30 0x43 0x30 0x30 0x30 0x30 0x30 0x30 0x33 0x32 0x46 0x38 0x04 G.13. 0x0D: Visualisation du software du jeu La version du software est une série de 10 caractères, complété de 0 essentiels du côté gauche. L exemple ci-dessous représente la version V TxPrototype: STX 0D EOT TxCmd: STX 0x30 0x44 EOT RxPrototype: STX 0D vvvvvvvvvv CS EOT Exemple: Hex: STX 0D 00V EOT 0x02 0x30 0x44 0x30 0x30 0x56 0x31 0x2E 0x30 0x30 0x2E 0x30 0x31 0x37 0x38 0x04 G.14. 0x0E: Visualisation du checksum du software Cette commande permet de visualiser la clef du software et le checksum en utilisant cette clef. La clef est composée de 3 bytes et envoie un caractère de 6 ASCII en utilisant le tableau de conversion décrit dans le chapitre D.2. Le checksum est un nombre de 2 bytes converti comme décrit dans le paragraphe D.2. Les deux séries sont séparées par un point-virgule (";"). Les 3 bytes de la clé sont calculés à partir du numéro de la semaine et de l année en cours. Le premier chiffre du numéro de la semaine constitue le premier byte ; le deuxième chiffre du numéro de la semaine constitue le deuxième byte ; les deux derniers chiffres du millésime de l année en cours constituent le troisième byte. Le numéro de la semaine est calculé sur base de la norme ISO 8601 qui prévoit que la semaine no 1 est la semaine qui contient le premier jeudi de l année. Exemple : pour la date 20/02/2006 ; soit la semaine 08 de 2006, clé1 = 0 ; clé 2 = 8 ; clé3 = 6 TxPrototype: STX 0E EOT TxCmd: STX 0x30 0x45 EOT RxPrototype: STX 0E key;checksum CS EOT Exemple: STX 0E 2AB792;F378 EF EOT Hex : 0x02 0x30 0x45 0x32 0x41 0x42 0x37 0x39 0x32 0x3B 0x46 0x33 0x37 0x38 0x45 0x46 0x04-32-

33 G.15. 0x0F: Download eid-logfile Pour la carte exploitant, la date de naissance doit être 01/01/1900 ; Flag : 0 = Carte (joueur) acceptée ; 1 = Carte exploitant ; 2 = Carte refusée ; Fichier LogFile limité aux 1000 derniers records; Commande pour le download : 0x0F TxPrototype: STX "0F" EOT TxCmd: STX 0x30 0x46 EOT RxPrototype: STX "0F" "FileLength" "LogFile" "CS" EOT Remarques: FileLength est le nombre de bytes du fichier LogFile exprimé en 16 bits, codé selon D.2 en 4 bytes (exemple 1000 records de 31 bytes : 0x37 0x39 0x31 0x38) Chaque identité est enregistrée dans le LogFile en suivant la norme : 04/11/2009;15:47;28/03/1983;0 CR LF (soit 31 bytes) A la demande de la CJH une transmission "manuelle" du fichier doit être possible. G.16. 0x80: Get F9 Data Cette commande permet de transmettre toutes les données nécessaires à la création du fichier F9. Remarque : cette commande doit provoquer la remise à zéro des compteurs "Total bet (journalier)", "Total Win (journalier)" et "Nombre de jeux (journalier)" (si les compteurs journaliers ne sont pas transmis, leur remise à zéro n'est pas obligatoire). Les compteurs supplémentaires "Total bet (global)", "Total Win (global)" et "Nombre de jeux (global)" ne peuvent pas être remis à zéro. TxPrototype: STX 80 EOT TxCmd: STX 0x38 0x30 EOT RxPrototype: STX 80 ";Identificatienummer; (codé selon D.1-10 chr complétés par des 0 à gauche) NoSuite; (codé selon D.1 10 chr complétés par des 0 à gauche) TotalBetJournalier; (codé selon D.2 hexadécimal 32 bits) TotalBetGlobal; (codé selon D.2 hexadécimal 32 bits) TotalWinJournalier; (codé selon D.2 hexadécimal 32 bits) TotalWinGlobal ; (codé selon D.2 hexadécimal 32 bits) NbrPartieJournalier; (codé selon D.2 hexadécimal 32 bits) NbrPartieGlobal; (codé selon D.2 hexadécimal 32 bits) CleRepartition; (codé selon D.1 format "000/000") ("C" / "E") NoLicenceC; (codé selon D.1 format "C000000") NoApprobation; (codé selon D.1 format "B /00") TotalBetOuverture; (codé selon D.2 hexadécimal 32 bits) TotalWinOuverture; (codé selon D.2 hexadécimal 32 bits) TotalBetFermeture; (codé selon D.2 hexadécimal 32 bits) TotalWinFermeture; (codé selon D.2 hexadécimal 32 bits) DateOuverture; (codé selon D.1 format "aaaa/mm/jj") HeureOuverture; (codé selon D.1 format "hh:mm:ss") DateFermeture; (codé selon D.1 format "aaaa/mm/jj") HeureFermeture ; (codé selon D.1 format "hh:mm:ss") NbrDoorOpen ; (codé selon D.2 hexadécimal 32 bits) NbrGlassOpen;" (codé selon D.2 hexadécimal 32 bits) CS EOT -33-