Notas do provedor de IoT. LoRaWAN e RS-485

Olá queridos amantes da Internet das Coisas. Continuo minha série de artigos.

Assim, aprendemos a trabalhar com a saída de pulso dos contadores e a criptografia masterizada. Qual é o próximo passo? A resposta é óbvia. RS-485.

Um pouco de teoria. O RS-485 (padrão recomendado) é uma interface de camada física assíncrona. Ele ganhou imensa popularidade na Internet Industrial, variando de serviços públicos e terminando em várias fábricas e empresas.

Em princípio, quase qualquer medidor que queira nos fornecer não um, mas vários parâmetros, provavelmente, serão equipados com RS-485. Menos comumente, RS-232 ou M-Bus, mas por enquanto vamos deixá-los de lado e analisar o exemplo mais revelador. Mais precisamente, problemas em trabalhar com ele.

Problema de velocidade

RS-485 é um padrão com fio. LoRa - sem fio. É lógico que deve haver um determinado dispositivo capaz de fazer amizade com eles.

Tudo bem. Quase todos os fabricantes do terminal da linha têm um módulo de rádio com suporte RS-485. Ele trabalha com o princípio de um canal transparente. Todos os pacotes que passam pelo fio são embalados como uma carga útil de pacotes LoRaWAN e enviados à transmissão. Ou são recebidos e convertidos em impulsos elétricos.

E aqui está o primeiro problema. O RS-485 é uma interface de alta velocidade. Os pacotes vão a velocidades de vários kilobits / s ou até várias dezenas. Por exemplo, uma das velocidades típicas do Modbus é 9,6 kbit / s.

O LoRa, mesmo com o melhor SF = 7 (125 kHz, 4/5), comprime 5,5 kbit / s. Com SF mais alto, haverá ainda menos.

Isso significa que o levantamento dos valores de algum medidor elétrico não levará segundos nem mesmo dezenas de segundos. A pontuação dura alguns minutos. E isso é com um tempo de espera ajustado corretamente. Se você deixar as configurações padrão, sua pesquisa provavelmente terminará em um erro de tempo limite. Fico em silêncio sobre as restrições no comprimento dos pacotes LoRaWAN. Há apenas problemas.

Problema de votação

Com saídas de pulso, tudo é simples. Contamos os pulsos, multiplicamos pelo preço da divisão e obtemos a leitura do medidor. Qualquer interface simples pode lidar com isso. E essa interface, além da simplicidade, será mais universal.

Com o RS-485, tudo é muito pior. Surpreendentemente, muitos não entendem uma coisa importante.
O RS-485 NÃO É UM PROTOCOLO DE TROCA! Ele não especifica o formato dos pacotes que entram nele. De fato, é apenas um meio de transmissão. Somente características elétricas e temporais da interface são especificadas. Isso é tudo! Tudo no topo já deve ser desmontado separadamente.

E há algo a desmontar! Além do nosso ambiente, todo fabricante pode terminar o que deseja. Bem, ou o que acabou sendo conveniente para ele pessoalmente. Por exemplo, o medidor de calor VKT-7 se comunicará conosco através do ModBus. E Energomera - através do GOST R IEC 61107-2001.

Todos esses protocolos são sobrepostos no meio de transmissão a partir de cima e têm um nível mais alto. Cada protocolo tem sua própria composição do quadro, exige que suas próprias equipes executem determinadas ações, fornece armazenamento diferente (e, portanto, pesquisa) de valores. Portanto, cada dispositivo precisa de seu próprio script de pesquisa. Além disso, mesmo dentro da estrutura de um protocolo (o mesmo ModBus), esse script será diferente de dispositivo para dispositivo.

Os protocolos em si não são secretos e, na maioria das vezes, são abertos. Além disso, o site de cada fabricante geralmente contém um utilitário gratuito com o qual você pode interrogar dispositivos. Mas esses utilitários não são universais e aprimorados para um fabricante. E lembramos que quase sempre temos um zoológico de dispositivos. E colocar vários programas no cliente ao mesmo tempo ... bem, isso não é muito conveniente.

Existem duas maneiras de sair. Ou escreva algo de sua preferência. Ou adote um programa no qual os scripts de pesquisa dos dispositivos mais populares já foram compilados. Existem muitas soluções prontas no mercado, por exemplo, "LERS-accounting" ou "YaEnergetik". Mas eles são pagos e custam um bom dinheiro. Bem como o desenvolvimento de seu software.

Além disso, se estivermos falando sobre a Internet industrial (ou seja, vamos além da estrutura dos serviços habitacionais e comunitários), soluções universais prontas não ajudarão mais. Como ser

De jeito nenhum.

Se você ainda planeja pesquisar no LoRa por meio de um canal transparente, ainda terá limites de velocidade e tempos limite. Pode não ser imediato e não com o primeiro dispositivo, mas isso acontecerá.

Problema padrão

Além de todos os problemas, temos mais um. Porque O RS-485 implica que podemos entrar em contato com o dispositivo a qualquer momento, o módulo de rádio LoRa com seu suporte deve ser da classe C. Ou seja, sempre ouça a transmissão e esteja pronto para responder.

Deixe-me lembrá-lo de que a classe C não implica em energia da bateria, mas o problema não é tão sério. Normalmente, o RS-485 é onde a energia externa pode ser obtida.

Pior é outro.

Por lei, podemos operar em duas faixas de frequência. Lembre-se do limite de 864-865 MHz? Não mais do que 0,1% do tempo no ar? Isso significa que cada dispositivo tomado separadamente pode estar no ar, por exemplo, não mais que 3,6 segundos por hora. Mas durante esse tempo, no SF = 12, nem empurramos três pacotes.

Você pode tentar extrair o máximo de canais 868.7-869.2. No entanto, outra restrição de padrões regionais da especificação LoRaWAN entra em vigor aqui - não mais de 1% do tempo de antena para cada dispositivo terminal (ciclo de serviço). OK, já é mais fácil, 36 segundos. Apenas o sentido ainda não é realmente.

Em algum momento, podemos dizer - oh, bem, essas bobagens! Vou sentar no ar pelo tempo que for necessário! Mas então aparece:

Problema de capacidade do éter

LoRa não é inútil trocar pacotes curtos e raros. De fato, todo o padrão é construído em torno disso. É necessário que cada dispositivo leve o mínimo de tempo possível no ar. Depois, reduziremos o risco de colisões e conseguiremos atingir essa densidade fantástica de vários milhares de radimódulos por BS. O que acontecerá se um módulo de rádio rabiscar em pacotes como uma metralhadora? Sua frequência é ocupada no momento da transmissão. E no momento da resposta, todas as frequências estão ocupadas, pois a estação base não ouve nada quando se transmite.

Obviamente, ninguém cancelou os pedidos em atraso para aumentar a capacidade. I.e. se houver dois BSs na área de cobertura de um módulo de rádio, um continuará a responder e o segundo poderá ouvir outro pacote. No entanto, o éter não é de borracha. Se cada módulo de rádio demorar um minuto para trocar pacotes, em uma hora não podemos pendurar mais de 60 dispositivos terminais por BS, isso estará sujeito à ausência de colisões. Muito pouco, especialmente se você se lembrar que o raio de ação de cada BS na cidade é de cerca de 2 km, ou talvez mais.

Então não?

Acontece que nossa rede LoRaWAN é limitada apenas a dispositivos com saída de pulso e sistemas de observação. Onde é registrado o fato de uma viagem?

Não.

Tentamos apenas usar o conceito de Internet das Pessoas, onde isso não pode ser feito. Concordo, é um hábito usar excessivamente um canal estável da Internet. Por exemplo, abra um vídeo, pegando ações no buffer e não assista. I.e. o tráfego passará, mas na verdade não será usado.

No entanto, tudo é diferente aqui. Temos pouca velocidade, também não há tempo no ar. Deve ser usado com moderação. O que você pode pensar?

A resposta está na superfície. Não conduza um monte de tráfego aéreo de protocolo pelo RS-485 através do LoRa.

O script de polling pode ser baixado no próprio módulo de rádio. Ele interrogará o medidor no local com uma certa frequência e nos enviará apenas valores pré-acordados e secos.

Este método tem dois pontos negativos:

• Esse módulo de rádio requer certos recursos de computação. Este não é um grande problema no nível atual de desenvolvimento de tecnologia.
• Esse módulo de rádio consome mais energia. Mas, no caso de um canal transparente, somos forçados a usar a classe C, que também não funciona com baterias. Isso é o que é.

Mas obtemos todas as informações necessárias em 2-3 pacotes. E então tudo se encaixará em um, se você precisar literalmente de vários parâmetros. De fato, muitas vezes acontece que não precisamos passar para ALL, um conjunto de valores bastante limitado.

O módulo de rádio pode transmitir dados, digamos, uma vez por hora. E no lado do servidor, nós os colocaremos em armazenamento. Se você precisar acessar o arquivo morto, o servidor nem precisará pesquisar o dispositivo.

Obviamente, você precisa ter algum tipo de módulo de rádio universal no qual vários scripts são carregados. E uma interface capaz de perceber essas informações. Esta não é uma maneira fácil, mas somente ela atende a todos os requisitos e limitações.

No momento, mais e mais fabricantes estão chegando a essa decisão. A Vega está preparando dispositivos semelhantes: icbcom, ORION M2M e outros já o possuem.

Porque Se usarmos uma interface auto-escrita, teremos desenvolvimentos semelhantes. Em algum momento, ficou claro que, se não nos aprofundássemos, simplesmente não poderíamos trabalhar.

Além dos truques para economizar tráfego, ainda precisamos de uma boa rede na qual os dispositivos operem no mínimo SF e na velocidade máxima. Eu enfatizo - não uma rede em que todos os dispositivos com SF = 7. Você ainda não conseguirá isso.

Uma rede que busca SF = 7. Isso significa planejamento competente e ADR.

Na saída, obtemos velocidades suficientes para os pacotes viajarem, ainda um grande número de módulos de rádio por BS e a capacidade de trabalhar com interfaces de nível superior à saída de pulso. O que foi necessário.

Colegas do PS, sou grato a todos pelo feedback. Diga-me, você ainda está interessado em aprender sobre o LoRaWAN ou a Internet das Coisas? As respostas podem me escrever no PM ou nos comentários. Para as solicitações mais interessantes ou massivas, os artigos serão publicados.