Test d'alarme efficace du système de surveillance : une approche hybride

Nous recevons souvent des questions de professionnels des sciences de la vie sur les bonnes pratiques de création et de gestion des environnements GxP. Dans ce blog, nous parlons d'une question récente formulée par un technicien chargé d'installer le système de surveillance continue viewLinc.  

Question :  Je suis un spécialiste contractuel de la validation qui travaille avec un fabricant pharmaceutique mondial. Je suis en train d'implémenter le CMS Vaisala viewLinc dans un nouvel entrepôt et je prévois actuellement de tester les fonctions d'alarme de viewLinc.  Si je comprends bien, pour tester les paramètres d'alarme seuil, le système viewLinc ne permet pas à un utilisateur de « forcer » ou de simuler une valeur d'entrée analogique. Ma question est la suivante : Est-il possible de configurer les enregistreurs de données sur un étalonnage de boucle pour forcer les valeurs d'entrée ? Merci pour votre soutien !

Réponse : J'apprécie votre défi et je me réjouis de voir que des tests d'alarme sont effectués.  Tout le monde ne le fait pas, mais il est essentiel de tester les alarmes périodiquement.   En tant que professionnel de la validation, je ne pense pas nécessairement que les alarmes fassent partie des BPF, car les critères de validation sont généralement basés sur les températures réelles plutôt que sur la présence ou l'absence d'alarmes.  

Cependant, les alarmes servent à protéger des actifs significatifs et constituent l'une des principales raisons pour lesquelles les clients utilisent des systèmes de surveillance automatisés.

Je mentionne ce fait (qui ne correspond pas nécessairement à la réalité) uniquement au cas où dans votre scénario, vous réaliseriez le traitement des fonctions d'alarme comme un risque commercial et non comme un risque pour les BPF.  Cela dit, je ne sais pas si je voudrais défendre cette distinction lors d'un audit.  Je vous déconseille fortement d'essayer de forcer les valeurs d'entrée sur un enregistreur Vaisala.  Ils ne sont pas conçus pour cela, et vous pourriez endommager l'enregistreur de données.  

Par contre, je propose deux options :  

1re option : utilisez le DL1416 (ou un autre enregistreur de données à sonde externe) et déposez la sonde externe dans un bain d'étalonnage de puits sec. Utilisez cette configuration pour créer votre alarme de température.  L'avantage ici est que vous pouvez tester le seuil à la valeur configurée exacte.  L'inconvénient est la complexité et le travail associé au système de bain.

2e option : Manipulez directement les paramètres de seuils.  Si vous devez prouver que l'alarme de seuil HIGH (haut) fonctionne sur l'enregistreur X, modifiez le seuil pour placer la valeur seuil au-dessous de la valeur actuelle.  Cela déclenchera la cascade d'alarmes et toutes les notifications associées.  L'avantage ici est que vous pouvez tester le seuil sans aucun équipement ou simulateur d'étalonnage, etc.  L'inconvénient est que l'alarme est testée à une valeur arbitraire, PAS à une valeur configurée exacte.  

Je préfère moi-même la 2e option, car je pense qu'il est facile d'affirmer que même si le seuil élevé était réglé à 8 °C, et que mon test d'alarme High (haute) a été effectué à une valeur arbitraire (par exemple à 5 °C), je peux toujours affirmer que l'alarme élevée a été générée, et que la cascade de notification a fonctionné. Et j'ai vérifié que le seuil Haut est correctement configuré à 8 °C.  Donc, le seul risque est que pour une raison inconnue ou une erreur de code caché… l'alarme ne fonctionnera pas à 8 °C, mais à 5 °C. Je pense que c'est un risque minime. 

Une approche hybride des tests d'alarme

Ma recommandation pour les tests d'alarme est une approche hybride qui exploite d'autres valeurs du système que nous connaissons, en particulier le fait que nous ayons des capteurs étalonnés ET que les seuils soient tous basés sur des modèles.

1)    Testez un seul emplacement de manière que l'alarme se déclenche à la valeur prévue.  C'est assez simple. Faites-le pour un réfrigérateur avec une alarme à 8 °C et ouvrez simplement la porte du réfrigérateur pour augmenter la température.  Vérifiez que l'alarme est générée lorsque les valeurs réelles de la température dépassent le seuil défini.  Ainsi, le système générera une alarme dès qu'une valeur réelle dépasse un seuil réel.  Vous pouvez également le faire en utilisant la 1re option, le bain d'étalonnage.  Mais ne le faites que pour un seul enregistreur (ou trois si votre client a besoin d'une triple vérification).  Mais NE le faites PAS pour chaque enregistreur et chaque seuil.

2)    Vérifiez que tous les enregistreurs de données avec des seuils programmés sont étalonnés.  Ainsi, les valeurs entrant dans le système pour l'alarme sont correctes.  Cela peut paraître bizarre, mais il y a des gens qui structurent les tests d'alarme de manière à le transformer en une sorte de double vérification médiocre de l'étalonnage avec une incertitude supplémentaire.

3)    Testez tous les autres modèles d'alarme en utilisant la 2e option, à savoir en ajustant le seuil d'alarme pour déclencher l'alarme.  Ne testez pas tous les enregistreurs de données.  Ne faites ce test qu'une seule fois par SEUIL et par MODÈLE DE SEUIL (ou par MODÈLE DE NOTIFICATION).  Si le système est configuré efficacement, en utilisant des modèles d'alarme, vous devrez alors tester beaucoup moins d'alarmes.

Ainsi, l'idée à la base de l'exploitation des modèles consiste à tester chaque modèle UNE FOIS, puis pour chaque enregistreur de données ou emplacement, à vérifier que le bon modèle (que vous venez de tester) est utilisé.

J'espère avoir répondu à votre question. Il existe de nombreux guides et conseils techniques pour viewLinc dans notre Portail de documents et nous sommes là pour vous aider. Découvrez le Portail d'assistance Vaisala.