Dari Hazard ke Implementasi: Peran LOPA dalam Menentukan BPCS, SIS, SIF, dan SIL pada Pabrik Petrokimia

• 1. Pendahuluan – Mengapa Risk-Driven Design Penting
• 2. Hazard Identification – Titik Awal Semua Desain
  • 2.1 Peran HAZOP
  • 2.2 Kenapa HAZOP Belum Cukup?
• 3. LOPA sebagai Kerangka Penentuan Proteksi
  • 3.1 Apa itu LOPA
  • 3.2 Struktur LOPA
  • 3.3 Apa Saja yang Bisa Menjadi IPL?
• 4. Dari LOPA ke SIL – Bagaimana Angka Ditentukan
  • 4.1 Risk Reduction Factor (RRF)
  • 4.2 Contoh Singkat – Reactor Overpressure
• 5. Masuk ke SIF – Unit Desain Functional Safety
  • 5.1 Apa itu SIF
  • 5.2 Contoh SIF Nyata di Petrokimia
    • 1. High-High Reactor Pressure Trip
    • 2. Furnace Flame Failure Trip
    • 3. Tank Overfill Shutdown
• 6. SIS – Platform untuk Menjalankan SIF
  • 6.1 Apa itu SIS
  • 6.2 Arsitektur SIS
    • Logic Solver
    • Redundant I/O
    • Voting Architecture
    • Dedicated Power
    • Fail-Safe Design
• 7. Posisi BPCS dalam Kerangka LOPA
  • 7.1 Apa itu BPCS
  • 7.2 Kapan BPCS Bisa Dianggap IPL?
    • 1. Independence
    • 2. Reliability Terbukti
    • 3. Tidak Common Cause dengan SIF
• 8. Arsitektur Final: Dari Risk ke Implementasi
  • Alur Konseptual
  • Penjelasan Sistemik per Tahap
    • 1. Hazard
    • 2. HAZOP
    • 3. LOPA
    • 4. Required SIL
    • 5. SIF Definition
    • 6. SIS Architecture
    • 7. Hardware & Implementation
• 9. Failure Scenario & Validasi
  • 1. BPCS Failure
  • 2. Sensor Drift
  • 3. Valve Stuck
  • 4. Power Failure
  • 5. Common Cause Network Failure
  • Hubungan Kembali ke LOPA
• 10. Lifecycle Functional Safety
  • Tahapan Lifecycle
    • 1. Hazard Analysis
    • 2. SIL Determination
    • 3. Safety Requirement Specification (SRS)
    • 4. Design & Verification
    • 5. FAT / SAT
    • 6. Commissioning
    • 7. Proof Testing
    • 8. Management of Change (MOC)
  • Pesan Utama Bab Ini
• 11. Kesalahan Umum di Proyek Greenfield
  • 1. Menentukan SIL sebelum LOPA
  • 2. Menggabungkan BPCS dan SIS demi biaya
  • 3. Mengabaikan Final Element Reliability
  • 4. Tidak Mengontrol Bypass Management
  • 5. Tidak Mempertimbangkan Obsolescence
• 12. Kesimpulan Artikel

1. Pendahuluan – Mengapa Risk-Driven Design Penting

Industri petrokimia beroperasi pada kondisi:

• Reaksi eksotermik tak terkendali
• Tekanan tinggi (>50–150 bar)
• Temperatur ekstrem
• Fluida mudah terbakar / toksik
• Inventori energi sangat besar

Dalam konteks ini, kegagalan kecil dapat berubah menjadi:

• Vessel rupture
• Vapor cloud explosion
• Jet fire
• Toxic release

Karena itu, desain sistem kontrol tidak boleh dimulai dari:

“PLC apa yang dipakai?”

Tetapi harus dimulai dari:

“Apa hazard-nya, dan seberapa besar risiko yang dapat diterima?”

Prinsip utama:

• Kontrol proses (BPCS) ≠ proteksi keselamatan
• Safety tidak boleh menjadi fitur tambahan
• Functional safety adalah lifecycle engineering process

Referensi standar:

• IEC 61511
• IEC 61508

2. Hazard Identification – Titik Awal Semua Desain

2.1 Peran HAZOP

HAZOP (Hazard and Operability Study) digunakan untuk:

• Mengidentifikasi deviasi (High Pressure, Low Flow, Reverse Flow, dll.)
• Menganalisis penyebab
• Menilai konsekuensi
• Mencatat existing safeguards

Struktur dasar HAZOP:

Deviation → Cause → Consequence → Safeguard → Recommendation

Contoh sederhana:

HAZOP bersifat:

• Sistematis
• Kualitatif
• Berbasis diskusi tim multidisiplin

2.2 Kenapa HAZOP Belum Cukup?

HAZOP hanya menjawab:

“Apa yang bisa salah?”

Tetapi tidak menjawab:

• Berapa frekuensinya?
• Apakah safeguard cukup?
• Berapa risk reduction yang dibutuhkan?
• Apakah perlu SIL 1, 2, atau 3?

HAZOP tidak menghasilkan angka.

Karena itu diperlukan metode kuantifikasi → LOPA.

Transisi logis:

HAZOP menghasilkan daftar skenario → LOPA mengevaluasi apakah proteksi cukup.

3. LOPA sebagai Kerangka Penentuan Proteksi

3.1 Apa itu LOPA

LOPA (Layer of Protection Analysis) adalah metode semi-kuantitatif untuk:

• Menghitung frekuensi kejadian berbahaya
• Mengevaluasi Independent Protection Layer (IPL)
• Menentukan risk reduction yang dibutuhkan

LOPA menjawab:

Apakah proteksi yang ada cukup? Jika tidak, berapa tambahan proteksi yang diperlukan?

3.2 Struktur LOPA

Urutan analisis:

1. Initiating event frequency
2. Consequence severity
3. Existing IPL
4. Required risk reduction
5. Required SIL

Bentuk umum perhitungan:

Residual Risk = Initiating Frequency ÷ (Product of IPL RRF)

Jika residual risk > tolerable risk → perlu tambahan proteksi.

3.3 Apa Saja yang Bisa Menjadi IPL?

Penekanan penting:

Tidak semua proteksi boleh dihitung sebagai IPL jika:

• Tidak independen
• Tidak dapat diaudit
• Tidak memiliki efektivitas terukur
• Response time tidak mencukupi

Contoh:

Alarm + operator action tidak boleh dihitung jika:

• Operator overload
• Tidak ada prosedur tertulis
• Waktu respons > waktu eskalasi hazard

4. Dari LOPA ke SIL – Bagaimana Angka Ditentukan

4.1 Risk Reduction Factor (RRF)

Hubungan RRF dengan SIL:

Artinya:

Jika LOPA menunjukkan kebutuhan RRF 1000 → Diperlukan SIL 3.

SIL bukan dipilih. SIL dihitung.

4.2 Contoh Singkat – Reactor Overpressure

Asumsi:

• Initiating event = 1 kali per tahun
• Target tolerable risk = 1 per 10.000 tahun
• Existing IPL hanya memberi RRF 10

Perhitungan:

Risk reduction total yang dibutuhkan = 10.000 Sudah ada 10 Masih dibutuhkan = 1000

→ Required RRF tambahan = 1000 → SIL 3

Pesan utama yang harus terkunci:

SIL muncul dari LOPA, bukan dari spesifikasi vendor atau kebiasaan proyek.

5. Masuk ke SIF – Unit Desain Functional Safety

5.1 Apa itu SIF

SIF (Safety Instrumented Function) adalah fungsi proteksi spesifik yang dirancang untuk:

1. Mendeteksi kondisi berbahaya
2. Memproses logika keselamatan
3. Membawa proses ke kondisi aman

Struktur dasar SIF:

Sensor → Logic Solver → Final Element

Karakteristik utama:

• Dirancang untuk satu skenario bahaya spesifik
• Memiliki target SIL individual
• Memiliki PFDavg yang dihitung
• Memiliki response time requirement

Penekanan penting:

SIL bukan milik PLC, SIL milik SIF.

Setiap SIF harus memiliki:

• Setpoint trip
• Safe state
• Voting logic
• Proof test interval
• Perhitungan PFDavg

Referensi praktik mengikuti IEC 61511.

5.2 Contoh SIF Nyata di Petrokimia

1. High-High Reactor Pressure Trip

• Sensor: 2oo3 pressure transmitter
• Logic: Safety PLC
• Final element: Feed valve close + heater trip
• Target: SIL 3

Tujuan: mencegah vessel rupture.

2. Furnace Flame Failure Trip

• Sensor: Flame detector
• Logic: Burner management logic
• Final element: Fuel gas isolation

Tujuan: mencegah furnace explosion.

3. Tank Overfill Shutdown

• Sensor: Independent high-high level switch
• Logic: Safety PLC
• Final element: Inlet valve close

Tujuan: mencegah hydrocarbon spill.

Penekanan kritikal:

• SIL dihitung per SIF, bukan per unit pabrik.
• Setiap SIF memiliki PFDavg sendiri.
• Final element sering menjadi kontributor terbesar terhadap PFDavg.

6. SIS – Platform untuk Menjalankan SIF

6.1 Apa itu SIS

SIS (Safety Instrumented System) adalah sistem keselamatan terintegrasi yang:

• Menjalankan satu atau lebih SIF
• Mengelola logic solver, I/O, power, dan diagnostik
• Harus independen dari BPCS

SIS adalah platform. SIF adalah fungsi di dalamnya.

6.2 Arsitektur SIS

Komponen utama:

1. Logic Solver
2. Safety I/O
3. Voting Architecture
4. Dedicated Power
5. Fail-safe Output

Logic Solver

• Certified untuk level SIL tertentu
• Deterministic scan
• Watchdog hardware

Contoh platform:

• Triconex Tricon
• S7-1500F

Redundant I/O

Digunakan untuk:

• Mengurangi dangerous undetected failure
• Mendukung arsitektur voting

Voting Architecture

Contoh:

• 1oo2 (one out of two)
• 2oo3 (two out of three)

Tujuan voting:

• Meningkatkan availability
• Mengurangi spurious trip
• Mengontrol common cause failure

Dedicated Power

• UPS terpisah
• Grounding terisolasi
• Tidak berbagi power dengan BPCS

Fail-Safe Design

Jika terjadi fault:

• Output menuju safe state
• Valve fail-close
• Motor trip

SIS tidak boleh bergantung pada:

• WAN
• Cloud
• Domain IT

7. Posisi BPCS dalam Kerangka LOPA

7.1 Apa itu BPCS

BPCS (Basic Process Control System) adalah sistem kontrol operasi normal yang menjalankan:

• PID control
• Cascade control
• Advanced Process Control (APC)
• Sequence control

Tujuan utama:

• Stabilitas proses
• Optimasi yield
• Efisiensi energi

Contoh platform industri:

• Emerson Electric
• Yokogawa
• Siemens
• Honeywell

7.2 Kapan BPCS Bisa Dianggap IPL?

BPCS dapat dihitung sebagai IPL di LOPA jika memenuhi:

1. Independence

• Sensor tidak shared dengan SIF
• Logic tidak bergantung pada SIS
• Tidak ada common power

2. Reliability Terbukti

• Data historis mendukung
• Availability tinggi
• Maintenance terkendali

3. Tidak Common Cause dengan SIF

• Tidak satu rack
• Tidak satu firmware
• Tidak satu power source

Jika tidak memenuhi → Tidak boleh dihitung sebagai IPL.

Penekanan penting:

BPCS bukan sistem keselamatan. Namun dalam LOPA, BPCS dapat menjadi salah satu layer proteksi jika independen dan terverifikasi.

8. Arsitektur Final: Dari Risk ke Implementasi

Arsitektur tidak boleh dimulai dari pemilihan PLC, panel, atau vendor. Arsitektur harus merupakan hasil turunan langsung dari analisis risiko.

Alur Konseptual

Hazard ↓ HAZOP ↓ LOPA ↓ Required SIL ↓ SIF Definition ↓ SIS Architecture ↓ Hardware & Implementation

Penjelasan Sistemik per Tahap

1. Hazard

Menentukan potensi energi berbahaya:

• Overpressure
• Runaway reaction
• Fuel gas accumulation
• Overfill hydrocarbon tank

Ini adalah sumber risiko, bukan sistem kontrol.

2. HAZOP

Menghasilkan daftar skenario deviasi. Contoh:

• High reactor pressure
• Loss of cooling
• Reverse flow

Output: daftar skenario yang akan dianalisis.

3. LOPA

Menentukan:

• Frekuensi kejadian
• Existing IPL
• Required Risk Reduction

Jika residual risk > tolerable risk → Diperlukan SIF.

4. Required SIL

Hasil numerik dari LOPA. Misal:

• Required RRF = 1000 → SIL 3

Ini adalah constraint desain.

5. SIF Definition

SIL diterjemahkan menjadi:

• Jumlah sensor (1oo2, 2oo3)
• Logic solver requirement
• Proof test interval
• Final element reliability

SIF didefinisikan dalam SRS.

6. SIS Architecture

SIF-SIF dikonsolidasikan dalam satu sistem keselamatan:

Arsitektur ditentukan oleh:

• Target SIL tertinggi
• Jumlah SIF
• Voting requirement
• Segregasi power & network

7. Hardware & Implementation

Baru pada tahap ini:

• Pemilihan safety PLC
• Desain panel
• Pemisahan tray kabel
• UPS dedicated
• Grounding scheme
• Cause & effect matrix

Pesan sistemik utama:

Jangan mulai dari PLC. Mulai dari risiko.

Jika urutan dibalik, desain menjadi vendor-driven, bukan risk-driven.

9. Failure Scenario & Validasi

Desain yang baik harus diuji terhadap kegagalan nyata.

Minimal skenario berikut harus dianalisis.

1. BPCS Failure

Contoh:

• PID runaway
• CPU DCS hang
• Network DCS collapse

Dampak:

• Proses bisa keluar dari batas aman

Validasi:

• SIS tetap bekerja tanpa ketergantungan pada BPCS
• Tidak ada shared sensor kritikal
• Tidak ada shared power

Jika BPCS dihitung sebagai IPL dalam LOPA, maka:

• Harus ada justifikasi independensi
• Jika BPCS gagal total → LOPA harus dievaluasi ulang

2. Sensor Drift

Contoh:

• Pressure transmitter reading lebih rendah dari aktual
• Impulse line tersumbat

Dampak:

• SIF tidak ter-trigger
• Dangerous undetected failure

Mitigasi:

• Voting 2oo3
• Proof test interval sesuai SIL
• Diagnostic coverage

Jika sensor gagal: Frekuensi IPL berkurang → residual risk naik.

3. Valve Stuck

Final element sering menjadi weakest link.

Contoh:

• Shutdown valve tidak menutup
• Pneumatic actuator gagal

Mitigasi:

• Partial Stroke Test
• SIL-rated solenoid
• Periodic full stroke test

Dalam LOPA: Jika valve reliability overestimated → SIL calculation tidak valid.

4. Power Failure

Contoh:

• Main MCC blackout
• UPS failure
• Ground fault

Validasi desain:

• Dedicated UPS SIS
• Fail-close valve
• Safe state on de-energize

Jika power SIS tidak independen dari BPCS: Common cause failure terjadi.

5. Common Cause Network Failure

Contoh:

• Shared switch antara BPCS dan SIS
• Firmware bug memengaruhi dua sistem
• Shared time server dependency

Validasi:

• Network zoning terpisah
• Tidak ada routing silang
• Engineering workstation terkontrol

Jika network menjadi common cause: IPL independen hilang → LOPA assumptions invalid.

Hubungan Kembali ke LOPA

LOPA mengasumsikan:

• IPL bekerja sesuai efektivitasnya
• Independensi terjaga
• Failure probability sesuai data

Jika dalam implementasi:

• Sensor tidak diuji
• Valve tidak diproof test
• Power tidak terpisah

Maka:

IPL gagal → frekuensi risiko meningkat → Perhitungan LOPA tidak lagi valid.

Artinya: Functional safety bukan hanya desain awal, tetapi validasi berkelanjutan.

10. Lifecycle Functional Safety

Mengacu pada IEC 61511, functional safety bukan aktivitas desain satu kali, tetapi lifecycle terstruktur sejak konsepsi hingga decommissioning.

Tahapan Lifecycle

1. Hazard Analysis

• HAZOP
• Identifikasi skenario berbahaya
• Penentuan tolerable risk

Output: daftar skenario kandidat LOPA.

2. SIL Determination

• LOPA
• Perhitungan Risk Reduction Factor
• Penetapan Required SIL per SIF

Output: daftar SIF + target SIL.

3. Safety Requirement Specification (SRS)

Dokumen paling kritikal.

SRS harus memuat:

• Deskripsi SIF
• Setpoint trip
• Safe state
• Response time
• Proof test interval
• Target PFDavg
• Bypass rule
• Environmental constraint

SRS adalah baseline audit.

4. Design & Verification

• Arsitektur voting
• Pemilihan sensor & valve
• PFDavg calculation
• Common cause analysis
• Independence validation

Output: desain yang memenuhi SIL target.

5. FAT / SAT

FAT (Factory Acceptance Test):

• Verifikasi logic
• Simulasi cause & effect
• Fault injection test

SAT (Site Acceptance Test):

• Loop test
• Final element functional test
• Power fail simulation

Tujuan: memastikan implementasi sesuai SRS.

6. Commissioning

• Bypass control formal
• Validasi trip aktual
• Dokumentasi baseline

7. Proof Testing

Dilakukan periodik sesuai SRS.

Tujuan:

• Mengurangi dangerous undetected failure
• Memastikan PFDavg tetap sesuai asumsi

Tanpa proof test: Perhitungan SIL menjadi tidak valid.

8. Management of Change (MOC)

Perubahan berikut wajib evaluasi ulang:

• Setpoint diubah
• Sensor diganti tipe
• Firmware update
• Penambahan shared resource
• Modifikasi logic

Jika perubahan memengaruhi IPL: LOPA harus ditinjau ulang.

Pesan Utama Bab Ini

Functional safety adalah proses 20+ tahun.

Kesalahan paling umum: Menganggap SIL selesai saat commissioning.

Padahal: SIL hanya valid jika lifecycle dijalankan konsisten.

11. Kesalahan Umum di Proyek Greenfield

Berikut pola kesalahan berulang di proyek baru.

1. Menentukan SIL sebelum LOPA

SIL ditentukan berdasarkan:

• “Biasanya reactor SIL 3”
• Permintaan owner
• Template proyek lama

Ini salah secara metodologi.

SIL harus muncul dari LOPA.

2. Menggabungkan BPCS dan SIS demi biaya

Risiko:

• Common cause failure
• Audit compliance gagal
• IPL independen hilang

Secara arsitektural: BPCS dan SIS harus terpisah secara fungsional dan, untuk unit high risk, juga secara fisik.

3. Mengabaikan Final Element Reliability

Fakta lapangan: Final element menyumbang kegagalan terbesar.

Kesalahan umum:

• Tidak ada partial stroke test
• Tidak menghitung failure rate valve
• Tidak mempertimbangkan pneumatic contamination

Jika valve reliability overestimated: SIL calculation salah.

4. Tidak Mengontrol Bypass Management

Bypass tanpa kontrol:

• SIF nonaktif tanpa pengawasan
• Durasi bypass tidak tercatat
• Operator lupa mengembalikan ke service

Bypass harus:

• Berizin formal
• Tercatat
• Time limited

5. Tidak Mempertimbangkan Obsolescence

Plant lifetime: 20–30 tahun. Platform kontrol: 10–15 tahun.

Risiko:

• Spare part tidak tersedia
• Firmware tidak didukung
• Patch keamanan tidak tersedia

Obsolescence planning harus masuk FEED.

12. Kesimpulan Artikel

Rangkaian logika artikel ini bersifat sistemik dan tidak boleh dibalik.

1. Semua dimulai dari hazard.
2. LOPA menentukan kebutuhan risk reduction.
3. Risk reduction menentukan SIL.
4. SIL menentukan SIF.
5. SIF dijalankan oleh SIS.
6. BPCS adalah layer operasional, bukan safety utama.
7. Desain harus risk-driven, bukan vendor-driven.

Jika urutan dibalik:

• SIL menjadi asumsi.
• SIF menjadi formalitas.
• SIS menjadi fitur PLC.
• Safety menjadi klaim, bukan hasil rekayasa.

Functional safety yang benar:

Hazard → Analisis → Kuantifikasi → Spesifikasi → Desain → Validasi → Operasi → Revalidasi.