< Kembali ke Rangkaian Alat Simulasi Otomotif

Pengarang: Johnny Liu, CEO di Dowway Vehicle
Diterbitkan: 16 Maret 2026
Terakhir Diperbarui: 16 Maret 2026
Catatan Peninjau: Disusun berdasarkan laporan sumber teknis yang disediakan untuk artikel ini.
Jenis Konten: Analisis industri teknis
Catatan Yurisdiksi: Artikel ini membahas alur kerja teknik otomotif dalam konteks global, dengan perhatian khusus pada lokalisasi pasar Tiongkok dan praktik teknik lokal.
Penafian: Artikel ini ditujukan untuk pendidikan teknik dan diskusi industri. Ini bukan nasihat hukum, sertifikasi, atau peraturan.

Jawaban Langsung

Simcenter System Architect, atau SSA, adalah platform arsitektur tingkat sistem dan simulasi bersama dalam portofolio Siemens Simcenter. Bagi tim otomotif, platform ini berfungsi sebagai jembatan antara persyaratan, desain fungsional, arsitektur fisik, simulasi, optimasi, dan verifikasi. Hal ini penting karena kendaraan modern bukan lagi sekadar produk mekanik sederhana. Kendaraan modern merupakan sistem mekanik, listrik, elektronik, dan perangkat lunak yang saling terkait erat dan perlu dirancang serta diperiksa sebagai satu kesatuan.

• Pengembangan kendaraan telah bergeser dari pekerjaan subsistem yang terisolasi ke rekayasa sistem lintas domain secara menyeluruh.
• SSA membantu menghubungkan persyaratan, arsitektur, model simulasi, dan validasi dalam satu alur kerja.
• Keunggulan utamanya adalah simulasi bersama heterogen, ketertelusuran penuh, desain modular, dan integrasi rantai alat.
• Sangat cocok untuk pekerjaan sistem penggerak EV, manajemen termal, ADAS, dan validasi pengontrol domain.
• Versi bahasa Mandarin menurunkan hambatan pembelajaran bagi tim teknik lokal dan mendukung standar serta kolaborasi lokal.

Program pengembangan kendaraan modern semakin sulit dikelola. Elektrifikasi, pengemudian cerdas, konektivitas, dan platform yang sarat perangkat lunak telah mendorong kompleksitas kendaraan jauh melampaui alur kerja berbasis dokumen lama. Banyak tim masih bekerja dengan alat dan file terpisah, yang menyebabkan silo informasi, iterasi yang lambat, dan masalah integrasi yang terlambat.

Di situlah rekayasa sistem berbasis model, atau MBSE, menjadi berguna. MBSE memberikan tim cara untuk menghubungkan persyaratan, fungsi sistem, desain fisik, simulasi, dan verifikasi dalam satu rantai. Dalam laporan yang Anda berikan, Simcenter System Architect berada di pusat rantai tersebut. Simcenter System Architect disajikan sebagai penghubung yang menghubungkan desain konsep, rekayasa detail, verifikasi simulasi, dan iterasi desain di seluruh rangkaian perangkat lunak otomotif.

---

Mengapa Tim Otomotif Membutuhkan Platform Tingkat Sistem?

Perubahan terbesar dalam pengembangan otomotif bukan hanya karena kendaraan memiliki lebih banyak perangkat lunak. Melainkan karena produk itu sendiri telah menjadi sistem campuran. Kendaraan modern menggabungkan:

• sistem mekanis seperti sasis dan bodi,
• sistem kelistrikan seperti baterai dan motor,
• sistem elektronik seperti ECU dan sensor, dan
• Sistem perangkat lunak seperti logika kontrol dan fungsi tertanam.

Komponen-komponen ini tidak bekerja sendiri-sendiri. Mereka saling memengaruhi satu sama lain sepanjang waktu. Masalah termal dapat mengubah keluaran daya. Strategi kontrol dapat mengubah suhu baterai. Penundaan komunikasi dapat mengubah respons pengereman. Itulah mengapa alat simulasi domain tunggal tradisional tidak lagi cukup dengan sendirinya.

Laporan tersebut mengidentifikasi tiga masalah umum dalam alur kerja lama:

• silo informasi antar tim,
• kecepatan iterasi rendah, dan
• Keterkaitan yang lemah antara desain dan kinerja sebenarnya.

SSA diposisikan sebagai alat yang memecahkan masalah tersebut dengan menggunakan arsitektur sistem sebagai lapisan pengorganisasian. Alih-alih membiarkan setiap disiplin bekerja secara terisolasi hingga integrasi tahap akhir, SSA memungkinkan tim untuk membangun satu pandangan sistem dan menjalankan validasi lintas domain lebih awal.

---

Apa yang Dilakukan Simcenter System Architect dalam Rantai Alat Otomotif?

SSA merupakan bagian dari rangkaian perangkat lunak Siemens Simcenter, tetapi perannya berbeda dari sekadar solver tunggal atau simulator domain tunggal. SSA tidak hanya berfokus pada satu disiplin ilmu saja. Perannya adalah untuk menghubungkan:

• persyaratan,
• arsitektur fungsional,
• arsitektur fisik,
• model simulasi,
• skenario validasi, dan
• melaporkan hasil.

Itulah mengapa SSA sangat cocok untuk MBSE otomotif. Dalam program kendaraan normal, alur kerja bergerak dari definisi konsep ke desain subsistem, kemudian ke simulasi, validasi, dan penyerahan ke manajemen siklus hidup. SSA berada di antara langkah-langkah tersebut dan membantu menjaga logika tetap terhubung.

Hal ini sangat penting ketika tim perlu membandingkan opsi arsitektur sejak dini, sebelum prototipe perangkat keras tersedia. Diagram statis tidak dapat melakukan itu. Spreadsheet yang terpisah tidak dapat melakukan itu. Platform arsitektur sistem dengan simulasi bersama dapat melakukannya.

---

Keunggulan Utama Simcenter System Architect untuk Teknik Otomotif

1. Simulasi Bersama Heterogen Multidisiplin

Laporan ini sangat menekankan poin ini, dan memang ada alasannya. Pengembangan otomotif melibatkan banyak disiplin ilmu sekaligus. Insinyur sasis, tim penggerak daya, tim baterai, insinyur kontrol, tim perangkat lunak, dan arsitek E/E sering menggunakan alat dan format model yang berbeda.

SSA mendukung integrasi model heterogen melalui antarmuka standar seperti FMI/FMU dan alur kerja bergaya Modelica SSP. Itu berarti model dari alat-alat seperti:

• Simcenter Amesim,
• MATLAB/Simulink, dan
• Lingkungan berbasis Modelica

dapat diintegrasikan ke dalam satu arsitektur simulasi tingkat sistem tanpa perlu melakukan perombakan besar pada model aslinya.

Ini merupakan keuntungan besar bagi teknik otomotif. Ambil contoh kendaraan listrik. Model termal baterai mungkin berada di Amesim, strategi kontrol motor mungkin dibangun di Simulink, dan model sistem lainnya mungkin berasal dari lingkungan lain. Dengan SSA, model-model tersebut dapat dijalankan bersama dalam satu pengaturan sehingga para insinyur dapat mempelajari aliran energi, perilaku termal, dan respons kontrol secara bersamaan.

Hal itu mempermudah mendeteksi masalah tingkat sistem sebelum integrasi perangkat keras dimulai.

2. Ketertelusuran Persyaratan Lengkap Berdasarkan MBSE

Laporan tersebut juga menekankan masalah kedua dalam pengembangan otomotif: persyaratan sering kali terpisah dari desain dan validasi. Tim mungkin memulai dengan dokumen persyaratan, kemudian beralih ke alat desain dan alat simulasi yang tidak terkait erat dengan tujuan awal. Ketika terjadi kesalahan, melacak penyebabnya kembali ke persyaratan yang tepat menjadi lambat dan rumit.

SSA mengatasi hal itu dengan mendukung impor, penguraian, alokasi, dan ketertelusuran persyaratan. Target kendaraan tingkat atas dapat dibagi menjadi target subsistem dan komponen, kemudian dikaitkan dengan model arsitektur, kasus simulasi, dan hasil validasi.

Contoh yang baik dari laporan tersebut adalah target pengereman darurat otomatis seperti:

Waktu respons AEB ≤ 100 ms

Persyaratan tersebut dapat diterapkan pada:

• persepsi,
• keputusan, dan
• subsistem aktuasi.

Dari situ, para insinyur dapat memeriksa apakah arsitektur dan hasil simulasi memenuhi target awal. Jika tidak, mereka dapat menelusuri kembali dari hasil yang gagal ke subsistem atau parameter yang tepat yang menyebabkan masalah tersebut.

3. Desain Arsitektur Modular dan Iterasi Cepat

Program pengembangan kendaraan jarang sekali berjalan dengan satu arsitektur tetap sejak hari pertama. Tim membandingkan konsep, mengubah parameter komponen, mengganti blok desain, dan menjalankan studi perbandingan berulang kali.

SSA menyediakan lingkungan desain modular grafis di mana para insinyur dapat membangun blok arsitektur, menghubungkannya melalui antarmuka standar, dan mengubahnya dengan cepat. Laporan tersebut menunjukkan bahwa hal ini berguna baik untuk pekerjaan konseptual maupun rekayasa detail karena mendukung:

• bangunan arsitektur seret dan lepas,
• komponen modular,
• antarmuka standar,
• pemodelan berparameter, dan
• analisis sensitivitas.

Hal ini mempercepat iterasi desain. Para insinyur dapat menyesuaikan kapasitas baterai, daya motor, parameter kontrol, kekakuan suspensi, atau nilai kunci lainnya dan mempelajari bagaimana keseluruhan kendaraan merespons.

Laporan tersebut bahkan mencatat bahwa Hyundai menggunakan optimasi parameter berbasis SSA untuk memangkas satu proses optimasi dari satu minggu menjadi 15 menit. Kecepatan seperti itu sangat penting ketika keputusan arsitektur perlu diambil dengan cepat.

4. Integrasi Tanpa Hambatan dengan Rantai Alat Otomotif

Salah satu poin penting lainnya dalam laporan ini adalah posisi SSA dalam rantai alat pengembangan otomotif yang lebih luas. SSA dirancang untuk terhubung dengan:

• NX untuk data CAD,
• Simcenter 3D untuk pekerjaan CAE,
• Simcenter Testlab untuk data pengujian dan validasi,
• Teamcenter untuk PLM dan manajemen siklus hidup, dan
• Alur kerja berbasis Git atau file untuk tata kelola model.

Artinya, model arsitektur, data simulasi, persyaratan, laporan, dan catatan siklus hidup dapat tetap terhubung, alih-alih berada di sistem terpisah dengan konflik versi.

Dalam pekerjaan rekayasa nyata, hal ini mengurangi data duplikat, membuat proses serah terima lebih rapi, dan mendukung ketertelusuran di seluruh proses pengembangan.

---

Modul Fungsional Inti dari Simcenter System Architect

Modul Desain Arsitektur Sistem

Inilah inti dari SSA. SSA memberikan tim lingkungan grafis dan modular untuk membangun model arsitektur sistem.

Pemodelan Arsitektur Fungsional

Mode pemodelan pertama berfokus pada fungsi sistem. Dalam bidang otomotif, ini berarti membangun pandangan fungsional dari kendaraan atau subsistem.

Sebagai contoh, sistem kontrol kendaraan dapat dipecah menjadi:

• fungsi penginderaan,
• fungsi pengambilan keputusan, dan
• fungsi eksekusi.

Laporan ini menggunakan struktur ini untuk menjelaskan bagaimana logika mengalir melalui sistem. Modul penginderaan meneruskan data lingkungan ke modul pengambilan keputusan. Modul pengambilan keputusan memproses data tersebut dan mengirimkan perintah kontrol ke modul eksekusi.

Jenis pemodelan ini berguna pada tahap konsep karena membantu tim mendefinisikan batasan dan logika sistem sebelum pilihan perangkat keras akhir dibuat.

Pemodelan Arsitektur Fisik

Mode pemodelan kedua berfokus pada komponen penyusun sistem. Di sinilah fungsi-fungsi ditetapkan pada komponen fisik seperti:

• kamera,
• unit radar,
• pengendali domain,
• kaliper rem,
• motor, dan
• komponen baterai.

Laporan tersebut juga mencatat bahwa pemodelan arsitektur fisik mendefinisikan antarmuka komponen, termasuk:

• antarmuka listrik,
• antarmuka mekanis, dan
• antarmuka komunikasi.

Hal ini penting dalam rekayasa detail karena menghubungkan fungsi dengan pilihan desain nyata dan pekerjaan integrasi selanjutnya.

Desain Arsitektur Hierarkis

SSA mendukung desain arsitektur berlapis. Tim dapat bekerja dari:

• tingkat kendaraan,
• hingga tingkat subsistem,
• hingga tingkat komponen.

Laporan tersebut memberikan contoh yang jelas tentang logika ini:

Arsitektur kendaraan → arsitektur subsistem daya → arsitektur komponen baterai

Hierarki semacam itu membuat model tetap mudah dibaca dan membantu tim besar membagi pekerjaan dengan cara yang terkontrol.

Pustaka Komponen Otomotif yang Dapat Digunakan Kembali

Laporan tersebut juga menyebutkan pustaka otomotif bawaan atau yang dapat digunakan kembali, termasuk blok standar untuk:

• sistem penggerak,
• casis,
• penangguhan, dan
• unit kontrol.

Hal ini mengurangi pekerjaan pemodelan yang berulang dan memberikan tim titik awal yang lebih standar.

---

Modul Manajemen dan Keterlacakan Persyaratan

Modul ini dibangun berdasarkan satu gagasan: persyaratan tidak boleh berada di luar alur rekayasa.

Impor Persyaratan

Menurut laporan tersebut, SSA dapat mengimpor kebutuhan dari berbagai sumber seperti:

• Excel, dan
• Dokumen persyaratan bergaya DOORS.

Hal itu mempermudah pengintegrasian target program tingkat atas ke dalam arsitektur dan lingkungan simulasi.

Rincian Persyaratan

Laporan ini memberikan contoh rinci di sini. Target tingkat kendaraan seperti:

Jangkauan NEDC ≥ 600 km

dapat dipecah menjadi persyaratan subsistem dan komponen seperti:

• kapasitas baterai ≥ 80 kWh,
• daya maksimum motor ≥ 150 kW, dan
• Kepadatan energi sel tunggal ≥ 280 Wh/kg.

Ini adalah langkah yang sangat praktis karena mengubah tujuan produk yang luas menjadi nilai-nilai yang dapat dirancang dan diverifikasi oleh para insinyur.

Alokasi Kebutuhan

Setelah diuraikan, persyaratan tersebut dialokasikan ke blok arsitektur yang tepat. Target kapasitas baterai dialokasikan ke sistem baterai. Target daya dialokasikan ke sistem motor dan penggerak. Target waktu dialokasikan ke blok penginderaan, komputasi, dan aktuasi.

Ketertelusuran Maju dan Mundur

Laporan ini menyampaikan poin penting di sini. SSA mendukung:

• ketertelusuran ke depan dari persyaratan ke desain ke simulasi ke validasi, dan
• Penelusuran terbalik dari hasil yang gagal kembali ke persyaratan awal.

Jika sebuah kendaraan gagal mencapai target jarak tempuhnya, para insinyur dapat menelusuri masalah tersebut kembali ke ukuran baterai, efisiensi motor, strategi termal, atau logika kontrol, alih-alih hanya menebak-nebak.

Hal itu menghemat waktu dan menjaga agar iterasi tetap fokus.

---

Modul Ko-Simulasi Multidisiplin

Modul ini mengubah arsitektur menjadi model sistem yang berfungsi.

Impor dan Kompatibilitas Model

Laporan ini mencantumkan lingkungan alat utama yang relevan di sini:

• Simcenter Amesim untuk model mekanik dan termal,
• MATLAB/Simulink untuk model strategi kontrol, dan
• Modelica untuk model multipisika.

Hal ini dapat diintegrasikan melalui antarmuka standar seperti FMI/FMU sehingga tim tidak perlu membangun ulang setiap model dari awal.

Bagi tim otomotif, itu berarti kelompok yang berbeda dapat tetap menggunakan alat pemodelan pilihan mereka sambil tetap berkontribusi pada satu pengaturan simulasi tingkat sistem.

Pengaturan Skenario Simulasi

Laporan tersebut memberikan beberapa jenis skenario otomotif yang realistis, termasuk:

• Siklus NEDC,
• Siklus WLTP,
• kondisi pendakian bukit, dan
• kondisi pengereman.

Pengaturan skenario dapat mencakup:

• kecepatan kendaraan,
• suhu sekitar, dan
• kondisi beban.

Bagian ini penting karena model sistem hanya akan berguna jika diuji dalam kondisi operasi yang realistis. Model termal baterai dalam wadah laboratorium adalah satu hal. Model termal baterai dalam kondisi pengisian cepat atau berkendara dengan kecepatan tinggi adalah hal lain.

Analisis Hasil

Laporan tersebut menyatakan bahwa SSA mendukung visualisasi hasil melalui:

• kurva,
• grafik, dan
• animasi.

Hal ini juga memungkinkan perbandingan langsung dari berbagai opsi arsitektur. Para insinyur dapat memeriksa nilai-nilai seperti:

• tegangan baterai,
• kecepatan motor,
• perpindahan suspensi, dan
• kinerja termal.

Hal ini mempermudah identifikasi hambatan dan perbandingan pilihan arsitektur secara terstruktur.

---

Modul Optimasi dan Analisis

Modul ini menangani peningkatan desain dan pertimbangan arsitektur.

Optimasi Parametrik

Laporan tersebut menyatakan bahwa SSA dapat mengoptimalkan parameter seperti:

• kapasitas baterai,
• tenaga motor,
• kekakuan suspensi, dan
• nilai strategi kontrol.

Tujuan optimasi dapat mencakup:

• jangkauan maksimum,
• penggunaan energi minimum, atau
• Performa NVH yang lebih baik.

Laporan tersebut mencatat penggunaan metode seperti algoritma genetika dan optimasi berbasis gradien.

Salah satu hasil yang disebutkan dalam teks sumber adalah bahwa Hyundai, dengan dukungan AI dalam proses yang lebih luas, mengurangi waktu evaluasi persyaratan tunggal dari 2 menit menjadi 0,1 detik. Hal itu menunjukkan bagaimana otomatisasi tingkat sistem dapat memangkas waktu iterasi desain.

Optimasi Multiobjektif

Hal ini sangat penting dalam pekerjaan otomotif karena tujuan desain seringkali saling bertentangan. Laporan tersebut memberikan contoh-contoh seperti:

• jangkauan versus percepatan, dan
• Pengurangan bobot versus kekuatan struktural.

SSA mendukung optimasi multi-objektif dengan tujuan berbobot sehingga tim dapat mencari arsitektur yang menyeimbangkan kebutuhan yang saling bertentangan daripada hanya mengejar satu KPI.

Analisis Sensitivitas

Analisis sensitivitas membantu mengidentifikasi parameter mana yang paling penting. Laporan ini memberikan contoh seperti:

• kapasitas baterai,
• efisiensi motor, dan
• koefisien hambatan

berkaitan dengan jangkauan kendaraan.

Hal itu membantu tim memfokuskan upaya rekayasa di tempat yang akan memberikan dampak terbesar.

---

Modul Manajemen Pelaporan dan Kolaborasi

Modul ini membahas komunikasi teknik, tata kelola, dan pengendalian siklus hidup.

Pembuatan Laporan Otomatis

Laporan tersebut menyatakan bahwa SSA dapat menghasilkan:

• laporan desain arsitektur,
• laporan validasi simulasi, dan
• laporan ketertelusuran persyaratan.

Laporan-laporan ini dapat mencakup diagram arsitektur, hasil simulasi, dan daftar persyaratan. Hal ini berguna tidak hanya untuk tinjauan internal, tetapi juga untuk dokumentasi teknik berbasis standar.

Kolaborasi dan Perizinan

Laporan tersebut menyatakan bahwa SSA mendukung pekerjaan multi-pengguna dan izin berbasis peran, termasuk peran seperti:

• desainer,
• pengulas, dan
• administrator.

Hal ini penting dalam program kendaraan berskala besar karena pekerjaan arsitektur, pekerjaan simulasi, dan manajemen persyaratan sering kali dilakukan oleh tim yang berbeda.

PLM dan Keterkaitan Siklus Hidup

Laporan tersebut juga mencatat integrasi dengan alat PLM sehingga laporan, model arsitektur, dan data simulasi dapat dikaitkan dengan alur kerja siklus hidup. Hal ini membantu dalam hal:

• kontrol versi,
• pencatatan, dan
• ketertelusuran di kemudian hari.

Teks sumber menyebutkan AZL menggunakan alur kerja terhubung semacam ini dalam pekerjaan EV NVH sehingga data uji dan data simulasi dapat digabungkan ke dalam satu set laporan standar.

---

Studi Kasus Rekayasa 1: Desain Arsitektur Sistem Penggerak Kendaraan Listrik dan Optimalisasi Kinerja

Kasus pertama dalam laporan ini berfokus pada produsen kendaraan arus utama yang mengembangkan kendaraan listrik bertenaga baterai baru. Program ini menghadapi beberapa masalah umum:

• kesulitan memilih arsitektur powertrain terbaik,
• validasi kinerja lintas domain yang rumit, dan
• Kebutuhan untuk menyeimbangkan jangkauan dan penggunaan energi.

SSA digunakan sebagai alat utama di tingkat sistem.

Langkah 1: Impor dan Uraikan Target Tingkat Kendaraan

Laporan sumber tersebut mencantumkan target utama sebagai berikut:

• Jangkauan NEDC ≥ 650 km,
• Akselerasi 0–100 km/jam ≤ 6,5 detik, dan
• Konsumsi energi ≤ 12 kWh per 100 km.

Target-target tingkat atas ini diimpor ke SSA dan dipecah menjadi target subsistem dan komponen seperti:

• kapasitas baterai ≥ 85 kWh,
• daya maksimum motor ≥ 160 kW, dan
• Efisiensi kontrol listrik ≥ 95%.

Hal ini menciptakan hubungan antara tujuan kendaraan dan arsitektur teknik.

Langkah 2: Membangun Arsitektur Fungsional dan Fisik

Tim tersebut kemudian membangun arsitektur powertrain fungsional dan fisik di SSA. Dengan menggunakan pustaka komponen otomotif, mereka mendefinisikan rantai fisik yang terdiri dari:

• paket baterai,
• motor,
• sistem kontrol listrik, dan
• peredam.

Tiga opsi arsitektur dibandingkan:

• penggerak roda belakang motor tunggal,
• penggerak semua roda motor ganda, dan
• Penggerak depan motor tunggal plus penambah jangkauan.

Tahap ini memberi tim cara terstruktur untuk membandingkan konsep-konsep, alih-alih hanya mengandalkan presentasi statis.

Langkah 3: Jalankan Simulasi Bersama Multidisiplin

Laporan tersebut menyatakan bahwa tim tersebut mengimpor:

• Model manajemen termal baterai yang dibangun di Simcenter Amesim, dan
• Model strategi kontrol motor yang dibangun di MATLAB/Simulink.

Mereka kemudian mengkonfigurasi kondisi NEDC, kecepatan tinggi, dan pendakian bukit untuk mensimulasikan ketiga konsep arsitektur tersebut. Hasil utama yang diperoleh meliputi:

• lapangan latihan golf,
• percepatan,
• penggunaan energi, dan
• suhu baterai.

Ini adalah salah satu contoh paling jelas dalam laporan tersebut tentang nilai SSA dalam pengembangan kendaraan nyata.

Langkah 4: Optimalkan dan Pilih Arsitektur Terbaik

Laporan tersebut menyatakan bahwa tim menggunakan optimasi multi-objektif dengan tujuan seperti:

• jangkauan maksimum,
• penggunaan energi minimum, dan
• performa akselerasi terbaik.

Setelah optimasi, solusi yang terpilih adalah arsitektur penggerak semua roda motor ganda. Laporan tersebut memberikan hasil akhir sebagai berikut:

• Jangkauan 680 km,
• 0–100 km/jam dalam 5,8 detik, dan
• 11,2 kWh per 100 km.

Hasil tersebut memenuhi target kendaraan.

Langkah 5: Melacak Persyaratan dan Menghasilkan Laporan

Tim tersebut kemudian menggunakan fungsi ketertelusuran SSA untuk memastikan bahwa desain komponen sesuai dengan persyaratan awal. Mereka menghasilkan:

• laporan arsitektur powertrain, dan
• laporan validasi simulasi,

Kemudian, output tersebut dikirim ke sistem PLM untuk pekerjaan selanjutnya seperti pemilihan komponen dan persiapan prototipe.

Laporan tersebut menyatakan bahwa hal ini membantu mempersingkat siklus pengembangan arsitektur powertrain sebesar 30% dan meningkatkan efisiensi validasi simulasi sebesar 40%.

---

Studi Kasus Rekayasa 2: Desain Arsitektur Pengontrol Domain Pengemudian Otonom dan Validasi Keselamatan Fungsional

Kasus kedua dalam laporan ini berfokus pada pengendali domain pengemudian otomatis L2+. Tantangan utamanya adalah:

• logika fungsional kompleks,
• koordinasi multi-modul yang sulit, dan
• Validasi keselamatan fungsional berdasarkan ekspektasi ISO 26262 ASIL-B.

SSA digunakan untuk mendukung pekerjaan arsitektur dan simulasi yang berorientasi pada keselamatan.

Langkah 1: Mendefinisikan dan Mengalokasikan Persyaratan Fungsional

Laporan tersebut mencantumkan fitur-fitur seperti:

• AEB,
• ACC, dan
• Menjaga jalur.

Persyaratan ini kemudian dirinci menjadi:

• persepsi,
• keputusan,
• pelaksanaan, dan
• modul komunikasi.

Pada saat yang sama, tim menetapkan tujuan keselamatan dan tingkat risiko sesuai dengan pola pikir ISO 26262.

Langkah 2: Membangun Arsitektur Pengontrol dan Mendefinisikan Antarmuka

Arsitektur tersebut menyatukan:

• antarmuka kamera dan radar pada lapisan penginderaan,
• Alokasi sumber daya CPU/GPU pada lapisan pengambilan keputusan,
• antarmuka rem dan kemudi di lapisan eksekusi, dan
• Antarmuka CAN, LIN, dan Ethernet pada lapisan komunikasi.

Laporan tersebut memperjelas bahwa definisi antarmuka merupakan bagian utama dari proses arsitektur, bukan detail kecil. Dalam pekerjaan pengontrol, banyak masalah muncul dari pengaturan waktu, komunikasi, dan asumsi antarmuka, bukan hanya dari maksud algoritma semata.

Langkah 3: Simulasikan Kasus Kegagalan untuk Validasi Keselamatan Fungsional

Laporan tersebut menyatakan bahwa SSA digunakan bersamaan dengan:

• Model strategi kontrol MATLAB/Simulink, dan
• Data uji Simcenter Testlab.

Tim tersebut membuat skenario kesalahan seperti:

• Kerusakan kamera,
• gangguan komunikasi, dan
• Kegagalan aktuator.

Simulasi ini digunakan untuk memeriksa diagnostik dan respons toleransi kesalahan.

Langkah 4: Optimalkan Arsitektur

Berdasarkan hasil simulasi, tim menemukan beberapa masalah keamanan seperti:

• penundaan komunikasi yang tinggi, dan
• Waktu respons diagnosis kesalahan yang lambat.

Mereka kemudian menggunakan optimasi parameter SSA untuk menyesuaikan:

• pengaturan protokol komunikasi,
• menghitung alokasi, dan
• strategi diagnostik.

Hal ini membantu meningkatkan keamanan dan keandalan sebelum tahap integrasi selanjutnya.

Langkah 5: Menghasilkan Keluaran yang Berorientasi pada Kepatuhan

Hasil akhir yang diperoleh meliputi:

• laporan desain arsitektur pengontrol,
• laporan validasi keselamatan fungsional, dan
• catatan ketertelusuran.

Hal ini mendukung pekerjaan sertifikasi dan kesiapan produksi di kemudian hari.

Laporan tersebut menyatakan bahwa kasus ini menunjukkan bagaimana SSA dapat mendukung pengembangan pengendali domain secara terstruktur dan sesuai standar, bukan hanya pemodelan sistem fisik.

---

Adaptasi Versi Bahasa Mandarin dan Nilai Rekayasa Lokal

Laporan ini mencakup bagian khusus tentang versi bahasa Mandarin dari Simcenter System Architect, dan bagian itu harus tetap ada dalam artikel karena memberikan nilai tambah yang nyata bagi pembaca yang dituju.

Versi bahasa Mandarin mempertahankan kemampuan inti lengkap dari versi bahasa Inggris sambil menambahkan dukungan bahasa lokal seperti:

• Teks antarmuka bahasa Mandarin lengkap,
• Menu dan dokumen bantuan berbahasa Mandarin,
• dukungan untuk impor dan pengeditan dokumen persyaratan berbahasa Mandarin, dan
• Dukungan teknis dan pelatihan berbahasa Mandarin.

Laporan tersebut juga mencatat dukungan terhadap standar dan norma lokal, termasuk referensi seperti GB/T 28950-2012 Persyaratan Keselamatan Kendaraan Listrik.

Hal ini bermanfaat karena beberapa alasan.

Pertama, hal ini menurunkan hambatan pembelajaran bagi tim teknik di Tiongkok.
Kedua, hal ini mempermudah penyusunan persyaratan dan kolaborasi harian dalam proyek-proyek lokal.
Ketiga, sistem ini tetap menjaga kompatibilitas data sepenuhnya dengan versi bahasa Inggris, yang mendukung kolaborasi lintas batas antara tim yang berbasis di Tiongkok dan tim di luar negeri.

Artinya, tim di Tiongkok dapat menggunakan versi bahasa Mandarin sementara mitra global menggunakan versi bahasa Inggris tanpa mengganggu alur data rekayasa yang dibagikan.

---

Catatan Teknik untuk Implementasi di Dunia Nyata

Laporan ini juga memberikan panduan praktis tentang penggunaan SSA dalam proyek-proyek rekayasa. Detail-detail ini tidak boleh diabaikan karena menjawab pertanyaan yang selalu diajukan oleh setiap tim setelah membaca tentang suatu platform: apa yang harus kita waspadai?

Standardisasi Model

Dalam simulasi bersama multi-domain, model yang diimpor memerlukan standar yang konsisten. Laporan tersebut menyatakan bahwa tim harus memastikan bahwa model mengikuti harapan FMI/FMU jika diperlukan dan bahwa satuan, parameter antarmuka, dan definisi data konsisten.

Selain itu, juga disarankan untuk membangun pustaka model standar internal sehingga tim dapat menggunakan kembali model dengan risiko ketidaksesuaian yang lebih rendah.

Persyaratan Kualitas

Teks sumber memperingatkan terhadap persyaratan yang samar seperti “meningkatkan jangkauan.” Persyaratan yang seharusnya adalah:

• terukur,
• dapat diuji, dan
• terkait dengan metode verifikasi.

Tanpa disiplin tersebut, ketertelusuran menjadi lemah dan model arsitektur kehilangan nilainya.

Skenario Simulasi yang Masuk Akal

Laporan tersebut menyatakan bahwa skenario simulasi harus sesuai dengan kondisi operasi nyata. Parameter seperti:

• suhu sekitar,
• kondisi jalan, dan
• memuat

Seharusnya mencerminkan kasus penggunaan kendaraan yang sebenarnya.

Salah satu contoh spesifik dalam laporan tersebut adalah program kendaraan listrik (EV) di Tiongkok utara yang seharusnya mencakup… kondisi suhu rendah pada -20°C untuk memverifikasi keandalan baterai dan manajemen termal.

Manajemen Kolaborasi Tim

Program otomotif berskala besar melibatkan banyak kelompok. Laporan ini merekomendasikan izin pengguna yang jelas, tanggung jawab tim yang jelas, dan alur kolaborasi yang terdefinisi di seluruh:

• tim desain arsitektur,
• tim simulasi, dan
• tim manajemen persyaratan.

Tanpa ini, konflik versi dan pekerjaan yang berulang dapat muncul kembali meskipun alat itu sendiri sudah mumpuni.

Integrasi Rantai Alat yang Mendalam

Catatan implementasi terakhir adalah memanfaatkan sepenuhnya integrasi SSA dengan perangkat Simcenter dan sistem PLM. Laporan ini memberikan Teamcenter sebagai contoh utama. Hasil simulasi tidak boleh terpisah dari catatan desain dan persyaratan. Keduanya harus dihubungkan sehingga peninjauan dan penggunaan kembali di kemudian hari menjadi lebih mudah.

---

Mengapa Simcenter System Architect Penting untuk Masa Depan

Laporan ini diakhiri dengan bagian yang berorientasi ke masa depan, dan bagian ini layak disimpan karena menjelaskan alasan jangka panjang mengapa alat ini penting.

Sistem kendaraan akan terus menjadi semakin kompleks seiring dengan kemajuan elektrifikasi, konektivitas, kecerdasan, dan arsitektur berbasis perangkat lunak. Hal ini akan meningkatkan kebutuhan akan:

• pemodelan tingkat sistem yang lebih baik,
• simulasi lintas domain yang lebih cepat,
• kontrol persyaratan yang lebih kuat, dan
• Validasi keamanan dan kinerja yang lebih andal.

Laporan tersebut juga mengarah pada penggabungan SSA di masa depan dengan:

• AI, dan
• Metode kembaran digital.

Arah tersebut masuk akal. Seiring model menjadi lebih besar dan program bergerak lebih cepat, tim teknik akan membutuhkan lebih banyak otomatisasi dalam studi arsitektur, optimasi, dan dukungan pengambilan keputusan tingkat sistem.

Poin terakhir laporan ini adalah bahwa MBSE (Managed-Based Surface Engineering) menjadi metode inti dalam pengembangan otomotif, bukan lagi praktik sampingan. Dalam konteks tersebut, SSA (Simulated Structure-Assistance Analysis) menjadi lebih dari sekadar penghubung simulasi. SSA menjadi lapisan kerja sentral dalam keseluruhan alur pengembangan.

---

Pertanyaan yang Sering Diajukan

Apa itu Simcenter System Architect dan bagaimana perannya dalam rangkaian perangkat MBSE otomotif?

Jawaban singkat:
Ini adalah lapisan arsitektur sistem yang menghubungkan persyaratan, desain sistem, aset simulasi, dan validasi dalam alur kerja MBSE otomotif.

Simcenter System Architect adalah platform pemodelan arsitektur tingkat sistem dan simulasi bersama dalam portofolio Siemens Simcenter. Dalam pengembangan otomotif, platform ini biasanya berada di antara definisi persyaratan dan simulasi teknik terperinci. Platform ini menghubungkan persyaratan, arsitektur fungsional, arsitektur fisik, model multi-domain, dan validasi sistem sehingga tim dapat mempelajari opsi arsitektur sebelum prototipe perangkat keras tersedia.

Bagaimana Simcenter System Architect mendukung simulasi bersama multidisiplin?

Jawaban singkat:
Hal ini memungkinkan model dari berbagai perangkat lunak rekayasa berjalan bersamaan dalam satu pengaturan tingkat sistem.

SSA mendukung integrasi model heterogen di berbagai domain dan alat. Dalam laporan ini, hal itu mencakup model berbasis Simcenter Amesim, MATLAB/Simulink, dan Modelica, dengan interoperabilitas melalui antarmuka seperti FMI/FMU. Hal ini memungkinkan tim otomotif untuk mensimulasikan interaksi antara mekanik, elektronik, kontrol, perilaku termal, dan domain lainnya dalam satu lingkungan daripada memeriksanya satu per satu.

Mengapa MBSE penting untuk pengembangan sistem otomotif modern?

Jawaban singkat:
Karena kendaraan modern terlalu kompleks untuk dikelola dengan baik menggunakan dokumen yang terpisah dan alat subsistem yang terisolasi.

Kendaraan kini menggabungkan sistem mekanik, listrik, elektronik, dan perangkat lunak dalam satu produk yang terhubung erat. MBSE memberikan tim cara terstruktur untuk mendefinisikan, menguraikan, mengalokasikan, dan memverifikasi persyaratan melalui model formal. Dalam alur kerja yang dijelaskan dalam laporan tersebut, SSA bertindak sebagai platform tingkat sistem yang menghubungkan arsitektur dan simulasi sehingga tim dapat memvalidasi pilihan lebih awal dan mengurangi masalah di tahap akhir.

Bagaimana Simcenter System Architect terintegrasi dengan perangkat rekayasa lainnya?

Jawaban singkat:
Ini menghubungkan pekerjaan arsitektur sistem dengan alat desain, simulasi, pengujian, dan siklus hidup.

Laporan ini mencantumkan integrasi dengan Simcenter Amesim, NX, Simcenter 3D, Simcenter Testlab, Teamcenter, dan manajemen model berbasis Git atau berbasis file. Hal ini membantu menjaga agar persyaratan, model, laporan, dan data validasi tetap terhubung di seluruh siklus hidup rekayasa. Alih-alih menyimpan catatan arsitektur, simulasi, dan siklus hidup dalam sistem yang terpisah, tim dapat mempertahankan alur pengembangan yang lebih konsisten.

Apa saja kasus penggunaan utama Simcenter System Architect di bidang otomotif?

Jawaban singkat:
Kasus penggunaan terkuat adalah desain sistem penggerak EV, studi termal baterai, pekerjaan strategi energi, desain ADAS dan pengontrol domain, serta validasi yang berorientasi pada keselamatan fungsional.

Laporan ini menyajikan dua studi kasus lengkap. Yang pertama mencakup desain dan optimasi arsitektur sistem penggerak kendaraan listrik, termasuk manajemen termal baterai dan simulasi siklus penggerak. Yang kedua mencakup pengontrol domain penggerak otomatis L2+, termasuk alokasi fitur, definisi antarmuka, simulasi kesalahan, dan validasi keselamatan. Studi kasus ini menunjukkan bagaimana SSA digunakan untuk pengambilan keputusan arsitektur awal dan verifikasi sistem selanjutnya.

---

Kesimpulan Akhir

Simcenter System Architect berguna dalam bidang teknik otomotif karena memberikan tim satu tempat untuk menghubungkan persyaratan, arsitektur, simulasi, optimasi, dan verifikasi.

Berdasarkan laporan sumber, nilainya jelas terlihat dalam empat bidang:

• simulasi bersama heterogen,
• Ketelusuran penuh,
• iterasi arsitektur modular, dan
• integrasi toolchain.

Lima kelompok fungsi utamanya juga jelas:

• desain arsitektur sistem,
• manajemen dan ketertelusuran persyaratan,
• simulasi bersama multidisiplin,
• optimasi dan analisis, dan
• pelaporan dan manajemen kolaborasi.

Dua studi kasus rekayasa dalam laporan ini menunjukkan pola yang sama dari sudut pandang yang berbeda. Dalam pengembangan kendaraan listrik (EV), SSA membantu tim membandingkan konsep sistem penggerak dan menyeimbangkan jangkauan, akselerasi, penggunaan energi, dan perilaku termal. Dalam pengembangan pengontrol penggerak otomatis, SSA membantu mengatur fitur, antarmuka, logika keselamatan, kasus kesalahan, dan catatan kepatuhan.

Versi bahasa Mandarin memberikan nilai tambah praktis bagi tim teknik lokal tanpa menghambat kolaborasi global.

Secara keseluruhan, laporan ini menyajikan SSA sebagai platform pengembangan tingkat sistem yang nyata untuk program kendaraan modern, terutama di mana kompleksitas, keterlacakan, dan integrasi lintas domain mendorong beban kerja.

---

Biografi Penulis

Johnny Liu adalah CEO di Dowway Vehicle. Dia bekerja di bidang strategi rekayasa otomotif, perencanaan arsitektur sistem, dan metode pengembangan digital untuk kendaraan listrik (EV), kendaraan cerdas, dan program rekayasa lintas domain.

---