Le mois dernier , j'ai passé en revue l'analyse préliminaire nécessaire pour commencer la construction d'un SEM pour le simulateur Tennessee Eastman (un simulateur de processus chimique). Cette analyse a donné des facteurs et des corrélations factorielles 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 un modèle capable de 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 JMP Pro fenêtre de comparaison de modèles.
Construire le SEM
Avant de me lancer dans la construction du modèle, je souhaite vous fournir l'un de mes tableaux de comparaison complets de modèles. 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 bon modèle. J'ai fait cela pour mettre en évidence le nombre de modèles qu'il est nécessaire de créer pour ne serait-ce que commencer à avoir un aperçu des données, mais je n'ai pas l'intention d'expliquer chacun de ces modèles, seulement les plus importants.
Lors de la création des SEM, j'ai utilisé uniquement les données sous contrôle. Une fois le modèle terminé, je l'ai appliqué à différents intervalles de temps pour essayer d'observer les changements survenus. Pour simplifier les choses, j'ai créé le premier modèle en utilisant uniquement 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. Puisque 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 celui-ci soit bien adapté 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), ce qui devrait donc déclencher l'alarme concernant ce modèle.
Cependant, vous vous en souviendrez peut-être 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. À ce stade, j’ai donc décidé d’ajouter un troisième facteur latent, de l’appeler compresseur et d’attribuer les variables manifestes précédemment associées à la pression à ce nouveau facteur de compresseur. Comme vous l’avez probablement compris à ce stade, tous nos facteurs latents sont susceptibles d’être fortement corrélés les uns aux autres, c’est pourquoi dans ce modèle une covariance a été ajoutée entre tous les facteurs. En pratique, cela a du sens puisque le travail d'un compresseur consiste à augmenter la pression, mais il produit également de la chaleur au cours du processus, ce qui signifie que cela 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 avec le modèle 9, nous constatons que le modèle 9 fonctionne mieux dans chaque métrique testée. Non seulement cela, mais nous constatons également que toutes nos covariances entre facteurs latents sont désormais statistiquement significatives. C'est un résultat prometteur. Vous remarquerez peut-être également dans le tableau comparatif 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 que sur les 12 modèles que j'ai créés, le modèle 9 est le « meilleur » statistiquement.
Détection de fautes
Alors maintenant que nous disposons d’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 montre-t-il qu’il y a un défaut ? C'est l'essentiel de mon travail et je vais donc souligner quelques façons dont j'ai découvert que le défaut pouvait être détecté ainsi que les avantages et les inconvénients de ces méthodes de détection de défauts.
Pour les lecteurs avertis parmi nous, vous aurez 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 aucune variable manifeste relative au rapport d'alimentation A/C dans le modèle ! Je couvrirai ce point davantage le mois prochain en abordant 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 j'ai constaté que l'ajout 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 liens de covariance entre les facteurs latents. Le modèle 4 est le même SEM mais avec la covariance entre les facteurs latents incluse (il est plus probable qu'il s'agisse du modèle correct).
Il existe plusieurs façons d’observer les changements au sein du système. Premièrement, l’importance de la connexion entre les variables peut être un indicateur d’un défaut puisque cette connexion qui devrait être importante est désormais 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 en cas de petits changements dans le système. Il s’agit clairement d’une question de sensibilité, mais cela nous montre que nous devons être prudents lorsque nous employons ce type d’analyse.
Deuxièmement, l’échec de la 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 sur la plateforme. 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 par défaut, et en fait, lorsque j'ai découvert cela pour la première fois, j'ai pensé 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 constitue son inconvénient. Vérifier si le modèle a convergé nous dira 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 panne 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 considère comme la meilleure consiste à observer l’évolution des 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 démontrer cela consiste à utiliser le filtre de données local dans JMP avec les contrôles 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 configurées en 10 groupes de 192 points temporels. Le défaut se produit au point de données 1120, mais est observable manuellement vers 11h30. Dans les deux cas, cela signifie que le défaut se produit à la fin du groupe 5, les effets étant principalement visibles 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'une panne s'est produite. Mais l'AICc rend difficile l'identification précise de l'endroit où ce défaut s'est produit puisque les principales modifications de cette valeur se produisent dans le groupe 7, longtemps après l'apparition du défaut. Dans ce cas, si vous ne saviez pas où se trouvait le défaut, vous signaleriez probablement que le défaut s'est produit dans le groupe 7. Alors que si l'on observe le CFI et le RMSE sur les mêmes groupes, on constate que ces valeurs commencent à s'écarter significativement de leurs valeurs de base dès que le défaut se produit. Le RMSE en particulier semble être la meilleure mesure pour détecter ce changement, puisque dans le groupe 5 le RMSE augmente légèrement puis dans le groupe 6 le RMSE augmente jusqu'à 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 d'avant le défaut. Par conséquent, pour cet exemple particulier, RMSE est la meilleure mesure statistique sur laquelle baser notre analyse, mais cette conclusion nécessite des tests supplémentaires pour voir si ce résultat se retrouve pour d'autres défauts dans d'autres ensembles de données.
Ci-dessus, j'ai fourni la même analyse que précédemment, 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 dans le groupe 5 uniquement à partir de l’importance de la corrélation. Ce manque 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 de défaut n'est pas bonne. Le mois prochain, j’explorerai plus en détail l’idée selon laquelle le SEM lui-même serait pauvre. Mais compte tenu des statistiques de comparaison du SEM original, il est peu probable que le modèle soit en cause. 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 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 des modèles donne une image beaucoup plus claire de l'endroit où le défaut se produit, par opposition à l'observation seule de l'importance des corrélations.
Conclusion/Travaux supplémentaires
À partir de cette exploration, vous devriez être en mesure de voir comment il est possible, bien que cela prenne du temps, de créer des SEM et de les utiliser pour détecter des défauts dans un système industriel réel. Cependant, cette application présente évidemment des inconvénients 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 le SEM peut être utilisé dans des processus réels. À ce stade, une conclusion raisonnable est que le SEM peut être utilisé dans la détection de défauts, mais uniquement comme modèle de base pour certaines conditions et qu’il n’est pas exhaustif.
Si quelqu'un d'autre a réussi à détecter les défauts à l'aide de SEM, soit à travers un autre exemple, soit en utilisant une autre méthode pour détecter quand et où un défaut s'est produit, déposez un commentaire ci-dessous, je serais très heureux d'en entendre parler.
