Tâche
Nous à l' équipe Synergy conçoit et fabrique des contrôleurs industriels. Ils sont conçus pour la comptabilité des ressources, la gestion des installations énergétiques et d'autres applications communément appelées Internet des objets (IoT). Souvent, nos clients n'ont pas seulement besoin de contrôleurs. Ils ont besoin d'une solution complète comprenant un système de contrôle.
Et ce système doit être proche de l'optimum: rapide, léger et fiable. Mais, selon l'anecdote bien connue, il est impossible de satisfaire simultanément toutes ces exigences. Nous devons rechercher un équilibre en fonction de la tâche, ce que nous avons essayé de faire.
Dans cet article, nous nous sommes limités à la classe des tâches lorsque les contrôleurs IoT sont directement connectés au système de contrôle ( IoT connecté directement ). Notre tâche est donc de développer un système de gestion qui devrait:
- transférer les données des capteurs connectés aux contrôleurs,
- envoyer des événements (par exemple, sur échauffement, ouverture de porte, perte de communication, etc.),
- transmettre les commandes de contrôle aux actionneurs,
Si le système se compose d'un grand nombre d'objets et / ou effectue des tâches importantes, il doit en outre:
- surveiller en permanence la présence de communication avec des objets,
- recueillir des statistiques sur votre travail,
- mettre à jour les paramètres et le logiciel des contrôleurs (sur demande);
- être protégé contre tout accès non autorisé. Pour l'État et les grandes entreprises privées, le système doit également se conformer à la législation sur le travail avec l'infrastructure d'information critique (CII). En particulier, les exigences de 187-FZ, FSB, FSTEC, les arrêtés du ministère des télécommunications et des communications de masse, etc.
Gestion sans serveur dédié
Pour plusieurs objets, le problème est simplement résolu avec le contrôle du réseau GSM au moyen de commandes SMS ou d'appels. Cette approche était populaire au début des années 2010, et ses avantages et inconvénients sont décrits, par exemple, ici . Pour les systèmes les plus sérieux, cette approche perd de sa pertinence aujourd'hui.
Un peu plus compliqué est le contrôle «manuel» des contrôleurs via IP dédié via le WEB ou la ligne de commande (CLI). Les contrôleurs doivent être connectés en permanence au réseau, avoir des adresses IP statiques «blanches» ou «grises». Vous pouvez également utiliser une adresse IP dynamique avec liaison à des noms de domaine statiques à l'aide de la technologie DynDNS ou similaire . Cela fonctionne bien s'il y a peu d'objets et s'il n'y a pas d'exigences particulières en matière de fiabilité.
Désavantages:
- , WEB () ;
- IP ;
- , NAT;
- IP . , GSM APN ;
- , «»;
- ().
Pour des démonstrations rapides, contrôle sur plusieurs objets, il suffit d'utiliser le contrôle par IP, SMS ou appels téléphoniques.
Ici, nous n'avons pas considéré la situation où un répartiteur fonctionne sur le même ordinateur et un système de contrôle est installé, car nous le considérons comme un cas dégénéré de l'élément suivant.
Gestion de serveur dédiée
Dans les autres cas, vous avez besoin d'un serveur avec une adresse IP dédiée, via laquelle les contrôleurs, les répartiteurs et les systèmes tiers se connecteront.
Si les contrôleurs transmettent des données uniquement en direction du serveur, par exemple des compteurs d'eau ou les appareils de navigation les plus simples (trackers), une connexion unidirectionnelle est suffisante. Dans ce cas, les contrôleurs doivent uniquement connaître l'adresse IP du serveur.
Dans notre tâche, un échange de données bidirectionnel est nécessaire pour mettre à jour le logiciel du contrôleur et transmettre des commandes. Pour organiser un tel échange, vous devez:
- lecture périodique des paramètres ou des commandes du serveur à l'initiative du contrôleur (acceptable si vous n'avez pas besoin d'une réponse rapide aux commandes), ou
- en utilisant une adresse IP statique ou des noms de domaine sur les contrôleurs afin que le serveur puisse les «atteindre» de lui-même, ou
- , . , MQTT, EGTS ( ). IP. , .
Lorsqu'il s'agit d'un système de contrôle basé sur une solution éprouvée et fiable, SCADA est la première chose à retenir. Et cela se justifie pleinement lorsqu'il s'agit de l'automatisation de la production ou d'une grande installation énergétique. En un mot, lorsque le système contient un grand nombre de capteurs et d'actionneurs de différents types. De tels systèmes nécessitent le développement de diagrammes mnémotechniques et d'algorithmes d'interaction avec les équipements uniques pour chaque objet, ce qui est parfaitement pensé dans SCADA.
Si vous avez besoin de surveiller et / ou de gérer des objets du même type (comme dans la tâche proposée), alors l'utilisation de SCADA peut rendre la solution trop «lourde» en raison de la complexité de la configuration, de la lourdeur de l'ajout d'objets standard et des exigences accrues pour les performances du serveur. Il est préférable d'utiliser l'un des systèmes de boîtes spécialisés du marché qui convient le mieux à la tâche. Par exemple:
- système de surveillance et de gestion des équipements de réseau - Système de gestion de réseau (SNMP, TR-069, CLI);
- système de comptage automatisé pour la chaleur, l'électricité, le gaz, l'eau. Pour faire court - ASKUE;
- système de suivi de navigation pour objets mobiles avec commande de systèmes embarqués;
- système de climatisation (ventilation, climatisation et chauffage) - CVC;
- système intelligent de maison / bureau / bâtiment;
- : , () , ;
- - , ..
Ces systèmes se chevauchent souvent les fonctionnalités les uns des autres. Par exemple, sur la base d'ASKUE, il est possible de mettre en œuvre le contrôle de l'éclairage extérieur, et sur la base de la "Smart House" pour contrôler le climat et l'accès. L'expansion de la fonctionnalité des systèmes «vivants» est en cours. De nouvelles API font leur apparition pour intégrer des produits en boîte dans les solutions client, ainsi que pour la prise en charge des fonctions personnalisées dans les logiciels en boîte. Un énorme avantage des produits en boîte est le fait qu'ils peuvent être achetés et mis sur votre serveur, après avoir reçu une solution aliénée qui fonctionne dans un circuit client fermé.
Si vous envisagez de vendre votre propre système sur le marché libre, vous devez comprendre qu'un concurrent peut sortir demain du fournisseur de logiciels en boîte d'aujourd'hui. En outre, l'utilisation de systèmes de boîtes comporte des risques supplémentaires tels que:
- augmentation du prix des licences,
- un contrôle faible sur le système (il n'y a pas de code source, même s'il y en a, il est extrêmement difficile à maintenir),
- de nombreux systèmes ne peuvent être utilisés qu'en tant que service cloud, ce qui peut être inacceptable pour les grands projets et / ou les projets gouvernementaux.
Développement basé sur des plateformes IoT
Si l'utilisation de logiciels en boîte n'est pas possible, il est judicieux de développer sur l'une des plates-formes IoT les plus populaires . Ces plates-formes contiennent des modules universels requis dans tout système IoT pour:
- enregistrement et suppression d'appareils IoT,
- authentification sécurisée des appareils IoT et maintien de la communication avec eux,
- travailler avec des données (bases de données optimisées pour différentes tâches),
- enregistrement des utilisateurs et gestion des droits d'accès,
- formation d'analyses basées sur les données collectées,
- générer des notifications pour les utilisateurs (SMS, E-Mail, push messages, ...),
- stocker les dernières données lues sur les appareils IoT,
- effectuer diverses actions sur des événements,
- visualisation des données, etc.
L'architecture du système sur la plateforme IoT est pratiquement indépendante de sa taille. Toutes les tâches liées à l'équilibrage de charge, à l'élimination des «freins» de la base de données et des fonctions «lourdes» sont assurées par la plateforme. De plus, le côté serveur de l'application est rapidement assemblé à partir de "cubes" - microservices. Le temps de mise sur le marché et le coût de la solution, qui dépend directement du paiement du travail des programmeurs, sont réduits.
Un système sur une plateforme IoT peut être développé en un minimum de temps. Son architecture ne changera pas beaucoup avec l'augmentation de la taille.
Avantages du développement sur une plateforme IoT basée sur le cloud:
- . AWS . . .
- , , , MQTT- – . , .
- IoT . ( ) ( IoT ).
- .
- la tâche de développement principale peut être externalisée. À l'avenir, la solution sera en mesure de prendre en charge non seulement les développeurs du système d'origine, comme c'est généralement le cas. Après tout, les plates-formes IoT bénéficient d'un support technique puissant, sont bien documentées et le nombre de développeurs qui peuvent travailler avec elles ne cesse de croître.
Désavantages:
- les composants des plates-formes IoT fonctionnent uniquement dans les installations de leurs propriétaires, créent un système complètement aliénable qui fonctionnera dans le centre de données du client, éventuellement dans de rares cas;
- le coût d'utilisation d'une plate-forme IoT pour de grands projets peut être plus élevé que le coût de location de machines virtuelles dans un centre de données;
- la migration d'une plate-forme IoT vers une autre implique de modifier une quantité décente de code. Bien qu'il existe maintenant une tendance à la normalisation des API;
- toutes les plates-formes IoT ne sont pas déployées dans des centres de données en Russie, ce qui rend impossible leur utilisation dans l'intérêt des clients gouvernementaux.
Développement entièrement propre
Si les lacunes des solutions précédentes sont critiques, vous devez développer votre propre solution. Et quelle que soit la qualité du plan, les premières versions du système seront tordues.
Ses propres solutions sont souvent mises en œuvre sur la base de systèmes open source tels que ThingsBoard, OpenSCADA, MajorDoMo, Home Assistant, iobroker, Nokia glial. Pour les petits projets, ils peuvent être trop «lourds» en raison:
- long temps de développement et coûts financiers correspondants. Les comptes sont généralement en années-personnes;
- au fur et à mesure que le nombre d'objets augmente, des goulots d'étranglement apparaîtront sous la forme de bases de données lentes, de collecteurs, de générateurs de rapports, etc., pour la résolution desquels il sera nécessaire de changer l'architecture et de la compléter avec des équilibreurs et des ressources en double;
- les frais d’administration courante et de soutien technique.
Dans le même temps:
Son développement se justifie soit pour les commandes gouvernementales, soit pour des projets aux plans ambitieux et aux gros budgets, soit lorsque l'indépendance et la sécurité sont essentielles.
Si vous avez besoin d'une démonstration rapide ( MVP ), alors cela peut être fait sur une plate-forme IoT ou un logiciel en boîte, en adoptant des approches éprouvées, tout en développant votre propre grande solution en parallèle.
Conclusion
Sur la base de l'analyse de différents systèmes, nous proposons l'algorithme de sélection de système de contrôle suivant.
Pour les démonstrations et les petits projets IoT pour plusieurs objets, vous pouvez utiliser le contrôle direct sur IP, SMS ou via des appels GSM. Sinon, un système de niveau supérieur est requis. L'utilisation de SCADA est justifiée dans l'automatisation industrielle et dans les grandes installations énergétiques. Pour la comptabilité des ressources, la gestion des équipements réseau, le suivi, la sécurité, la "maison intelligente", etc. il est pratique d'utiliser une solution en boîte de la spécialisation requise. Développer des systèmes sur des plates-formes IoT est plus difficile, mais donne plus de perspective et de flexibilité. Les solutions sur les plates-formes IoT étrangères sont sérieusement limitées en termes d'échelle et de domaines d'application en Russie. Le plus difficile est le développement complètement propre. Et cela ne se justifie que pour les commandes gouvernementales et les projets les plus ambitieux.Dans le même temps, pour des démonstrations rapides et la copie des bonnes pratiques, il sera utile, en parallèle de votre propre développement, de faire un projet de design sur la plateforme IoT.
Enfin, nous souhaitons partager une petite prévision:
- dans les plateformes cloud IoT, il vaut la peine d'attendre l'apparition de modèles préconfigurés pour "Smart Home", ASKUE, NMS, ACS, etc. Cela simplifiera encore l'utilisation des plates-formes IoT et attirera un public encore plus large.
- Les développeurs traditionnels de SCADA et d'autres solutions en boîte offriront davantage d'outils aux développeurs externes qui ont fait leurs preuves sur les plates-formes IoT. Il est peu probable que les solutions en boîte fermée résisteront à la concurrence du marché.
- Les plates-formes IoT nationales destinées aux clients publics et privés se développeront encore plus activement.
- Les API des différentes plates-formes IoT deviendront plus similaires au fil du temps. De ce fait, la transition d'une plateforme IoT à une autre sera simplifiée.
Dans le prochain article, plus technique, nous parlerons de notre projet de surveillance des systèmes de communication sur la plateforme AWS et des contrôleurs GIC .
N'oubliez pas d'écrire dans les commentaires si nous avons manqué quelque chose d'important. L'un des objectifs de notre blog est d'obtenir des commentaires constructifs.