Structure du logiciel

La structure du logiciel est telle qu'elle satisfait aux exigences essentielles (§ 1.4 ci-dessus). En particulier, elle permet:

! une compréhension facile des fonctions assurées par Marius

! la libre concurrence pour les nouveaux développements comme pour la maintenance ! le transfert de l'application sur d'autres plates-formes (nouveau système d’exploitation...) ! la réutilisation de certains processus sur d'autres opérations que Marius.

! une utilisation de Marius par les opérateurs sans notice d'emploi

La structure du logiciel est en principe du ressort du réalisateur, à charge pour le Maître d'œuvre de s'assurer que les solutions proposées sont les bonnes. L'expérience montre qu'il faut parfois anticiper sur les solutions.

Concernant la réutilisation de certains processus, il est évident, qu'il faut d'abord vérifier que les fonctions assurées par le processus correspondent bien aux fonctions récherchées par l'opération cible. Le frontal de transmission, la gestion du synoptique (et son couplage à Géomarius), la commande manuelle des PMV, la main-courante et sa diffusion, les éditions iso-trafic, certaines tâches utiles à la maintenance sont par exemple des processus qui méritent d'être regardés.

Au-delà de la ré-utilisation du code, Marius peut au minimum proposer la liste des fonctions de très bas niveau qui sont implémentées, qui permettrait aux Maîtres d'Ouvrage de nouvelles opérations de découvrir de nombreuses questions auxquelles il devrait normalement répondre pour rédiger des spécifications précises.

2.6.2

Indépendance des processus

(Spécifications proposées par le Maître d'Oeuvre et acceptées par le Titulaire à la signature du marché) Le logiciel est constitué de processus indépendants des machines physiques.

Un processus permet de configurer les processus actifs dans n'importe quelle machine équipée des ressources suffisantes pour l'accueillir.

Les dialogues entre processus se font par échanges de messages IP, répertoriés dans une bibliothèque. Le fonctionnement de chaque processus est testé à l'aide d'un jeu de test spécifique documenté, qui servira lors de toute évolution ultérieure.

Les différents modules du logiciel d’applications sont rendus indépendants les uns des autres par l’utilisation des convertisseurs entre d’une part, chaque type d’entrée et la zone commune de transit entre les différents modules et, d’autre part, entre la zone commune de transit et les différents types de sortie. En d’autres termes, une entrée n’a pas d’effet direct sur une sortie.

Un message d’entrée (ME), produit par un opérateur, un correspondant externe ou un algorithme interne est converti en un ou plusieurs Messages de Transit (MT).

Un message de sortie (MS) à destination d’un écran, d’une imprimante, etc. ... (tout module matériel ou logiciel) est le produit de la conversion d’un MT.

Un MT est un « jeton » événement, qui peut voyager entre différents modules logiciels ou matériels. Tous les MT sont au même format. Une table des correspondances établit les liens entre toute entrée et sortie.

Ces élements sont plus que fonctionnels (ils relèvent d'une solution de la responsabilité du développeur, sauf à satisfaire un objectif de ré-utilisation ailleurs) Cette façon de faire, courante aujourd'hui, ne l'était pas en 1991. Elle s'est avérée particulièrement utile au moment d'améliorer certains processus et pour la maintenance. Attention, car l'abus d'échanges de messages de transit peut conduire à une dégradation des performances. Il semble clair que pour favoriser la maintenance et la réutilisation, une architecture modulaire telle que celle de Marius est souhaitable voir indispensable. Une des questions techniques clés (pour l’architecture) d’un SAGT reste de savoir quel « bus logiciel » il faut utiliser pour mettre en œuvre le dialogue entre les processus.

2.6.3

Architecture du logiciel:

(Spécification proposée par le Titulaire et agréée par le Maître d'œuvre lors du projet)

IHM TRV

SEV REG

VID TUN

SAC RAU COM

GBD RTC RAU TEDI Niveau opérateur Niveau traitemen Niveau communication Réseaux extérieurs Comm avec l'ensemble des modules fonctionnels (paramètrages, archivages, consultations) appels à garage envoi de fax traitement des appels messages au format LCR supervision tunnels commandes caméras animation cdes opérateurs affichages aux usagers Evénements données de trafic

2.3.2.

Découpage en modules fonctionnels

On entend par module fonctionnel (MF) l’ensemble des logiciels participant à un même type de fonctionnalité. Ce découpage est organisé horizontalement (par fonction du système informatique ). Les MF sont repérés par un mnémonique de trois lettres majuscules.

! COM Ce MF regroupe les programmes de communication avec tous les équipements SIREDO en protocole TEDI.

! REG Ce MF assure le traitement des données de trafic. Il pilote les panneaux d’affichage de tous types tant en mode manuel qu’en mode automatique. Il effectue le calcul des heures perdues et la détection automatique des bouchons.

! SEV Ce MF assure l’interface avec le serveur de trafic (MI Siredo).

! SAC Ce MF gère les communications avec les différents correspondants du P.C. Appel automatique des garages de service par Minitel,. Envoi automatique à Stradivarius ou par Fax ou par Internet en cas d’événements spécifiques.

! TUN Ce MF effectue la gestion technique centralisée des deux tunnels reliés au P.C.

! VID Ce MF effectue les opérations de pilotage, de cyclage et d’affectation des caméras du réseau sur les moniteurs vidéo du P.C.

! RAU Ce MF gère l’interface avec le pilote informatique de RAU (PIRAU) qui gère l’ensemble des équipements du réseau des appels d’urgence.

! TRV Ce MF effectue la gestion prévisionnelle des travaux ainsi que les informations aux usagers qui en découlent.

! IHM Ce MF gère l’interface graphique entre les opérateurs du système et les autres MF. Il gère également la mise en forme et l’édition de toutes les données du système.

architecture a supporté sans difficulté la réorganisation des répertoires, la réorganisation des commandes opérateurs, le remplacement complet de certains processus importants, le changement de machine et d'OS, ainsi que l'établissement du marché de maintenance avec une société tierce.

2.6.4

Processus critiques

Le Titulaire effectue tous les tests nécessaires à la vérification qu'aucun développement ou correction ne porte atteinte aux performances ou aux fonctions des processus critiques.

En particulier:

Blocage du superviseur

Le blocage du superviseur maintient opérationnel le Réseau d’appel d’urgence (RAU), le système de surveillance vidéo et la commande manuelle des panneaux.

En cas de panne totale de Marius, les appels RAU sont assurés par le PI-RAU (à charge pour l'opérateur de demander à l'appelant de lui donner le code du PAU affiché sur celui-ci).

La commande manuelle des panneaux est un processus prévu à partir du PC portable de maintenance, qui n'a pas été réalisé à ce jour. Le mainteneur a néanmoins toujours la possibilité d'exécuter une requête LCR ou un fichier préprogrammé de requêtes LCR.

Indépendance des Postes Opérateur

Le Titulaire doit démontrer que la gestion multiposte fonctionne de telle façon que le blocage d’un poste opérateur laisse les autres postes en bon état de fonctionnement.

En outre, après réception, toute reprise après portage d'une version de l'environnement monoposte à l'environnement multiposte donne lieu à pénalités.

Cette spécification est délicate du fait de l'obligation d'une réponse des caméras dans les 150ms qui suivent l'action sur la souris.

Gestion cartographique

La gestion de la cartographie est un processus transversal qui doit faire l'objet d'un banc de test spécifique.

Ce banc de test n'a pas été réalisé, avec l'accord du Maître d'oeuvre, vu la lourdeur du test, comparé à un enjeu assez faible: il n'y a en fait pas vraiment besoin d'un test spécifique pour s'apercevoir d'un problème sur la gestion cartographique.

Gestion vidéo

La commande des caméras est une fonction utile et fréquente. L'analyse doit tenir compte au maximum de l'"intelligence" des PIC. Tout ce qui peut être délégué au PIC au travers des fonctions LCR doit l'être (par exemple les mémorisation de cadrages pré-configurés).

La connaissance approfondie du LCR est absolument nécessaire pour une gestion performante de la vidéosurveillance.

Gestion de la main-courante

La gestion des événements a pour ambition de supprimer la nécessité d'une main-courante papier. Les temps de réponse, la fiabilité des enregistrements et la robustesse de la gestion multiposte sont des critères importants.

Il est trop tôt pour évaluer cette deuxième génération de main-courante (développée en 99), rendue nécessaire pour satisfaire aux nouveaux besoins exprimés (historique de toutes les communications entrantes et sortantes relative à chaque événement, suivi des interventions sur le site, diffusion automatique et diversifiées des caractéristiques de l'événement).