Documentation complète
Exécutables Win32
Il s'agit d'une application de bureau en Visual Basic 6 qui permet de décrire la structure d'un objet dangereux sous la forme d'un réseau GERT et de calculer des estimations des facteurs de risque pour chaque nœud. Le système est basé sur un moteur basé sur des objets COM implémentés en Visual C++/ATL, et il existe un système de plugins pour évaluer les dangers. Chaque plugin est un objet COM. Il existe également une façade système sous la forme d'un objet COM à intégrer dans Mathcad.
L'échelle d'évaluation des dangers utilisée est trop grande (11 points) pour que les évaluations puissent être facilement effectuées manuellement. Par conséquent, une partie essentielle du système est la composante d'automatisation de leur calcul (voir Fig. 5.1). A cet effet, une technique spéciale est proposée et mise en œuvre, décrite dans le paragraphe suivant. Il s’avère que bon nombre des dangers identifiés chevauchent ceux utilisés par les ingénieurs en sécurité. Cela implique un avantage significatif du modèle développé, qui s'exprime dans le fait que les méthodes d'évaluation des conditions, de la santé et de la sécurité au travail peuvent être relativement facilement adaptées à nos nombreux facteurs de risque. Il est important que les méthodes existantes permettent, sur la base des GOST, des réglementations et de la documentation des installations de production dangereuses, de déterminer diverses caractéristiques quantitatives d'un objet, en les convertissant en échelles universelles (notation). La présence et le test de ces méthodes sont essentiels, simplifiant le processus très laborieux de développement d'une méthodologie de calcul des estimations. La méthodologie proposée peut être utilisée dans de nombreux cas, mais pas toujours, et tous les experts ne seront pas satisfaits de cette approche. Une plus grande flexibilité est donc nécessaire. C'est pourquoi une architecture a été développée basée sur la mise en œuvre du module d'évaluation comme composant externe par rapport à l'Aléa. Pour offrir cette flexibilité, il est nécessaire de fournir à l'utilisateur (généralement un expert) la possibilité de mettre en œuvre ses propres algorithmes d'estimation de valeur et d'utiliser ses propres structures et bases de données. Le type de connexion entre un tel module et le système Hazard étant simple, il n'est pas conseillé de surcharger le produit avec Visual Basic for Applications. Les spécificités du développement de tels algorithmes sont déterminées par la nécessité de travailler avec des structures de données complexes. Par conséquent, le script d'hébergement est également inadapté et alourdit de manière injustifiée le produit, puisqu'il est conçu pour mettre en œuvre des algorithmes de gestion d'objets, plutôt que pour traiter des données structurées. Le concept optimal ici est le concept de modules d'extension (plugins), qui a été implémenté à l'aide de la technologie COM. De tels modules sont généralement très compacts (de petite taille, peu dépendants de diverses bibliothèques et composants et consomment peu de ressources). Ils peuvent être implémentés dans n'importe quel langage pour lequel il existe un outil permettant le développement de composants utilisant la technologie COM. Cela offre une plus grande flexibilité de mise en œuvre, mais, en soi, n’introduit pas de complexité technologique significative à la tâche. L'intensité du travail et la complexité augmentent considérablement lors de la mise en œuvre de ce composant dans des outils et des langages de bas niveau, par exemple en utilisant Visual C++. Cependant, comme méthode accessible aux programmeurs non qualifiés, la moins gourmande en main d'œuvre et très efficace, une implémentation en Visual Basic est proposée. Le type de communication avec Hazard est très simple et le composant doit uniquement être un serveur COM en cours qui implémente l'interface IFactorAssign et peut agir en tant que client COM en utilisant l'interface IDispatch et la double interface MGertNet. La création de tels objets COM, implémentés par un serveur COM en cours, à l'aide de Visual Basic 6 est triviale et peut être facilement réalisée par des programmeurs non qualifiés, car elle est essentiellement automatisée. L'essence formulée du développement d'une extension détermine le contenu de la spécification de celle-ci. Pour que le composant soit reconnu par Hazard, connecté et capable d'interagir avec lui, les éléments suivants sont requis :
A titre d'exemple, une extension universelle a été implémentée (dans Visual Basic 6), qui est un produit très complexe et implémente la technique de la moyenne pondérée. Le module d'évaluation implémenté utilisant la méthode de la moyenne pondérée est universel, il utilise donc une interface graphique sophistiquée, des structures de données dynamiques complexes et des éditeurs pour celles-ci, ce qui vous permet de décrire efficacement un large éventail d'OPO. Il ne s’agit donc pas d’un exemple typique. Cependant, comme déjà indiqué, toutes ces difficultés ne concernent pas le mécanisme d'interaction avec Hazard, mais sont des caractéristiques de cette mise en œuvre, certaines exigences pour celle-ci (en tant que produit commercial universel). Pour des cas particuliers (usage officiel), il est proposé de créer des modules simples avec une structure statique qui peuvent être développés efficacement par des programmeurs non qualifiés utilisant Visual Basic.
Hazard est implémenté en tant que serveur COM hors processus (ActiveX EXE) à l'aide de Visual Basic 6 et est représenté par la classe COM Hazard.HazardApp. Le noyau Hazard, qui contient des codes pour un modèle de développement d'un incident dans une installation de production dangereuse, des codes pour l'exécution du modèle et des algorithmes d'optimisation, est implémenté en tant que serveur COM en cours de processus (DLL ActiveX), à l'aide de Visual C++ 6.0 (ATL ) et est représenté par la classe COM GERTNETLib.MGertNet. Hazard peut être utilisé par les clients OLE Automation, pour lesquels il offre la possibilité de créer ses propres instances en créant Hazard.HazardApp. La classe HazardApp possède un certain nombre de propriétés et de méthodes publiques qui offrent un accès limité aux capacités de Hazard, pour lesquelles une couche spéciale a été implémentée (bien qu'assez « grossière »), prenant en compte les particularités du travail en mode serveur d'automatisation OLE. La couche assure non seulement la bonne exécution des fonctions, mais également l'accès au noyau Hazard. Ce dernier peut également être utilisé directement – en créant une instance de MGertNet sans exécuter Hazard. La plupart des interfaces et classes de la bibliothèque GERTNETLib sont ouvertes et créées (publiques, créables), mais leur implémentation impose largement des restrictions sur l'implémentation des interfaces qui y sont décrites, depuis une conversion croissante des pointeurs vers des interfaces vers les types d'implémentation d'objets C++ est réalisée. Par conséquent, l’utilisation directe du noyau Hazard doit suivre des règles strictes : Création d’une instance Hazard :
Dim m_haApp As HazardApp
Set m_haApp = CreateObject( "Hazard.HazardApp" )
Pour informer les clients de la progression des opérations asynchrones, HazardApp et MGertNet fournissent un point de connexion pour le récepteur avec l'interface ICallBack. Examinons les objets inclus par une instance HazardApp. GertNetMain (lecture seule) – modèle de développement d'incidents. S'il n'y a pas de modèle (il n'a pas été chargé ou un nouveau a été créé), alors vide (Rien). GertNetMainDsp (lecture seule) – Interface IDispatch du modèle de développement d'incidents. S'il n'y a pas de modèle (il n'a pas été chargé ou un nouveau a été créé), alors vide (Rien).
GN_Opt (lecture seule) – une copie du modèle utilisé pour l'optimisation. Défini uniquement pendant l'exécution de l'optimisation.
GN_Rang (lecture seule) – une copie du modèle utilisé pour le classement. À définir uniquement pendant que le classement est en cours.
GN_Run (lecture seule) – une copie du modèle utilisé lors de l'exécution. Défini uniquement pendant l’exécution de l’exécution.
Rep1 (lecture seule) – une collection de rapports sur le modèle (exécutions, modèle).
Rep2 (lecture seule) – une collection de rapports sur des ensembles de mesures (optimisation, complexes, application expérimentale d'ensembles de mesures).
XCollection (lecture seule) – un ensemble de mesures d'amélioration de la sécurité. Chaque complexe est décrit par un ensemble d'activités (CollSF). Chaque événement (SafetyPrecaution) contient une collection d'impacts (FChange) sur le modèle. Pour accéder aux complexes de mesures, il existe une propriété publique supplémentaire : SFnn(n). Il est indexé et en lecture seule.
Enumérateurs (lecture seule) – une collection d'enquêteurs.
Facteurs (lecture seule) – un ensemble de facteurs de risque. Chaque facteur de cette collection se voit attribuer un énumérateur de la collection Enumerators.
OptimizResultsGetAndClear (lecture seule) – SAFEARRAY(IDispatch). Utilisé après l'optimisation. Lorsque cette propriété est appelée, un tableau de pointeurs vers l’interface IDispatch de collections de mesures d’amélioration de la sécurité est renvoyé. Dans ce cas, le client appelant devient propriétaire des collections et le noyau Hazard publie des références à celles-ci. Il ne peut donc être appelé qu’une seule fois. Chaque collection contient une sélection d'activités - une solution possible au problème d'optimisation.
Editeur de modèles | Éditeur de tableaux de scores |
Éditeur d'amélioration de la sécurité | Moniteur de paquet de mesures |