Protocole informatique classe III

Transcription

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 1er novembre 2015
Protocole informatique jeux de hasard (classe III)
Version III_V11
Commission des Jeux de hasard
1er novembre 2015
Table des matières
Page
1
CONTENU DU PRÉSENT DOCUMENT ................................................................................................ 4
2
DÉFINITIONS ET ABRÉVIATIONS ....................................................................................................... 5
3
CONDITIONS TECHNIQUES RELATIVES AU CÂBLAGE ET AUX COMPOSANTS PASSIFS DU
LAN CHEZ LA PERSONNE OBLIGÉE.................................................................................................. 6
4
CONDITIONS TECHNIQUES RELATIVES AUX COMPOSANTS ACTIFS DU LAN CHEZ LA
PERSONNE OBLIGÉE. ......................................................................................................................... 7
5
CONDITIONS TECHNIQUES RELATIVES AUX CLIENTS ET AUX SERVEURS CHEZ LA
PERSONNE OBLIGÉE (F11) ................................................................................................................. 8
6
CONDITIONS TECHNIQUES RELATIVES AU LOCAL DESTINÉ AU "DATA-RACK" CHEZ LA
PERSONNE OBLIGÉE ........................................................................................................................ 10
7
CONDITIONS TECHNIQUES RELATIVES À LA LIAISON DE DONNÉES DE LA PERSONNE
OBLIGÉE AVEC LA COMMISSION DES JEUX DE HASARD ........................................................... 11
8
CONDITIONS RELATIVES À LA LIAISON ENTRE LE TITULAIRE D'UNE LICENCE DE CLASSE C
ET LA PERSONNE OBLIGÉE ............................................................................................................. 12
9
CONDITIONS RELATIVES À L’INFORMATION COMPTABLE ET FINANCIÈRE (F9)...................... 13
10
CONDITIONS RELATIVES AU CONTRÔLE TECHNIQUE CHEZ LA PERSONNE OBLIGÉE (F10) . 15
11
CONDITIONS RELATIVES À LA DOCUMENTATION CONCERNANT LE SYSTÈME
INFORMATIQUE CHEZ LA PERSONNE OBLIGÉE ........................................................................... 16
12
UTILISATION DES NOUVELLES TECHNOLOGIES DE L'INFORMATION ....................................... 17
13
CONDITIONS GÉNÉRALES, NI SPÉCIFIQUE, NI LIÉES AUX SUJETS PRÉCÉDENTS (F7) .......... 18
14
NORMES CONCERNANT LA NOMENCLATURE DES FICHIERS À ENVOYER PAR LA PERSONNE
OBLIGÉE ............................................................................................................................................. 20
15
CERTIFICATION .................................................................................................................................. 21
16
APPROBATION ................................................................................................................................... 23
17
ANNEXE 1 : DÉFINITIONS XML ......................................................................................................... 24
18
ANNEXE 2 : PROTOCOLE DE COMMUNICATION STANDARD ....................................................... 24
19
ANNEXE 3 : TABLE ASCII .................................................................................................................. 35
20
ANNEXE 4 : ARRÊTÉ ROYAL DU 23 MAI 2003 ................................................................................. 38
-3-
Version III_V11
1
1er novembre 2015
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-
Version III_V11
2
1er novembre 2015
DÉFINITIONS ET ABRÉVIATIONS
Abréviation
LAN
Client
Personne obligée
On-line
UTP
DHCP
WINS
DNS
FTP
DVD
EPROM
Xls-file
XML
RJ45
Propagation Delay
TCP/IP
IPV4
IPV6
SWITCH
SSL
SSH
HTTP
DMZ
Connection IP
ISP
IP-adres
Définition
Local Area Network : le réseau local
Toute unité électronique, donc tant les pc
administratifs que les jeux automatiques
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
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)
Unshielded Twisted Pair
Dynamic Host Configuration Protocol
Windows Internet Naming Service
Domain Name System
File Transfer Protocol
Digital Versatile Disk
Erasable Programmable Read Only Memory
Format de fichier de Microsoft Excel.
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
Registered Jack 45
Le temps nécessaire à un signal pour se rendre du
point A au point B par un canal de transmission
donné
Transmission Control Protocol / Internet Protocol
Adresse Internet du Protocole en 4 positions
Adresse Internet du Protocole en 6 positions
Un appareil électronique qui organise le flux des
messages entre différents segments du LAN
Secure sockets layer
Secure shell
Hypertext transfert protocol.
Demilitarized Zone
connection basée sur le protocol Internet
Internet Service Provider
Internet Protocol adres.
-5-
Version III_V11
3
1er novembre 2015
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 Commission des Jeux de hasard.
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-
Version III_V11
4
1er novembre 2015
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-
Version III_V11
5
1er novembre 2015
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-
Version III_V11
1er novembre 2015
-/ LOCI
-/ TimeStamp 1er 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-
Version III_V11
6
1er novembre 2015
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-
Version III_V11
7
1er novembre 2015
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 Commission des Jeux de hasard.
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-
Version III_V11
8
1er novembre 2015
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-
Version III_V11
9
1er novembre 2015
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.
-/ No d'identification du jeu (no de série) (*)
-/ No d'approbation Métrologie (*)
-/ 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
"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-
Version III_V11
1er novembre 2015
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-
Version III_V11
10
1er novembre 2015
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.
-/ No d'identification du jeu (No de série de la machine) (*)
-/ 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 (*)
"III_F10"
-15-
Version III_V11
11
1er novembre 2015
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-
Version III_V11
12
UTILISATION
DES
L'INFORMATION
1er novembre 2015
NOUVELLES
Pas d'exigences au stade actuel.
-17-
TECHNOLOGIES
DE
Version III_V11
13
1er novembre 2015
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 1er mars de chaque année
-/ 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)
"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 000000. 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) :
-/ 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)
"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-
Version III_V11
1er novembre 2015
-/ 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-
Version III_V11
14
1er novembre 2015
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_20130517_221743.xml
-20-
Version III_V11
15
1er novembre 2015
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 Commission des Jeux de hasard (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 Commission des Jeux de hasard 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 e-mail à [email protected] 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-
Version III_V11
1er novembre 2015
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-
Version III_V11
16
1er novembre 2015
APPROBATION
Le présent protocole a été établi par la Commission des jeux de hasard et approuvé en sa
séance du 1er octobre 2014.
Les constructeurs doivent apporter les modifications nécessaires à leur système online
avant le 1er juillet 2015. La certification obtenue, au plus tard le 1er 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-
Version III_V11
17
1er novembre 2015
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 :
www.gamingcommission.be ; Section <La Loi> <Protocoles> <Informatique>.
Définitions du fichier "III_F7" (Point 13) : /f7/
Field
protocolVersion
Cardinality
1
Data type
string
Description
Version du protocole (attribut de f7) = III_V11
generalInfo/licenseId
1
int
Le numéro de la licence E Placeur
generalInfo/fileDate
1
protocolDate
Date du fichier (après 01-01-2000)
generalInfo/licenseType
1
licenseTypeType
Type de licence : E
generalInfo/email
1
emailType
Email du responsable On-Line
int
Le numéro de licence E fabricant
detailType
Les appareils en magasin
detailType
Les jeux de hasard placés dans des établissements de
jeux de hasard durant la période concernée
detailType
Les jeux de hasard retirés des établissements de jeux
de hasard durant la période concernée
detailType
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
detailType
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
detailType
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
0→1
generalInfo/manufacturerId
stock
1
1
install
1
uninstall
1
installAfterBuy
1
uninstallAndSold
1
uninstallWithKit
detailType : /f7/.../
Field
nbOfItems
Cardinality
1
0→n
item
Data type
int
Description
Nombre de machines concernées
itemType
Informations détaillées par machine
Data type
string
Description
Le numéro d'identification unique du jeu (no de série)
itemType: /f7/.../item/
Field
gameid
Cardinality
1
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-
Version III_V11
1er novembre 2015
Field
Cardinality
Data type
Description
protocolVersion
1
string
1
int
1
protocolDate
1
licenseTypeType
Type de licence : E
generalInfo/email
1
emailType
0→1
int
Le numéro de la licence E Fabricant
1
int
detailInfoType
details/nbOfItems
0→n
details/ detail
detailInfoType : /f9/details/detail/
Field
gameId
Cardinality
1
Data type
string
Description
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)
Field
Cardinality
Data type
Description
protocolVersion
1
string
1
int
1
protocolDate
1
licenseTypeType
Type de licence : E
generalInfo/email
1
emailType
-25-
Version III_V11
0→1
int
1
int
detailInfoType
details/nbOfItems
details/detail
1er novembre 2015
0→n
Field
gameId
Cardinality
1
Data type
string
Description
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)
Field
Cardinality
Data type
Description
protocolVersion
1
string
1
int
1
protocolDate
1
licenseTypeType
Type de licence : E
generalInfo/email
1
emailType
0→1
int
1
int
detailInfoType
details/nbOfItems
details/detail
0→n
Field
gameId
Cardinality
1
Data type
string
Description
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 1er polling négatif
positivePollingDate
1
datetime
TimeStamp du polling positif
-26-
Version III_V11
18
1er novembre 2015
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 45 836 472 = 0x02BB68B8:
Envoyer les 8 bytes 0x30 0x32 0x42 0x42 0x36 0x38 0x42 0x38
-27-
Version III_V11
1er novembre 2015
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-
Version III_V11
1er novembre 2015
CD
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
Description
Rb(*1)
Null
6
Get game identification (identification jeu)
31
Get general counters (compteurs généraux)
70
Get ‘Credit in’ counter (compteur “Cash in”)
14
Get ‘Credit out’ counter (compteur “Cash out”)
14
Get ‘Hand pay’ counter (compteur “comptant”)
14
Get ‘Total bet’ counter (compteur “total In”)
14
Get ‘Total win’ counter (compteur “total Out”)
14
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
10+Len
0x0F Download eID-logfile
208
0x80 Get F9 Data
117
0x81 Get F10 Data
116
0x82 Get Extra Counters
(*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 “0000000000”
TxCmd:
STX 0x30 0x31 EOT
RxPrototype: STX “01” “B-xx-xxxxxx/xx;ssssssssss” “CS” EOT
Exemple:
STX “01” “B-03-007004/01;V1234567R0” “1B” EOT
-29-
Version III_V11
Hex:
1er novembre 2015
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.
TxCmd:
STX 0x30 0x32 EOT
RxPrototype: STX “02” “credit in” “credit out” “handpay” “total bets” “total wins”
“games” “interrupts“ “door” “CS” EOT
Exemple:
STX “02”
“0000002F” “0000001A” “00001234” “00005678”
“12343210” “00000012” “00009876” “98765432” “0D” 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.
TxCmd:
STX 0x30 0x33 0x36 0x33 EOT
RxPrototype: STX “03” “credit in” “CS” EOT
Exemple:
STX “03” “0000002F” “FB” EOT
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.
TxCmd:
STX 0x30 0x34 0x36 0x34 EOT
RxPrototype: STX “04” “credit out” “CS” EOT
Exemple:
STX “04” “0000001A” “F6” EOT
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’
TxCmd:
STX 0x30 0x35 EOT
RxPrototype: STX “05” “handpay” “CS” EOT
Exemple:
STX “05” “00000010” “E6” EOT
-30-
Version III_V11
1er novembre 2015
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.
TxCmd:
STX 0x30 0x36 EOT
RxPrototype: STX “06” “total bet” “CS” EOT
Exemple:
STX “06” “00000010” “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.
TxCmd:
STX 0x30 0x37 EOT
RxPrototype: STX “07” “total win” “CS” EOT
Exemple:
STX “07” “00000010” “E8” EOT
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.
TxCmd:
STX 0x30 0x38 EOT
RxPrototype: STX “08” “games” “CS” EOT
Exemple:
STX “08” “00000010” “E9” EOT
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.
TxCmd:
STX 0x30 0x39 EOT
RxPrototype: STX “09” “interrupts” “CS” EOT
Exemple:
STX “09” “00000010” “EA” EOT
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” “00000010” “F2” EOT
-31-
Version III_V11
1er novembre 2015
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” “00000032” “F7” EOT
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” “00000032” “F8” EOT
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 “V1.00.01”.
TxPrototype: STX “0D” EOT
TxCmd:
STX 0x30 0x44 EOT
RxPrototype: STX “0D” “vvvvvvvvvv” “CS” EOT
Exemple:
STX “0D” “00V1.00.01” “78” EOT
Hex: 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-
Version III_V11
1er novembre 2015
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.
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;
TotalWinJournalier;
TotalWinGlobal ;
NbrPartieJournalier;
NbrPartieGlobal;
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-000000/00")
TotalBetOuverture;
TotalWinOuverture;
TotalBetFermeture;
TotalWinFermeture;
DateOuverture;
(codé selon D.1 – format "aaaa/mm/jj")
HeureOuverture;
(codé selon D.1 – format "hh:mm:ss")
DateFermeture;
HeureFermeture ;
(codé selon D.1 – format "hh:mm:ss")
NbrDoorOpen ;
NbrGlassOpen;"
“CS” EOT
-33-
Version III_V11
1er novembre 2015
G.17. 0x81: Get F10 Data.
Cette commande permet de transmettre toutes les données nécessaires à la création du
fichier F10.
TxCmd:
STX 0x38 0x31 EOT
“;NoIdentification;
(codé selon D.1 - 10 chr complétés par des ‘0’ à gauche)
NoSuite;
NoApprobation;
DateApprobation;
DateDernVerif;
DateSignatureSoft;
HeureSignatureSoft; (codé selon D.1 – format "hh:mm:ss")
ResultatSignatureSoft; (codé selon D.2 – format “key ; checksum” Vb.
2AB792;F378)
VersionSoftware;
NoLicenceC ;”
(codé selon D.1 – format "C000000")
“CS” EOT
G.18. 0x82: Get Extra Counters.
Cette commande permet de transmettre les compteurs supplémentaires demandés par le
point AR 2003/07/11 règles III Article 5 du protocole de contrôle. Les compteurs totalisant
les 20.000 parties en cours portent la dénomination "Counter " ; les compteurs reprenant le
résultat des 20.000 parties antérieures portent la dénomination "Memory....".
TxCmd:
STX 0x38 0x32 EOT
“;NoIdentification;
NoSuite;
NoApprobation;
CounterTotalBet;
CounterTotalWin;
CounterPlayedGames; (codé selon D.2 – hexadécimal 32 bits)
CounterTotalTime;
MemoryTotalBet;
MemoryTotalWin;
MemoryPlayedGames; (codé selon D.2 – hexadécimal 32 bits)
MemoryTotalTime;” (codé selon D.2 – hexadécimal 32 bits)
“CS” EOT
-34-
Version III_V11
19
1er novembre 2015
ANNEXE 3 : TABLE ASCII
Decimal
Octal
Hex
Binary
Value
Description
000
000
000
00000000
NUL
(Null char.)
001
001
001
00000001
SOH
(Start of Header)
002
002
002
00000010
STX
(Start of Text)
003
003
003
00000011
ETX
(End of Text)
004
004
004
00000100
EOT
(End of Transmission)
005
005
005
00000101
ENQ
(Enquiry)
006
006
006
00000110
ACK
(Acknowledgment)
007
007
007
00000111
BEL
(Bell)
008
010
008
00001000
BS
(Backspace)
009
011
009
00001001
HT
(Horizontal Tab)
010
012
00A
00001010
LF
(Line Feed)
011
013
00B
00001011
VT
(Vertical Tab)
012
014
00C
00001100
FF
(Form Feed)
013
015
00D
00001101
CR
(Carriage Return)
014
016
00E
00001110
SO
(Shift Out)
015
017
00F
00001111
SI
(Shift In)
016
020
010
00010000
DLE
(Data Link Escape)
017
021
011
00010001
DC1
(XON = Device Control 1)
018
022
012
00010010
DC2
(Device Control 2)
019
023
013
00010011
DC3
(XOFF = Device Control 3)
020
024
014
00010100
DC4
(Device Control 4)
021
025
015
00010101
NAK
(Negative Acknowledgement)
022
026
016
00010110
SYN
(Synchronous Idle)
023
027
017
00010111
ETB
(End of Trans.
024
030
018
00011000
CAN
(Cancel)
025
031
019
00011001
EM
(End of Medium)
026
032
01A
00011010
SUB
(Substitute)
027
033
01B
00011011
ESC
(Escape)
028
034
01C
00011100
FS
(File Separator)
029
035
01D
00011101
GS
(Group Separator)
030
036
01E
00011110
RS
(Record Separator)
031
037
01F
00011111
US
(Unit Separator)
032
040
020
00100000
SP
(Space)
033
041
021
00100001
!
(exclamation mark)
034
042
022
00100010
"
(double quote)
035
043
023
00100011
#
(number sign)
036
044
024
00100100
$
(dollar sign)
037
045
025
00100101
%
(percent)
038
046
026
00100110
&
(ampersand)
039
047
027
00100111
-35-
(single quote)
Version III_V11
1er novembre 2015
040
050
028
00101000
(
(left/opening parenthesis)
041
051
029
00101001
)
(right/closing parenthesis)
042
052
02A
00101010
*
(asterisk)
043
053
02B
00101011
+
(plus)
044
054
02C
00101100
,
(comma)
045
055
02D
00101101
-
(minus or dash)
046
056
02E
00101110
.
(dot)
047
057
02F
00101111
/
(forward slash)
048
060
030
00110000
0
(character 0)
049
061
031
00110001
1
(character 1)
050
062
032
00110010
2
(character 2)
051
063
033
00110011
3
(character 3)
052
064
034
00110100
4
(character 4)
053
065
035
00110101
5
(character 5)
054
066
036
00110110
6
(character 6)
055
067
037
00110111
7
(character 7)
056
070
038
00111000
8
(character 8)
057
071
039
00111001
9
(character 9)
058
072
03A
00111010
:
(colon)
059
073
03B
00111011
;
(semi-colon)
060
074
03C
00111100
<
(less than)
061
075
03D
00111101
=
(equal sign)
062
076
03E
00111110
>
(greater than)
063
077
03F
00111111
?
(question mark)
064
100
040
01000000
@
(AT symbol)
065
101
041
01000001
A
(character A)
066
102
042
01000010
B
(character B)
067
103
043
01000011
C
(character C)
068
104
044
01000100
D
(character D)
069
105
045
01000101
E
(character E)
070
106
046
01000110
F
(character F)
071
107
047
01000111
G
(character G)
072
110
048
01001000
H
(character H)
073
111
049
01001001
I
(character I)
074
112
04A
01001010
J
(character J)
075
113
04B
01001011
K
(character K)
076
114
04C
01001100
L
(character L)
077
115
04D
01001101
M
(character M)
078
116
04E
01001110
N
(character N)
079
117
04F
01001111
O
(character O)
080
120
050
01010000
P
(character P)
081
121
051
01010001
Q
(character Q)
082
122
052
01010010
R
(character R)
083
123
053
01010011
S
(character S)
084
124
054
01010100
T
(character T)
-36-
Version III_V11
1er novembre 2015
085
125
055
01010101
U
(character U)
086
126
056
01010110
V
(character V)
087
127
057
01010111
W
(character W)
088
130
058
01011000
X
(character X)
089
131
059
01011001
Y
(character Y)
090
132
05A
01011010
Z
(character Z)
091
133
05B
01011011
[
(left/opening bracket)
092
134
05C
01011100
\
(back slash)
093
135
05D
01011101
]
(right/closing bracket)
094
136
05E
01011110
^
(caret/cirumflex)
095
137
05F
01011111
_
(underscore)
096
140
060
01100000
`
097
141
061
01100001
a
(character a)
098
142
062
01100010
b
(character b)
099
143
063
01100011
c
(character c)
100
144
064
01100100
d
(character d)
101
145
065
01100101
e
(character e)
102
146
066
01100110
f
(character f)
103
147
067
01100111
g
(character g)
104
150
068
01101000
h
(character h)
105
151
069
01101001
i
(character i)
106
152
06A
01101010
j
(character j)
107
153
06B
01101011
k
(character k)
108
154
06C
01101100
l
(character l)
109
155
06D
01101101
m
(character m)
110
156
06E
01101110
n
(character n)
111
157
06F
01101111
o
(character o)
112
160
070
01110000
p
(character p)
113
161
071
01110001
q
(character q)
114
162
072
01110010
r
(character r)
115
163
073
01110011
s
(character s)
116
164
074
01110100
t
(character t)
117
165
075
01110101
u
(character u)
118
166
076
01110110
v
(character v)
119
167
077
01110111
w
(character w)
120
170
078
01111000
x
(character x)
121
171
079
01111001
y
(character y)
122
172
07A
01111010
z
(character z)
123
173
07B
01111011
{
(left/opening brace)
124
174
07C
01111100
|
(vertical bar)
125
175
07D
01111101
}
(right/closing brace)
126
176
07E
01111110
~
(tilde)
127
177
07F
01111111
DEL
(delete)
-37-
Version III_V11
20
1er novembre 2015
ANNEXE 4 : ARRÊTÉ ROYAL DU 23 MAI 2003
23 MAI 2003. - Arrêté royal 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é - MB du 04/06/2003
ALBERT II, Roi des Belges,
A tous, présents et à venir, Salut.
Vu la loi du 7 mai 1999 sur les jeux de hasard, les établissements de jeux de hasard et la
protection des joueurs, en particulier l'article 43, 5;
Vu l'avis de la Commission des jeux de hasard, donné le 6 novembre 2002;
Vu l'avis de l'Inspecteur des Finances, donné le 7 janvier 2003;
Vu l'accord de Notre Ministre du Budget, donné le 11 février 2003;
Vu la demande de traitement urgent, motivée par la circonstance que les prochaines
élections fédérales ont lieu le 18 mai 2003 et compte tenu à cet égard de la dissolution
préalable des chambres fédérales et d'une période de traitement des affaires courantes.
Vu l'avis 35.216/2 du Conseil d'Etat, donné le 7 avril 2003, en application de l'article
84, alinéa 1er, 2°, des lois coordonnées sur le Conseil d'Etat;
Vu la Directive 98/34/CE du Parlement européen et du Conseil du 22 juin 1998
prévoyant une procédure d'information dans le domaine des normes et réglementations
techniques, modifiée par la Directive 98/48/CE du 20 juillet 1998;
Sur la proposition de Notre Ministre de l'Intérieur, de Notre Ministre de la Justice, de
Notre Ministre des Finances, de Notre Ministre des Entreprises et Participations
publiques, de Notre Ministre de l'Economie et de Notre Ministre de la Santé publique,
Nous avons arrêté et arrêtons :
Article 1er. Dans le présent arrêté royal, il convient d'entendre par :
LAN : 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.
Art. 2. Toute personne obligée procède une fois par mois à une liaison de données avec
le LAN de la Commission des jeux de hasard.
Art. 3. Tous les coûts liés à l'achat du matériel, à l'obtention des licences de logiciels et
aux loyers dus sont à charge de la personne obligée.
Art. 4. Un serveur central qui relie la personne obligée au titulaire d'une licence de
classe C est prévu comme configuration du matériel.
Il est prévu un logiciel de base de données de nature à garantir suffisamment la qualité,
l'intégrité, la robustesse et le multiple access.
Art. 5. Lorsque le serveur central de la personne obligée est en panne pendant plus de
24 heures, tous les jeux du titulaire d'une licence de classe C sont arrêtés.
-38-
Version III_V11
1er novembre 2015
Une procédure de back-up et de recovery est présentée à la Commission des jeux de
hasard ainsi que la preuve d'exécution de tests tous les six mois.
Art. 6. Le système informatique est protégé contre les interférences électromagnétiques
et électrostatiques ainsi que contre les ondes radioélectriques.
Art. 7.
§ 1er. La Commission des jeux de hasard rédige un protocole contenant les éléments
suivants :
1. Des conditions techniques relatives au câblage et aux composants passifs du LAN
chez la personne obligée;
2. Des conditions techniques relatives aux composants actifs du LAN chez la personne
obligée;
3. Des conditions techniques relatives aux clients et aux serveurs chez la personne
obligée;
4. Des conditions techniques relatives au local destiné au data-rack chez la personne
obligée;
5. Des conditions techniques relatives à la liaison de données de la personne obligée
avec la Commission des jeux de hasard;
6. Des conditions relatives à la liaison entre le titulaire d'une licence de classe C et la
personne obligée;
7. Des conditions relatives à l'information comptable et financière;
8. Des conditions relatives au contrôle technique chez la personne obligée;
9. Des conditions relatives à la documentation concernant le système informatique chez
la personne obligée;
10. Des normes concernant la nomenclature des fichiers à envoyer.
§ 2. Ce protocole est communiqué à toutes les personnes obligées au plus tard une
semaine après son approbation par la Commission des jeux de hasard.
Toute modification du protocole est communiquée à toutes les personnes obligées au
plus tard une semaine après son approbation par la Commission des jeux de hasard.
Art. 8. Le présent arrêté entre en vigueur concomitamment avec article 43, 5, de la loi
du 7 mai 1999 sur ces jeux de hasard, les établissements de jeux de hasard et la
protection des joueurs soit trois mois après sa publication au Moniteur belge, à
l'exception de l'article 7 qui entre en vigueur le jour de sa publication au Moniteur
belge.
Art. 9. Notre Ministre qui a l'Intérieur dans ses attributions, Notre Ministre qui a la
Justice dans ses attributions, Notre Ministre qui a les Finances dans ses attributions,
Notre Ministre qui a des Entreprises et Participations publiques dans ses attributions, et
Notre Ministre qui a l'Economie dans ses attributions, et notre Ministre de la Santé
publique sont chargés, chacun en ce qui le concerne, de l'exécution du présent arrêté.
Donné à Bruxelles, le 23 mai 2003.
-39-

Protocole informatique classe III

Transcription

Documents pareils

Le jeu - Ministère de l`éducation nationale

Sujet : La nature fait-elle bien les choses ?

III. Conclusion

l`homme dé - Joueurs Info Service

Gagnants du jeu du juste poids panier de Noël - cie

Jeux d`argent I) Définition - Préparation Concours Infirmier

Télécharger - Naturalselling

Le Comité régional de parents du regroupement Ouest, est heureux

Faux papiers collés – Hans Arp