Notas do provedor de IoT. Propriedade

Continuação da série de artigos. Início:


A primeira parte → || → A segunda parte → || → A terceira parte

Gostaria de dedicar meu quarto artigo a um pensamento importante. Fui solicitado por vários comentários e mensagens no PM.

A Internet das Coisas ainda é muito jovem. Está lentamente retirando cada vez mais esferas para si e está sendo utilizado em áreas cada vez maiores. No entanto, como qualquer nova tecnologia, agora a IoT está apenas de pé. De fato, as primeiras regras e recomendações mal aparecem, como e com base em qual tecnologia implantar a rede. E ninguém sabe a resposta exata para a pergunta de qual padrão “voará” e qual irá afundar no esquecimento. E eu não sei. Só posso assumir, com base na análise de mercado, os prós ou contras de tecnologias individuais.


Então, por que tudo o mesmo LoRaWAN?


No meu primeiro artigo, argumentei: existe um espectro não licenciado, economia de bateria e alta imunidade a ruídos. Mas, em um grau ou outro, outros padrões também têm isso. Eles também sabem como viver com a bateria por um longo tempo, e também trabalham em 868. Talvez não pareçamos lá, a topologia em estrela não se enraizará e será substituída por redes mesh.


Tudo é possível. No entanto, LoRa tem uma vantagem importante que nem todos estão cientes. Este não é um padrão proprietário. Ou seja, ele não está focado em uma empresa, em um fornecedor. É mais ou menos aberto e é produzido por muitos fabricantes.


Não vamos dissimular, a bola ainda é regida pelo desenvolvedor, a empresa francesa Semtech. Só ela faz cristais para batatas fritas. E sua influência é sentida na Aliança LoRa. No entanto, os franceses escolheram um modelo de negócios bem-sucedido. A própria produção de chips está à mercê de várias outras empresas, a especificação é de domínio público e a produção de terminais LoRa agora pode ser estabelecida no porão.



E o mais importante, tudo o que honestamente suporta o LoRaWAN é compatível entre si.
Por que isso é importante?


Qualquer padrão fechado em um fabricante-desenvolvedor acarreta um risco óbvio. O fabricante pode desaparecer e você ainda terá uma pilha de ferro comprado, mas não útil, em suas mãos. Essa ameaça aumentará se o software for implantado não em seus servidores, mas na nuvem do fabricante. Por isso, imediatamente demitimos, por exemplo, "Swift". Pode ser dez vezes melhor em características, nem vou discutir sobre esse assunto. É apenas proprietário do começo ao fim. Se você escolher como uma tecnologia, se ligará a laços tangíveis à Swift Telematics. A empresa é maravilhosa, seu diretor é um engenheiro muito agradável e extremamente entusiasmado. No entanto, dependendo de suas decisões, é de alguma forma míope.


Semelhante ao Vaviot com seu NB-Fi. Já é mais interessante, o Vaviot decidiu abrir e publicar o código fonte no Github. Imediatamente, muitos notaram que era suspeitamente semelhante ao SigFox, apenas levemente dopado, mas não o ponto. Assim que várias empresas independentes assumem a produção do NB-Fi, ele já pode ser considerado para projetos reais. Claro, o NB-Fi com segurança é muito triste, porque realmente inicia um ataque repetido. Mas agora estamos discutindo o conceito, não os detalhes.


Eu acho que o momento com um único fornecedor é óbvio para muitos. No entanto, há mais uma coisa que nem todo mundo entende. É por isso que as soluções de código aberto são tão populares. Quando um desenvolvedor abre e coloca a documentação em exibição pública, quando ele entrega a produção para dezenas de empresas e centenas de empresas implantam redes sem a participação dele, somente então os bugs realmente são divulgados. Uma enorme comunidade está estudando a tecnologia sob um microscópio, algumas estão entusiasmadas, outras estão trabalhando por razões. Todas essas pessoas pensam de maneira diferente, falam idiomas diferentes, têm níveis de habilidade diferentes. E eles vão encontrar. Eles vão encontrar tudo o que é possível.


O LoRaWAN é freqüentemente chamado de padrão com vazamento para inúmeras falhas. Aqui, as chaves de sessão podem viver por vários meses (falaremos sobre isso no tópico de segurança), não é o uso mais eficiente do espectro, existem truques sobre como introduzir uma terminação em um estupor.


Sim, é estúpido negar. Mas tudo isso sabemos apenas porque o LoRa é muito bem estudado pelas mesmas pessoas que tiveram acesso a ele.
Outros padrões têm exatamente os mesmos problemas. Só que nem sempre sabemos sobre eles. Talvez alguém diga: proximidade também é proteção. Em parte sim. Mas, de acordo com a lei de Murphy, se o problema for possível, isso acontecerá em algum lugar.


Com o LoRaWAN, pelo menos sabemos para onde olhar e o que temer. Com os proprietários, isso não funcionará. Seus problemas surgirão no momento mais inoportuno. E nós, em virtude de nossa ignorância, nem sequer entendemos o que aconteceu.


E a LoRa tem toda uma Aliança que continua a se desenvolver. Em outubro, a especificação 1.1 foi lançada. De pouco uso na prática, em qualquer caso, não vi dispositivos com suporte para novos itens. Mas se você se aprofundar, fica claro - entre outras coisas, muitos bugs foram corrigidos. Quando os engenheiros se sentaram no trabalho, eles já sabiam o que trabalhar primeiro.


Como os proprietários desenvolverão seu padrão (se houver)? Obviamente, modifique e melhore, sem perceber que um erro crítico foi migrado para a versão atualizada.


Vamos fazer de novo. Não há dogmas na Internet das Coisas, estamos escrevendo uma história aqui e agora. Dou-lhe meus argumentos, e eles não são tanto para LoRa quanto para código-fonte aberto em geral. O artigo acabou sendo um pouco filosófico, mas quero esclarecer a posição sobre a pergunta: "Por que você não usa isso, é melhor?" Pode ser melhor, mas será seriamente considerado apenas no caso de abertura, compatibilidade e multi-fornecedor. Na próxima edição do Notes, falaremos sobre segurança e mergulharemos na tecnologia novamente. Não sou a favor de um longo raciocínio, mas é melhor indicar a posição imediatamente e em geral do que em partes nos comentários.


PS Quando falei sobre a compatibilidade de dispositivos de diferentes fabricantes, quis dizer que você pode pendurar diferentes estações base em nosso servidor e acabar com diferentes fabricantes na rede. Mas se o primeiro for implementado em nosso país (agora os BS de três fornecedores estão trabalhando na rede), o segundo me pareceu um futuro muito distante. Um ano, talvez dois, antes que os clientes nos procurem com seus equipamentos.



Mas o futuro chegou mais rápido. O cliente entrou em contato conosco com o seu final, na verdade, ele pega uma rede de aluguel de nós. Demorou um pouco para caber no formato do pacote e funcionou.


C. Compatibilidade.


PPS Serei consistente e, em todo o artigo, acrescentarei o termo esquecido IMHO.

Source: https://habr.com/ru/post/pt412807/


All Articles