Dari Pemanggilan Alat hingga Rekayasa Siklus Tertutup: Bagaimana Agen AI Terlibat dalam Pengembangan Sistem “Tiga-Listrik” Kendaraan Listrik

Pengarang: Johnny Liu, CEO di Dowway Vehicle

Diterbitkan pada: 9 Juli 2026

Waktu Baca: 15 menit

Kategori: Kendaraan Listrik, Rekayasa AI, Desain Berbasis Model (MBD)

Melampaui Hype Chatbot

Jika tim rekayasa perangkat lunak otomotif Anda melihat kerangka kerja seperti Agen Hermes atau Cakar Terbuka dan hanya melihat “chatbot yang lebih pintar,” mereka menggunakannya dengan salah. Dalam penelitian dan pengembangan otomotif yang berintegritas tinggi—terutama dalam sistem “Tiga-Listrik” (Sistem Manajemen Baterai)[BMS]Unit Kontrol Kendaraan[VCU], dan Unit Kontrol Motor[MCU])—nilai sebenarnya dari AI bukanlah untuk membuat keputusan akhir bagi para insinyur.

Sebaliknya, nilainya terletak pada kemampuannya untuk mengatur akses file, pemanggilan alat, eksekusi perintah CLI, sandboxing browser, dan pengambilan pengetahuan perusahaan ke dalam suatu sistem yang terintegrasi. alur kerja rekayasa yang dapat diaudit dan deterministik.

Artikel ini menjelaskan bagaimana Agen AI dapat menjembatani alat-alat yang terfragmentasi dari Desain Berbasis Model (MBD) tanpa mengorbankan keselamatan, menelusuri jalur yang jelas dari pemanggilan alat sederhana hingga siklus tertutup rekayasa yang lengkap.

1. Masalah Utama dalam Rekayasa Data: File yang Terfragmentasi, Alat yang Terisolasi, dan Rantai Bukti yang Terputus

Setiap insinyur perangkat lunak powertrain yang berpengalaman tahu bahwa cacat sistem kontrol yang umum jarang berasal dari satu file yang terisolasi. Pertimbangkan skenario pemecahan masalah standar ini:

• Gejala: Dalam kondisi suhu rendah, batas daya pengisian baterai turun secara tak terduga. Hal ini terjadi bersamaan dengan pembatasan torsi yang sporadis dan ketidaksesuaian kode masalah diagnostik (DTC) antara output pengontrol aktual dan spesifikasi sistem.

Untuk mendiagnosis masalah ini, seorang insinyur harus secara bersamaan membuka, mengurai, dan melakukan rujukan silang terhadap kumpulan data yang sangat besar dan terfragmentasi:

[System Requirements] ── (DOORS / Word)
       │
[Software Model]       ── (MATLAB Simulink / Stateflow)
       │
[Network Interfaces]   ── (DBC / ARXML)
       │
[Memory Mapping]       ── (ASAP2 / A2L / Calibration Parameters)
       │
[Real-world Behavior]  ── (Vector CANoe Trace / CANape Logs / MDF4)

Empat Tingkat Fragmentasi

Alur kerja ini menyoroti fragmentasi yang parah di empat dimensi yang berbeda:

1. Fragmentasi Tingkat Berkas: Persyaratan terdapat di Word atau IBM DOORS; logika kontrol berada di model MATLAB Simulink (.slx) dan diagram Stateflow; antarmuka bus didefinisikan dalam .dbc atau .arxml; alamat memori didefinisikan dalam .a2lSkrip pengujian ditulis dalam CAPL atau Python; log pengujian ada di .mdf, .data, atau .csv berkas.
2. Isolasi Rantai Alat: Para insinyur harus terus-menerus beralih konteks. Mereka berpindah dari MATLAB/Simulink (desain model) ke Vector CANoe (simulasi bus), Vector CANape atau TsMaster (kalibrasi/pengukuran), Excel (pemetaan data), dan sistem pelacak masalah berbasis web internal (Jira).
3. Inkonsistensi Semantik: Variabel fisik yang persis sama (seperti arus pengisian baterai target) mungkin diberi nama Target_Perubahan_Mata_Harga dalam spesifikasi persyaratan fungsional, bms_I_target di ruang kerja model Simulink, Arus Target BMS dalam basis data sinyal CAN DBC, dan Batas_Kurr_Perubahan_P_BMS dalam file kalibrasi A2L. File-file tersebut seringkali memiliki laju pengambilan sampel, faktor skala, satuan, dan rentang nilai valid yang berbeda.
4. Rantai Bukti yang Hilang: AI generatif dapat dengan mudah menyarankan penyebab utama hipotetis. Namun, jika saran tersebut tidak dapat menunjuk ke milidetik spesifik dalam log, transisi sinyal spesifik dalam jejak, jalur spesifik dalam model Simulink, atau ID kasus uji spesifik, maka tidak dapat diterima sebagai kesimpulan teknik..

Pertanyaannya bukanlah seberapa pintar gelar LLM itu. Pertanyaannya adalah: Di manakah posisi Agen AI dalam rantai alat MBD, bagaimana cara mengakses file, kapan diizinkan memanggil skrip, dan kapan harus berhenti untuk menyerahkan kendali kembali kepada insinyur manusia?

2. Batasan Otomatisasi Tradisional vs. Batasan Agen

Departemen perangkat lunak otomotif telah menggunakan skrip otomatis (API MATLAB, parser DBC Python, rangkaian pengujian CAPL, pipeline CI/CD Jenkins, dan makro Excel) selama beberapa dekade. Alat-alat ini sangat deterministik, dapat diulang, dan sepenuhnya dapat diaudit.

Namun, mereka memiliki biaya peralihan konteks yang tinggi. Skrip Python dapat mengurai DBC, dan skrip MATLAB dapat menjalankan pemeriksaan model, tetapi mereka tidak berbagi konteks semantik.

Matriks berikut mendefinisikan di mana skrip otomatisasi tradisional menemui jalan buntu dan di mana Agen AI harus berperan:

Artefak Teknik	Batasan Otomatisasi Tradisional	Batasan Agen AI
Simulink / Stateflow	Skrip menjalankan Pemeriksaan Aturan Desain Statis (seperti Model Advisor) dan menghasilkan laporan XML. Namun, menafsirkan laporan ini dan menghubungkan kegagalan kembali ke persyaratan sistem masih memerlukan pekerjaan manual.	Agen membaca laporan Penasihat Model dan spesifikasi asli, memetakan kegagalan, dan menghasilkan daftar masalah teknik yang diprioritaskan. tidak pernah mengedit langsung file model.
DBC / A2L / MDF	Skrip Python atau CANape dapat mengekstrak daftar sinyal, tetapi pemetaan variabel di seluruh DBC dan A2L mengharuskan para insinyur untuk memelihara tabel konversi Excel manual yang rentan.	Agen tersebut secara dinamis menyelesaikan ketidaksesuaian pemetaan semantik dengan menganalisis faktor skala, tipe data, satuan fisik, dan versi parameter kalibrasi di seluruh DBC, A2L, dan model.
CANoe / CAPL	Platform pengujian otomatis menjalankan skrip pengujian dan mengekspor laporan pengujian dalam format HTML. Namun, menemukan akar penyebab dari hasil pengujian “Gagal” memerlukan penelusuran log secara manual.	Agen memindai jejak pengujian CANoe dan file log CAPL, mengisolasi stempel waktu kegagalan yang tepat, menghubungkannya dengan kode diagnostik, dan menyusun koreksi skrip CAPL.
Spesifikasi Persyaratan	Skrip standar dapat memverifikasi apakah dokumen persyaratan memiliki bidang ID, tetapi skrip tersebut tidak dapat menilai kejelasan teks atau memetakan cakupan pengujian.	Agen tersebut mengekstrak kriteria penerimaan fungsional, mencocokkannya dengan titik uji aktual, dan menghasilkan draf matriks keterlacakan ujung-ke-ujung.
Alat Web Internal	Para insinyur harus menyalin dan menempelkan log pelacakan atau kode kesalahan diagnostik secara manual ke dalam Jira, Confluence, atau basis pengetahuan internal.	Agen tersebut menggunakan alat pencarian dan pengambilan untuk memindai basis data internal, melakukan rujukan silang terhadap log masalah historis, dan mencatat referensi bersama dengan URL sumber.

3. Arsitektur Referensi: LLM pada Lapisan Orkestrasi

Untuk menerapkan Agen AI secara aman dalam pengembangan sistem yang kritis terhadap keselamatan (seperti pipeline perangkat lunak ISO 26262 ASIL-D), LLM harus berada sepenuhnya di dalam Lapisan Orkestrasi, benar-benar terisolasi dari Siklus Eksekusi Keselamatan.

    ┌────────────────────────────────────────────────────────┐
    │                  HUMAN ENGINEER (Review)               │
    └───────────────────────────▲────────────────────────────┘
                                │
               [State / Logs]   │   [Approve / Correct]
                                │
    ┌───────────────────────────▼────────────────────────────┐
    │             LLM ORCHESTRATION LAYER (Agent)            │
    │  - Plan Formulation        - Context Assembly          │
    │  - Semantic Mapping        - Reasoning & Tool-calling  │
    └───────────────────────────┬────────────────────────────┘
                                │
            [Authorized Tool Calls] / [Structured Outputs]
                                │
    ┌───────────────────────────▼────────────────────────────┐
    │               AUDITABLE EXECUTION LAYER                │
    │  ┌───────────────────────┐   ┌───────────────────────┐  │
    │  │  Sandboxed Environment│   │   Whitelisted Tools   │  │
    │  │  - Read-Only Snapshots│   │   - MATLAB / CANoe APIs│  │
    │  │  - Isolated Browsers  │   │   - Python/CAPL Parsers│  │
    │  └───────────────────────┘   └───────────────────────┘  │
    └────────────────────────────────────────────────────────┘

Kerangka kerja seperti Cakar Terbuka mendefinisikan alat sebagai fungsi terstruktur yang dapat dipanggil oleh Agen (eksekusi, pengambilan web, pencarian lokal, pengiriman pesan). Demikian pula, Agen Hermes menggunakan sandbox lokal untuk menjalankan utilitas sistem dengan aman.

Untuk perangkat lunak otomotif, kita harus menetapkan lima batasan keamanan mutlak:

1. Pengujian Kapasitas Penyimpanan Hanya Baca (Read-Only Storage Sandboxing): Agen harus beroperasi pada snapshot baca-saja atau cabang git khusus dari ruang kerja (./snapshot proyek). Sistem ini tidak boleh memiliki akses tulis ke cabang produksi, kunci kriptografi, atau repositori dasar milik perusahaan.
2. Pemanggilan Alat yang Diizinkan: Agen tidak dapat menjalankan perintah shell mentah. Sebaliknya, ia harus berinteraksi dengan ekosistem rekayasa dengan memanggil daftar putih skrip Python atau MATLAB deterministik yang telah ditulis sebelumnya.
3. Pencatatan Batasan Eksekusi: Setiap eksekusi skrip harus berjalan dalam direktori yang ketat, memberlakukan batasan waktu eksekusi, dan secara otomatis menangkap semua stdout, stderr, kode keluar, dan hash file input. Log ini disimpan dalam jejak audit yang tidak dapat diubah.
4. Profil Browser Terisolasi: Untuk pengambilan data dari web (seperti mencari definisi standar ASAM atau memeriksa papan Jira internal), Agen harus menggunakan profil peramban khusus yang sepenuhnya terisolasi dari kredensial SSO pribadi atau perusahaan.
5. Pemisahan Penyewa Basis Pengetahuan: Saat terhubung ke basis data generasi tambahan pengambilan (RAG) yang berisi pedoman kalibrasi hak milik atau data debugging proyek sebelumnya, sistem harus menerapkan kontrol akses berbasis peran (RBAC) yang ketat untuk mencegah kebocoran IP antar pelanggan.

4. Integrasi Langkah demi Langkah: Memetakan Agen ke Rantai Alat MBD

Mari kita periksa bagaimana Agen AI mengeksekusi alur kerja MBD empat langkah yang lengkap.

Step 1: Parse Specs ──► Step 2: Scan Model ──► Step 3: Align Signals ──► Step 4: Parse Logs
 (Requirements to         (MATLAB Report         (DBC to A2L          (CANoe Trace
   Test Matrix)            Analyzer)               Mapping)             to Evidence)

Langkah 4.1: Spesifikasi Persyaratan hingga Penyusunan Matriks Pengujian

Agen tersebut menerima dokumen persyaratan (seperti file markdown atau JSON yang diekspor dari DOORS). Agen tersebut menganalisis setiap klausa fungsional untuk mengekstrak:

• Prasyarat (misalnya, Suhu Baterai < -10°C)
• Masukan aktif (seperti Colokan_Pengisian_Disetel == TRUE)
• Output sistem yang diharapkan (seperti Batas Arus Pengisian Maksimum == 15A)
• Kondisi diagnostik terkait.

Alih-alih mencoba menulis kode akhir, Agen tersebut menghasilkan output yang terstruktur. Draf Matriks Uji dalam format JSON, mendefinisikan titik validasi eksplisit untuk pengujian MIL/SIL/HIL selanjutnya.

Langkah 4.2: Verifikasi Model untuk Menerbitkan Daftar Periksa

Agen tersebut diblokir agar tidak dapat memodifikasi model Simulink (.slx) atau diagram Stateflow secara langsung. Sebaliknya, ia memanggil skrip MATLAB lokal melalui antarmuka baris perintah. Skrip pelaksana ini:

1. Membuka MATLAB dalam sesi tanpa antarmuka grafis (headless).
2. Menjalankan pemeriksa aturan desain statis khusus (seperti memeriksa konvensi penamaan atau mencari port sinyal yang tidak terhubung).
3. Mengekspor laporan diagnostik terstruktur.

Agen membaca laporan ini, mencocokkannya dengan pedoman desain perangkat lunak, dan membuat daftar periksa terstruktur yang menyoroti kesalahan (seperti “Diagram alur status Manajer Biaya “tidak memiliki jalur transisi default”).

Langkah 4.3: Pemetaan Semantik Bidang DBC, A2L, dan Kalibrasi

Langkah ini mencocokkan sinyal komunikasi fisik dengan memori pengontrol internal. Agen memanggil parser Python khusus untuk membaca CAN DBC dan file A2L pengontrol.

Kemudian, sistem ini membangun tabel pemetaan variabel terpadu dan memeriksa perbedaan yang signifikan:

[Signal: BMS_Target_I] ── (DBC Unit: Ampere | Scale: 0.1 | Offset: 0)
                                 VS
[Parameter: Target_I_Cal] ── (A2L Unit: Ampere | Scale: 0.01 | Offset: -40)
                                 ▲
                         [Agent Flags Mismatch]