Kubernetes pour la voiture: comment ouvrir l'accès du développeur à l'ordinateur de bord et le sécuriser

Il s'agit d'une histoire en deux parties - sur un nouveau cycle de développement automobile. Cette «série» est dédiée au développement d'EPAM, la plate-forme de véhicules connectés Aos. Alex Agizim , CTO, Automotive & Embedded Systems, explique en quoi il diffère d'une solution cloud traditionnelle et comment il permet aux développeurs de logiciels d'accéder à la voiture. Vous pouvez vous familiariser avec la première partie ici .



Dans la première partie, j'ai expliqué comment nos développements XEN Hypervisor isolent la partie service des logiciels automobiles des logiciels requis pour la sécurité. C'est l'un des obstacles à une utilisation généralisée dans l'industrie. Pour la première fois, un hyperviseur open source deviendra un concurrent à part entière des solutions commerciales fermées.

Mais ce n'est que la première étape. Pour amener les services automobiles à un nouveau niveau, vous devez «laisser» les entreprises de services et les développeurs loin de l'intégration et de l'automobile. Cela nécessite le niveau d'abstraction suivant. Pour qu'un développeur qui utilise des frameworks modernes dans le développement logiciel puisse, sans réapprendre, concevoir ses services pour les voitures.

Peut-être après avoir lu, vous voudrez dire: «Pourquoi de telles difficultés? Par exemple, j'ai acheté une tablette Android pour une voiture, mis en place les services nécessaires et je suis assez content. » Il s'agit d'une approche d'ingénierie classique, très support. Mais voyons plus loin. Du point de vue logiciel, l'industrie automobile est depuis longtemps coincée dans les approches classiques. Je vais vous dire comment nous voyons son avenir et ce que nous faisons pour cela. Et au final, passons par les principales difficultés.

Alors.

Pourquoi avez-vous besoin de laisser le développeur de services dans l'ordinateur de bord de la voiture? Et qu'est-ce qui ne va pas maintenant?

La voiture devient un appareil de plus en plus complexe. Il regorge de capteurs pour toutes les occasions, et les engins spatiaux envieront les performances des ordinateurs de bord. Avec tout cela, la voiture reste très limitée dans ses capacités. Le développement logiciel progresse, mais 90% passent.

Une analogie étroite avec les smartphones. Jusqu'en 2007-2009, il était assez difficile d'écrire une application qui s'exécuterait sur différents téléphones portables. De nombreux systèmes d'exploitation et frameworks se sont battus sur le marché: solutions de Symbian, Motorola, Ericsson, etc ... Le nombre de personnes ayant des compétences en développement pour eux était faible. Si une entreprise souhaitait qu'un grand nombre de personnes utilisent son service ou son application, un problème a commencé avec la prise en charge de différents systèmes d'exploitation et cadres.

Exactement la même chose se produit aujourd'hui dans l'industrie automobile. Pour que le service soit pris en charge par différents constructeurs automobiles, vous devez vous adapter à de nombreux cadres et à un ensemble de règles. Pour Mercedes séparément, pour Toyota séparément, etc.

Lorsque iOS est apparu en 2007, un an plus tard - Android -, l'industrie mobile a immédiatement fait une percée. En AUTOMOBILE, le conflit de deux paradigmes principaux continue.

Le premier est traditionnel. Un ordinateur de bord embarqué est un appareil fermé dont l'accès est réservé au constructeur . Les développeurs tiers n'ont aucun moyen ici: la sûreté et la sécurité avant tout. De manière fiable, mais non sans défauts. D'une part, le constructeur ferme tout sur lui-même. Il n'est pas nécessaire de blâmer les développeurs de services tiers. D'un autre côté, on ne peut pas être à la pointe du progrès. Un constructeur automobile ne peut pas couvrir entièrement la liste de souhaits du client. Le cycle de développement et de lancement sur le marché est trop long, l'équipe, même très excitée, est encore limitée. Et la voiture autonome connectée attendue s'éloigne encore plus. Comme l'intégration dans une économie partagée.

L'autre extrême consiste à considérer une voiture comme un appareil IoT . Autrement dit, il vous suffit de collecter les données de tous les capteurs automobiles, de les emballer et de les envoyer au cloud pour traitement. Répétez plusieurs milliers de fois si nécessaire. Des centaines de projets cloud, dont Google, Microsoft et Amazon, tentent de surveiller la voiture. Mais c'est un peu faux.

Auto n'est pas une maison intelligente avec des ampoules, un thermostat et un téléviseur. Il a des centaines de fois plus de capteurs et sa propre puissance de calcul. Et - plus important encore - le canal entre la voiture et le centre est instable. Même s'il est stable sous condition, il est peu probable qu'il veuille exécuter des centaines de mégaoctets de données chaque seconde. Sinon, il n'y a aucun moyen dans une telle approche - toute la logique métier du service fonctionne dans le cloud.

Qu'avons-nous trouvé en retour?

Nous avons choisi une idéologie différente. Une voiture n'est pas seulement une source d'informations provenant de capteurs. Il s'agit d'un nœud informatique à part entière sur lequel le service peut exécuter sa logique métier .

Pour cela, la voiture a besoin d'un élément de base - la plate-forme de véhicule connecté. Il vous permet d'ouvrir la voiture en tant que plate-forme logicielle. Et d'autre part, utilisez les outils adoptés dans les services cloud pour gérer le déploiement et l'orchestration des services qui devraient fonctionner sur l'ordinateur de bord.

Si nos prévisions sont vraies, nous nous retrouverons avec un écosystème où le programmeur peut agir de la manière habituelle et intégrer une partie de la logique métier dans un ordinateur de voiture. De la même manière qu'aujourd'hui dans les services cloud, il appuie sur un bouton, lance CI / CD, déploiement de tous les composants nécessaires pour tous les nœuds nécessaires. Dans notre cas, l'un des nœuds de déploiement sera une voiture. Et nous donnons un cadre qui peut le faire. Par conséquent, nous appelons notre plateforme cloud "Kubernetes for cars".

Le concept de notre vision est divisé en 2 parties:

1. isoler les logiciels de sécurité des logiciels de services connectés;
2. fournir le niveau d'abstraction nécessaire aux entreprises qui souhaitent se développer ou proposent déjà des services de véhicules connectés. Ils ne devraient pas se soucier de l'intégration, mais développer des services avec leurs outils habituels et utiliser l'ordinateur de bord comme périphérique périphérique.

Un ordinateur de bord embarqué devrait devenir un ordinateur de pointe pour les futurs services mobiles. Nous évitons aux constructeurs automobiles d'inventer des services de manière indépendante et ouvrons la voiture aux développeurs. Comment c'est arrivé avec les smartphones.

Quels cas peut-il fermer?

Le cas racine est le manque de connectivité . Dans la version cloud classique, le service perdra l'accès à la voiture. Dans la variante Connected Vehicle Platform, le développeur peut prévoir cela et pré-«flasher» la logique à l'intérieur de la voiture. Et pour la partie cloud de celui-ci - au moins tamponner les données.

La plateforme contribuera également à améliorer considérablement la gestion de la flotte et la gestion de la flotte et la maintenance prédictive. La communication avec le cloud pour ces services devient, sinon facultative, alors beaucoup moins populaire.

Un exemple tout à fait compréhensible est le travail des services de taxi. Maintenant, ils sont mis en œuvre sur les smartphones, fonctionnent très bien avec les cartes et les paiements, mais ne peuvent pas prendre en compte l'état de la voiture. Par exemple, vous êtes en retard à l'aéroport, Uber arrive - et soudain, il s'avère que le conducteur n'a assez d'essence que pour une partie du trajet. Le conducteur ne pouvait pas comprendre cela à l'avance. Mais si le service Uber a été déployé à l'intérieur de l'ordinateur de bord, au stade de la commande, je pourrais dire au backend que cette voiture particulière ne convient pas. Et la qualité de service serait plus élevée.

Dans le cas de la future économie partagée, vous devez avoir un ensemble de services dans la voiture qui sera complètement sans interface utilisateur. Par exemple, un service qui surveillera l'état technique de la voiture (l'exemple avec Uber et l'essence convient également ici). Ou un service qui surveille la façon dont une personne conduit et transmet ces données aux compagnies d'assurance ou de location.

Dans le même temps, les compagnies d'assurance ou de location doivent empêcher le passager et le conducteur de les retirer ou de les déconnecter. Aujourd'hui, ils sont tordus par des services qui ne fonctionnent qu'avec l'aide d'unités de télécommunications supplémentaires. Et c'est l'achat, l'installation, l'intégration, l'écriture du service lui-même. Cela prend beaucoup de temps et d'argent.

Par conséquent, nous considérons toujours le véhicule connecté sous deux aspects. Un côté se connecte simplement aux services Internet. Le second est l'automobile dans le cadre d'une économie partagée. Pour ce faire, tous les éléments de base doivent être intégrés dans la voiture au stade de sa production. Par conséquent, nous parlons soit avec des constructeurs automobiles soit avec des constructeurs d'ordinateurs automobiles.

L'un des problèmes de l'industrie est qu'il n'est pas possible de proposer des cas d'utilisateurs car il n'y a pas assez d'approche de plate-forme. C'était la même chose avec les téléphones portables. Vous pouvez, par exemple, dire que 2 800 entreprises proposent des solutions de gestion de flotte. Mais ils sont tous très monolithiques. Si vous devez changer quelque chose, vous devez changer les ordinateurs de bord et de télécommunication. Après tout, je veux faire quelque chose que cette unité ne peut pas faire.

Comment arrêter en toute sécurité un service d'entreprise du cloud à la voiture? Qu'est-ce qui peut empêcher cela et comment le résoudre?

1. Conteneurs

Puisque nous venons des idées de Kubernetes, alors sa principale compétence est de déployer des conteneurs. Mais avec un ordinateur de voiture, c'est difficile.

Premièrement, même si en Python, nous écrivons quelques lignes de code qui affichent «Bonjour tout le monde», la taille du conteneur peut atteindre 50 Mo. Le verser à travers un canal cellulaire peut ou non fonctionner. Même la 5G mystique a les mêmes problèmes que toute autre connexion: couverture, bande passante, stabilité. Vous devez donc augmenter les chances.

Deuxièmement, l'ordinateur de voiture est très bon en puissance de calcul, mais toujours beaucoup plus limité que n'importe quel plus petit serveur dans le cloud. De nombreux autres programmes fonctionnent dessus. Vous ne pouvez pas simplement "manger" 200 Mo de RAM.

Par conséquent, nous avons tout d'abord décrit notre type de conteneur dans le cadre de la norme OCI. Le problème avec la taille est résolu comme suit: toutes les choses de base dont un développeur a besoin pour faire fonctionner un service n'ont pas besoin d'être transportées depuis le cloud. Ils sont déjà préinstallés sur l'ordinateur de voiture. Vous devez apporter uniquement le code lui-même, ce qui, dans le pire des cas, prend des centaines de kilo-octets.

Le problème avec les ressources de l'ordinateur de bord est résolu grâce à leur description dans notre spécification de conteneur. Pour cette raison, vous pouvez très facilement déterminer les quotas que l'ordinateur de voiture surveillera. Et le service installé ne peut jamais les dépasser.

2. Sécurité

Kubernetes a été initialement conçu pour déployer et orchestrer des services dans le cloud. C'est-à-dire dans un environnement contrôlé, pris en charge et protégé des mauvaises mains. Mais nous avons une voiture et les attaquants ont un fantasme illimité. Ils peuvent retirer l'ordinateur de bord, le casser avec un appareil, entrer dans le canal entre la voiture et le cloud. Par conséquent, la sécurité est notre tâche prioritaire constante.

Nous avons mis en place un modèle avancé selon les recommandations de la US National Security Agency. Il dit ce qui suit: lors de la conception de votre système de sécurité, vous devez d'abord minimiser le nombre de lieux d'attaques potentielles, et également créer la sécurité comme un gâteau de couche. Piraté à un certain niveau? Il faut le remarquer et faire tout son possible pour ne pas se laisser aller au suivant.

Dans notre modèle, la «tarte» ressemble à ceci:

1. Nous utilisons des conteneurs comme une sorte d'isolateur au niveau du système d'exploitation Linux. Il est très difficile de sortir du conteneur;
2. Sortez du conteneur? Mais la plate-forme de véhicules connectés fonctionne sur une machine virtuelle distincte - pour laquelle nous avons besoin de XEN. Cette machine virtuelle est isolée de tous les périphériques. La communication avec les périphériques ne peut se produire que via certaines API fournies par le constructeur automobile;
3. Vous avez cassé le conteneur et la machine virtuelle? Nous avons une autre barrière - l'introspection des machines virtuelles: analyse des modèles sur lesquels la machine virtuelle fonctionne. Par exemple, une machine virtuelle essaie soudainement de manière agressive d'accéder à une sorte de mémoire, qu'elle ne touche généralement pas. Vous pouvez répondre: éteignez cette machine virtuelle, revenez à la version stable, etc.

3. Échelle

Le temps de mise à jour est-il critique sur les smartphones des utilisateurs pour les services bancaires mobiles conditionnels? Pas spécialement. Si seulement rien ne se cassait en chemin. Pour les services cloud, la question de la mise à l'échelle n'est pas un gros problème.

Pas avec une voiture. Disons que vous avez loué une voiture et que vous souhaitez utiliser votre service, ce qui vous donne une bonne police d'assurance, car vous conduisez bien. Mais pour cela, il est nécessaire qu'un service soit installé dans la voiture qui donne vos données à la compagnie d'assurance.

Vous montez dans la voiture, insérez la clé dans la serrure, tournez et après 3 secondes vous êtes prêt à partir. Il est logique que dans ces 3 secondes la voiture accepte tous les services nécessaires au voyage. Mais s'il n'y a pas une telle machine, mais 10 000? Un système qui déploie des services sur une voiture devrait pouvoir le faire rapidement. Le temps d'installation doit être constant quel que soit le nombre de véhicules à installer.

Nous avons résolu ce problème à l'aide du module complémentaire que nous avons développé au-dessus de RabbitMQ. Il facilite la mise à l'échelle et la réduction des systèmes, en fonction du nombre de nœuds que vous devez utiliser.

4. Canaux de communication

Lors du déploiement du cloud vers la voiture, le canal de communication doit être crypté. Nous utilisons Mutual TLS pour l'authentification. Cela fonctionne dans deux directions: la voiture se connecte au cloud et le cloud se connecte à la voiture. Tout cela est basé sur des certificats. Si les certificats ne correspondent pas ou si quelqu'un essaie de les remplacer, l'autorisation ne se produira pas et l'accès à l'ordinateur de bord ne sera pas obtenu.

De plus, chaque canal par lequel les conteneurs sont expédiés du cloud vers la voiture est crypté avec son propre jeu de clés. Supposons que quelqu'un a volé une clé, un certificat et a pu accéder au canal de transfert de conteneurs. Mais il ne peut accéder qu'au canal de cette voiture particulière. Quelle sera l'indication. Vous pouvez renouveler les certificats, le nouveau chiffrement Mutual TLS commencera à fonctionner dessus - et tous les efforts de craquage sont vains. Cela nous évite le problème des réseaux IoT, lorsqu'un certificat piraté peut compromettre tous les appareils.

5. La mutualisation

Imaginez un réseau IoT domestique intelligent régulier. Il a des fabricants d'appareils et des opérateurs de réseau. En règle générale, les dépendances entre les périphériques et les opérateurs sont statiques. Le cycle de vie est également assez stable: si vous commencez à échanger une ampoule intelligente contre une autre, ce ne sera pas bientôt et vous le ferez rarement.

Dans le cas de l'automobile et de l'économie partagée, ces dépendances sont très dynamiques. Il y a un constructeur automobile . Il y a un acheteur / propriétaire - disons que c'est une entreprise d'autopartage. Il y a un opérateur de service. Et il y a un utilisateur final .

Le propriétaire, l'opérateur et l'utilisateur peuvent changer tout le temps. Lundi matin, la voiture appartient à une certaine banque, l'opérateur est la société A. Après le déjeuner, elle est déjà exploitée par la société B. Les utilisateurs de différents opérateurs peuvent également être différents. Mais en même temps, les services qui leur appartiennent doivent migrer après eux pour différentes voitures.

C'est ce qu'on appelle ici la mutualisation et est pris en charge par la conception dans notre système de gestion du déploiement de services. Les rôles du fournisseur de services et du fournisseur de services ont déjà été définis; aucune logique supplémentaire n'est nécessaire. Vous pouvez attribuer différents services à une voiture. Supposons qu'une voiture soit transférée à un autre propriétaire. Les services du précédent seront automatiquement supprimés et les services du nouveau seront automatiquement fournis. Les réseaux IoT d'aujourd'hui et les mêmes Kubernetes ne conviennent pas - ils n'ont tout simplement pas rencontré un tel cas.

6. Suivi du fonctionnement des services

Pour communiquer avec le service automobile, il existe une API standardisée appelée VIS - Vehicle Information Services. Il est normalisé par le W3C. Cette API dans notre concept est implémentée et contrôlée par le constructeur automobile. Le service des véhicules connectés est sous contrôle total.

Différents fabricants commencent à prendre en charge cette API. Et le développeur ne se soucie pas du fabricant pour lequel il rend le service.

Bien sûr, chaque constructeur automobile peut faire des exceptions. Comme les smartphones: les Galaxy S9 et S10 ont la même API de base, mais chacun a des choses qui conviennent à un modèle particulier. Dans une voiture, les informations de base peuvent également être obtenues quel que soit son type. Et pour des choses spécifiques, leurs propres nuances. Cela permet aux fabricants de proposer des éléments uniques et distingués à valeur ajoutée.

Sur quels composants de la plateforme est-il écrit? Et sur quoi sera-t-il possible d'écrire des services pour les voitures?

La plateforme elle-même est écrite en Python. La gestion de niveau supérieur du système de déploiement est écrite en Python. Toute la partie embarquée est écrite en C.

En ce qui concerne les services, le premier que nous avons pris en charge pour Python, a ajouté JavaScript. À la demande de plusieurs constructeurs automobiles, .NET a été ajouté. On parle de Java.

En général, il s'agit d'un problème tactique. Il n'y a pas de programmeurs JavaScript - il y a des programmeurs. Je pense qu'avec le développement de l'automobile, des programmeurs apparaîtront qui sont impliqués dans des services de véhicules spécifiquement connectés. Une ampoule «que faire s'il n'y a pas de connectivité?» Clignotera toujours dans leur tête Indépendamment de ce que nous avons dans l'air - 5G ou 10G. La connexion sans fil ne fonctionne pas 100% du temps.

Comment les constructeurs automobiles réagissent-ils à la plateforme?

Tout constructeur automobile dispose aujourd'hui d'une division interne qui développe des services connectés. Ces personnes sont capables de travailler rapidement. Mais ils sont gênés par leurs propres départements de matériel et de logiciels internes.

Nous nous concentrons là-dessus. Nous apportons un outil à l'aide duquel leurs propres services de développement peuvent travailler plus rapidement et de manière plus flexible. Et les gars de Embedded, qui changent maintenant une ligne de code pendant 2 ans, pourront le faire une fois avec la plate-forme - puis le système leur permettra d'être indépendants d'eux.

En général, les fabricants examinent Aos avec suffisamment d'attention. Mais avec intérêt - car cela leur ouvre de nouvelles opportunités. Par exemple, ils peuvent construire un modèle commercial comme Amazon, Google, Microsoft: attribuer des frais de service pour l'utilisation de l'ordinateur de bord, de l'API, etc. De plus, je pense qu'un jour, ils arriveront à un modèle de marché. Autrement dit, les développeurs de logiciels et de services connectés paieront une commission à l'utilisateur qui installe son service.

Dans l'industrie mobile, cela s'est produit rapidement. Mais nous comprenons: les gens ne changent pas de voiture chaque année. Le cycle de développement de logiciels automobiles dure de 4 à 6 ans. Par conséquent, ce dont nous parlons aujourd'hui avec les constructeurs automobiles commencera à apparaître sous la forme d'une sorte de pilotes à peine avant 2022.

Essayons-nous de copier ou de concurrencer Tesla?

Non, et vice versa. Contrairement à d'autres, Tesla peut mettre à jour par voie aérienne tout logiciel fonctionnant sur n'importe quel ordinateur de la voiture. Ainsi, ils peuvent constamment introduire de nouvelles fonctionnalités. Mais leur ordinateur n'est pas une plateforme pour développer des services d'autopartage. Vous ne pouvez pas acheter 10 voitures, embaucher 2 programmeurs et écrire un service de partage de voiture sympa. Par conséquent, Tesla est également l'un de nos clients potentiels. Et des plus avancés.

Avec notre plateforme, ni Tesla ni d'autres fabricants n'auront à consacrer du temps à l'invention d'un vélo. Après tout, personne dans les applications Cloud ne développe déjà leurs Kubernetes. Notre vision est que cela devrait se produire avec la plate-forme de véhicule connecté.

Si nous parlons de la concurrence en général, jusqu'à présent, nous n'avons vu aucun concurrent qui ait au moins parlé de ce dont nous parlons. Il s'est avéré que l'industrie automobile est toujours très fermée. Et beaucoup de choses dans la plate-forme - le même support pour FOTA et SOTA - nous ne le faisons pas seulement parce qu'elles sont nécessaires maintenant, mais en avance sur le calendrier.

Cependant, je ne pense pas qu'à l'avenir, il y aura une seule plate-forme pour toutes les voitures. , 2-3 . , . — . , .