Réduire la perte d'eau, promouvoir la conservation avec ArcGIS | Questions & Réponses

Anonymous User

<\/HEAD>

Voici les questions et réponses du webinaire Réduire la perte d'eau, promouvoir la conservation<\/A><\/EM><\/STRONG>.<\/P>

<\/P>

• Q1 : Pat, avez-vous de gros clients qui sont surveillés et soustraits de l'analyse du débit minimum nocturne ?<\/SPAN><\/LI>R1 : Nous avons un grand client en gros qui est surveillé avec SCADA. Nous soustrayons ces débits des relevés des compteurs de la zone de mesure du district (DMA) affectée.<\/SPAN><\/LI><\/UL><\/P>Q2 : Comment avez-vous déterminé que 0,05 gpm était le chiffre acceptable pour les fuites ou usages nocturnes ?<\/SPAN><\/LI>R2 : Nous sommes partis du chiffre de 0,05 gpm par connexion pour définir les valeurs initiales minimales de performance. Nous avons examiné les valeurs initiales de débit reçues pour les DMA et avons commencé à resserrer les pires parties de notre système par des réparations. La valeur de 0,05 gpm par connexion s'est avérée être un objectif réalisable et sera abaissée à mesure que nous chercherons à resserrer davantage le système en trouvant/réparant des fuites de débits plus faibles.<\/SPAN><\/LI><\/UL><\/P>Q3 : Que voulez-vous dire par spread et level lors du placement des enregistreurs de fuite ?<\/SPAN><\/LI>R3 : Level et Spread sont deux valeurs retournées par les enregistreurs après leur déploiement et leur « écoute » des bruits de fuite. Elles n'ont rien à voir avec le placement des enregistreurs. Elles indiquent à quel point les bruits entendus par un enregistreur sont forts (niveau sonore en décibels – un nombre plus élevé signifie un bruit plus fort). De plus, les valeurs de spread indiquent combien de bruits distincts un enregistreur détecte. Moins il y a de bruits (valeur spread plus basse), plus cela renforce la certitude qu'un bruit de fuite est présent près des enregistreurs.<\/SPAN><\/LI><\/UL><\/P>Q4 : Combien y a-t-il de vannes principales dans votre système ?<\/SPAN><\/LI>R4 : Environ 7 200<\/SPAN><\/LI><\/UL><\/P>Q5 : Pouvez-vous intégrer ArcGIS et AMI (c’est-à-dire détection active des fuites) pour créer des évaluations NRW en temps réel et des tableaux de bord ?<\/SPAN><\/LI>R5 : Je suppose que c'est possible, mais je ne connais personne qui l'ait fait. Nous aimerions faire cela, mais nous ne disposons pas de données AMI.<\/SPAN><\/LI><\/UL><\/P>Q6 : Comment avez-vous déterminé votre KPI de 52mgd ?<\/SPAN><\/LI>R6 : Je suppose que vous faites référence au KPI de 56 gallons par minute sur l'exemple DMA montré dans la présentation. Il y a 1 131 connexions dans le DMA Mulloy West. En multipliant notre KPI souhaité de 0,05 gallons par minute par connexion par 1 131, on obtient un débit souhaité de 56 gallons par minute pour ce DMA.<\/SPAN><\/LI><\/UL><\/P>Q7 : Comment gérez-vous les données des enregistreurs de fuite ? Tous les journaux vont-ils dans une seule classe d'entités avec date ou groupe d'étude ?<\/SPAN><\/LI>R7 : Toutes les données des enregistreurs vont dans une seule classe d'entités. Nous les gérons avec un champ statut. Selon le groupe de travail, nous pouvons trier par classe ou faire apparaître/disparaître les entités selon les changements de statut en temps réel.<\/SPAN><\/LI><\/UL> <\/SPAN><\/P>Q8 : Combien de temps a-t-il fallu pour mettre en place des DMA fonctionnels ? C’est-à-dire que les données recueillies étaient réellement utiles ?<\/SPAN><\/LI>R8 : Du côté construction/matériel du projet, il a fallu environ six semaines pour installer et configurer les 30 premiers compteurs DMA. Il a fallu environ une semaine supplémentaire pour créer les entités DMA puis nous avons commencé à recevoir des données utiles. Du côté SIG, il a fallu moins d'une journée pour configurer la carte DMA initiale et moins d'une autre journée pour assembler le tableau de bord.<\/SPAN><\/LI><\/UL><\/P>Q9 : Avec quelle entreprise avez-vous travaillé pour obtenir les sondes d'insertion et les enregistreurs de fuite ?<\/SPAN>
• R9 : Matchpoint, Inc.

http:\/\/www.matchpointinc.us\/<\A> <\Span> <\Li> <\Ul>

<\P>

• Q10 : Pourriez-vous donner une idée sur la taille minimale du système nécessaire pour que cette approche soit rentable ? <\Span> <\Li> R10 : Je pense que tout système pourrait bénéficier d'une forme d'analyse du débit s'il existe des pertes réelles appréciables dans l'eau non facturée qui peuvent être couvertes. Même s'il ne s'avère pas y avoir actuellement des pertes importantes – la surveillance des débits peut fournir des notifications plus rapides lorsque des fuites se produisent – réduisant ainsi la durée des fuites même pour des systèmes relativement étanches. Le principe de surveillance des débits minimums nocturnes (au moins pour les bases clients résidentielles) semble être une bonne approche pour presque tous les systèmes. Jusqu'où vous investissez dans le personnel, le matériel, le logiciel, etc., doit prendre en compte plusieurs facteurs : coût de l'eau ; exigences réglementaires ; disponibilité de la source d'eau ; perception publique ; capacités technologiques ; attentes ROI ; etc. <\Span> <\Li> <\Ul> <\P> Q11 : Ces outils/systèmes de détection peuvent-ils identifier et localiser des branchements illégaux avec vol d'eau ? <\Span> <\Li> R11 : Oui – surtout la solution de surveillance du débit. Pouvoir comparer les débits réels dans les conduites avec les données des compteurs au détail peut aider à révéler plusieurs choses pouvant être à l'origine des écarts. Les différences entre ces deux catégories peuvent aider à identifier non seulement les fuites, mais aussi : vol ; branchements non comptabilisés ; compteurs lents/arrêtés ; etc. <\Span> <\Li> <\Ul> <\P> Q12 : L'outil Leak Logger automatise-t-il l'emplacement où placer les enregistreurs basé sur les informations sur l'actif et la canalisation ou montre-t-il seulement la zone couverte où vous saisissez manuellement où placer les enregistreurs ?<\Span> <\Li> R12 : Il montre seulement la zone couverte par les enregistreurs après leur placement. Cependant, l'utilisateur peut faire plusieurs itérations avec l'outil pour gérer un placement efficace/complet dans la zone d'enquête.<\Span> <\Li> <\Ul> <\P> Q13 : Vous n'avez pas pris en compte la pression ni la longueur du tuyau pour le débit minimum nocturne ?<\Span> <\Li> R13 : Non. Nous nous intéressons au débit excessif – indépendamment de la pression du système ou de la longueur du tuyau. À l'avenir, nous pourrions fixer des KPI moins agressifs dans les zones avec plus de tuyaux/pression plus élevée, mais notre objectif initial est de voir jusqu'où nous pouvons descendre réalistement avec le KPI gpm/connexion – indépendamment de la pression ou longueur du tuyau.<\Span> <\Li> <\Ul> <\P> Q14 : Quand avez-vous migré vers le Local Government Information Model (LGIM) ? Avez-vous rencontré une résistance liée aux coûts venant de la direction concernant le développement du SIG ?<\Span> <\Li> R14 : La migration vers LGIM a eu lieu vers février 2014. La direction a en fait conduit le désir de migrer vers LGIM. Ils ont compris que cela devait se faire afin de profiter plus facilement des développements ArcGIS existants et futurs.<\Span> <\Li> <\Ul> <\P> Q15 : Comment les systèmes AMI mesurant tous les points de consommation sauf ceux non mesurés changeraient-ils cette configuration ?<\Span> <\Li> R15 : Les données AMI dans cette configuration seraient d'une grande aide. Pouvoir soustraire la consommation légitime connue des valeurs mesurées éliminerait une partie des suppositions que nous faisons. Nous supposons une consommation légitime (un peu plus qu'une estimation éclairée qui permet aussi une certaine quantité de fuite) que nous calculons en multipliant un facteur par le nombre de connexions. Disposer des données AMI réelles ajouterait beaucoup de certitude à ce que nous faisons et améliorerait considérablement notre processus. La question 5 ci-dessus fait allusion aux évaluations NRW en temps réel. Nous aimerions faire cela, mais AMI serait extrêmement coûteux à réaliser avec la technologie actuelle.<\Span>