Objectifs de l'étude système

La présentation du sujet n'a pas la prétention d'être complète ni d'avoir levée toutes les options techniques. Elle ne saurait donc, en l'état, constituer le point de départ de la réalisation du logiciel de contrôle : il reste encore trop d'inconnues concernant, entre autres, le matériel et sa liaison avec le logiciel. Nous précisons ci-dessous quels sont, en l'occurrence, les rôles de l'Étude Système.

Répartition du contrôle :

Une importante question que l'on doit se poser au début des réflexions menées au sujet d'un tel système concerne la distribution, plus ou moins importante, du contrôle entre le logiciel et les différents périphériques (tourniquets, lecteurs).

Par exemple, on peut envisager d'avoir un micro-ordinateur sur chaque tourniquet : à ce moment-là, le contrôle est complétement décentralisé. On peut, à l'inverse, n'avoir qu'un seul micro-ordinateur qui centralise entièrement le contrôle. Il existe, bien entendu, des situations intermédiaires où chaque tourniquet possède une certaine autonomie : un exemple typique consiste à équiper chaque tourniquet d'une horloge qui conditionne une partie de son comportement.

Construction d'un modèle fermé :

En tout état de cause, l'argumentation technique qui peut conduire à telle ou telle décision en la matière ne peut s'effectuer qu'en analysant le système dans son ensemble. À noter que cette argumentation technique doit aussi se nourrir des informations dont on peut disposer concernant les matériels offerts sur le marché (on peut aussi décider de faire réaliser un matériel nouveau).

L'Étude Système va donc consister essentiellement à construire un modèle fermé de notre futur système et à prouver sur ce modèle que ses propriétés caractéristiques (qu'il va donc falloir expliciter avec précision) sont bien assurées.

Comportement matériels :

Un important résultat de l'Étude Système concerne les spécifications comportementales des différents matériels. Pour mener à bien cette étude, nous allons être amenés à introduire dans le modèle un certain nombre d'hypothèses concernant ces matériels. Par exemple, est-ce que le tourniquet se rebloque tout seul après le passage d'une personne, ou bien est-ce que ce bloquage ne peut être obtenu qu'après réception par le tourniquet d'un ordre venant du logiciel? Bien entendu, l'option choisie conditionne l'organisation du logiciel. Cette option constitue une hypothèse sous laquelle le modèle du logiciel peut être prouvé fonctionner correctement.

À l'issue de l'Étude Système, nous aurons ainsi effectué un certain nombre de choix de comportement du matériel. Ces choix devront être consignés dans un Cahier des Charges Matériel comportant, entre autres, une procédure de recette visant à vérifier que le matériel effectivement mis en place possède bien les propriétés que l'on attend de lui. Si ce n'était pas le cas en effet, il est clair que le mariage du logiciel et du matériel n'aurait aucune chance d'aboutir à un système fonctionnant correctement comme cela aurait été démontré sur le modèle (sous les hypothèses concernées). Cette démonstration n'aurait donc servi à rien.

Généralisation éventuelle du problème :

Nous pouvons aussi nous poser la question de savoir si le Cahier des Charges ci-dessus n'est pas trop orienté vers un seul type de système de contrôle, à savoir celui de l'accès à des batiments depuis l'extérieur. Plus généralement, le réalisateur de tels systèmes aurait peut-être intérêt à étudier un dispositif plus général qui saurait aussi s'adapter à des contrôles entre bâtiments. Nous voudrions donc savoir, grâce à l'Étude Système, si une telle généralisation est intéressante. Ce choix sera dicté essentiellement par la facilité de construction du modèle.

Aborder les questions de sécurité :

Une importante question qui n'est pas du tout abordée dans le Cahier des Charges est celle de la sécurité des personnes impliquées dans un tel système. Nous voudrions que l'Étude Système nous renseigne à ce sujet, ou tout au moins pose un certain nombre de questions pertinentes. Par exemple, est-il possible que des personnes restent bloquées dans un bâtiment? Comment garantir le contraire?

Les problèmes de synchronisation :

Plus techniquement, le Cahier des Charges est silencieux en ce qui concerne le timing fin de l'opération de transfert. Par exemple, quel décalage existe-t-il entre l'allumage du voyant vert, le débloquage du tourniquet et le démarrage du décompte de 30 secondes. Serait-il possible que le feu vert s'allume alors que le tourniquet est encore bloqué, ou que le voyant vert s'éteigne alors que le tourniquet est toujours débloqué, etc ?

La question n'est pas tant de savoir si les comportements précédents sont bons ou mauvais, elle est plutôt de reconnaître l'existence de ces comportements et de savoir à l'avance s'ils vont pouvoir apparaître (même de façon très fugitive) dans le système final qui sera mis en service.

Fonctionnement à la marge :

Une autre question qui n'est pas non plus abordée dans ce Cahier des Charges est celle du fonctionnement "à la marge" du système. Par exemple, quel est la réaction du système lorsqu'une carte est introduite dans le lecteur alors que les voyants verts ou rouges sont encore allumés (autrement dit, alors que la précédente transaction n'est pas terminée) ? Plus généralement, on voudrait pouvoir comprendre et prévoir comment le système réagit devant un comportement "hostile" de certains utilisateurs. Dans ce genre de système, on ne doit pas, en effet, compter sur des hypothèses trop fortes relatives au "bon" comportement des utilisateurs. Certains utilisateurs se comporteront certainement de façon "bizarre".