CR005 Architecture et contraintes techniques

Date:

03-18 12h-17h

Type:

Réunion

PartiesPrenantes:

ABI, HSI, KWG, MPA, PSO

Lieu:

Paris-ControlIT

Organisateur:

ABI

Rapporteur:

KWG

Presents:

ABI, HSI, KWG, MPA

Objectifs:

Définir l’architecture et revenir sur les fonctions associées à chaque noeud.

Attention

Ce compte rendu est un document de travail et n’est pas contractuel.

  1. ControlIT rappelle l’architecture classique des applications déjà mises en place par leur soin.

  2. Il n’y a aucune raison a priori de changer d’architecture sachant qu’elle fonctionne bien dans différents contextes.

  3. Les matériels sécurité (sas de sécurité, caméras, etc.) sont toujours connectés directement au serveur de contrôle.

  4. Ce serveur permet de gérer en temps réel les matériels en les commandant par leurs drivers

  5. Le serveur d’applications doit être plus ou moins puissant selon le volume de données à gérer et le nombre de transactions à mettre en œuvre.

  6. De tels clients devront pouvoir être gérés avec AirLocksControl.

  7. _

  8. Les vigiles seront équipés de smartphones Huawei pour gérer les incidents.

  9. C’est un grand changement car jusque-là des appareils spécialisés ou des postes fixes étaient utilisés.

  10. Les applis des smartphones des vigiles seront connectées au serveur applicatif via une connexion sécurisée https et un réseau wifi interne sécurisé.

  11. ControlIT mentionne qu’il est possible d’installer des systèmes de brouillage et bien d’autres choses, qui rendent ce réseau à la fois sûr et fiable.

    ../_images/huawei.jpeg

    Fig. 1 : Smartphones des vigiles

  12. Les incidents doivent être localisés (e.g. sas de sécurité, porte, point d’accès et/ou zone) et gardés dans l’historique.

  13. En fonction des cas, et la plupart du temps après s’être rendu sur place, le vigile choisit de prendre en charge un incident ou de le laisser aux autres vigiles.

  14. Lorsqu’un vigile prend un incident, celui change d’état (« nouveau » -> « affecté »). A partir de ce moment c’est lui qui contrôle totalement le sas de sécurité concerné jusqu’à ce qu’il déclare l’incident clos.

  15. Pour régler l’incident le vigile peut neutraliser l’incident : dans ce cas la seconde porte du sas est ouverte et le sas reprend ensuite son fonctionnement automatique.

  16. Il peut aussi ouvrir la première des deux portes du sas de sécurité, puis la fermer dès que la ou les personnes sont sorties. Le sas reprend ensuite son fonctionnement automatique.

  17. Evidemment si nécessaire les vigiles appelleront les services compétents (urgences médicale, police, armée, etc.)

  18. La discussion sur le rôle des vigiles s’est achevée sur la conclusion suivante.

  19. L’IHM des vigiles doit être très ergonomique vu l’utilisation à la fois intensive et rapide attendue.

  20. _

  21. Le poste administrateur (toujours un seul, pour des raisons de sécurité) et les postes gestionnaire de groupe (autant que nécessaire) seront connectés au serveur applicatif par une liaison Ethernet, avec une application WEB.

  22. Il s’agit dans les deux cas de PCs sous Linux Fedora.

  23. _

  24. Les gestionnaires de groupe gèrent non seulement les personnes et leurs inscriptions à des groupes, mais aussi les problèmes liés à la perte d’un badge.

  25. Lorsqu’un badge est perdu, volé (y compris via une agression), la personne est tenue d’en informer immédiatement son gestionnaire de groupe.

  26. Un badge n’est associé qu’à une seule personne à la fois et une personne ne peut posséder qu’un badge (pour un site) à un moment donné.

  27. Les personnes sont connus au minimum par leur nom et leur prénom et un numéro d’identité national (NIN).

  28. Le NIN utilisé dépend des personnes et des pays considérés.

  29. Ce peut être le numéro de passeport, le numéro de carte d’identité ou tout autre document selon le pays.

  30. Un mail et deux numéros de téléphone peuvent également être renseignés lors de l’enregistrement.

  31. A chaque fois qu’un badge est donné à quelqu’un, qu’il est annulé suite à une perte ou un vol, l’opération doit être enregistrée dans l’historique.

  32. Toutes ces opérations sont effectuées par les gestionnaires de groupe.

  33. Lorsqu’un personne appartient à plusieurs groupes, et si ces groupes sont gérés par différents gestionnaires de groupe, n’importe quel de ces gestionnaires de groupe peut enregistrer la perte du badge.

  34. Finalement, le serveur applicatif est le seul élément de AirLocksControl a être connecté à internet via tcp-ip.

  35. C’est lui qui gèrera les web-services mentionnés auparavant.

  36. _

  37. Il est fait état d’un démarrage éminent de la phase de collecte des exigences.

  38. Les spécifications UML seront faites par le groupe M1 de la MIAGE de Grenoble à partir des comptes rendus de réunions réalisés jusque-là.

  39. Les personnels de la société ControlIT ne seront pas disponibles dans les semaines qui viennent.

  40. Il risque d’en être de même des personnels de MIAGE Grenoble ayant participé à ces réunions.