Dans l'article, malgré le fait qu'il s'agit, bien sûr, de relations publiques pures et parle de notre nouveau produit cool (opinion de l'auteur), j'ai essayé de décrire notre expérience utile.
Quels problèmes nous et nos clients avons-nous rencontrés lors de l'organisation du développement à distance de logiciels pour les appareils, comment ils ont été résolus, et d'où Redd, le complexe logiciel et matériel de développement de logiciels à distance pour les systèmes embarqués, a «grandi». Pourquoi cette «boîte» est-elle apparue, et comment la vie (encore une fois, l'opinion de l'auteur) changera-t-elle de millions de développeurs de systèmes embarqués, d'appareils Internet des objets, d'équipements pour les voitures, d'avions, de communications.
Je travaille pour une entreprise qui s'appelle modestement
MIR . Ne confondez pas avec le système de paiement, nous n'avons aucun lien avec lui.
MONDE dans notre cas signifie Atelier d'outils de développement.
Nous développons des logiciels système pour les clients russes et étrangers. Un client typique est un fabricant de microcontrôleurs et de microprocesseurs, généralement avec certains non standard, étendus par rapport à la norme, et peut-être avec sa propre architecture.
Pour eux, nous développons des outils de développement: IDE, compilateurs, systèmes d'exploitation en temps réel, débogueurs, simulateurs, profileurs et autres composants SDK.
En parallèle, nous prenons également en charge le développement de logiciels pour les systèmes embarqués. Par exemple, pour le constructeur automobile allemand, nous créons des logiciels pour les tableaux de bord modernes. Nous réalisons également des projets en avionique, développons des logiciels d'organisation de réseaux maillés de «compteurs intelligents» et de drones, réalisons des logiciels personnalisés pour les systèmes de contrôle d'accès et travaillons sur le marché de l'IoT (smart sockets par exemple). En général, il existe de nombreux projets intéressants dans lesquels il s'avère acquérir une expérience assez non standard dans la résolution de problèmes émergents.
Pour les clients, nous sommes des développeurs externes. De plus, nous sommes situés à Saint-Pétersbourg, Veliky Novgorod et Krasnoyarsk, et nos clients sont à Moscou, Zelenograd, Tula, Voronezh, en Allemagne et en Corée.
Dans le même temps, nous développons des logiciels pour les appareils. Et pour programmer un appareil spécifique, il est nécessaire que le programmeur ait cet appareil.
Si quelqu'un n'est soudainement pas familier avec la «technologie»: vous avez besoin d'un ordinateur de travail où les outils de développement nécessaires, tels que l'IDE, sont installés. Les appareils doivent être connectés au même ordinateur: tableaux de débogage, tableaux de bord (si nous parlons de développement pour les voitures). Cela ressemble à quelque chose dans l'image:
Le développeur écrit le code sur l'ordinateur et le télécharge sur l'appareil où il est exécuté.
Il est clair que sans l'appareil lui-même, il est impossible de vérifier le fonctionnement, il est impossible de déboguer ou d'optimiser. De plus, il est important pour le programmeur de voir ce qui se passe physiquement avec l'appareil: quelles LED clignotent, ce qui est affiché à l'écran, où la roue tourne.
Problèmes de développeur
Et ici les problèmes commencent.
Le premier que nous rencontrons est la disponibilité des équipements.
De nombreuses entreprises fabriquent des pièces uniques aux premiers stades de la production. Ils sont simplement physiquement dans le monde il y a une, deux ou cinq pièces. Les transférer à un développeur externe (pour nous) est un gros problème et une tâche difficile pour le client. Il ne peut tout simplement pas y avoir d'appareils gratuits.
Par exemple, comme c'est le cas avec le nouveau processeur 1967044 de JSC PKK Milander. Il est toujours dans un état d'achèvement du TOC, mais les outils de développement pour cela doivent être faits maintenant.
Le deuxième problème , quand il y a peu de produits, il y a beaucoup de problèmes matériels. Et, si le produit nous est venu de Moscou et que nous avons trouvé une erreur dans le matériel, nous pouvons transférer le produit au fabricant pour correction dans un délai d'un jour. Et si le produit venait d'Allemagne? Vous devez renvoyer le produit au développeur, attendre les corrections et revenir. Tout cela n'est ni rapide ni coûteux. Et il y a toujours des temps d'arrêt pour les programmeurs et les délais de projet sont décalés pendant que nous attendons un périphérique fixe. Et il y avait aussi des clients qui transportaient l'appareil uniquement pour des raisons de sécurité. Cependant, les erreurs matérielles sont généralement beaucoup plus courantes qu'elles ne peuvent se le permettre.
De manière générale, la présence de frontières dans le monde est l'un des obstacles majeurs qui causent constamment des désagréments. La livraison de matériel même depuis l'Europe proche de nous se transforme en quête, mais depuis la Corée ou les USA ... Je ne préciserai pas les problèmes qui se posent et comment les résoudre, je peux seulement dire qu'ils augmentent tous le temps et le coût des projets pour le client. Cela signifie qu'ils réduisent notre compétitivité.
Un autre problème est que l'équipement peut se casser. Le transport est une augmentation du risque de dommages à l'équipement, plus une perte de temps et des coûts logistiques. L'équipement doit être déconnecté, emballé, transféré, déballé, connecté et configuré, inclus dans les stands.
Imaginez maintenant que vous développez un analyseur de gaz, qui est livré avec plusieurs cylindres énormes et lourds ...
ou un système de pulvérisation pour un hélicoptère.
Le débogage de tels systèmes doit maintenant être effectué sur les émulateurs, bien qu'il serait beaucoup plus pratique de vérifier certaines choses à distance (par exemple, le contrôle PID du moteur à pulvérisation, lorsque le client au début de la saison expérimente l'installation de moteurs à injection ou à carburateur, ou tord les résistances variables dans leur système de contrôle) .
Mais des problèmes surviennent même si les programmeurs sont dans le même bâtiment.
L'équipement peut être «perdu» s'il n'y a pas de processus de transfert formel et qu'il passe entre les programmeurs du projet. Ou l'équipement peut «aller» au développeur pendant longtemps, s'il existe des processus formels, mais bureaucratiques. Je ne peux pas dire que nous avons vraiment perdu l’équipement du client, mais il y avait des situations où il n’était pas clair qui avait exactement la carte de débogage en ce moment, et combien de temps elle serait encore occupée. La situation n'est pas critique, résolue en cinq minutes, mais il existe de nombreux projets. Pourquoi passer plus de temps?
Le problème est aggravé par le fait que les programmeurs sont des gens très dépendants. Par conséquent, s'il y a concurrence entre eux pour les mêmes frais (et cela arrive souvent, car nous travaillons principalement avec du matériel unique), les «superpositions» temporaires et les temps d'arrêt pour les employés qui l'attendent sont inévitables.
Et même si vous êtes un leader brillant et construisez un excellent processus et logistique, vous perdrez toujours en efficacité en résolvant une solution de programmation à distance sans bouger.
Par exemple, dans un tel cas. Au stade final du développement, les tests commencent. Et ça ne va pas après, mais en parallèle avec le développement, dans un cycle. Les testeurs vérifient les fonctions effectuées, trouvent les erreurs, puis les programmeurs corrigent les bogues, puis les tests sont nécessaires, etc. L'équipement dans le même projet est nécessaire à la fois par les développeurs et les testeurs. Et si vos bureaux sont situés, par exemple, à Krasnoyarsk et à Veliky Novgorod, l'équipement peut fonctionner presque 24h / 24. Jour et soir (à Moscou), les programmeurs de Novgorod écrivent le code, puis tôt le matin (puisque la différence est de 4 heures), les testeurs de Krasnoïarsk se connectent et testent entièrement sur le même équipement pendant leurs heures de travail.
Solution traditionnelle
La conclusion est évidente: travailler à distance avec du fer peut être très rentable. Vous devez mettre tout le matériel en un seul endroit et donner à l'équipe un accès à distance.
Les développeurs se connectent à tour de rôle à l'appareil, travaillent avec lui, terminent la tâche et se déconnectent, libérant ainsi de l'espace pour la suivante.
Et tout dans ce schéma serait formidable, mais l'utilisation d'un accès à distance standard à un ordinateur connecté au produit ne fonctionne pas.
Le plus souvent, il n'est
pas possible d'utiliser différentes interfaces pour connecter du matériel: généralement, un ordinateur a un ensemble limité et il est impossible de se connecter directement à la carte de débogage sans adaptateurs. Par exemple, vous devrez acheter un programmeur qui permet une connexion à distance.
Si vous parvenez toujours à vous connecter, le développeur
ne pourra toujours pas contrôler les paramètres d'alimentation de l' appareil: il est ringard de ne pas redémarrer l'appareil. Pour appuyer sur le bouton marche / arrêt ou retirer la fiche du cordon d'alimentation, vous devrez appeler un collègue au bureau pour qu'il aille le faire à la main.
Et puis un collègue à qui le programmeur «a fait tomber une pensée» devrait y revenir pendant 5 à 10 minutes, sans compter le temps qu'il courait et on lui a dit au téléphone quel interrupteur tirer. Exécutez donc des heures de travail et des dizaines d'heures de travail au ralenti sur plusieurs projets qui ne sont pas liés au courant.
De plus,
il n'est pas clair ce qui arrive physiquement à l'appareil . Ce qui est affiché sur l'écran ou les indicateurs de l'appareil développé, comment les LED clignotent. Ce n'est pas toujours nécessaire, mais un tel besoin survient généralement au moment le plus inopportun.
Bien sûr, il existe une option pour essayer de contourner ces limitations. Achetez un relais télécommandé pour pouvoir redémarrer l'appareil, une webcam pour surveiller, tout monter et configurer. De plus, si nous parvenons à transmettre à tout le monde comment travailler avec cela, où «entrer» et quoi faire dans le bon ordre, alors nous nous rapprocherons de la solution ...
Sauf que lorsqu'il y a plus de développeurs que d'appareils, il n'y a
pas d'organisation centralisée et claire du processus d'accès . Et lorsque vous travaillez avec l'équipe, vous devrez en quelque sorte convenir séparément qui et quand travailler avec l'équipement.
Redd - complexe de programmation à distance
L'idée de résoudre tous les problèmes exprimés de façon globale a fait surface, et même au début, nous ne pouvions pas comprendre pourquoi personne n'avait rien fait de tel lorsque nous avons commencé à chercher des concurrents. Nous avons trouvé des solutions, mais inférieures, dans certaines parties. Tout le monde fait quelque chose dans son domaine: quelqu'un purement déboguer JTAG, quelqu'un émuler, mais vous devez aussi déboguer et rester debout, observer, alimenter et contrôler l'accès. Dans le complexe, personne ne le fait, respectivement, et il n'y a pas de solutions pleinement opérationnelles.
Par conséquent, nous avons commencé à développer Redd (acronyme de Remote development device). Il s'agit d'un complexe matériel-logiciel qui organise l'accès aux équipements microélectroniques via Internet ou un réseau local en utilisant un certain nombre de protocoles de communication standard et personnalisés.
Nous n'avons pas recherché de «nano innovations». En fait, Redd est simplement des technologies compréhensibles et simples combinées en un seul appareil, qui au total donnent une solution aux problèmes que j'ai décrits ci-dessus.
Redd peut se connecter à l'appareil via différentes interfaces, ce qui élimine le problème de travailler avec un grand nombre d'appareils, est capable de gérer l'alimentation, et vous pouvez maintenant redémarrer l'appareil sans aucune aide. Il y a une caméra vidéo à travers laquelle le développeur voit ce qui se passe avec l'appareil en temps réel.
De plus, la partie serveur du produit vous permet de réserver du matériel via l'interface de calendrier et contrôle l'accès.
Techniquement, Redd se compose de deux composants dépendants: un «terminal distant» et un logiciel serveur.
Le terminal distant est un ordinateur compatible PC basé sur le processeur Intel, équipé d'une carte d'extension d'interface, que nous développons nous-mêmes. Dans la première version (en mars), Ethernet et USB Host (JTAG) seront disponibles. Dans le second (en juin) - UART, Ethernet, GPIO, SPI (+ flash SPI), SDIO (avec un adaptateur pour un émulateur de carte SD), I2C, USB 2.0 OTG, PCIe, LVDS, RS232 CMOS, interrupteurs d'alimentation pour commutation d'alimentation et logique des touches d'activation, par exemple des boutons.
L'appareil possède l'ensemble d'interfaces le plus couramment utilisé, et il existe un FPGA pour implémenter toutes les choses non standard. Le système étant conçu dans un complexe, l'absence de conflits mutuels est garantie. Et les interfaces iront de projet en projet avec le complexe, sans avoir besoin d'acheter quelque chose de plus.
UPD: voici à quoi ressemble une carte externe avec des connecteurs d'interface Redd. Il "colle" dans le connecteur du panneau avant et permet l'utilisation d'interfaces standard. Bien qu'une variante soit également possible, qui est montrée sur d'autres photos, sans planche.
Les équipements développés sont souvent impossibles à tester en permanence dans des conditions de combat. Un hélicoptère ne paie que 50 euros pour l'assistance au décollage et à l'atterrissage. Conduire une voiture tout le temps n'est pas réaliste. Les navires ne sont pas toujours en mer. En général, nous avons besoin d'émulateurs.
Comment le système communique-t-il avec le monde extérieur? Via des capteurs connectés à différents bus. Eh bien, les signaux aux actionneurs sont également émis sur les bus. La gamme de pneus actuelle est assez large. Cela peut être CAN, UART (dans la version CMOS, RS232, RS485), Ethernet, MODBUS (via le même UART ou Ethernet), des lignes numériques avec différents niveaux et ainsi de suite, etc., etc.
Une solution typique consiste à réaliser des émulateurs de capteurs et d'actionneurs en les connectant aux bus. L'équipement en cours de développement considérera qu'il reçoit des informations réelles, et le développeur imitera divers scénarios de travail réel, en déboguant des algorithmes de travail. Bien sûr, pour chaque projet, vous pouvez acheter des contrôleurs de différentes interfaces et les connecter.
Ou vous pouvez connecter Redd à la place de ces capteurs et interprètes, écrire des simulateurs de leur travail (c'est-à-dire eux, c'est-à-dire que nous simulons l'environnement externe), puis déboguer l'appareil en cours de développement qui pense qu'il est dans la voiture ou ailleurs, et nous le faisons débogage de la logique cible. Et les testeurs grâce à ce mécanisme pourront vérifier les situations limites et même délibérément erronées qui sont très difficiles ou complètement impossibles à reproduire dans les tests ordinaires.
La partie serveur du complexe est située directement sur le terminal. Le développeur via le Web peut voir quels appareils et à quelle heure sont à sa disposition. Peut les réserver sur un calendrier afin qu'il ait automatiquement accès. Il se connecte via le protocole ssh au terminal, et avec lui, au débogueur et à la gestion des émulateurs d'appareils. De plus, le mode de fonctionnement de Redd peut être non seulement multi-utilisateur, mais également avec la connexion simultanée de plusieurs appareils.
Ainsi, Redd permet d'organiser l'accès à distance des développeurs internes ou externes à un appareil (ou à un groupe d'appareils, il est possible de connecter plusieurs appareils à un même terminal), de planifier et de gérer l'accès dans le temps, sans mouvement physique.
Un bonus supplémentaire - Redd peut également être utilisé pour démontrer le produit aux clients externes et aux clients sans transfert réel. Ou pour organiser la programmation de dispositifs d'apprentissage à distance, ce qui peut être intéressant pour les fabricants de microprocesseurs ou pour les établissements d'enseignement.
Et maintenant
Nous terminons maintenant le développement de la première version, elle sortira début mars, et elle est déjà
disponible en pré-commande (bien sûr, à des conditions préférentielles).
L'objectif principal de cet article (à l'exception de la publicité) est de recueillir des commentaires.
Écrivez si vous n'êtes pas d'accord qu'il y a des problèmes qui sont décrits dans l'article, ou vous pouvez nommer ces problèmes que j'ai oubliés.
Peut-être connaissez-vous une solution que nous n'avons pas trouvée ou résolvez-vous ces problèmes à votre manière.
Ou ils sont prêts à nous soutenir avec un mot aimable (ou peut-être pas seulement) dans le développement de produits.
Je me ferai un plaisir de commenter.