Résumé
Cette étude s'inscrit dans le contexte du nouvel hôpital mi1itaire de Bruxelles et concerne spécifiquement le système transactionnel. Celui-ci reprendra des applications existantes du "Service de Santé" et supportera, en plus, des applications de gestion hospitalière. Sur la même machine, d'autres applications en batch et en remote-batch sont prévues mais nous ne les prenons pas en considération, dans cette étude. Le problème est de définir les moyens, tant matériel que logiciel, de ce système et d'évaluer les performances de la configuration que nous dessinerons.Le choix des terminaux ainsi que de leurs emplacements a été effectué dans des études précédentes. Il en ressort que le futur réseau se scinde en deux parties : un réseau externe dont les terminaux sont répartis dans les principaux centres et hôpitaux militaires de Belgique et d'Allemagne, et un réseau interne à l'hôpital de Bruxelles dont les terminaux se répartissent aux points où les informations de gestion sont saisies ou restituées.
Pour concevoir une configuration, il faut certaines connaissances des applications : types de transactions, fonctions à exécuter dans le CPU par transaction, accès aux fichiers et volumes des transactions par terminaux. Ces derniers, bien qu'approximatifs, sont très importants pour la définition des moyens. A l'aide de ces renseignements , nous établirons une configuration de réseau : logiciel des terminaux, logiciel de télétraitement de l ' ordinateur, logiciel du front-end processor et un schéma des lignes en fonction des emplacements physiques des terminaux et du volume des transactions.
Dans les connaissances actuelles, nous avons à notre disposition deux moyens pour estimer les performances du système : le calcul analytique et la simulation. Le calcul analytique donne de bons résultats, pour autant qu' aucune ressource n'atteigne une charge critique. Nous avons choisi la simulation parce qu'elle permet de juger des situations ambiguës qui résultent du calcul analytique. Le modèle de simulation est caractérisé par la présence de trois blocs indépendants : l'horloge multiple, le programme de gestion de lignes et les applications. L'horloge met des demandes de polling pour le PGL, le PGL transmet des messages vidéo et imprimante et les applications utilisent les ressources du CPU et des disques pour compléter ou consulter les fichiers.
Pour exploiter les résultats de la simulation, nous essayons d'abord de valider le modèle en approchant des résultats de la simulation par un rapide calcul analytique. La simulation a sous-chargé certains terminaux, ce dont nous avons tenu compte pour l'analyse des résultats. Le CPU et les
disques ne posent pas de problème au point de vue de leur charge. Certaines lignes, par contre, atteignent une charge critique. Les lignes du réseau externe pourront accepter leur charge théorique sans dégradation importante du temps de réponse, sauf pour la ligne de la Gendarmerie qui devra passer de 4800 à 9600 bps. Pour le réseau interne, la situation est différente : certaines lignes accusent des temps de réponse pour lesquels l'écart-type est très important. Cela nous a amenés à proposer une nouvelle configuration de ligne pour le réseau interne.
Pour le futur, on pourra affiner les temps de service du CPU par applications. Lorsqu'on connaitra plus de détails sur les applications, on pourra étudier les répartitions des longueurs des messages selon les applications et les terminaux. Il serait également intéressant de changer les valeurs de nos paramètres par celles obtenues chez quelques constructeurs pour une première évaluation des performances de leur configuration. On peut prévoir une modélisation de réseaux plus complexes ayant des concentrateurs ou des lignes en boucles.
| la date de réponse | 1977 |
|---|---|
| langue originale | Français |
| L'institution diplômante |
|
| Superviseur | J. Baily (Promoteur) |