CR002 Réunion iPark pour l’hôpital Michallon

Date:

02-17 15h-18h

Type:

Réunion

Lieu:

Grenoble - Park Hôtel

PartiesPrenantes:

ABI, JDR, PSO, AGO

Organisateur:

ABI

Rapporteur:

KWG

Presents:

ABI, JDR, PSO, AGO,

Objectifs:

CHU

Attention

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

Nouvel intervenant, directeur des services généraux du CHUGA - Eliezer LAEMMEL (ELL)

  1. Grâce aux contacts d’AGO, une rencontre sur le projet du CHUGA (Centre hospitalier universitaire Grenoble-Alpes) a été organisée opportunément.

  2. Le CHUGA désire s’équiper d’un nouveau système de contrôle d’accès de son parking de l’hôpital Michallon à l’occasion de sa rénovation énérgétique.

  3. Il comprend à la fois des parties accessibles au personnel et d’autres au public en accès payant.

  4. Il s’agit donc d’un prospect chaud pour iPark.

  5. Les différents matériels ont été choisis pour répondre aux fonctions attendues.

  6. Il est rappelé qu’une présentation de ces matériels aura lieu à Berlin - Gate-IS.

  7. Un premier plan des parkings a été établi à partir des documents des architectes du CHUGA.

  8. La figure 1 montre le plan du parking public qui est en accès payant, avec un point d’accès au nord et un point de sortie au sud.

    ../_images/hoteldept1.png

    Fig. 1 : Parking Michallon - Niveau 1 - Accès public payant

  9. La figure 2 montre le plan des niveaux supérieurs, dont l’accès est dédié au personnel du CHUGA.
    ../_images/hoteldept2.png

    Fig. 2 : Parking Michallon - Niveau supérieurs - Accès personnels

  10. Les capteurs de passage dans le sol sont utilisés pour détecter la sortie ou l’entrée d’un véhicule avant de refermer la barrière

  11. Chaque niveau supérieur est accessible ou non à un membre du personnel en fonction de leur appartenance à un groupe.

  12. Ces groupes de personnes doivent pouvoir être définis dans iPark.

  13. On estime qu’il y aura environ 40 groupes pour les 9 7000 employés du CHUGA.

  14. Même si différents groupes de personnels ont été identifiés, d’autres pourraient apparaître.

  15. Chaque personnel devra donner la numéro de plaque d’immatriculation de son véhicule pour avoir accès au parking. iPark enregistrera aussi leurs nom, prénoms, statut ainsi que leur service.

  16. Un superviseur unique par parking peut créer des administrateurs pour gérer des groupes. Il leur donne des droits sur la gestion d’un ou plusieurs niveaux de parking.

  17. Chaque groupe d’un parking sera alors créé et géré par un administrateur et pas par le superviseur.

  18. Par exemple l’administrateur des personnels des urgences peut ajouter un personnel infirmier dans iPark en donnant son numéro de plaque, l’ajouter au groupe « Infirmer Urgence Nuit ». et définir les niveaux auxquelles le groupe « Infirmer Urgence Nuit » a accès et à quels moments.

  19. Un autre administrateur s’occupe des personnels de restauration du CHUGA, etc.

  20. Bien entendu les administrateurs de groupe ne pourront pas donner à un groupe l’accès à des niveaux dont il n’est pas chargé.

  21. Le nombre de personnels par groupe va de 1 à 100 environ.

  22. Les autorisations d’un groupe définissent les niveaux auxquels ses membres ont accès et à quelles périodes.

  23. Par exemple les infirmiers de nuit des urgences ont besoin d’un accès de 20h à 6h et ont accès au parking du niveau 6, tous les jours de la semaine.

  24. Les personnels les médecins de nuit des urgences ont eux aussi besoin d’un accès de 20h à 6h et ont accès au parking du niveau 5, tous les jours de la semaine.

  25. Les personnels des RH centraux n’ont accès qu’aux horaires de bureau au parking du niveau 4, du lundi au vendredi.

  26. On pourra imaginer d’utiliser dans le futur des périodes d’accès standardisés pour les ré-utiliser avec plusieurs groupes.

  27. Dans tous les cas pour une période un groupe peut accéder toujours aux mêmes zones de parking (cf. CR003-Fig1_ et CR003-Fig2_).

  28. Une autorisation définit ainsi la zone auquel un groupe peut accéder sur une période.

  29. Par exemple, en reprenant l’exemple donné par ELL du 7 décembre, on doit pouvoir définir deux autorisations comme présenté dans le tableau ci-dessous.

    Tab. 1 : Exemple ELL 07-12

    Groupe

    Période

    Zone de parking

    Technique

    LMMJVSx 08:00-20:00

    N2

    RH centraux

    LMMJVxx 9:00-18:00

    N4

  30. Les autorisations définies de cette façon devraient aussi convenir a priori pour les autres parkings gérés par iPark.

  31. Il s’agit en effet d’une représentation générale et sans doute satisfaisante.

  32. Des gardiens sont chargé de gérer les incidents à l’entrée ou à la sortie d’un niveau.

  33. Ils peuvent depuis leur tablette débloquer l’entrée ou la sortie d’un conducteur bloqué suite à un incident.

  34. Si un véhicule n’est pas autorisé à entrer ou sortir (ticket non reconnu, plaque d’immatriculation inconnue, appel du conducteur qui a perdu son ticket, …) un incident est envoyé par iPark aux gardiens du parking.

  35. Le véhicule est alors bloqué dans la zone et doit attendre qu’un gardien le débloque.

  36. L’appli iPark de la tablette du gardien le met en contact audio avec le conducteur du véhicule et lui affiche la caméra associée à la borne d’accès concernée.

  37. Le gardien peut alors, suivant les cas, émettre un ticket d’entrée sur la borne, enregistrer l’accès ou la sortie d’un personnel, lever ou baisser une barrière.

  38. Par exemple, en cas de plaque d’immatriculation non reconnue en entrée d’une zone d’accès restreint, après avoir discuté de la raison du problème, le gardien pourra laisser entrer le conducteur et enregistrer son entrée; ou en cas de problème de ticket à la sortie, générer un ticket forfaitaire sur la borne.

  39. Un élément important concerne les règles à appliquer en cas d’incendie dans une zone.

  40. Les barrières des points de sortie doivent être ouvertes automatiquement.

  41. Il faut donc prendre en compte les systèmes à incendie et les interfacer avec iPark.

  42. La question de l’affichage du nombre de places disponibles par niveaux n’est été tranchée, rendre public cette donnée ne faisant pas l’unanimité.

  43. La conservation de l’historique des événements (accès et incident) étant nécessaire dans le contexte sécuritaire actuel, cette fonctionnalité devra être intégrée à iPark.

  44. Un web service permettra à des systèmes externes (e.g. systèmes RH / de contrôle de présence) d’importer les événements d’accès de iPark (horaire d’entrée et sortie pour chaque niveau).

  45. Ce web service devra être sécurisé pour des aspects de confidentialité.

  46. En conclusion, la réunion sur rencontre sur le projet de l’hôpital Michallon a été très instructive.

  47. Il correspond bien aux fonctionnalités de base d’iPark.

  48. AccesIT confirme son intérêt de développer une version d’iPark pour ce parking.

  49. Cette version sera la première développée et sa conception sera faite au plus vite par MIAGE Grenoble.

  50. La prochaine réunion se fera à Berlin dans les locaux de Z-Park.