Apakah Kendaraan Kini Didefinisikan oleh Perangkat Lunak? Arsitektur Domain dan Transformasi SDV

Bagikan Halaman Ini
Ya: perilaku, fitur, dan karakter performans mobil modern kini terutama ditentukan oleh perangkat lunak. Transformasi ini yang disebut kendaraan berbasis perangkat lunak (SDV) memindahkan arsitektur elektronik kendaraan dari tumpukan ECU ke pengendali domain dan zonal, memisahkan perangkat keras dari perangkat lunak, dan membentuk ulang segalanya mulai dari bobot kabel hingga pembaruan OTA.
Sorotan
- Kendaraan saat ini bisa memiliki 100 atau lebih unit kendali; arsitektur baru menargetkan pengurangan angka itu hingga 20%.
- Arsitektur domain mengorganisasi berdasarkan fungsi, arsitektur zonal berdasarkan lokasi fisik.
- Pada topologi zonal, tulang punggung berb lebar digunakan seperti CAN XL (hingga 20 Mbps) dan Ethernet gigabit.
- Pembaruan OTA adalah kemampuan dasar SDV yang dimungkinkan berkat pemisahan perangkat keras dan perangkat lunak.
- Transisinya bertahap: area pertama adalah domain bodi (body); ADAS, powertrain, dan sasis bisa lebih lama tetap pada struktur yang ada.
Apa Sebenarnya Kendaraan Berbasis Perangkat Lunak Itu?
Definisinya jelas: kendaraan berbasis perangkat lunak adalah kendaraan yang fungsionalitas dan perilakunya terutama ditentukan oleh perangkat lunak, bukan perangkat keras. Pada mobil tradisional, sebuah fitur ditentukan oleh komponen perangkat keras yang diproduksi khusus untuk fungsi tersebut; pada SDV, perangkat keras yang sama dapat mengambil fungsi berbeda melalui perangkat lunak yang berjalan di atasnya. Bahkan setelah kendaraan terjual, fitur baru bisa ditambahkan, perilaku bisa dikalibrasi, dan kesalahan bisa diperbaiki dari jarak jauh.
Arsitektur E/E saat ini tersusun dari 100 atau lebih unit kendali; struktur generasi baru menghemat hingga 20% pada jumlah unit kendali dan hingga 10% pada material serta perangkat keras.
Angka-angka dalam kalimat ini merangkum skala transformasinya. Masalahnya bukan hanya jumlah unit kendali: setiap ECU membawa kabelnya sendiri, tumpukan perangkat lunaknya sendiri, dan beban validasinya sendiri. Visi SDV adalah mengubah struktur tersebar ini menjadi sistem yang dapat dikelola perangkat lunak sebagai satu lapisan yang konsisten. Untuk itu, arsitektur elektronik perlu dirancang ulang dari awal.
Dari ECU ke Arsitektur Domain: Pengelompokan Berdasarkan Fungsi
Era ketika setiap fungsi kecil pada mobil memiliki unit kendali elektronik (ECU) tersendiri menjadikan kumpulan kabel tidak terkelola. Arsitektur domain menjadi jawaban sistematis pertama atas hal ini: elektronik kendaraan diorganisasi berdasarkan area fungsional besar seperti ADAS, infotainment, powertrain, elektronik bodi, sasis, dan keamanan (safety). Setiap domain umumnya memiliki prosesor, tumpukan perangkat lunak, antarmuka komunikasi, sensor, dan aktuatornya sendiri, serta dikelola oleh pengendali domain.
Struktur ini memberikan penyederhanaan signifikan dibandingkan kekacauan ECU. Namun seiring membesarnya tujuan SDV, batasan arsitektur domain mulai terlihat. Terutama data sensor yang dihasilkan fungsi otonom mendorong bandwidth jaringan CAN klasik hingga batasnya. Selain itu, fakta bahwa setiap domain membawa sumber daya komputasinya sendiri membuat kabel bundel tetap rumit dan menyulitkan penskalaan perangkat lunak di seluruh kendaraan.
Arsitektur Zonal: Organisasi Bergeser dari Fungsi ke Lokasi
Arsitektur zonal membalik logika ini: mengelompokkan elektronik berdasarkan lokasi fisiknya di kendaraan, bukan berdasarkan fungsinya. Kendaraan dibagi menjadi zona seperti depan kiri, depan kanan, belakang kiri, belakang kanan, dan kabin; di setiap zona, sebuah kontroler zonal mengumpulkan sensor, aktuator, dan distribusi dayan di zona tersebut, serta berkomunikasi dengan platform komputasi berkinerja tinggi yang terpusat.
| Fitur | Arsitektur domain | Arsitektur zonal |
|---|---|---|
| Prinsip organisasi | Berdasarkan fungsi (powertrain, ADAS, bodi...) | Berdasarkan lokasi fisik (depan kiri, belakang kanan...) |
| Sumber daya komputasi | Komputasi khusus domain | Komputasi terpusat/terdistribusi yang terkonsolidasi |
| Pengkabelan | Rumit, kabel bundel yang panjang | Pengkabelan dan berat yang berkurang |
| Jumlah ECU | Banyak ECU | Sedikit kontroler zonal + komputer terpusat |
| Fleksibilitas perangkat lunak | Sulit diskalakan untuk SDV | Fleksibilitas perangkat lunak yang tinggi |
Keuntungannya nyata dan terukur: berat kabel bundel berkurang, sambungan titik-ke-titik berkurang, dan upaya validasi arsitektur kendaraan serta sistem menjadi lebih sederhana. Lebih penting lagi, desain sensor dan aktuator menjadi independen dari node komputasi terpusat; sehingga siklus pembaruan perangkat keras dan perangkat lunak terpisah, dan satu desain sensor dapat digunakan lintas beberapa generasi kendaraan.
Apa Tugas Kontroler Zonal? Pembagian Tugas dan Hubungannya dengan Perangkat Keras

Kunci arsitektur zonal adalah kontroler zonal yang bertanggung jawab menghubungkan banyak aktuator dan sensor ke ECU komputasi terpusat. Kontroler ini bukan sekadar kotak pengumpul data; ia dapat menjalankan loop kontrol waktu nyata pada dirinya sendiri, mengelola perangkat di zonanya, dan mengirimkan lalu lintas yang telah difilter dan diprioritaskan ke backbone. Menurut penilaian rekayasa dari Ti, MCU modul zonal harus menawarkan kinerja waktu nyata yang tinggi, memori yang luas, dukungan virtualisasi untuk berbagai tingkat ASIL, komunikasi berkecepatan tinggi ke backbone, serta banyak antarmuka ujung berbiaya rendah seperti CAN FD dan LIN.
Bagaimana distribusi dayan menjadi terdesentralisasi?
Dalam arsitektur domain, dayan didistribusikan dari kotak distribusi dayan terpusat yang berisi sekring dan relai. Pada struktur zonal, distribusi menjadi terdesentralisasi: satu bundel dayan ditarik dari baterai ke zona, dan modul zonal membagikan dayan tersebut ke modul-modul di zona itu. Kabel daya yang pendek berarti penghematan berat dan biaya secara langsung. Selain itu, sekring digantikan oleh sekring pintar berbasis semikonduktor; saklar sisi tinggi dengan karakteristik I²t menyediakan variasi sekring yang lebih sedikit dan penampang kabel yang lebih teroptimasi. Kotak distribusi dayan pintar yang terdiri dari MCU, saklar sisi tinggi, dan transceiver menjadi unit yang konfigurasinya dilakukan melalui perangkat lunak: kotak yang sama dapat digunakan di setiap zona dengan penyesuaian sesuai beban.
Pemisahan I/O Fisik dan Logis
Modul zonal menggabungkan fungsi input/output logis beberapa ECU di satu titik sehingga mengurangi kompleksitas kabel; sementara posisi fisik sensor dan aktuator tetap dipertahankan. Satu langkah lebih jauh, perangkat ujung menjadi "cerdas": sirkuit lokal menyimpan informasi status dan menjalankan diagnosis kerusakan. Protokol yang disederhanakan seperti CAN FD Light bahkan dapat menghilangkan kebutuhan MCU terpisah di beberapa node ujung. Pemisahan ini, di mana perangkat keras tetap tetap sementara tugasnya ditentukan oleh perangkat lunak, merupakan tulang punggung rekayasa SDV.
Bus Data pada Kendaraan Zonal: Bandwidth, Penjadwalan Waktu, dan Keamanan Siber
Fusi sensor dan beban kerja AI mewajibkan topologi zonal dibangun di atas backbone berbandwidth tinggi: PCIe, CAN XL yang mencapai kecepatan data hingga 20 Mbps dan tetap menjaga kompatibilitas CAN yang ada, serta Ethernet gigabit. Tantangan sebenarnya bukan sekadar bandwidth, melainkan penjadwalan waktu; pesan kontrol singkat, data sensor ADAS, dan lalu lintas infotainment membawa persyaratan latensi, jitter, dan sinkronisasi yang sangat berbeda satu sama lain. Ukuran kasarnya seperti ini: target latensi level milidetik untuk audio, dan level mikrodetik untuk transmisi daya serta kontrol sasis berlaku di sini.
Untuk membawa kelas lalu lintas yang berbeda ini dalam satu jaringan, Time-Sensitive Networking (TSN) berbasis Ethernet muncul sebagai solusi. Standar-standar seperti sinkronisasi waktu (IEEE 802.1AS), pembentukan lalu lintas peka waktu (802.1Qbv), express traffic (802.3br), frame pre-emption (802.1Qbu), dan redundansi (802.1CB) memberikan jaminan latensi deterministik bagi data kritis. Di sisi keselamatan, ada dukungan ISO 26262, jalur komunikasi redundan, partisi keselamatan, dan deteksi kerusakan; di sisi keamanan siber, standar ISO/SAE 21434, regulasi UNECE, serta mekanisme enkripsi-autentikasi tingkat rendah seperti MACsec yang menentukan. Karena arsitektur zonal memusatkan jaringan, metode serangan berbasis Ethernet juga menjadi dapat diterapkan; keruntuhan konsep pemisahan I/O-pemrosesan dalam kasus pelanggaran keamanan merupakan risiko yang harus dievaluasi secara individual.
Bagaimana Pemisahan Perangkat Keras-Perangkat Lunak Memungkinkan Pembaruan OTA?
Pembaruan OTA adalah fitur pertama yang terlintas dalam sebagian besar diskusi SDV, tetapi bukanlah sebuah kemampuan yang berdiri sendiri; melainkan hasil dari sebuah arsitektur. Pembaruan tanpa gangguan tidak dapat dicapai tanpa memisahkan perangkat lunak dari chip tertentu melalui lapisan abstraksi perangkat keras (HAL) dan tanpa memecah fungsi kendaraan menjadi layanan yang independen, dapat digunakan kembali, dan berkopling longgar (arsitektur berorientasi layanan, SOA). Pemisahan ini juga mencakup isolasi antar perangkat lunak dengan tingkat keselamatan yang berbeda.
Makna konkretnya adalah: arsitektur zone, bersama pembaruan OTA/FOTA dan konektivitas cloud berkelanjutan, memberikan kendali perawatan perangkat lunak tingkat tinggi kepada pabrikan, sekaligus dapat mengalihkan loop kontrol waktu nyata ke modul zone. Penyetelan halus seperti penguatan modul yang tidak digunakan pada kendaraan listrik juga menjadi lebih mudah dalam struktur ini. Pada akhirnya, perangkat lunak kendaraan listrik lebih dari sekadar saluran pembaruan; ia adalah lapisan definisi yang menentukan fitur, sistem keselamatan, dan karakter performa kendaraan. Kendaraan mulai menyerupai pusat data terdistribusi di atas roda; rantai nilai bersandar pada perangkat lunak, daya komputasi, dan arsitektur sistem.
Seberapa Cepat Transisi Ini Terjadi, dan Apakah Arsitektur Zonal Saja Cukup?
Transisi akan berlangsung bertahap. Domain bodi (body), karena memuat banyak ECU aktuator dan sensor terdistribusi, akan menjadi area pertama yang bermigrasi ke arsitektur zone; transisi kontrol ADAS, powertrain, dan sasis dapat memakan waktu lebih lama karena sifatnya yang kritis terhadap keselamatan. Evolusi pada lapisan MCAL, BSW, dan aplikasi sejak 2017 menunjukkan bahwa ini bukan sekadar proyek teknis, melainkan perubahan pola pikir di tingkat industri.
Pembacaan yang berimbang juga diperlukan. Arsitektur zonal mengorganisasikan ulang kendaraan secara fisik; sisi logis dan perangkat lunak (SOA, HAL, keamanan siber) tetap harus diselesaikan - hanya menyusun ulang kabel tidak menjadikan kendaraan didefinisikan oleh perangkat lunak. Estimasi ukuran pasar juga berubah secara signifikan tergantung definisi cakupannya; angka-angka berbeda untuk pasar arsitektur E/E bersumber dari perbedaan dalam apa yang dihitung (hanya platform komputasi, atau seluruh elektronika terdistribusi). Selain itu, perlu diingat bahwa pemasok semikonduktor dan solusi, sebagai pihak-pihak dalam transisi ini, secara alami berkepentingan dengan transformasi tersebut.
Kesimpulannya adalah sebuah keseimbangan rekayasa yang jelas: kendaraan yang didefinisikan oleh perangkat lunak hanya mungkin jika kendaraan didefinisikan oleh perangkat lunak, organisasi perangkat keras baru berbasis domain dan pengontrol zonal, lapisan perangkat lunak yang terdekomposisi, dan tulang punggung data yang deterministik serta aman hadir secara bersamaan. Pembaruan OTA adalah buah paling terlihat dari struktur terintegrasi ini; revolusi sesungguhnya terletak pada perangkat keras kendaraan yang menyerahkan definisi tugasnya kepada perangkat lunak.
Sumber
- How a Zone Architecture Paves the Way to a Fully Software-Defined Vehicle (TI SPRY345)
- Domain vs zonal architecture: a complete guide
- Zonal E/E Architecture for Software Defined Vehicles (SDVs)
- Automotive zonal architecture
- Automotive Zone Controller
- Zone Control Unit (ZCU)
- What is a Software-Defined Vehicle
- Understanding Software-Defined Vehicles (SDVs)
- Software-Defined Vehicle (SDV) Explained
- Why Safety Function Decoupling is Essential
- Service-Oriented Architecture for SDVs
- What Is Service-Oriented Architecture (SOA)?
- The Rise of the Software-Defined Vehicle: Architectures and Challenges
- The E/E architecture of the future
- Vehicle Electronics Architecture
- Redefining Architecture in SDVs