CR003 Matériels de contrôle d’accès

Date:

03-15 7h-17h

Type:

Réunion

PartiesPrenantes:

KWG, CMS, YBI, MPA, ZSH

Lieu:

Berlin chez Z-Park

Organisateur:

KWG

Rapporteur:

KWG

Presents:

KWG, CMS, YBI, MPA, ZSH

Objectifs:

Architecture et discussions sur les fonctionnalités gardien

Attention

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

Nouvelles parties prenantes :

• Clarissa Maris (CMS) - Z-Park, Berlin

• Yohav El Benali (YBI) - Z-Park, Berlin

1. La réunion a eu lieu dans les locaux de Z-Park.

2. Z-Park développe et commercialise du matériel de contrôle d’accès de parkings à la pointe de l’innovation technologique

3. Z-Park voudrait développer son marché à l’international et souhaite donc intégrer le consortium pour participer à l’élaboration de iPark.

4. Il est entendu que Z-Park fournira ces matériels et pour chaque modèle un driver logiciel pour l’intégrer à iPark.

5. Par contre un problème est vite apparu pendant la réunion.

6. Des dépôts de brevet sont en cours pour plusieurs matériels très innovants et il sera impossible de les utiliser pour les tests avant au moins deux mois, et cela pour des problèmes de confidentialité.

7. La direction ne souhaite prendre aucun risque de fuites et même en interne seuls certains employés (e.g. YBI) ont une connaissance précise de ces matériels tel qu’ils seront vendus une fois les brevets déposés dans quelques mois.

8. Après quelques échanges et discussions animées, il est apparu que ce ne devrait cependant pas être un problème pour iPark.

9. Z-Park fournira des simulateurs pour que les tests puissent commencer dès maintenant.

10. Toutes les parties logicielles sur le serveur applicatif pourront être réalisées en amont grâce à la simulation de ces matériels pilotées par les drivers à installer sur le serveur de contrôle.

11. AccessIT, qui travaille depuis longtemps avec Z-Park, est confiant dans cette démarche.

12. L’API des drivers de matériel est fournie dès maintenant par Z-Park (en annexe de ce compte-rendu)

13. L’utilisation d’une spécification UML a été soulignée comme un point essentiel dans ce contexte tendu.

14. Il a été convenu que MIAGE Grenoble fournira rapidement des scénarios qui serviront à écrire les tests de la version pour l’hôpital Michallon.

15. Il s’agit bien entendu de tester tous les scénarios de passage : sans incident ou avec incident générant des alarmes envoyées aux gardiens.

16. Les matériels principaux fournis par Z-Park sont des barrières, des bornes à tickets, des automates de paiement, des capteurs de passage, des caméra de surveillance et des lecteurs de plaque minéralogique

17. Un exemple de fonctionnement basique est montré sur ce lien (téléchargement ici)

18. Les barrières levantes peuvent avoir des lisses de différentes formes et tailles mais sont toutes contrôlables par le même driver.

19. Les bornes à tickets ressembleront par certains aspects à la borne « ZEAG-LE » de HubParking présenté dans la figure 1 ci-dessous

    

    Fig. 1 - « borne ZEAG-LE » par HubParking

20. La borne « ZEAG-LE » n’est là qu’à titre d’illustration ; les bornes Z-Park ont de nombreuses différences.

21. Le matériel est extrêmement performant (à condition que les contrôles logiciels suivent).

22. La borne peut émettre (en entrée) et lire (en sortie) des tickets de stationnement utilisant des QR codes qui ressemblent par certains aspects à celui à gauche sur la figure 2 ci-dessous

    

    Fig. 2 - Tickets Michallon 2024

23. Les tickets sont émis en touchant un bouton d’émission de ticket.

24. Les bornes possèdent un afficheur de texte et un bouton d’appel pour les conducteurs bloqués en sortie ou dont l’accès est refusé en entrée.

25. Ce bouton met en marche le micro et les haut-parleurs de la borne pour la communication avec les gardiens ainsi que l’affichage de la vidéo.

26. Les capteurs de passage s’installent sous la chaussée. Il sont capables, sur commande, de détecter le passage d’un véhicule (voiture ou moto)

27. Ils permettent non seulement de comptabiliser les véhicules présents dans une zone, mais aussi, couplés avec une seconde barrière aval, d’éviter le piggypacking en sortie de zone payante

28. Les caméra de surveillance et les lecteurs de plaque sont connectés de la même façon que les capteurs de passage.

29. En fait tous les matériels sont entièrement contrôlés par les drivers fournis par Z-Park (API fournie en annexe).

30. Ces drivers seront installés sur le serveur de contrôle.

31. Chaque matériel est connecté au panneau de brassage du serveur de contrôle par une connexion RFC 813

32. Une fois de plus Z-Park propose le matériel pour gérer les accès, mais leurs fonctions devront être commandées depuis le serveur de contrôle via les drivers fournis.

33. Le paiement dans les zones publiques s’effectue sur les bornes de sortie. Le conducteur introduit son ticket. La borne affiche le montant à payer et demande au conducteur de passer sa carte bancaire dans le lecteur de CB (ou avec un passage sans contact). Le conducteur obtient en retour son ticket après impression du montant du parking et de la date de sortie pour servir de facture et un justificatif de paiement CB.

34. Ce justificatif CB est similaire par certains aspects à celui à droite sur la figure 2 (voir plus haut)

35. Pour iPark, la vérification du paiement ou des autorisations après le lecture de plaque devra toujours être faite en moins de 10 secondes.

36. Sachant que l’on envisage d’utiliser ces matériels dans des parking avec des heures de pointes à plus de 400 entrées ou sorties par heure, un soin tout particulier devra être apporté à cet aspect.

37. Tous les matériels doivent être reliés au serveur de contrôle du site via des câbles RJ12 et utiliser le protocole « RFC 873 »

38. Le serveur de contrôle doit être installé dans une salle sécurisée proche des matériels d’accès du site.

39. Il s’agit d’un matériel spécialisé quasi temps réel auquel les matériels d’accès sont connectés chacun par un câble sur un panneau de brassage (jusqu’à des centaines sur certains sites).

40. Ce serveur de contrôle devra être connecté au serveur applicatif via une liaison TCP/IP sécurisée.

41. En conclusion de cette (longue) réunion, il apparaît clairement que les technologies innovantes proposées par Z-Park en font un partenaire idéal.

42. De plus, certains matériels n’étant pas disponibles à ce jour, il est essentiel de préparer les scénarios à prendre en compte et de les spécifier de manière rigoureuse.

43. Z-Park fournira des simulateurs matériels pilotables par les driver fournis.

44. Dans un premier temps des tests seront ainsi effectués à partir des scénarios fournis par MIAGE Grenoble.

45. Une réunion est prévue (03-18) pour discuter des points non abordés jusque-là et notamment de l’architecture de déploiement.