Cara Menulis Safety Logic SIL-3 pada Sistem PLC

SIL-3 safety logic merupakan bagian dari implementasi functional safety pada sistem kontrol yang memiliki tuntutan integritas keselamatan tinggi. Pada aplikasi industri, terutama proses, logika keselamatan tidak boleh dipandang hanya sebagai program PLC biasa yang dibuat lebih kompleks.

Perancangan SIL-3 dimulai jauh sebelum programmer menulis ladder logic, function block, atau structured text. Arsitektur sistem, Safety Requirement Specification (SRS), analisis risiko, hardware, diagnostic coverage, fault handling, application software, testing, validation, dan management of change semuanya menjadi bagian dari safety lifecycle. Untuk process industry, IEC 61511 menetapkan persyaratan specification, design, installation, operation, maintenance, serta application programming untuk Safety Instrumented System (SIS).

Karena itu, pemrograman SIL-3 sebaiknya dipahami sebagai proses menerjemahkan persyaratan safety yang sudah ditetapkan ke dalam deterministic safety logic, bukan sebagai aktivitas membuat algoritma PLC yang lebih rumit.

Apa Itu SIL-3 pada Safety PLC?

Safety Integrity Level (SIL) 3 adalah salah satu level integritas keselamatan dalam kerangka functional safety IEC 61508. Dalam aplikasi process industry, IEC 61511 menjadi standar sektor yang mengatur penerapan functional safety pada SIS.

SIL tidak ditentukan hanya berdasarkan jenis PLC atau jumlah sensor. Target SIL berkaitan dengan kemampuan safety function mencapai dan mempertahankan kondisi aman dengan tingkat probabilitas kegagalan yang sesuai dengan target yang telah ditetapkan.

Karena itu, sebuah sistem tidak otomatis menjadi SIL-3 hanya karena menggunakan:

• Safety PLC
• Redundant CPU
• Tiga sensor
• Voting logic 2oo3
• Certified component

Semua elemen tersebut harus menjadi bagian dari safety architecture yang tervalidasi.

SIL-3 Bukan Sekadar SIL-2 dengan Lebih Banyak Redundansi

Salah satu kesalahpahaman yang sering terjadi adalah menganggap SIL-3 sebagai SIL-2 yang diberi satu sensor tambahan atau satu CPU tambahan.

Padahal, peningkatan integritas keselamatan melibatkan banyak aspek.

Di antaranya:

• Hardware architecture
• Hardware fault tolerance
• Diagnostic coverage
• Probability of dangerous failure
• Common-cause failure
• Systematic capability
• Safety software
• Verification and validation
• Proof testing
• Fault response

IEC 61508 secara khusus mengatur software safety-related melalui IEC 61508-3, termasuk safety lifecycle, specification, design, validation, modification, dan penggunaan development tools.

Apakah SIL-3 Harus Menggunakan 2oo3?

Tidak selalu.

Arsitektur 2oo3 (Two-out-of-Three) memang merupakan salah satu pendekatan voting yang populer untuk redundant safety instrumentation, tetapi tidak dapat dinyatakan sebagai arsitektur minimum yang diwajibkan untuk semua SIL-3.

Pemilihan arsitektur harus didasarkan pada safety requirements dan hasil analisis hardware serta reliability.

Contoh arsitektur yang dapat ditemui pada sistem safety antara lain:

• 1oo1
• 1oo2
• 2oo2
• 2oo3

Setiap arsitektur memiliki karakteristik yang berbeda terhadap:

• Dangerous failure
• Spurious trip
• Fault tolerance
• Diagnostic coverage
• Availability
• Common-cause failure

Karena itu, engineer tidak boleh menentukan voting architecture hanya berdasarkan label “SIL-3”.

Contoh konsep 2oo3

Pada sistem 2oo3 terdapat tiga channel pengukuran:

Sensor A
Sensor B
Sensor C

Kemudian sistem menggunakan voting logic:

2 dari 3 channel setuju → Safety action

Arsitektur seperti ini dapat membantu meningkatkan fault tolerance sekaligus mempertahankan availability, tetapi kelayakannya tetap harus dibuktikan melalui safety analysis dan perhitungan yang sesuai.

Mengapa Redundant Sensor Digunakan?

Redundansi memungkinkan safety system melakukan perbandingan antar-sumber data.

Misalnya terdapat tiga pressure transmitter yang mengukur pressure vessel yang sama.

Ketika:

• Sensor A = 10 bar
• Sensor B = 10,1 bar
• Sensor C = 10 bar

sistem dapat menganggap ketiga pengukuran konsisten.

Namun apabila:

• Sensor A = 10 bar
• Sensor B = 10,1 bar
• Sensor C = 18 bar

muncul indikasi channel disagreement.

Logic kemudian dapat menentukan tindakan berdasarkan SRS, diagnostic strategy, voting architecture, dan kondisi proses.

Inilah alasan redundancy harus disertai diagnostics. Menambah sensor tanpa kemampuan mendeteksi kegagalan tidak otomatis menghasilkan safety integrity yang lebih tinggi.

Mengapa Output Feedback Penting?

Safety function tidak berhenti ketika PLC mengirimkan command.

Misalnya safety logic memberikan perintah:

TRIP → Close Shutdown Valve

Sistem seharusnya, sesuai SRS, dapat memiliki mekanisme untuk mengetahui apakah final element benar-benar mencapai safe state.

Feedback dapat berasal dari:

• Valve limit switch
• Position feedback
• Contactor feedback
• Motor feedback
• Auxiliary contact
• Pressure response

Konsepnya:

Safety Command → Final Element → Feedback → Diagnostic

Dengan pendekatan tersebut, PLC tidak hanya mengetahui bahwa command telah dikeluarkan, tetapi juga dapat mendeteksi kondisi ketika final element gagal merespons sesuai yang dipersyaratkan.

Bagaimana SIL-3 Menangani Fault?

Safety logic harus memiliki respons yang jelas terhadap kondisi fault.

Contohnya:

Normal Input → Continue Operation

Invalid Input → Diagnostic

Detected Dangerous Fault → Defined Safety Response

Respons aktual harus mengikuti SRS dan safety architecture.

Tidak semua diagnostic fault harus selalu menyebabkan shutdown pada setiap sistem SIL-3. Keputusan tersebut bergantung pada safety function, diagnostic strategy, process design, dan requirements yang ditetapkan.

Yang penting adalah setiap fault yang relevan memiliki respons yang telah didefinisikan dan diverifikasi, bukan dibiarkan menghasilkan kondisi ambigu.

Safety Requirement Specification sebagai Acuan Utama

Programmer tidak seharusnya menentukan sendiri bagaimana safety function berperilaku hanya berdasarkan preferensi pemrograman.

Sumber utama implementasi adalah Safety Requirement Specification (SRS).

SRS dapat menetapkan hal-hal seperti:

• Initiating condition
• Trip setpoint
• Voting logic
• Safe state
• Response time
• Diagnostic requirements
• Reset philosophy
• Bypass requirements
• Restart conditions
• Final element behavior
• Proof-test requirements

IEC 61511 secara eksplisit mencakup identification of functional requirements dan safety integrity requirements untuk SIF serta lifecycle requirements untuk architecture, hardware configuration, application programming, dan system integration.

Prinsip Menulis SIL-3 Safety Logic

Setelah safety architecture dan SRS ditetapkan, programmer menerjemahkannya ke dalam application logic.

Beberapa prinsip penting adalah sebagai berikut.

Gunakan Safety PLC dan Safety Components yang Sesuai

Hardware yang digunakan harus sesuai dengan safety architecture dan target SIL.

Safety PLC, safety I/O, communication path, firmware, dan associated components harus dipilih berdasarkan certification dan manufacturer safety manual yang relevan.

Istilah seperti “TÜV-approved firmware” sebaiknya tidak digunakan secara umum sebagai satu-satunya kriteria. Yang penting adalah kesesuaian produk dan konfigurasi terhadap certified safety concept.

TÜV dan lembaga independen lainnya memang melakukan product assessment dan certification berdasarkan standar functional safety seperti IEC 61508.

Pisahkan Safety Logic dari Standard Control Logic

Safety function perlu memiliki pemisahan yang jelas dari standard control sesuai architecture yang telah disertifikasi.

Tujuannya adalah mengendalikan kemungkinan systematic interference dan memastikan safety function tidak bergantung pada logika kontrol yang tidak relevan terhadap safety.

Bentuk implementasinya bergantung pada platform PLC dan safety architecture yang digunakan.

Hindari Kondisi yang Tidak Terdefinisi

Setiap kemungkinan input atau state yang relevan harus mempunyai perilaku yang jelas.

Misalnya:

• Valid input
• Invalid input
• Sensor failure
• Communication failure
• Diagnostic failure
• Initialization
• Reset
• Restart
• Bypass
• Maintenance state

Program tidak boleh bergantung pada asumsi bahwa semua input selalu valid.

Gunakan Logic yang Deterministik

Safety software harus memiliki perilaku yang dapat diprediksi.

Perhatian khusus diberikan pada:

• Scan execution
• Timing
• State transition
• Watchdog behavior
• Data validity
• Communication status
• Fault response

Tujuannya adalah memastikan safety function tidak berubah perilakunya karena state tersembunyi atau dependency yang tidak terkontrol.

IEC 61508-3 memasukkan persyaratan software lifecycle dan teknik untuk menghindari serta mengendalikan fault dan failure pada safety-related software.

Contoh Struktur Logic SIL-3

Contoh konseptual sebuah safety function:

Pressure Sensor A
↓
Pressure Sensor B
↓
Pressure Sensor C
↓
Input Diagnostics
↓
Voting Logic
↓
Trip Decision
↓
Safety Output
↓
Shutdown Valve
↓
Position Feedback

Untuk arsitektur 2oo3, voting logic secara konseptual dapat menghasilkan:

Trip = (A AND B) OR (A AND C) OR (B AND C)

Namun formula tersebut hanya contoh konsep voting. Implementasi aktual harus mengikuti SRS, safety PLC architecture, diagnostic behavior, dan certified function blocks yang digunakan.

Fault Detection pada Sensor

Safety logic sebaiknya tidak hanya memeriksa apakah nilai sensor melewati setpoint.

Misalnya:

Pressure > Trip Setpoint

belum tentu cukup.

Logic dapat perlu mempertimbangkan kondisi seperti:

Sensor Valid? Signal Healthy? Communication Healthy? Rate of Change Valid? Channel Agreement? Diagnostic Fault?

Barulah safety function menentukan tindakan.

Pendekatan ini membantu menghindari keputusan safety berdasarkan data yang diketahui tidak valid.

Mismatch Detection

Pada sistem redundant, channel mismatch merupakan kondisi penting untuk dianalisis.

Contohnya:

Sensor A = 10 bar
Sensor B = 10,2 bar
Sensor C = 16 bar

Logic harus menentukan apakah kondisi tersebut:

• Merupakan sensor fault
• Merupakan process transient
• Memerlukan alarm
• Mengurangi redundancy
• Memerlukan safe-state transition

Tidak ada satu respons yang otomatis benar untuk semua aplikasi. Respons harus berasal dari SRS dan safety analysis.

Safe State dan Reset Logic

SIL-3 safety logic juga harus mendefinisikan safe state secara eksplisit.

Misalnya:

High Pressure → Close SDV

Setelah trip, sistem tidak seharusnya otomatis kembali ke kondisi normal tanpa memenuhi persyaratan restart.

Reset philosophy dapat mensyaratkan:

1. Penyebab trip harus hilang.
2. Diagnostic fault tidak aktif.
3. Process condition telah aman.
4. Operator melakukan manual reset.
5. Final element berada pada kondisi yang benar.
6. Tidak terdapat interlock yang masih aktif.

Konsep ini membantu mencegah automatic restart yang tidak diinginkan.

Bypass dan Override

Safety system sering membutuhkan bypass untuk maintenance atau testing.

Namun, bypass merupakan kondisi yang sangat sensitif.

Program harus menetapkan dengan jelas:

• Siapa yang boleh melakukan bypass
• Kapan bypass diperbolehkan
• Bagaimana bypass diaktifkan
• Bagaimana bypass ditampilkan
• Bagaimana bypass dibatasi waktunya
• Bagaimana bypass dikembalikan
• Apa compensating measure yang diperlukan

Logic bypass tidak boleh menjadi jalan untuk menghilangkan safety function tanpa kontrol.

Mengapa Programmers Harus Menghindari “Improvisasi”?

Pada standard control system, programmer kadang membuat logic tambahan untuk meningkatkan convenience atau availability.

Contohnya:

Auto-recovery
Auto-reset
Value clamping
Silent recovery

Dalam safety system, fitur tersebut tidak boleh ditambahkan hanya karena terlihat “lebih nyaman”.

Setiap perubahan terhadap safety behavior harus dapat ditelusuri ke requirement yang telah disetujui.

Dengan kata lain:

Programmer mengimplementasikan safety requirement, bukan mendefinisikan safety requirement.

Verification dan Validation

SIL-3 tidak dapat dibuktikan hanya dengan melihat bahwa program PLC berjalan tanpa error.

Safety-related software memerlukan proses verification dan validation yang sesuai.

Contohnya:

• Logic review
• Static analysis
• Test case
• Simulation
• Fault injection
• I/O testing
• Cause-and-effect verification
• Timing verification
• Proof test
• Validation terhadap SRS

IEC 61508-3 mencakup persyaratan software safety lifecycle dan informasi yang diperlukan untuk software safety validation.

Untuk process industry, IEC 61511 juga mengatur lifecycle yang mencakup specification, design, installation, operation, maintenance, dan application programming SIS.

Dokumentasi Safety Logic

Setiap safety function sebaiknya memiliki dokumentasi yang memungkinkan engineer lain memahami apa yang dilakukan logic.

Dokumen dapat mencakup:

• Cause & Effect
• SRS
• Logic diagram
• I/O list
• Safety function description
• Voting philosophy
• Trip setpoint
• Reset philosophy
• Bypass philosophy
• Test procedure
• Validation record
• Change history

Dokumentasi ini sangat penting ketika sistem harus di-maintain, dimodifikasi, atau diaudit.

Contoh Alur Safety Function

Sebuah high-pressure shutdown dapat digambarkan secara sederhana:

Pressure Transmitter A/B/C
↓
Signal Validation
↓
2oo3 Voting
↓
High-High Pressure Trip
↓
Safety Logic
↓
Close Shutdown Valve
↓
Valve Position Feedback
↓
Trip Confirmed

Apabila salah satu transmitter mengalami fault, sistem dapat menggunakan diagnostic dan voting logic untuk menentukan apakah safety function masih dapat beroperasi sesuai architecture.

Namun, tindakan yang tepat terhadap loss of redundancy harus mengikuti SRS dan hasil safety analysis.

Checklist SIL-3 Safety Logic

Item	Pemeriksaan
SIL target telah ditentukan	☐
SRS tersedia dan disetujui	☐
Safety architecture telah ditentukan	☐
Hardware sesuai certification	☐
Safety I/O sesuai	☐
Voting logic sesuai SRS	☐
Input diagnostics diterapkan	☐
Fault response didefinisikan	☐
Safe state didefinisikan	☐
Reset philosophy didefinisikan	☐
Bypass/override dikendalikan	☐
Final element feedback diperiksa	☐
Safety logic diverifikasi	☐
Safety function divalidasi	☐
Modification terdokumentasi	☐

Kesimpulan

Writing SIL-3 safety logic in PLC systems bukan terutama tentang membuat program yang lebih panjang atau menggunakan lebih banyak instruksi PLC.

Fokus utamanya adalah menerjemahkan Safety Requirement Specification, safety architecture, diagnostic requirements, fault response, dan safe-state philosophy ke dalam application logic yang deterministik dan dapat diverifikasi.

SIL-3 juga tidak otomatis berarti harus menggunakan arsitektur 2oo3. Voting architecture, redundancy, diagnostic coverage, hardware fault tolerance, dan parameter reliability harus ditentukan berdasarkan safety analysis dan persyaratan sistem.

Untuk aplikasi process industry, IEC 61511 menyediakan kerangka penerapan SIS, sedangkan IEC 61508 memberikan dasar functional safety dan persyaratan software safety-related.

Karena itu, programmer SIL-3 bukan sekadar seorang PLC programmer. Ia bekerja dalam sebuah functional safety lifecycle yang melibatkan engineering, risk analysis, hardware, software, testing, validation, operation, maintenance, dan change management.

Prinsip sederhananya adalah:

Define the Safety Requirement → Design the Safety Architecture → Implement the Logic → Verify → Validate → Maintain

Dan yang paling penting, setiap perubahan pada safety logic harus dapat ditelusuri kembali ke requirement yang telah disetujui.