Le mois dernier , j'ai passé en revue l'analyse préliminaire requise pour commencer à construire un SEM pour le simulateur Tennessee Eastman (un simulateur de processus chimique). Cette analyse a produit des facteurs et des corrélations de facteurs entre les variables manifestes et les facteurs latents, qui peuvent être utilisés comme modèle de base pour la comparaison SEM. Cependant, comme je l'ai mentionné dans certains mes messages précédents , d'autres modèles doivent être créés et pris en compte sur la base de l'analyse préliminaire pour déterminer que nous avons trouvé un bon modèle pour le système. Dans ce cas, un "bon" modèle serait celui qui peut détecter les défauts du système sans signaler aucun problème en temps d'exécution normal. L'une des principales façons dont j'évaluerai ces modèles consiste à utiliser les mesures statistiques fournies par JMPPro de la fenêtre de comparaison des modèles.
Construire le SEM
Avant d'entrer dans la construction du modèle, je souhaite vous fournir l'un de mes tableaux de comparaison de modèles complets. Chaque fois que je mentionnerai l'un des SEM dans cette section, je me référerai au tableau ci-dessous avec le numéro de modèle correspondant au modèle correct. J'ai fait cela pour mettre en évidence le nombre de modèles qu'il est nécessaire de créer pour même commencer à avoir un aperçu des données, mais je ne prévois pas d'expliquer chacun de ces modèles, seulement le plus important.
Lors de la création des SEM, je n'ai utilisé que les données sous contrôle. Une fois le modèle terminé, j'ai appliqué le modèle à divers intervalles de temps pour essayer d'observer les changements qui se sont produits. Pour garder les choses simples, j'ai créé le premier modèle en utilisant seulement deux facteurs avec une covariance entre les facteurs puisque nous savons que ces facteurs sont probablement liés (c'est le modèle 5).
Nous le voyons à travers les lignes pleines, qui dénotent une signification statistique, et la ligne pointillée, qui dénote une corrélation statistiquement significative. Étant donné que nous sélectionnons nous-mêmes les corrélations, une ligne pointillée est susceptible d'indiquer que la corrélation entre ces variables n'est pas nécessaire dans le modèle pour que le modèle soit bien ajusté aux données. D'après notre connaissance du domaine, nous savons qu'il doit y avoir une relation covariable entre ces facteurs (température et pression), cela devrait donc déclencher une sonnette d'alarme à propos de ce modèle.
Cependant, vous vous souviendrez peut-être dans mon message précédent J'ai mentionné que quelques variables manifestes basées sur le compresseur ne sont pas aussi corrélées à la pression que les autres variables. Donc, à ce stade, j'ai décidé d'ajouter un troisième facteur latent, de l'appeler compresseur et d'affecter les variables manifestes précédemment associées à la pression à ce nouveau facteur de compresseur. Comme vous le comprenez probablement à ce stade, tous nos facteurs latents sont susceptibles d'être fortement corrélés les uns aux autres, donc dans ce modèle, une covariance a été ajoutée entre tous les facteurs. Pratiquement, cela a du sens puisque le travail d'un compresseur consiste à augmenter la pression, mais il produit également de la chaleur dans le processus, ce qui signifie qu'il est susceptible d'affecter à la fois nos facteurs de température et de pression (il s'agit du modèle 9 dans le tableau).
En comparant le modèle 5 au modèle 9, nous constatons que le modèle 9 fonctionne mieux dans chaque métrique testée. Non seulement cela, mais nous voyons également que toutes nos covariances entre les facteurs latents sont maintenant statistiquement significatives. C'est un résultat prometteur. Vous pouvez également remarquer dans le tableau de comparaison que nous avons beaucoup de valeurs négatives ; ce n'est pas un problème. Les mêmes règles s'appliquent : les valeurs inférieures sont meilleures. Ici vous pouvez voir, sur les 12 modèles que j'ai créés, le modèle 9 est statistiquement le "meilleur" modèle.
Détection de fautes
Alors maintenant que nous avons un modèle qui semble s'adapter raisonnablement bien aux données et nous donne des corrélations statistiquement significatives lorsqu'il est sous contrôle, il est temps de poser la grande question : Comment le SEM nous indique-t-il qu'il y a un défaut ? C'est le cœur de mon travail, et je vais donc mettre en évidence quelques façons dont j'ai trouvé que le défaut pouvait être détecté et les avantages et les inconvénients de ces méthodes de détection de défauts.
Pour les lecteurs avertis parmi nous, vous avez peut-être remarqué que même si j'ai mentionné dans mon dernier message que le défaut était une erreur dans le rapport d'alimentation A/C, il n'y a pas de variables manifestes relatives au rapport d'alimentation A/C dans le modèle ! J'aborderai ce point plus en détail le mois prochain lorsque j'aborderai les problèmes de ce modèle, mais pour l'instant, sachez que j'ai testé diverses variables liées au rapport A/C et que j'ai constaté que l'addition qui donnait les meilleures statistiques était lorsque la variable "A- Feed S1 » a été ajouté au modèle.
Ci-dessous, j'ai inclus les statistiques de comparaison pour deux modèles avec la variable A-Flow incluse. Comme d'habitude, les modèles non restreints et indépendants sont donnés, ainsi que le modèle 3, qui est un SEM sans connexions de covariance entre les facteurs latents. Le modèle 4 est le même SEM mais avec la covariance entre les facteurs latents inclus (ceci est plus susceptible d'être le bon modèle).
Il existe plusieurs manières d'observer les changements au sein du système. Tout d'abord, l'importance de la connexion entre les variables peut être un indicateur de l'apparition d'un défaut puisque cette connexion qui devrait être importante est maintenant considérée comme non importante par le modèle. Malheureusement, parfois en fonction de votre modèle et de sa sensibilité, la signification statistique des corrélations peut changer sous de petits changements dans le système. Il s'agit clairement d'un problème de sensibilité, mais cela nous montre que nous devons être prudents lorsque nous utilisons ce type d'analyse.
Deuxièmement, l'échec de convergence peut être utilisé pour détecter des défauts dans le système. Ceci est associé au nombre d'itérations qui ont eu lieu dans la plate-forme. Si plus de 1 000 itérations sont effectuées, l'analyse est annulée et le modèle ne peut pas converger. Il s'agit d'une distinction très claire entre les modèles sous contrôle et défectueux, et en fait, lorsque j'ai découvert cela pour la première fois, je pensais que cela fournissait une distinction très claire entre les données sous contrôle et hors contrôle. Mais il ne fait que cela et seulement cela, ce qui est l'inconvénient. Vérifier si le modèle a convergé nous indiquera qu'il y a une erreur quelque part, mais pas où ni quand elle s'est produite. Ce qui, si le système ne produit pas de produit ou subit une défaillance catastrophique, serait assez clair et ne nécessiterait pas de SEM.
Par conséquent, la méthode de détection des défauts que je pense être la meilleure consiste à observer le changement dans les statistiques fournies par le rapport de comparaison de modèles sur une certaine période de temps spécifiée par l'utilisateur. Le moyen le plus simple pour moi de le démontrer est d'utiliser le filtre de données local dans JMP avec les commandes d'animation.
Comme vous pouvez le voir à travers l'animation ci-dessus, j'ai ajouté un filtre de données local pour diviser l'ensemble des données en 10 groupes de 192 points de temps. Le défaut se produit au point de données 1120, mais est observable manuellement vers 1130. Dans les deux cas, cela signifie que le défaut se produit à la fin du groupe 5, les effets étant observés principalement dans les groupes 6 et 7 avant que le système n'atteigne un nouvel état stable. Si vous observez les statistiques de comparaison sur ces groupes, vous pouvez voir qu'après le groupe 5, les statistiques changent rapidement, ce qui indique un défaut.
Cependant, certaines statistiques sont meilleures que d'autres pour détecter ce défaut particulier. Par exemple, l'AICc change radicalement sur ces groupes, ce qui nous indique qu'un défaut s'est produit. Mais l'AICc rend difficile l'identification précise de l'endroit où ce défaut s'est produit puisque les principaux changements de cette valeur se produisent dans le groupe 7, longtemps après que le défaut s'est produit. Dans ce cas, si vous ne saviez pas où se trouvait le défaut, vous seriez susceptible de signaler que le défaut s'est produit dans le groupe 7. Alors que si nous observons le CFI et le RMSE sur les mêmes groupes, nous voyons que ces valeurs commencent à s'écarter significativement de leurs valeurs de base dès que le défaut se produit. La RMSE en particulier semble être la meilleure métrique pour détecter ce changement, puisque dans le groupe 5 la RMSE augmente légèrement puis dans le groupe 6 la RMSE est augmentée à des niveaux qui indiquent une erreur dans le modèle. Une fois que le système revient à un état stable après le défaut, le RMSE revient alors à sa valeur de pré-défaut. Par conséquent, pour cet exemple particulier, RMSE est la meilleure mesure statistique sur laquelle baser notre analyse, mais cette conclusion doit être testée plus avant pour voir si ce résultat est trouvé pour d'autres défauts dans d'autres ensembles de données.
Ci-dessus, j'ai fourni la même analyse qu'auparavant, mais au fur et à mesure que je parcours les groupes, le SEM et ses corrélations respectives sont donnés. Dans les groupes 3 et 4, on voit que différentes corrélations deviennent statistiquement insignifiantes de la même manière que les connexions deviennent insignifiantes dans les groupes 5 et 6, après la faute. Le problème ici est qu'il est impossible de dire si le défaut se produit dans le groupe 3 ou le groupe 5 uniquement à partir de la signification de la corrélation. Cette absence de distinction suggère trois possibilités : que ce SEM n'est pas bon pour le système, qu'il n'y a pas assez de points temporels par groupe, ou que cette méthode de détection d'un défaut n'est pas bonne. Le mois prochain, j'explorerai davantage l'idée que le SEM lui-même est pauvre. Mais compte tenu des statistiques de comparaison du SEM d'origine, il est peu probable que le modèle soit le problème. Au lieu de cela, il est probable que la méthode de détection des défauts soit le problème, car savoir si une corrélation est significative ou non fournit beaucoup moins d'informations que plusieurs statistiques qui nous donnent des valeurs quantitatives à comparer.
Comme vous pouvez le voir, espérons-le, la détection du défaut grâce aux statistiques calculées dans la section de comparaison de modèles donne une image beaucoup plus claire de l'endroit où le défaut se produit, par opposition à l'observation de la signification des seules corrélations.
Conclusion/Poursuite des travaux
À partir de cette exploration, vous devriez pouvoir voir comment il est possible, bien que chronophage, de créer des SEM et de les utiliser pour détecter des défauts dans un système industriel réel. Cependant, il y a évidemment des inconvénients avec cette application et la manière spécifique dont j'ai créé les modèles. Le mois prochain, j'ai pour objectif d'explorer certains de ces inconvénients et la portée dans laquelle SEM peut être utilisé dans des processus réels. À ce stade, une conclusion juste est que SEM peut être utilisé dans la détection de défauts mais seulement comme modèle de base pour certaines conditions, il n'est pas exhaustif.
Si quelqu'un d'autre a réussi à détecter les défauts à l'aide de SEM, soit par le biais d'un autre exemple, soit en utilisant une autre méthode pour détecter quand et où un défaut s'est produit, laissez un commentaire ci-dessous, je serais très heureux d'en entendre parler.
