Partie 3 sur 4
Par Tom DeWitte et Tom Coolidge
La transformation numérique du paquet de construction de l'industrie du gaz et des pipelines a initialement été axée sur la transformation numérique des cartes papier annotées en données numériques. La plupart des solutions initiales de suivi et de traçabilité sur le marché se sont presque exclusivement concentrées sur cette partie du paquet de construction. Qu'en est-il du reste du paquet de construction ?
Un paquet de construction de tuyauterie contient plus que des cartes papier annotées. Il contient les résultats des tests de pression, les inspections des tuyaux exposés, les listes de contrôle, les rapports quotidiens, et plus encore. Qu'en est-il de la transformation numérique de ces documents ?
Dans cet article de blog, nous discuterons comment configurer et automatiser la capture des données du test de pression. La documentation des tests de pression a historiquement été une pièce d'information critique qui est trop souvent reléguée au bas de la pile de documents, classée au fond du cabinet, mise en boîte, entreposée, et finalement égarée pour ne jamais être retrouvée. Si vous êtes responsable de la gestion ou de la détermination de la pression maximale admissible d'exploitation (MAOP) d'une zone de pression, alors cette réalité frustrante vous a probablement fait faire un facepalm.
Un avantage clé de la transformation numérique de la documentation des tests de pression est que cette information est immédiatement liée aux actifs testés. En tant qu'enregistrement lié à l'actif, il suffit d'un simple clic pour récupérer cette information. Fini les recherches dans des boîtes entreposées pleines de documents pour trouver cette information critique.
Qu'est-ce qu'un test de pression ?
Le test de pression est une pratique standard dans l'industrie. Le but est d'identifier les problèmes qui entraîneraient une défaillance du système et la fuite de gaz avant que le gaz naturel ne circule à travers ces nouveaux actifs. En termes simples, c'est pour s'assurer que les composants nouvellement installés font partie d'un système de tuyauterie sûr et fiable.
L'action physique d'effectuer un test de pression n'est pas compliquée. Vous insérez une substance inerte, telle que l'air ou l'eau, dans la portion nouvellement installée du système de tuyauterie. Le nouveau sous-système est ensuite pressurisé à la pression d'essai souhaitée. Une fois pressurisé, le sous-système est surveillé pendant une durée spécifiée pour vérifier que les tuyaux, vannes et raccords maintiennent la pression et ne fuient pas. La dernière étape consiste à documenter le test pour conserver cette information importante pour une analyse future et l'ingénierie du système de tuyauterie.
Problèmes historiques
Documenter un test de pression comporte deux composantes principales. Les résultats du test lui-même, et l'identification des composants du système de tuyauterie qui ont été testés. Historiquement, tout cela se faisait sur papier. C'était chronophage. Les équipes sur le terrain devaient esquisser la portion testée et identifier les composants inclus dans le sous-système testé. Non seulement cela était sujet à des erreurs et omissions de données, mais c'était aussi une documentation redondante des données. Les équipes sur le terrain étaient invitées à redessiner le nouveau système de tuyauterie pour le test de pression après avoir dessiné séparément ces composants pour la documentation as-built annotée.
Les premières tentatives pour convertir la documentation papier en documentation numérique se sont souvent concentrées sur l'élimination de la création redondante des esquisses. Par exemple, une solution héritée demandait à l'utilisateur sur le terrain de cliquer manuellement sur chaque actif unique participant au test de pression. Cela éliminait la création redondante des esquisses, mais au prix d'une perte significative en productivité. Imaginez combien de temps il vous faudrait sur votre téléphone, tablette ou ordinateur portable pour sélectionner manuellement chaque raccord, vanne et segment de tuyau du sous-système testé à la pression. Cela pourrait facilement inclure plus de 100 éléments uniques. Cette approche numérique héritée, en plus d'être plus longue à compléter, restait sujette aux omissions de données.
Plus facile, plus rapide et plus précis
Ce problème industriel concernant comment documenter efficacement et précisément les tests de pression est un excellent exemple où une application mobile géospatiale peut résoudre ce problème de manière unique. Il existe une solution qui offre à l'utilisateur sur le terrain un processus plus simple pour documenter les tests de pression d'une manière plus rapide et plus précise. Alors, quel est exactement le secret qu'une solution mobile géospatiale peut fournir ?
La réponse est les polygones.
Notre secret
Une application mobile géospatiale consciente comme ArcGIS Field Maps comprend quels segments nouvellement installés, vannes et raccords sont contenus dans l'étendue d'un polygone. Cette compréhension géospatiale élimine le besoin pour un utilisateur sur le terrain de sélectionner manuellement les composants du système de tuyauterie.
L'utilisation d'un polygone pour représenter l'étendue du test de pression simplifie la documentation du test en deux étapes.
Étape 1 : Dessiner un polygone autour des composants du système de tuyauterie qui ont été testés.
Étape 2 : Documenter les résultats du test lui-même.
Les deux configurations clés dans ArcGIS Field Maps pour permettre cette automatisation sont la couche polygone et une règle d'attribut.
Le polygone du test de pression
L'entité polygone du test de pression est l'enregistrement persistant du test de pression. Elle est activée avec des pièces jointes permettant que des photos du manomètre soient stockées comme partie intégrante du dossier du test. Les informations spécifiques qu'une entreprise souhaite capturer concernant le test (durée, milieu d'essai dans le tuyau, qui a effectué le test, etc.) constituent le schéma du polygone. Cet enregistrement polygonal capture pleinement où, quand, qui, comment et quoi a été testé.
Documenter les résultats du test
Pour la plupart des entreprises, définir le schéma est un processus unique consistant à convertir les questions du formulaire papier en un formulaire intelligent numérique. Le schéma peut inclure des listes déroulantes, valeurs par défaut et sélecteurs date afin d'éliminer les fautes de frappe et accélérer la saisie des données.
Maintenir le lien entre actif et test
Une partie clé de l'automatisation du test consiste à taguer tous les actifs nouvellement installés qui ont été testés. C'est là qu'une règle d'attribut est mise en œuvre. La règle compare l'étendue polygonale aux composants du système documentés lors du flux initial digital as-built sur le terrain.
Voici le script arcade pour automatiser l'attribution ID du test dans la classe d'entités StagingLine.
//Nom règle : StagingPressureTest_PressureTestID_StagingLine
//Description : Pousser attributs StagingPressureTest vers StagingLines
//Type : Calcul
//Sous-type : Tous
//Champ : pipetestpressure
//Modifiable : coché (true)
//Déclencheur : Insert, Update
//Code erreur : 7
//Message erreur : Impossible d'appliquer attributs StagingPressureTest aux StagingLines
//Évaluer depuis évaluation application : coché (true)
// Obtenir ID test pression depuis entité polygone
var retVal = $feature['pipetestpressure'];
var pressureTestId = $feature['PressureTestID'];
var feature_set = FeatureSetByName($datastore, 'StagingLine', ['OBJECTID'], false);
// Trouver entités ligne intersectant le polygone
var intersected_features = Intersects($feature, feature_set);
//Si besoin exclure certains types d'entités modifier ligne suivante et changer boucle "for" par : filtered_features
//var filtered_features = Filter(intersected_Features, 'assetgroup not in (10, 12)')
//ajouter entités au dictionnaire mise à jour
var updates = [];
var i = 0;
for (var feat in intersected_features) {
updates[i++] = {'objectid': feat.objectid,
'attributes': {
'PRESSURETESTID': $feature.pressureTestID<\/FONT><\/P>
}<\/FONT><\/P> }<\/FONT><\/P>}<\/FONT><\/P>\/\/retourner le dictionnaire<\/FONT><\/P>return {<\/FONT><\/P> 'result': retVal,<\/FONT><\/P> 'edit': [{<\/FONT><\/P> 'className': 'StagingLine',<\/FONT><\/P> 'updates': updates <\/FONT><\/P> }]<\/FONT><\/P>}<\/FONT><\/P>Cette règle d'attribut est automatiquement initiée dès que l'utilisateur du terrain soumet le polygone de test de pression.<\/FONT><\/P>
<\/span><\/FONT><\/P>Applications mobiles conscientes de la géospatialité<\/H1>Cette configuration d'ArcGIS Field Maps montre comment les besoins de documentation des informations de construction de tuyaux, comme un test de pression, peuvent être traités de manière unique. Les applications mobiles conscientes de la géospatialité fournissent la sauce secrète pour automatiser la documentation avec la facilité d'utilisation et la productivité que recherchent les utilisateurs sur le terrain. <\/P>Il est également important de noter que l'automatisation du marquage des actifs testés à la pression avec l'ID unique du test de pression améliore la qualité des données. Cette écriture mobile de l'ID du test de pression sur chacun des actifs signifie que ces données critiques ne seront plus perdues dans la pile de boîtes à l'entrepôt.<\/P>Si vous êtes intéressé par le déploiement de cette configuration d'ArcGIS Field Maps, nous avons publié tous les scripts, modèles de données et instructions pour cette configuration de test de pression et toute la solution numérique d'as-built sur le terrain. Vous pouvez télécharger cette configuration gratuitement depuis le site Esri Community. Voici le lien<\/A>. Cet article de blog est le troisième d'une série de quatre articles expliquant comment déployer ArcGIS Field Maps pour l'as-built numérique sur le terrain. Si vous avez manqué nos articles précédents sur l'as-built numérique sur le terrain, voici les liens vers ces articles.<\/P>Partie 1 : As-Built numérique sur le terrain avec ArcGIS<\/A><\/P>Partie 2 : As-Built numérique sur le terrain avec ArcGIS : Pas de code-barres Pas de problème<\/A><\/P>Le prochain article du blog continuera à exploiter l'amélioration de productivité grâce à la conscience géospatiale. Le blog #4 révélera la sauce secrète de la configuration et de l'automatisation pour gérer le projet de construction, et comment lier automatiquement toute la documentation numérique du projet de construction ensemble.<\/P>
VEUILLEZ NOTER : Les publications sur ce site sont les nôtres et ne représentent pas nécessairement la position, les stratégies ou les opinions d'Esri.<\/EM><\/P>
