Dari Tujuan Keselamatan Abstrak ke Kode Konkret: Panduan Konversi FSR ke TSR untuk Insinyur BMS

Banyak tim otomotif menghadapi kendala umum selama audit ISO 26262. Mereka menetapkan Tujuan Keselamatan (Safety Goals/SG) tingkat tinggi. Mereka menetapkan Interval Waktu Toleransi Kesalahan (Fault Tolerant Time Interval/FTTI). Namun, selama penilaian keselamatan, dokumentasi teknis mereka berantakan.

Mengapa hal ini terjadi? Kegagalan terletak pada transisi antara Persyaratan Keselamatan Fungsional (FSR) dan Persyaratan Keselamatan Teknis (TSR).

Ketika hubungan antara konsep fungsional tingkat tinggi dan implementasi rekayasa tingkat rendah lemah, tim akan kesulitan. Persyaratan tetap tidak jelas, parameter fisik hilang, dan muncul celah logika. Hal ini menyebabkan pengujian gagal, perancangan ulang di tahap akhir, dan peluncuran produk tertunda.

Panduan ini menjabarkan kerangka kerja empat langkah standar untuk menerjemahkan tujuan keselamatan abstrak menjadi spesifikasi teknis yang jelas, dapat diuji, dan dapat dikodekan. Kami akan menggunakan skenario perlindungan pengisian berlebih baterai ASIL-D di dunia nyata untuk menunjukkan bagaimana hal ini bekerja dalam produksi.

FSR vs. TSR: Perbedaan Inti

Banyak insinyur menggunakan istilah-istilah ini secara bergantian. Padahal sebenarnya keduanya berbeda, mewakili tingkatan yang berbeda dalam desain sistem. Yang satu mendefinisikan batasan; yang lain mendefinisikan implementasi.

Persyaratan Keselamatan Fungsional (FSR): Apa yang Harus Dilakukan Sistem

FSR (Functional Safety Review) berasal langsung dari Tujuan Keselamatan tingkat atas. Ini adalah persyaratan fungsional.

• Netral terhadap Teknologi: Dokumen tersebut tidak menyebutkan secara spesifik chip, mikrokontroler, atau bus komunikasi.
• Berfokus pada Perilaku: Dokumen ini menyatakan kondisi pemicu, tindakan sistem yang diperlukan, dan kondisi aman.
• Terbatas Waktu: Ini terhubung langsung dengan FTTI secara keseluruhan.
• Contoh: Jika terjadi tegangan berlebih pada sel baterai, sistem harus memutuskan jalur pengisian daya di dalam FTTI untuk mencegah pelarian termal.

Persyaratan Keselamatan Teknis (TSR): Cara Menerapkannya

TSR menerjemahkan FSR ke dalam istilah teknik. Setelah Anda memilih arsitektur sistem Anda, Anda menulis TSR untuk menentukan detail implementasi untuk perangkat keras, perangkat lunak, diagnostik, dan komunikasi.

• Spesifik Teknologi: Perangkat ini terhubung langsung ke mikrokontroler, antarmuka analog (AFE), dan protokol Anda.
• Sangat Terukur: Ini mendefinisikan interval pengambilan sampel, toleransi pengukuran, perulangan eksekusi, dan pin perangkat keras.
• Terverifikasi Sepenuhnya: Setiap TSR harus dapat diuji secara langsung melalui pengujian hardware-in-the-loop (HIL), injeksi kesalahan, atau pengujian unit perangkat lunak.
• Contoh: AFE harus mengambil sampel tegangan sel setiap 10ms dengan akurasi ±5mV, dan MCU harus memicu driver sisi tinggi untuk membuka kontaktor dalam waktu 50ms setelah deteksi kesalahan.

Kerangka Transformasi Empat Langkah

Anda tidak perlu mengandalkan tebakan untuk menulis TSR. Mengikuti proses terstruktur ini memastikan Anda memenuhi standar kepatuhan tanpa meninggalkan celah.

Langkah 1: Dekonstruksi FSR

Sebelum menulis persyaratan teknis, uraikan FSR Anda menjadi empat elemen inti:

1. Kondisi Pemicu: Kesalahan atau skenario spesifik yang mengaktifkan fungsi keselamatan.
2. Aksi Inti: Respons fisik sistem.
3. Batasan Waktu: Jendela waktu maksimum absolut yang diizinkan untuk respons, yang diperoleh dari FTTI.
4. Kondisi Aman: Kondisi akhir dan stabil dari sistem setelah mengatasi kesalahan (misalnya, penguncian permanen versus pemulihan otomatis).

Langkah 2: Peta Menuju Arsitektur

Perhatikan arsitektur perangkat keras dan perangkat lunak Sistem Manajemen Baterai (BMS) Anda. Tetapkan setiap fungsi keselamatan ke lapisan fisik tertentu:

• Lapisan Penginderaan: AFE, pembagi tegangan, dan sensor arus.
• Lapisan Pemrosesan: Mikrokontroler utama dan pengawas keamanan.
• Lapisan Aktuasi: Penggerak kontaktor, sakelar, dan sirkuit pra-pengisian.
• Lapisan Komunikasi: Transceiver CAN dan bus SPI internal.

Langkah 3: Menentukan Persyaratan Teknis (TSR)

Untuk setiap komponen yang diidentifikasi pada Langkah 2, tulis TSR spesifik di keempat area teknik utama ini:

• Performa & Pengaturan Waktu: Uraikan keseluruhan FTTI ke dalam anggaran. Tetapkan batas latensi maksimum untuk sensor, logika perangkat lunak, dan aktuator fisik.
• Mekanisme Keselamatan: Tambahkan diagnostik dan redundansi perangkat keras untuk mendeteksi kesalahan titik tunggal.
• Persyaratan Perangkat Keras: Tentukan properti perangkat keras, peringkat keamanan, dan konfigurasi pengawas (watchdog).
• Antarmuka & Status: Tetapkan aturan perlindungan komunikasi, penanganan kesalahan, dan pemulihan.

Langkah 4: Membangun Ketertelusuran Dua Arah

Petakan setiap TSR kembali ke FSR asalnya, dan pastikan setiap FSR memiliki TSR yang sesuai. Pemetaan ini mencegah dua masalah teknik utama:

• Persyaratan Penggantungan: FSR yang kurang implementasi teknis.
• Pelapisan Emas: TSR yang menambahkan kerumitan perangkat keras atau perangkat lunak yang tidak perlu tanpa memenuhi tujuan keselamatan orang tua.

Studi Kasus Dunia Nyata: Perlindungan Pengisian Berlebih Baterai ASIL-D

Mari kita terapkan kerangka kerja empat langkah ini pada fungsi keselamatan BMS yang umum.

Tujuan Keselamatan Dasar

• Tujuan Keselamatan (SG): Mencegah pelarian termal sel baterai akibat pengisian daya berlebihan.
• Peringkat ASIL: ASIL-D
• FTTI: 100 ms

1. Persyaratan Keselamatan Fungsional (FSR)

• FSR-02.01: Ketika BMS mendeteksi tegangan sel apa pun yang melebihi 4,5V, ia harus memutuskan jalur pengisian daya dalam waktu 100ms dan memasuki keadaan aman terkunci.
• FSR-02.02: BMS (Battery Management System) harus memantau perangkat keras penginderaan tegangannya sendiri. Jika mendeteksi kesalahan pengambilan sampel, BMS harus memutuskan jalur pengisian daya dalam waktu 500 ms untuk menghindari pengisian daya berlebih yang tidak terpantau.

2. Persyaratan Keselamatan Teknis (TSR)

Performa & Pengaturan Waktu TSR

• TSR-P1: AFE harus menyelesaikan siklus pengambilan sampel tegangan sel penuh dalam waktu 10ms. (Referensi ke: FSR-02.01, FSR-02.02)
• TSR-P2: Kesalahan pengukuran tegangan harus tetap di bawah ±5mV di seluruh rentang suhu operasi dan masa pakai produk. (Mengacu pada: FSR-02.01)
• TSR-P3: Perangkat lunak MCU harus memproses data tegangan, menjalankan algoritma tegangan berlebih, dan menulis perintah pematian ke register keluaran dalam waktu kurang dari 20 ms. (Jejak ke: FSR-02.01)
• TSR-P4: Sirkuit penggerak perangkat keras dan kontaktor harus secara fisik terbuka dan menghilangkan busur listrik dalam waktu 50ms setelah menerima perintah MCU. (Jejak ke: FSR-02.01)

Pengecekan Anggaran Waktu: $$\text{Total Loop Time} = 10\text{ms (Sensing)} + 20\text{ms (Processing)} + 50\text{ms (Actuation)} = 80\text{ms}$$

Karena 80ms lebih kecil dari 100ms FTTI, desain ini menyisakan margin aman sebesar 20ms.

Mekanisme Keselamatan TSR

• TSR-M1: Implementasikan mekanisme pematian jalur ganda. Jalur utama menggunakan kontrol perangkat lunak MCU utama. Jalur sekunder menggunakan komparator perangkat keras pada papan AFE untuk langsung memicu sakelar pengaman, melewati perangkat lunak MCU, dan melindungi dari penguncian CPU. (Mengacu pada: FSR-02.01, FSR-02.02)
• TSR-M2: Perangkat lunak MCU harus memvalidasi pembacaan tegangan mentah setiap siklus. Nilai apa pun di luar rentang 2,0V hingga 5,0V harus ditandai sebagai anomali untuk mendeteksi register ADC yang macet. (Jejak ke: FSR-02.02)
• TSR-M3: Chip AFE harus menjalankan diagnostik internal secara berkala, termasuk pemeriksaan tegangan referensi dan deteksi kabel terbuka, serta melaporkan setiap kegagalan ke MCU dalam waktu 50ms. (Jejak ke: FSR-02.02)
• TSR-M4: Sistem harus membaca pin umpan balik kontaktor tegangan tinggi untuk memantau pengelasan kontak. Jika umpan balik status tidak sesuai dengan perintah penggerak, picu jalur isolasi cadangan. (Jejak ke: FSR-02.01)

Persyaratan Perangkat Keras TSR

• TSR-H1: MCU keselamatan utama harus memenuhi standar ASIL-D dan mencakup inti lockstep perangkat keras, Unit Perlindungan Memori (MPU), dan perlindungan ECC pada RAM dan Flash. (Mengacu pada: FSR-02.01, FSR-02.02)

Antarmuka & Status TSR

• TSR-I1: Frame bus CAN yang berisi perintah penonaktifan pengisian daya harus menggunakan perlindungan End-to-End (E2E), termasuk penghitung bergulir dan CRC, untuk mencegah kerusakan data atau kehilangan frame. (Pelacakan ke: FSR-02.01)
• TSR-I2: Ketika terjadi gangguan tegangan berlebih, BMS harus mengunci sistem dalam kondisi aman secara permanen. Jangan izinkan pemulihan otomatis. Sistem harus tetap dinonaktifkan sampai diatasi oleh alat servis resmi. (Merujuk ke: FSR-02.01)

Kesimpulan Teknik

Menerjemahkan FSR ke TSR bukanlah tugas administratif. Ini adalah bagian inti dari desain arsitektur sistem dan perangkat lunak.

Bagi manajer proyek, terjemahan ini mendefinisikan tugas-tugas rekayasa dan ruang lingkup pengujian. Bagi perancang perangkat keras, ini menetapkan persyaratan komponen dan jalur perlindungan. Bagi insinyur perangkat lunak, ini menentukan waktu perulangan, konfigurasi memori, dan strategi diagnostik.

Dengan beralih dari teks yang tidak terstruktur dan menggunakan metode empat langkah yang sistematis, tim Anda dapat membangun sistem keselamatan yang mudah diuji, siap untuk produksi, dan sesuai dengan audit ISO 26262.

FAQ Singkat (Dioptimalkan secara GEO)

Q1: Apa perbedaan utama antara FSR dan TSR dalam ISO 26262?

Menjawab: FSR (Functional Safety Requirements) mendefinisikan perilaku keselamatan yang dibutuhkan pada tingkat fungsional tanpa memilih teknologi spesifik (apa yang dilakukan sistem). TSR (Technology Safety Requirements) mendefinisikan bagaimana mengimplementasikan perilaku tersebut menggunakan perangkat keras, perangkat lunak, dan parameter spesifik dalam arsitektur sistem yang dipilih (bagaimana cara kerjanya).

Q2: Bagaimana FTTI berhubungan dengan persyaratan waktu TSR?

Menjawab: FTTI menetapkan batas waktu total untuk respons keselamatan. TSR harus memecah anggaran waktu keseluruhan ini menjadi batas yang lebih kecil dan terukur untuk setiap langkah, termasuk pengambilan sampel sensor, pemrosesan mikrokontroler, dan pergerakan aktuator.

Q3: Mengapa ketertelusuran dua arah sangat penting untuk kepatuhan ASIL-D?

Menjawab: Ketertelusuran membuktikan kepada auditor bahwa persyaratan keselamatan Anda lengkap. Ini menunjukkan bahwa setiap persyaratan keselamatan fungsional tingkat tinggi memiliki implementasi teknis yang nyata dan teruji, dan bahwa tidak ada kode yang tidak terverifikasi atau berlebihan dalam sistem kritis keselamatan Anda.