Olahpesan otomotif, arsitektur referensi data & analitik

  • Artikel

Arsitektur referensi ini dirancang untuk mendukung OEM otomotif dan Penyedia Mobilitas dalam pengembangan aplikasi kendaraan dan layanan digital yang terhubung canggih. Tujuannya adalah untuk menyediakan infrastruktur olahpesan, data, dan analitik yang andal dan efisien. Arsitektur ini mencakup pemrosesan pesan, pemrosesan perintah, dan kemampuan penyimpanan status untuk memfasilitasi integrasi berbagai layanan melalui API terkelola. Ini juga menjelaskan solusi data dan analitik yang memastikan penyimpanan dan aksesibilitas data dengan cara yang dapat diskalakan dan aman untuk rekayasa digital dan berbagi data dengan ekosistem mobilitas yang lebih luas.

Sistem

Diagram arsitektur tingkat tinggi.

Diagram arsitektur tingkat tinggi menunjukkan blok logis utama dan layanan olahpesan otomotif, solusi data & analitik. Detail lebih lanjut dapat ditemukan di bagian berikut.

  • Kendaraan berisi kumpulan perangkat. Beberapa perangkat ini adalah Perangkat Lunak yang Ditentukan, dan dapat menjalankan beban kerja perangkat lunak yang dikelola dari cloud. Kendaraan ini mengumpulkan dan memproses berbagai data, mulai dari informasi sensor dari perangkat elektro-mekanik seperti sistem manajemen baterai hingga file log perangkat lunak.
  • Layanan olahpesan kendaraan mengelola komunikasi ke dan dari kendaraan. Ini bertanggung jawab untuk memproses pesan, menjalankan perintah menggunakan alur kerja dan menengahi backend manajemen kendaraan, pengguna, dan perangkat. Ini juga melacak pendaftaran dan provisi kendaraan, perangkat, dan sertifikat.
  • Backend manajemen kendaraan dan perangkat adalah sistem OEM yang melacak konfigurasi kendaraan dari pabrik untuk perbaikan dan pemeliharaan.
  • Operator memiliki IT & operasi untuk memastikan ketersediaan dan performa kendaraan dan backend.
  • Layanan data & analitik menyediakan penyimpanan data dan memungkinkan pemrosesan dan analitik untuk semua pengguna data. Ini mengubah data menjadi wawasan yang mendorong keputusan bisnis yang lebih baik.
  • Produsen kendaraan menyediakan layanan digital sebagai nilai tambah untuk pelanggan akhir, dari aplikasi pendamping hingga aplikasi perbaikan dan pemeliharaan.
  • Beberapa layanan digital memerlukan integrasi bisnis ke sistem backend seperti sistem Dealer Management (DMS), Customer Relationship Management (CRM) atau Enterprise Resource Planning (ERP).
  • Backend manajemen persetujuan adalah bagian dari manajemen pelanggan dan melacak otorisasi pengguna untuk pengumpulan data sesuai dengan undang-undang negara/wilayah geografis.
  • Data yang dikumpulkan dari kendaraan adalah input ke proses rekayasa digital, dengan tujuan peningkatan produk berkelanjutan menggunakan analitik dan pembelajaran mesin.
  • Ekosistem mobilitas cerdas dapat berlangganan dan mengonsumsi telemetri langsung serta wawasan agregat untuk menyediakan lebih banyak produk dan layanan.

Microsoft adalah anggota grup kerja Eclipse Software Defined Vehicle, forum untuk kolaborasi terbuka menggunakan sumber terbuka untuk platform perangkat lunak kendaraan.

Aliran data

Arsitektur ini menggunakan pola olahpesan penerbit/pelanggan untuk memisahkan kendaraan dari layanan.

Pesan kendaraan ke cloud

Aliran data kendaraan ke cloud digunakan untuk memproses data telemetri dari kendaraan. Data telemetri dapat dikirim secara berkala (status kendaraan, pengumpulan dari sensor kendaraan) atau berdasarkan peristiwa (pemicu pada kondisi kesalahan, reaksi terhadap tindakan pengguna).

Diagram aliran data olahpesan.

  1. Kendaraan dikonfigurasi untuk pelanggan berdasarkan opsi yang dipilih menggunakan API Manajemen. Konfigurasi berisi:
    1. Informasi provisi untuk kendaraan dan perangkat.
    2. Konfigurasi pengumpulan data kendaraan awal berdasarkan pertimbangan pasar dan bisnis.
    3. Penyimpanan pengaturan persetujuan pengguna awal berdasarkan opsi kendaraan dan penerimaan pengguna.
  2. Kendaraan menerbitkan pesan telemetri dan peristiwa melalui klien Message Queuing Telemetry Transport (MQTT) dengan topik yang ditentukan ke fitur broker MQTT Azure Event Grid di layanan olahpesan kendaraan.
  3. Event Grid merutekan pesan ke pelanggan yang berbeda berdasarkan topik dan atribut pesan.
    1. Pesan berprioritas rendah yang tidak memerlukan pemrosesan langsung (misalnya, pesan analitik) dirutekan langsung ke penyimpanan menggunakan instans Azure Event Hubs untuk buffering.
    2. Pesan prioritas tinggi yang memerlukan pemrosesan segera (misalnya, perubahan status yang harus divisualisasikan dalam aplikasi yang menghadap pengguna) dirutekan ke Azure Function menggunakan instans Azure Event Hubs untuk buffering.
  4. Pesan berprioritas rendah disimpan langsung di data lake menggunakan pengambilan peristiwa. Pesan-pesan ini dapat menggunakan decoding dan pemrosesan batch untuk biaya optimal.
  5. Pesan prioritas tinggi diproses dengan fungsi Azure. Fungsi ini membaca pengaturan persetujuan kendaraan, perangkat, dan pengguna dari Device Registry dan melakukan langkah-langkah berikut:
    1. Memverifikasi bahwa kendaraan dan perangkat terdaftar dan aktif.
    2. Memverifikasi bahwa pengguna telah memberikan persetujuan untuk topik pesan.
    3. Dekode dan memperkaya payload.
    4. Menambahkan lebih banyak informasi perutean.
  6. Pusat Aktivitas Telemetri Langsung dalam solusi data &analitik menerima pesan yang didekodekan. Azure Data Explorer menggunakan penyerapan streaming untuk memproses dan menyimpan pesan saat diterima.
  7. Lapisan Layanan digital menerima pesan yang didekodekan. Bus Layanan memberikan pemberitahuan kepada aplikasi tentang perubahan/peristiwa penting pada status kendaraan. Azure Data Explorer menyediakan status kendaraan terakhir yang diketahui dan riwayat jangka pendek.

Pesan cloud ke kendaraan

Aliran data cloud ke kendaraan sering digunakan untuk menjalankan perintah jarak jauh di kendaraan dari layanan digital. Perintah ini termasuk kasus penggunaan seperti pintu kunci/buka kunci, kontrol iklim (atur suhu kabin pilihan) atau perubahan konfigurasi. Eksekusi yang berhasil tergantung pada status kendaraan dan mungkin memerlukan beberapa waktu untuk menyelesaikannya.

Tergantung pada kemampuan kendaraan dan jenis tindakan, ada beberapa kemungkinan pendekatan untuk eksekusi perintah. Kami membahas dua variasi:

  • Mengarahkan pesan cloud ke perangkat (A) yang tidak memerlukan pemeriksaan persetujuan pengguna dan dengan waktu respons yang dapat diprediksi. Ini mencakup pesan untuk masing-masing dan beberapa kendaraan. Contohnya termasuk pemberitahuan cuaca.
  • Perintah kendaraan (B) yang menggunakan status kendaraan untuk menentukan keberhasilan dan memerlukan persetujuan pengguna. Solusi olahpesan harus memiliki logika alur kerja perintah yang memeriksa persetujuan pengguna, melacak status eksekusi perintah dan memberi tahu layanan digital setelah selesai.

Perintah pengguna aliran data berikut yang dikeluarkan dari layanan digital aplikasi pendamping sebagai contoh.

Diagram alur data perintah dan kontrol.

Pesan langsung dijalankan dengan jumlah hop minimum untuk performa terbaik (A):

  1. Aplikasi pendamping adalah layanan terautentikasi yang dapat menerbitkan pesan ke Event Grid.
  2. Event Grid memeriksa otorisasi untuk Layanan aplikasi Pendamping untuk menentukan apakah dapat mengirim pesan ke topik yang disediakan.
  3. Aplikasi pendamping berlangganan respons dari kombinasi kendaraan / perintah tertentu.

Ketika perintah yang bergantung pada status kendaraan memerlukan persetujuan pengguna (B):

  1. Pemilik/pengguna kendaraan memberikan persetujuan untuk eksekusi fungsi perintah dan kontrol ke layanan digital (dalam contoh ini aplikasi pendamping). Biasanya dilakukan ketika pengguna mengunduh/mengaktifkan aplikasi dan OEM mengaktifkan akun mereka. Ini memicu perubahan konfigurasi pada kendaraan untuk berlangganan topik perintah terkait di broker MQTT.
  2. Aplikasi pendamping menggunakan perintah dan mengontrol API terkelola untuk meminta eksekusi perintah jarak jauh.
    1. Eksekusi perintah mungkin memiliki lebih banyak parameter untuk mengonfigurasi opsi seperti waktu habis, opsi penyimpanan dan penerusan, dll.
    2. Logika perintah memutuskan cara memproses perintah berdasarkan topik dan properti lainnya.
    3. Logika alur kerja membuat status untuk melacak status eksekusi
  3. Logika alur kerja perintah memeriksa informasi persetujuan pengguna untuk menentukan apakah pesan dapat dijalankan.
  4. Logika alur kerja perintah menerbitkan pesan ke Event Grid dengan perintah dan nilai parameter.
  5. Modul olahpesan di kendaraan berlangganan topik perintah dan menerima pemberitahuan. Ini merutekan perintah ke beban kerja yang tepat.
  6. Modul olahpesan memantau beban kerja untuk penyelesaian (atau kesalahan). Beban kerja bertanggung jawab atas eksekusi (fisik) perintah.
  7. Modul olahpesan menerbitkan laporan status perintah ke Event Grid.
  8. Modul alur kerja berlangganan pembaruan status perintah dan memperbarui status internal eksekusi perintah.
  9. Setelah eksekusi perintah selesai, aplikasi layanan menerima hasil eksekusi melalui API perintah dan kontrol.

Penyediaan Kendaraan dan Perangkat

Aliran data ini mencakup proses untuk mendaftarkan dan memprovisikan kendaraan dan perangkat ke layanan olahpesan kendaraan. Proses ini biasanya dimulai sebagai bagian dari manufaktur kendaraan.

Diagram aliran data provisi.

  1. Sistem Pabrik menugaskan perangkat kendaraan ke status konstruksi yang diinginkan. Ini dapat mencakup penginstalan dan konfigurasi awal firmware & perangkat lunak. Sebagai bagian dari proses ini, sistem pabrik akan mendapatkan dan menulis sertifikat perangkat, yang dibuat dari penyedia Infrastruktur Kunci Umum.
  2. Sistem Pabrik mendaftarkan kendaraan &perangkat menggunakan VEHICLE &Device Provisioning API.
  3. Sistem pabrik memicu klien provisi perangkat untuk terhubung ke pendaftaran perangkat dan menyediakan perangkat. Perangkat mengambil informasi koneksi ke broker MQTT.
  4. Aplikasi pendaftaran perangkat membuat identitas perangkat dengan broker MQTT.
  5. Sistem pabrik memicu perangkat untuk membuat koneksi ke broker MQTT untuk pertama kalinya.
    1. Broker MQTT mengautentikasi perangkat menggunakan Sertifikat Akar CA dan mengekstrak informasi klien.
  6. Broker MQTT mengelola otorisasi untuk topik yang diizinkan menggunakan registri lokal.
  7. Untuk penggantian bagian, Sistem Dealer OEM dapat memicu pendaftaran perangkat baru.

Catatan

Sistem pabrik biasanya lokal dan tidak memiliki koneksi langsung ke cloud.

Analitik Data

Aliran data ini mencakup analitik untuk data kendaraan. Anda dapat menggunakan sumber data lain seperti pabrik atau operator lokakarya untuk memperkaya dan memberikan konteks data kendaraan.

Diagram analitik data.

  1. Lapisan layanan olahpesan kendaraan menyediakan telemetri, peristiwa, perintah, dan pesan konfigurasi dari komunikasi dua arah ke kendaraan.
  2. Lapisan IT & Operations menyediakan informasi tentang perangkat lunak yang berjalan pada kendaraan dan layanan cloud terkait.
  3. Beberapa alur menyediakan pemrosesan data ke dalam status yang lebih halus
    • Pemrosesan dari data mentah ke data kendaraan yang diperkaya dan dideduplikasi.
    • Agregasi Data Kendaraan, indikator dan wawasan performa utama.
    • Pembuatan data pelatihan untuk pembelajaran mesin.
  4. Aplikasi yang berbeda mengonsumsi data yang disempurnakan dan diagregasi.
    • Visualisasi menggunakan Power BI.
    • Alur kerja Integrasi Bisnis menggunakan Logic Apps dengan integrasi ke dalam Dataverse.
  5. Data Pelatihan yang Dihasilkan digunakan oleh alat seperti ML Studio untuk menghasilkan model ML.

Skalabilitas

Solusi kendaraan dan data yang terhubung dapat diskalakan ke jutaan kendaraan dan ribuan layanan. Disarankan untuk menggunakan pola Stempel Penyebaran untuk mencapai skalabilitas dan elastisitas.

Diagram konsep skalabilitas.

Setiap unit skala olahpesan kendaraan mendukung populasi kendaraan yang ditentukan (misalnya, kendaraan di wilayah geografis tertentu, dipartisi berdasarkan tahun model). Unit skala aplikasi digunakan untuk menskalakan layanan yang memerlukan pengiriman atau penerimaan pesan ke kendaraan. Layanan umum dapat diakses dari unit skala apa pun dan menyediakan layanan manajemen perangkat dan langganan untuk aplikasi dan perangkat.

  1. Unit skala aplikasi berlangganan aplikasi untuk pesan yang menarik. Layanan umum menangani langganan komponen unit skala olahpesan kendaraan.
  2. Kendaraan ini menggunakan layanan manajemen perangkat untuk menemukan penugasannya ke unit skala olahpesan kendaraan.
  3. Jika perlu, kendaraan disediakan menggunakan alur kerja Penyediaan Kendaraan dan perangkat.
  4. Kendaraan menerbitkan pesan ke broker MQTT.
  5. Event Grid merutekan pesan menggunakan informasi langganan.
    1. Untuk pesan yang tidak memerlukan pemeriksaan pemrosesan dan klaim, pesan dirutekan ke hub ingress pada unit skala aplikasi yang sesuai.
    2. Pesan yang memerlukan pemrosesan dirutekan ke logika pemrosesan D2C untuk dekode dan otorisasi (persetujuan pengguna).
  6. Aplikasi mengonsumsi peristiwa dari instans hub peristiwa ingress aplikasi mereka.
  7. Aplikasi menerbitkan pesan untuk kendaraan.
    1. Pesan yang tidak memerlukan lebih banyak pemrosesan diterbitkan ke broker MQTT.
    2. Pesan yang memerlukan lebih banyak pemrosesan, kontrol alur kerja, dan otorisasi dirutekan ke Logika Pemrosesan C2D yang relevan melalui instans Azure Event Hubs.

Komponen

Arsitektur referensi ini mereferensikan komponen Azure berikut.

Konektivitas

  • Azure Event Grid memungkinkan onboarding perangkat, AuthN/Z, dan pub-sub melalui MQTT v5.
  • Azure Functions memproses pesan kendaraan. Ini juga dapat digunakan untuk menerapkan API manajemen yang memerlukan eksekusi berumur pendek.
  • Azure Kubernetes Service (AKS) adalah alternatif ketika fungsionalitas di balik API Terkelola terdiri dari beban kerja kompleks yang disebarkan sebagai aplikasi kontainer.
  • Azure Cosmos DB menyimpan pengaturan persetujuan kendaraan, perangkat, dan pengguna.
  • Azure API Management menyediakan gateway API terkelola ke layanan back-end yang ada seperti manajemen siklus hidup kendaraan (termasuk OTA) dan manajemen persetujuan pengguna.
  • Azure Batch menjalankan tugas intensif komputasi besar secara efisien, seperti penyerapan jejak komunikasi kendaraan.

Data dan Analitik

  • Azure Event Hubs memungkinkan pemrosesan dan penyerapan data telemetri dalam jumlah besar.
  • Azure Data Explorer menyediakan eksplorasi, kurasi, dan analitik data telemetri kendaraan berbasis rangkaian waktu.
  • Azure Blob Storage menyimpan dokumen besar (seperti video dan dapat melacak) dan data kendaraan yang dikumpulkan.
  • Azure Databricks menyediakan serangkaian alat untuk mempertahankan solusi data tingkat perusahaan dalam skala besar. Diperlukan untuk operasi jangka panjang pada data kendaraan dalam jumlah besar.

Integrasi Backend

  • Azure Logic Apps menjalankan alur kerja otomatis untuk integrasi bisnis berdasarkan data kendaraan.
  • Azure App Service menyediakan aplikasi web dan back end seluler yang menghadap pengguna, seperti aplikasi pendamping.
  • Azure Cache for Redis menyediakan penembolokan data dalam memori yang sering digunakan oleh aplikasi yang menghadap pengguna.
  • Azure Bus Layanan menyediakan broker yang memisahkan konektivitas kendaraan dari layanan digital dan integrasi bisnis.

Alternatif

Pemilihan jenis komputasi yang tepat untuk menerapkan pemrosesan pesan dan API terkelola tergantung pada banyak faktor. Pilih layanan yang tepat menggunakan panduan Pilih layanan komputasi Azure.

Contoh:

  • Azure Functions untuk proses berumur pendek berbasis peristiwa seperti penyerapan telemetri.
  • Azure Batch untuk tugas Komputasi Berkinerja Tinggi seperti mendekode Pelacakan CAN / File Video besar
  • Azure Kubernetes Service untuk orkestrasi logika kompleks terkelola dan lengkap seperti manajemen alur kerja perintah & kontrol.

Sebagai alternatif untuk berbagi data berbasis peristiwa, Anda juga dapat menggunakan Azure Data Share jika tujuannya adalah untuk melakukan sinkronisasi batch di tingkat data lake.

Detail skenario

Diagram tampilan tingkat tinggi.

OEM otomotif mengalami transformasi yang signifikan saat mereka beralih dari memproduksi produk tetap ke menawarkan kendaraan yang terhubung dan ditentukan perangkat lunak. Kendaraan menawarkan berbagai fitur, seperti pembaruan over-the-air, diagnostik jarak jauh, dan pengalaman pengguna yang dipersonalisasi. Transisi ini memungkinkan OEM untuk terus meningkatkan produk mereka berdasarkan data dan wawasan real time sambil juga memperluas model bisnis mereka untuk menyertakan layanan baru dan aliran pendapatan.

Arsitektur referensi ini memungkinkan produsen otomotif dan penyedia mobilitas untuk:

  • Gunakan data umpan balik sebagai bagian dari proses rekayasa digital untuk mendorong peningkatan produk berkelanjutan, secara proaktif mengatasi akar penyebab masalah dan menciptakan nilai pelanggan baru.
  • Menyediakan produk dan layanan digital baru dan digitalisasi operasi dengan integrasi bisnis dengan sistem back-end seperti Enterprise Resource Planning (ERP) dan Customer Relationship Management (CRM).
  • Bagikan data dengan aman dan memenuhi persyaratan khusus negara/wilayah untuk persetujuan pengguna dengan ekosistem Mobilitas cerdas yang lebih luas.
  • Integrasikan dengan sistem back-end untuk manajemen siklus hidup kendaraan dan manajemen persetujuan menyederhanakan dan mempercepat penyebaran dan manajemen solusi kendaraan yang terhubung menggunakan Toolchain DevOps Kendaraan yang Ditentukan Perangkat Lunak.
  • Simpan dan berikan komputasi dalam skala besar untuk kendaraan dan analitik.
  • Mengelola konektivitas kendaraan ke jutaan perangkat dengan cara yang hemat biaya.

Kemungkinan kasus penggunaan

Kasus penggunaan OEM Automotive adalah tentang meningkatkan performa kendaraan, keamanan, dan pengalaman pengguna.

  • Peningkatan produk berkelanjutan: Meningkatkan performa kendaraan dengan menganalisis data real-time dan menerapkan pembaruan dari jarak jauh.
  • Validasi Armada Uji Rekayasa: Memastikan keamanan dan keandalan kendaraan dengan mengumpulkan dan menganalisis data dari armada pengujian.
  • Aplikasi Pendamping & Portal Pengguna: Mengaktifkan akses dan kontrol kendaraan jarak jauh melalui aplikasi dan portal web yang dipersonalisasi.
  • Perbaikan & Pemeliharaan Proaktif: Memprediksi dan menjadwalkan pemeliharaan kendaraan berdasarkan wawasan berbasis data.

Kasus penggunaan ekosistem yang lebih luas memperluas aplikasi kendaraan yang terhubung untuk meningkatkan operasi armada, asuransi, pemasaran, dan bantuan pinggir jalan di seluruh lanskap transportasi.

  • Koneksi operasi armada komersial: Mengoptimalkan manajemen armada melalui pemantauan real time dan pengambilan keputusan berbasis data.
  • Asuransi Kendaraan Digital: Menyesuaikan premi asuransi berdasarkan perilaku mengemudi dan memberikan pelaporan kecelakaan segera.
  • Pemasaran Berbasis Lokasi: Memberikan kampanye pemasaran yang ditargetkan kepada pengemudi berdasarkan lokasi dan preferensi mereka.
  • Bantuan Jalan: Memberikan dukungan dan bantuan real-time kepada pengemudi yang membutuhkan, menggunakan lokasi kendaraan dan data diagnostik.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Keandalan

Keandalan memastikan aplikasi Anda dapat mencapai komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keandalan.

  • Pertimbangkan penskalaan horizontal untuk menambahkan keandalan.
  • Gunakan unit skala untuk mengisolasi wilayah geografis dengan peraturan yang berbeda.
  • Menskalakan otomatis dan instans yang dipesan: mengelola sumber daya komputasi dengan penskalaan dinamis berdasarkan permintaan dan mengoptimalkan biaya dengan instans yang telah dialokasikan sebelumnya.
  • Redundansi geografis: mereplikasi data di beberapa lokasi geografis untuk toleransi kesalahan dan pemulihan bencana.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.

  • Mengamankan koneksi kendaraan: Lihat bagian tentang manajemen sertifikat untuk memahami cara menggunakan sertifikat X.509 untuk membangun komunikasi kendaraan yang aman.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

  • Pertimbangan biaya per kendaraan: biaya komunikasi harus tergantung pada jumlah layanan digital yang ditawarkan. Hitung RoI layanan digital terhadap biaya operasi.
  • Menetapkan praktik untuk analisis biaya berdasarkan lalu lintas pesan. Koneksi lalu lintas kendaraan cenderung meningkat seiring dengan semakin banyaknya layanan yang ditambahkan.
  • Pertimbangkan biaya jaringan & seluler
    • Gunakan alias topik MQTT untuk mengurangi volume lalu lintas.
    • Gunakan metode yang efisien untuk mengodekan dan mengompresi pesan payload.
  • Penanganan lalu lintas
    • Prioritas pesan: kendaraan cenderung memiliki pola penggunaan berulang yang menciptakan puncak permintaan harian / mingguan. Gunakan properti pesan untuk menunda pemrosesan pesan non-kritis atau analitik untuk menghaluskan beban dan mengoptimalkan penggunaan sumber daya.
    • Skala otomatis berdasarkan permintaan.
  • Pertimbangkan berapa lama data harus disimpan panas/hangat/dingin.
  • Pertimbangkan penggunaan instans cadangan untuk mengoptimalkan biaya.

Keunggulan operasional

Keunggulan operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Gambaran umum pilar keunggulan operasional.

  • Pertimbangkan untuk memantau perangkat lunak kendaraan (log/metrik/jejak), layanan olahpesan, layanan data & analitik, dan layanan back-end terkait sebagai bagian dari operasi TI terpadu.

Efisiensi kinerja

Efisiensi performa adalah kemampuan beban kerja Anda untuk diskalakan agar memenuhi permintaan yang diberikan oleh pengguna dengan cara yang efisien. Untuk informasi selengkapnya, lihat Gambaran umum pilar efisiensi performa.

  • Pertimbangkan untuk menggunakan konsep skala untuk solusi yang menskalakan di atas 50.000 perangkat, terutama jika beberapa wilayah geografis diperlukan.
  • Pertimbangkan dengan cermat cara terbaik untuk menyerap data (olahpesan, streaming, atau batch).
  • Pertimbangkan cara terbaik untuk menganalisis data berdasarkan kasus penggunaan.

Langkah berikutnya

  • Buat solusi Autonomous Vehicle Operations (AVOps) untuk melihat lebih luas tentang rekayasa digital otomotif untuk mengemudi otonom dan terbantu.

Artikel berikut mencakup beberapa konsep yang digunakan dalam arsitektur:

  • Pola Pemeriksaan Klaim digunakan untuk mendukung pemrosesan pesan besar, seperti unggahan file.
  • Stempel Penyebaran mencakup konsep umum yang diperlukan untuk menskalakan solusi ke jutaan kendaraan.
  • Pembatasan menjelaskan konsep yang diperlukan untuk menangani jumlah pesan yang luar biasa dari kendaraan.

Artikel berikut ini menjelaskan interaksi antar komponen dalam arsitektur: