Kubernetes untuk mobil: cara membuka akses pengembang ke komputer yang terpasang dan membuatnya aman

Ini adalah kisah dua bagian - tentang babak baru pengembangan otomotif. "Seri" ini didedikasikan untuk pengembangan EPAM sendiri, Aos Connected Vehicle Platform. Alex Agizim , CTO, Automotive & Embedded Systems, menjelaskan perbedaannya dari solusi cloud tradisional dan bagaimana hal itu memberi pengembang perangkat lunak akses ke mobil. Anda dapat membiasakan diri dengan bagian pertama di sini .



Pada bagian pertama, saya berbicara tentang bagaimana pengembangan XEN Hypervisor kami mengisolasi bagian layanan dari perangkat lunak otomotif dari perangkat lunak yang diperlukan keselamatan. Ini adalah salah satu hambatan untuk meluasnya penggunaan di industri. Untuk pertama kalinya, hypervisor open source akan menjadi pesaing penuh untuk solusi komersial tertutup.

Tapi ini hanya langkah pertama. Untuk membawa layanan otomotif ke tingkat yang baru, Anda harus "membiarkan" perusahaan dan pengembang layanan jauh dari tertanam dan otomotif ke dalamnya. Ini membutuhkan tingkat abstraksi selanjutnya. Sehingga pengembang yang menggunakan kerangka kerja modern dalam pengembangan perangkat lunak dapat, tanpa belajar ulang, merancang layanannya untuk mobil.

Mungkin setelah membaca Anda akan ingin mengatakan: "Mengapa kesulitan seperti itu? Sebagai contoh, saya membeli tablet Android untuk mobil, mengatur layanan yang diperlukan dan saya cukup senang. " Ini adalah pendekatan rekayasa klasik, sangat mendukung. Tapi mari kita lihat lebih luas. Industri otomotif, dari sudut pandang perangkat lunak, telah lama terjebak dalam pendekatan klasik. Saya akan memberi tahu Anda bagaimana kami melihat masa depannya dan apa yang kami lakukan untuk ini. Dan pada akhirnya, mari kita melewati kesulitan utama.

Jadi

Mengapa Anda harus membiarkan pengembang layanan masuk ke komputer on-board mobil? Dan apa yang salah sekarang?

Mobil menjadi perangkat yang semakin kompleks. Itu penuh dengan sensor untuk semua kesempatan, dan pesawat ruang angkasa akan iri kinerja komputer on-board. Dengan semua ini, kemampuan mobil tetap sangat terbatas. Pengembangan perangkat lunak maju, tetapi 90% berlalu.

Analogi yang dekat adalah smartphone. Sampai 2007-9, menulis aplikasi yang akan berjalan pada ponsel yang berbeda cukup sulit. Banyak sistem operasi dan kerangka kerja berjuang di pasar: solusi dari Symbian, Motorola, Ericsson, dll. Jumlah orang dengan keterampilan pengembangan untuk mereka kecil. Jika sebuah bisnis menginginkan sejumlah besar orang untuk menggunakan layanan atau aplikasinya, masalah dimulai dengan dukungan pada sistem operasi dan kerangka kerja yang berbeda.

Hal yang persis sama terjadi hari ini di industri otomotif. Agar layanan dapat didukung oleh pabrikan mobil yang berbeda, Anda harus beradaptasi dengan banyak kerangka kerja dan seperangkat aturan. Untuk Mercedes secara terpisah, untuk Toyota secara terpisah, dll.

Ketika iOS muncul pada 2007, setahun kemudian - Android - industri seluler segera membuat terobosan. Dalam AUTOMOBILE, konflik dua paradigma utama terus berlanjut.

Yang pertama adalah tradisional. Komputer mobil terpasang adalah perangkat tertutup, akses yang hanya tersedia untuk pabrikan . Pengembang pihak ketiga tidak memiliki jalan di sini: keselamatan dan keamanan pertama-tama. Andal, tapi bukan tanpa cacat. Di satu sisi, pabrikan menutup semuanya pada dirinya sendiri. Tidak perlu menyalahkan pengembang layanan pihak ketiga. Di sisi lain, seseorang tidak bisa berada di ujung tombak kemajuan. Satu pembuat mobil tidak dapat sepenuhnya menutupi Daftar Keinginan pelanggan. Siklus pengembangan dan peluncuran pasar terlalu lama, tim, bahkan sangat bersemangat, masih terbatas. Dan mobil self-driving yang terhubung diharapkan bergerak lebih jauh. Seperti integrasi ke dalam ekonomi bersama.

Ekstrem lainnya adalah menganggap mobil sebagai perangkat IoT . Artinya, cukup kumpulkan data dari semua sensor otomotif, kemas dan kirim ke cloud untuk diproses. Ulangi ribuan kali jika perlu. Jadi ratusan proyek cloud, termasuk Google, Microsoft dan Amazon, sedang mencoba untuk menonton mobil. Tapi ini agak salah.

Otomatis bukan rumah pintar dengan lampu, termostat, dan TV. Ia memiliki ratusan kali lebih banyak sensor dan daya komputasi sendiri. Dan - yang paling penting - saluran antara mobil dan pusat tidak stabil. Sekalipun kondisinya stabil, kecil kemungkinannya bahwa ia ingin menjalankan ratusan megabita data setiap detik. Jika tidak, tidak ada cara dalam pendekatan ini - seluruh logika bisnis dari layanan ini bekerja di cloud.

Apa yang kita dapatkan sebagai imbalan?

Kami telah memilih ideologi yang berbeda. Mobil bukan hanya sumber informasi dari sensor. Ini adalah simpul komputasi lengkap di mana layanan dapat mengeksekusi logika bisnisnya .

Untuk ini, mobil memerlukan elemen dasar - Platform Kendaraan Terhubung. Ini memungkinkan Anda untuk membuka mobil sebagai platform perangkat lunak. Dan di sisi lain, gunakan alat yang diadopsi dalam layanan cloud untuk menangani penyebaran dan pengaturan layanan yang harus bekerja pada komputer on-board.

Jika perkiraan kami benar, kami akan berakhir dengan ekosistem di mana programmer dapat bertindak seperti biasa dan menanamkan beberapa bagian dari logika bisnis ke dalam komputer mobil. Dengan cara yang sama seperti saat ini dalam layanan cloud, ia menekan tombol, meluncurkan CI / CD, penyebaran semua komponen yang diperlukan untuk semua node yang diperlukan. Dalam kasus kami, salah satu simpul untuk penyebaran akan menjadi mobil. Dan kami memberikan kerangka kerja yang bisa melakukan ini. Karena itu, kami menyebut platform cloud kami "Kubernetes untuk mobil."

Konsep dalam visi kami dibagi menjadi 2 bagian:

1. mengisolasi perangkat lunak keselamatan dari perangkat lunak layanan yang terhubung;
2. untuk memberikan tingkat abstraksi yang diperlukan bagi perusahaan yang ingin mengembangkan atau sudah melakukan layanan kendaraan yang terhubung. Mereka seharusnya tidak repot-repot dengan embedded, tetapi mengembangkan layanan dengan alat mereka yang biasa dan menggunakan komputer on-board sebagai perangkat tepi.

Komputer mobil terpasang harus menjadi komputer canggih untuk layanan seluler di masa mendatang. Kami menyelamatkan produsen mobil dari menciptakan layanan secara independen dan membuka mobil untuk pengembang. Bagaimana itu pernah terjadi dengan smartphone.

Kasing apa yang bisa ditutup?

Kasus root adalah kurangnya konektivitas . Dalam versi cloud klasik, layanan akan kehilangan akses ke mobil. Dalam varian Connected Vehicle Platform, pengembang dapat melihat ini dan melakukan pra-"flash" logika di dalam mobil. Dan untuk bagian cloud itu - setidaknya buffer data.

Platform ini juga akan membantu secara signifikan meningkatkan manajemen armada dan manajemen armada & pemeliharaan prediktif. Komunikasi dengan cloud untuk layanan ini menjadi, jika bukan opsional, maka menjadi kurang populer.

Contoh yang sepenuhnya dapat dipahami adalah pekerjaan layanan taksi. Sekarang mereka diimplementasikan pada smartphone, berfungsi baik dengan kartu dan pembayaran, tetapi tidak dapat memperhitungkan keadaan mobil. Misalnya, Anda terlambat ke bandara, Uber tiba - dan tiba-tiba ternyata pengemudi memiliki bensin yang cukup hanya untuk sebagian saja. Pengemudi tidak dapat memahami hal ini sebelumnya. Tetapi jika layanan Uber digunakan di dalam komputer on-board, maka pada tahap pemesanan, saya dapat mengatakan kepada backend bahwa mobil khusus ini tidak cocok. Dan kualitas layanan akan lebih tinggi.

Dalam hal ekonomi bersama di masa depan, Anda perlu memiliki satu set layanan di dalam mobil yang akan sepenuhnya tanpa UI. Misalnya, layanan yang akan memantau kondisi teknis mobil (contoh dengan Uber dan bensin juga cocok di sini). Atau layanan yang memantau bagaimana seseorang mengemudi, dan memberikan data ini kepada perusahaan asuransi atau persewaan.

Pada saat yang sama, perusahaan asuransi atau persewaan perlu mencegah penumpang dan pengemudi melepas atau memutuskan hubungan mereka. Hari ini mereka dipelintir oleh layanan yang hanya bekerja dengan bantuan unit telekomunikasi tambahan. Dan ini adalah pembelian, instalasi, integrasi, penulisan layanan itu sendiri. Butuh banyak waktu dan uang.

Oleh karena itu, kami selalu melihat Kendaraan Terhubung dalam dua aspek. Satu sisi hanya menghubungkan ke layanan Internet. Yang kedua adalah otomatis sebagai bagian dari ekonomi bersama. Untuk melakukan ini, semua elemen dasar harus diintegrasikan ke dalam mobil pada tahap produksinya. Karena itu, kami berbicara dengan produsen mobil atau dengan produsen komputer mobil.

Salah satu masalah industri adalah bahwa tidak mungkin untuk membuat kasus pengguna karena tidak ada pendekatan platform yang cukup. Itu sama dengan ponsel. Anda dapat, misalnya, mengatakan bahwa ada 2.800 perusahaan yang membuat solusi untuk manajemen armada. Tetapi mereka semua sangat monolitik. Jika Anda perlu mengubah sesuatu, Anda harus mengganti komputer on-board dan telekomunikasi. Lagi pula, saya ingin melakukan sesuatu yang tidak bisa dilakukan unit ini.

Bagaimana cara mematikan layanan bisnis dari cloud ke mobil? Apa yang bisa mencegah ini dan bagaimana kita menyelesaikannya?

1. Wadah

Karena kita berasal dari ide-ide Kubernetes, maka keterampilan utamanya adalah untuk menggunakan kontainer. Tetapi dengan komputer mobil itu sulit.

Pertama, bahkan jika dalam Python kita menulis beberapa baris kode yang mencetak "Halo, dunia", ukuran wadah bisa mencapai 50 MB. Mencurinya melalui saluran seluler mungkin berhasil atau tidak. Bahkan 5G mistis memiliki masalah yang sama dengan koneksi lain: jangkauan, bandwidth, stabilitas. Jadi, Anda perlu meningkatkan peluang.

Kedua, komputer mobil sangat bagus dalam daya komputasi, tetapi masih jauh lebih terbatas daripada server terkecil di cloud. Banyak program lain berjalan di sana. Anda tidak bisa datang dan "memakan" 200 MB RAM.

Karena itu, pertama-tama, kami menggambarkan jenis wadah kami dalam kerangka standar OCI. Masalah dengan ukuran diselesaikan sebagai berikut: semua hal dasar yang perlu dikembangkan pengembang untuk layanan tidak perlu dibawa dari cloud. Mereka sudah diinstal sebelumnya di komputer mobil. Anda hanya perlu membawa kode itu sendiri, yang dalam kasus terburuk membutuhkan ratusan kilobyte.

Masalah dengan sumber daya komputer terpasang diselesaikan melalui deskripsinya dalam spesifikasi wadah kami. Karena ini, Anda dapat dengan mudah menentukan kuota yang akan dipantau komputer mobil. Dan layanan yang diinstal tidak pernah dapat melebihi mereka.

2. Keamanan

Kubernet awalnya dirancang untuk menggunakan dan mengatur layanan di Cloud. Yaitu, secara terkendali, didukung dan dilindungi dari lingkungan tangan yang salah. Tetapi kami memiliki mobil, dan para penyerang memiliki fantasi yang tidak terbatas. Mereka dapat menarik keluar komputer, memecahkannya dengan beberapa perangkat, masuk ke saluran antara mobil dan cloud. Karena itu, keamanan adalah tugas utama kami yang selalu menjadi prioritas kami.

Kami telah menerapkan model lanjutan sesuai dengan rekomendasi Badan Keamanan Nasional AS. Dikatakan sebagai berikut: ketika merancang sistem keamanan Anda, Anda harus terlebih dahulu meminimalkan jumlah tempat serangan potensial, dan juga membangun keamanan sebagai kue lapis. Diretas pada tingkat tertentu? Penting untuk memperhatikan hal ini dan melakukan segala upaya untuk tidak melepaskan yang berikutnya.

Dalam model kami, "pai" terlihat seperti ini:

1. Kami menggunakan wadah sebagai semacam isolator di tingkat OS Linux. Sangat sulit untuk keluar dari wadah;
2. Keluar dari wadah? Tetapi Platform Connected Vehiclle berjalan di mesin virtual yang terpisah - untuk itulah kita membutuhkan XEN. Mesin virtual ini diisolasi dari semua periferal. Komunikasi dengan periferal hanya dapat terjadi melalui beberapa API yang disediakan oleh pabrikan mobil;
3. Pecah wadah dan mesin virtual? Kami memiliki satu penghalang lagi - introspeksi mesin virtual: analisis pola di mana mesin virtual bekerja. Sebagai contoh, sebuah mesin virtual tiba-tiba secara agresif mencoba untuk mendapatkan semacam memori, yang biasanya tidak disentuh. Anda dapat merespons: matikan mesin virtual ini, putar kembali ke versi stabil, dll.

3. Skala

Apakah waktu pembaruan penting pada ponsel cerdas pengguna untuk mobile banking bersyarat? Tidak terutama. Kalau saja tidak ada yang rusak di jalan. Untuk layanan cloud, masalah penskalaan bukanlah masalah besar.

Bukan dengan mobil. Katakanlah Anda menyewa mobil dan ingin menggunakan layanan Anda, yang memberi Anda polis asuransi yang baik, karena Anda mengemudi dengan baik. Tetapi untuk ini, perlu bahwa layanan dipasang di mobil yang memberikan data Anda ke perusahaan asuransi.

Anda masuk ke mobil, memasukkan kunci ke kunci, putar dan setelah 3 detik Anda siap untuk pergi. Adalah logis jika dalam 3 detik ini mobil menerima semua layanan yang diperlukan untuk perjalanan. Tetapi jika tidak ada satu mesin seperti itu, tetapi 10.000? Sistem yang menyebarkan layanan ke mobil harus dapat melakukan ini dengan cepat. Waktu pemasangan harus konstan terlepas dari jumlah kendaraan yang dipasang.

Kami memecahkan masalah ini dengan bantuan add-on yang kami kembangkan di atas RabbitMQ. Ini membuatnya mudah untuk meningkatkan dan menurunkan sistem, tergantung pada berapa banyak node yang perlu Anda gunakan.

4. Saluran komunikasi

Ketika penyebaran dari cloud ke mobil terjadi, saluran komunikasi harus dienkripsi. Kami menggunakan Mutual TLS untuk otentikasi. Ini bekerja dalam dua arah: mobil masuk ke cloud, dan cloud masuk ke mobil. Semua ini berdasarkan sertifikat. Jika sertifikat tidak cocok atau seseorang mencoba untuk menggantinya, otorisasi tidak akan terjadi dan akses ke komputer terpasang tidak akan diperoleh.

Selain itu, setiap saluran melalui mana kontainer dikirim dari cloud ke mobil dienkripsi dengan set kunci sendiri. Misalkan seseorang telah mencuri kunci, sertifikat, dan bisa masuk ke saluran transfer kontainer. Tapi dia hanya bisa sampai ke saluran mobil khusus ini. Tentang apa indikasinya. Anda dapat memperbarui sertifikat, enkripsi Saling TLS baru akan mulai bekerja pada mereka - dan semua upaya pemecahan telah sia-sia. Ini menyelamatkan kita dari masalah jaringan IoT, ketika satu sertifikat yang diretas dapat membahayakan semua perangkat.

5. Multitenancy

Bayangkan sebuah jaringan IoT rumah pintar biasa. Ini memiliki produsen perangkat dan operator jaringan. Sebagai aturan, ketergantungan antara perangkat dan operator bersifat statis. Siklus hidup juga cukup stabil: jika Anda mulai menukar satu bola lampu pintar dengan yang lain, bola lampu itu tidak akan segera dan Anda akan jarang melakukannya.

Dalam hal mobil dan ekonomi bersama, ketergantungan ini sangat dinamis. Ada pabrikan mobil . Ada pembeli / pemilik - katakanlah ini adalah perusahaan berbagi mobil. Ada operator layanan. Dan ada pengguna akhir.

Pemilik, operator, dan pengguna dapat berubah setiap saat. Pada hari Senin pagi, mobil milik bank tertentu, operatornya adalah perusahaan A. Setelah makan siang, sudah dioperasikan oleh perusahaan B. Pengguna dari operator yang berbeda juga bisa berbeda. Tetapi pada saat yang sama, layanan milik mereka harus bermigrasi setelah mereka untuk mobil yang berbeda.

Ini disebut Multitenancy di sini dan didukung oleh desain dalam sistem manajemen penyebaran layanan kami. Peran penyedia layanan dan penyedia layanan telah ditentukan, tidak ada logika tambahan yang diperlukan. Anda dapat menetapkan layanan yang berbeda untuk satu mobil. Misalkan sebuah mobil ditransfer ke pemilik lain. Layanan yang sebelumnya akan dihapus secara otomatis, dan layanan yang baru akan secara otomatis dikirimkan. Jaringan IoT saat ini dan Kubernet yang sama tidak cocok - mereka hanya tidak menemukan kasus seperti itu.

6. Memantau pengoperasian layanan

Untuk berkomunikasi dengan layanan mobil ada API standar yang disebut VIS - Layanan Informasi Kendaraan. Ini distandarisasi oleh W3C. API ini dalam konsep kami diimplementasikan dan dikendalikan oleh pabrikan mobil. Layanan kendaraan yang terhubung berada di bawah kendali penuh.

Berbagai pabrikan mulai mendukung API ini. Dan pengembang tidak peduli untuk apa dia membuat layanan.

Tentu saja, setiap produsen mobil dapat membuat beberapa pengecualian. Seperti halnya smartphone: Galaxy S9 dan S10 memiliki API dasar yang sama, tetapi masing-masing memiliki hal-hal yang adil untuk model tertentu. Di dalam mobil, informasi dasar juga dapat diperoleh terlepas dari jenisnya. Dan untuk hal-hal tertentu, nuansa mereka sendiri. Hal ini memungkinkan produsen untuk menghasilkan beberapa hal unik dan berbeda dengan nilai tambah.

Apa saja komponen dari platform yang ditulis? Dan pada apa mungkin untuk menulis layanan untuk mobil?

Platform itu sendiri ditulis dalam Python. Manajemen tingkat atas dari sistem penyebaran ditulis dalam Python. Seluruh bagian tertanam ditulis dalam C.

Adapun layanan, pertama kami membuat dukungan untuk Python, menambahkan JavaScript. Atas permintaan beberapa produsen mobil, .NET ditambahkan. Ada pembicaraan tentang Jawa.

Secara umum, ini adalah masalah taktis. Tidak ada programmer JavaScript - ada programmer. Saya berpikir bahwa dengan perkembangan otomotif, programmer akan muncul yang terlibat dalam layanan kendaraan yang terhubung khusus. Bola lampu "apa yang harus dilakukan jika tidak ada konektivitas?" Akan selalu berkedip di kepala mereka Terlepas dari apa yang kita miliki di udara - 5G atau 10G. Koneksi nirkabel tidak berfungsi 100% setiap saat.

Bagaimana produsen mobil bereaksi terhadap platform?

Setiap pembuat mobil saat ini memiliki divisi internal yang mengembangkan layanan terhubung. Orang-orang ini mampu bekerja cepat. Tetapi mereka dihambat oleh departemen perangkat keras dan perangkat lunak internal mereka sendiri.

Kami fokus pada ini. Kami membawa alat dengan bantuan yang departemen pengembangan mereka sendiri dapat bekerja lebih cepat dan lebih fleksibel. Dan orang-orang dari embedded, yang sekarang mengubah satu baris kode selama 2 tahun, akan dapat melakukan ini sekali dengan platform - maka sistem akan memungkinkan mereka untuk terlepas dari mereka.

Secara umum, produsen melihat Aos dengan cukup hati-hati. Tetapi dengan minat - karena itu membuka peluang baru bagi mereka. Misalnya, mereka dapat membangun model bisnis seperti Amazon, Google, Microsoft: menetapkan biaya layanan untuk menggunakan komputer, API, dll. Juga, saya pikir suatu hari mereka akan datang ke model pasar. Artinya, pengembang perangkat lunak dan layanan yang terhubung akan membayar komisi untuk pengguna yang memasang layanan mereka.

Dalam industri seluler, ini terjadi dengan cepat. Tapi kami mengerti: orang tidak mengganti mobil setiap tahun. Siklus pengembangan perangkat lunak otomotif membutuhkan waktu 4-6 tahun. Oleh karena itu, apa yang kita bicarakan dengan pembuat mobil hari ini akan mulai muncul dalam bentuk semacam pilot hampir sebelum tahun 2022.

Apakah kita mencoba menyalin atau bersaing dengan Tesla?

Tidak, dan bahkan sebaliknya. Tesla, tidak seperti yang lain, dapat memperbarui melalui udara perangkat lunak apa pun yang berjalan di komputer mana pun di mobil. Sehingga mereka dapat terus-menerus memperkenalkan fitur-fitur baru. Tetapi komputer mereka bukan platform untuk mengembangkan layanan berbagi mobil. Anda tidak dapat membeli 10 mobil, menyewa 2 programmer dan menulis layanan berbagi mobil yang keren. Karena itu, Tesla juga merupakan salah satu pelanggan potensial kami. Dan dari yang paling maju.

Dengan platform kami, baik Tesla maupun pabrikan lain tidak perlu menghabiskan waktu untuk menciptakan sepeda. Lagipula, tidak ada seorang pun di aplikasi Cloud yang sudah mengembangkan Kubernet mereka. Visi kami adalah bahwa ini harus terjadi dengan Platform Kendaraan Terhubung.

Jika kita berbicara tentang kompetisi secara umum, sejauh ini kita belum melihat satu pesaing pun yang setidaknya membicarakan tentang apa yang kita bicarakan. Ternyata, industri otomotif masih sangat tertutup. Dan banyak hal di platform - dukungan yang sama untuk FOTA dan SOTA - kami tidak hanya karena mereka dibutuhkan sekarang, tetapi lebih cepat dari jadwal.

Namun, saya tidak berpikir bahwa di masa depan akan ada satu platform untuk semua mobil. , 2-3 . , . — . , .