Vor 2 Jahren haben wir einen Blog über Habr gestartet, der mit einem
Überprüfungstext darüber beginnt, was wir tun, welche Technologien wir verwenden und wohin wir uns bewegen. Seit 2017 hat sich viel geändert, und heute erfahren Sie, wie Sie unsere Entscheidung treffen können - die globale Managementplattform Connected Cars, die von vielen Benutzern und Unternehmen verschiedener Ebenen verwendet wird. Das Material ist von der Problemstellung bis zur Bereitstellung nach Prozessen unterteilt.
Das Flaggschiffprodukt Bright Box -
Remoto - ist eine technologisch hoch entwickelte,
funktionsreiche Plattform für Connected Car, die Geräte, Software für Händler und Autohersteller sowie eine mobile Anwendung für den Benutzer umfasst. Laut der primären Bright Box-Analyse unter Autobesitzern stellte sich heraus, dass sie zunächst eine Fernsteuerung der Türschlösser, eine Klimaregelung und eine Autosuche mit Warnmeldungen über Schock oder Evakuierung benötigen. Letzteres ist bereits ein Klassiker. Jetzt bietet der Remoto-Block dem Benutzer die folgenden Dienste: Fernsteuerung der Fahrzeugfunktionen, Möglichkeit zum Empfangen von Daten von Hardware und CAN, GPRS, SMS, Bluetooth und Steuerung der Ausgangsleistung zur elektronischen Zündeinheit. Der Benutzer erhält diese Informationen in einer mobilen Anwendung.
Und ein solcher Benutzer kann nicht nur der Besitzer der Maschine sein. Informationen, die zur Sammlung verfügbar sind, können für viele Automarktteilnehmer ein nützliches Werkzeug sein. Zum Beispiel Carsharing. Carsharing-Unternehmen sind heute die aktivsten Akteure auf dem Automobilmarkt. Moskau ist die Stadt Nummer eins in der Gesamtzahl der Autos, die am Carsharing beteiligt sind. Bis 2020 soll Carsharing in Russland die Marke von 40.000 Autos erreichen. Carsharing-Unternehmen werden Eigentümer der folgenden Daten: Kilometerstand, GPS-Koordinaten, Geschwindigkeit, Türstatus und Kraftstoffstand. Der Schlüssel zu all dem ist ein Smartphone, das billiger und sicherer ist.
Andrey Kuprikov, Mitbegründer und Direktor für Geschäftsentwicklung bei YouDrive und einer der Kunden von Bright Box:„Carsharing ohne Telematiklösung ist kaum vorstellbar. Unsere Plattform ist verpflichtet, alle möglichen Informationen über das Auto zu sammeln, was und wie es passiert. Andernfalls wirkt sich dies auf das Geschäft aus. Es ist die Telematik, die Informationen über die Kosten für Reparaturen und Ersatzteile sowie über die Kosten für Ausfallzeiten eines Autos liefert, das aufgrund eines Verschuldens eines Geschwindigkeitsliebhabers repariert wird. Mit einem Telematikgerät an Bord können Sie ein einzigartiges Programm zur Kundenbindung erstellen. “
Seit Anfang dieses Jahres ist Remoto ein Lösungsanbieter für zwei große Carsharing-Unternehmen, YouDrive und EasyRide, mit 1.000 Fahrzeugen in seiner Flotte. Der Einsatz der Lösung im Carsharing ist nicht nur bequem, sondern auch unter Sicherheits- und Finanzgesichtspunkten effektiv - in Form der Reduzierung des Unfallrisikos und im Rahmen des Treueprogramms. Mit der Entwicklung des Carsharing werden Benutzerdaten gesammelt, und jetzt verfügt Carsharing wie Banken über ein bestimmtes Kundenbewertungssystem. Wir haben über die Logik der Funktionsweise von Bewertungsalgorithmen für Carsharing-Benutzer geschrieben und zuerst
den Bewertungsalgorithmus basierend auf scharfen Beschleunigungen und Bremsen und dann
die Algorithmen zur Analyse des Fahrstils basierend auf den Werten für Geschwindigkeit, Motordrehzahl und Beschleunigungsmesser analysiert .
Wir arbeiten aber nicht nur auf dem russischen Markt aktiv, dies ist auch eine zusätzliche Herausforderung. Mit der Erweiterung der Arbeitsgeographie wurde deutlich, dass die korrekte und effektive Umstrukturierung der technischen Vertikale ein entscheidender Moment der Entwicklung ist.
Sagen wir Vitaly Baum, Chief Product Officer
und Vyacheslav Sokolov, Chief Engineering Officer:Unser System besteht aus einer Reihe von Komponenten. In der Technik sind engagierte Teams für sie verantwortlich. Tatsächlich umfasst das Engineering drei Geschäftsprozesse und eine Reihe unterstützender Services.
Innerhalb der Engineering-Einheiten können folgende Geschäftsprozesse unterschieden werden:
- Entwicklung eines Telematikgeräts mit eingebetteter Software zur Integration in Autos. Beschäftigt sich mit der technischen Abteilung von HW.
- Der Prozess der Herstellung von Geräten für einen bestimmten Kunden im Auftrag eines Geschäftsbereichs. Verantwortlich für die Herstellung
- Entwicklung von Remoto Cloud Services, die für die Interaktion von Client, Benutzer und Telematikgerät verantwortlich sind. Es handelt sich um eine Vielzahl von Backend-Diensten mit einer Reihe von Portalen für verschiedene Benutzer, mobile Clientanwendungen und Data Lake. Die Produktion wird von der Produktmanagementabteilung übernommen. Die Entwicklung des gesamten Softwareteils erfolgt durch die Produktentwicklungsabteilung mit Releases und Support durch das RCS-Betriebsteam.
Es ist anzumerken, dass die Aufgabe, die funktionalen Anforderungen für ein bestimmtes Merkmal zu bestimmen, bei der Abteilung Produktmanagement liegt, zu der neben Produktexperten auch Analysten und Designer gehören. Darüber hinaus gehen die Anforderungen an die Produktentwicklungsabteilung, die vor der schwierigen Aufgabe steht, Funktionen in Systemkomponenten, einschließlich Gerätefirmware, zu zerlegen. Diese Aufgabe wird vom Produktentwicklungsarchitekten zusammen mit einem Team von Systemanalysten übernommen.
Wie sieht die Produktplanung aus? In letzter Zeit ist das Produktmanagement Teil eines Engineering-Teams geworden. Und eine solche Organisationsstruktur spiegelte sich in unserer Arbeitsweise wider. Das PM-Team legt fest, welches Produkt im Allgemeinen sein soll und welche Funktionen es haben soll, unabhängig von den Systemkomponenten. Es stellt sich kurz heraus - eine oberflächliche Beschreibung dessen, was in der Aufgabe zu tun ist. Danach werden Funktionsspezifikationen erstellt, die wir FSD nennen, oder eine Reihe von Jobstorys - zum Beispiel die Möglichkeit, eine Anwendung im Produkt als „Wartungsregister“ zu senden. Jede Funktion wird durch eine Reihe ähnlicher Jobgeschichten beschrieben.
PMs sind auch am technischen Design beteiligt. Sie führen eine technische Analyse der Funktionsspezifikation durch und erstellen ein technisches Design - TDD (Technical Design Document), diskutieren dieses technische Design mit Entwicklern und landen es unter ihrem Verständnis. Nachdem die funktionalen Anforderungen und das technische Design geschrieben wurden, beginnen wir mit der Arbeit an der Benutzeroberfläche - dies ist die Benutzeroberfläche für die Benutzererfahrung.
Daher bilden Produktingenieure für den Kunden einen bestimmten Satz von „Versorgungseinheiten“ („Anmeldung zur Wartung“ kann eine solche Gebrauchseinheit sein) und geben ihn an einen Spezialisten weiter, der die Logik in diesem Satz beschreibt. Nützlichkeit in einem Wartungsantrag bedeutet, dass der Kunde ein Formular mit den erforderlichen Informationen ausfüllen kann, das mit den Erwartungen der Händler bei der Einreichung eines Wartungsantrags übereinstimmt. Der Produktspezialist analysiert auch den Markt, untersucht, was in dem Produkt enthalten sein sollte und welchen Wert es für die Kunden hat.
Unsere Produktexperten kommunizieren heute mehr mit dem Geschäft innerhalb des Unternehmens oder direkt mit Kunden. Die Roadmap wird vom Roadmap-Ausschuss gebildet, dem die Top-Manager des Unternehmens angehören, um alle Bereiche der Unternehmensentwicklung zu berücksichtigen. Der Ausschuss tritt einmal im Quartal zusammen.
Dies geschieht, um das gemeinsame Verständnis zu koordinieren und die Produktintegrität sicherzustellen, damit die Funktionen nahtlos in die aktuelle Vision des Produkts passen.
Es gibt einen separaten Dienst - die Cybersicherheit, der mit Mitarbeitern und Spezialisten der Backend-Abteilung interagiert, um Schwachstellen zu identifizieren, zu schließen und Risiken zu bewerten, zu denen diese Risiken führen können. Heute legt der Chief Engineering Officer, der auch das Produktteam leitet, die Aufgabe für diese Abteilung fest. Sie kommuniziert wiederum mit dem Kunden und versteht, was jetzt erforderlich ist, um alle Cybersicherheitsstandards einzuhalten. All dies ist im Release-Plan enthalten, Schwachstellen werden geschlossen, Zertifikate werden erhalten und im Allgemeinen wird die Sicherheitslücke beseitigt.
Nachdem die Funktionalität vom Engineering ausgearbeitet und von der Sicherheitsabteilung bewertet wurde, geht ihre Spezifikation an das Produktentwicklungsteam, wo die Arbeitsgruppe die Funktionen nach den Komponenten des Systems zerlegt - was sich auf das Backend bezieht, was auf das Gerät, was die mobile Anwendung tun sollte. Das Produktentwicklungsteam und das HW-Entwicklungsteam einigen sich auf eine Zusammenarbeit, alles läuft auf einen gemeinsamen Plan hinaus und ist sich in den Teams nicht einig.
Wie stellen wir bereit?
Am Ende der Entwicklung wird das gesammelte Ergebnis einem Integrationstest unterzogen und auf die Version auf der Cloud-Plattform übertragen. Auf der Cloud-Plattform, auf der wir (Azure) hosten, gehostete Umgebungen für Kunden. Die Umgebung ist für das Betriebsteam verantwortlich, in dem die Ingenieure, DevOps und der Support arbeiten.
Kommentar von Vladimir Glazkov, Senior DevOps Engineer:Unsere gesamte Infrastruktur wird als Code beschrieben. Wir nehmen alle Änderungen nur über den Code vor. Dieser Ansatz reduziert das Risiko des menschlichen Faktors bei Aktualisierungen. Außerdem können Sie schnell eine zusätzliche Instanz der Umgebung für einige vorübergehende dringende Anforderungen bereitstellen. Bei einem Ausfall der Rechenleistung (VM / VMSS) können Sie schnell eine neue Instanz bereitstellen.
Über CI / CD - im Moment verwenden wir eine Reihe von TeamCity / Octopus Deploy. TeamCity ist dabei, .net-Projekte zusammenzustellen. Unit-Tests werden gestartet. Anschließend wird in Octopus eine Version erstellt und auf den entsprechenden Zielen (VM / VMSS / K8S) bereitgestellt. Nach einer erfolgreichen Bereitstellung werden Abnahmetests gestartet. Wenn einer der Tests abstürzt, wird das Entwicklungsteam benachrichtigt.
Zunächst wurden für jedes Geschäftsprojekt separate Ressourcensätze erstellt, einschließlich CI / CD-Tools. Schnell stellte sich heraus, dass dieser Ansatz mit zunehmender Anzahl von Projekten zum Scheitern verurteilt ist - es ist einfach unmöglich, einen solchen Zoo effektiv zu verwalten. Vor zwei Jahren wurde ein Vereinigungsprojekt gestartet, das vier Monate später endete. Dabei wurden die Kernkomponenten des Systems zugewiesen, für sie ist der Montage- und Bereitstellungsprozess für alle Umgebungen gleich. Die Möglichkeit, eine Baugruppe / Bereitstellung zusätzlicher Komponenten hinzuzufügen, die für ein bestimmtes Geschäftsprojekt spezifisch sind, wurde ebenfalls beschrieben und implementiert. Beim Erstellen neuer Umgebungen sind einzelne Instanzen von TeamCity & Octopus nicht mehr erforderlich. Es wurden Skripte geschrieben, die über die API alle für die Montage und Bereitstellung erforderlichen Dinge erstellen und konfigurieren.
Wir kamen zu der folgenden Verwendung von Umgebungen: Für die Entwicklung verwendet jedes Team zwei Umgebungen:
- die erste für die Entwicklung neuer Funktionen, die Überprüfung von Merkmalen durch den Autor usw.;
- Die zweite dient der Stabilisierung.
Es kann viele solcher Umgebungen geben, deren Wartung angesichts der durchgeführten Vereinheitlichung recht einfach ist.
Es gibt auch eine Umgebung für die Annahme der Freigabe durch das für die Kampfumgebung zuständige Team. Es besteht den letzten Test vor der Freigabe in der Produktion.
Wir haben eine Vereinbarung mit Entwicklern über das Gerät zum Transformieren von Konfigurationsdateien. In jedem Projekt gibt es eine Datei, die eine Reihe von Parametern enthält, die in verschiedenen Umgebungen unterschiedliche Bedeutungen haben. Entwickler füllen die Datei mit den erforderlichen Parametern (Datenbankverbindungszeichenfolgen, Verbindungsschlüssel usw.) aus. Die Werte dieser Parameter sind Variablen. Für jede Umgebung sind die Werte dieser Variablen individuell. Mit diesem Ansatz stören Entwickler nicht das lokale Sammeln und Prüfen für sich. Variablen werden in Octopus Deploy gespeichert.
Für die Überwachung verwenden wir Azure Monitor, Application Insights und Log Analytics. Zabbix lebt seine Zeit aus, wahrscheinlich wird ihm in Zukunft die ehrenvolle Rolle externer Kontrollen übertragen.
Als ich in das Unternehmen eintrat, dauerte die Schaffung einer neuen Umgebung drei Wochen. Es gab fast keine Anweisungen, Änderungen wurden manuell vorgenommen und nirgendwo aufgezeichnet. Unsere Reise zu IaaC begann mit einer einfachen Automatisierung, die den Prozess auf 1 Woche reduzierte. Das Erstellen einer neuen Umgebung dauert jetzt 4 Stunden. Automatisierte ungefähr 95% der Aktionen.
Unser Backend ist in .net (4.6 / 4.7 und Core) geschrieben, die Front ist JS. Für das Hosting verwenden wir
Virtual Machine Scale Sets und K8S. Dementsprechend ist es sehr einfach, unter Laständerungen zu skalieren.
Wie das System im Inneren funktioniert
Ivan Stolet, Leiter Plattformentwicklung Bright Box:
Auf der Site finden Sie immer ein Diagramm der aktuellen Architektur.
Alle Daten im System werden verteilt gespeichert. Es gibt separate Datenbanken für die Speicherung personenbezogener Daten in Bezug auf die Region, die gemäß den örtlichen Gesetzen organisiert sind. Es gibt Datenbanken, in denen der inhaltliche Teil der Kundenbindungsdienste, der Speicherung von Nachrichten, Anwendungen, Daten aus verschiedenen Integrationssystemen von Händlern und Automobilherstellern gesammelt wird. Separat werden verarbeitete Telemetriedaten sowie Einstellungen und andere Daten gesammelt, die erforderlich sind, um die Funktionsfähigkeit der Remoto-Dienste und unserer Geräte sicherzustellen. Wir erfassen Kalttelemetriedaten separat mithilfe von Datenbanken, in denen große Mengen an Informationen gespeichert werden. Außerdem wurden separate Data Warehouses gebaut, die den Betrieb von Remoto AI-Systemen ermöglichen. Mit Hilfe der sogenannten Crawler werden alle notwendigen statistischen Informationen gesammelt, künstliche Intelligenz wählt auf ihrer Basis Benutzergruppen aus und erstellt „Vorhersagen“.
Die Datenerfassung von Geräten erfolgt mit der IoT-Lösung von Microsoft. Geräte sind mit der Plattform verbunden, die Plattform sammelt die gesamte Telemetrie und legt sie in einem temporären Zwischenspeicher für temporäre Datenspeicherereignisse ab. Unsere Mitarbeiter sind bereits mit Ereignis-Hubs verbunden, verarbeiten Telemetrie, zeichnen kalte und verarbeitete Daten wie Routen und Verkehrsereignisse auf und führen Befehle aus. Ein separater Dienst kann Diagnosedaten vom Gerät anfordern, den Zustand des Fahrzeugs analysieren und benutzerdefinierte Berichte erstellen.
Für benutzerdefinierte mobile Anwendungen ist eine API implementiert, mit der der Benutzer Zugriff auf die verarbeitete Telemetrie sowie die Möglichkeit erhält, Befehle für das im Auto installierte Gerät auszuführen. Dieselbe API wird verwendet, um Zugriff auf Daten des Kundenbindungsdienstes zu erhalten. Der Benutzer erhält in seiner mobilen Anwendung Nachrichten, Sonderangebote von Händlern und Autoherstellern. Er hat die Möglichkeit, Dienste zu nutzen, z. B. einen Antrag für eine Probefahrt oder einen Kredit auszufüllen. Über die mobile Anwendung kann der Benutzer die Einstellungen für das Gerät festlegen, Telematikdienste aktivieren, z. B. Schock auslösen, die Geschwindigkeit beschleunigen oder die Zone verlassen, sowie den automatischen Motorstart gemäß Zeitplan oder Temperatur konfigurieren.
Händler wiederum haben über die bereitgestellten Portale die Möglichkeit, Diagnosen auf dem Gerät des Benutzers durchzuführen, den Remote-Motorstart beispielsweise für technische Arbeiten oder den Kundendienst zu blockieren, ein spezielles persönliches Angebot zu erstellen und Benutzeranfragen zu bearbeiten. Die Kommunikation mit dem Benutzer erfolgt in solchen Fällen meist über Push-Benachrichtigungen.
Der Händler hat auch die Möglichkeit, die mobile Anwendung anzupassen, der Händler oder der Autohersteller kann die Anwendung in den Farben seiner Marke malen, Schlüsselsymbole ändern, die in der Anwendung verfügbaren Funktionen und einige andere kosmetische Funktionen bestimmen. Hierfür wurde ein separates Portal erstellt.
Um den Kundensupport bereitzustellen, gibt es ein technisches Portal, in dem Sie die aktuellen Einstellungen der Benutzer und ihrer Geräte überprüfen und die Funktionsfähigkeit des Geräts diagnostizieren können. Falls erforderlich, können die Daten auf Wunsch des Kunden angepasst werden. Wenn der Benutzer während der Konfiguration ein anderes Automodell ausgewählt hat, kann der Support-Spezialist dies beheben. Das Portal bietet auch die Möglichkeit, dass FOTA (Firmware over the Air) die Firmware eines Geräts oder einer Gruppe von Geräten im Falle einer neuen Version der Firmware mit neuen Funktionen oder Fehlerkorrekturen aktualisiert.
Und ein paar Worte zur Sicherheit
Kommentar von Artyom Nerob, CISO:Heute steht das Sicherheitsteam des Unternehmens im aktiven Dialog mit dem Unternehmen.
Wir bemühen uns, die gesetzlichen Anforderungen einzuhalten: das Gesetz über personenbezogene Daten und die DSGVO. Es ist wichtiger denn je, einen sicheren Entwicklungszyklusprozess zu etablieren, d.h. Hinzufügen einiger Kontrollpunkte zu den aktuellen Entwicklungsverfahren in Form von Codeüberprüfung vor der Veröffentlichung der Anwendung, zusätzliche Code-Analyse von Drittanbietern, um Entwickler für das anfängliche Schreiben von sicherem Code zu sensibilisieren. Weltweite Praktiken und Standards empfehlen dringend die Sorge um die Sicherheit während der Entwicklung und nicht danach. Denn nach der Veröffentlichung sind die Kosten für die Behebung der Sicherheitsanfälligkeit um 30% höher. Wir überprüfen regelmäßig die Produktsicherheit durch Kunden, d. H. Penetrationstests. Angesichts der erhöhten Informationssicherheit bestehen wir diese Tests nun recht erfolgreich und es gibt keine Schwachstellen mit kritischen oder hohen Risiken im Produkt von Release zu Release.
Heute haben wir ein Team für die Durchführung von Penetrationstests und betrachten es als ein Team, das uns im Entwicklungsprozess dabei helfen wird, die Codesicherheit zu überprüfen, um sie in zukünftigen Versionen zu berücksichtigen. Hierbei handelt es sich nicht um vollständige Penetrationstests, sondern lediglich um eine Überprüfung, die in unseren Entwicklungsgeschäftsprozess integriert wird und unter dem Gesichtspunkt eines sicheren Codeentwicklungszyklus äußerst korrekt ist.
Darüber hinaus haben
wir das Zertifikat von ISO 27001 , dem Standard für Informationssicherheitsmanagement, gemäß einem Audit von BSI bestätigt.
Wie leben wir und wie geht es weiter?
Hier bei Bright Box suchen wir ständig nach Möglichkeiten, die Connected Car-Plattform von Remoto zu entwickeln.
, , , , , . , , Honda, Motor Car, MINI. 2017 Zurich.
, Bright Box « ». , . , , :
: , .«»:
- ( ), , ( );
- ( );
- /, ;
- ;
- (///);
- .
, , , .
?, , .
, . work-life 1- , . .
, , , - .. , .
– .
? , .
, , . , 3 . .
Boni, . :
– , . , «» . , .
– , . , – , , . , – 1-2% .
– , . 1- , .
, – .
– .
, , , .
Bright Box ist auf der Suche nach Talenten. Wenn es Ihnen nahe schien, dass Sie lesen und Autos und künstliche Intelligenz lieben, kommen Sie .
Melden Sie sich an regelmäßigen Nachrichten, Features und Analysen aus der Welt des Connected Cars können Sie hier . Es gibt auch ein offizielles Driving to the Future- Blog auf Medium .