Belajar Firmware Engineer - Safety & MISRA

#Pendahuluan

Setelah di episode 18–19 firmware kita aman dari serangan, pada episode ini kita menghadapi ancaman yang berbeda: kegagalan biasa yang berakibat fatal. Di domain otomotif, medis, dan industri, bug yang "hanya" menyebabkan crash bukan sekadar gangguan — ia bisa melukai atau membunuh. Untuk domain ini, kode harus mengikuti standar yang bisa disertifikasi.

Mengapa MISRA penting? MISRA C adalah standar praktik kode C untuk sistem kritis — dirancang untuk menghilangkan konstruksi yang ambigu, tidak terdefinisi, atau rawan kesalahan dari bahasa C. Ia bukan "saran gaya" tapi aturan yang bisa diverifikasi otomatis, dan di banyak industri wajib. Episode ini memberi kalian kacamata yang sama dengan auditor sertifikasi.

#MISRA C:2012

MISRA C (Motor Industry Software Reliability Association) adalah kumpulan aturan penulisan C untuk sistem safety-critical. Edisi 2012 dibagi ke beberapa kategori:

Contoh aturan yang wajib diketahui:

/* Rule 10.1 (Required): operasi antara tipe bertanda & tak bertanda
   harus dikonversi eksplisit */
uint32_t x = u32a + (uint32_t)u16b;   // OK: cast eksplisit
uint32_t y = u32a + u16b;             // Violation (implisit)
 
/* Rule 10.3 (Required): jangan assign nilai bertanda ke unsigned */
uint32_t z = (uint32_t)(-1);          // Violation tanpa alasan
 
/* Rule 15.1 (Mandatory): tidak ada goto */
/* Rule 16.x: switch harus punya default, break di tiap case */

Inti MISRA: hapus ketidakjelasan bahasa C. Hampir semua aturannya adalah konversi eksplisit, tidak ada UB, dan kontrol alur yang ketat — karena alat static analysis bisa memeriksanya secara otomatis.

#Functional Safety: IEC 61508 dan ISO 26262

Functional safety = keamanan yang dijamin secara sistematis, bukan berdasarkan keberuntungan. Dua kerangka utama:

Semakin tinggi level (SIL 4 / ASIL D), semakin ketat proses: hazard analysis, desain redundansi, pengujian terdokumentasi, dan justifikasi setiap pelanggaran aturan (deviation).

Airbag ECU      : ASIL D - kegagalan = cedera parah -> ketat
Infotainment    : ASIL A - gangguan -> standar lebih longgar

Pemetaan SIL/ASIL dilakukan dari hazard analysis (seberapa parah, seberapa mungkin, seberapa terkendali). Di sinilah kolaborasi sistem engineer dan firmware engineer terjadi.

#Proses dan Tooling

Keamanan fungsional bukan cuma soal aturan — ini proses terdokumentasi:

Tool yang dipakai industri:

• Static analysis: Coverity, Polyspace, PC-lint, QAC — memeriksa aturan MISRA secara otomatis.
• Coverage: branch/condition coverage wajib untuk level tinggi (MC/DC untuk ASIL D).
• RTOS terverifikasi: FreeRTOS Safety Manual, atau RTOS bersertifikat (SafeRTOS, ThreadX).

#Praktik: Review ala MISRA

Lakukan review MISRA pada kode kalian. Contoh kasus nyata:

void set_speed(int speed) {
    if (speed < 0) speed = 0;        // magic number
    uint16_t reg = speed * 2 + 5;    // int -> uint16 implisit
    switch (speed % 4) {
        case 1: reg++; break;        // dll...
        // tidak ada default
    }
    sensor_set(reg);
}

#define SPEED_MIN 0
#define SPEED_MAX 100
 
void set_speed(int32_t speed) {
    if (speed < SPEED_MIN) { speed = SPEED_MIN; }
    if (speed > SPEED_MAX) { speed = SPEED_MAX; }
 
    uint32_t reg = (uint32_t)speed * 2U + 5U;   // cast eksplisit
    switch ((uint32_t)speed % 4U) {
        case 0U: ... break;
        case 1U: ... break;
        default: break;                          // wajib default
    }
    sensor_set((uint16_t)reg);                  // cast eksplisit
}

Perhatikan polanya: batas eksplisit, cast eksplisit, default di switch, konstanta dinamai. Review MISRA bukan "mempercantik kode" — tiap perubahannya menghilangkan satu kelas bug.

#Kesalahan Umum Safety

1. MISRA dipakai setelah kode jadi — hasilnya massal deviation; terapkan sejak awal.
2. Menyalin peraturan tanpa konteks — pahami mengapa tiap rule ada.
3. Mengabaikan deviation process — level tinggi menuntut dokumentasi, bukan kode "bagus".
4. Mengandalkan test manual — bukti otomatis (coverage, static analysis) wajib.
5. Redundansi tanpa hazard analysis — duplikasi bukan otomatis lebih aman.
6. RTOS/toolchain tanpa safety case — gunakan versi dengan safety manual.

#Penutup

Inti yang harus dibawa pulang:

• MISRA C:2012 menghilangkan konstruksi C yang ambigu/berbahaya; wajib di sistem kritis.
• Kategori: Directive, Mandatory, Required, Advisory — diverifikasi alat, bukan hafalan.
• Functional safety: IEC 61508 (SIL), ISO 26262 (ASIL) — semakin tinggi level, semakin ketat proses.
• Tooling: static analysis, coverage MC/DC, RTOS bersertifikat, dan deviation document.
• Review MISRA: cast eksplisit, batas jelas, default di switch, konstanta bernama.

Di episode 21 selanjutnya kita menaruh AI di dalam chip: TinyML Firmware — inferensi edge di MCU, kuantisasi, dan deployment model ke perangkat. Perangkat kalian akan mulai berpikir!