---

Mai 2019

Volume 34, numéro 5

[Machine Learning]

Utilisation de l’analyse de survie pour la maintenance prédictive

Par Zvi Topol | Mai 2019

Quelques années, j’ai introduit les principes fondamentaux de l’analyse de survie et décrit comment implémenter un algorithme non paramétriques appelé Kaplan-Meier dans C# (msdn.com/magazine/dn630650). Maintenant, je vais examiner une nouvelle analyse de survie, en particulier à deux méthodologies plus avancées qui sont disponibles sur les deux plateformes de bibliothèque Spark Machine Learning (MLLib), machine learning populaires et h2o.ai, qui sont tous deux pris en charge par Azure HDInsight. J’utiliserai un cas d’usage de maintenance prédictive en tant que l’exemple en cours.

Maintenance prédictive pour l’Internet industriel des objets

L’idée principale derrière l’Internet industriel des objets (IIoT) consiste à connecter des ordinateurs, appareils, capteurs et équipements industriels et applications au sein d’une organisation et à en permanence collecter des données, telles que les erreurs système et de télémétrie de l’ordinateur, à partir de tous ceux-ci dans le but de les analyser et agir sur ces données afin d’optimiser l’efficacité opérationnelle.

L’objectif de la maintenance prédictive consiste à prédire avec précision quand un ordinateur ou un de ses composants échouera. Si vous pouvez le faire, vous pouvez effectuer la maintenance juste avant la défaillance de ce type est censé pour se produire. Cela est plus efficace que l’exécution d’une maintenance de ne pas jusqu'à ce qu’une défaillance se produit, auquel cas l’ordinateur ou le composant n’est pas disponible jusqu'à ce que le problème est résolu, s’il s’agit en effet reparable. Ce temps d’arrêt non planifié est susceptible d’être très coûteux.

Maintenance prédictive est également plus efficace que la maintenance préventive à intervalles fréquents, ce qui peut également être sont coûteuses, car la maintenance inutiles peut-être être appliqué.

L’exemple et les données que j’utiliserai sont une version adaptée de l’exemple à bit.ly/2J4WnbN. L’exemple inclut 100 machines de fabrication, avec aucun interdépendances entre les ordinateurs. Chaque ordinateur est un des quatre modèles possibles.

Les données pour les ordinateurs incluent un historique des échecs, des opérations de maintenance et de télémétrie de capteur, ainsi que d’informations sur le modèle et l’âge (en années) des ordinateurs. Ces données sont disponibles dans les fichiers .csv téléchargeables à partir de la ressource mentionnée précédemment. Je vous fournirons également un fichier de données transformées (comp1_df.csv) est « prêt à l’analyse de survie » et explique comment effectuer les transformations par la suite.

Chaque machine dans l’exemple d’origine possède quatre composants différents, mais je vais me concentrer uniquement sur un composant. Le composant peut être géré de façon proactive avant une défaillance, ou conservé après échec afin de le réparer.

Analyse de survie

Dans mon article précédent sur l’analyse de survie, j’ai présenté les concepts de base importants que je vais utiliser et étendre dans cet article. Je vous encourage à lire cet article pour vous familiariser avec ces concepts, y compris les fonctions de survie et risque de basculement, censoring et l’estimateur de Kaplan-Meier (KM) non paramétriques.

Dans cet article, je montrerai comment étendre le concept de l’estimateur de KM à inclure covariates ou des variables (également appelés fonctionnalités) qui peuvent avoir des effets sur la survie, ou, dans ce cas, en cas d’échec de composants de l’ordinateur. Dans l’exemple, je vais utiliser modèle de machine, d’age de la machine et de télémétrie de la machine comme covariates et modèles de régression de survie permet d’évaluer les effets de ces covariates en cas d’échec de la machine. 

La notion d’estimer les effets de covariates sur une variable cible, dans ce cas le temps de défaillance, les taux de risque ou les probabilités de survie, n’est pas unique pour l’analyse de survie et sert de base pour les modèles de régression en général.

Lorsque vous créez des modèles statistiques, vous voyez covariates de trois principaux types de données : par catégorie, ordinale et continue. Types de données catégoriques sont des types qui se répartissent en plusieurs catégories distinctes. Ici, un modèle d’ordinateur est un type de données catégoriques, il existe quatre modèles d’ordinateur différent. Types de données ordinales sont des types de données catégorielles qui ont un ordre pertinent. Par exemple, les évaluations de films à partir de 1 à 10, où 10 est le plus divertissant et l’autre le moins. Enfin, les types de données continues sont ceux qui représentent des nombres continus. Ceux serait les machine télémétrie relevés ici, qui sont des nombres continus échantillonnées à certains moments (dans ce cas, toutes les heures).

Après avoir identifié les types de données et la méthodologie à utiliser, vous devez les encoder les types de données différents dans covariates. En règle générale, pour les modèles de régression, variables continues sont naturellement codés covariates continues, tandis que les types de données catégorielles nécessitera une certaine forme de codage. Une option populaire pour le codage, que j’utiliserai dans cet article, est où, pour les types de données catégorielles avec des catégories de N, covariates de n-1 sont créées, et une catégorie i est représentée en définissant ses cotes spécifiques à la valeur de tous les autres à zéro. La catégorie nième est représentée en définissant tous les covariates à zéro. Il s’agit généralement une solution parfaitement adaptée pour les modèles de régression avec une ligne de base défini explicitement, où tous les covariates peuvent être égales à zéro. Il s’agit également du format utilisé par le langage de programmation R pour encoder des variables catégorielles ou facteurs.

Cet encodage pour categoricals a une interprétation simple pour sa signification pour certains ou tous les covariates à être définie à zéro. Toutefois, pour les types de données continues, définition d’une certaine cotes à zéro ne peut pas toujours être significative. Par exemple, si un cotes représente la largeur ou hauteur de la machine, la définition que cotes à zéro serait dénuée de sens, car aucun ordinateur de ce type n’est en réalité.

Ce problème consiste à utiliser mean covariates continues centrés, où pour un cotes donné, sa moyenne sur le dataset d’apprentissage est soustrait de sa valeur. Ensuite, lorsque vous définissez ce cotes transformées à zéro, il est équivalent à définir les cotes d’origine à sa valeur moyenne. Cette technique est appelée « signifie centrage » et je vais utiliser ici pour les covariates machine âge et les données de télémétrie.

Il est important de se rappeler que cette transformation suivant, vous devez toujours utiliser covariates centrés mean en tant qu’entrée au modèle. C’est également le cas lorsque vous appliquez le modèle de régression pour un nouveau jeu de données de test.

Une fois que les valeurs de données sont encodées en tant que covariates, modèles de régression de survie prennent ensuite ces covariates et une certaine forme de variables de cibles de survie (dont je parlerai bientôt) et spécifiez un modèle qui lie les effets de ces covariates sur la survie /-à-événement de temps .

Transformation des données au Format de survie et ingénierie des fonctionnalités

Pour utiliser les modèles de régression de survie que je vais décrire, vos données doivent avoir au moins deux champs : l’horodatage de l’événement d’intérêt (ici, Échec de la machine) et un champ booléen indiquant si censoring s’est produite. (Ici, censoring décrit une situation dans laquelle aucune défaillance s’est produite à ou avant une heure spécifiée. Dans mon exemple, qui passe de manière préventive, plutôt que comme une réponse aux défaillances, de maintenance est censé être censoring.

Les modèles de régression de survie que j’aborderai ont différentes hypothèses pour simplifier leur dérivation mathématique. Certaines de ces hypothèses ne peuvent pas contenir ici, mais il est toujours utile appliquer la survie de modélisation à cet exemple.

La documentation d’analyse de survie est très riche et nombreuses avancées des modèles de régression de survie et techniques ont été développées à l’adresse et d’assouplissent certains de ces hypothèses. Vous trouverez plus d’informations sur ces modèles et les techniques dans le livre, « Le statistiques Analysis de défaillance temps données » par Kalbfleisch et Prentice (Wiley-Interscience, 2002), à bit.ly/2TACdLR.

J’ai en faisons l’hypothèse que chaque opération de maintenance exécutée sur un composant de machine entièrement réinitialise ce composant et peut donc être traitée indépendamment. Il est ensuite possible d’utiliser la régression de survie sur les deux types d’intervalles (illustrée Figure 1) :

• L’intervalle entre une défaillance et de l’opération de maintenance précédente (durée de l’événement).
• L’intervalle entre les opérations de maintenance suivantes (censoring).

Figure 1 représentation sous forme de survie de pannes d’ordinateur

Chaque intervalle en Figure 1 commence par une opération de maintenance. Le premier type de terminaisons intervalle avec X, qui dénote une défaillance, alors que le second type se termine par O, qui dénote une autre opération de maintenance avant une défaillance (il s’agit essentiellement d’une opération de maintenance proactive), ce qui signifie dans ce cas une observation censurés de George.

Par conséquent, les données d’origine doivent être converties dans ce format avec les deux champs obligatoires. Le champ « time_to_event » représente la durée en heures, jusqu'à ce que la panne ou de la prochaine opération de maintenance. Le champ « événement » est défini à un d’un échec et zéro pour une opération de maintenance avant l’échec.

Il est souvent souhaitable d’effectuer des transformations supplémentaires sur les covariates, qui est souvent appelée « ingénierie ». L’objectif de ce processus consiste à générer des covariates avec mieux le potentiel prédictif. Par exemple, vous pouvez créer un autre cotes qui calcule la moyenne de la pression dans les 10 heures avant l’échec. Il existe de nombreuses options différentes pour les fonctions et les fenêtres de temps possible pour créer ce type covariates, et il existe quelques outils que vous pouvez utiliser pour vous aider à automatiser ce processus, tels que le tsfresh de package Python open source (tsfresh.readthedocs.io/en/ dernière).

Maintenant je vais aborder les modèles de régression de deux survie : le modèle de danger proportionnelle Cox (ou un modèle de Cox PH) disponible dans h2o.ai et le modèle de Weibull accélération des temps de défaillance disponible dans Spark MLLib.

Régression des dangers proportionnelle COX

Rappelez-vous qu’une fonction risque détermine le taux d’événements au moment de t pour des objets ou des individus qui sont actifs au temps t. Pour l’exemple de la maintenance prédictive, il peut être décrit comme la probabilité d’échec dans la prochaine heure, pour une durée donnée t et pour tous les ordinateurs où la défaillance d’un composant 1 n’a pas encore s’est produite depuis leur dernière mise à jour. Taux de risque plus élevés impliquent un risque plus élevé de raison d’échec. La régression Cox PH estime les effets de covariates sur le taux de risque, comme spécifié par le modèle suivant :

Ici, h(t) est la fonction risque de basculement au moment de t, h0(t) le danger de la ligne de base au moment t, les variables Xi sont les covariates différents et les versions bêta correspondantes sont des coefficients correspondant aux covariates (plus un peu plus loin). Le danger de ligne de base est le type lorsque tous les covariates sont égales à zéro. Notez que cela est étroitement liée à l’interception dans d’autres modèles de régression, comme la régression linéaire ou logistique.

En fonction de ce modèle, il n’existe aucune relation directe entre les covariates et l’heure de survie. Ce modèle est appelé semi-structurées paramétrique, car le taux de risque au temps t est une fonction d’un taux de risque de ligne de base qui est estimé à partir des données et n’a pas une forme fermée paramétrique et un composant de multiplication qui est paramétrable.

La raison pour laquelle que ce modèle est appelé un modèle de danger proportionnel est, car il permet de comparer le ratio de deux fonctions de danger. Dans ce cas, étant donné un modèle d’estimation, est le rapport entre deux points de données différentes :

Annule le taux de risque de ligne de base et le rapport résultant entre les dangers est uniquement une fonction de coefficients et covariates et ne dépend pas à nouveau sur l’heure. Il s’agit d’une régression étroitement liée à la logistique où le journal de la notation d’évidence est évaluée. En outre, le modèle de régression Cox PH ne spécifie pas directement la survie (fonction) et les informations fournies se concentre sur le rapport ou la proportion de fonctions de danger. Par conséquent, il est principalement utilisé pour comprendre les effets de covariates sur survivabilité, plutôt que pour estimer directement la fonction de survie.

Avec le PH Cox modèle spécifié, les coefficients et le danger non paramétrique de la ligne de base peuvent être estimées à l’aide de diverses techniques. Une technique répandue est estimation de vraisemblance maximale partielle (également utilisée dans h2o.ai).

L’extrait de code suivant est un script R qui s’exécute une estimation du modèle Cox PH à l’aide de h2o.ai sur les moyennes covariates centrés (télémétrie de l’ordinateur et l’âge) et le modèle de machine cotes catégoriques :

library(h2o)
localH2O <- h2o.init()
inputFileName<-'comp1_df.csv'
df<-read.csv(inputFileName, header=TRUE, stringsAsFactors=TRUE)
df.hex <- as.h2o(df, key = "df.hex")
model <- h2o.coxph(x = c("age_mean_centered", "model","volt_mean_centered",
  "rotate_mean_centered","pressure_mean_centered", "vibration_mean_centered"),
  event_column = "event", stop_column ="time_to_event" ,training_frame = df.hex)
summary(model)

Au moment de la rédaction, le modèle de Cox PH dans h2o.ai n’est pas disponible à utiliser à partir de Python, donc le code R est fourni. Instructions d’installation sont disponibles sur bit.ly/2z2QweL, ou, pour h2o.ai avec Azure HDInsight, à bit.ly/2J7nXp6.

L’extrait de code en cours d’exécution génère la sortie illustrée dans Figure 2.

Sortie de la figure 2 de la régression Cox PH

Surv(time_to_event, event) ~ model + volt_mean_centered + rotate_mean_centered +
    pressure_mean_centered + vibration_mean_centered + age_mean_centered
  n= 709, number of events= 192
                               coef      exp(coef) se(coef)    z      Pr(>|z|)   
model.model2                  -0.066955  0.935237  0.257424 -0.260    0.795   
model.model3                  -0.021837  0.978400  0.215614 -0.101    0.919   
model.model4                   0.308878  1.361896  0.227469  1.358    0.174   
volt_mean_centered             0.031903  1.032418  0.003990  7.995    1.33e-15 ***
rotate_mean_centered           0.001632  1.001633  0.001362  1.199    0.231   
pressure_mean_centered        -0.008164  0.991869  0.005768 -1.415    0.157   
vibration_mean_centered        0.018220  1.018387  0.013866  1.314    0.189   
age_mean_centered              0.004804  1.004815  0.013293  0.361    0.718   
---
Signif. codes:  0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1
                                  exp(coef) exp(-coef) lower .95 upper .95
model.model2                      0.9352     1.0692    0.5647     1.549
model.model3                      0.9784     1.0221    0.6412     1.493
model.model4                      1.3619     0.7343    0.8720     2.127
volt_mean_centered                1.0324     0.9686    1.0244     1.041
rotate_mean_centered              1.0016     0.9984    0.9990     1.004
pressure_mean_centered            0.9919     1.0082    0.9807     1.003
vibration_mean_centered           1.0184     0.9819    0.9911     1.046
age_mean_centered                 1.0048     0.9952    0.9790     1.031
Rsquare= 0.094   (max possible= 0.941 )
Likelihood ratio test= 70.1  on 8 df,   p=4.69e-12
Wald test            = 70.19  on 8 df,   p=4.514e-12

La première chose importante à noter est les coefficients estimées des covariates. Les cotes de modèle d’ordinateur est encodé comme un type de données catégorielles. La ligne de base pour cette catégorie est Modèle1, qui est représentée en définissant les trois covariates encodage les autres modèles de trois ordinateur (model.model2, model.model3 et model.model4) à zéro. Chaque cotes obtient son propre coefficient. Il est important de comprendre comment interpréter les coefficients.

Si vous appliquez la fonction exponentielle aux coefficients pour les covariates de modèle de machine (exp(coeff) dans la sortie), vous voyez que model.model2 a la valeur 0.9352, tandis que model.model4 a la valeur 1.3619. Cela signifie que les ordinateurs de modèle2 ont un taux de risque est inférieur au taux de risque du modèle d’ordinateur de référence (modèle 1) pour cent 6.5, et que les machines de model.model4 un danger nettement supérieur de 36.2 pour cent par rapport aux machines de model.model1. En d’autres termes, les machines de model.model4 ont le risque le plus élevé de défaillance, tandis que les machines de model.model2 ont le moins de risques de défaillance. Par conséquent, lors de la hiérarchisation des opérations de maintenance, le modèle de l’ordinateur doit être un facteur important à prendre en considération.

Tous les autres covariates sont mean covariates continues centrés. L’interprétation des coefficients affilié avec eux est que le taux de risque de basculement est fourni par la valeur exponentielle de le covariates autour de leurs moyens. Par conséquent, en augmentant la valeur de cotes d’une unité (en conservant tous les autres covariates fixées), le taux de risque de basculement augmente (ou diminue) par la valeur exponentielle du coefficient (de manière similaire à celle de la variable catégorielle). Par conséquent, par exemple, en augmentant la tension d’une unité, le risque de défaillance augmente de 3.2 %.

Un autre point important de mentionner ici concerne les techniques de diagnostic de modèle. Ces techniques fournissent une base pour comprendre si le modèle prises en compte (dans ce cas, le modèle de Cox PH) est approprié. Ici, la valeur Rsquare (il s’agit d’une valeur comprise entre zéro et un, plus le mieux) est relativement faible (0.094) et la plupart des scores-z des coefficients n’indique pas que les coefficients sont statistiquement significatives (il n’est pas suffisamment de preuves pour prendre en charge qui ils sont différents de zéro). Ces indicateurs permettent de conclure qu’il existe des améliorations, par exemple par le biais de l’ingénierie. Il existe également d’autres tests statistiques qui sont spécifiques au modèle de Cox PH qui doit être effectué. Vous pouvez consulter la documentation d’analyse de survie que je l’ai mentionné précédemment pour plus d’informations.

Le modèle de temps de défaillance accélérée

Le modèle de régression de survie dans Spark MLLib est le modèle de temps de défaillance accélérée (AFT). Ce modèle spécifie une fonction de survie à partir d’une distribution de mathématiques théorique certaines (Weibull) directement et a la propriété de temps échec accélérée.

Le modèle arrière est défini comme suit. Supposons qu'un objet est caractérisé par à l’aide de la covariates (linéaires) et les coefficients :

Supposons également que l’objet a un s(t) de fonction survie paramétriques et dénoté par s0(t), la fonction de survie d’un objet de base (avec tous les covariates a la valeur zéro). Le modèle arrière définit la relation entre s(t) et s0(t) en tant que :

À partir de cette définition, vous pouvez voir pourquoi le modèle est appelé modèle de l’accélération des temps de défaillance. Cela signifie que la fonction de survie inclut un facteur d’accélérateur, qui est la fonction exponentielle des combinaisons linéaire des covariates, ce qui multiplie la survie temps t.

Ce type de modèle est utile lorsqu’il y a certaines covariates, telles que l’âge (dans mon jeu de données, ordinateur âge), cela peut provoquer des UnitOne accélération ou décélération de temps de survie/échec.

La distribution de Weibull est une généralisation de la distribution exponentielle et une distribution continue populaire dans les modèles de survie paramétriques. Il existe quelques variantes quant à paramétrer. Ici, je vais utiliser la version de distribution de Weibull deux paramètres suivante pour t > = 0 :

(Il existe également des versions avec trois paramètres.) Les deux paramètres de la distribution sont la forme est déterminée par k et l’échelle est déterminé par l’expression lambda. Une analogie approximative est le moyen de qu'une distribution en cloche a une caractéristique écart moyen et.

Souvenez-vous que la relation entre le f (t) fonction de densité de distribution, le h(t) fonction risque de basculement et la s(t) de fonction de survie est donnée par f (t) = h(t)s(t).

Les fonctions de risque de basculement et de survie de Weibull sont les suivantes :

Contrairement au modèle Cox PH, la survie et les fonctions de danger sont entièrement spécifiées et ont des représentations paramétriques. Reportez-vous à Figure 3 et Figure 4 pour les visualisations des fonctions de distribution et de survie de Weibull pour différentes valeurs de k et lambda.

Forme de Distribution de Weibull figure 3 en fonction des différentes valeurs de K et Lambda

Forme de fonction de survie de Weibull figure 4 pour différentes valeurs de K et Lambda

Figure 5 illustre les effets sur la forme de la fonction de survie de Weibull covariates de modèle arrière.

Figure 5 accélérée des temps de défaillance de la fonction de probabilité de survie de Weibull

Estimation des coefficients pour le modèle AFT Weibull dans Spark MLLib s’effectue à l’aide de l’algorithme d’estimation de vraisemblance maximale. Plus d’informations sur la façon dont il est fait à bit.ly/2XSauomet recherchez le code d’implémentation à bit.ly/2HtJw0v.

Contrairement à l’estimation du modèle Cox PH, où uniquement les coefficients des covariates sont signalés (ainsi que des diagnostics), les résultats obtenus à partir de l’estimation de l’état de modèle de Weibull AFT les coefficients de covariates, ainsi que les paramètres spécifiques pour la distribution de Weibull — une interception et un paramètre de mise à l’échelle. Je montrerai comment convertir ceux à k et lambda dans quelques instants.

Les résultats pour l’implémentation de Weibull AFT dans Spark MLLib correspondent aux résultats pour l’implémentation de Weibull AFT à l’aide de la fonction survreg à partir de la bibliothèque R populaire « survie » (plus de détails sont disponibles dans bit.ly/2XSxkw8).

Vous pouvez exécuter le script R suivant pour la loi de Weibull AFT estimation du modèle (le code s’exécute sur un MLLi Spark installée localement, mais vous pouvez également utiliser Spark sur HDInsight à bit.ly/2u2U5Qf) :

library(survival)
library(SparkR, lib.loc = c(file.path(Sys.getenv("SPARK_HOME"), "R", "lib")))
sparkR.session(master = "local[*]")
inputFileName<-'comp1_df.csv'
df<-read.csv(inputFileName, header=TRUE, stringsAsFactors=TRUE)
aftMachineDF<-suppressWarnings(createDataFrame(df))
aftMachineModel <- spark.survreg(aftMachineDF,Surv(time_to_event, event) ~ model +
  age_mean_centered +  volt_mean_centered + rotate_mean_centered +
  pressure_mean_centered + vibration_mean_centered)
summary(aftMachineModel)

Le script génère uniquement les coefficients estimés sans informations supplémentaires. Il est possible d’obtenir ces informations en exécutant survreg (étant donné que les résultats correspondent) :

library(survival)
machineModel<-survreg(Surv(time_to_event, event) ~ model + age_mean_centered +
  volt_mean_centered+rotate_mean_centered + pressure_mean_centered +
  vibration_mean_centered, df, dist='weibull')
summary(machineModel)

Dans ce cas, le script R génère la sortie plus élaborée dans Figure 6.

Figure 6 sortie de la régression arrière Weibull

survreg(formula = Surv(time_to_event, event) ~ model + age_mean_centered +
    volt_mean_centered + rotate_mean_centered + pressure_mean_centered +
    vibration_mean_centered, data = df, dist = "weibull")
                              Value        Std. Error    z            p
(Intercept)                 8.172991       0.119133    68.6040     0.00e+00
modelmodel2                 0.040289       0.154668    0.2605      7.94e-01
modelmodel3                 0.027225       0.129629    0.2100      8.34e-01
modelmodel4                  -0.163865      0.136382   -1.2015     2.30e-01
age_mean_centered           -0.000753      0.007960    -0.0946     9.25e-01
volt_mean_centered           -0.019731      0.002583   -7.6391     2.19e-14
rotate_mean_centered         -0.000767      0.000821   -0.9334     3.51e-01
pressure_mean_centered       0.005173       0.003496     .4795     1.39e-01
vibration_mean_centered      -0.008214      0.008391   -0.9789     3.28e-01
Log(scale)                   -0.508060      0.051963   -9.7773     1.41e-22
Scale= 0.602
Weibull distribution
Loglik(model)= -1710.3   Loglik(intercept only)= -1747.2
                           Chisq= 73.73 on 8 degrees of freedom, p= 8.9e-13
Number of Newton-Raphson Iterations: 8
n= 709

Avant de passer à décrire la sortie, je dois mentionner que le paramétrage de Weibull dans Spark MLLib et survreg est un peu différent de celle du paramétrage que j’ai abordé.

Une transformation est obligatoire et peut être effectuée comme suit. Désigner les paramètres signalés — interception par m et augmenter la taille de s, puis k = 1/s, lambda = exp(-m/s) et chaque coefficient doit être multiplié par (-1/s). Il existe un package R nommé SurvRegCensCov qui peut effectuer cette conversion automatiquement, à l’aide de ConvertWeibull sur le modèle que survreg estimé :

$vars
                                            Estimate        SE
lambda                                    1.260459e-06   8.642772e-07
gamma                                     1.662064e+00   8.636644e-02
modelmodel2                               -6.696297e-02  2.569595e-01
modelmodel3                               -4.524990e-02  2.155000e-01
modelmodel4                               2.723541e-01   2.268785e-01
age_mean_centered                         1.251958e-03   1.322780e-02
volt_mean_centered                        3.279500e-02   3.947495e-03
rotate_mean_centered                      1.274045e-03   1.365339e-03
pressure_mean_centered                    -8.598142e-03  5.807130e-03
vibration_mean_centered                   .365213e-02    1.391255e-02

Ici, le gamma est égal à k dans le paramétrage de Weibull précédent. (Pour plus d’informations sur SurvRegCensCov, consultez bit.ly/2CgcSMg.)

Étant donné les paramètres estimés, à la différence avec le modèle Cox PH, il est désormais possible d’obtenir la fonction de survie (c’est la fonction de survie de Weibull AFT) et l’utiliser pour prédire les probabilités de survie pour n’importe quel covariates directement. En supposant que le premier point dans le jeu de données est un nouveau point de données, vous pouvez exécuter les éléments suivants :

predict(machineModel, newdata=df[1,], type='quantile')

Il en résulte le temps à l’événement (en heures) pour les quantiles 0.1 et 0.9 (les valeurs par défaut), comme suit :

807.967 5168.231

Cela signifie que l’option étant donné les covariates du premier point de données (répertoriés ici), la probabilité de défaillance est de 10 % à ou juste avant 807.967 heures après une opération de maintenance, et la probabilité de défaillance est 90 pour cent à ou juste avant 5168.231 heures après l’opération de maintenance :

model       age           volt_mean_centered                 rotate_mean_centered
 model3       18                  3.322762                          51.8113
pressure_mean_centered     vibration_mean_centered             age_mean_centered
 10.10773                         11.4267                           6.488011

Vous pouvez également utiliser le paramètre « p » pour obtenir l’heure de survie pour n’importe quel quantiles entre zéro et un ; par exemple, ajoutez le paramètre « p = 0,5 » le temps médian échec, c'est-à-dire, pour les premier point de données, les heures 2509.814 après une opération de maintenance.

Comme avec l’estimation de modèle Cox PH, la colonne p dans la sortie de survreg fournit des informations sur la signification statistique des coefficients estimées, bien que dans ce cas, les chiffres sont préférables (p-valeurs inférieures). Il existe toujours une salle d’ingénierie de fonctionnalité ici comme a été décrit précédemment pour le modèle de Cox PH.

Il est également important d’effectuer des diagnostics de modèle ici, comme c’était le cas de la régression Cox PH, pour vous assurer que le modèle de Weibull AFT est adapté pour les données, par rapport, par exemple, dans d’autres modèles paramétriques. Tandis que l'on n’abordera pas ici ce processus, vous pouvez en savoir plus sur elle en faisant référence à l’ouvrage « Analyse de survie » j’ai mentionné précédemment.

Pour résumer

J’ai présenté l’utilisation de la maintenance prédictive pour le IIoT comme un exemple motivant l’adoption de deux modèles de régression de survie qui sont disponibles dans h2o.ai et MLLib de Spark. Je vous ai montré comment modéliser un problème de maintenance prédictive de défaillance de machine dans l’infrastructure d’analyse de survie en encodage variables en tant que covariates et transformer les données de série chronologique au format de survie. J’ai décrit également les modèles de survie de deux, les différences entre eux et comment les appliquer aux données. Enfin, j’ai abordé brièvement l’interprétation des résultats et des diagnostics de modèle. Il est important de noter que j’ai seulement effleuré la surface de cette rubrique fascinante et très riche et je vous encourage à explorer davantage. Un point de départ pour cette opération est donc en vous reportant à la documentation que je l’ai mentionné dans l’article.

---

Zvi Topola travaillé comme chercheur de données dans différents secteurs industriels, y compris de marketing analytique multimédia et divertissement et Internet industriel des objets. Il a remis et entraîner plusieurs machine learning et analytique projets, y compris en langage naturel et interfaces de voix, la recherche cognitive, analyse vidéo, systèmes de recommandation et de marketing des systèmes de prise en charge de décision. Topol est actuellement chez MuyVentive LLC, une analytique avancée R & de la société D et peut être contacté à zvi.topol@muyventive.com.

Merci à l'expert technique Microsoft suivant d'avoir relu cet article : James McCaffrey

---

Discuter de cet article sur le forum MSDN Magazine