In dem Artikel habe ich versucht, unsere nützliche Erfahrung zu beschreiben, obwohl es sich natürlich um reine PR handelt und über unser neues cooles Produkt (Meinung des Autors) spricht.
Auf welche Probleme stießen wir und unsere Kunden bei der Organisation der Remote-Entwicklung von Software für Geräte, wie wurden sie gelöst und wo hat Redd, der Software- und Hardwarekomplex für die Remote-Entwicklung von Software für eingebettete Systeme, „Fuß gefasst“? Warum ist diese „Box“ aufgetaucht und wie wird sich das Leben (wieder die Meinung des Autors) von Millionen von Entwicklern eingebetteter Systeme, Geräte des Internet der Dinge, Ausrüstung für Autos, Flugzeuge und Kommunikation ändern?
Ich arbeite für eine Firma, die bescheiden
MIR heißt. Verwechseln Sie nicht mit dem Zahlungssystem, wir haben keine Beziehung dazu.
WORLD steht in unserem Fall für Workshop of Development Tools.
Wir entwickeln Systemsoftware für russische und ausländische Kunden. Ein typischer Kunde ist ein Hersteller von Mikrocontrollern und Mikroprozessoren, normalerweise mit einigen nicht standardmäßigen, relativ zum Standard erweiterten und möglicherweise mit einer eigenen Architektur.
Für sie entwickeln wir Entwicklungstools: IDEs, Compiler, Echtzeitbetriebssysteme, Debugger, Simulatoren, Profiler und andere SDK-Komponenten.
Parallel dazu übernehmen wir die Entwicklung von Software für eingebettete Systeme. Für den deutschen Autohersteller stellen wir beispielsweise Software für moderne Dashboards her. Wir führen auch Projekte in der Avionik durch, entwickeln Software zur Organisation von Maschennetzwerken aus „intelligenten Zählern“ und Drohnen, erstellen kundenspezifische Software für Zugangskontrollsysteme und arbeiten auf dem IoT-Markt (z. B. Smart Sockets). Im Allgemeinen gibt es viele interessante Projekte, bei denen sich herausstellt, dass sie bei der Lösung neu auftretender Probleme eine nicht standardmäßige Erfahrung gesammelt haben.
Für Kunden sind wir externe Entwickler. Darüber hinaus befinden wir uns in St. Petersburg, Veliky Novgorod und Krasnoyarsk und unsere Kunden in Moskau, Zelenograd, Tula, Woronesch, Deutschland und Korea.
Gleichzeitig entwickeln wir Software für Geräte. Und um ein bestimmtes Gerät zu programmieren, muss der Programmierer über dieses Gerät verfügen.
Wenn jemand plötzlich nicht mehr mit der „Technologie“ vertraut ist: Sie benötigen einen funktionierenden Computer, auf dem die erforderlichen Entwicklungstools wie die IDE installiert sind. Geräte müssen an denselben Computer angeschlossen sein: Debug-Boards, Dashboards (wenn es um die Entwicklung von Autos geht). Es sieht ungefähr so aus wie auf dem Bild:
Der Entwickler schreibt den Code auf den Computer und lädt ihn auf das Gerät herunter, auf dem er ausgeführt wird.
Es ist klar, dass es ohne das Gerät selbst unmöglich ist, den Betrieb zu überprüfen, zu debuggen oder zu optimieren. Darüber hinaus ist es für den Programmierer wichtig zu sehen, was physisch mit dem Gerät passiert: Welche LEDs blinken, was wird auf dem Bildschirm angezeigt, wo dreht sich das Rad?
Entwicklerprobleme
Und hier beginnen die Probleme.
Das erste , dem wir begegnen, ist die Verfügbarkeit von Ausrüstung.
Viele Unternehmen stellen in den frühen Produktionsphasen Einzelstücke her. Sie sind einfach physisch in der Welt, es gibt ein, zwei oder fünf Stücke. Die Übertragung an einen externen Entwickler (an uns) ist ein großes Problem und eine schwierige Aufgabe für den Kunden. Möglicherweise gibt es einfach keine freien Geräte.
Zum Beispiel wie beim neuen Prozessor 1967–044 von JSC PKK Milander. Die OCD befindet sich noch im Abschluss, aber die Entwicklungstools dafür müssen jetzt durchgeführt werden.
Das zweite Problem , wenn es nur wenige Produkte gibt, treten bei ihnen viele Hardwareprobleme auf. Wenn das Produkt aus Moskau zu uns kam und wir einen Fehler in der Hardware festgestellt haben, können wir das Produkt innerhalb eines Tages zur Korrektur an den Hersteller übertragen. Und wenn das Produkt aus Deutschland kommt? Sie müssen das Produkt an den Entwickler zurücksenden, auf Korrekturen warten und zurückkehren. Das alles ist weder schnell noch teuer. Und dennoch gibt es Ausfallzeiten für Programmierer und Projektfristen werden verschoben, während wir auf das korrigierte Gerät warten. Außerdem gab es Kunden, die das Gerät aus Sicherheitsgründen nur persönlich transportierten. Hardwarefehler sind jedoch in der Regel weitaus häufiger, als sie es sich leisten können.
Im Allgemeinen ist das Vorhandensein von Grenzen in der Welt eines der schwerwiegenden Hindernisse, die ständig Unannehmlichkeiten verursachen. Die Lieferung von Ausrüstung auch aus Europa in unserer Nähe wird zu einer Aufgabe, aber aus Korea oder den USA ... Ich werde nicht auf die auftretenden Probleme und deren Lösung eingehen, ich kann nur sagen, dass sie alle die Zeit und die Kosten von Projekten für den Kunden erhöhen. Das heißt, sie verringern unsere Wettbewerbsfähigkeit.
Ein weiteres Problem ist, dass das Gerät kaputt gehen kann. Der Transport erhöht das Risiko von Geräteschäden sowie Zeit- und Logistikkosten. Die Ausrüstung muss getrennt, verpackt, übertragen, ausgepackt, verbunden und konfiguriert werden und in den Ständen enthalten sein.
Stellen Sie sich nun vor, Sie entwickeln einen Gasanalysator, der mit mehreren großen und schweren Flaschen geliefert wird ...
oder ein Sprühsystem für einen Hubschrauber.
Jetzt muss das Debuggen solcher Systeme an Emulatoren durchgeführt werden, obwohl es viel bequemer wäre, einige Dinge aus der Ferne zu überprüfen (z. B. die PID-Regelung des Sprühmotors, wenn der Kunde zu Beginn der Saison mit der Installation von Einspritz- oder Vergasermotoren experimentiert oder die variablen Widerstände in seinem Steuersystem verdreht). .
Probleme treten jedoch auch dann auf, wenn sich Programmierer im selben Gebäude befinden.
Geräte können „verloren gehen“, wenn keine formellen Übertragungsprozesse vorhanden sind und sie zwischen Programmierern innerhalb des Projekts ausgetauscht werden. Oder die Geräte können für lange Zeit an den Entwickler „gehen“, wenn es formale Prozesse gibt, die jedoch bürokratisch sind. Ich kann nicht sagen, dass wir die Ausrüstung des Kunden wirklich verloren haben, aber es gab Situationen, in denen nicht klar war, wer genau das Debugging-Board im Moment hatte und wie lange es noch beschäftigt sein würde. Die Situation ist unkritisch, in fünf Minuten gelöst, aber es gibt viele Projekte. Warum zusätzliche Zeit verbringen?
Die Sache wird durch die Tatsache verschärft, dass Programmierer sehr süchtig sind. Wenn zwischen ihnen ein Wettbewerb um dieselbe Gebühr besteht (und dies geschieht häufig, da wir hauptsächlich mit einzigartiger Hardware arbeiten), sind vorübergehende „Überlagerungen“ und Ausfallzeiten für Mitarbeiter, die darauf warten, unvermeidlich.
Und selbst wenn Sie ein brillanter Marktführer sind und einen hervorragenden Prozess und eine hervorragende Logistik aufbauen, verlieren Sie dennoch an Effizienz, wenn Sie eine Remote-Programmierlösung lösen, ohne sich zu bewegen.
Zum Beispiel in einem solchen Fall. In der letzten Entwicklungsphase beginnen die Tests. Und es geht nicht danach, sondern parallel zur Entwicklung in einem Zyklus. Tester überprüfen die durchgeführten Funktionen, finden Fehler, dann beheben Programmierer Fehler, dann sind Tests erforderlich und so weiter. Geräte innerhalb desselben Projekts werden sowohl von Entwicklern als auch von Testern benötigt. Und wenn sich Ihre Büros beispielsweise in Krasnojarsk und in Veliky Novgorod befinden, können die Geräte fast rund um die Uhr arbeiten. Tag und Abend (in Moskau) schreiben Programmierer aus Nowgorod den Code, und am frühen Morgen (da die Differenz 4 Stunden beträgt) verbinden sich die Tester von Krasnojarsk während ihrer Arbeitszeit mit denselben Geräten und testen sie vollständig.
Traditionelle Lösung
Die Schlussfolgerung liegt auf der Hand: Die Fernarbeit mit Eisen kann sehr rentabel sein. Sie müssen die gesamte Hardware an einem Ort platzieren und dem Team Fernzugriff gewähren.
Entwickler stellen abwechselnd eine Verbindung zum Gerät her, arbeiten damit, erledigen die Aufgabe und trennen die Verbindung, wodurch Speicherplatz für das nächste frei wird.
Und alles in diesem Schema wäre großartig, aber die Verwendung des Standard-Fernzugriffs auf einen Computer, der mit dem Produkt verbunden ist, funktioniert nicht.
In den meisten Fällen ist es
nicht möglich, unterschiedliche Schnittstellen zum Anschließen von Hardware zu verwenden: Normalerweise verfügt ein Computer über einen begrenzten Satz, und es ist unmöglich, ohne Adapter eine direkte Verbindung zum Debugboard herzustellen. Beispielsweise müssen Sie einen Programmierer kaufen, der eine Remoteverbindung ermöglicht.
Wenn Sie immer noch eine Verbindung herstellen können, kann der Entwickler die
Energieeinstellungen des Geräts immer
noch nicht steuern : Es ist blöd, das Gerät nicht neu zu starten. Um die Ein- / Aus-Taste zu drücken oder den Stecker des Netzkabels herauszuziehen, müssen Sie einen Kollegen im Büro anrufen, damit er es von Hand macht.
Und dann müsste ein Kollege, den der Programmierer „einen Gedanken niedergeschlagen“ hat, für 5-10 Minuten darauf zurückgreifen. Dies zählt nicht die Zeit, die er lief, und ihm wurde am Telefon gesagt, welcher Schalter zu ziehen ist. Führen Sie also bei mehreren Projekten, die nicht mit dem aktuellen Stand zusammenhängen, Arbeitsstunden und Dutzende von Arbeitsstunden gleichzeitig im Leerlauf aus.
Außerdem
ist nicht klar, was physisch mit dem Gerät passiert . Was wird auf dem Bildschirm oder den Anzeigen des entwickelten Geräts angezeigt, wie blinken die LEDs? Es ist nicht immer notwendig, aber ein solches Bedürfnis entsteht normalerweise im ungünstigsten Moment.
Natürlich besteht die Möglichkeit, diese Einschränkungen zu umgehen. Kaufen Sie ein ferngesteuertes Relais, damit das Gerät neu gestartet werden kann, eine Webcam, die überwacht, gemountet und konfiguriert werden kann. Wenn es uns außerdem gelingt, allen zu vermitteln, wie man damit arbeitet, wo man „hineingeht“ und was in der richtigen Reihenfolge zu tun ist, kommen wir der Lösung näher ...
Abgesehen davon, dass es
keine zentralisierte und übersichtliche Organisation des Zugriffsprozesses gibt, wenn mehr Entwickler als Geräte vorhanden sind. Und wenn Sie mit dem Team arbeiten, müssen Sie sich irgendwie separat einigen, wer und wann mit der Ausrüstung arbeitet.
Redd - Fernprogrammierkomplex
Die Idee, alle angesprochenen Probleme umfassend zu lösen, lag an der Oberfläche, und selbst zunächst konnten wir nicht verstehen, warum niemand so etwas getan hatte, als wir anfingen, nach Konkurrenten zu suchen. Wir haben einige Lösungen gefunden, die jedoch teilweise minderwertig sind. Jeder tut etwas auf seinem Gebiet: jemand, der JTAG rein debuggt, jemand, der emuliert, aber Sie müssen auch debuggen und stehen, um zu sein, zu beobachten, Macht und Zugriffskontrolle. In dem Komplex tut dies jeweils niemand und es gibt keine voll funktionsfähigen Lösungen.
Aus diesem Grund haben wir mit der Entwicklung von Redd begonnen (steht für Remote Development Device). Dies ist ein Hardware-Software-Komplex, der den Zugriff auf mikroelektronische Geräte über das Internet oder ein lokales Netzwerk mithilfe einer Reihe von Standard- und benutzerdefinierten Kommunikationsprotokollen organisiert.
Wir haben keine „Nano-Innovationen“ verfolgt. In der Tat ist Redd einfach verständlich und einfache Technologien in einem Gerät kombiniert, die insgesamt eine Lösung für die oben beschriebenen Probleme bieten.
Redd kann über verschiedene Schnittstellen eine Verbindung zum Gerät herstellen, wodurch das Problem der Arbeit mit einer großen Anzahl von Geräten behoben wird, die Stromversorgung verwaltet werden kann und Sie das Gerät jetzt ohne Hilfe neu starten können. Es gibt eine Videokamera, über die der Entwickler in Echtzeit sieht, was mit dem Gerät passiert.
Darüber hinaus können Sie über den Serverteil des Produkts Geräte über die Kalenderoberfläche buchen und den Zugriff steuern.
Technisch gesehen besteht Redd aus zwei abhängigen Komponenten: einem „Remote-Terminal“ und einer Serversoftware.
Das Remote-Terminal ist ein PC-kompatibler Computer, der auf dem Intel-Prozessor basiert und mit einer von uns selbst entwickelten Schnittstellenerweiterungskarte ausgestattet ist. In der ersten Version (im März) werden Ethernet und USB Host (JTAG) verfügbar sein. Im zweiten (im Juni) - UART, Ethernet, GPIO, SPI (+ SPI-Flash), SDIO (mit einem Adapter für einen SD-Kartenemulator), I2C, USB 2.0 OTG, PCIe, LVDS, RS232 CMOS, Netzschalter für die Stromumschaltung und logisch Tasten zur Aktivierung, zum Beispiel Tasten.
Das Gerät verfügt über die am häufigsten verwendeten Schnittstellen sowie ein FPGA für die Implementierung nicht standardmäßiger Funktionen. Da das System in einem Komplex aufgebaut ist, ist das Fehlen gegenseitiger Konflikte garantiert. Und die Schnittstellen werden zusammen mit dem Komplex von Projekt zu Projekt verlaufen, ohne dass etwas Zusätzliches gekauft werden muss.
UPD: So sieht eine externe Karte mit Redd-Schnittstellenanschlüssen aus. Es "klebt" in den Anschluss an der Vorderseite und ermöglicht die Verwendung von Standardschnittstellen. Obwohl eine Variante möglich ist, die auf anderen Fotos gezeigt wird, ohne Tafel.
Entwickelte Ausrüstung ist unter Kampfbedingungen oft nicht ständig zu testen. Ein Hubschrauber zahlt nur 50 Euro für die Versandunterstützung beim Start und bei der Landung. Es ist unrealistisch, ständig Auto zu fahren. Schiffe sind nicht immer auf See. Im Allgemeinen brauchen wir Emulatoren.
Wie kommuniziert das System mit der Außenwelt? Über Sensoren, die an verschiedene Busse angeschlossen sind. Nun, die Signale an die Aktuatoren werden auch in den Bussen ausgegeben. Das aktuelle Reifensortiment ist recht breit. Dies können CAN, UART (in der CMOS-, RS232-, RS485-Version), Ethernet, MODBUS (über denselben UART oder Ethernet), digitale Leitungen mit unterschiedlichen Pegeln usw. usw. sein.
Eine typische Lösung besteht darin, Emulatoren von Sensoren und Aktoren herzustellen, indem sie an die Busse angeschlossen werden. Das in der Entwicklung befindliche Gerät berücksichtigt, dass es echte Informationen erhält, und der Entwickler ahmt verschiedene Szenarien realer Arbeit nach und debuggt Arbeitsalgorithmen. Natürlich können Sie für jedes Projekt Controller verschiedener Schnittstellen erwerben und verbinden.
Oder Sie können Redd anstelle dieser Sensoren und Darsteller anschließen, Simulatoren ihrer Arbeit schreiben (dh sie simulieren die externe Umgebung) und dann das in der Entwicklung befindliche Gerät debuggen, das glaubt, es sei im Auto oder woanders, und das tun wir Debuggen der Ziellogik. Durch diesen Mechanismus können Tester Grenz- und sogar absichtlich fehlerhafte Situationen überprüfen, die bei normalen Tests nur sehr schwer oder gar nicht reproduzierbar sind.
Der Serverteil des Komplexes befindet sich direkt am Terminal. Der Entwickler kann über das Internet sehen, welche Geräte und zu welcher Zeit für ihn verfügbar sind. Kann sie in einem Kalender buchen, sodass ihm automatisch Zugriff gewährt wird. Es verbindet sich über das ssh-Protokoll mit dem Terminal und damit mit dem Debugger und der Verwaltung von Geräteemulatoren. Darüber hinaus kann die Betriebsart von Redd nicht nur Mehrbenutzer sein, sondern auch bei gleichzeitiger Verbindung mehrerer Geräte.
Auf diese Weise kann Redd den Remotezugriff interner oder externer Entwickler auf ein Gerät (oder eine Gruppe von Geräten, es ist möglich, mehrere Geräte an ein Terminal anzuschließen) organisieren, den Zugriff im Laufe der Zeit ohne physische Bewegung planen und verwalten.
Ein zusätzlicher Bonus - Redd kann auch verwendet werden, um das Produkt externen Kunden und Kunden ohne tatsächliche Übertragung zu demonstrieren. Oder zum Organisieren der Programmierung von Fernlerngeräten, die für Hersteller von Mikroprozessoren oder für Bildungseinrichtungen interessant sein können.
Was jetzt?
Jetzt beenden wir die Entwicklung der ersten Version, sie wird Anfang März veröffentlicht und ist bereits
vorbestellbar (natürlich zu Vorzugskonditionen).
Das Hauptziel dieses Artikels (außer Werbung) ist das Sammeln von Feedback.
Schreiben Sie, wenn Sie nicht einverstanden sind, dass es Probleme gibt, die im Artikel beschrieben werden, oder Sie können die Probleme benennen, die ich vergessen habe.
Vielleicht kennen Sie eine Lösung, die wir nicht gefunden haben, oder Sie lösen diese Probleme auf Ihre eigene Weise.
Oder sie sind bereit, uns mit einem freundlichen Wort (oder vielleicht nicht nur) bei der Produktentwicklung zu unterstützen.
Ich werde gerne einen Kommentar abgeben.