Olá, caros amantes da Internet das Coisas. Neste artigo, gostaria de falar novamente sobre habitação e a pesquisa de dispositivos de medição.
Periodicamente, um novo jogador importante no setor de telecomunicações anuncia como em breve entrará neste mercado e dominará tudo. Sempre que ouço esses relatos, penso: 'boa sorte, pessoal!'
Vocês nem imaginam aonde estão indo.
Para que vocês entendam a magnitude do problema, vou resumir um pouco da nossa experiência no desenvolvimento da plataforma 'Cidade Inteligente'. Focando naquela parte que lida com a gestão.

A ideia geral e as primeiras dificuldades
Se falarmos não sobre dispositivos de medição individuais, mas sobre aqueles que estão em porões, caldeiras e empresas, a maior parte deles agora está equipada com saída telemétrica. Mais raramente com saída por impulso, e mais frequentemente — RS-485/232 ou Ethernet. Geralmente, os dispositivos de medição mais 'lucrativos' são aqueles que medem calor. É por sua gestão que estão dispostos a pagar em primeiro lugar.
Já abordei em minha artigo as particularidades do RS-485. Em resumo, é apenas uma interface de transmissão de dados. Essencialmente, são requisitos para impulsos elétricos e linhas de comunicação. A descrição dos pacotes vai um nível acima, no padrão de transmissão de dados que opera acima do RS-485. E qual será esse padrão depende do fabricante. Frequentemente Modbus, mas não necessariamente. Mesmo que seja Modbus, ele pode estar um pouco modificado.
Basicamente, para cada dispositivo de medição precisa haver um script de coleta que saiba ‘dialogar’ com ele e realizá-la. Isso significa que a sistemática de gestão é um conjunto de scripts para cada contador individual. Um banco de dados onde tudo isso é armazenado. E uma interface do usuário, onde ele pode gerar o relatório necessário.

Parece simples. O diabo, como sempre, está nos detalhes.
Vamos começar pela primeira parte.
Scripts
Como escrever? Bem, é óbvio que você precisa comprar um dispositivo de medição, desmontá-lo, aprender a se comunicar com ele e integrá-lo na plataforma geral.
Infelizmente, esta solução cobrirá apenas parte de nossas necessidades. Normalmente, um contador popular tem várias gerações, e o script para cada geração pode diferir. Às vezes um pouco, às vezes significativamente. Ao comprar algo, você recebe a última geração. Já o assinante provavelmente terá algo mais antigo. Isso não é mais vendido nas lojas. E o assinante não vai trocar o equipamento de medição.
Daí surge o primeiro problema. A escrita de tais scripts é uma estreita ligação entre os desenvolvedores de software e os engenheiros no campo. Compramos a última geração, escrevemos um template inicial e depois o modificamos em dispositivos reais. Fazer isso em um laboratório é irreal, somente no trabalho com assinantes ativos.
Levamos um bom tempo para criar essa conexão. Agora o algoritmo está refinado. Os templates iniciais eram constantemente corrigidos e complementados, dependendo do que encontramos na prática. Claro, o assinante era avisado se, de repente, seu contador não era exatamente "igual". Quando tal dispositivo aparecia, ele se conectava de acordo com o esquema padrão e o script de consulta era modificado conforme necessário. Durante a integração, o assinante trabalha gratuitamente. Eles são informados de que estão em modo de teste. O próprio processo de integração é algo bastante imprevisível. Às vezes, precisa-se fazer poucas correções. Outras vezes, é um processo complexo que requer deslocamento ao local, revisão de literatura e superação sequencial de obstáculos.
A tarefa não é simples, mas é viável. O resultado é um script funcional. Quanto maior a biblioteca de scripts, mais fácil se torna a vida.
O segundo problema.
Cartões tecnológicos de conexão
Para que você compreenda a complexidade desse trabalho, vou dar um exemplo. Vamos pegar o muito popular contador de calor VKТ-7.
O nome por si só ainda não diz nada. O VKТ-7 possui várias soluções de hardware. Qual é a interface interna?

Existem diferentes opções. Pode haver saída em um conector padrão DB-9 (que é RS-232). Pode haver apenas um bloco de terminais com contatos RS-485. Pode até mesmo ter um cartão de rede com RJ-45 (neste caso, ModBus é encapsulado em Ethernet).
Ou talvez absolutamente nada. Apenas um medidor exposto. Nele, é possível instalar uma saída de interface, que é vendida separadamente pelo fabricante e tem um custo. O principal problema - para sua instalação é necessário abrir o medidor e romper os selos. Ou seja, nesse processo está envolvida a organização fornecedora de recursos. Eles são notificados de que os selos serão rompidos, é marcada uma data e nosso engenheiro, na presença de um representante da fornecedora, realiza as modificações necessárias, após o que o medidor é novamente selado.
Dependendo da interface instalada, são feitas modificações adicionais. Por exemplo, decidimos conectar o medidor por cabo. Esta é a opção mais simples; se há um switch nosso a 100 metros de distância, então complicar com LoRa é desnecessário. É mais fácil conectá-lo à nossa rede, em um VLAN isolado.
Para RS-485/232 é necessário um conversor para Ethernet. Muitos logo se lembrarão do MOXA, mas isso é caro. Para nossas soluções, escolhemos uma solução chinesa mais barata.
Se a saída é imediatamente Ethernet, o conversor não é necessário.
Pergunta. Suponha que nós mesmos instalamos a saída de interface. Podemos facilitar a vida e colocar Ethernet em todos os lugares desde o início?
Nem sempre isso é possível. É necessário olhar para a execução do gabinete. Pode ser que não haja o buraco necessário para que a interface se encaixe corretamente. E o medidor, lembrando, fica no nosso porão. Ou na caldeira. Lá a umidade é alta, não se pode comprometer a vedação. Modificar o gabinete com uma lixa é uma má ideia. É melhor instalar algo que não exija grandes modificações desde o início. Muitas vezes, RS-485 é a única opção.
Além disso. O medidor está conectado à alimentação garantida? Se não, ele funciona com bateria. Nesse modo, foi projetado para uma leitura manual uma vez por mês por três minutos. Um acesso constante ao VKT-7 descarregará sua bateria. Portanto, é necessário prolongar a alimentação garantida e instalar um conversor de tensão.
Para cada fabricante de medidores, o módulo de alimentação é diferente. Isso pode ser um bloco externo em trilho DIN ou um conversor embutido.
Portanto, em nosso armazém, deve sempre haver um conjunto de várias interfaces e módulos de alimentação para cada medidor. A nomenclatura é impressionante.
Claro, no final, tudo isso será pago pelo assinante. Mas ele não vai esperar um mês até que chegue o dispositivo necessário. E precisa de um orçamento para a conexão aqui e agora. Portanto, a margem tecnológica recai sobre nós.
Tudo o que descrevi se traduz em um mapa técnico claro de conexão, para que os engenheiros no campo não fiquem se perguntando que tipo de equipamento encontram no porão e o que é necessário para seu funcionamento.
O mapa técnico está alinhado com o regulamento geral de conexão. Afinal, não basta conectar o medidor à nossa rede; é preciso atribuir o VLAN apropriado à porta do switch, fazer diagnósticos e realizar uma sondagem de teste. Estamos nos esforçando para automatizar todo o processo ao máximo, para evitar erros e não sobrecarregar os engenheiros.
Bem, escrevemos os mapas técnicos, regulamentos, automação. E estabelecemos a logística.
Onde mais podem estar as armadilhas?
Os dados são lidos e enviados para o banco de dados.
Esses números não fazem diferença para o assinante. Ele precisa de um relatório. De preferência no formato que já conhece. Melhor ainda se for imediatamente apresentado em um formato compreensível que ele pode imprimir, assinar e entregar. Portanto, é necessário uma interface simples e clara que mostre as informações sobre o medidor e possa gerar automaticamente o relatório.
Aqui nossa confusão continua. Acontece que existem vários formatos de relatório. Eles, em essência, refletem a mesma coisa (calor consumido), mas de maneiras diferentes.
Alguns assinantes relatam em valores absolutos (ou seja, na coluna de consumo de calor, os valores começam com a instalação do medidor), enquanto outros relatam em deltas (quando informamos o consumo durante um período sem referência aos valores iniciais). Na prática, eles usam normas não padronizadas, mas sim práticas estabelecidas. Já houve casos em que os assinantes viam todos os valores que precisavam (a quantidade de calor consumido, o volume do fluido térmico fornecido e dispensado, a diferença de temperaturas), mas as colunas no relatório estavam fora de ordem.
Daí o próximo passo — o relatório deve ser personalizável. Ou seja, o assinante escolhe a sequência dos elementos e quais recursos estão disponíveis em seu documento.
Aqui está um ponto interessante. Tudo bem se nosso dispositivo de medição estiver instalado corretamente. Mas acontece que a empresa de instalação, ao instalar o ITP, cometeu um erro e configurou o horário do dispositivo de medição incorretamente. Encontramos dispositivos que pensam que estamos em 2010. Em nosso sistema, isso aparecerá como leituras zeradas na data atual, enquanto o consumo real será se escolhermos o ano de 2010. Aqui, os deltas são muito úteis. Ou seja, dizemos que nas últimas 24 horas, consumimos tanto.
Parece complicado, não é? É tão difícil ajustar o relógio?
Exatamente com o VKT-7 isso levará ao completo zeramento do medidor e à exclusão de arquivos dele.
O assinante será forçado a provar às concessionárias que não instalou o ITP ontem, mas sim há cinco anos.
E, finalmente, a cereja do bolo.
Certificação
Temos um dispositivo de medição e temos um relatório. Entre eles, nosso sistema que gera esse relatório. Você confia nele?
Eu confio. Mas como provar que não há nenhuma alteração interna, que não distorcemos os valores? Isso já é uma questão de certificação. O sistema de consulta deve ter um certificado que comprove sua imparcialidade. Todos os grandes sistemas, como LERS, Eu Energia e outros, possuem tal certificado. Nós também o recebemos, embora isso seja caro e demore muito tempo.
Claro, sempre é possível cortar caminho e comprar algo pronto. Mas você terá que pagar ao desenvolvedor. E o desenvolvedor pode pedir não apenas uma taxa de adesão, mas também uma mensalidade. Ou seja, seremos obrigados a compartilhar uma parte do nosso lucro com ele.
Por que tudo isso?
O principal problema não está nisso. O desenvolvimento de um sistema próprio também é muito caro e muito mais difícil. No entanto, ele oferece uma vantagem importante. Entendemos claramente como isso funciona. Podemos escalá-lo facilmente e podemos modificá-lo se surgir a necessidade. O assinante recebe um serviço mais completo, enquanto nós temos controle total sobre o processo.
É exatamente por isso que escolhemos o segundo caminho. Investimos um ano de trabalho de nossos desenvolvedores e engenheiros de campo nele. Agora, entendemos claramente o funcionamento de toda a cadeia.
Olhando para trás, percebo que sem o conhecimento adquirido, eu simplesmente não conseguiria interpretar corretamente o comportamento anômalo de determinado medidor.
Além disso, com base no sistema de gerenciamento, é possível criar algo maior. Alarmes para consumo excessivo, relatórios de falhas. Em breve, teremos um aplicativo móvel pronto.
Nós fomos ainda mais longe e nossa plataforma (senão não seria assim chamada) passou a aceitar solicitações dos cidadãos, permitindo gerenciar nossos 'interfones inteligentes', o controle da iluminação pública e vários outros projetos que ainda não mencionei.

Tudo isso é complicado, desgastante e demorado. Mas o resultado vale a pena. Os assinantes recebem um produto abrangente pronto para uso.
Todo operador que planeja entrar no setor de utilidades públicas com certeza seguirá por esse caminho. Ele conseguirá?
Essa é a questão. O problema não está apenas no dinheiro. Como mencionei anteriormente, é necessária uma ligação entre o trabalho de campo e o desenvolvimento. Nem todos os grandes players estão acostumados com isso. Se os seus desenvolvedores estão em Moscovo e as conexões são feitas em Novosibirsk, o seu tempo até ter um produto pronto se alonga consideravelmente.
O tempo dirá quem se manterá nesse mercado e quem dirá 'deixa pra lá!' Mas uma coisa eu sei com certeza — chegar e conquistar uma fatia do mercado apenas com dinheiro não será suficiente. Esse processo exige abordagens não convencionais, bons engenheiros, investigação na regulamentação, comunicação com fornecedores e assinantes, constante identificação e superação de obstáculos.
P. S. Neste artigo, concentrei-me intencionalmente no aquecimento e não mencionei eletricidade ou água. Também descrevo a conexão via cabo. Se tivermos uma saída impulsiva — existem suas nuances, como verificações obrigatórias após a instalação. Pode ser que o cabo não alcance, então usamos LoRaWAN. Descrever toda a nossa plataforma e as etapas do seu desenvolvimento em um único artigo é simplesmente impossível.
Fonte: habr.com
