Commençons par le fer
J'ai travaillé une fois dans une usine, où ils ont sculpté toutes sortes d'appareils électroniques, pas très compliqués, et tombant parfois sous la définition d '«Internet des objets». Pour la plupart, toutes sortes de capteurs pour les systèmes de sécurité: fumée, bruit, pénétration, incendie, etc. L'assortiment de produits était large, les lots étaient parfois inférieurs à 500 pièces, et presque pour chaque produit, je devais faire un dispositif de test séparé - en fait, juste une boîte en fer blanc dans laquelle le produit a été testé, pressé par un couvercle et, par en dessous, des aiguilles de contact ont été pressées contre des points de contact sur une carte de circuit imprimé, quelque chose comme ceci:
Ainsi, il était possible de communiquer physiquement avec l'appareil. Le protocole de communication que nous avions était assez courant dans l'industrie - RS232 (port COM, un type d'UART). Toutes sortes de dispositifs contrôlés simples pour tester le produit final ont également été mis dans la boîte. Toutes ces instrumentations auxiliaires étaient contrôlées de la même manière. Toute la structure était très fragile et toutes sortes de problèmes faisaient partie de la routine quotidienne.
La gamme de problèmes était très large - mauvais contacts, inversion de la polarité lors de l'installation, problèmes avec le produit testé, avec les appareils de contrôle et de mesure, avec les aiguilles de contact, avec le code de test ... mais on ne sait jamais! Mais il était nécessaire de tester en permanence, et si les tests commençaient à «rouler» quelque part, l'un des ingénieurs devait piétiner la ligne et commencer à tout vérifier manuellement.
Tout d'abord, Docklight a été lancé - un bon utilitaire pour «communiquer» via les ports COM, mais il avait beaucoup de limitations. Et nous approchons ici de l'essence de la question.
Pourquoi Docklight ne me convenait pas?
Eh bien, allons-y.
- Le premier problème est que Docklight ne fonctionne que sur Windows. Ainsi, l'installation du "centre nerveux" sous la forme de RaspberryPi, qui connecterait tous les appareils, ou quelque chose comme ça, pourrait être oubliée. J'ai dû installer NUC - la solution la moins chère dans cette situation. Lourd, plutôt grand et pas le moins cher. Soit dit en passant, lorsque ces montages de test ont été traînés d'un endroit à l'autre, les NUC se sont beaucoup battus (bien que j'avoue que leur conception est assez solide).
- Le deuxième - l'accès à distance ne pouvait être effectué que par le biais du partage de bureau - il a été ralenti même par le biais du réseau local, et même par Internet, il était complètement boiteux.
- Troisièmement, chaque appareil avait son propre ensemble de commandes, et Docklight pouvait charger un fichier avec une liste de commandes. Si, par exemple, vous deviez partager une liste similaire avec quelqu'un du département, alors envoyez un e-mail avec le fichier ou ... envoyez un lien vers le fichier dans le dossier partagé! Naturellement, chaque installation Docklight nécessitait de tels fichiers localement, et tout cela devait être fait des dizaines (voire des centaines de fois) manuellement - pour chaque NUC, chaque ingénieur faisait glisser ses listes de commandes préférées et pratiques. Et dans la cour 2019, permettez-moi de vous rappeler ...
- Quatrièmement, Docklight ne vous permet pas d'associer automatiquement un port COM à un nom de périphérique: par exemple, Windows, lorsque vous connectez l'alimentation, communiquera avec le périphérique via COM12. Si vous voulez «tirer les chaînes» manuellement, alors dans Docklight vous devez ouvrir COM12. Comment pouvons-nous savoir qu'il s'agit uniquement de l'alimentation et non, disons, de SwitchBoard? Eh bien, vous pouvez consulter le gestionnaire de périphériques à chaque fois et essayer de ne pas oublier quel périphérique est connecté à quel port. En même temps, personne ne garantit que si vous retirez simplement l'appareil puis le rebranchez, le port précédent restera avec cet appareil. Bref, chaque fois que vous devez le faire manuellement. Et croyez-moi, à la fin de la journée, ma tête en tournait.
- Cinquièmement, chaque port avait besoin d'une copie distincte du programme et, bien sûr, toutes les opérations devaient être effectuées individuellement pour chaque périphérique, et bien que Docklight prenne en charge les scripts, il n'y a pas d'interaction entre les instances individuelles.
Ensuite. Aucune intégration avec aucun autre produit n'a été fournie. Cela semble être une bagatelle, mais voici une situation où il a chauffé à blanc: le test est tombé, et nous devons comprendre pourquoi. Tout d'abord, vous devez vous connecter aux appareils et voir s'ils sont morts du tout. Nous allons au gestionnaire de périphériques, regardons sur quel port se trouve notre appareil, ouvrons Docklight, initions la communication avec notre port ... Erreur. Merde! J'ai oublié d'arrêter le service installé sur le NUC et conserve tous les ports. Exclusif, vous savez. D'accord, nous ralentissons le service, ouvrons le port, chargeons le fichier avec les commandes de l'appareil, envoyons les commandes, nous obtenons (ou n'obtenons pas) les réponses, nous résolvons le problème. Nous relançons le test, il se bloque à nouveau ... Oh, bon sang, j'ai oublié de fermer Docklight et de redémarrer le service. Tout semble être sans erreur. Mais c'est pour les deux prochaines heures, jusqu'à ce que quelque chose se passe de nouveau. Et croyez-moi, il était nécessaire de résoudre ces problèmes plus souvent que nous le souhaiterions.
Eh bien, et bien sûr, à propos des extensions, ajoutez. il ne pourrait pas y avoir de fonctionnalités ou similaires - le produit est fermé, écrit depuis longtemps (il semble qu'ils ne soient plus spécialement développés), il n'y a pas de personnalisation.
Eh bien, j'ai décidé de faire quelque chose de mien, mais de corriger (ou d'améliorer) la situation avec les problèmes décrits.
Il s'est avéré quelque chose comme Zabbix, mais avec un affûtage pour une situation spécifique.
Quelle est donc la différence?
Il est peut-être judicieux de commencer par une description générale de l'architecture, puis d'entrer dans les détails.
Le schéma ressemble à ceci:
Nous avons un agent qui fonctionne à la station à laquelle nos appareils sont physiquement connectés. L'agent a été écrit en Python, donc il fonctionne sans problème sous Windows, Linux, et vous pouvez le terminer en toute sécurité pour une utilisation sur RaspberryPi et appareils similaires. Le programme est extrêmement peu exigeant en termes de ressources et très stable. L'agent est constamment connecté via le Websocket au serveur (back-end) et reçoit tous les paramètres de port et leurs paramètres à partir de là, à la fois pendant l'initialisation et pendant les mises à jour. L'agent a sa propre interface graphique pour les paramètres et la surveillance dans ce cas (peut-être que la connexion a été perdue, peut-être que la licence a expiré).
Ensuite. Le serveur (alias le back-end) provient du docker (et fonctionne donc simplement non seulement sur amazon ou Google Cloud, mais également sur toute machine pas si puissante sur un LAN avec Linux à bord). Il est écrit en Django en collaboration avec Redis (pour supporter les websockets). Il stocke tous les paramètres et assure la communication entre l'interface utilisateur graphique (juste une page écrite en ReactJS) et via l'agent - avec nos appareils. Communication bidirectionnelle, entièrement asynchrone. Tous les paramètres sont stockés dans Postgres et Mongo.
Eh bien, et, peut-être, la partie la plus importante du système est le client lui-même (simplement, une page dans un navigateur, écrite pour ReactJS pour plus de dynamisme).
Oui, le design visuel est loin d'être parfait, mais c'est réparable.
Eh bien, cela peut être arrondi, je n'ajouterai que quelques mots sur l'état du projet et de la démo.
- Il s'agit d'un alpha assez précoce, conçu pour démontrer plus probablement les équipements potentiels et vérifier le niveau d'intérêt.
- Jouez une démo - ici
Se connecter
nom d'utilisateur: operator_0
mot de passe: 123456789
Nous sélectionnons QA_Test et n'importe quelle station (c'est juste une tentative de simuler la structure de l'entreprise - les ports sont connectés aux stations, ils sont divisés en départements et chaque bureau a sa propre structure)
En principe, s'il y a un intérêt, j'ajouterai la prise en charge de https et je créerai des assemblys d'agent pour différentes plates-formes, ainsi que toutes les autres fonctionnalités.
Je me ferai un plaisir de recevoir vos commentaires et suggestions. La critique est la bienvenue!