Notes du fournisseur IoT. Propriété

Suite de la série d'articles. Début:


La première partie → || → La deuxième partie → || → La troisième partie

Je voudrais consacrer mon quatrième article à une réflexion importante. J'ai été invité par de nombreux commentaires et messages dans PM.

L'Internet des objets est encore très jeune. Il enlève lentement de plus en plus de sphères pour lui-même et trouve son utilisation dans des zones de plus en plus vastes. Cependant, comme toute nouvelle technologie, l'IoT n'est plus que sur ses pieds. En fait, les premières règles et recommandations apparaissent à peine, comment et sur la base de quelle technologie déployer le réseau. Et personne ne connaît la réponse exacte à la question de savoir quelle norme «s'envolera» et laquelle plongera dans l'oubli. Et je ne sais pas. Je ne peux que supposer, sur la base d'une analyse de marché, les avantages ou les inconvénients des technologies individuelles.


Alors pourquoi tout de même LoRaWAN?


Dans mon premier article, j'ai plaidé pour: il existe un spectre sans licence, une économie de batterie et une immunité au bruit élevée. Mais, à un degré ou à un autre, d'autres normes ont également cela. Ils savent aussi vivre longtemps sur batterie, ils travaillent aussi en 868. Peut-être qu'on n'y regarde pas du tout, la topologie en étoile ne prendra pas racine et elle sera remplacée par des réseaux maillés?


Tout est possible. Cependant, LoRa a un avantage important que tout le monde ne connaît pas. Ce n'est pas une norme propriétaire. Autrement dit, il ne se concentre pas sur une seule entreprise, sur un seul fournisseur. Il est plus ou moins ouvert, et il est produit par de nombreux fabricants.


Ne nous dissimulons pas, la balle est toujours dirigée par le développeur, la société française Semtech. Elle seule fait des cristaux pour les chips. Et son influence se fait sentir dans l'Alliance LoRa. Cependant, les Français ont choisi un modèle économique réussi. La production de puces elle-même est à la merci de plusieurs autres sociétés, le cahier des charges est du domaine public et la production de terminaux LoRa peut désormais être établie au sous-sol.



Et surtout, tout ce qui prend honnêtement en charge LoRaWAN est compatible les uns avec les autres.
Pourquoi est-ce important?


Toute norme, fermée sur un seul fabricant-développeur comporte un risque évident. Le fabricant peut disparaître et vous aurez toujours un tas de fer acheté, mais pas utile dans les mains. Cette menace apparaîtra si le logiciel n'est pas déployé sur vos serveurs, mais dans le cloud du fabricant. C'est pourquoi nous avons immédiatement rejeté, par exemple, "Swift". Il peut être dix fois meilleur en termes de caractéristiques, je ne discuterai même pas sur ce sujet. C'est juste propriétaire du début à la fin. Si vous la choisissez comme technologie, vous vous liez à des liens tangibles avec la Swift Telematics. L'entreprise est formidable, leur directeur est un ingénieur très agréable et extrêmement enthousiaste. Cependant, dépendre de ses décisions est en quelque sorte à courte vue.


Similaire à Vaviot avec son NB-Fi. C'est déjà plus intéressant, Vaviot a décidé d'ouvrir et de publier le code source sur le Github. Immédiatement, beaucoup ont remarqué qu'il était étrangement similaire à SigFox, seulement légèrement dépassé, mais pas le point. Dès que plusieurs sociétés indépendantes se lancent dans la production de NB-Fi, il peut déjà être envisagé pour de vrais projets. Bien sûr, NB-Fi avec sécurité est très triste, car il y a vraiment lancé une attaque répétée. Mais nous discutons maintenant du concept, pas des détails.


Je pense que le moment avec un seul fournisseur est évident pour beaucoup. Cependant, il y a encore une chose que tout le monde ne comprend pas. C'est à cause de cela que les solutions open source sont si populaires. Lorsqu'un développeur ouvre et met la documentation à la disposition du public, lorsqu'il donne la production à des dizaines d'entreprises et que des centaines d'entreprises déploient des réseaux sans sa participation, alors seulement les bogues disparaissent vraiment. Une énorme communauté étudie la technologie au microscope, certains sont enthousiastes, certains travaillent pour des raisons. Toutes ces personnes pensent différemment, parlent des langues différentes, ont des niveaux de compétence différents. Et ils trouveront. Ils trouveront tout ce qui est possible.


LoRaWAN est souvent appelé la norme qui fuit pour de nombreux défauts. Ici, les clés de session peuvent vivre plusieurs mois (nous en parlerons dans le sujet de la sécurité), ce n'est pas l'utilisation la plus efficace du spectre, il y a des astuces pour introduire une terminaison dans la stupeur.


Oui, c'est stupide de le nier. Mais tout cela, nous le savons simplement parce que LoRa est très bien étudié par les personnes mêmes qui y ont eu accès.
D'autres normes ont exactement les mêmes problèmes. Seulement, nous ne les connaissons pas toujours. Peut-être que quelqu'un dira: la proximité est aussi une protection. En partie ainsi. Mais, selon la loi de Murphy, si des problèmes sont possibles, cela se produira quelque part.


Avec LoRaWAN, nous savons au moins où regarder et quoi craindre. Avec les propriétaires, cela ne fonctionnera pas. Leurs problèmes surgiront au moment le plus inopportun. Et nous, en raison de notre ignorance, ne comprenons même pas ce qui s'est passé.


Et LoRa a toute une alliance qui continue de se développer. En octobre, la spécification 1.1 a été publiée. Il a peu d'utilité dans la pratique, en tout cas, je n'ai pas vu d'appareils avec prise en charge de nouveaux éléments. Mais si vous y creusez, cela devient clair - entre autres, de nombreux bugs ont été corrigés. Lorsque les ingénieurs se sont assis au travail, ils savaient déjà sur quoi travailler en premier.


Comment les propriétaires développeront-ils leur norme (le cas échéant)? Évidemment, modifiez et améliorez, sans remarquer qu'une erreur critique a migré vers la version mise à jour.


Faisons-le encore. Il n'y a pas de dogmes sur l'Internet des objets, nous écrivons une histoire ici et maintenant. Je vous donne mes arguments, et ils ne sont pas tant pour LoRa que pour l'open source en général. L’article s’est avéré un peu philosophique, mais je veux clarifier la position sur la question: "Pourquoi n’utilisez-vous pas cela, est-ce mieux?" C'est peut-être mieux, mais cela ne sera sérieusement envisagé que dans le cas de l'ouverture, de la compatibilité et du multi-fournisseur. Dans le prochain numéro de Notes, nous parlerons de sécurité et nous replongerons dans la technologie. Je ne suis pas partisan d'un long raisonnement, mais il vaut mieux indiquer la position immédiatement et en général, que dans les pièces dans les commentaires.


PS Quand j'ai parlé de la compatibilité des appareils de différents fabricants, je voulais dire que vous pouvez accrocher différentes stations de base sur notre serveur et mettre fin à différents fabricants sur le réseau. Mais si le premier est mis en œuvre dans notre pays (maintenant les BS de trois fournisseurs travaillent sur le réseau), alors le second me semble un avenir très lointain. Un an, peut-être deux, avant que les clients ne viennent chez nous avec leur équipement.



Mais l'avenir est venu plus vite. Le client nous a contacté avec sa fin, en fait, il nous prend un réseau de location. Il a fallu un peu de temps pour s'adapter au format de l'emballage et cela a fonctionné.


C. Compatibilité.


PPS I sera cohérent et à tout l'article j'ajouterai le terme oublié IMHO.

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


All Articles