• Ajouts de capteurs ailleurs au sein du processus de transformation de l’eau d’érable
• Visualiser clairement ces nouvelles données et les enregistrer ci-requis
• Concevoir une architecture de système qui permettra de, non seulement acquérir des données, mais aussi de contrôler à distance plusieurs fonctions industrielles comme arrêt/départ de moteur ou pompe, etc.

Approche générale

       Dès le début, j’ai considéré ce projet comme un vrai défi en soi, car ce dernier adressait un problème réel et allait même au-delà des notions vues durant mon baccalauréat en informatique. À première vue, ce projet semblait assez complexe mais mes notions antécédentes en électrotechnique faisaient que je pouvais et voulais relever ce défi, même en dépit des commentaires de quelques personnes qui ont voulu initialement me décourager. Afin de mener ce projet à bon terme, il fallait que je développe une approche générale face au projet. En partant, il était clair que mon projet avait une saveur plus prononcée en design électronique qu’en design logiciel. N’empêche qu’en bout de ligne, les concepts demeuraient les mêmes et une solution devait être trouvée. L’approche initiale que j’ai eue fut basée sur deux concepts de base. Comme vue en classe, le premier concept fut de "Diviser pour régner! ". C’est-à-dire briser mon problème en sous-problèmes et de résoudre chacun de ces derniers un à la fois. Le deuxième concept en est un assez âgé et de plus en plus utilisé de part le monde : "Il ne faut pas réinventer la roue! ". En bref, je voulais développer un système basé sur une architecture ouverte qui utilise des protocoles, des composants et des logiciels existants. Se faisant, je m’assurais de m’attaquer directement au problème et non pas à un obstacle entre moi et la solution.

       L’analyse primaire du projet m’indiquait qu’il fallait que premièrement je comprenne le besoin. Par la suite, je devais identifier les composantes principales du système et proposer une architecture. Si tout allait bien et si je trouvais les ressources, je prévoyais aussi effectuer des tests suivis d’une démonstration. Suite à cette analyse initiale, j’ai donc pu briser mon projet en huit étapes. Ces étapes distinctes sont les suivantes :

• Rédaction et compréhension de l’énoncé des besoins
• Établissement des spécifications générales du système
• Recherche et identification des composants technologiques
• Design général du système
• Tests des composants électroniques
• Choix et conception logiciel
• Tests d’intégration en laboratoire
• Démonstration en laboratoire et installation en situation

       Les paragraphes qui suivent reprennent chacune de ces huit étapes distinctes et résument leurs contenus ainsi que les résultats obtenus durant le projet.

Rédaction et compréhension de l'énoncé des besoins

       La première tâche que j’ai dû exécuter pour ce travail fut de rédiger l’énoncé des besoins du système sur lequel je baserais mon projet. Par l’intermédiaire du téléphone, de fac-similés et bien entendu d’Internet, j’ai interagi à maintes reprises avec mon client habitant en Beauce afin de recueillir toute l’information nécessaire qui guiderait mon projet. J’ai donc pu recueillir les fonctionnalités que mon client désirait et aussi les caractéristiques générales du système, comme par exemple la température d’opération, la dimension géographique du terrain à couvrir, les particularités du système existant, etc.

       Avec l’aide de mon client, cette information fut ensuite brisée en deux catégories de besoin, soit les besoins primaires et ceux secondaires. En bref, nous avons regroupé sous les besoins primaires toutes les fonctionnalités essentielles qui devraient se retrouver au sein de la solution développée et aussi toutes les données techniques qui doivent caractériser le système. Sous les besoins secondaires figurent les fonctionnalités que mon client aimerait éventuellement obtenir mais qui ne sont pas importantes pour la première phase de l’automatisation de l’érablière. Il va donc de soi de dire qu’à partir de ce moment, il fut clair que l’automatisation de l’érablière se ferait en deux phases subséquentes et que mon projet dans le cadre du cours Projet de Synthèse devenait automatiquement la première phase.

       Une fois sa rédaction complétée, cet énoncé des besoins m’a permis de vraiment bien comprendre l’envergure de ce projet et m'a facilité l’extraction des spécifications requises du système. Cliquez sur le lien suivant: Énoncé des besoins afin de visualiser le contenu de l'énoncé.

Établissement des spécifications générales du système

       Suite à la rédaction de l’énoncé des besoins, je voulais définir de façon générale, les spécifications générales du système avant d’aller de l’avant afin de réduire mes risques d’échec et de fournir vraiment une solution viable. Cette phase fut plutôt abstraite car, étant donné que mon projet était relativement petit, j’ai pu effectuer intellectuellement et de manière non formelle cette analyse. Les résultats furent les suivants :

• Le propriétaire doit pouvoir maintenir le système seul. Cela veut dire qu’une fois installé, le système doit pouvoir être maintenu avec le minimum d’aide extérieur. Il serait souhaitable que les bris possibles au système soient préalablement identifiés et qu’un plan d’action simple et efficace existe. Les raisons sont simples. Les érablières se retrouvent souvent dans des régions éloignées et l’on ne peut dépendre d’une tierce partie qui prendrait beaucoup de temps pour répondre à un appel technique. Deuxièmement, les coûts d’opération de l’érablière doivent rester le plus bas possible, donc il était hors de question de proposer un service technique coûteux pour assurer la maintenance. Le système doit donc être fiable, facile d’installation et utiliser des composants avec une architecture ouverte.

• Le système doit pouvoir être fonctionnel à partir d’un ordinateur standard. C’est-à-dire que le logiciel doit pouvoir fonctionner sur un ordinateur IBM ou clone de type 486 ou plus puissant. De plus, le lien de communication avec les capteurs doit être possible à partir de cette architecture.

• L’interface utilisateur doit être simple et indicative. L’utilisateur doit être en mesure d’un simple regard de constater si tout fonctionne bien ou non, et cela sur toutes ses lignes. Des alarmes visuelles ou sonores doivent existées.

• Lecture simultanée sur plusieurs capteurs. Cette spécification est probablement celle qui fut la plus problématique et celle qui forgera le plus la solution. Étant donné que je dois effectuer un minimum de 10 lectures simultanées de capteurs et que ce nombre peut monter jusqu’à 100, il est clair qu’un système de multiplexage/réseautage serait requis. Le câblage direct de chaque capteur vers la cabane principale doit aussi être rejeté car avec des distances moyennes de 500 pieds, l’érablière se changerait rapidement en assiette de spaghetti avec tous les câbles requis! Le design général du système devait donc offrir toute l’expansion désirée et supporter une connexion de style arbre similaire au réseau de tubulure. Par exemple, il serait souhaitable qu’un seul lien interconnecte le bâtiment principal à la station de pompage maître située à près de 2000 pieds, et que de là le système pourrait être divisé.

• Le système doit fonctionner à l’intérieur des distances énoncées. Le système couvre une région de 1000 x 2000 pieds et éventuellement au-delà de ce rectangle lors d’une expansion prévue. Pour les capteurs, étant donné qu’il n’y a pas d’électricité dans les bois, l’alimentation doit provenir du lien, dans notre cas de la station de pompage. Chaque capteur doit donc être soit en réseau ou encore fournir un signal lisible jusqu’à 1000 pieds de distance. À première vue, mettre les capteurs en réseau peut devenir assez complexe. Pour ce qui est du signal transmit par les capteurs, un signal de courant est plus efficace sur de longues distances qu’un signal de voltage car ce dernier aura des pertes assez significatives. Pour ce qui est de la connexion principale entre la cabane et la station de pompage, le protocole utilisé doit pouvoir fonctionner sur des distances de près de 2000 pieds.

• Expansion du système. Tel que décrit ci-haut, le système proposé doit permettre une augmentation significative des capteurs. De plus, tel qu’indiqué auparavant, le système doit aussi permettre, non seulement de lire différents capteurs, mais aussi de contrôler de l’instrumentation à distance.

• Température d’opération du système. Le système opère normalement à une température variant de –10° à 10° Celsius. Les composants choisis doivent donc fonctionner adéquatement à cette température. Pour fin de test, il serait souhaitable que le système puisse répondre aux exigences du climat canadien de –40° à 35° Celsius.

• Coût minimum. Étant donné que les capteurs sont nombreux, le coût unitaire de chacun doit être raisonnable sinon le coût total du système sera trop élevé. À titre indicatif, le coût du système proposé pour la première phase doit être moindre que $10,000.

• Les capteurs doivent couvrir une plage de 14,5 à –5 PSI au minimum. Le système présent de vacuum fonctionne de façon optimale à 20 PSI sous la pression normale de l’air. Les capteurs choisis devront donc opérer dans cette plage et il serait souhaitable que la plage réelle des capteurs soit la plus près possible de celle du fonctionnement afin d’avoir un signal proportionnel significatif.

• Climat. Le système, spécialement les liens, câbles, circuit du capteur ou autres composants doivent supporter le climat canadien. Des précautions sont donc nécessaires pour s’assurer que les composants seront protégés ou qu’ils ne se dégraderont pas au soleil, à la pluie, au gèle, au vent, etc.

Recherche et identification des composants technologiques

       La prochaine étape de ce projet fut de rechercher et d’identifier les composants du système. Cette tâche ardue a consommé près de la moitié de mon temps disponible pour le projet. Les recherches s’effectuèrent principalement sur Internet, dans les catalogues de pièces et aussi en questionnant du personnel qualifié. N’ayant pas de ressource compétente pour diriger mes recherches, il a donc fallut que je développe un degré de connaissance un peu plus élevé sur les caractéristiques de chaque composant. Une fois encore, mon approche fut de briser cette tâche générale en sous tâche et de compléter chacune de ces sous-recherches individuellement. Voici en ordre chronologique les composants que j’ai dû identifier :

• Capteur de pression. Dès le début du projet, ce composant fut identifier comme la pierre angulaire du projet. Il fallait absolument trouver et identifier un capteur qui répondait non seulement aux normes requises, mais aussi à un prix abordable qui satisfaisait mon client, sinon je ne pouvais aller de l’avant. Au début des recherches, j’ai essayé de trouver un système déjà développé. C’est-à-dire un composant où le signal de pression en PSI était transformé en un signal standard comme par exemple de 4-20 mA. J’ai trouvé quelques solutions mais les prix étaient faramineux. Le moins cher était dans l’ordre de quelques centaines de dollars canadiens. Ce qui définitivement ne plaisait pas à mon client. La deuxième approche fut de rechercher simplement le capteur de pression et de construire moi-même le circuit de transformation pression-courant. Cette tâche fut assez longue car j’ai dû premièrement identifier quelles sont les compagnies en Amérique du Nord qui fabriquent des capteurs de pression. En bout de ligne, il y en avait qu’environ cinq. J’ai donc continué en épluchant littéralement chacun des sites web de ces compagnies. Je cherchais un capteur qui soit disponible ici au Canada, à un prix dans la région de $20 CAD. Après maintes et maintes vérifications auprès du service technique des divers fabriquants, j’ai finalement déniché la perle rare. Le capteur en question permettait une lecture de pression différentielle de 0 à 200 kPa (qui correspond à 0-29 PSI). Avec une alimentation de 10V, ce capteur produit un signal électrique de 0-40mV proportionnel à la différence de pression entre les deux ports d’entrée.

• Circuit électronique de transformation pression-courant. Tel que mentionné au sein de la portion du travail ayant trait aux spécifications, le signal provenant des capteurs (0-40 mV) doit être transformé en un signal en courant afin de palier aux longues distances entre chaque capteur et le module de multiplexage. J’ai donc choisi un des standards les plus utilisés, celui de 4-20mA. Ce qui veut dire qu’avec aucune différence de pression sur le capteur, il y aura un signal de 4 mA à la sortie et avec une pression différentielle de 29 PSI, on retrouvera un signal de 20 mA. Initialement, j’avais commencé à faire le design de mon propre circuit d’interface avec l’aide d’un chargé de cours du module informatique. Cette première tentative fut abandonnée suite à la découverte d’une solution déjà éprouvée sur le site Internet d'un des fabriquants. Lors des tests initiaux sur cette solution, je me suis aperçu que techniquement quelque chose ne fonctionnait pas. Le diagramme proposé avait certaines lacunes qui me furent par la suite confirmées par le service d’ingénierie du fabriquant en question. Ce diagramme ne pouvait fonctionner avec le type de capteur que j’avais en dépit des dires de la feuille descriptive de l’application. J’ai donc recommencé à chercher sur Internet et j’ai trouvé un autre design d’application. Cette fois-ci, avec quelques modifications, tout semblait concorder.

• Lien et interface entre ordinateur personnel et circuit du capteur de pression. À ce stade, j’avais les composants situés aux extrémités, à savoir un ordinateur personnel et les circuits des capteurs de pression. Je dois maintenant identifier les modules de communication et de multiplexage ainsi que le protocole et le médium de transport qui établiront une communication fiable de bout en bout. Sur le terrain, l’ordinateur est à près de 2000 pieds de la station de pompage où je pourrai installer des composants intermédiaires comme le module de multiplexage car c’est un des seuls lieux où l’on peut retrouver de l’électricité. De cette station partira le câblage vers chaque capteur. En moyenne, la distance entre la station et les capteurs variera de 200 à 1000 pieds. Étant donné que la distance la plus importante était celle entre la cabane principale où l’ordinateur se retrouve et la station de pompage, j’ai décidé d’analyser ce lien en premier afin de m’aider à identifier une solution viable. J’ai donc effectué une analyse des médiums de transport les plus utilisés en prenant aussi compte des protocoles disponibles.

          Cette analyse m'a permis de conclure que le câble téléphonique devrait être choisi comme médium de transport. De plus, les protocoles RS-232 et RS-485 semblent idéals car la vitesse de transmission n’est pas critique pour mon type d’application. J’ai donc poursuivi mes recherches en gardant cette analyse en mémoire. Lors d’une discussion avec un étudiant du module d’ingénierie en informatique, j’ai découvert une compagnie qui produisait le genre d’équipement dont j’avais besoin. J’ai donc consulté leur catalogue et confirmé par téléphone les spécifications et les prix des appareils requis.

• Commande des pièces. Sur papier tout semblait concorder. J’avais les pièces de mon casse-tête identifiées mais étant donné que je voulais non seulement fournir une solution documentée mais aussi la prouver en laboratoire et en situation, je devais acquérir ces équipements au moins pour les tests. Pour ce qui est des composants du circuit du capteur, après discussion avec mon professeur superviseur qui était en fait le directeur du département d’informatique, ce dernier a bien voulu utiliser des fonds de recherche pour acquérir environ $150 de pièces électroniques. D’autres pièces furent aussi commandées via les différents programmes d’exemplaire gratuit des compagnies fabricantes et d’autres furent aussi achetées directement par moi. Le problème principal résidait avec les modules de communications. Ces derniers coûtaient près de $2000 CAD et provenaient d’une compagnie américaine. Après quelques discussions au téléphone avec le service à la clientèle de cette compagnie, j’ai cependant réussi à les convaincre de prêter gratuitement pour fin d’essai les quelques modules dont j'avais besoin. Quelques semaines plus tard, j’étais donc près à passer à l’étape suivante.

Design général du système

        La photo ci-bas montre visuellement le design proposé pour le système. Il est à noter que ce design rencontre toutes les spécifications générales énoncées auparavant dans ce document. Les équipements proposés sont faciles à utiliser, à installer et à changer. Les modules de communications peuvent même être débranchés et rebranchés sans nécessairement couper l’alimentation du circuit (Hot PnP). Le propriétaire pourra donc effectuer des branchements et débranchements à condition que l’architecture globale soit respectée. Le système utilise l’interface d’un des ports de communication série de l’ordinateur (Com1 ou Com2). On peut retrouver ces ports sur tous les ordinateurs. Le système proposé utilise le protocole de communication RS-485 qui permet de contrôler jusqu’à 25 nœuds de communication pouvant eux-mêmes lire ou contrôler sept modules de multiplexage qui peuvent opérer jusqu’à 16 canaux chacun. Un calcul rapide nous donne un total de 2800 capteurs ou circuits pouvant être contrôlés. De plus, le protocole RS-485 offre aussi les avantages d’un réseau. C’est à dire que l’on peut ajouter où bon nous semble des nœuds additionnels au système. Je crois que le point de l’expansion est bien adressé.

Tests des composants électroniques

Plusieurs tests furent nécessaires afin de prouver le fonctionnement du système. Le premier test a consisté au montage du circuit du capteur (voir photo ci-jointe) et de le calibrer pour couvrir la plage de 4-20 mA lors de l’application d’une pression différentielle de 0-29 PSI. Le premier calibrage se faisait sans pression appliquée sur le capteur. On ajuste donc la limite inférieure afin d’obtenir 4 mA. Le deuxième calibrage est pour la limite supérieur. Pour le réaliser, j’ai inversé l’utilisation du capteur. C’est-à-dire que j’ai appliqué une différence de pression, non pas en utilisant une pression négative (vacuum) mais en utilisant une pression positive provenant d’un pneu de bicyclette. J’ai d’abord placé 29 PSI dans mon pneu et j’ai connecté la valve de ce pneu sur le port du capteur désigné pour les pressions positives en laissant le port pour les pressions négatives à l’air libre. J’obtenais donc une différence de pression de 29 PSI qui m’a permis de calibrer ma limite maximale de 20 mA. Une fois le circuit testé et fonctionnel, j’ai ajouté un régulateur de tension au sein du circuit qui assurera un voltage stable peu importe la longueur du circuit de courant. Quelques petits ajustements furent requis, mais en général ce deuxième test a fonctionné assez bien. Mon circuit de capteur est donc opérationnel.

Choix et conception logiciel

Tests d'intégration en laboratoire

Démonstration en laboratoire et installation en situation

Conclusion