Modèles et Architectures
Modèle technique
Au risque de défoncer des portes ouvertes, je propose 2 architectures techniques :
- centralisée
- décentralisée
Modèle centralisée
Des antennes passives sont disposés et reliées à un concentrateur.
Celui ci sera en charge de l'alimentation et de l’échange de données avec le serveur.
On peut représenter cette architecture sous cette forme :
L'architecture centralisée est celle proposée par videopokertable.
Des antennes passives sont disposés et reliées à un concentrateur.
Celui ci sera en charge de l'alimentation et de l’échange de données avec le serveur.
Voici quelques photos en exemple :
Il s'agit de la préparation de la table avec les éléments encastrés.
On voit bien le passage des câbles en étoiles, synonymes d'une architecture centralisée.
L'ensemble des cartes convergent vers le module ci dessous. On distingue les 13 soudures et une alimentation unique, ainsi qu'un module wifi ou bluetooth
Modèle décentralisée
L'architecture décentralisée se caractérise par la mise en œuvre de module autonome, aussi bien dans l’échange de données que dans la gestion de l'énergie.
Le schéma ci dessous présente une vue possible
Il n'y a actuellement pas de solution utilisant cette architecture
Architecture mixte
Le monde n'est pas manichéen et entre ces 2 propositions, on peut rajouter un critère supplémentaire.
Du coup, nous aurons 4 solutions techniques à étudier.
Avantages et inconvénients
Le modèle centralisée :
- permet de mieux gérer l'alimentation
- d' utiliser le Bluetooth dans la communication entre le concentrateur et le serveur
mais :
- nécessite une intégration à la table
- pose des problèmes de maintenance en cas de panne d'un des équipements
Le modèle décentralisée :
- permet la création de module autonome qui peuvent s’intégrer plus facilement à une table existante
- permet de poser la solution sur ou sous une table en fonction des contraintes liées à la RFID
mais
- n'autorise que le Wifi pour la connexion entre les équipements, car le Bluetooth est limité à 2 points.
- nécessite de recharger chaque élément avant les évènements
- crée une limite dans l'autonomie électrique
Le modèle câblée :
- sécurise les échanges de données en limitant les opérations de piratage
- nécessite un gros paquet de câble, ce qui n'en fait pas une solution facile à poser et à cacher
- garanti un débit
Le modèle sans fils :
- facilite son déploiement et sa maintenance
mais
-a l'inverse du câblé, elle est plus exposée au piratage
- attentions aux effets sur la santé du à une longue exposition ( exemple maux de tête)
Architecture technique
L'architecture retenu est une architecture 3-tiers, adaptée à l’échange de données en TCP-IP
Chaque table est composé de 10 modules SmartPlayer relié en Wifi à la SmartConsole.
Chaque SmartPlayer est un serveur Web
Le SmartBoard est relié à la SmartConsole, c'est aussi un serveur Web.
Les equipements se connecte au Hotspot qui est en partage de connexion et qui devient le serveur DNS
Ainsi les SmartPlayers et la SmartConsole peuvent communiquer.
Ensuite la SmarConsole peut dialoguer avec le SmartServer via le HotSpot
Chaque tournoi dispose de son propre plan d'adressage local 192.168.xxx.xxx
La SmartConsole centrale les informations.
Sur demande, elle envoie les moves au SmartServer pour diffusion, en utilisant le téléphone en mode AP paramétré pour le tournoi.
Si plus de 10 tables par tournoi, il faut 1 téléphone et 1 SmartConsole supplémentaire par tranche de 10 tables.
Pour des raisons de code, je limite à 3 HotSpot par tournoi.
Vue Pour 1 tournoi
Vue pour les plusieurs tournois
Architecture fonctionnelle
A l'issu de l’état des lieux, j'ai défini une architecture fonctionnelle ci contre.
A vous de cliquer sur chaque domaine pour accéder aux détails
Décompte des modules
je ne savais pas ou mettre cette partie, alors en attendant de trouver mieux c'est ici.
En effet il s'agit a la fois d'une contrainte technique et d'une contrainte fonctionnelle.
Reprenons l'image du passage de câble et comptons sur nos doigts :
il y a 5 modules raccordées de chaque cotés de la tables, 2 modules pour les joueurs assis au au centre de la table ou le croupier et une barre pour le board.
Conclusion : il y a 2 modules en plus par rapport au nombre de joueur.
Après une petite visite sur le site de videopokertable, ces 2 modules situées de part et d'autre du board sont appelés "Muck"
C'est intéressant car cela soulève une limitation technique que je n'avais pas identifié auparavant et que j'ai retrouvé dans le code informatique des solutions RFID DIY.
Chaque tag RFID n'est lu qu'une fois. Autrement dit, si vous laissez votre tag RFID devant une antenne, cela ne génère pas de lecture en boucle.
Il me semble d'une coupure de l'alimentation des antennes selon un certain cycle pourrait créer une fausse boucle de relecture. il faut juste dimensionner ce cycle de manière satisfaisante et regarder les effets sur l'usure du matériel et la consommation électrique.
L'autre fonction ( on n'est plus dans le technique) est probablement lié à l'interface utilisateur. En effet comment indiquer au serveur qu'un joueur s'est couché ou qu'une main est terminée. Si celui ci jette ces cartes, le module du joueur ne réagira pas. En plaçant ces cartes sur les modules de muck, le serveur est capable de mettre à jour rapidement la situation de jeu.
L'inconvénient de ce système est la manipulation que cela nécessite.
La gestion des jetons
Ceci est plus un aparté qu'un article de fond.
La gestion des jetons est probablement le module technique et fonctionnelle le plus complexe à mettre en œuvre.
Meme la solution VideopokerTable ne propose qu'un suivi des mises et des stacks qu'en postprod.