{"id":48676,"date":"2025-09-17T18:09:33","date_gmt":"2025-09-17T18:09:33","guid":{"rendered":"https:\/\/becolve.com\/blog\/decalogo-de-boas-praticas-para-a-comunicacao-controlo-e-supervisao-de-instalacoes-nao-vigiadas-parte-1\/"},"modified":"2025-09-17T18:09:48","modified_gmt":"2025-09-17T18:09:48","slug":"decalogo-de-boas-praticas-para-a-comunicacao-controlo-e-supervisao-de-instalacoes-nao-vigiadas-parte-1","status":"publish","type":"blog","link":"https:\/\/becolve.com\/pt-pt\/blog\/decalogo-de-boas-praticas-para-a-comunicacao-controlo-e-supervisao-de-instalacoes-nao-vigiadas-parte-1\/","title":{"rendered":"Dec\u00e1logo de boas pr\u00e1ticas para a comunica\u00e7\u00e3o, controlo e supervis\u00e3o de instala\u00e7\u00f5es n\u00e3o vigiadas (Parte 1)"},"content":{"rendered":"

[et_pb_section bb_built=”1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.19.4″]<\/p>\n

Ser o gestor de uma infraestrutura urbana (energia el\u00e9trica, g\u00e1s, \u00e1guas de qualquer tipo ou cobertura de r\u00e1dio, televis\u00e3o ou m\u00f3vel)<\/strong> requer o controlo de um elevado n\u00famero de pequenas instala\u00e7\u00f5es aut\u00f3nomas distribu\u00eddas geograficamente sem pessoal pr\u00f3ximo e que, al\u00e9m disso, maioritariamente devem trabalhar de forma aut\u00f3noma. \u00c9 evidente que a gest\u00e3o destes sites deve cobrir necessidades bem diferentes das de ambientes como a ind\u00fastria ou a dom\u00f3tica<\/strong>. O seu controlo n\u00e3o pode falhar (todos sabemos o caos que um apag\u00e3o provoca num ambiente urbano) nem perder-se informa\u00e7\u00e3o para a sua gest\u00e3o, mas, ao mesmo tempo, normalmente, n\u00e3o se disp\u00f5e de pessoal<\/strong> nas redondezas nem de um grande canal de comunica\u00e7\u00e3o com a instala\u00e7\u00e3o. Assim, a partir da Logitek M2M<\/strong>, propomos neste post um conjunto de a\u00e7\u00f5es com o objetivo de prevenir erros, aumentar a seguran\u00e7a, garantir o controlo e assegurar uma resposta r\u00e1pida no controlo, comunica\u00e7\u00e3o e supervis\u00e3o destas instala\u00e7\u00f5es n\u00e3o vigiadas. Um “Dec\u00e1logo de boas pr\u00e1ticas para a comunica\u00e7\u00e3o, controlo e supervis\u00e3o de instala\u00e7\u00f5es n\u00e3o vigiadas”<\/strong> que veremos em dois posts consecutivos. Estes s\u00e3o os primeiros 5 pontos: <\/p>\n

\"\"<\/p>\n

1) Ter elementos apropriados<\/strong> para o seu sistema n\u00e3o \u00e9 negoci\u00e1vel. Estas instala\u00e7\u00f5es costumam trabalhar em ambientes exigentes<\/strong> e isso deve ser tido em conta. Por muito que os elementos de controlo e comunica\u00e7\u00e3o possam estar em arm\u00e1rios el\u00e9tricos, estes sites costumam sofrer temperaturas extremas no ver\u00e3o e no inverno, acumular p\u00f3, ter pequenas varia\u00e7\u00f5es el\u00e9tricas, humidade\u2026 ou seja, os elementos devem ser refor\u00e7ados, instal\u00e1veis em calha DIN, com intervalo de temperatura e humidade<\/strong> alargados e ter certa flexibilidade el\u00e9trica. Ainda que tenha diversas funcionalidades ou uma grande pot\u00eancia de processamento, uma placa eletr\u00f3nica sem um encapsulamento deste tipo n\u00e3o \u00e9 uma solu\u00e7\u00e3o vi\u00e1vel. 2) Assegurar a alimenta\u00e7\u00e3o<\/strong>. A maior parte das perdas de alimenta\u00e7\u00e3o n\u00e3o previs\u00edveis costumam ser de curta ou m\u00e9dia dura\u00e7\u00e3o, nunca mais de meio dia, pelo que ter uma redund\u00e2ncia de alimenta\u00e7\u00e3o para o site costuma ser \u00fatil e suficiente. Este sistema pode ser uma dupla entrada de tens\u00e3o de outra subesta\u00e7\u00e3o ou fornecedor<\/strong>, um SAI aut\u00f3nomo ou at\u00e9 umas baterias recarregadas por pain\u00e9is solares. Evidentemente, sempre que a entrada principal falhe, dever\u00e1 ser reportado ao sistema. 3) Controlo aut\u00f3nomo<\/strong>. Em qualquer circunst\u00e2ncia ou problema, a instala\u00e7\u00e3o deve funcionar ou, pelo menos, minimizar os riscos<\/strong>. Para cumprir estas premissas, uma arquitetura de edge computing<\/strong> \u00e9 a op\u00e7\u00e3o mais fi\u00e1vel. <\/p>\n

\"\"<\/p>\n

O controlo da instala\u00e7\u00e3o, a sua programa\u00e7\u00e3o e l\u00f3gica de atua\u00e7\u00e3o devem estar nos elementos de controlo do pr\u00f3prio site (tipicamente RTUs). Evidentemente, o centro de controlo (CC) deve interagir com as RTUs, parametriz\u00e1-las, ativar um ou outro programa, etc., mas a instala\u00e7\u00e3o tem de poder trabalhar autonomamente<\/strong> em caso de perda de comunica\u00e7\u00e3o com o CC. Outro motivo para justificar esta forma de trabalhar s\u00e3o as caracter\u00edsticas das redes de comunica\u00e7\u00f5es<\/strong>. Evidentemente, n\u00e3o t\u00eam as mesmas lat\u00eancias nem se disp\u00f5e da mesma largura de banda numa rede de F.O., cablada ou Wi-fi do que num site ligado por GPRS. Esse atraso de segundos pode provocar acidentes (sobretens\u00f5es, por exemplo) num grande n\u00famero de dispositivos enquanto os equipamentos de controlo continuam \u00e0 espera de uma resposta do CC. A arquitetura que a IoT<\/strong> tanto prodiga, onde se enviam todos os dados para uma Cloud<\/strong> e que os elementos que interagem com ela tomam as decis\u00f5es, n\u00e3o deve aplicar-se, ou pelo menos, n\u00e3o hoje em dia. 4) Estrat\u00e9gia PUSH<\/strong>. Em linha com o controlo aut\u00f3nomo, os gestores da instala\u00e7\u00e3o devem ser avisados imediatamente se tiver ocorrido um alerta ou a\u00e7\u00e3o concreta, sem esperar que o CC, na sua rotina de supervis\u00e3o, descubra que algo grave aconteceu. As RTUs devem poder enviar mensagens de forma ativa<\/strong> para as situa\u00e7\u00f5es onde n\u00e3o \u00e9 recomend\u00e1vel esperar que lhes consultem. Isto implica utilizar protocolos de comunica\u00e7\u00f5es espec\u00edficos e\/ou m\u00e9todos mais tradicionais como SMS ou correios eletr\u00f3nicos. \u00c9 de destacar que esta estrat\u00e9gia tem uma derivada. Uma estrat\u00e9gia PUSH n\u00e3o tem sentido sem uma gest\u00e3o autom\u00e1tica de alarmes<\/strong> que permita estabelecer, para um problema concreto, um Workflow de a quem avisar (tendo em conta hor\u00e1rio e calend\u00e1rio), como e se a RTU deve esperar confirma\u00e7\u00e3o ou n\u00e3o. \"\"<\/p>\n

5) Interoperabilidade.<\/strong> Quem trabalhou com instala\u00e7\u00f5es deste tipo sabe que, tipicamente, coexistem tanto elementos que se consideram obsoletos (mas que continuam a ser funcionais) como os novos dispositivos que se foram instalando para adicionar funcionalidades. Perante este problema, deve evitar-se colocar diferentes elementos de controlo ou intelig\u00eancias paralelas<\/strong> que criem uma esp\u00e9cie de Frankestein tecnol\u00f3gico. Isto sempre implica que os gestores do sistema devam conhecer m\u00faltiplas tecnologias diferentes, cada um com o seu software particular, um suporte t\u00e9cnico distinto, etc. Assim, se se deseja centralizar o controlo e as comunica\u00e7\u00f5es do site n\u00e3o vigiado num \u00fanico elemento, dever\u00e1 apostar-se por RTUs com presta\u00e7\u00f5es de interoperabilidade<\/strong>. Isso implica saber interagir com: <\/p>\n