Belajar Embedded Engineer - Automotive & Industrial Embedded

#Pendahuluan

Episode 19 dan 20 memperkenalkan safety dan ASIL; episode ini membawa kalian ke tempat di mana keduanya dipakai setiap hari: industri otomotif dan industri pabrik. Satu mobil modern berisi 100+ ECU yang saling berbicara lewat CAN bus; satu lini produksi berisi PLC dan sensor yang berkomunikasi lewat protokol industri seperti Modbus, EtherCAT, dan Profinet.

Dunia ini tidak menoleransi "cukup jalan" — semua protokol dibangun di atas fondasi determinisme (episode 14) dan safety (episode 19). Episode ini membangun fondasi: apa itu CAN, bagaimana frame-nya dibentuk, apa itu AUTOSAR, dan bagaimana protokol industri diorganisasi.

#CAN Bus: Bahasa Mobil Modern

CAN (Controller Area Network) adalah bus serial yang dirancang Bosch pada 1980-an untuk otomotif — dan kini juga dominan di industri. Keunggulannya:

1. Dua kabel, banyak node — semua ECU (engine, ABS, airbag, dashboard) terhubung di satu bus.
2. Robust — diferensial signaling, error detection built-in, resistan terhadap interferensi.
3. Prioritas berbasis arbitrase — frame berprioritas lebih rendah otomatis menunggu saat dua node mengirim bersamaan.
4. Kecepatan — klasik 125 kbps-1 Mbps (CAN 2.0), hingga beberapa Mbps (CAN FD).

Konsep penting: CAN bukan "satu node adalah master". Semua node bisa mengirim kapan saja; arbitrase memastikan hanya satu yang menang — berdasar ID frame (semakin kecil ID, semakin tinggi prioritas). Inilah mengapa ID harus dipilih hati-hati: ID kecil untuk data kritis waktu (ABS), ID besar untuk telemetri santai.

#Struktur Frame CAN

Frame CAN memiliki bagian-bagian yang wajib dipahami:

| SOF | ArbID (11-bit) | RTR | IDE | r0 | DLC (4-bit) | Data (0-8 byte) | CRC | ACK | EOF |

Bagian yang paling sering menentukan desain:

• Arbitration ID (ArbID) — identitas pesan sekaligus prioritas.
• DLC — jumlah byte data (0-8 untuk CAN 2.0; hingga 64 untuk CAN FD).
• Data — payload; sering berisi sinyal ter-pack (bit-field) — efisien, tapi butuh dokumentasi "DBC file" untuk mendekode.
• CRC + ACK — deteksi error dan konfirmasi penerimaan.

Contoh mengirim frame dengan library CAN (misal MCP2515 atau CAN transceiver + STM32 bxCAN):

CanTxMsgTypeDef frame;
frame.StdId = 0x123;          /* ArbID: prioritas + identitas pesan */
frame.IDE   = CAN_ID_STD;
frame.RTR   = CAN_RTR_DATA;
frame.DLC   = 4;              /* 4 byte data */
frame.Data[0] = (sensor_value >> 8) & 0xFF;
frame.Data[1] = sensor_value & 0xFF;
frame.Data[2] = 0x00;
frame.Data[3] = checksum8(sensor_value);
 
HAL_CAN_AddTxMessage(&hcan, &frame, &tx_mailbox);

Perhatikan packing manual: nilai 16-bit dipecah menjadi byte dan dirangkai — inilah kenapa seluruh proyek CAN nyata punya DBC file (Database CAN) yang mendefinisikan setiap sinyal dan bit-nya. Tanpa DBC, data antar vendor adalah teka-teki.

#AUTOSAR: Standar Arsitektur ECU

AUTOSAR (AUTomotive Open System ARchitecture) adalah standar arsitektur software untuk ECU otomotif — kolaborasi pabrikan dan supplier besar. Tujuannya: membuat software ECU portabel dan dapat dipakai ulang antar vendor dan platform.

Lapisan arsitektur AUTOSAR Classic (untuk MCU) yang harus dikenal:

Manfaat praktisnya: tim aplikasi menulis terhadap antarmuka standar (RTE), bukan register chip tertentu. Supplier menyediakan BSW yang tersertifikasi. Kerugiannya: kompleksitas dan lisensi tinggi — inilah kenapa AUTOSAR hanya masuk akal untuk proyek besar.

Di sisi modern, AUTOSAR Adaptive (untuk SoC/Linux, POSIX, C++) menangani aplikasi dengan kebutuhan resource besar — layanan, komunikasi IP, dan update OTA yang dibahas di episode 17.

#Protokol Industri: Modbus, EtherCAT, dan Lainnya

Di dunia pabrik, lanskap protokolnya berbeda dari otomotif. Tiga yang paling sering ditemui:

Pola desainnya seragam: protocol framing, addressing, error handling, dan timing budget. Kemampuan membaca spesifikasi protokol dan mengimplementasikan lapisan dasar dengan benar adalah skill yang membuat kalian berguna di banyak proyek industri.

#Praktik: Komunikasi CAN Pertama

1. Siapkan board + transceiver CAN (misal MCP25625 + Arduino, atau board STM32 dengan CAN).
2. Buat dua node: node A mengirim frame ID 0x100 berisi nilai ADC, node B menerima dan menampilkan.
3. Tambahkan node ketiga dengan ID lebih kecil (0x010) yang mengirim lebih sering — amati arbitrase bekerja (node 0x100 menunggu).
4. Rusak satu kabel bus — amati error handling dan pemulihan bus.
5. (Lanjutan) Buat DBC sederhana untuk frame kalian dan dekode data dengan tool seperti can-utils (candump, cansend).

#Common Pitfalls

1. Terminasi bus salah — CAN wajib resistor 120Ω di kedua ujung; tanpa itu komunikasi tidak stabil.
2. ArbID tidak direncanakan — prioritas salah; data kritis menunggu data santai.
3. Packing manual tanpa dokumentasi — data tidak bisa didekode tim lain.
4. Tidak menangani bus-off — node yang sering error di-bus-off; butuh recovery logic.
5. DLC salah — frame tidak cocok dengan konsumen; komunikasi diam-diam gagal.

#Penutup

Inti yang harus dibawa pulang:

• CAN adalah bus robust multi-node dengan arbitrase prioritas dan deteksi error bawaan.
• Frame CAN = ArbID + DLC + Data + CRC/ACK; data ter-pack di dokumentasikan lewat DBC.
• AUTOSAR (Classic + Adaptive) menyeragamkan software ECU agar portabel antar vendor.
• Industri memakai Modbus, EtherCAT, Profinet, OPC UA — anatomi protokolnya sama, budaya safety-nya wajib.
• Praktik: bangun 2-3 node CAN, amati arbitrase, dan dokumentasikan dengan DBC.

Di episode 24 selanjutnya kita melompat ke kelas perangkat keras yang lebih dalam: SoC & FPGA basics — memahami Zynq, dasar Verilog/VHDL, dan mendesain logika sendiri, dengan praktik blink FPGA pertama. Dari sini kalian melihat bahwa "embedded" tidak berhenti di menulis C. Sampai jumpa di episode 24!