McKinsey: memikirkan kembali arsitektur perangkat lunak dan elektronik di bidang otomotif

McKinsey: memikirkan kembali arsitektur perangkat lunak dan elektronik di bidang otomotif

Ketika mobil melanjutkan transisinya dari yang digerakkan oleh perangkat keras ke yang digerakkan oleh perangkat lunak, aturan persaingan dalam industri otomotif berubah secara dramatis.

Mesin adalah inti teknologi dan teknik mobil abad ke-20. Saat ini, peran ini semakin banyak diisi oleh perangkat lunak, daya komputasi yang lebih besar, dan sensor canggih; sebagian besar inovasi melibatkan semua ini. Semuanya bergantung pada hal-hal ini, mulai dari efisiensi mobil, akses internet dan kemungkinan mengemudi secara otonom, hingga mobilitas listrik dan solusi mobilitas baru.

Namun, seiring dengan semakin pentingnya elektronik dan perangkat lunak, tingkat kerumitannya juga meningkat. Ambil contoh semakin banyaknya baris kode (SLOC) yang terdapat pada mobil modern. Pada tahun 2010, beberapa kendaraan memiliki sekitar sepuluh juta SLOC; pada tahun 2016, angka ini meningkat 15 kali lipat menjadi sekitar 150 juta baris kode. Kompleksitas seperti longsoran salju menyebabkan masalah serius pada kualitas perangkat lunak, sebagaimana dibuktikan dengan banyaknya ulasan mobil baru.

Mobil memiliki tingkat otonomi yang lebih tinggi. Oleh karena itu, orang yang bekerja di industri otomotif menganggap kualitas dan keamanan perangkat lunak dan elektronik sebagai persyaratan utama untuk menjamin keselamatan manusia. Industri otomotif perlu memikirkan kembali pendekatan modern terhadap perangkat lunak dan arsitektur kelistrikan dan elektronik.

Memecahkan masalah industri yang mendesak

Ketika industri otomotif beralih dari perangkat yang digerakkan oleh perangkat keras ke perangkat yang digerakkan oleh perangkat lunak, jumlah rata-rata perangkat lunak dan elektronik pada kendaraan meningkat pesat. Saat ini, perangkat lunak menyumbang 10% dari total konten mobil untuk segmen D atau mobil yang lebih besar (sekitar $1220). Pangsa rata-rata perangkat lunak diperkirakan akan tumbuh sebesar 11%. Diperkirakan pada tahun 2030 perangkat lunak akan menyumbang 30% dari total konten kendaraan (sekitar $5200). Tidak mengherankan jika orang-orang yang terlibat dalam beberapa tahap pengembangan mobil mencoba memanfaatkan inovasi yang dimungkinkan oleh perangkat lunak dan elektronik.

McKinsey: memikirkan kembali arsitektur perangkat lunak dan elektronik di bidang otomotif

Perusahaan software dan pemain digital lainnya pun tak mau ketinggalan. Mereka berusaha menarik produsen mobil sebagai pemasok tingkat pertama. Perusahaan memperluas partisipasi mereka dalam teknologi otomotif dengan beralih dari fitur dan aplikasi ke sistem operasi. Pada saat yang sama, perusahaan yang terbiasa bekerja dengan sistem elektronik dengan berani memasuki bidang teknologi dan aplikasi dari raksasa teknologi. Produsen mobil premium bergerak maju dan mengembangkan sistem operasi, abstraksi perangkat keras, dan pemrosesan sinyal mereka sendiri untuk menjadikan produk mereka unik.

Ada konsekuensi terhadap strategi di atas. Masa depan akan melihat arsitektur berorientasi layanan kendaraan (SOA) berdasarkan platform komputasi umum. Para pengembang akan menambahkan banyak hal baru: solusi di bidang akses Internet, aplikasi, elemen kecerdasan buatan, analitik tingkat lanjut, dan sistem operasi. Perbedaannya bukan terletak pada perangkat keras tradisional mobil, namun pada antarmuka pengguna dan cara kerjanya dengan perangkat lunak dan elektronik canggih.

Mobil-mobil masa depan akan beralih ke platform keunggulan kompetitif merek baru.

McKinsey: memikirkan kembali arsitektur perangkat lunak dan elektronik di bidang otomotif

Hal ini kemungkinan besar mencakup inovasi infotainmen, kemampuan mengemudi otonom dan fitur keselamatan cerdas berdasarkan perilaku “fail-safe” (misalnya, sistem mampu menjalankan fungsi utamanya meskipun ada bagian yang gagal). Perangkat lunak akan terus berpindah ke tumpukan digital untuk menjadi bagian dari perangkat keras dengan kedok sensor pintar. Tumpukan akan terintegrasi secara horizontal dan akan menerima lapisan baru yang akan memindahkan arsitektur ke SOA.

Tren mode mengubah aturan main. Mereka mempengaruhi perangkat lunak dan arsitektur elektronik. Tren ini mendorong kompleksitas dan saling ketergantungan teknologi. Misalnya, sensor dan aplikasi pintar baru akan dibuat "ledakan data" di dalam kendaraan. Jika perusahaan otomotif ingin tetap kompetitif, mereka perlu memproses dan menganalisis data secara efektif. Pembaruan SOA modular dan pembaruan over-the-air (OTA) akan menjadi persyaratan utama untuk mendukung perangkat lunak yang kompleks dalam armada. Mereka juga sangat penting untuk penerapan model bisnis baru yang fitur-fiturnya muncul sesuai permintaan. Akan ada peningkatan penggunaan sistem infotainment dan, meskipun pada tingkat yang lebih rendah, sistem infotainment yang lebih maju sistem bantuan pengemudi (ADAS). Pasalnya, semakin banyak pengembang aplikasi pihak ketiga yang menyediakan produk untuk kendaraan.

Karena persyaratan keamanan digital, strategi kontrol akses konvensional tidak lagi menarik. Saatnya beralih ke konsep keselamatan terpadu, dirancang untuk memprediksi, mencegah, mendeteksi, dan melindungi dari serangan dunia maya. Seiring dengan munculnya kemampuan High Automated Driving (HAD), kita memerlukan konvergensi fungsionalitas, daya komputasi yang unggul, dan integrasi tingkat tinggi.

Menjelajahi sepuluh hipotesis tentang arsitektur listrik atau elektronik masa depan

Jalur pengembangan teknologi dan model bisnisnya belum jelas. Namun berdasarkan penelitian ekstensif dan pendapat para ahli, kami telah mengembangkan sepuluh hipotesis mengenai arsitektur kendaraan listrik atau elektronik di masa depan dan implikasinya terhadap industri.

Konsolidasi unit kontrol elektronik (ECU) akan menjadi semakin umum

Daripada menggunakan beberapa ECU khusus untuk fungsi tertentu (seperti gaya “tambah fungsi, tambahkan jendela”), industri akan beralih ke arsitektur ECU kendaraan terpadu.

Pada tahap pertama, sebagian besar fungsi akan difokuskan pada pengontrol domain gabungan. Untuk domain kendaraan inti, mereka akan menggantikan sebagian fungsi yang saat ini tersedia di ECU terdistribusi. Perkembangan sudah berlangsung. Kami mengharapkan produk jadinya bisa dipasarkan dalam dua hingga tiga tahun. Konsolidasi kemungkinan besar terjadi pada tumpukan yang terkait dengan fungsi ADAS dan HAD, sementara fungsi kendaraan yang lebih mendasar mungkin mempertahankan tingkat desentralisasi yang lebih tinggi.

Kami bergerak menuju mengemudi otonom. Oleh karena itu, virtualisasi fungsi perangkat lunak dan abstraksi dari perangkat keras akan menjadi penting. Pendekatan baru ini dapat diterapkan dengan berbagai cara. Dimungkinkan untuk menggabungkan perangkat keras ke dalam tumpukan yang memenuhi persyaratan latensi dan keandalan yang berbeda. Contohnya adalah tumpukan berkinerja tinggi yang mendukung fungsionalitas HAD dan ADAS, dan tumpukan terpisah dengan latensi rendah dan berdasarkan waktu untuk fungsi keamanan inti. Atau Anda bisa mengganti ECU dengan satu “superkomputer” cadangan. Skenario lain yang mungkin terjadi adalah ketika kita sepenuhnya meninggalkan konsep unit kontrol dan memilih jaringan komputasi cerdas.

Perubahan ini terutama didorong oleh tiga faktor: biaya, pendatang baru di pasar, dan permintaan HAD. Mengurangi biaya pengembangan fitur dan perangkat keras komputasi yang diperlukan, termasuk peralatan komunikasi, akan mempercepat proses konsolidasi. Hal yang sama juga berlaku bagi pendatang baru di pasar otomotif yang kemungkinan besar akan mendisrupsi industri dengan pendekatan yang berpusat pada perangkat lunak pada arsitektur kendaraan. Meningkatnya permintaan akan fungsionalitas dan redundansi HAD juga memerlukan tingkat konsolidasi ECU yang lebih tinggi.

Beberapa produsen mobil premium dan pemasoknya sudah terlibat aktif dalam konsolidasi ECU. Mereka mengambil langkah pertama untuk memperbarui arsitektur elektroniknya, meski saat ini belum ada prototipe.

Industri akan membatasi jumlah tumpukan yang digunakan untuk peralatan tertentu

Dukungan konsolidasi menormalkan batas tumpukan. Ini akan memisahkan fungsi kendaraan dan perangkat keras ECU, termasuk penggunaan virtualisasi secara aktif. Perangkat keras dan firmware (termasuk sistem operasi) akan bergantung pada persyaratan fungsional inti, bukan menjadi bagian dari domain fungsional kendaraan. Untuk memastikan pemisahan dan arsitektur berorientasi layanan, jumlah tumpukan harus dibatasi. Di bawah ini adalah tumpukan yang dapat menjadi dasar mobil generasi masa depan dalam 5-10 tahun:

  • Tumpukan berdasarkan waktu. Dalam domain ini, pengontrol terhubung langsung ke sensor atau aktuator, sementara sistem harus mendukung persyaratan real-time yang ketat dengan tetap mempertahankan latensi rendah; penjadwalan sumber daya didasarkan pada waktu. Tumpukan ini mencakup sistem yang mencapai tingkat keamanan kendaraan tertinggi. Contohnya adalah domain klasik Automotive Open Systems Architecture (AUTOSAR).
  • Tumpukan berdasarkan waktu dan peristiwa. Tumpukan hibrid ini menggabungkan aplikasi keamanan berkinerja tinggi dengan dukungan untuk ADAS dan HAD, misalnya. Aplikasi dan periferal dipisahkan oleh sistem operasi, sedangkan aplikasi dijadwalkan berdasarkan waktu. Dalam suatu aplikasi, penjadwalan sumber daya dapat didasarkan pada waktu atau prioritas. Lingkungan pengoperasian memastikan bahwa aplikasi-aplikasi penting berjalan dalam wadah yang terisolasi, dengan jelas memisahkan aplikasi-aplikasi ini dari aplikasi lain di dalam kendaraan. Contoh yang bagus adalah AUTOSAR adaptif.
  • Tumpukan yang didorong oleh peristiwa. Tumpukan ini berfokus pada sistem infotainment, yang tidak terlalu penting bagi keselamatan. Aplikasi secara jelas dipisahkan dari periferal, dan sumber daya dijadwalkan menggunakan penjadwalan optimal atau berbasis peristiwa. Tumpukan berisi fungsi yang terlihat dan sering digunakan: Android, Automotive Grade Linux, GENIVI, dan QNX. Fitur-fitur ini memungkinkan pengguna untuk berinteraksi dengan kendaraan.
  • Tumpukan awan. Tumpukan terakhir mencakup akses data dan mengoordinasikannya serta fungsi kendaraan secara eksternal. Tumpukan ini bertanggung jawab untuk komunikasi, serta verifikasi keamanan aplikasi (otentikasi) dan menetapkan antarmuka otomotif tertentu, termasuk diagnostik jarak jauh.

Pemasok otomotif dan produsen teknologi sudah mulai mengkhususkan diri pada beberapa produk ini. Contoh utama adalah sistem infotainment (event-driven stack), di mana perusahaan mengembangkan kemampuan komunikasi - 3D dan navigasi tingkat lanjut. Contoh kedua adalah kecerdasan buatan dan penginderaan untuk aplikasi berkinerja tinggi, di mana pemasok bekerja sama dengan produsen mobil utama untuk mengembangkan platform komputasi.

Dalam domain berbasis waktu, AUTOSAR dan JASPAR mendukung standarisasi tumpukan ini.

Middleware akan mengabstraksi aplikasi dari perangkat keras

Ketika kendaraan terus berevolusi menuju platform komputasi seluler, middleware akan memungkinkan kendaraan dikonfigurasi ulang dan perangkat lunaknya diinstal serta diperbarui. Saat ini, middleware di setiap ECU memfasilitasi komunikasi antar perangkat. Pada kendaraan generasi berikutnya, ini akan menghubungkan pengontrol domain ke fungsi akses. Menggunakan perangkat keras ECU di mobil, middleware akan menyediakan abstraksi, virtualisasi, SOA, dan komputasi terdistribusi.

Sudah ada bukti bahwa industri otomotif beralih ke arsitektur yang lebih fleksibel, termasuk middleware. Misalnya, platform adaptif AUTOSAR adalah sistem dinamis yang mencakup middleware, dukungan sistem operasi kompleks, dan mikroprosesor multi-core modern. Namun pengembangan yang tersedia saat ini terbatas hanya pada satu ECU saja.

Dalam jangka menengah, jumlah sensor onboard akan meningkat secara signifikan

Dalam dua hingga tiga generasi kendaraan berikutnya, pembuat mobil akan memasang sensor dengan fungsi serupa untuk memastikan cadangan terkait keselamatan mencukupi.

McKinsey: memikirkan kembali arsitektur perangkat lunak dan elektronik di bidang otomotif

Dalam jangka panjang, industri otomotif akan mengembangkan solusi sensor khusus untuk mengurangi jumlah dan biaya. Kami percaya bahwa menggabungkan radar dan kamera mungkin menjadi solusi paling populer dalam lima hingga delapan tahun ke depan. Ketika kemampuan mengemudi otonom terus berkembang, pengenalan lidar akan diperlukan. Mereka akan memberikan redundansi baik di bidang analisis objek maupun di bidang lokalisasi. Misalnya, konfigurasi mengemudi otonom SAE International L4 (otomatisasi tinggi) pada awalnya kemungkinan memerlukan empat hingga lima sensor lidar, termasuk yang dipasang di belakang untuk navigasi kota dan visibilitas hampir 360 derajat.

Sulit untuk mengatakan apa pun tentang jumlah sensor pada kendaraan dalam jangka panjang. Entah jumlahnya akan bertambah, berkurang, atau tetap sama. Itu semua tergantung pada peraturan, kematangan teknis solusi, dan kemampuan untuk menggunakan banyak sensor dalam berbagai kasus. Persyaratan peraturan dapat, misalnya, meningkatkan pemantauan pengemudi, sehingga menghasilkan lebih banyak sensor di dalam kendaraan. Kita berharap untuk melihat lebih banyak sensor elektronik konsumen digunakan di interior kendaraan. Sensor gerak, pemantauan kesehatan (detak jantung dan kantuk), pengenalan wajah dan iris mata hanyalah beberapa kemungkinan penggunaan. Namun, untuk menambah jumlah sensor atau bahkan menjaga agar tetap sama, diperlukan bahan yang lebih beragam, tidak hanya pada sensor itu sendiri, tetapi juga pada jaringan kendaraan. Oleh karena itu, mengurangi jumlah sensor jauh lebih menguntungkan. Dengan munculnya kendaraan yang sangat otomatis atau sepenuhnya otomatis, algoritme dan pembelajaran mesin yang canggih dapat meningkatkan kinerja dan keandalan sensor. Berkat teknologi sensor yang lebih kuat dan mumpuni, sensor yang tidak diperlukan mungkin tidak lagi diperlukan. Sensor yang digunakan saat ini mungkin menjadi usang - sensor yang lebih fungsional akan muncul (misalnya, sensor ultrasonik mungkin muncul alih-alih asisten parkir berbasis kamera atau lidar).

Sensor akan menjadi lebih pintar

Arsitektur sistem memerlukan sensor yang cerdas dan terintegrasi untuk mengelola sejumlah besar data yang diperlukan untuk pengendaraan yang sangat otomatis. Fungsi tingkat tinggi seperti fusi sensor dan penentuan posisi XNUMXD akan dijalankan pada platform komputasi terpusat. Loop pra-pemrosesan, pemfilteran, dan respons cepat kemungkinan besar akan ditempatkan di tepi atau dilakukan di dalam sensor itu sendiri. Sebuah perkiraan menyebutkan jumlah data yang dihasilkan mobil otonom setiap jam adalah empat terabyte. Oleh karena itu, AI akan berpindah dari ECU ke sensor untuk melakukan pra-pemrosesan dasar. Hal ini memerlukan latensi rendah dan performa komputasi yang rendah, terutama jika Anda membandingkan biaya pemrosesan data di sensor dan biaya transmisi data dalam jumlah besar di dalam kendaraan. Namun, redundansi keputusan jalan raya di HAD memerlukan konvergensi untuk komputasi terpusat. Kemungkinan besar, penghitungan ini akan dihitung berdasarkan data yang telah diproses sebelumnya. Sensor pintar akan memantau fungsinya sendiri, sementara redundansi sensor akan meningkatkan keandalan, ketersediaan, dan keamanan jaringan sensor. Untuk memastikan kinerja sensor yang tepat di segala kondisi, aplikasi pembersihan sensor seperti deicer dan penghilang debu dan kotoran akan diperlukan.

Diperlukan kekuatan penuh dan jaringan data redundan

Aplikasi penting dan keselamatan penting yang memerlukan keandalan tinggi akan menggunakan siklus redundan sepenuhnya untuk semua yang diperlukan untuk manuver yang aman (komunikasi data, daya). Pengenalan teknologi kendaraan listrik, komputer pusat dan jaringan komputasi terdistribusi yang haus daya akan memerlukan jaringan manajemen daya redundan baru. Sistem toleransi kesalahan yang mendukung kontrol kabel dan fungsi HAD lainnya akan memerlukan pengembangan sistem redundan. Hal ini secara signifikan akan meningkatkan arsitektur implementasi pemantauan toleransi kesalahan modern.

"Automotive Ethernet" akan menjadi tulang punggung mobil

Jaringan otomotif saat ini tidak cukup untuk memenuhi kebutuhan transportasi masa depan. Peningkatan kecepatan data, persyaratan redundansi untuk HAD, kebutuhan akan keamanan dan perlindungan di lingkungan yang terhubung, dan kebutuhan akan protokol standar lintas industri kemungkinan besar akan mengarah pada munculnya Ethernet otomotif. Ini akan menjadi penggerak utama, terutama untuk bus data pusat yang redundant. Solusi Ethernet akan diperlukan untuk menyediakan komunikasi yang andal antar domain dan memenuhi permintaan real-time. Hal ini dimungkinkan berkat penambahan ekstensi Ethernet seperti Audio Video Bridging (AVB) dan jaringan sensitif waktu (TSN). Perwakilan industri dan OPEN Alliance mendukung penerapan teknologi Ethernet. Banyak produsen mobil telah mengambil langkah besar ini.

Jaringan tradisional seperti jaringan interkoneksi lokal dan jaringan pengontrol akan terus digunakan di dalam kendaraan, tetapi hanya untuk jaringan tertutup tingkat rendah seperti sensor. Teknologi seperti FlexRay dan MOST kemungkinan besar akan digantikan oleh Ethernet otomotif dan ekstensinya AVB dan TSN.

Di masa depan, kami berharap industri otomotif juga akan menggunakan teknologi Ethernet lainnya - HDBP (produk bandwidth penundaan tinggi) dan teknologi 10-Gigabit.

OEM akan selalu memiliki kontrol ketat atas konektivitas data untuk memastikan keamanan fungsional dan HAD, namun mereka akan membuka antarmuka untuk memungkinkan pihak ketiga mengakses data

Gerbang komunikasi pusat yang mengirim dan menerima data penting keamanan akan selalu terhubung langsung ke backend OEM. Akses terhadap data akan terbuka untuk pihak ketiga apabila hal tersebut tidak dilarang oleh aturan. Infotainment merupakan “keterikatan” pada kendaraan. Di bidang ini, munculnya antarmuka terbuka akan memungkinkan penyedia konten dan aplikasi untuk menyebarkan produk mereka sementara OEM mematuhi standar sebaik mungkin.

Port diagnostik on-board saat ini akan digantikan oleh solusi telematika yang terhubung. Akses pemeliharaan untuk jaringan kendaraan tidak lagi diperlukan, namun akan dapat dialirkan melalui backend OEM. OEM akan menyediakan port data di bagian belakang kendaraan untuk kasus penggunaan tertentu (pelacakan kendaraan yang dicuri atau asuransi pribadi). Namun, perangkat purnajual akan memiliki akses yang semakin sedikit ke jaringan data internal.

Operator armada besar akan memainkan peran lebih besar dalam pengalaman pengguna dan menciptakan nilai bagi pelanggan akhir. Mereka akan dapat menawarkan kendaraan berbeda untuk tujuan berbeda dalam langganan yang sama (misalnya, untuk perjalanan sehari-hari atau liburan akhir pekan). Mereka akan diminta untuk menggunakan beberapa backend OEM dan mengkonsolidasikan data di seluruh armada mereka. Basis data yang besar kemudian akan memungkinkan operator armada untuk memonetisasi data konsolidasi dan analisis yang tidak tersedia di tingkat OEM.

Mobil akan menggunakan layanan cloud untuk menggabungkan informasi di dalam pesawat dengan data eksternal

Data “non-sensitif” (yaitu, data yang tidak terkait dengan identitas atau keamanan) akan semakin banyak diproses di cloud untuk mendapatkan informasi tambahan. Ketersediaan data ini di luar OEM akan bergantung pada undang-undang dan peraturan di masa mendatang. Seiring bertambahnya volume tidak mungkin dilakukan tanpa analisis data. Analytics diperlukan untuk memproses informasi dan mengekstrak data penting. Kami berkomitmen terhadap kendaraan otonom dan inovasi digital lainnya. Penggunaan data yang efektif akan bergantung pada pembagian data antara beberapa pelaku pasar. Masih belum jelas siapa yang akan melakukan ini dan bagaimana caranya. Namun, pemasok otomotif besar dan perusahaan teknologi telah membangun platform otomotif terintegrasi yang dapat menangani banyaknya data baru ini.

Komponen yang dapat diupgrade akan muncul di mobil yang mendukung komunikasi dua arah

Sistem pengujian di dalam pesawat akan memungkinkan kendaraan memeriksa pembaruan secara otomatis. Kita akan mampu mengatur siklus hidup kendaraan dan fungsinya. Semua ECU akan mengirim dan menerima data dari sensor dan aktuator, mengambil data. Data ini akan digunakan untuk mengembangkan inovasi. Contohnya adalah membangun rute berdasarkan parameter kendaraan.

Kemampuan update OTA adalah suatu keharusan bagi HAD. Dengan teknologi ini, kita akan memiliki fitur-fitur baru, keamanan siber, dan penerapan fitur dan perangkat lunak yang lebih cepat. Faktanya, kemampuan pembaruan OTA adalah kekuatan pendorong di balik banyak perubahan penting yang dijelaskan di atas. Selain itu, kemampuan ini juga memerlukan solusi keamanan komprehensif di semua tingkat tumpukan—baik di luar kendaraan maupun di dalam ECU. Solusi ini masih perlu dikembangkan. Akan menarik untuk melihat siapa yang akan melakukannya dan bagaimana caranya.

Apakah update mobil bisa diinstall seperti di smartphone? Industri ini perlu mengatasi keterbatasan dalam kontrak pemasok, persyaratan peraturan, serta masalah keamanan dan privasi. Banyak produsen mobil telah mengumumkan rencana untuk meluncurkan penawaran layanan OTA, termasuk pembaruan over-the-air untuk kendaraan mereka.

OEM akan melakukan standarisasi armada mereka pada platform OTA, bekerja sama dengan penyedia teknologi di bidang ini. Konektivitas dalam kendaraan dan platform OTA akan segera menjadi sangat penting. OEM memahami hal ini dan ingin mendapatkan lebih banyak kepemilikan di segmen pasar ini.

Kendaraan akan menerima pembaruan perangkat lunak, fitur dan keamanan untuk masa pakai desainnya. Otoritas pengatur kemungkinan akan menyediakan pemeliharaan perangkat lunak untuk memastikan integritas desain kendaraan. Kebutuhan untuk memperbarui dan memelihara perangkat lunak akan mengarah pada model bisnis baru untuk pemeliharaan dan pengoperasian kendaraan.

Menilai Dampak Masa Depan Perangkat Lunak Otomotif dan Arsitektur Elektronik

Tren yang berdampak pada industri otomotif menciptakan ketidakpastian terkait perangkat keras. Namun, masa depan perangkat lunak dan arsitektur elektronik tampak menjanjikan. Semua kemungkinan terbuka bagi industri: pembuat mobil dapat membentuk asosiasi industri untuk menstandardisasi arsitektur kendaraan, raksasa digital dapat menerapkan platform cloud on-board, pemain mobilitas dapat memproduksi kendaraan mereka sendiri atau mengembangkan tumpukan kendaraan dengan kode sumber terbuka dan fitur perangkat lunak, pembuat mobil dapat memperkenalkan mobil otonom yang semakin canggih dengan konektivitas Internet.

Produk tidak lagi berpusat pada perangkat keras. Mereka akan berorientasi pada perangkat lunak. Transisi ini akan sulit bagi perusahaan mobil yang terbiasa memproduksi mobil tradisional. Namun, mengingat tren dan perubahan yang dijelaskan, bahkan perusahaan kecil pun tidak punya pilihan. Mereka harus bersiap.

Kami melihat beberapa langkah strategis utama:

  • Pisahkan siklus pengembangan kendaraan dan fungsi kendaraan. OEM dan pemasok Tingkat XNUMX harus memutuskan bagaimana mereka akan mengembangkan, menawarkan, dan menerapkan fitur. Mereka harus independen terhadap siklus pengembangan kendaraan, baik dari sudut pandang teknis maupun organisasi. Mengingat siklus pengembangan kendaraan saat ini, perusahaan perlu menemukan cara untuk mengelola inovasi perangkat lunak. Selain itu, mereka harus mempertimbangkan opsi untuk peningkatan dan peningkatan (seperti unit komputasi) untuk armada yang ada.
  • Tentukan target nilai tambah untuk pengembangan perangkat lunak dan elektronik. OEM harus mengidentifikasi fitur-fitur pembeda yang dapat mereka tetapkan tolok ukurnya. Selain itu, penting untuk mendefinisikan dengan jelas target nilai tambah untuk pengembangan perangkat lunak dan elektronik mereka sendiri. Anda juga harus mengidentifikasi area dimana produk akan dibutuhkan dan topik yang hanya boleh didiskusikan dengan pemasok atau mitra.
  • Tetapkan harga eksplisit untuk perangkat lunak. Untuk memisahkan perangkat lunak dari perangkat keras, OEM perlu memikirkan kembali proses dan mekanisme internal untuk membeli perangkat lunak secara langsung. Selain penyesuaian tradisional, penting juga untuk menganalisis bagaimana pendekatan tangkas dalam pengembangan perangkat lunak dapat dikaitkan dengan proses pengadaan. Di sinilah vendor (tingkat satu, tingkat dua, dan tingkat tiga) juga memainkan peran penting karena mereka perlu memberikan nilai bisnis yang jelas pada penawaran perangkat lunak dan sistem mereka sehingga mereka dapat memperoleh bagian pendapatan yang lebih besar.
  • Kembangkan diagram organisasi khusus untuk arsitektur elektronik baru (termasuk backend). Industri otomotif perlu mengubah proses internal untuk mengirimkan dan menjual perangkat elektronik dan perangkat lunak canggih. Mereka juga perlu mempertimbangkan pengaturan organisasi yang berbeda untuk topik elektronik terkait kendaraan. Pada dasarnya, arsitektur "berlapis" yang baru memerlukan potensi gangguan terhadap pengaturan "vertikal" saat ini dan pengenalan unit organisasi "horizontal" baru. Selain itu, terdapat kebutuhan untuk memperluas kemampuan dan keterampilan pengembang perangkat lunak dan elektronik dalam tim.
  • Mengembangkan model bisnis komponen kendaraan individu sebagai suatu produk (khususnya untuk pemasok). Penting untuk menganalisis fitur mana yang memberikan nilai tambah nyata pada arsitektur masa depan dan oleh karena itu dapat dimonetisasi. Hal ini akan membantu Anda tetap kompetitif dan mendapatkan pangsa pasar yang signifikan dalam industri elektronik otomotif. Selanjutnya, model bisnis baru perlu ditemukan untuk menjual perangkat lunak dan sistem elektronik, baik itu produk, layanan, atau sesuatu yang benar-benar baru.

Ketika era baru perangkat lunak dan elektronik otomotif dimulai, hal ini secara mendasar mengubah segalanya tentang model bisnis, kebutuhan pelanggan, dan sifat persaingan. Kami yakin akan ada banyak uang yang bisa dihasilkan dari ini. Namun untuk memanfaatkan perubahan yang akan terjadi, semua orang di industri ini harus memikirkan kembali pendekatan mereka terhadap manufaktur mobil dan menetapkan (atau mengubah) penawaran mereka dengan bijak.

Artikel ini dikembangkan bekerja sama dengan Global Semiconductor Alliance.

Sumber: www.habr.com

Tambah komentar