Protocole II V12.1

Transcription

Protocole II V12.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 II au moyen d’un système informatique approprié.
- Texte coordonné Version :
II_V12.1
du 1er décembre 2016
Protocole informatique jeux de hasard (classe II)
Version II_V12.1
Commission des Jeux de hasard
1er décembre 2016
Table des matières
Page
1
CONTENU DU PRÉSENT DOCUMENT ................................................................................................ 4
2
DÉFINITIONS ET ABRÉVIATIONS ....................................................................................................... 5
3
CONDITIONS GÉNÉRALES .................................................................................................................. 6
4
CONDITIONS TECHNIQUES RELATIVES AU CÂBLAGE ET AUX COMPOSANTS PASSIFS DU
LAN ........................................................................................................................................................ 8
5
CONDITIONS TECHNIQUES RELATIVES AUX COMPOSANTS ACTIFS DU LAN ............................ 9
6
CONDITIONS TECHNIQUES RELATIVES AUX CLIENTS ET AUX SERVEURS .............................. 10
7
CONDITIONS TECHNIQUES RELATIVES AU LOCAL DESTINÉ AU "DATA-RACK" ...................... 12
8
CONDITIONS TECHNIQUES RELATIVES À LA LIAISON DE DONNÉES AVEC LA COMMISSION
DES JEUX DE HASARD...................................................................................................................... 13
9
CONDITIONS SUPPLÉMENTAIRES RELATIVES AU SYSTÈME DE VIDÉOSURVEILLANCE ........ 14
10
CONDITIONS RELATIVES À L’INFORMATION COMPTABLE ET FINANCIÈRE (F1 ET F2) ........... 15
11
CONDITIONS RELATIVES À L'ENREGISTREMENT (F5).................................................................. 16
12
CONDITIONS RELATIVES AU CONTRÔLE TECHNIQUE (F6) ......................................................... 17
13
CONDITIONS RELATIVES À LA DOCUMENTATION CONCERNANT LE SYSTÈME
INFORMATIQUE ET LE SYSTÈME DE VIDÉOSURVEILLANCE ....................................................... 19
14
UTILISATION DES NOUVELLES TECHNOLOGIES DE L'INFORMATION ....................................... 20
15
NORMES CONCERNANT LA NOMENCLATURE DES FICHIERS À ENVOYER .............................. 21
16
APPROBATION ................................................................................................................................... 22
17
ANNEXE 1 : DÉFINITIONS XML ......................................................................................................... 23
18
ANNEXE 2 : PROTOCOLE DE COMMUNICATION STANDARD ....................................................... 27
19
ANNEXE 3 : TABLE ASCII .................................................................................................................. 38
20
ANNEXE 4 : ARRÊTÉ ROYAL DU 23 MAI 2003 ................................................................................. 41
-3-
Version II_V12.1
1
1er décembre 2016
CONTENU DU PRÉSENT DOCUMENT
L’art. 38, 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 II doit se faire au moyen d’un système
informatique approprié.
Le présent document décrit les conditions techniques auxquelles le système précité doit
répondre.
Le présent protocole constitue l’exécution de l’art. 11 de l’arrêté royal du 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 II, au moyen d'un système informatique
approprié (M.B. 04/06/2003).
-4-
Version II_V12.1
2
1er décembre 2016
DÉFINITIONS ET ABRÉVIATIONS
Abréviation
LAN
Client
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
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 II_V12.1
3
1er décembre 2016
CONDITIONS GÉNÉRALES
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.
Tous les titulaires de licences "B" 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
évaluations techniques et loi sur les Jeux de Hasard de 1999 (y compris tous les
changements de cette loi). L’interface du jeu automatique doit également faire l’objet d’une
certification.
La fiabilité et la disponibilité de la connexion data avec les jeux automatiques dans les
établissements de classe II 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’accorder 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 B 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é.
-6-
Version II_V12.1
1er décembre 2016
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 :
Les systèmes cashless doivent satisfaire 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.
Le système alternatif doit, au moins, respecter les exigences suivantes :
-/ Les "Player cards" doivent comporter une identification électronique unique ;
-/ Les terminaux de paiement autorisés (y compris celui de la caisse) doivent
comporter une identification électronique unique ;
-/ L'application cashless doit :
-/ faire en sorte que les "chargements cashless" ne peuvent être effectués qu'à
partir d'un terminal de paiement autorisé et uniquement lorsque la carte du
joueur concerné a été identifiée ;
-/ enregistrer les données sur le serveur d'une manière sécurisée (cryptage) ;
-/ enregistrer, en plus du montant "cashless", un code de contrôle permettant de
sécuriser l'enregistrement (hash faisant intervenir l'ID de la carte ;
un timestamp ; le montant cashless ; un mot de passe connu uniquement par le
développeur Cashless ; ...) ;
-/ être certifiée par le certificateur du système "on-line".
-/ 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).
-/ Pour chaque carte, un fichier sécurisé reprenant l'ensemble des transactions (dépôts,
retraits, date, ) doit être conservé sur le serveur cashless."
D/ RAM-reset :
Afin de garantir la continuité de la valeur des compteurs, la réglementation suivante est
d’application en cas de RAM-reset:
Les informations concernant l’ouverture et la fermeture du compartiment CPU
(cpuItem, voir point 11) doivent être générées juste avant et juste après le RAM-reset
afin d'être envoyées via le fichier F6.
-7-
Version II_V12.1
4
1er décembre 2016
CONDITIONS TECHNIQUES RELATIVES AU CÂBLAGE ET AUX
COMPOSANTS PASSIFS DU LAN
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.
-8-
Version II_V12.1
5
1er décembre 2016
CONDITIONS TECHNIQUES RELATIVES AUX COMPOSANTS
ACTIFS DU LAN
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.
-9-
Version II_V12.1
6
1er décembre 2016
CONDITIONS TECHNIQUES RELATIVES AUX CLIENTS ET AUX
SERVEURS
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.
Si, pour une raison quelconque la porte donnant accès au compartiment cpu de la machine
automatique est ouverte, le Service évaluations techniques doit être informé (voir point 11)
(la machine peut rester en exploitation).
La porte mentionnée ci-dessus doit être équipée d’un senseur, protégé de façon mécanique
et électronique, lequel enregistrera tous les mouvements de cette porte dans une base de
données du système on line, de telle manière que tous les mouvements seront enregistrés et
que dès lors plus aucune information ne pourra être ôtée ou modifiée. L’approvisionnent
énergétique des senseurs de même que l’interface qui garantit l’envoi de ces interruptions
vers le système on line et la connexion de l’interface avec le système on line même, doivent
être garantis à tout moment. Lorsqu’une interruption de la connexion survient, le système
on line doit enregistrer l’heure de début et de fin de cette interruption.
Si, pour une raison quelconque (vieux modèle, en panne de façon définitive, vente,.....) un
jeu automatique est retiré, la Commission des Jeux de Hasard doit être prévenue
immédiatement. En même temps il y a lieu d’envoyer à la Commission des Jeux de Hasard
, via l'adresse email [email protected] toutes les données d’identification du
jeu ainsi que les valeurs des compteurs mécaniques et/ou électroniques. Le jeu en question
doit rester à disposition de la Commission des Jeux de Hasard à proximité de
l’établissement jeu concerné pendant une période de 14 jours ouvrables. Pendant cette
période, si elle l’estime nécessaire, la commission peut effectuer un contrôle des données
transmises.
Polling
Concernant le polling (détermine si un jeu est online/offline) la procédure suivante est
d’application:
- Indépendamment de la communication data entre la carte mère du jeu – interface –
système online une routine de polling doit être prévue afin de déterminer si la connexion
entre l’interface et le système online est opérationnelle.
- L’initiative peut être prise soit par le serveur, soit par l’interface. Dans tous les cas le
serveur doit vérifier que les messages de polling de tous les jeux arrivent;
-10-
Version II_V12.1
1er décembre 2016
- Chaque machine de jeu doit au minimum donner un polling positif toutes les 5 minutes.
La fréquence de polling de chaque machine doit être au moins une fois par minute;
- Si dans une période de 5 minutes (à compter à partir du premier polling négatif) il n’y a
pas un polling positif le serveur mémorise le TimeStamp (evenTiming/start) et les
compteurs (totalBetBegin et totalWinBegin).
- Lors du premier polling positif suivant
le serveur mémorise les données
complémentaires de l'événement : le TimeStamp (evenTiming/end) et les compteurs
(totalBetEnd et totalWinEnd).
- Le bloc de données onlineItemType ne doit être envoyé que dans le premier fichier
F6 qui suit la clôture de l'évènement. Si plusieurs interruptions se sont produites, le
fichier F6 contiendra autant de bloc onlineItemType qu'il y a eu d'interruptions.
- La commande à utiliser pour le polling est celle pour récupérer en “real time” les
compteurs du jeu;
- Le résultat de chaque polling positif est enregistré dans la DB y compris la valeur des
compteurs (d’historique des 50 derniers pollings). En cas de “ram reset” les valeurs des
compteurs juste avant et après le reset doivent être communiqué à la commission des jeux
de hasard.
Concernant la synchronisation des “RTC” le serveur du système online doit se synchroniser
avec un “time server” public au moins une fois par heure. Ensuite les “RTC” de machines
de jeux sont synchronisés avec le serveur online.
Quotidiennement, un historique de ces évènements (interruption de la connexion, ouverture
du compartiment cpu) doit être ajouté au fichier F6.
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).
-11-
Version II_V12.1
7
1er décembre 2016
CONDITIONS TECHNIQUES RELATIVES AU LOCAL DESTINÉ
AU "DATA-RACK"
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.
Cette documentation doit être également disponible sous forme électronique.
-12-
Version II_V12.1
8
1er décembre 2016
CONDITIONS TECHNIQUES RELATIVES À LA LIAISON DE
DONNÉES AVEC LA COMMISSION DES JEUX DE HASARD
Le titulaire de licence assure une connexion IP adéquate avec la DMZ du SPF Justice, 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.
Le titulaire de licence est également chargé de l’acquisition, de l’installation et de la
programmation des composants actifs requis du LAN.
Le titulaire de licence 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.
Connexion supplémentaire à la Commission des Jeux de Hasard pour la supervision en
ligne :
-/ Afin de permettre à la Commission des Jeux de Hasard le suivi en ligne, chaque
détenteur de licence doit prévoir un VPN de « site à site ».
-/ Cette connexion sera intégrée dans le pare-feu internet de la Commission des Jeux de
Hasard, les informations requises seront communiquées en temps utile.
-/ Grâce à cette connexion il doit être possible de consulter tous matériels et logiciels qui
font l'objet de la procédure de certification. Il devrait également être possible de copier
des fichiers afin de poursuivre les recherches.
-13-
Version II_V12.1
9
1er décembre 2016
CONDITIONS SUPPLÉMENTAIRES RELATIVES AU SYSTÈME
DE VIDÉOSURVEILLANCE
Des caméras doivent être installées au moins aux endroits suivants :
- le lieu d’enregistrement et/ou de contrôle du joueur, de sorte que la constitution du fichier
et l’interrogation du fichier central des personnes exclues peuvent être suivies ;
- les caisses ;
- les jeux automatiques.
Sur simple demande, les enregistrements demandés doivent être transmis à la Commission
des jeux de hasard. Dans le cas de formats propriétaire le "viewer" adéquat doit être
également fourni.
Ce "viewer" doit fonctionner avec toutes les versions disponibles du système d’exploitation
Windows. Les images vidéo doivent posséder un "framerate" minimal de 12
images/seconde.
La résolution minimale doit être 4CIF (704 x 480). La qualité et le choix des caméras
doivent tenir compte des conditions spéciales d’éclairage prévalant dans l’établissement de
jeux de hasard.
Pour les nouveaux ou les renouvellements des systèmes de surveillance, il y a lieu d'utiliser
des caméras couleurs.
Les informations concernant les renouvellements et/ou adaptations des systèmes doivent
être communiquées à la Commission des jeux de hasard via l'adresse email
[email protected].
Le préposé responsable de l’exploitation de l’établissement de jeu (le titulaire de la
licence de classe D) doit pouvoir visionner les images vidéos « en temps réel » à partir
de son poste de travail, ceci au moins lorsque l’administrateur (le titulaire de la licence
d’exploitation) est absent et ne peut donc assumer cette tâche et que le matériel vidéo
n’est, par conséquent, pas accessible au titulaire de la licence D.
Les enregistrements doivent être conservés pendant quatre semaines.
Les images doivent être constamment disponibles. Le titulaire de licence est tenu de
notifier immédiatement, à la Commission des Jeux de hasard, via l'adresse email
[email protected], tout dérangement technique survenu au niveau de
la vidéosurveillance.
Les images doivent reprendre la date et l'heure de la prise de vue.
-14-
Version II_V12.1
10
1er décembre 2016
CONDITIONS RELATIVES À L’INFORMATION COMPTABLE ET
FINANCIÈRE (F1 ET F2)
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 à partir du serveur de l'établissement de jeu à la Commission des
jeux de hasard.
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 14/ A Certification.
-/ Nombre de machines concernées
Pour chaque machine mono-joueur :
Pour chaque machine multi-joueur, identification des masters + :
-/ No d'identification du jeu (*)
-/ No de suite interne (attribué par la salle de jeu)
-/ No d'approbation du service évaluations techniques(*)
-/ No de la vignette de taxe
-/ 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) (*)
-/ Compteur Total Bet à l'ouverture (*)
-/ Compteur Total Bet à la fermeture (*)
-/ Compteur Total Win à l'ouverture (*)
-/ Compteur Total Win à la fermeture (*)
-/ TimeStamp de l'ouverture
-/ TimeStamp de la fermeture
Remarque :
-/ Le champ "masterType" doit respecter la codification suivante :
M1 : single master, cpu dans le master et les satellites
M2 : single master, cpu uniquement dans les satellites
M3 : single master, cpu uniquement dans le master
M4 : multi master, cpu dans le master et les satellites
M5 : multi master, cpu uniquement dans les satellites
M6 : multi master, cpu uniquement dans le master
Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "II_F1"
B/ Résultats globaux :
Résultat total provenant de la caisse destinée spécialement aux jeux automatiques :
-/ Total des mises pour toutes les machines
-/ Total des gains pour toutes les machines
-/ Résultat global des machines automatiques
-/ TimeStamp de l'ouverture
-/ TimeStamp de la fermeture
-15-
Version II_V12.1
11
1er décembre 2016
CONDITIONS RELATIVES À L'ENREGISTREMENT (F5)
Il convient de transmettre à la Commission des jeux de hasard, toutes les 24 heures, un
fichier en format XML comportant par visiteur :
- date et heure de l'enregistrement ;
- nom ;
- prénom ;
- date de naissance ;
- lieu de naissance ;
- profession ;
- nom de rue et numéro de maison ;
- code postal ;
- commune ;
- pays (2chr conformément norme ISO 3166-1-alpha-2 code) ;
Dans le cas où l'établissement tient uniquement un registre électronique, le programme doit
générer une fiche reprenant les données mentionnées ci-dessus plus la date du jour et l'heure
et un numéro de suite séquentielle. Le client doit signer cette fiche avant de rentrer dans la
salle de jeux. Ces fiches doivent être conservées dans les mêmes conditions que le registre
traditionnel.
Ce fichier doit être généré de façon automatique et envoyé directement à la Commission des
jeux de hasard à partir de l’établissement.
Remarque : la signature peut se faire électroniquement via la carte eId.
Une intégration doit être prévue entre le logiciel d’enregistrement des joueurs et la
fonctionnalité "Interrogation EPIS".
Dans la pratique, cela s’assimile à l’utilisation du service web. L’interrogation manuelle via
le site web n'est pas autorisée.
Si EPIS n’est pas accessible, il convient d’attendre le time-out normal. Le joueur concerné
doit être inscrit dans le registre provisoire. Une période d'attente de 15' court alors. Durant ce
laps de temps, EPIS ne doit plus être interrogé. Les joueurs qui sont ajoutés durant cette
période sont enregistrés dans le registre provisoire. A l’échéance de cette période d’attente,
EPIS récupère automatiquement tous les joueurs inscrits dans le registre provisoire. La
"procédure d’urgence" actuelle continue de produire ses effets. Un nouveau délai de 15’
débute lors d’un nouveau time-out.
Le programme d’enregistrement ne peut plus offrir de possibilités de choix manuels afin
d’interroger ou non EPIS. En cas d’inaccessibilité prolongée d’EPIS, le contenu du registre
Bis est transféré dans le fichier F5.
-16-
Version II_V12.1
12
1er décembre 2016
CONDITIONS RELATIVES AU CONTRÔLE TECHNIQUE (F6)
Ces informations doivent être transmises toutes les 24 heures à la Commission des jeux
de hasard.
Le fichier XML global présente la structure décrite à l'annexe 1 : Définitions du fichier
"II_F6". Ce fichier reprend les éléments suivants :
(*) = 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 14/ A Certification.
Informations administratives :
-/ Numéro de série de la machine (*)
-/ Nom de la machine
-/ Numéro de suite interne (attribué par la salle de jeu)
-/ Numéro d'approbation du service évaluations techniques (*)
-/ Date de la dernière vérification
Le fichier XML présente la structure décrite à l'annexe 1 : élément-XML "info"
Informations concernant l’intégrité du logiciel du jeu :
Au moins une fois toutes les 24 heures un programme vérifiant la / les signatures
EPROM est lancé sur chaque appareil de jeu de hasard automatique.
-/ Nombre d'éléments software concernés
Pour chaque élément software concerné:
-/ Identification de l'élément software concerné (*)
-/ Identification de la version software (*)
-/ Signature software (*)
-/ Clés utilisées pour la Signature software (*)
Le fichier XML présente la structure décrite à l'annexe 1 : élément-XML "epromItem"
Informations concernant l’ouverture et la fermeture du compartiment CPU :
-/ Nombre d'évènements CPU
Pour chaque "évènement" CPU :
-/ TimeStamp de l'évènement (prévoir une précision correcte ; au moins la minute)
-/ Type d'évènement (Open / Close)
-/ No de suite de l'évènement
-/ No du licence "E" responsable de l'évènement
-/ Nom du technicien responsable de l'évènement
-/ Raison de l'évènement (si type = Close : indiquer "Fin d'intervention")
-/ Nombre de jours depuis la dernière ouverture
-/ Total Bet lors de l'évènement (*)
-/ Total Win lors de l'évènement (*)
La rupture de connexion entre le switch CPU et le module de contrôle doit être
considéré comme une ouverture de la porte CPU.
Pour une même journée, il faut limiter le nombre d'évènements CPU "fantômes" à 50 et
intervenir sur la machine endéans les 48 h pour réparer le switch défectueux. Le dernier
évènement CPU "résolution du problème de switch" doit être communiqué
Le fichier XML présente la structure décrite à l'annexe 1 : élément-XML "cpuItem"
Informations concernant l’interruption de la connexion avec le système on line :
-/ Nombre d'interruptions OnLine
Pour chaque évènement :
-/ TimeStamp de l'interruption
-/ TimeStamp de la remise en service de la liaison OnLine
-17-
Version II_V12.1
1er décembre 2016
-/ Total Bet lors de l'interruption (*)
-/ Total Win lors de l'interruption (*)
-/ Total Bet lors de la remise en service de la liaison OnLine (*)
-/ Total Win lors de la remise en service de la liaison OnLine (*)
Le fichier XML présente la structure décrite à l'annexe 1 : élément-XML "onlineItem"
-18-
Version II_V12.1
13
1er décembre 2016
CONDITIONS
RELATIVES
À
LA
DOCUMENTATION
CONCERNANT LE SYSTÈME INFORMATIQUE ET LE SYSTÈME
DE VIDÉOSURVEILLANCE
La documentation suivante doit être transmise préalablement à la Commission des jeux de
hasard :
a) 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.
b) concernant le système de vidéo-surveillance :
- nom et adresse du fournisseur et/ou du fabricant ;
- numéros d’identification et de série ;
- localisation et plan du poste de contrôle ;
- plan technique du système et de son fonctionnement ;
- documentation technique relative aux caméras utilisées.
-19-
Version II_V12.1
14
UTILISATION
DES
L'INFORMATION
1er décembre 2016
NOUVELLES
Pas d'exigences au stade actuel.
-20-
TECHNOLOGIES
DE
Version II_V12.1
15
1er décembre 2016
NORMES CONCERNANT LA NOMENCLATURE DES FICHIERS À
ENVOYER
La commission n'a pas d'exigence particulière en ce qui concerne le nom du fichier xml
mais conseille d'utiliser un nom permettant facilement à l'envoyeur d'identifier
clairement le fichier, ci-après un exemple de nom de fichier pouvant être utilisé.
Exemple : II_012345_F5_20130517_221743.xml
Attention: les fichiers envoyés pour des numéros de licence non valides seront refusés
par le système.
-21-
Version II_V12.1
16
1er décembre 2016
APPROBATION
Le présent protocole a été établi par la Commission des jeux de hasard et approuvé en sa
séance du 26 octobre 2016.
Les constructeurs doivent apporter les modifications nécessaires à leur système online
avant le 1er juillet 2017. La certification obtenue pour la version protocole précédente, reste
valable.
La Commission des jeux de hasard veillera scrupuleusement à la stricte application du
présent protocole. Le non-respect des dates mentionnées ci-dessus peut donner lieu à des
sanctions.
Le Président.
E. Marique.
-22-
Version II_V12.1
17
1er décembre 2016
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 "II_F1" (Point 9) : /f1/
Field
Cardinality
Data type
Description
protocolVersion
1
string
Version du protocole (attribut de f1) = II_V12
generalInfo/licenseId
1
int
Le numéro de la licence B
generalInfo/fileDate
1
protocolDate
Date du fichier (après 01-01-2000)
generalInfo/licenseType
1
licenseTypeType
Type de licence : B
generalInfo/email
1
emailType
Email du responsable On-Line
int
Le numéro de licence E fabricant
generalInfo/manufacturerId
0→1
monoPlayer
1
monoPlayerType
Données des machines mono-joueur
multiPlayer
1
multiPlayerType
Données des machines multi-joueurs
monoPlayerType : /f1/monoPlayer/
Field
nbOfItems
station
Cardinality
1
Data type
0→n
int
Description
Nombre de stations concernées
stationType
Données des stations mono-joueur
multiPlayeTyper : /f1/multiPlayer/
Field
nbOfItems
multi
Cardinality
1
Data type
0→n
int
Description
Nombre de machines concernées
multiType
Données éléments des machines multi-joueurs
multiType : /f1/multiPlayer/multi/
Field
masters/nbOfItems
masters/master
stations/nbOfItems
stations/station
Cardinality
1
Data type
1→n
1
1→n
Description
int
Nombre de master
masterType
Données des master qui composent cette machine
int
Nombre de satellites
stationType
Données des stations qui composent cette machine
masterType : /f1/multiPlayer/multi/masters/master/
Field
id
masterType
Cardinality
1
1
Data type
string
Description
Le numéro d'identification unique du master
masterTypeType
Le type du master : M1,M2,M3,M4,M5,M6
stationType : /f1/multiPlayer/multi/stations/station/ ; /f1/monoplayer/station/
Field
id
Cardinality
1
Data type
string
Description
Le numéro d'identification unique du jeu (no de série) (*)
internalId
1
string
Le numéro de suite interne (attribué par le casino)
approvalId
1
string
Le numéro d'approbation du service évaluations techniques
(*)
extraInfo/taxNumber
1
string
Numéro de la vignette de taxe
-23-
Version II_V12.1
extraInfo/realBet
1er décembre 2016
1
long
Total des mises de la journée (en eurocents)
extraInfo/realWin
1
long
Total des gains de la journée (en eurocents)
extraInfo/gameResult
1
long
Résultat de la journée (en eurocents)
extraInfo/nbOfGamesPlayed
1
long
Nombre de parties jouées (compteur global) (*)
extraInfo/realBetBegin
1
long
Compteur Total Bet à l'ouverture (en eurocents) (*)
extraInfo/realBetEnd
1
long
Compteur Total Bet à la fermeture (en eurocents) (*)
extraInfo/realWinBegin
1
long
Compteur Total Win à l'ouverture (en eurocents) (*)
extraInfo/realWinEnd
1
long
Compteur Total Win à la fermeture (en eurocents) (*)
extraInfo/ opening/start
1
dateTime
TimeStamp de l'ouverture
extraInfo/ opening/end
1
dateTime
TimeStamp de la fermeture
(* = données de base, c'est à dire données devant être récoltées en temps réel sur la machine ; voir exigences du point 3 A
Certification)
Field
Cardinality
Data type
Description
protocolVersion
1
string
1
int
1
protocolDate
1
licenseTypeType
Type de licence : B
generalInfo/email
1
emailType
int
0→1
gamesInfo/totalRealBet
1
long
Total des mises pour toutes les machines (en eurocents)
gamesInfo/totalRealWin
1
long
Total des gains pour toutes les machines (en eurocents)
gamesInfo/totalGamesResult
1
long
Résultat global des machines automatiques (en
eurocents)
gamesInfo/opening/start
1
dateTime
TimeStamp de l'ouverture
gamesInfo/opening/end
1
dateTime
TimeStamp de la fermeture
Field
Cardinality
Data type
Description
protocolVersion
1
string
1
int
1
protocolDate
1
licenseTypeType
Type de licence : B
generalInfo/email
1
emailType
0→1
int
1
int
Nombre de visiteurs
guestType
Données des visiteurs
guests/nbOfItems
guests/guest
0→n
guestType : /f5/guests/guest/
Field
timestamp
Cardinality
1
Data type
protocolDateTime
Description
TimeStamp de l'enregistrement (après 01-01-2000)
lastName
1
string
Nom
firstName
1
string
Prénom
-24-
Version II_V12.1
birthDay
1er décembre 2016
1
date
Date de naissance
birthPlace
1
string
lieu de naissance
profession
1
string
Profession
houseNbr
1
string
Numéro
houseBox
1
string
Boîte
street
1
string
Rue
zipCode
1
string
Code postal
city
1
string
commune
country
1
string
pays (2chr conformément ISO 3166-1-alpha-2 code)
Field
protocolVersion
Cardinality
1
Data type
string
Description
1
int
1
protocolDate
1
licenseTypeType
Type de licence : B
generalInfo/email
1
emailType
0→1
int
1
int
Nombre de machines concernées
gameType
Liste des données techniques par jeu
games/nbOfItems
games/game
1→n
gameType : /f6/games/game/
Field
info
Cardinality
1
eprom/nbOfItems
1
eprom/epromItem
1→n
cpu/nbOfItems
cpu/cpuItem
1
0→n
online/nbOfItems
1
online/onlineItem
0→n
Data type
infoType
Description
Informations administratives
int
Nombre d'éléments software concernés
epromItemType
Information concernant les éléments software
int
Nombre d'évènements CPU
cpuItemType
Information concernant les évènements CPU
int
Nombre d'interruptions OnLine
onlineItemType
Information concernant interruption on-line
infoType : /f6/games/game/info/
Field
id
Cardinality
1
Data type
string
Description
Numéro de série de la machine (*)
gameName
1
string
Nom de la machine
internalId
1
string
Numéro de suite interne (attribué par la salle)
string
Numéro d'approbation du service évaluations techniques(*)
date
Date de la dernière vérification
approvalNumber
lastCheckDate
1
0→1
epromItemType : /f6/games/game/eprom/epromItem/
Field
Data type
string
Description
Identification de l'élément software concerné (*)
1
string
Identification de la version software (*)
checkResult
1
string
Signature software (*)
checkKeys
1
string
Clés ou algorithme utilisés pour la Signature software (*)
id
gameSoftwareVersion
Cardinality
1
cpuItemType : /f6/games/game/cpu/cpuItem/
Field
openDateTime
eventType
Cardinality
1
1
Data type
dateTime
Description
TimeStamp de l'évènement
cpuEventType
Type d'évènement (Open / Close)
-25-
Version II_V12.1
formId
1er décembre 2016
1
string
No de suite de l'évènement
licenseId
1
int
No du licence "E" responsable de l'évènement
name
1
string
Nom du technicien responsable de l'évènement
reason
1
string
Raison de l'évènement
nbOfDaysSinceLastEvent
1
int
Nombre de jours depuis la dernière ouverture
totalBet
1
decimal
Total Bet lors de l'évènement (en eurocents) (*)
totalWin
1
decimal
Total Win lors de l'évènement (en eurocents) (*)
onlineItemType : /f6/games/game/online/onlineItem/
Field
evenTiming/start
Cardinality
1
Data type
dateTime
Description
TimeStamp de l'interruption
evenTiming/end
1
dateTime
TimeStamp de la remise en service de la liaison OnLine
totalBetBegin
1
decimal
Total Bet lors de l'interruption (en eurocents) (*)
totalWinBegin
1
decimal
Total Win lors de l'interruption (en eurocents) (*)
totalBetEnd
1
decimal
Total Bet lors de la remise en service de la liaison OnLine (en
eurocents) (*)
totalWinEnd
1
decimal
Total Win lors de la remise en service de la liaison OnLine (en
eurocents) (*)
(* = 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 14 A
Certification)
-26-
Version II_V12.1
18
1er décembre 2016
ANNEXE 2 : PROTOCOLE DE COMMUNICATION STANDARD
De plus, un protocole de communication standard est prévu , lequel uniformise l’échange
de données entre l’interface et la carte-mère des machines à sous automatiques.
A. But :
Ce protocole comporte 3 groupes de commandes :
1. Les commandes publiques obligatoires que chaque jeu automatique de classe II doit
supporter. Ces commandes portent les références 0 à 127 soit 00(hex) – 7F(hex)
2. Les commandes publiques optionnelles (texte en bleu dans cette annexe) qui servent
à améliorer la communication et/ou à remédier à certaines imperfections des
commandes obligatoires. Le fabricant qui déclare supporter ces commandes
s'engagent à respecter cette partie du protocole. Les fabricants qui souhaitent utiliser
ces commandes doivent au préalable s'assurer qu'elles sont correctement supportées
par la machine de jeux.
3. Les commandes privées facultatives : L'utilisation de ces commandes est propre à
un jeu. Il s'agit des commandes 176 à 255 soit B0(hex) – FF(hex).
Il appartient au système on-line de vérifier si les commandes du groupe 2 et/ou du
groupe 3 sont supportées. Ainsi, une compatibilité avec les jeux déjà installés est
assurée.
Exemple : Pour déterminer si une commande du groupe 2 est supportée:
1. vérifier la communication entre le jeu et le système on-line par la réponse correcte à
une commande obligatoire du groupe 1,
2. envoyer une commande du groupe 2 : si la réponse est la commande NULL ou s'il
n'y pas de réponse, cette commande n'est pas supporté.
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
-27-
Version II_V12.1
1er décembre 2016
-/ 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
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
En plus, les termes suivants sont utilisés pour les commandes Cashless (0x91 à 0x98) :
• interface status (IntStat) = information d'un byte, direction master → slave :
IntStat: bit 0 (0x01) = 1/0: interface connection to server Y/N
1 (0x02) = 1/0: player card present Y/N
2 (0x04) = 1/0: cashless in (interface → game) supported Y/N
3 (0x08) = 1/0: cashless out (game → interface) supported Y/N
4 (0x10) = 1/0: lock game Y/N
5 (0x20) = 0, not used
6 (0x40) = 0, not used
7 (0x80) = 0, not used
• game status (GamStat) = information d'un byte, direction slave → master :
GamStat: bit 0 (0x01) = 1/0: stable game status and counters Y/N
1 (0x02) = 1/0: credit in enabled Y/N
2 (0x04) = 1: payout activated, 0 @ answer to cd 93
3 (0x08) = 1/0: cashless in (interface → game) supported Y/N
4 (0x10) = 1/0: cashless out (game → interface) supported Y/N
5 (0x20) = 1: note change out activated, 0 @ answer to cd 93
-28-
Version II_V12.1
1er décembre 2016
6 (0x40) = 1: hand pay activated, 0 @ answer to cd 93
7 (0x80) = 0, not used
• game events (GamEvent) = information d'un byte, direction slave → master :
GamEvent: bit 0 (0x01) = 1/0: stable game status and counters Y/N
1 (0x02) = 1/0: credit in enabled Y/N
2 (0x04) = 1: payout activated, 0 @ answer to cd 93 or hopper pay start
3 (0x08) = 1: coin(s) in detected, 0 @ answer to cd 2, 3 or 97
4 (0x10) = 1: coin(s) out detected , 0 @ answer to cd 2, 4, or 97
5 (0x20) = 1: change out activated, 0 @ answer to cd 93
6 (0x40) = 1: hand pay requested, 0 @ answer to cd 93
7 (0x80) = 1: new door / switch event(s), 0 @ answer to cd 12
• return code (RetCode) = 16 bit information (2 bytes), direction slave → master :
RetCode: bit 0
(0x0001) = 1/0: service request Y/N
1
(0x0002) = 1/0: service mode Y/N
2
(0x0004) = 1: power on, 0 @ answer to cd 97
3
(0x0008) = 1/0: locked game Y/N
4
(0x0010) = 1/0: CPU door open Y/N
5
(0x0020) = 1/0: other door than CPU door open Y/N
6
(0x0040) = 1: coin in error, 0 @ answer to cd 97
7
(0x0080) = 1: pay out error, 0 @ answer to cd 97
8
(0x0100) = 1: note in error, 0 @ answer to cd 97
9
(0x0200) = 1/0: hopper full Y/N
10 (0x0400) = 1/0: coin box full Y/N
11 (0x0800) = 1: parameter(s) changed, 0 @ answer to cd 97
12 (0x1000) = 1: RAM reset, 0 @ answer to cd 97
13 (0x2000) = 0, not used
14 (0x4000) = 0, not used
15 (0x8000) = 0, not used
• transaction number (TrnNb) = information d'un byte, reste constant pour toute la
procédure Cashless et doit être différent pour toute nouvelle procédure (transaction
Cashless)
• security check (SecChk): CRC16 sur 16 bits, utilisant l'algorithme CCITT, avec la
clef 0x1021 dérivé du polynôme x^16+x^12+x^5+1 avec une valeur initiale du
CRC16 = 0. Le CRC16 est calculé en utilisant une clé de sécurité initiale de 32 bits
(long), codé en 8 bytes en utilisant la conversion ASCII décrit en D.2. et toutes le
données qui ont été convertis en ASCII (voir D.2).
Exemple :
ajouter 450 € de crédits au jeu = 45000 €c = 0x0000AFC8 avec :
-/ un numéro de transaction = 18 (0x12)
-/ une clé de sécurité initiale (secrète) = 0xA103BCA4
le SecCheck, calculé sur la chaîne “A103BCA4120000AFC8“ donne 0xC0BE
la chaîne à transmettre est donc “120000AFC8C0BE”.
• transaction status (TrnStat) = information d'un byte, direction slave → master :
TrnStat = 0x00: credit transfer accepted and waiting for validation
0x01: credit in or regular payout transfer executed with success
0x02: credit transfer canceled
0x11: change out transfer executed with success
0x21: hand pay procedure with success
0x81: transfer refused (no reason specified)
0x82: credit transfer refused due to reached credit limit
-29-
Version II_V12.1
1er décembre 2016
0x83: transfer refused cause security check (SecChk) error
0x84: transfer refused due to transaction number (TrnNb) error
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.
-30-
Version II_V12.1
1er décembre 2016
Cmd
Description
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
Null
Get game identification (identification jeu)
Get general counters (compteurs généraux)
Get ‘Credit in’ counter (compteur “Cash in”)
Get ‘Credit out’ counter (compteur “Cash out”)
Get ‘Hand pay’ counter (compteur “comptant”)
Get ‘Total bet’ counter (compteur “total In”)
Get ‘Total win’ counter (compteur “total Out”)
Get number of played games (nombre de parties
jouées)
Get number of interrupts (nombre d’interruptions)
Get ‘CPU-Door open’ (nombre d'ouverture de la
"zône" CPU)
Get ‘Change in’ counter (compteur “change in”)
Get ‘Change out’ counter (compteur “change
out”)
Get game software version
Get checksum (signature software)
Réserve
Ouverture du compartiment CPU
Fermeture du compartiment CPU
Obtenir les évènements porte / interrupteurs
Synchronisation des "RTC"
Ajouter des crédits au jeu : Crédit in
Validation Credit In
Paiement du jeu
Validation paiement
Annulation transaction
Obtenir l'information « game event »
Obtenir les informations comptables du jeu
Obtenir l'information étendue du protocole
0x09
0x0A
0x0B
0x0C
0x0D
0x0E
0x0F
0x10
0x11
0x12
0x19
0x91
0x92
0x93
0x94
0x95
0x96
0x97
0x98
Nbre bytes
TxD
RxD
4
6
4
31
4
70
4
14
4
14
4
14
4
14
4
14
4
14
Groupe
Cmd
1
1
1
1
1
1
1
1
1
4
4
14
14
1
1
4
4
14
14
1
1
4
4
16
17
25
25
20
0
22
46
30
46
22
8
70
16
1
1
4
4
4
24
20
20
20
20
20
4
6
4
1
1
2
1
2
2
2
2
2
2
2
2
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
-31-
Version II_V12.1
1er décembre 2016
G.1. 0x01: Visualisation de l’identification du jeu
Rend le numéro d’approbation du service évaluations techniques sous un format B-xxxxxxxx/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
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.
TxCmd:
STX 0x30 0x32 EOT
RxPrototype: STX “02” “credit in” “credit out” “handpay” “total bets” “total wins”
“games” “interrupts“ “CPU-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
-32-
Version II_V12.1
1er décembre 2016
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
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 ‘CPU-Door open’
-33-
Version II_V12.1
1er décembre 2016
Le compteur ‘CPU 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
le compartiment CPU est ouvert.
TxPrototype: STX “0A” EOT
TxCmd:
STX 0x30 0x41 EOT
RxPrototype: STX “0A” “CPU-Door” “CS” EOT
Exemple:
STX “0A” “00000010” “F2” EOT
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.
-34-
Version II_V12.1
1er décembre 2016
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
G.15. 0x0F: Réservé pour une utilisation ultérieure
G.16. 0x10: Ouverture du compartiment CPU.
Cette commande permet d’enregistrer une ouverture du compartiment CPU avec la date
et l’heure de l’évènement. Si le numéro du compartiment CPU n’est pas défini d’une
manière standard, le chiffre 1 sera utilisé par défaut. L’exemple illustre une ouverture de
la porte n° 2 le 10/04/2006 à 10.43 heures.
TxCmd:
STX 0x31 0x30 EOT
RxPrototype: STX “10” “door“ “date” “time” “CS” EOT
Exemple :
STX “10” “2” “2006/04/18” ”10:43:21” “25” EOT
Hex: 0x02 0x31 0x30 0x32
0x32 0x30 0x30 0x36 0x2F 0x30 0x34 0x2F 0x31 0x38
0x31 0x30 0x3A 0x34 0x33 0x3A 0x32 0x31 0x32 0x35 0x04
G.17. 0x11: Fermeture du compartiment CPU.
Cette commande permet d’enregistrer une fermeture du compartiment CPU avec la
date et l’heure de l’évènement. Si le numéro du compartiment CPU n’est pas défini
d’une manière standard, le chiffre 1 sera utilisé par défaut. L’exemple illustre une
fermeture de la porte n° 2 le 10/04/2006 à 10.43 heures.
TxCmd:
STX 0x31 0x31 EOT
RxPrototype: STX “11” “door“ “date” “time” “CS” EOT
Exemple:
STX “11” “2” “2006/04/18” ”10:43:21” “26” EOT
Hex: 0x02 0x31 0x31 0x32
0x32 0x30 0x30 0x36 0x2F 0x30 0x34 0x2F 0x31 0x38
0x31 0x30 0x3A 0x34 0x33 0x3A 0x32 0x31 0x32 0x36 0x04
G.18. 0x12: Obtenir les évènements porte / interrupteurs
Cette commande permet d'obtenir d'une manière générale les évènements tels que
ouverture de porte ou activation d'interrupteurs de surveillance. Cette fonction
remplace les fonctions 0x10 et 0x11.
RxPrototype: STX “12” “action” “date” time” “seqnb” “CS” EOT
où: “action” = “00”: tout transmis, pas de nouveau(x) événement(s)
”01”: non utilisé
“02”: porte Cpu ouverte
“03”: porte Cpu fermée
”04 - - FF”: non utilisé maintenant
“date” “time” = “AAMMJJ” “HHMM”
“seqnb” = Numéro de séquence à 1 Byte, incrémenté pour chaque nouvel
évènement, copie du dernier numéro de séquence si “action” =
“00”. La valeur 1 suit 255 et la valeur 0 est réservé.
-35-
Version II_V12.1
1er décembre 2016
G.19. 0x19: Synchronisation des "RTC"
Cette commande permet de synchroniser les jeux automatiques avec le serverur online.
Ex: Synchronisation à la date du 18/04/2006 à 10:43:21
TxPrototype: STX “19” “date” “time” “CS” EOT
Exemple.: STX “19” “2006/04/18” “10:43:21” “FC” EOT
Hex: 0x02 0x31 0x39
0x32 0x30 0x30 0x36 0x2F 0x30 0x34 0x2F 0x31 0x38 0x31 0x30 0x3A 0x34 0x33
0x3A 0x32 0x31 0x46 0x43 0x04
G.20. 0x91: Credit In : Ajouter des crédits au jeu
Cette commande permet de demander l'addition de crédits au jeu, le montant maximum à
transmettre par transaction est 500 €.
TxPrototype: STX “91” “TrnNb” “Amount2Add” “SecChk” “CS” EOT
RxPrototype: STX “91” “TrnNb” “TrnStat” “Amount2BAdded” “SecChk” “CS” EOT
où: Amount2Add = montant à ajouter
Amount2BAdded = montant ajouté après validation par la commande 0xB2
G.21. 0x92: Validation du Credit In
Cette commande permet de valider le transfert des crédits vers le jeu.
TxPrototype: STX “92” “TrnNb” “Amount2Add” “SecChk” “CS” EOT
RxPrototype: STX “92” “TrnNb” “TrnStat”
“Amount2Add” “AmountAdded”
“CreditBefore” “CreditAfter” “SecChk” “CS” EOT
où: Amount2Add = montant initialement demandé à ajouter
Amount2Added = montant ajouté
CreditBefore
= crédits au jeu avant la transaction
CreditAfter
= crédits au jeu après la transaction
G.22. 0x93: Payout du jeu
Cette commande permet de payer les crédits disponible au jeu, de recevoir le montant d'un
change ou de transférer le montant d'un paiement manuel (Handpay / Drop). Le jeu signale
l'action dans la réponse à la commande 0x96 (Évènements jeu) pendant 4 secondes. Si la
commande 0x93 est envoyé pendant ce délai, la procédure est démarré et la signalisation du
type de paiement est codé dans la variable TranStat des commandes 0x93 et 0x94 (voir
D.3.).
TxPrototype: STX “93” “TrnNb” “Amount2Pay” “SecChk” “CS” EOT
RxPrototype: STX “93” “TrnNb” “TrnStat” “Amount2Pay” “Amount2BPaid” “SecChk”
“CS” EOT
où: Amount2Pay = Montant demandé pour paiement, 99.000.000 = payer tout
Amount2BPaid = Montant retiré après validation par la commande 0xB4
G.23. 0x94: Validation Payout
Cette commande valide la demande de paiement 0x93 préalable.
TxPrototype: STX “94” “TrnNb” “Amount2Pay” “SecChk” “CS” EOT
RxPrototype: STX “94” “TrnNb” “TrnStat”
“Amount2Pay”
“CreditBefore” “CreditAfter” “SecChk” “CS” EOT
où: Amount2Pay = montant initialement demandé à payer
AmountPaid = montant payé
CreditBefore = crédits au jeu avant la transaction
CreditAfter
= crédits au jeu après la transaction
-36-
“AmountPaid”
Version II_V12.1
1er décembre 2016
G.24. 0x95: Annulation transaction financière
Cette commande annule la commande 0x91 (Credit In) ou 0x93 (Payout) qui précède cette
commande 0x95.
TxPrototype: STX “95” “TrnNb” “InitalAmount” “SecChk” “CS” EOT
RxPrototype: STX “95” “TrnNb” “TrnStat” “InitalAmount” “SecChk” “CS” EOT
où: InitialAmount = montant initialement évoqué (à ajouter / retirer)
G.25. 0x96: Obtenir l'information « game event »
Cette commande permet de recevoir le statut des évènements possibles survenant au jeu. Le
jeu signale un évènement pendant 4 secondes.
En ce qui concerne le Payout (paiement des crédits disponible au jeu, recevoir le montant d'un
change ou transférer le montant d'un paiement manuel =Handpay / Drop, le jeu amorce un
paiement via le Hopper à l'expiration de ce délai. Si par contre, la commande 0x93 (payout)
est reçu par le jeu en dedans ces 4 secondes, la procédure de paiement « Cashless » est initié.
RxPrototype: STX “96” “GamEvent” “CS” EOT
G.26. 0x97: Obtenir les informations comptables du jeu
Cette commande permet d'obtenir les compteurs du jeu servant à la comptabilité.
TxPrototype: STX “97” “IntStat” EOT
RxPrototype: STX “97” “GamStat” “GamEvent” “RetCode” “credit in” “credit out” “bets”
“wins” “handpay” “games” “current credits” “CS” EOT
G.27. 0x98: Obtenir l'information du protocole supporté
Cette commande permet de connaître la version du protocole on-line supporté.
RxPrototype: STX “98” “BPvp.vs.dd” “CS” EOT
Exemple:
STX “98” “BP09.12.00” “CS” EOT
où: vp = version du protocole on-line classe II (version 9 = version 2013)
vs = version supporté (12 dans l'exemple)
dd = indication de tests, une version où dd est différent de 0 n'est pas (encore) approuvé
par les constructeurs
-37-
Version II_V12.1
19
1er décembre 2016
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
-38-
(single quote)
Version II_V12.1
1er décembre 2016
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)
-39-
Version II_V12.1
1er décembre 2016
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)
-40-
Version II_V12.1
20
1er décembre 2016
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 II, au moyen
d'un système informatique approprié.
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 38, 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 13 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.215/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 ordinateurs que les jeux automatiques;
UPS : Uninterruptable Power Supply.
Art. 2.
§ 1er. Tous les établissements de jeux hasard de classe II prévoient un LAN, lequel est
connecté avec un LAN de la Commission des jeux de hasard.
§ 2. Tous les établissements de jeux de hasard de classe II disposent d'un système de
vidéosurveillance.
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 des établissements de jeux de hasard de classe II.
Art. 4. Un serveur central unique relié à tous les clients via le LAN 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. Un système de vidéosurveillance adapté est prévu. Il convient d'informer
correctement le personnel et les joueurs de l'existence et du fonctionnement de ce
système.
-41-
Version II_V12.1
1er décembre 2016
Les enregistrements sont conservés dans un local séparé auquel peuvent uniquement
accéder les membres du personnel désignés, les membres de la Commission des jeux de
hasard et de son secrétariat, ainsi que des personnes externes à la Commission des jeux
de hasard qu'elle désigne nommément.
Les enregistrements, effectués sur un support au choix, doivent être conservés pendant
quatre semaines et mis à la disposition de la Commission des jeux de hasard sur simple
demande de celle-ci.
Lorsque des irrégularités au jeu sont constatées et filmées ou en cas de dérèglement
important du système de vidéosurveillance, la Commission des jeux de hasard en est
informée immédiatement. Elle se prononce sur la procédure à suivre et sur l'utilisation
des enregistrements. Aucun enregistrement ne peut être effacé ou détruit avant sa
décision.
Les enregistrements relatifs au jeu, à l'enregistrement et aux caisses, ont lieu dès
l'ouverture de la salle de jeu jusqu'à la clôture de toutes les opérations et à la fermeture
de la salle de jeu. Les autres enregistrements sont effectués sur une base permanente,
sans interruption.
Art. 6. La Commission des jeux de hasard a la garantie, à l'aide d'un code source et d'un
code objet, que le logiciel qu'elle a approuvé fonctionne réellement.
A cet effet, elle peut à tout moment demander une recompilation afin de vérifier si le
code source officiel a bien été compilé.
Art. 7. Un UPS adapté avec une autonomie de deux heures est prévu pour le serveur
central. Lorsque la connexion entre un jeu automatique et le LAN se coupe ou rencontre
un problème quelconque d'ordre mécanique ou technique qui dure plus de 24 heures, le
jeu est arrêté compte tenu des règles de fonctionnement en matière d'arrêt et de relance
de jeux automatiques.
Lorsque le serveur central est en panne pendant plus de 24 heures, tous les jeux sont
arrêtés.
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 des tests tous les quatre mois.
Art. 8. Toute modification, de quelque nature que ce soit, du système informatique doit
préalablement avoir été approuvée par la Commission des jeux de hasard.
Art. 9. L'accès au serveur central, aux postes de travail et aux programmes doit être
réglé par un système de mots de passe qui est soumis à la Commission des jeux de
hasard avant son introduction.
Le système informatique et le système de vidéosurveillance sont installés dans des
locaux séparés. L'accès est uniquement autorisé après une procédure de contrôle d'accès
qui est soumise à la Commission des jeux de hasard avant son introduction.
Art. 10. Le système informatique est protégé contre les interférences
électromagnétiques et électrostatiques ainsi que contre les ondes radioélectriques.
**** tel que modifié par ..... *****
Art. 11.
§ 1er. La Commission des jeux de hasard rédige un protocole contenant les éléments
suivants :
1. contenu du présent document;
2. définitions et abréviations;
-42-
Version II_V12.1
1er décembre 2016
3.
4.
5.
6.
7.
des conditions techniques relatives au câblage et aux composants passifs du LAN;
des conditions techniques relatives aux composants actifs du LAN;
des conditions techniques relatives aux clients et aux serveurs;
des conditions techniques au local destiné au data-rack;
des conditions techniques relatives à la liaison de données avec la Commission des
jeux de hasard;
8. des conditions supplémentaires relatives au système de vidéosurveillance;
9. des conditions relatives à l’information comptable et financière;
10. des conditions relatives à l’enregistrement;
11. des conditions relatives au contrôle technique;
12. des conditions relatives à la documentation concernant le système informatique et le
système de vidéosurveillance;
13. utilisation des nouvelles technologies de l’information;
14. Conditions générales, ni spécifique, ni liées aux sujets précédents.
15. des normes concernant la nomenclature des fichiers à envoyer;
16. approbation.”
§ 2. Ce protocole est communiqué à tous les titulaires d'une licence de classe II au plus
tard une semaine après son approbation par la Commission des jeux de hasard.
Toute modification du protocole est communiquée aux titulaires d'une licence de classe
II au plus tard une semaine après son approbation par la Commission des jeux de
hasard.
Art. 12. Par dérogation à l'article 2, § 1er, du présent arrêté royal, les établissements de
jeux de hasard de classe II peuvent, pendant deux ans après l'entrée en vigueur du
présent arrêté royal, relier tous leurs clients de l'établissement de jeux de hasard de
classe II au serveur central, d'une manière approuvée au préalable par la Commission
des jeux de hasard. Ce serveur central doit à son tour être relié une fois par semaine au
moins au LAN de la Commission des jeux de hasard.
Art. 13. Le présent arrêté entre en vigueur trois mois après sa publication au Moniteur
belge , à l'exception de l'article 11 qui entre en vigueur le jour de sa publication au
Moniteur belge .
Art. 14. 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.
ALBERT
Par le Roi :
Le Ministre de l'Intérieur,
A. DUQUESNE
Le Ministre des Finances,
D. REYNDERS
Le Ministre de la Justice,
-43-
Version II_V12.1
1er décembre 2016
M. VERWILGHEN
Le Ministre des Entreprises et Participations publiques,
R. DAEMS
Le Ministre de l'Economie,
Ch. PICQUE
Le Ministre de la Santé publique,
J. TAVERNIER
-44-

Protocole II V12.1

Transcription

Documents pareils

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

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

Sujet : La nature fait-elle bien les choses ?

OFFRE DE STAGE: Ingénieur Calculs H/F

MSC Musica - Kaefer Wanner

l`homme dé - Joueurs Info Service

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