Tous les articles par Dominique Beuscart

CONFIGURATION ‘GDB_Services’

2.1 Notice

[Service]

;Nom= Manager,Archivage,Replica,Surveyor,Export,Mail
; ATTENTION : mettre «  » pour ignorer ce service.
;Appli= Nom de l’exécutable pour les applications avec mode DEBUG
; Appli= » » pour son utilisation en service
; Defaut= » »
;Libelle= Libellé du COMBO de l’appli de supervision des services GDB Services
;Desc= Description du service
;Serveur= Nom ou adresse IP de la machine ou s’exécute le service
; Si Serveur= » » utilise la machine locale par défaut
;Option Argument lorsqu’il s’agit d’un exécutable
; /DEBUG /AUTOSTART
;On= On=1 Valide la gestion de ce service ou de cette application par ‘GDB_Services’
; (Rien à voir avec activation ou mise en service)
;AppliType= TypeAppli=1 lorsque l’utilisation est en application Windows (# service)
; Defaut=0 pour service

;Nombre de services à gérer limité à 7 services.

2.2 Exemple

[Service_1]
Nom=Manager
Libelle=Manag
Desc=Moteur de gestion des évènements du contrôle d’accès et de la détection intrusion
Serveur=VERCINGETORIX
AppliExe=GDB_Manager64.exe
AppliRep=C:\AegisHF_Server_64
ServiceExe=GDB_Manager64.exe
ServiceRep=C:\AegisHF_Services
Option=/DEBUG /AUTOSTART
AppliType=1
On=1

2.3 Détails

Nom : nom mnémonique du service, ce nom sera complété pour faire le nom exacte du service. ‘Manager’ donnera ‘GDB_Manager’ ou ‘GDB_Manager64’ suivant la version de l’OS.

Libellé : nom qui apparaitra dans les boutons, il est raisonnable de ne pas dépasser 6 caractères.

Desc : description du service telle qu’elle apparaitra dans les fenêtres de gestion des services WINDOWS.

Serveur : nom du serveur sur lequel tourne le service (important si l’exécutable de maintenance et contrôle ‘GDB_Services’ ne se trouve pas sur le même poste).

AppliExe : nom de l’exécutable lorsque le service doit être lancé en mode DEBUG (avec fenêtre de maintenance). Actuellement seul le service ‘Manager’ dispose d’un mode maintenance.

AppliRep ; répertoire ou est rangé AppliExe

ServiceExe : nom de l’exécutable du service.

ServiceRep : répertoire ou est rangé ServiceExe

Option : liste des arguments à passer au moment du lancement

AppliType : 1 l’application sera lancée en mode DEBUG, 0 en tant que service.

On : 1 l’application ou le service sera sous le contrôle de l’automate de surveillance ‘GDB_Services’, 0 service à gérer manuellement comme tout autre service WINDOW.

NOTA : certains de ces paramètres pourront être modifiés (avec mise à jour dans ce fichier INI) :

  • AppliType
  • On

Etats d’une entrée / sortie

Dans la centrale, les états d’une entrée et de la sortie de même rang (même n° physique) sont visualisables sous forme de 8 octets hexadécimaux.

Octet 1

6 bits d’état + 2 bits de la valeur analogique (poids fort)

  • $01 : Bit 9 de la valeur analogique (10 bits)
  • $02 : Bit 10 de la valeur analogique (10 bits)
  • $04 : EL : Etat logique du capteur (EL) après filtrage, masquage, fonction d’automatisme
  • $08 : EM : Alarme masquée
  • $10 : EP : Etat physique du capteur (EP)
  • $20 : Fil du capteur coupé
  • $40 : Auto protection du capteur
  • $80 : Fil du capteur shunté

NOTA : EM est force lorsque cette entree est utilisée par un automatisme.

Octet 2

8 bits (poids faible) à ajouter aux 2 bits de l’octet précédent pour définir la valeur analogique de l’entrée sur 10 bits (1.024 points). Les capteurs sont généralement alimentés par la source interne de 4.096 volts.

Visualisation

Les octets 1 et 2 sont visualisables par l’application Configuration des objets onglet Configuration avec sélecteur sur entrée:

Octet 3

  • $01 : le périphérique sur lequel est connecté le capteur est joignable
  • $02 : temporisation ALT en cours
  • $04 : temporisation FAL en cours
  • $08 : le capteur est correctement configuré
  • $10 : l’alarme capteur déclenché a été émise dans la pile des évènements
  • $20 : l’alarme capteur fil coupé a été émise dans la pile des évènements
  • $40 : l’alarme autoprotection du capteur a été émise dans la pile des évènements
  • $80 l’alarme fil shunté du capteur a été émise dans la pile des évènements

L’ octet 3 est visualisable par l’application Configuration des objets onglet Alarme :

Octet 4

8 bits définissant l’état de la sortie

  • $01 : libre
  • $02 : Sortie forcée à ON par la supervision
  • $04 : Sortie forcée à OFF par la supervision
  • $08 : La sortie est correctement configurée
  • $10 : Etat physique de la sortie
  • $20 : Etat logique de la sortie
  • $40 : Temporisation FLT en cours
  • $80 : Temporisation BOU en cours

L’ octet 4 est visualisable par l’application Configuration des objets onglet Configuration avec sélecteur sur sortie :

Octet 5 et 6

Temporisation sur 16 bits en cours (entrée)

Octet 7 et 8

Temporisation sur 16 bits en cours ( sortie)

SNMP – Format des traps

Le format des traps est décrit dans la M.I.B. sous la syntaxe ‘ctrleEvent….’.

Parmi tous les O.I.D. définis, certains peuvent être exploités plus finement que leur description de base.

ctrleEventNumber

OID 1.3.6.1.4.1.29024.1.9.1 = « Nombre d’enregistrements dans la table des evenements. »

Ce nombre est défini par défaut à 10 (consulter Oserys pour une valeur supérieure)

ATTENTION : sur coupure secteur de la centrale, ces évènements sont perdus. Pour retrouver ces évènements, utiliser la fonctionnalité ‘évènements en flash’ de la centrale, compromis à faire entre la table des badges et la table des évènements.

ctrleEventDescr

OID 1.3.6.1.4.1.29024.1.9.3.1.4 = « Description de l’evenement. »

Ce texte qui décrit l’évènement est personnalisable au gré du configurateur de l’application suivant le principe :

  • La centrale émet l’évènement avec un n° d’évènement puis pour les évènements 000 et 001 un n° de sous-évènement appelé n° d’alarme, se reporter au fichier EXCEL ‘190919_liste evenements_MAJ 801‘.
  • La description se constitue en référant ces deux n° à un texte formaté disponible dans le fichier descriptions-traps, fichier à télécharger dans la centrale (à l’aide du protocole FTP par exemple). Ce texte ne doit comporter aucun des caractères suivants : (,),[,],{,}, ni aucun accent.
  • La description est ensuite complétée par la couche IP de la centrale :
    • Du nom du local entre accolades,
    • l’UUID de la centrale entre crochets,
    • le nom du porteur du badge sur 8 caractères (si badge) ou les 8 octets définissant les états d’une entrée/sortie.

Exemple :

Passage LOCAUX TECHNIQUES OK suite a une demande par badge {LOCAL_B33 } [01CF5113] (Bdom_M16)

Apparition alarme entree Radar bivolumetrique {LOCAL_B33 PERIPH 1} [01CF5113] (E1 7D E9 00 00 00 00 00)

A des fins de DEBUG, cette description est visualisable avec l’application  SNMP Trap Browser, mode administrateur, bouton trace, sélection description.


Lecteur en code seul

Saisie du code

Manipulation sur le lecteur

  • Code normal correct : séquence d’acceptation puis VERT fixe tant que la commande d’ouverture est active.
  • Code sous-contrainte avec passage : séquence d’acceptation puis VERT fixe tant que la commande d’ouverture est active avec génération d’une alarme de niveau prioritaire + envoi TRAP passage et TRAP alarme.
  • Code sous-contrainte sans passage : Bip VERT + buzzer une fois sans lancement de l’automatisme avec génération d’une alarme de niveau prioritaire + envoi TRAP alarme.
  • Code inconnu : séquence rejet sans TRAP alarme + incrémentation code erroné.
  • Code inconnu (n fois) : séquence rejet et envoi TRAP alarme et verrouillage du clavier pendant le ‘Temps pour revalider un badge’ onglet Configuration de l’application passage. Disparition de la signalisation lumineuse des touches.
  • Code inconnu immédiat (1 fois) : après Code inconnu (n fois), séquence rejet sans envoi de TRAP.
  • Code valide immédiat : après Code inconnu (n fois), séquence rejet sans envoi de TRAP.
  • Chaque appui sur une touche relance le temps de clavier de 5 secondes.
  • A la fin de la tempo ‘Temps pour revalider un badge’, retour à la normal avec ré-apparition de la signalisation lumineuse des touches.
  • Le nombre de codes successifs incorrects est configurable par ‘Clavier NB’ onglet Configuration de l’application Ctrl.

Configuration

Lecteur en badge + code

1. Manipulation opérateur

  • Badge autorisé : un bip d’acceptation puis un clignotement rapide VERT le temps de saisie du code à 4 ou 8 digits, chaque appui sur une touche relance le temps de clavier de 5 secondes. Code normal correct : séquence d’acceptation puis VERT fixe tant que la commande d’ouverture est active + envoi TRAP passage.
  • Code non valide : séquence rejet + incrémentation code erronée.
  • Code sous-contrainte avec passage : séquence d’acceptation puis VERT fixe tant que la commande d’ouverture est active avec génération d’une alarme de niveau prioritaire + envoi TRAP passage et TRAP alarme.
  • Code sous-contrainte sans passage : Bip VERT + buzzer une fois, sans lancement de l’automatisme avec génération d’une alarme de niveau prioritaire + envoi TRAP alarme.
  • Code inconnu : séquence rejet sans alarme + incrémentation code erroné.
  • Code inconnu (n fois) : séquence rejet et envoi TRAP alarme et verrouillage du clavier pendant le ‘Temps pour revalider un badge’ onglet Configuration de l’application « Passages64 ». Le nombre de codes successifs incorrects est configurable par ‘Clavier NB’ onglet Configuration de l’application « Ctrl64 ». Le badge associé est rendu ‘invalide temporairement’ sur la centrale, la répercussion sur les autres centrales dépend de la configuration du serveur.
  • Voir revalidation d’un badge invalide temporairement.
  • Badge rejeté : séquence rejet + envoi d’un TRAP avec la signification du rejet (24 types de rejet possible).

2. Configuration du passage

L’automatisme utilise le clavier ou non

Ouverture ou non de la porte après inhibition de la zone

Plage horaire lecteur seul sans clavier

Lecteur en badge seul

1. Manipulation opérateur

  • Badge autorisé : séquence d’acceptation puis VERT fixe jusqu’à l’ouverture de la porte.
  • Badge rejeté :  séquence rejet + envoi TRAP.

2. Configuration du passage

L’automatisme utilise le clavier ou non.

Ouverture ou non de la porte après inhibition de la zone.

Plage horaire lecteur seul sans le clavier.


Invalidité temporaire

1. Cause d’invalidation temporaire d’un badge

Rendre un badge invalide peut être provoqué :

  • A l’initiative de l’opérateur dans « AegisCS »
  • A l’initiative de la centrale elle-même suite à « n » codes erronés.

Le nombre « n » est configurable par l’automatisme de passage dans l’application « CTRLE64 », onglet « Configuration », « Clavier nbre ».

Temps RAZ code erroné : A la fin de la tempo, remet le compteur de code erroné à 0. Cette remise à zéro ne revalide pas les badges invalidés précédemment sur codes erronés.

Temps avant réactivation : Période permettant de revalider un badge invalidé à l’aide d’un badge valide. Paramétrable dans l’application « Passages64 », onglet « Configuration », « Temps pour revalider un badge ».

Nota : Si Temps avant réactivation est = 0, il n’est pas possible de revalider un badge avec l’aide d’un badge valide. La revalidation ne pourra être effectuée qu’avec l’application AegisCS.

2. Revalidation d’un badge (à l’aide d’un deuxième badge valide)

Badge « 1 » + code non valide : Séquence rejet + incrémentation code erroné sans émission d’un TRAP.

Badge « 1 » + code non valide « n« fois : Séquence rejet + émission d’un TRAP alarme + Badge « 1 » invalidé temporairement + lancement de la temporisation « Temps RAZ code erroné ».

Pour revalider le badge « 1 », présentez le badge invalide devant le lecteur : Séquence rejet.

Badge « 2 » immédiat (avant fin de la tempo « Temps avant réactivation ») + code valide : Séquence acceptation + RAZ compteur code erroné + revalidation immédiate du badge « 1« .

Nota : Pour revalider un badge après la fin de la tempo « Temps avant réactivation », présenter à nouveau le badge « 1 » et reprendre la procédure ci-dessus.

Badge « 2 » immédiat (avant fin de la tempo « Temps avant réactivation ») + code non valide : Séquence rejet + émission d’un TRAP alarme + incrémentation compteur code erroné. Si le nombre de code non valide (Badge « 1 » + badge « 2« ) atteins la valeur « n« ,  invalidation du badge « 2« .

Badge « 2 » (après Temps RAZ code erroné) + code non valide : Séquence rejet + incrémentation code erroné sans Emission d’un TRAP.

Badge « 2 » (après Temps RAZ code erroné) + code non valide « n » fois : Séquence rejet + émission d’un TRAP alarme + invalidation du badge « 2« .

Badge « 2 » (après Temps RAZ code erroné) + code valide : Séquence acceptation + lancement automatisme + émission TRAP passage.

Voir Logiciel / Configuration / Configuration des passages / Onglet configuration

3. Tests de validation (application lecteur) :

Test A : Reset tempo code erroné

Badge « 1 » : Présentation avec code erroné une seule fois. Compteur code erroné = 1, la tempo TERR est lancée avec « $80 + Temps RAZ code erroné ».

Le compteur code erroné (et sa tempo associée) s’annule :

  • A la fin de la tempo ,
  • Sur présentation du Badge « 1 »  avec un code accepté,
  • Sur présentation du Badge « 2 »  avec un code accepté.
Test B : Invalidation d’un badge

Badge « 1 » : Présentation avec code erroné. A la ‘n+1’ présentation, alarme « Badge invalide temporairement ». Toute nouvelle présentation relance cette alarme.

Test C : Revalidation d’un badge

Manipulation possible si la tempo de réactivation est suffisamment longue pour le permettre.

Badge « 1 » : Présentation du badge précédemment rendu invalide temporairement, Alarme « Badge invalide temporairement ».

Badge « 2 » : Présentation d’un nouveau badge valide avec code valide dans le temps inférieur à TINVAL, aucun message distinctif pour le Badge « 1« .

Badge « 1 » : Le badge a retrouvé toutes ses fonctionnalités.

4. Tests de validation (application digicode) :

Cette application ne dispose pas de badge, seul la fonction digicode est utilisée. Dans ce cas, il est préférable de configurer un nombre de digits supérieur à 4.

Test A : Reset tempo code erroné

Frappe d’un code erroné une seule fois. Compteur code erroné = 1, la tempo TERR est lancée avec « $80 + Temps RAZ code erroné ».

Le compteur code erroné (et sa tempo associée) s’annule :

  • A la fin de la tempo ,
  • A la remise sous tension de la centrale,
  • Sur frappe d’un code accepté.
Test B : Verrouillage du lecteur

Après frappe de ‘n’ codes erronés consécutifs le clavier est verrouillé avec le message ‘CLAVIER VERROUILLE’ (Cas des lecteurs LCTE ou STID avec écran tactile).

Le clavier redevient actif :

  • A la fin de la tempo,
  • A la remise sous tension de la centrale,
  • Par une télécommande sécurisée de la supervision.

Conditions de rejet d’un badge

Séquence rejet : 3 bip ROUGE consécutif + buzzer 300 msec.

24 flags permettent de définir la raison du rejet d’un badge ou d’un code. Ces flags sont cumulables.

1. Définition donné par la MIB

— 1.3.6.1.4.1.29024.1.9.3.1.10
ctrleEventRejectcond OBJECT-TYPE
SYNTAX Integer32 {

  1. passageNonAutorise(1),
  2. plageHoraireNonValide(2),
  3. horsDateDeValidite(3),
  4. mauvaiseVersionBadge(4),
  5. antiPassback(5),
  6. situationDeCrise(6),
  7. badgeReEntrant(7),
  8. inconnuDuLotDeBadge(8),
  9. codeClavierErrone(9),
  10. codeClavierSousCotrainte(10),
  11. trousseauDeCleIndisponible(11),
  12. listeRouge(12),
  13. dateDeValidite(13),
  14. invalideTemporairement(14),
  15. passageBloque(15),
  16. plageHoraireNonAutoriseAActiver(16),
  17. centraleActivee(17),
  18. dateInvalidite(18),
  19. listeNoire(19),
  20. erreurCodeClavierActivation(20),
  21. nonAutoriseAActiver(21),
  22. nonAutoriseADesactiver(22),
  23. erreurCodeClavierDeDesactivation(23),
  24. passageBloqueFerme(24)

} MAX-ACCESS read-only

STATUS current

DESCRIPTION « Conditions du rejet. »

::= { ctrleEventEntry 10 }

Formations

SoFraSur offre divers types de formation adaptés aux besoins de ses Clients et à leur métier.

1. INSTALLATION

1.1. Technicien d’installation sur site

Préconisé avant toute installation et mise en service de matériel sur site.

Voir fiche formation « Technicien sur site ».

1.2. Technicien d’intégration

Préconisé à toute personne devant assuré la mise en route et la maintenance des produits électroniques.

Voir fiche formation « Technicien d’intégration ».

2. UTILISATION

2.1. Technicien de configuration

Préconisé à toute personne devant assuré l’installation et la configuration des diverses applications logicielles d’un site.

Voir fiche formation « Technicien de configuration ».

2.2. Exploitant contrôle d’accès

Préconisé à toute personne devant assuré l’exploitation du système de contrôle des accès d’un site.

Voir fiche formation « Exploitant accès ».

2.3. Exploitant détection intrusion

Préconisé à toute personne devant assuré l’exploitation du système de gestion des alarmes d’un site.

Voir fiche formation « Exploitant intrusion ».

3. MAINTENANCE LOGICIELLE

3.1. Ingénieur développeur couche IP

Préconisé à toute personne devant maintenir et installer la couche logicielle de communication sous Linux.

Voir fiche formation « Ingénieur couche IP ».

3.2 Ingénieur développeur firmware de la centrale et son lecteur

Préconisé à toute personne devant maintenir et installer la couche logicielle de fonctionnement de la centrale ou du lecteur.

Voir fiche formation « Ingénieur firmware ».

3.3. Ingénieur développeur module commun

Préconisé à toute personne devant maintenir les logiciels applicatifs soit sous WinDev soit sous WebDev (modules communs tels que base de données, serveurs, …).

Voir fiche formation « Ingénieur modules communs ».

3.4. Ingénieur développeur logiciel applicatif client lourd

Préconisé à toute personne devant maintenir les logiciels applicatifs sous WinDev.

Voir fiche formation « Ingénieur applications ».

3.5. Ingénieur développeur logiciel applicatif client léger (WEB)

Préconisé à toute personne devant maintenir les logiciels applicatifs sous WebDev.

Voir fiche formation « Ingénieur applications WEB ».

4. Exemples de formation Client

Exemple d’une formation complète à l’usage d’un NOC-SOC (configuration, accès par badge) : Formation client.