Kiiota Blog

Memahami Cara Kerja PID Control pada DCS Supcon

2026-05-09T09:38:18+00:00

Ditulis oleh Ketut Kumajaya — 9 Mei 2026

Pendahuluan

Pada banyak sistem kontrol industri, PID controller merupakan algoritma utama untuk menjaga variabel proses seperti pressure, flow, temperature, dan level tetap berada pada setpoint. Salah satu hal yang sering membingungkan engineer ketika menggunakan DCS Supcon adalah bentuk parameter PID-nya yang sedikit berbeda dibanding beberapa PLC atau DCS modern lain.

Pada Supcon:

Parameter P menggunakan Proportional Band (%)
Parameter I menggunakan nilai reciprocal dari Integral Time ($1/T_I$)
Derivative menggunakan bentuk filtered derivative

Akibatnya:

Semakin kecil nilai P → controller semakin agresif
Semakin besar nilai I → integral semakin agresif

Ini berbeda dengan beberapa sistem lain yang menggunakan proportional gain langsung maupun integral time langsung.

Apa itu PID Controller?

PID controller adalah algoritma kontrol yang menghitung output berdasarkan tiga komponen: Proportional, Integral, dan Derivative. Ketiganya bekerja bersama untuk menjaga process variable (PV) tetap berada di setpoint (SP).

Proportional (P)

Komponen P menghasilkan output yang proporsional terhadap besar error saat ini — selisih antara SP dan PV. Semakin besar error, semakin besar output yang dihasilkan.

P bekerja instan: begitu error muncul, output langsung berubah. Kelemahannya, P saja hampir selalu meninggalkan offset permanen — PV mendekati SP tapi tidak pernah benar-benar mencapainya.

Integral (I)

Komponen I menjumlahkan error dari waktu ke waktu. Selama error masih ada, integral terus terakumulasi dan mendorong output hingga offset benar-benar hilang.

I bertugas menghilangkan offset yang ditinggalkan oleh P. Namun integral yang terlalu agresif dapat menyebabkan overshoot dan oscillation karena output terus didorong bahkan saat PV sudah mendekati SP.

Derivative (D)

Komponen D membaca kecepatan perubahan error. Bila PV bergerak cepat menuju SP, derivative mulai mengurangi output lebih awal — seperti rem sebelum mencapai target.

D membantu mengurangi overshoot dan mempercepat stabilisasi. Namun derivative sangat sensitif terhadap noise sehingga tidak selalu digunakan, terutama pada proses dengan sinyal yang tidak bersih.

PID Visualizer

Setpoint (SP) Process Variable (PV) Output controller Noise PV

Gain (Kp)besar = agresif

1.0

Integral time T_I (min)kecil = agresif

2.0 min

Derivative T_D (detik)besar = lebih prediktif

Setpoint (SP) Process Variable (PV) Output controller Noise PV

P — band (%)kecil = agresif

150% Kp = 0.67

I — input DCSbesar = agresif

1.00 T_I = 1.0 min

D — detikbesar = lebih prediktif

Mode derivativeaktif saat D > 0

Struktur PID pada Supcon

Dokumen Supcon menunjukkan formula dasar berikut:

$$\frac{U(s)}{E(s)} = \frac{1}{P} + \frac{1}{T_I s} + \frac{T_D s}{1+\frac{T_D}{K_d}s}$$

Dengan:

$U(s)$ = output controller
$E(s)$ = error
$P$ = proportional band
$T_I$ = integral time
$T_D$ = derivative time
$K_d$ = derivative filter gain

Error didefinisikan sebagai:

$$e(t) = SP(t) - PV(t)$$

Di mana:

$SP$ = setpoint
$PV$ = process variable

Komponen Proportional (P)

Bagian proportional pada Supcon:

$$U_P(s)=\frac{1}{P}E(s)$$

Karena Supcon menggunakan proportional band, hubungan dengan gain klasik menjadi:

$$K_p=\frac{100}{P}$$

Makna Praktis

Semakin kecil P:

gain semakin besar
respons controller semakin agresif

Semakin besar P:

gain semakin kecil
controller semakin lembut

Contoh

P = 100%

$K_p=\frac{100}{100}=1$

P = 600%

$K_p=\frac{100}{600}=0.167$

Artinya:

P 100% sekitar 6 kali lebih agresif dibanding P 600%.

Cara Kerja Integral (I)

Bagian integral pada Supcon:

$$U_I(s)=\frac{1}{T_I s}E(s)$$

Dalam domain waktu:

$$u_I(t)=\frac{1}{T_I}\int e(t),dt$$

Integral bertugas:

menghilangkan offset
memastikan PV akhirnya mencapai SP

Parameter I sebagai Reciprocal

Penting dipahami: parameter I yang diinput di DCS Supcon bukan $T_I$ langsung, melainkan nilai reciprocal-nya.

Dokumentasi Supcon menyebutkan bahwa I ditampilkan sebagai reciprocal, dan nilai yang terlalu kecil dapat menyebabkan overflow perhitungan. Nilai minimum yang diizinkan adalah 1/60 = 0.02 menit.

Hubungannya:

$$I_{input} = \frac{1}{T_I}$$

Artinya:

I (input DCS)	T_I aktual	Karakter
0.02 menit	50 menit	sangat lambat
0.17 menit	6 menit	lambat
1 menit	1 menit	sedang
2 menit	0.5 menit	agresif
6 menit	10 detik	sangat agresif

Kesimpulan: I besar → integral lebih agresif.

Ini kebalikan dari intuisi engineer yang terbiasa dengan sistem yang menggunakan integral time langsung.

Karakter Integral

Semakin besar $I_{input}$:

integral semakin cepat
offset dihilangkan lebih agresif

Semakin kecil $I_{input}$:

integral semakin lambat
loop lebih tenang

Cara Kerja Derivative (D)

Bagian derivative pada Supcon:

$$U_D(s)=\frac{T_D s}{1+\frac{T_D}{K_d}s}E(s)$$

Derivative berfungsi:

memprediksi arah perubahan PV
mengurangi overshoot
mempercepat stabilisasi

Namun Supcon tidak menggunakan derivative ideal murni, melainkan derivative yang sudah difilter.

Mengapa Derivative Difilter?

Derivative sangat sensitif terhadap noise.

Tanpa filter:

$$U_D(s)=T_D sE(s)$$

Sedikit noise pada PV dapat menghasilkan perubahan output besar.

Karena itu Supcon menambahkan filter low-pass:

$$\frac{T_D s}{1+\frac{T_D}{K_d}s}$$

Agar derivative tetap stabil untuk aplikasi industri.

D_PI Mode pada Supcon

Supcon menyediakan mode penting bernama D_PI.

Pada mode ini:

derivative hanya diterapkan ke PV
bukan ke error

Formula discrete yang digunakan:

$$u_d(n)=\frac{T_D}{K_d T_s+T_D}u_d(n-1)+K_d\left[y(n)-y(n-1)\right]$$

Dengan:

$y(n)$ = PV sekarang
$y(n-1)$ = PV sebelumnya
$u_d(n)$ = derivative output sekarang
$u_d(n-1)$ = derivative output sebelumnya
$T_s$ = sampling time

Mengapa D_PI Penting?

Jika derivative diterapkan langsung pada error:

$$\frac{d}{dt}(SP-PV)$$

Maka perubahan mendadak pada SP akan menghasilkan:

derivative kick
lonjakan output besar

Pada plant nyata ini bisa berbahaya:

valve bergerak mendadak
pressure spike
instabilitas proses

Karena itu Supcon menggunakan derivative terhadap PV saja.

Ini merupakan praktik industri yang baik.

Kapan Mengaktifkan D_PI?

Aktifkan D_PI ketika:

loop menggunakan derivative (D > 0)
setpoint loop sering diubah oleh operator atau oleh major loop cascade
proses sensitif terhadap lonjakan output mendadak — misalnya pressure loop, recycle valve, atau cryogenic process

Dengan D_PI aktif, perubahan SP tidak akan memicu derivative kick karena derivative hanya menghitung perubahan PV, bukan perubahan error.

Kapan Derivative Sebaiknya Tidak Dipakai Sama Sekali?

Derivative tidak diperlukan — bahkan kontraproduktif — pada kondisi berikut:

Flow loop — sinyal flow transmitter mengandung noise tinggi; derivative akan memperkuat noise dan membuat valve hunting
Level loop — proses lambat dan toleran terhadap offset kecil; derivative tidak memberikan manfaat signifikan
Loop dengan transmitter noise tinggi — noise sekecil apapun akan diperkuat oleh derivative, meskipun sudah difilter
Loop yang sudah stabil dengan PI saja — menambahkan D tanpa alasan jelas hanya menambah kompleksitas tuning

Sebagai panduan praktis: aktifkan derivative hanya bila ada masalah spesifik yang ingin diatasi — overshoot berlebihan atau respons yang terlalu lambat pada proses dengan dead time besar seperti temperature loop.

D_PI pada Cascade Control

Perlu diperhatikan: mode D_PI tidak berlaku pada minor loop di cascade control.

Ketika minor loop menerima setpoint dari major loop, differential action pada minor loop tetap menggunakan formula derivative original terhadap error, bukan terhadap PV. Hal ini karena setpoint minor loop berubah secara dinamis mengikuti output major loop, sehingga metode PV differential tidak dapat diterapkan.

Implikasinya pada aplikasi seperti compressor atau ASU: bila derivative diaktifkan pada secondary loop cascade, perlu diperhitungkan bahwa derivative kick tetap dapat terjadi saat major loop memberikan perubahan setpoint yang signifikan.

Bentuk Lengkap PID Supcon

Secara konseptual dalam domain waktu:

$$u(t)=\frac{1}{P}e(t)+\frac{1}{T_I}\int e(t),dt+T_D\frac{de(t)}{dt}$$

Walaupun implementasi aktualnya menggunakan:

derivative filter
discrete execution
anti-reset windup
mode D_PI

Interpretasi Parameter Supcon

Proportional Band

P (%)	Karakter
1000	sangat lembut
600	lembut
300	sedang
100	agresif
50	sangat agresif

Range yang diizinkan: minimum 6.25%, maximum 204800%.

Integral Time (I sebagai reciprocal)

I input adalah $1/T_I$ — semakin besar nilai I yang diinput, semakin agresif integral. Lihat tabel konversi lengkap di bagian "Parameter I sebagai Reciprocal" di atas.

Range yang diizinkan: minimum 0.02 menit (= 1/60), maximum sama dengan D.

Derivative Time

D (detik)	Karakter
0	derivative nonaktif
kecil	efek derivative kecil
besar	derivative kuat

Range yang diizinkan: minimum 0s, maximum 3276.8s.

Karakter Tuning Berdasarkan Jenis Proses

Tabel berikut memberikan range tipikal sebagai starting point tuning awal. Nilai final harus selalu disesuaikan dengan dinamika aktual loop di plant masing-masing — ukuran equipment, span transmitter, dan karakteristik valve sangat mempengaruhi hasil akhir.

Proses	P tipikal (%)	I tipikal (input)	D	Alasan
Flow	50–200	1–5	Tidak perlu	Proses cepat, butuh respons agresif
Pressure	100–500	0.3–2	Jarang	Rentan oscillation, coupling antar equipment
Temperature	300–1000	0.05–0.3	Opsional	Proses lambat, integral agresif bisa windup
Level	500–2000	0.05–0.1	Tidak perlu	Tank sebagai buffer, cukup proportional-dominant

Flow Control

Flow adalah proses tercepat — dead time kecil, time constant kecil.

Starting point yang umum digunakan:

P: 50–200% (agresif)
I: 1–5 (agresif, $T_I$ aktual 1–0.2 menit)
D: tidak diperlukan, noise pada flow transmitter membuat derivative kontraproduktif

Pressure Control

Pressure sering memiliki coupling antar equipment — terutama pada header bersama atau sistem compressor dengan recycle.

Starting point yang umum digunakan:

P: 100–500% (sedang)
I: 0.3–2 (sedang, $T_I$ aktual 3–0.5 menit)
D: jarang digunakan, perlu hati-hati terhadap oscillation

Temperature Control

Proses thermal memiliki time constant besar dan dead time yang signifikan.

Starting point yang umum digunakan:

P: 300–1000% (lembut)
I: 0.05–0.3 (lambat, $T_I$ aktual 20–3 menit)
D: opsional, dapat membantu pada proses dengan dead time besar

Integral yang terlalu agresif pada temperature loop berisiko windup karena proses lambat merespons.

Level Control

Tank berfungsi sebagai buffer — tidak perlu mengejar setpoint terlalu agresif.

Starting point yang umum digunakan:

P: 500–2000% (lembut, proportional-dominant)
I: 0.05–0.1 (sangat lambat, $T_I$ aktual 20–10 menit)
D: tidak diperlukan

Kesalahan Umum Saat Tuning Supcon

Salah interpretasi P

Karena Supcon menggunakan proportional band, banyak engineer salah interpretasi:

Mereka mengira P besar = agresif. Padahal pada Supcon, P besar = lembut.

Salah interpretasi I

Karena Supcon menampilkan I sebagai reciprocal, banyak engineer mengira I kecil = agresif.

Padahal pada Supcon: I besar = agresif (karena $I = 1/T_I$, nilai besar berarti waktu integral singkat).

Akibat kedua kesalahan ini:

tuning menjadi terlalu lambat
atau justru terlalu agresif tanpa disadari

Kesimpulan

PID pada Supcon menggunakan:

proportional band untuk P
reciprocal integral time untuk I
filtered derivative untuk D

Karakter utamanya:

P kecil → lebih agresif
I besar → lebih agresif (karena $I = 1/T_I$)
derivative menggunakan filter untuk mengurangi noise
tersedia mode D_PI untuk menghindari derivative kick, kecuali pada minor loop cascade

Memahami interpretasi parameter ini sangat penting sebelum melakukan tuning di plant nyata, terutama pada sistem seperti:

compressor
Air Separation Unit
cryogenic process
pressure loop
recycle control
flow regulation

Analisis Spektrum Keahlian: Relevansi Pemahaman Lintas Domain

2026-04-19T05:46:07+00:00

Ditulis oleh Ketut Kumajaya — 1 November 2025

Catatan ini saya tulis di penghujung 2025 sebagai refleksi atas perjalanan 25 tahun di dunia kontrol dan otomasi. Membacanya kembali hari ini, saya menyadari bahwa di tengah gempuran teknologi yang semakin cepat, prinsip-prinsip inilah yang menjaga akurasi dan kemanusiaan dalam setiap keputusan teknis saya.

Pendahuluan

Perjalanan profesional saya tidak pernah berjalan lurus. Ada banyak persimpangan, percobaan, bahkan kegagalan dan kehilangan pekerjaan yang justru menjadi guru terbaik. Dari pemrograman kernel Linux hingga desain control system yang dapat diaudit, serta dokumentasi yang ramah bagi siapa saja, saya belajar bahwa keahlian bukanlah label yang melekat, melainkan proses yang terus berkembang — dan yang terpenting, bisa diwariskan agar orang lain tak perlu mengulang kesulitan yang sama.

"Teknologi tidak berhenti di mesin, melainkan di pemahaman manusia."

Tulisan ini adalah upaya sederhana saya untuk melihat diri sendiri secara jujur, sambil berbagi apa yang saya pelajari. Saya mencoba merangkum pengalaman ke dalam delapan lapisan kompetensi yang saling terhubung, yang bersama-sama membentuk cara saya berpikir dan bekerja: integratif, sistematik, dan humanistik.

Urutan lapisan ini mengikuti alur alami perjalanan saya — dari fondasi teknis yang paling dasar, naik ke integrasi sistem, lalu ke aspek manusiawi dan visioner — dengan harapan bisa memberikan titik pijak bagi siapa saja yang sedang menavigasi dunia yang semakin kompleks ini.

1. Lapisan Teknis-Operasional — Dari Sensor ke Data

Lapisan ini adalah fondasi: kemampuan untuk mengubah konsep menjadi sistem nyata di lapangan. Dari PLC, SCADA, hingga flowmeter kriogenik, saya belajar bahwa detail teknis bukan sekadar angka — melainkan jembatan antara fenomena fisik dan keputusan operasional sehari-hari.

Cakupan Utama

Desain dan pemrograman PLC, DCS, dan SCADA berbasis Ladder, Function Block Data (FBD), dan Structured Text (ST), atau bahkan JavaScript di Node-RED dan C# di Rapid SCADA.
Integrasi solusi terbuka seperti 4diac FORTE (IEC 61499) atau OpenPLC (IEC 61131-3).
Integrasi PLC, PID control, sistem I/O dan instrumentasi berbagai merk.
Analisis performa kompresor sentrifugal, booster expander, dan tangki kriogenik.
Konfigurasi transmitter DP dan orifice flowmeter dengan kompensasi tekanan dan temperatur.
Implementasi sistem logging audit-grade berbasis JSON dan MQTT.

Pelajaran yang Saya Dapat

Sistem kontrol terbaik bukan hanya yang bekerja — tapi yang bisa ditelusuri, diverifikasi, dan dipahami oleh tim. Sistem yang tidak bisa dijelaskan kepada orang lain adalah sistem yang rapuh. Fondasi ini perlu disatukan dalam arsitektur yang lebih luas agar tidak terisolasi.

2. Lapisan Arsitektur & Integrasi Sistem — Menyatukan Ekosistem

Otomasi industri bukan kumpulan perangkat yang bekerja sendiri-sendiri. Ia adalah ekosistem data. Lapisan ini adalah jembatan antara dunia fisik — sensor dan aktuator — dengan dunia digital: dashboard, analitik, dan keputusan berbasis data.

Cakupan Utama

Desain arsitektur edge-to-server dengan retry logic, buffering, dan dead-letter queue.
Pengembangan middleware untuk menyatukan API, autentikasi, dan datasource visualisasi.
Sinkronisasi flow context memory → persistent storage untuk mencegah kehilangan data.
Integrasi Modbus, OPC UA, dan REST API ke dalam sistem visualisasi terdistribusi.
Implementasi pola event sourcing dan self-healing pipeline.

Pelajaran yang Saya Dapat

Arsitektur terbuka memberi ruang bagi sistem untuk bertahan lama — tidak tergantung vendor, dapat diaudit, dan bisa diteruskan ke tim berikutnya tanpa kehilangan konteks. Pengalaman ini membawa saya ke akarnya: pemahaman software dari level paling dalam membuat integrasi terasa lebih intuitif.

3. Lapisan Software & Embedded Systems — Dari Kernel ke Aplikasi

Dari arsitektur yang lebih tinggi, pengalaman saya kembali ke level paling rendah dari sistem digital: kernel dan firmware. Perspektif bottom-up ini membentuk cara saya mendekati kompleksitas — dari bawah, bukan dari asumsi.

Cakupan Utama

Pengembangan Linux kernel dan Android device tree untuk SoC ARM.
Pembuatan utility open source karena kebutuhan kerja.
Skrip otomatisasi (Bash, Python, JavaScript) untuk data logging dan visualisasi performa.
Kontribusi pada ekosistem CyanogenMod, 4diac, Rapid SCADA, dan komunitas FOSS lain.

Pelajaran yang Saya Dapat

Memahami sistem dari bawah ke atas mengubah cara merancang solusi di level aplikasi. Bukan sekadar lebih efisien — tapi lebih jujur terhadap apa yang sebenarnya terjadi di dalam sistem.

4. Lapisan Komunitas Open Source — Kolaborasi, Inklusivitas, Transparansi

Komunitas open source mengajarkan sesuatu yang tidak diajarkan di tempat kerja manapun: bahwa gelar dan jabatan bukan penentu kualitas kontribusi. Profesor bisa setara dengan diploma. Setiap orang bisa berkontribusi, setiap ide bisa diuji, dan setiap kesalahan bisa diperbaiki secara terbuka — di depan semua orang.

Cakupan Utama

Kontribusi pada kernel Linux, device tree, dan utilitas open source.
Partisipasi dalam komunitas FOSS global (Android, GitHub, forum teknis).
Pembuatan dan pemeliharaan tool lintas komunitas.
Diskusi terbuka, peer review, dan iterasi berbasis masukan publik.

Pelajaran yang Saya Dapat

Inklusivitas: kontribusi tidak mengenal latar belakang.
Transparansi: keputusan teknis harus bisa ditelusuri dan dipahami siapa pun.
Kerendahan hati: selalu ada ruang untuk belajar.
Keberlanjutan: solusi yang baik bisa diteruskan.

Dampak pada Cara Berpikir

Nilai-nilai ini saya bawa ke dunia industri yang cenderung tertutup: menulis dokumentasi audit-grade, membangun sistem vendor-neutral, mendorong budaya yang tidak menyembunyikan cara kerjanya. Bukan sebagai idealisme — tapi karena sistem yang transparan lebih mudah dijaga dan lebih tahan lama.

5. Lapisan Mekanikal & Proses — Menghormati Fenomena Fisik

Data digital hanyalah representasi. Di baliknya ada energi, fluida, tekanan, dan temperatur yang nyata — dan yang nyata ini tidak bisa diabaikan.

Cakupan Utama

Analisis performa kompresor sentrifugal.
Studi fenomena surge dan choke.
Perhitungan volume tangki torisferik berbasis standar ASME.
Evaluasi efisiensi expander, pompa, dan sistem kriogenik.

Pelajaran yang Saya Dapat

Engineering adalah bahasa universal — menghubungkan fenomena fisik dengan angka yang bisa diuji ulang. Kesalahan di lapangan sering bukan karena kurang data, tapi karena kurang pemahaman terhadap fisika yang bekerja di baliknya.

6. Lapisan Rekayasa Pengetahuan & Dokumentasi

Dokumentasi bukan produk akhir dari pekerjaan. Ia adalah bagian dari pekerjaan itu sendiri. Menulis dengan jelas berarti berpikir dengan jelas — dan itu berlaku dua arah.

Cakupan Utama

Dokumentasi teknis human-friendly dengan narasi edukatif.
Living documentation berbasis Markdown, Pandoc, GitHub Pages.
Prinsip troubleshooting mental framework.
Gaya penulisan yang menghubungkan sains, etika, dan empati.

Pelajaran yang Saya Dapat

Pengetahuan yang tidak bisa ditulis ulang oleh orang lain adalah pengetahuan yang rentan hilang. Dokumentasi yang baik bukan yang paling lengkap — tapi yang paling mudah diikuti oleh orang yang belum pernah ada di sana sebelumnya.

7. Lapisan Inovasi, Efisiensi, & Sustainability

Filosofi Zero-Cost Engineering tidak lahir dari pilihan ideologis. Ia lahir dari keterbatasan anggaran yang memaksa kreativitas. Keterbatasan bukan hambatan — ia adalah filter yang menyisakan solusi yang benar-benar bisa bertahan.

Cakupan Utama

Integrasi alur kerja FOSS end-to-end tanpa lisensi.
Desain sistem otomasi yang dapat diperluas tanpa ketergantungan vendor.
Kerangka kerja reproducible engineering documentation.
Edukasi internal tentang efisiensi berbasis keterbukaan.

Pelajaran yang Saya Dapat

Efisiensi sejati bukan soal biaya yang ditekan, melainkan kemandirian intelektual yang dibangun — kemampuan untuk memahami, memodifikasi, dan meneruskan sistem tanpa bergantung pada satu vendor atau satu orang.

8. Lapisan Kepemimpinan & Budaya Kerja

Kepemimpinan bagi saya bukan memberi perintah. Bukan pula memberi motivasi. Kepemimpinan adalah memberi arah yang jelas dan ruang yang cukup agar orang lain bisa tumbuh dengan cara mereka sendiri.

Cakupan Utama

Membangun budaya human empowerment.
Mendorong transformasi menuju sistem otomasi terbuka.
Menulis refleksi tentang kepemimpinan manusiawi di era otomasi.
Menyeimbangkan data dengan intuisi manusia.

Pelajaran yang Saya Dapat

Pemimpin yang hanya membaca data akan selalu terlambat. Yang dibutuhkan adalah kemampuan membaca situasi — memahami konteks manusia di balik angka, dan mengambil keputusan yang tidak mereduksi manusia menjadi variabel.

Kesimpulan

Delapan lapisan ini bukan daftar keahlian. Ia adalah peta perjalanan — dengan semua persimpangan, percobaan, dan kegagalannya.

Tuntutan atasan, ekspektasi customer, dan tekanan organisasi sering memaksa keluar dari zona nyaman. Justru di situlah pertumbuhan terjadi: belajar lebih cepat, berpikir lebih jernih, dan menemukan cara menjembatani teknologi dengan kebutuhan manusia.

Keterlibatan dalam komunitas open source memperluas cara pandang: kolaborasi, transparansi, dan inklusivitas bukan nilai tambahan — melainkan fondasi sistem dan budaya kerja yang bisa bertahan lama. Nilai ini saya bawa ke dunia industri agar solusi tidak hanya berfungsi, tetapi juga bisa diaudit, dipelajari, dan diteruskan.

Setiap lapisan adalah jembatan — antara mesin dan manusia, data dan intuisi, logika dan empati. Di era di mana AI dan otomasi mengubah segalanya, keahlian lintas domain bukan lagi pilihan. Ia adalah prasyarat untuk tidak tertinggal — dan untuk tidak meninggalkan orang lain.

Formula yang saya pegang:

Precision in System — setiap logika harus bisa diaudit.

Transparency in Knowledge — setiap ide harus bisa diajarkan.

Humanity in Leadership — setiap keputusan harus memuliakan manusia.

Saya tidak berusaha menjadi ahli di semua bidang. Saya berusaha memahami bagaimana semuanya saling terhubung — dan mengapa hubungan itu penting.

Booster Expander dalam Sistem Cryogenic: Konsep Dasar hingga Monitoring Operasional

2026-04-19T02:34:56+00:00

Ditulis oleh Ketut Kumajaya — 19 April 2026

Pendahuluan

Dalam sistem Air Separation Unit (ASU), booster expander adalah salah satu komponen rotating equipment yang paling sering disalahpahami. Banyak operator memandangnya sebagai dua mesin terpisah — sebuah expander dan sebuah kompresor booster — yang kebetulan terhubung pada satu shaft.

Padahal pemahaman yang tepat justru sebaliknya:

Booster bukan mesin utama yang dibantu expander. Booster adalah beban — expander adalah prime mover yang memutarnya.

Dengan kata lain, booster tidak menentukan kemampuan sistem. Ia hanya mengikuti energi yang disediakan oleh expander. Ini bukan sekadar konsep, melainkan batasan fisika yang menentukan bagaimana sistem harus dioperasikan.

Artikel ini membahas konsep dasar booster expander, hubungan energi di dalamnya, serta pendekatan monitoring berbasis rasio yang lebih tepat untuk operasional sehari-hari.

Konsep Dasar: Satu Sistem Energi

Booster expander terdiri dari dua komponen utama dalam satu shaft:

Expander — gas bertekanan tinggi diekspansikan, menghasilkan kerja melalui ekstraksi enthalpy, memutar shaft, dan menghasilkan efek pendinginan yang signifikan.
Booster — memanfaatkan energi tersebut untuk mengkompresi gas di sisi booster.

Keduanya bukan dua mesin independen, melainkan satu sistem energi yang saling terikat.

Energi yang tersedia dari expander adalah batas atas dari kerja yang dapat dilakukan oleh booster.

Penting untuk dipahami bahwa energi expander bukanlah nilai tetap — ia sangat dinamis, dipengaruhi oleh kondisi inlet (temperatur dan tekanan), posisi nozzle, serta backpressure di sisi outlet. Inilah sebabnya kapasitas booster bisa terasa berubah meskipun tidak ada yang diubah di sisi booster itu sendiri — sumber energinya yang berfluktuasi.

Pendinginan pada expander bukan sekadar akibat penurunan tekanan seperti yang terjadi pada ekspansi melalui valve (efek Joule-Thomson), tetapi karena ekstraksi kerja dari gas. Inilah sebabnya expander jauh lebih efektif menghasilkan temperatur rendah dibandingkan ekspansi melalui valve biasa.

Booster Expander — Cryostar HA1660A (Performance Curve)

Expander — design

Shaft — design

Booster — design

Energi expander (cold production)0 kW

Power dikonsumsi booster0 kW

Bearing losses0 kW

Opening nozzle expander 77%

Bypass booster 0%

Speed shaft

0 RPM

ER aktual / design

—

CR aktual / design

—

Status

Normal

Design point: nozzle 77.5%

Keseimbangan Energi dan Dampaknya di Lapangan

Secara fundamental:

$$W_{expander} = W_{booster} + W_{losses}$$

Dimana losses meliputi:

losses mekanis (bearing, seal, leakage)
losses aerodinamis internal

Namun operator tidak melihat persamaan ini secara langsung. Yang terlihat adalah manifestasinya:

vibrasi meningkat
speed tidak stabil
mesin terasa tidak "smooth"
bahkan trip

Ketika keseimbangan energi terganggu, sistem keluar dari design point dan memicu:

perubahan pola aliran di impeller
munculnya unbalanced aerodynamic forces
berkembang menjadi rotor instability

Dalam jangka panjang:

Kondisi ini mempercepat keausan bearing dan menurunkan keandalan mesin.

Vibrasi sering didiagnosis sebagai masalah mekanis — bearing, alignment, atau balancing. Padahal di lapangan, vibrasi pada booster expander sangat sering berakar dari energy mismatch di sisi aerodinamis, bukan dari komponen mekanis itu sendiri. Mengejar solusi mekanis tanpa memeriksa keseimbangan energi proses adalah langkah yang bisa membuang waktu dan biaya.

Dengan kata lain, menjaga keseimbangan energi bukan hanya soal performa — tetapi juga umur equipment.

Power, Torsi, dan Speed: Batasan yang Tidak Bisa Dinegosiasikan

$$W = \tau \times \omega$$

Karena expander dan booster berada pada satu shaft:

kecepatan rotasi selalu sama
keseimbangan torsi harus terpenuhi

$$\tau_{expander} = \tau_{booster} + \tau_{losses}$$

Implikasi paling penting:

Ini bukan batasan kontrol — ini batasan fisika. Booster tidak bisa dipaksa bekerja melebihi energi yang disediakan expander.

Jika batas ini dilanggar, sistem tidak langsung berhenti — ia akan bereaksi dengan cara tertentu sebelum akhirnya tidak stabil:

flow di kedua sisi berubah secara otomatis
rasio ekspansi dan kompresi bergeser dari design point
titik operasi berpindah ke zona yang kurang efisien atau tidak stabil
speed turun, vibrasi meningkat, dan potensi trip meningkat

Memahami mekanisme ini membantu operator mengenali tanda-tanda awal ketidakseimbangan sebelum sistem mencapai kondisi kritis.

Parameter Utama: Rasio Ekspansi dan Rasio Kompresi

Catatan krusial:

Semua perhitungan harus menggunakan tekanan absolut (bar abs / psia). Menggunakan tekanan gauge akan menghasilkan rasio yang salah dan interpretasi kondisi operasi yang keliru.

Rasio Ekspansi (Expander):

$$ER = \frac{P_{inlet}}{P_{outlet}}$$

Rasio Kompresi (Booster):

$$CR = \frac{P_{discharge}}{P_{suction}}$$

Mengapa bukan differential pressure (ΔP)?

ΔP hanya menunjukkan selisih absolut tanpa memperhitungkan kondisi suction.

Suction (bar abs)	Discharge (bar abs)	ΔP (bar)	CR
5.0	6.0	1.0	1.20
4.0	5.0	1.0	1.25

ΔP yang sama tidak selalu mencerminkan kondisi operasi yang sama.

Dengan sistem DCS, rasio dapat dihitung secara real-time, sehingga lebih representatif dibanding ΔP.

Temperatur Adalah Konsekuensi, Bukan Target

$$T_{outlet} = T_{inlet} \times \left(\frac{P_{outlet}}{P_{inlet}}\right)^{\frac{\gamma-1}{\gamma}}$$

Temperatur outlet adalah fungsi langsung dari rasio tekanan.

Rasio adalah penyebab. Temperatur adalah akibat.

Jika rasio sesuai design dan kondisi inlet normal, maka temperatur akan mengikuti secara alami.

Mengejar temperatur tanpa memperhatikan rasio sama seperti memperbaiki gejala tanpa menyentuh penyebabnya.

Opening Nozzle Expander: Satu Tuas untuk Seluruh Sistem

Opening nozzle (pada beberapa vendor dikenal sebagai VIGV atau segmental nozzle) adalah satu-satunya manipulated variable utama. Lebih tepat dipahami bukan sebagai pengatur flow semata, melainkan sebagai pengatur energi — karena yang sesungguhnya dikendalikan adalah enthalpy drop di sisi expander, yang menentukan berapa besar energi tersedia untuk memutar shaft dan menggerakkan booster. Perubahannya mempengaruhi seluruh sistem:

--- config: theme: neutral --- flowchart TD A("Opening Nozzle ↑"):::nozzle B("Flow Expander ↑"):::expander C("Energi Expander ↑"):::expander D("Torsi Shaft ↑"):::shaft E("Speed ↑"):::shaft F("Booster Work ↑"):::booster G("Flow Booster ↑"):::booster H("Rasio Kompresi Berubah"):::output A --> B B --> C C -->|Menghasilkan| D D --> E E --> F F --> G G --> H classDef nozzle fill:#fff2cc,stroke:#bf9000,stroke-width:2px,color:#000 classDef expander fill:#cfe2f3,stroke:#1155cc,stroke-width:2px,color:#000 classDef shaft fill:#d9ead3,stroke:#38761d,stroke-width:2px,color:#000 classDef booster fill:#fce5cd,stroke:#e69138,stroke-width:2px,color:#000 classDef output fill:#d9d2e9,stroke:#351c75,stroke-width:2px,color:#000

Pengaruh Opening Nozzle terhadap Keseimbangan Sistem Booster Expander

Tidak ada perubahan kecil di sistem ini — satu adjustment akan menggeser seluruh keseimbangan sistem.

Profil Vendor sebagai Peta Energi

Vendor biasanya menyediakan tabel performa yang mencakup speed, flow, tekanan, temperatur, dan posisi nozzle.

Setiap titik dalam tabel tersebut adalah kondisi di mana keseimbangan energi tercapai. Profil vendor adalah peta keseimbangan energi sistem.

Vendor umumnya tidak hanya menyediakan data untuk 100% pembebanan, tetapi juga untuk beberapa titik lain — misalnya 90% dan 110%. Setiap titik pembebanan memiliki profil keseimbangan energi tersendiri dengan rasio, speed, flow, dan posisi nozzle yang berbeda. Pendekatan monitoring berbasis rasio berlaku di semua titik pembebanan tersebut — operator tinggal mengacu ke profil yang sesuai dengan kondisi operasi aktual, tanpa perlu mengekstrapolasi sendiri.

Bypass Valve Booster: Anti-Surge dan Implikasinya terhadap Energi

Dalam sistem booster, bypass valve merupakan bagian dari sistem anti-surge protection, yang berfungsi menjaga kompresor tetap berada pada daerah operasi yang stabil.

Fungsinya meliputi:

menjaga flow minimum melalui booster
mencegah surge akibat aliran yang terlalu rendah
melindungi impeller dari instabilitas aerodinamis

Bypass valve bekerja dalam domain perilaku aliran (flow stability), bukan dalam domain keseimbangan energi sistem.

Namun dari sudut pandang energi, ada implikasi yang sangat penting.

Dalam kondisi operasi normal:

Bypass valve seharusnya berada pada posisi full close.

Ini bukan sekadar prosedur, tetapi konsekuensi dari sistem yang sudah seimbang:

sistem tidak lagi membutuhkan recirculation untuk menjaga stabilitas
seluruh energi dari expander diserap oleh booster
tidak ada flow yang “diputar ulang” tanpa kontribusi proses

Jika bypass tetap terbuka:

energi kompresi terbuang
efisiensi menurun
sebagian flow hanya bersirkulasi tanpa menghasilkan kerja proses
kondisi operasi menjadi bias terhadap design

Sistem yang stabil karena bypass terbuka belum tentu sistem yang benar secara energi.

Fenomena Lapangan

Sering ditemukan bypass yang tidak pernah benar-benar full close dan dianggap sebagai kondisi normal. Dalam banyak kasus, hal ini berawal dari fase startup yang kurang terkoordinasi:

nozzle dinaikkan terlalu cepat
energi expander meningkat sebelum sistem siap
speed melonjak
bypass dibiarkan terbuka sebagai solusi sementara

Yang menjadi masalah, kondisi sementara ini kemudian bertahan dan diwariskan sebagai “kenormalan”.

Jika sistem hanya stabil saat bypass terbuka, kemungkinan besar sistem belum berada pada titik operasi yang benar.

Shut-Off Valve Expander: Isolasi Sumber Energi Sistem

Jika bypass valve bekerja dalam menjaga stabilitas aliran selama operasi normal, maka shut-off valve berada pada level yang berbeda: isolasi total sumber energi sistem.

Shut-off valve bukan lagi bagian dari kontrol proses, tetapi bagian dari sistem keselamatan yang memutus hubungan antara sumber energi dan rotating equipment.

Pada kondisi trip, fokus sistem berubah dari stability control menjadi energy isolation.

Shut-off valve pada inlet expander berfungsi untuk:

menghentikan aliran gas ke expander
mengisolasi sumber energi dari sistem shaft
menghilangkan driving force utama pada turbin expander
memastikan proses rundown terjadi secara terkendali dan terprediksi

Secara konsep energi:

--- config: theme: neutral --- flowchart TD RUN([RUN]):::state --> N N --> STOP([STOP]):::state STOP --> T subgraph N["Normal Operation"] direction LR A("Gas"):::expander B("Expander"):::expander C("Energy Extraction"):::expander D("Shaft"):::shaft E("Booster"):::booster A --> B --> C --> D --> E end subgraph T["Trip / Shutdown Transient"] direction LR G("Gas Flow Isolated"):::nozzle H("Energy Supply Cut"):::nozzle I("Shaft Decays Naturally"):::shaft G --> H --> I end classDef state fill:#eeeeee,stroke:#666,stroke-width:2px,color:#000 classDef nozzle fill:#fff2cc,stroke:#bf9000,stroke-width:2px,color:#000 classDef expander fill:#cfe2f3,stroke:#1155cc,stroke-width:2px,color:#000 classDef shaft fill:#d9ead3,stroke:#38761d,stroke-width:2px,color:#000 classDef booster fill:#fce5cd,stroke:#e69138,stroke-width:2px,color:#000 classDef output fill:#d9d2e9,stroke:#351c75,stroke-width:2px,color:#000 classDef alert fill:#f4cccc,stroke:#cc0000,stroke-width:2px,color:#000

Konsep Energi Normal Operation dan Trip Condition

Yang penting dipahami adalah bahwa tanpa shut-off valve, expander masih dapat “menerima energi residual” dari sistem upstream meskipun kondisi trip sudah aktif. Dalam kondisi tertentu, ini dapat menyebabkan:

rundown yang tidak terkontrol
beban dinamis tambahan pada shaft
peningkatan stress pada bearing selama deceleration
potensi secondary mechanical issue akibat transien yang tidak terisolasi

Shutdown yang aman bukan hanya menghentikan operasi, tetapi memastikan tidak ada lagi energi baru yang masuk ke sistem.

Perbedaan Konseptual yang Perlu Dipahami

Aspek	Bypass Valve	Shut-Off Valve
Peran utama	Stabilitas aliran (anti-surge)	Isolasi energi
Domain	Flow dynamics	Energy boundary
Kondisi normal	Menutup (ideal)	Terbuka
Kondisi trip	Tidak utama	Menutup cepat dan pasti

Penegasan Arsitektur Sistem

Bypass valve menjaga sistem tetap stabil dalam domain operasi.
Shut-off valve memastikan sistem benar-benar terputus dari sumber energi saat keluar dari domain operasi.

Dengan kata lain:

bypass valve bekerja di dalam sistem
shut-off valve bekerja di batas sistem

Keduanya tidak saling menggantikan, karena bekerja pada dua level yang berbeda: operational stability vs energy isolation boundary.

Seal Gas dan Lube Oil: Parameter Pendukung yang Tidak Boleh Diabaikan

Di luar keseimbangan energi proses, ada dua sistem pendukung yang dapat menghasilkan gejala yang sama di lapangan — khususnya pada vibrasi dan bearing temperature — dan sering luput dari perhatian dalam diagnostik awal.

Dengan kata lain:

Tidak semua vibrasi berasal dari ketidakseimbangan energi, tetapi semua kemungkinan harus dipisahkan dengan jelas sebelum tindakan diambil.

Seal gas pressure:

Seal gas berfungsi mencegah process gas masuk ke area bearing. Jika tekanan seal gas tidak mencukupi atau tidak stabil:

process gas dapat merembes masuk ke bearing area
karakteristik pelumasan terganggu
bearing temperature naik dan vibrasi meningkat

Lube oil:

Tekanan dan kondisi oli secara langsung menentukan kualitas film pelumasan di bearing. Jika tekanan oli terlalu rendah atau oli terkontaminasi:

film oli tidak terbentuk sempurna
terjadi kontak metal-to-metal
bearing temperature naik dan vibrasi meningkat

Perlu diperhatikan bahwa gejala yang muncul dari masalah seal gas atau lube oil dapat sangat mirip dengan gejala akibat ketidakseimbangan energi, seperti:

peningkatan vibrasi
kenaikan bearing temperature
operasi yang terasa tidak stabil

Sebelum menyimpulkan bahwa vibrasi berasal dari ketidakseimbangan energi atau masalah mekanis struktural, kondisi seal gas dan lube oil perlu diperiksa terlebih dahulu — keduanya adalah variabel independen yang dapat menghasilkan gejala serupa.

Prosedur Startup: Melewati Critical Speed dengan Benar

Contoh sistem dengan dua critical speed (misal 15.500 dan 19.000 RPM):

Fase 1 — Menuju Critical Speed Pertama

Naikkan nozzle dengan cepat
Lewati critical speed pertama sesegera mungkin
Bypass masih terbuka

Fase 2 — Antar Critical Speed

Mulai koordinasi nozzle dan bypass secara proporsional
Hindari berlama-lama di zona ini

Fase 3 — Setelah Critical Speed Kedua

Semua critical speed terlewati
Koordinasi penuh, nozzle naik proporsional dengan bypass closing
Target: bypass full close

Yang berbahaya bukan melewati critical speed, tetapi terlalu lama berada di dalamnya.

Untuk sistem dengan satu critical speed, prosedur menjadi dua fase — cepat melewati critical speed, lalu koordinasi penuh hingga bypass full close.

Monitoring Berbasis Rasio

Pendekatan monitoring terbaik adalah membandingkan rasio aktual dengan design secara bersamaan untuk kedua sisi:

Parameter	Formula	Makna
Rasio Ekspansi	$ER = P_{inlet} / P_{outlet}$	Performa expander
Rasio Kompresi	$CR = P_{discharge} / P_{suction}$	Performa booster

Namun yang lebih powerful adalah melihat hubungan antara ER dan CR, bukan hanya masing-masing secara terpisah. Pola korelasi keduanya memberikan informasi diagnostik yang jauh lebih kaya:

Pola	Interpretasi
ER naik, CR tidak mengikuti	Energy mismatch — energi expander tidak terserap optimal oleh booster
ER stabil, CR naik	Kemungkinan masalah downstream booster
ER turun, CR turun bersamaan	Pergeseran kondisi operasi secara keseluruhan — periksa inlet expander dan nozzle
ER & CR keduanya menyimpang dari design	Sistem di luar design envelope — kembalikan ke profil vendor

Pendekatan berbasis pola korelasi ini adalah langkah menuju condition-based monitoring yang lebih proaktif.

Panduan Interpretasi untuk Operator

Kondisi	Kemungkinan Penyebab	Indikasi Vibrasi	Tindakan
ER tinggi	P inlet tinggi / outlet rendah	Meningkat	Periksa upstream
CR tinggi	Discharge tinggi	Meningkat	Periksa downstream
ER & CR menyimpang	Di luar design envelope	Instability	Kembali ke profil vendor
Speed fluktuatif	Ketidakseimbangan energi	Fluktuatif	Evaluasi nozzle & bypass

Estimasi Flow

Pendekatan berbasis keseimbangan energi dengan asumsi proses isentropik dan efisiensi konstan:

$$\dot{m}_{expander} = \frac{W_{expander}}{\Delta h} \times \frac{1}{\eta_{expander}}$$

$$\dot{m}_{booster} = \frac{W_{booster}}{\Delta h} \times \eta_{booster}$$

Catatan penting:

Formula ini valid dengan asumsi medium gas yang digunakan konsisten dengan kondisi design. Jika terjadi perubahan komposisi gas yang signifikan, diperlukan koreksi terhadap density atau molecular weight.
Estimasi paling akurat di sekitar design point.
Efisiensi berubah terhadap flow dan speed — pada kondisi low load, estimasi menjadi kurang presisi.

Implementasi di DCS

Python

# Input
P_exp_inlet     = 6.0   # bar abs
P_exp_outlet    = 1.4   # bar abs
P_bst_suction   = 5.5   # bar abs
P_bst_discharge = 6.2   # bar abs

# Design
ER_design = 6.0 / 1.4
CR_design = 6.2 / 5.5

# Rasio aktual (dengan proteksi division by zero)
ER_actual = P_exp_inlet / P_exp_outlet if P_exp_outlet > 0 else 0
CR_actual = P_bst_discharge / P_bst_suction if P_bst_suction > 0 else 0

# Deviasi terhadap design (%)
ER_deviation = (ER_actual - ER_design) / ER_design * 100 if ER_design > 0 else 0
CR_deviation = (CR_actual - CR_design) / CR_design * 100 if CR_design > 0 else 0

print(f"ER Aktual : {ER_actual:.3f} (Design: {ER_design:.3f}, Deviasi: {ER_deviation:.2f}%)")
print(f"CR Aktual : {CR_actual:.3f} (Design: {CR_design:.3f}, Deviasi: {CR_deviation:.2f}%)")

📎 Bisa langsung dicoba di: 👉 Python Online Compiler

Structured Text (PLC / DCS)

(* Input Variables *)
VAR
    P_EXP_INLET     : REAL;  (* Tekanan inlet expander, bar abs *)
    P_EXP_OUTLET    : REAL;  (* Tekanan outlet expander, bar abs *)
    P_BST_SUCTION   : REAL;  (* Tekanan suction booster, bar abs *)
    P_BST_DISCHARGE : REAL;  (* Tekanan discharge booster, bar abs *)
    ER_DESIGN       : REAL;  (* Rasio ekspansi design *)
    CR_DESIGN       : REAL;  (* Rasio kompresi design *)
END_VAR

(* Output Variables *)
VAR
    ER_ACTUAL    : REAL;  (* Rasio ekspansi aktual *)
    CR_ACTUAL    : REAL;  (* Rasio kompresi aktual *)
    ER_DEVIATION : REAL;  (* Deviasi ER, % *)
    CR_DEVIATION : REAL;  (* Deviasi CR, % *)
END_VAR

(* Kalkulasi Rasio *)
IF P_EXP_OUTLET > 0.0 THEN
    ER_ACTUAL := P_EXP_INLET / P_EXP_OUTLET;
END_IF;

IF P_BST_SUCTION > 0.0 THEN
    CR_ACTUAL := P_BST_DISCHARGE / P_BST_SUCTION;
END_IF;

(* Deviasi terhadap design *)
IF ER_DESIGN > 0.0 THEN
    ER_DEVIATION := (ER_ACTUAL - ER_DESIGN) / ER_DESIGN * 100.0;
END_IF;

IF CR_DESIGN > 0.0 THEN
    CR_DEVIATION := (CR_ACTUAL - CR_DESIGN) / CR_DESIGN * 100.0;
END_IF;

Kesimpulan

Booster expander bukan dua mesin terpisah, melainkan satu sistem energi yang saling terikat.

Expander adalah sumber energi. Booster adalah beban yang mengikuti. Energi dari expander adalah batas atas yang tidak bisa dilanggar — ini bukan soal kontrol, tetapi hukum fisika.

Parameter utama yang harus dijaga adalah rasio — rasio ekspansi menentukan performa expander, rasio kompresi menentukan performa booster. Temperatur bukan target utama, melainkan konsekuensi dari rasio yang tercapai.

Opening nozzle adalah satu tuas yang menggeser seluruh keseimbangan sistem — mempengaruhi speed, flow, rasio, dan temperatur secara bersamaan.

Bypass valve harus berada dalam kondisi full close saat operasi normal. Jika tidak, energi terbuang dan kondisi operasi yang sebenarnya menjadi tidak terlihat.

Profil vendor bukan sekadar referensi, melainkan peta keseimbangan energi yang harus dijaga.

Dengan memahami hubungan ini dan mengimplementasikan monitoring berbasis rasio di DCS, operator tidak hanya membaca angka — tetapi memahami kondisi sistem secara menyeluruh.

Booster expander bukan sistem yang bisa dikontrol secara bebas — ia adalah sistem yang harus dipahami batas energinya. Operator yang memahami energi tidak menunggu alarm untuk bereaksi; mereka membaca perilaku mesin dan mengenali ketidakseimbangan sebelum menjadi masalah.

Pada akhirnya, yang dijaga bukan sekadar parameter — tetapi keseimbangan energi sistem secara keseluruhan.

Distribusi Flow Expander dan Booster dalam Sistem Cryogenic

2026-02-18T14:32:30+00:00

Dalam sistem cryogenic atau gas separation modern, expander dan booster bekerja sebagai satu kesatuan mekanis. Expander berfungsi sebagai penggerak (motor) yang menghasilkan energi dari ekspansi gas dingin, sementara booster bertindak sebagai beban berupa centrifugal compressor yang mengonsumsi energi tersebut. Keseimbangan keduanya menentukan stabilitas operasi, efisiensi energi, dan umur peralatan.

Landasan Teori

Expander: menurunkan temperatur gas melalui ekspansi isentropik, sekaligus menghasilkan energi mekanis pada shaft. Energi ini digunakan untuk menggerakkan booster.
Booster: menaikkan tekanan gas (umumnya recycle nitrogen atau udara kering) agar sesuai dengan kebutuhan proses. Beban booster harus seimbang dengan energi expander agar tidak terjadi mismatch.
Distribusi Flow: Rasio flow expander terhadap booster menjadi indikator utama apakah energi yang dihasilkan expander cukup, berlebih, atau kurang dibandingkan kebutuhan booster.
Rasio Kompresi Booster: perbandingan tekanan keluar absolute (discharge abs) dan tekanan masuk absolute (suction abs) booster. Rasio ini menentukan beban kerja booster. Jika terlalu tinggi sementara energi expander kurang, booster bisa mendekati surge dan menimbulkan vibrasi.
Rasio Ekspansi Expander: perbandingan tekanan masuk absolute dan tekanan keluar absolute expander. Rasio ini menentukan seberapa besar energi mekanis yang dihasilkan expander. Jika terlalu tinggi, energi berlebih bisa memicu vibrasi akibat torsi berlebihan pada shaft.

📌 Catatan: semua rasio kompresi dan ekspansi harus dihitung dari tekanan absolut, bukan tekanan gauge.

Dengan demikian, matching energi harus dilihat secara holistik: flow ratio, rasio kompresi, dan rasio ekspansi.

Contoh Data Operasi dan Analisis Flow

Mode	Flow Expander (Nm³/h)	Flow Booster (Nm³/h)	Rasio Exp/Booster	Interpretasi Utama
1	38.300	56.100	0,683	Expander dominan, energi spesifik tinggi, perlu monitoring vibrasi
2	37.000	57.473	0,644	Rasio terendah, booster lebih dominan, efisiensi expander menurun
3	36.700	55.964	0,656	Kondisi menengah, relatif stabil
4	35.800	55.547	0,645	Flow expander terendah, booster stabil, efisiensi sistem sedikit turun

Catatan Penting

Rasio <1 dalam contoh ini adalah kondisi normal: booster selalu menerima flow lebih besar dibanding expander.
Rasio 0,64–0,68 sesuai dengan desain dalam contoh ini, di mana expander tidak boleh terlalu dominan.
Energi berlebih (expander dominan) → vibrasi karena torsi berlebihan.
Energi kurang (booster dominan) → vibrasi karena booster mendekati surge.
Rasio kompresi dan ekspansi harus dijaga di sekitar nilai desain agar matching energi tetap terjaga.

Kesimpulan

Distribusi flow expander–booster adalah indikator utama keseimbangan energi, lebih penting daripada sekadar melihat flow absolut di booster.
Rasio kompresi booster dan rasio ekspansi expander harus selalu diperhatikan bersama flow ratio, karena ketiganya membentuk neraca energi yang menjaga stabilitas operasi.
Vibrasi bisa muncul baik saat energi expander berlebih maupun kurang, sehingga pemantauan harus dilakukan secara holistik: flow ratio, kompresi, ekspansi, serta kondisi mekanis (bearing, shaft).
Dengan menjaga distribusi flow dan rasio sesuai desain, sistem cryogenic dapat beroperasi stabil, efisien, dan aman.

Menyiapkan Advantech UNO-220 sebagai Edge Device Industri

2026-01-08T01:51:59+00:00

1. Pendahuluan

Dokumentasi ini menyajikan panduan lengkap untuk menyiapkan Advantech UNO-220-P4N2AE — sebuah industrial gateway kit (chassis + HAT I/O) yang dirancang untuk dipasangi Raspberry Pi 4 Model B — agar siap berfungsi sebagai edge device industri.

Panduan ini dirancang untuk memastikan UNO‑220 mampu:

Beroperasi secara mandiri di lapangan, tanpa ketergantungan pada infrastruktur tambahan,
Terhubung aman ke server pusat melalui jaringan terenkripsi,
Menjalankan fungsi pengolahan data real‑time sekaligus visualisasi menggunakan Node‑RED (v4.x dengan Node.js v22 LTS) dan Rapid SCADA 6.4.3.

--- config: theme: neutral --- flowchart TD A["DCS / PLC
(Modbus RTU)"]:::legacy subgraph Integrasi direction LR B["Modbus Gateway"]:::gateway C["Node-RED"]:::nodered D["Rapid SCADA"]:::scada E["SCADA Grafana Proxy"]:::proxy end F["OS & Hardening"]:::os G["Backup & Recovery"]:::backup H["Deployment"]:::deploy I["ZeroTier"]:::network J["Server Integrasi"]:::server A --> B B --> C --> I B --> D --> E Integrasi --> F --> G --> H --> Integrasi E --> I --> J classDef legacy fill:#efefef,stroke:#999,stroke-width:2px,color:#000 classDef hardware fill:#f4cccc,stroke:#cc0000,stroke-width:2px,color:#000 classDef os fill:#cfe2f3,stroke:#1155cc,stroke-width:2px,color:#000 classDef nodered fill:#d9ead3,stroke:#38761d,stroke-width:2px,color:#000 classDef scada fill:#fff2cc,stroke:#bf9000,stroke-width:2px,color:#000 classDef proxy fill:#ead1dc,stroke:#741b47,stroke-width:2px,color:#000,stroke-dasharray:4 3 classDef gateway fill:#e2efd9,stroke:#274e13,stroke-width:2px,color:#000,stroke-dasharray:4 3 classDef network fill:#d0e0e3,stroke:#134f5c,stroke-width:2px,color:#000 classDef backup fill:#e6e6e6,stroke:#666666,stroke-width:2px,color:#000 classDef deploy fill:#fce5cd,stroke:#e69138,stroke-width:2px,color:#000 classDef server fill:#d9d2e9,stroke:#351c75,stroke-width:2px,color:#000

Alur Terpadu UNO-220 untuk Integrasi Edge Industri yang Andal

Seluruh tahapan — mulai dari aktivasi fitur perangkat keras, penguatan keamanan sistem operasi, hingga instalasi perangkat lunak produksi — telah digabungkan dalam satu dokumen terpadu. Dengan demikian, panduan ini dapat dijadikan standar operasional untuk deployment UNO‑220 di lingkungan industri, tanpa perlu merujuk ke dokumen eksternal tambahan.

Advantech UNO‑220 sebagai edge device industri

2. Persiapan Perangkat

2.1 Perangkat Keras

Komponen	Spesifikasi / Catatan	Alasan / Risiko
Main Unit	Advantech UNO‑220 (kit untuk Raspberry Pi 4 Model B, IP40, varian P4N2AE mendukung PoE)	Form factor industri, rugged, siap dipasang di panel; casing melindungi dari debu & getaran.
Media Penyimpanan	MicroSD industrial‑grade ≥ 32 GB. Pilih model dengan endurance pSLC/SLC, PLP/ECC bila tersedia.	Endurance tinggi, tahan suhu ekstrem, mencegah korupsi data akibat siklus tulis intensif.
Catu Daya	12–24 VDC atau PoE (802.3at/PoE+ bila beban tinggi). Rencanakan margin 20–30% di atas beban terukur.	Konsumsi bergantung konfigurasi (model RPi4, addon USB/serial, beban CPU).
RTC	Epson RX‑8010SJ‑B (dengan battery backup)	Menjamin timestamp akurat meski tanpa NTP; penting untuk audit log & histori data.
I/O Expander	TI TCA9554 (alamat I²C 0x27)	Menambah GPIO untuk kontrol/monitoring eksternal.
TPM	Infineon OPTIGA TPM SLB9670	Mendukung secure boot, enkripsi, integritas sistem.
Jaringan	Ethernet LAN (1 GbE) untuk konfigurasi awal; ZeroTier untuk manajemen jarak jauh.	Ethernet stabil untuk setup awal; ZeroTier memberi VPN overlay aman tanpa port publik.

2.2 Perangkat Lunak

Ubuntu Server arm64 terbaru (contoh: 25.10 dengan kernel 6.17+ saat penulisan).
Untuk commissioning/testing gunakan rilis interim; untuk produksi gunakan rilis LTS (24.04 LTS yang tersedia, atau 26.04 LTS setelah rilis stabil pada 23 April 2026).
Tool flashing: Raspberry Pi Imager atau Balena Etcher → tulis image OS ke microSD.
Akses jaringan & SSH dari komputer host → konfigurasi awal headless (tanpa monitor/keyboard).

Referensi tambahan: periksa juga panduan resmi Ubuntu untuk Raspberry Pi untuk memastikan image, kernel, dan metode flashing sesuai dengan rilis terbaru.

Upgrade ke Ubuntu 26.04 LTS
Setelah rilis stabil tersedia (sudo do-release-upgrade -c):

Backup penuh sistem (lihat Bab 11) dan uji di staging.
Update paket: sudo apt update && sudo apt full-upgrade.
Pastikan tool upgrade: sudo apt install update-manager-core.
Jalankan upgrade: sudo do-release-upgrade → konfirmasi.
Reboot, lalu verifikasi:
- lsb_release -a (versi Ubuntu)
- uname -r (kernel ARM64)
- test service (Node‑RED, ZeroTier, Rapid SCADA).

Catatan: Hindari opsi -d (development). Tunggu path resmi Canonical agar kernel & driver ARM64 tetap kompatibel dengan UNO‑220.

2.3 Struktur Deployment (Timeline 5 Hari)

Untuk memastikan proses commissioning berjalan konsisten dan dapat diaudit, berikut struktur deployment UNO‑220 selama 5 hari. Setiap langkah telah disusun agar modular, dapat direplikasi, dan mendukung validasi bertahap.

--- config: theme: neutral --- timeline title Timeline Deployment UNO-220 (Hari 1–4) section Hari 1 - Dasar dan Strukturisasi 2025-11-03 : Persiapan perangkat & verifikasi PoE (UNO-220 casing industrial, microSD pSLC/SLC, Raspberry Pi 4B) : Flash Ubuntu Server 25.10 + aktifkan SSH : Boot awal, login SSH, ubah password, set zona waktu : Update sistem + pasang overlay RTC, TPM, Expander : Edit config.txt, reboot, uji RTC/I²C/TPM : Nonaktifkan serial console ttyS0 (untuk RTU) : Instal ZeroTier + join network, uji ping antar node section Hari 2 - Tools dan Integrasi 2025-11-04 : Setup GPIO rules + grup gpio : Uji LED PL1 manual via gpioset : Instal Node-RED v4.x + konfigurasi logging : Flow monitoring sistem + heartbeat LED PL1 : Instal Rapid SCADA 6.4.3 + Nginx reverse proxy : Integrasi CSV monitoring + test curl localhost : Instal SCADA Grafana proxy + verifikasi endpoint JSON : Instal mbusd sebagai gateway Modbus TCP–RTU via RS-485 section Hari 3 - Hardening, Backup, & Validasi 2025-11-05 : Setup SSH key-based login, nonaktifkan login password : Konfigurasi UFW + Fail2Ban (whitelist IP ZeroTier) : Sinkronisasi RTC + aktifkan unattended-upgrades + hold kernel : Nonaktifkan service tidak terpakai : Atur EEPROM boot order : Manual backup + auto backup + cron : Uji rsync ke USB/NAS + logrotate : Uji recovery Node-RED/SCADA/ZeroTier : Checklist audit end-to-end section Hari 4 - Deployment 2025-11-06 : Pasang fisik UNO-220 di panel lapangan : Koneksi RS-485, ethernet, dan power PoE/DC : Uji dashboard Node-RED, SCADA, Modbus TCP, Grafana full : Dokumentasi akhir + handover checklist

3. Instalasi Ubuntu Server 25.10

Rekomendasi Spesifikasi microSD Industrial‑Grade

Parameter	Nilai Minimum
Kelas Speed	Class 10 / UHS‑I
Kapasitas	≥ 32 GB
NAND Type	pSLC / Industrial SLC
Operating Temp.	‑40°C hingga +85°C
Endurance	≥ 30K write cycles, Power-Loss Protection (PLP) atau ECC
Brand	Transcend Industrial, Swissbit, Apacer Industrial, Innodisk

Langkah Instalasi

Unduh image OS
Ambil image Ubuntu Server 25.10 (arm64) dari situs resmi Ubuntu.
Tulis image ke microSD
Gunakan Raspberry Pi Imager atau Balena Etcher.
Aktifkan SSH
Setelah flashing selesai, mount partisi boot lalu buat file kosong bernama ssh:
```
touch /media//boot/ssh
```
Pasang microSD & hubungkan perangkat
Masukkan microSD ke UNO‑220, hubungkan kabel Ethernet dan catu daya.
Temukan alamat IP
- Via router/DHCP lease
- Atau gunakan:
```
sudo nmap -sn 192.168.1.0/24
```
Login pertama via SSH
```
ssh ubuntu@
```
Password default: ubuntu (akan diminta ganti saat login pertama).

Set zona waktu
Pilih sesuai lokasi operasional:

Wilayah	Zona Waktu	Pilihan
Sumatra, Jawa, Kalimantan Barat/Tengah	WIB (UTC+7)	Asia/Jakarta
Bali, Nusa Tenggara, Kalimantan Selatan/Timur	WITA (UTC+8)	Asia/Makassar
Maluku, Papua	WIT (UTC+9)	Asia/Jayapura

Contoh:

sudo timedatectl set-timezone Asia/Jakarta
timedatectl status

Update sistem

sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y && sudo apt clean

Troubleshooting

IP tidak terdeteksi → gunakan arp -a atau nmap untuk scanning subnet.
SSH gagal → pastikan file ssh ada di partisi boot, atau gunakan monitor + keyboard sementara.
MicroSD lambat → uji dengan:
```
sudo hdparm -tT /dev/mmcblk0
```

4. Aktivasi Fitur Hardware UNO-220

Sebelum mengaktifkan fitur hardware UNO-220, pastikan sistem memiliki paket dasar untuk kompilasi dan pengambilan kode sumber. Jalankan perintah berikut untuk menginstal semua dependensi penting:

sudo apt update
sudo apt install -y build-essential git curl device-tree-compiler

Kloning terlebih dahulu repository yang berisi berkas device tree overlay untuk hardware UNO-220:

git clone --depth=1 https://github.com/kumajaya/uno-220-poe.git
cd uno-220-poe

4.1 Kompilasi Semua Overlay

Compile kedua overlay secara berurutan:

sudo dtc -@ -I dts -O dtb dts/i2c-rtc-overlay.dts -o /boot/firmware/current/overlays/i2c-rtc-mod.dtbo
sudo dtc -@ -I dts -O dtb dts/tpm-slb9670-overlay.dts -o /boot/firmware/current/overlays/tpm-slb9670-mod.dtbo

I/O Expander TCA9554 gunakan overlay standar pca953x.

Verifikasi:

ls /boot/firmware/current/overlays/ | grep -E 'i2c-rtc-mod|tpm-slb9670-mod'

4.2 Update config.txt

Catatan: Editor teks nano digunakan untuk mengedit file konfigurasi di terminal.

Gunakan panah arah untuk berpindah baris.

Tekan Ctrl + O untuk menyimpan, lalu Enter, dan Ctrl + X untuk keluar.

Edit /boot/firmware/config.txt:

sudo nano /boot/firmware/config.txt

Tambahkan baris-baris ini di akhir file:

# RTC Epson RX-8010
dtoverlay=i2c-rtc-mod,rx8010
# TI TCA9554
dtoverlay=pca953x,addr=0x27
# Infineon TPM SLB9670
dtoverlay=tpm-slb9670-mod,cs=0x00

Simpan, lalu reboot:

sudo reboot

4.3 Uji RTC (Epson RX-8010SJ-B)

sudo apt install util-linux-extra -y
sudo hwclock -r --verbose
sudo hwclock -w --verbose
timedatectl status

4.4 Uji I/O Expander (TI TCA9554)

Uji (hubungkan kabel dari GPIO 0 ke 1 untuk loopback):

sudo apt install gpiod -y
gpiodetect
gpioinfo
gpioset 2 0=0 && gpioget 2 1  # Off
gpioset 2 0=1 && gpioget 2 1  # On

Note: Jika ingin mengakses TCA9554 langsung dari Node-RED menggunakan node-red-contrib-tca9554, pastikan driver kernel gpio_pca953x tidak aktif.

Untuk akses sementara:
```
sudo modprobe -r gpio_pca953x
```
Untuk menonaktifkan permanen, tambahkan tanda # di depan baris dtoverlay=pca953x,addr=0x27 pada /boot/firmware/config.txt.

4.5 Uji Trusted Platform Module (SLB9670)

sudo apt install tpm2-tools -y
tpm2_getrandom 8 | xxd -p
tpm2_getrandom 16 | xxd -p
tpm2_getrandom 32 | xxd -p

4.6 GPIO & LED PL1

Untuk dapat mengendalikan PL1 GPIO LED di UNO‑220 dibutuhkan kombinasi konfigurasi udev rules + dependensi Python agar Node‑RED dapat melakukan akses GPIO tanpa hak root.

Tambahkan aturan udev di /etc/udev/rules.d/45-gpio.rules:

KERNEL=="gpiochip*", GROUP="gpio", MODE="0660"
KERNEL=="gpiomem",   GROUP="gpio", MODE="0660"

Reload rules:

sudo udevadm control --reload-rules && sudo udevadm trigger

Tambahkan user ke grup gpio:
```
sudo usermod -aG gpio ubuntu
```

Install dependensi Python untuk Node‑RED GPIO node:

sudo apt install python3-rpi.gpio -y  # Untuk Node-RED GPIO

LED PL1 (GPIO12, pin 32 pada header Raspberry Pi, terhubung ke gpiochip0) dapat dikendalikan via Node‑RED node rpi-gpio out.
Pengujian manual dapat dilakukan dengan perintah:

gpioset 0 12=1   # LED ON
gpioset 0 12=0   # LED OFF

4.7 Serial Console (RS‑232/RS‑485)

UNO‑220 mendukung koneksi fisik RS‑232 dan RS‑485 yang dipetakan ke /dev/ttyS0. Secara default, /dev/ttyS0 digunakan sebagai console debug oleh kernel. Agar port ini dapat digunakan aplikasi lain (misalnya komunikasi dengan perangkat eksternal atau Modbus RTU, termasuk classic DCS), hapus parameter berikut dari /boot/firmware/cmdline.txt:

console=serial0,115200

Simpan perubahan lalu reboot.

Pengujian koneksi serial:

sudo apt install minicom -y
minicom -D /dev/ttyS0 -b 115200

Troubleshooting Hardware:

Jika overlay gagal terpasang:
```
dmesg | grep i2c
i2cdetect -y 1
```
Setelah melakukan perubahan pada config.txt, lakukan reboot agar overlay aktif.
Gunakan ls /boot/firmware/current/overlays/ untuk memastikan file .dtbo hasil compile tersedia.

5. Instalasi ZeroTier

ZeroTier digunakan untuk menyediakan konektivitas aman antar perangkat tanpa perlu membuka port publik. UNO‑220 akan bergabung ke jaringan virtual ZeroTier dan dapat diakses menggunakan alamat IP internal ZeroTier.

Instalasi Paket

curl -s https://install.zerotier.com | sudo bash
sudo systemctl enable zerotier-one
sudo systemctl start zerotier-one

Verifikasi instalasi:

zerotier-cli info

Output normal: 200 info ONLINE

Join ke Network
```
sudo zerotier-cli join 
```
- adalah ID jaringan yang sudah dibuat di controller (publik atau self‑hosted).
- Cek status:
```
zerotier-cli listnetworks
```
Otorisasi Node
- Jika menggunakan controller publik (my.zerotier.com): login ke dashboard, pilih network, lalu authorize .
- Jika menggunakan controller self‑hosted: lakukan otorisasi node melalui web UI atau API controller internal. Pastikan node muncul di daftar anggota network, lalu tandai sebagai authorized.
Verifikasi Koneksi
- Cek interface ZeroTier:
```
ip addr show zt*
```
- Gunakan IP ZeroTier untuk SSH:
```
ssh ubuntu@
```
- Uji konektivitas antar node:
```
ping 
```
Catatan Keamanan
- Gunakan IP ZeroTier untuk remote SSH, bukan IP publik.
- Pastikan firewall ufw (lihat Bab 10) hanya membuka port yang diperlukan (22, 80, 443, 9993, 1880, 10002, 3000).
- ZeroTier menggunakan UDP port 9993; pastikan tidak diblokir di perangkat maupun firewall jaringan.
- Untuk self‑hosted controller, pastikan server controller terlindungi dengan TLS/HTTPS dan hanya dapat diakses oleh admin.
Troubleshooting
- Jika join gagal:
```
journalctl -u zerotier-one -f
```
- Jika node tidak muncul di controller:
  - Pastikan network ID benar.
  - Pastikan perangkat dapat menjangkau server controller (cek UDP 9993).
- Jika IP ZeroTier tidak muncul:
```
sudo systemctl restart zerotier-one
zerotier-cli listnetworks
```

6. Instalasi Node‑RED

Update sistem
```
sudo apt update && sudo apt upgrade -y
```
Jalankan installer resmi Node‑RED
Script ini akan menghapus instalasi lama, memasang Node.js sesuai versi yang dipilih, menginstal Node‑RED terbaru, serta menyiapkan service systemd.

Pilih Node.js 22 LTS dengan opsi --node22 dan tambahkan opsi --pi untuk sekaligus memasang node khusus Raspberry Pi (GPIO, I²C, dsb.):
```
bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered) --confirm-root --node22 --pi
```

Aktifkan service

sudo systemctl enable nodered.service
sudo systemctl start nodered.service

Akses editor
Buka browser ke alamat:
http://:1880

6.1 Amankan Akses Node‑RED

Edit file ~/.node-red/settings.js:

adminAuth: {
    type: "credentials",
    users: [{
        username: "admin",
        password: "",
        permissions: "*"
    }]
},

Untuk mengisi nilai pada konfigurasi settings.js, jalankan perintah berikut:

node-red admin hash-pw

Salin hasil hash ke field password pada konfigurasi adminAuth.

Setelah itu, restart service agar perubahan aktif:

sudo systemctl restart nodered.service

6.2 Aktivasi Logging untuk Monitoring I/O dan Deteksi Error Hardware

Edit ~/.node-red/settings.js untuk mengaktifkan logging detail. Logging ini berguna untuk:

Monitoring I/O: menangkap event GPIO, I²C expander (TCA9554), dan komunikasi serial.
Deteksi error hardware: misalnya kegagalan RTC (RX‑8010) atau TPM (SLB9670).
Audit: mencatat perubahan konfigurasi dan akses API.

logging: {
    console: {
        // Gunakan "info" untuk operasi normal
        // Naikkan ke "debug" saat commissioning
        // Gunakan "trace" hanya untuk troubleshooting detail
        level: "info",   // "debug" untuk detail commissioning, "trace" untuk troubleshooting mendalam
        metrics: true,   // Log node events (receive/send) dan memory usage (monitoring resource hardware)
        audit: true      // Log API access untuk melacak perubahan konfigurasi
    }
}

Catatan Operasional:

Metrics: mencatat event inject/receive/send, misalnya perubahan status GPIO expander.
Memory logs: setiap 15 detik, Node‑RED mencatat heap usage. Berguna untuk mendeteksi potensi overload pada RPi4B ARM64.
Level rekomendasi:
- info → operasi normal (default).
- debug → commissioning, validasi hardware.
- trace → troubleshooting detail, gunakan hanya sementara karena log akan sangat besar.

Restart service agar konfigurasi aktif:

sudo systemctl restart nodered.service

Melihat log:

sudo journalctl -u nodered.service -f
# atau
node-red-log

Filter hardware issues:

sudo journalctl -u nodered.service | grep "error\|I/O"

Troubleshooting:

Jika terjadi error npm terkait memori, jalankan Node‑RED dengan opsi:
```
node-red-pi --max-old-space-size=512
```
Semua log tersimpan di journal systemd, sehingga tetap terintegrasi dengan mekanisme logrotate.

6.3 System Resource Monitoring (CPU Temperature, Memory Usage, CPU Load, Disk Usage, Uptime) dengan Node‑RED

Untuk memantau metrik sistem secara real‑time (CPU Temperature, Memory Usage, CPU Load, Disk Usage, Uptime), kita gunakan exec node di Node‑RED untuk menjalankan perintah Linux, lalu visualisasikan hasilnya di dashboard dan simpan ke file CSV untuk integrasi dengan Rapid SCADA (lihat 7.2).

Threshold alert yang disarankan:

Temperature > 80 °C
CPU Load > 2.0 (1‑min average)
Memory Usage > 80%
Disk Usage > 80%

Setup visudo untuk vcgencmd
Agar Node‑RED bisa membaca suhu CPU via sudo vcgencmd tanpa prompt password:
```
sudo visudo
```
Tambahkan di akhir:
```
ubuntu ALL=(ALL) NOPASSWD: /usr/bin/vcgencmd
```
Simpan → keluar. Uji:
```
sudo vcgencmd measure_temp
# contoh output: temp=45.2°C
```
Instal Node Tambahan
Di editor Node‑RED (http://:1880), buka Menu → Manage palette → Install:
- node-red-dashboard (untuk UI gauge/chart)
Restart Node‑RED setelah instalasi.

Flow Lengkap
Flow berikut melakukan polling setiap 10 detik, mengeksekusi perintah sistem, menggabungkan hasil, menuliskannya ke CSV, dan menampilkan di dashboard.

Langkah Import:

Salin JSON di bawah.
Di Node‑RED editor, pilih Menu → Import → Clipboard.
Paste JSON, lalu klik Import.

[{"id":"fe919f4f898a361a","type":"inject","z":"2aa78c88.04da44","name":"Poll 10s","props":[{"p":"payload","v":"","vt":"str"},{"p":"topic","v":"","vt":"str"}],"repeat":"10","once":true,"onceDelay":"5","x":180,"y":240,"wires":[["fca6b8400889d4f3","27f74b0ccf05dca3","231f57b96b131413","450425f381c32b46","01694ddd54ec6a73"]]},{"id":"f1188809e56ab2de","type":"exec","z":"2aa78c88.04da44","command":"nproc --all","addpay":"","append":"","timer":"","winHide":false,"name":"Get CPU Cores","x":400,"y":220,"wires":[["d204093578cae4b4"],[],[]]},{"id":"fca6b8400889d4f3","type":"exec","z":"2aa78c88.04da44","command":"bash -c 'if sudo command -v vcgencmd >/dev/null 2>&1; then sudo vcgencmd measure_temp | grep -o \"[0-9]*\\.[0-9]*\"; else awk \"{printf(\\\"%.1f\\\", \\$1/1000)}\" /sys/class/thermal/thermal_zone0/temp; fi'","addpay":"","append":"","timer":"","winHide":false,"name":"CPU Temp","x":390,"y":100,"wires":[["23fd137e13f7dd24"],[],[]]},{"id":"23fd137e13f7dd24","type":"change","z":"2aa78c88.04da44","name":"Set Topic Temp","rules":[{"t":"set","p":"topic","pt":"msg","to":"Temperature","tot":"str"}],"x":620,"y":100,"wires":[["71d65c821a231f67"]]},{"id":"27f74b0ccf05dca3","type":"exec","z":"2aa78c88.04da44","command":"awk '{print $1}' /proc/loadavg","addpay":"","append":"","timer":"","winHide":false,"name":"CPU Load","x":390,"y":160,"wires":[["a75ecd76131c54e9"],[],[]]},{"id":"a75ecd76131c54e9","type":"change","z":"2aa78c88.04da44","name":"Set Topic Load","rules":[{"t":"set","p":"topic","pt":"msg","to":"Load","tot":"str"},{"t":"set","p":"payload","pt":"msg","to":"($number($trim(payload)) ? $number($trim(payload)) : 0) / ($flowContext(\"cpu_cores\") ? $flowContext(\"cpu_cores\") : 4) * 100.0 ~> $round(2)\t","tot":"jsonata"}],"x":620,"y":160,"wires":[["71d65c821a231f67"]]},{"id":"231f57b96b131413","type":"exec","z":"2aa78c88.04da44","command":"free | awk '/Mem/ {printf(\"%.2f\", $3/$2 * 100.0)}'","addpay":"","append":"","timer":"","winHide":false,"name":"Memory Usage","x":400,"y":280,"wires":[["fe468f39b7e6bb81"],[],[]]},{"id":"fe468f39b7e6bb81","type":"change","z":"2aa78c88.04da44","name":"Set Topic Mem","rules":[{"t":"set","p":"topic","pt":"msg","to":"Memory","tot":"str"}],"x":620,"y":280,"wires":[["71d65c821a231f67"]]},{"id":"450425f381c32b46","type":"exec","z":"2aa78c88.04da44","command":"df -h / | awk 'NR==2 {print $5}' | tr -d '%' | awk '{print $1 + 0}'","addpay":"","append":"","timer":"","winHide":false,"name":"Disk Usage","x":390,"y":400,"wires":[["49baac92701386dd"],[],[]]},{"id":"49baac92701386dd","type":"change","z":"2aa78c88.04da44","name":"Set Topic Disk","rules":[{"t":"set","p":"topic","pt":"msg","to":"Disk","tot":"str"},{"t":"set","p":"payload","pt":"msg","to":"$trim(payload)","tot":"jsonata"}],"x":620,"y":400,"wires":[["71d65c821a231f67"]]},{"id":"01694ddd54ec6a73","type":"exec","z":"2aa78c88.04da44","command":"awk '{print $1}' /proc/uptime","addpay":"","append":"","timer":"","winHide":false,"name":"Uptime","x":380,"y":340,"wires":[["198a0c0ac2416c0c"],[],[]]},{"id":"198a0c0ac2416c0c","type":"change","z":"2aa78c88.04da44","name":"Set Topic Uptime","rules":[{"t":"set","p":"topic","pt":"msg","to":"Uptime","tot":"str"},{"t":"set","p":"payload","pt":"msg","to":"($number($trim(payload)) ? $number($trim(payload)) : 0) / 3600 ~> $round(2)","tot":"jsonata"}],"x":630,"y":340,"wires":[["71d65c821a231f67"]]},{"id":"71d65c821a231f67","type":"join","z":"2aa78c88.04da44","name":"Join Metrics","mode":"manual","build":"object","property":"payload","timeout":"10","count":"5","x":890,"y":260,"wires":[["a7f8cf77487b9a83","891b1b27.c66998","30378886.4cc918","500cb64f.5bd7c8","70e60250.56125c","2280e8e0.31af58","f70a49af60753879","26b5ccd1c2d785e9"]]},{"id":"a7f8cf77487b9a83","type":"function","z":"2aa78c88.04da44","name":"Format CSV","func":"let ts = moment().utc().format('YYYY.MM.DD HH:mm:ss');\nlet p = msg.payload;\nlet row = `${ts},${p.Temperature},${p.Load},${p.Memory},${p.Uptime},${p.Disk}`;\nmsg.payload = row;\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[{"var":"moment","module":"moment"}],"x":1130,"y":360,"wires":[["375bd16453cc4dd0"]]},{"id":"375bd16453cc4dd0","type":"file","z":"2aa78c88.04da44","name":"Append CSV","filename":"/home/ubuntu/uno220_stat.csv","filenameType":"str","appendNewline":true,"createDir":true,"overwriteFile":"false","x":1330,"y":360,"wires":[[]]},{"id":"8f5767ef7b5ad18c","type":"change","z":"2aa78c88.04da44","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"Timestamp,Temperature,Load,Memory,Uptime,Disk","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":1140,"y":400,"wires":[["6aef7d561dd3b777"]]},{"id":"3668be62b36e7593","type":"inject","z":"2aa78c88.04da44","name":"Clear","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"60","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":950,"y":400,"wires":[["8f5767ef7b5ad18c"]]},{"id":"6aef7d561dd3b777","type":"file","z":"2aa78c88.04da44","name":"Clear CSV","filename":"/home/ubuntu/uno220_stat.csv","filenameType":"str","appendNewline":true,"createDir":false,"overwriteFile":"true","encoding":"none","x":1330,"y":400,"wires":[[]]},{"id":"891b1b27.c66998","type":"ui_gauge","z":"2aa78c88.04da44","name":"","group":"dafb9311.e6497","order":1,"width":6,"height":4,"gtype":"gage","title":"Temperature","label":"","format":"{{msg.payload.Temperature}}°C","min":0,"max":"100","colors":["#00b500","#e6e600","#ca3838"],"seg1":"","seg2":"","diff":false,"className":"","x":1130,"y":120,"wires":[]},{"id":"30378886.4cc918","type":"ui_template","z":"2aa78c88.04da44","group":"dafb9311.e6497","name":"CPU Load","order":3,"width":6,"height":2,"format":"\n\n    CPU Load:\n    \n        {{msg.payload.Load}}%
\n    
\n
","storeOutMessages":true,"fwdInMessages":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1130,"y":160,"wires":[[]]},{"id":"500cb64f.5bd7c8","type":"ui_gauge","z":"2aa78c88.04da44","name":"","group":"d597c1ca.fe019","order":1,"width":6,"height":4,"gtype":"gage","title":"Memory Usage","label":"","format":"{{msg.payload.Memory}}%","min":0,"max":"100","colors":["#00b500","#e6e600","#ca3838"],"seg1":"","seg2":"","diff":false,"className":"","x":1140,"y":200,"wires":[]},{"id":"70e60250.56125c","type":"ui_text","z":"2aa78c88.04da44","group":"d597c1ca.fe019","order":2,"width":6,"height":1,"name":"","label":"Uptime","format":"{{msg.payload.Uptime}}hour(s)","layout":"row-center","className":"","style":false,"font":"","fontSize":"","color":"#000000","x":1120,"y":240,"wires":[]},{"id":"2280e8e0.31af58","type":"ui_template","z":"2aa78c88.04da44","group":"d597c1ca.fe019","name":"Disk Usage","order":3,"width":6,"height":2,"format":"\n\n    Disk Usage:\n    \n        {{msg.payload.Disk}}%
\n    
\n
","storeOutMessages":true,"fwdInMessages":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1130,"y":320,"wires":[[]]},{"id":"d204093578cae4b4","type":"change","z":"2aa78c88.04da44","name":"Store Cores","rules":[{"t":"set","p":"cpu_cores","pt":"flow","to":"$number($trim(payload)) ? $number($trim(payload)) : 4","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":610,"y":220,"wires":[[]]},{"id":"ebf66d26260831f1","type":"inject","z":"2aa78c88.04da44","name":"Init 3s","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":"3","topic":"","payload":"","payloadType":"str","x":190,"y":180,"wires":[["f1188809e56ab2de"]]},{"id":"f70a49af60753879","type":"debug","z":"2aa78c88.04da44","name":"Debug","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1110,"y":80,"wires":[]},{"id":"26b5ccd1c2d785e9","type":"ui_template","z":"2aa78c88.04da44","group":"dafb9311.e6497","name":"Spacer","order":2,"width":0,"height":0,"format":"\n\n","storeOutMessages":true,"fwdInMessages":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1120,"y":280,"wires":[[]]},{"id":"dafb9311.e6497","type":"ui_group","name":"Temperature Group","tab":"d7c34f92.385aa","order":1,"disp":false,"width":6,"collapse":false,"className":""},{"id":"d597c1ca.fe019","type":"ui_group","name":"Memory Group","tab":"d7c34f92.385aa","order":2,"disp":false,"width":6,"collapse":false,"className":""},{"id":"d7c34f92.385aa","type":"ui_tab","name":"UNO-220","icon":"dashboard","disabled":false,"hidden":false},{"id":"11c630d0f7478e8b","type":"global-config","env":[],"modules":{"node-red-dashboard":"3.6.6"}}]

Penjelasan Flow
- Inject node: trigger setiap 10 detik.
- Exec nodes: jalankan perintah Linux untuk ambil metrik.
- Join node: gabungkan hasil menjadi satu objek (msg.payload.Temperature, Load, Memory, Disk, Uptime).
- Function node: format ke CSV dengan timestamp UTC ISO 8601 seperti yang diharapkan Rapid SCADA.
- File node: append ke /home/ubuntu/uno220_stat.csv.
- Dashboard nodes: gauge untuk Temp, Load, Memory, Disk; text untuk Uptime.
Catatan: File CSV berfungsi sebagai buffer sementara, sedangkan trending historis sepenuhnya ditangani oleh Rapid SCADA.
Akses Dashboard
Buka:
http://:1880/ui
Troubleshooting
- Jika vcgencmd tidak tersedia di Ubuntu, flow otomatis fallback ke /sys/class/thermal/thermal_zone0/temp.
- Jika join timeout, naikkan timeout ke 15 detik.
- Cek hasil CSV:
```
tail -f /home/ubuntu/uno220_stat.csv
```

6.4 Indikator Heartbeat LED PL1 dengan Node‑RED

Untuk memastikan Node‑RED service aktif sekaligus memverifikasi sistem operasi berjalan normal, LED PL1 pada UNO‑220 dapat digunakan sebagai indikator heartbeat dengan pola berkedip periodik.

Flow Lengkap
Flow berikut mengendalikan LED PL1 (GPIO12, pin 32) agar berkedip dengan siklus penuh: 2 detik ON dan 2 detik OFF. Langkah import sama seperti JSON monitoring pada seksi 6.3.

[{"id":"659d98c5338c2aa4","type":"inject","z":"2aa78c88.04da44","name":"Blink Trigger","props":[{"p":"payload"}],"repeat":"2","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":200,"y":480,"wires":[["5a0f6bca78144bc7"]]},{"id":"5a0f6bca78144bc7","type":"delay","z":"2aa78c88.04da44","name":"1s Delay","pauseType":"rate","timeout":"1","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":400,"y":480,"wires":[["ca0e3b91a72ed37c"]]},{"id":"ca0e3b91a72ed37c","type":"change","z":"2aa78c88.04da44","name":"Toggle LED State (0/1)","rules":[{"t":"set","p":"payload","pt":"msg","to":"$number($not($flowContext(\"led_state\") ? $flowContext(\"led_state\") : 0))","tot":"jsonata"},{"t":"set","p":"led_state","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":620,"y":480,"wires":[["c23f25c34982533f"]]},{"id":"c23f25c34982533f","type":"rpi-gpio out","z":"2aa78c88.04da44","name":"LED PL1 Output","pin":"12","set":"","level":"msg.payload","freq":"","out":"out","bcm":true,"x":860,"y":480,"wires":[]},{"id":"b1892e385a988550","type":"global-config","env":[],"modules":{"node-red-node-pi-gpio":"2.0.6"}}]

Penjelasan Flow
- Inject node: memicu alur setiap 2 detik.
- Delay node: menahan pesan 1 detik untuk menjaga pola stabil.
- Change node: membalik nilai 0/1 dengan menyimpan status terakhir di flow context led_state.
- rpi-gpio out: mengirim nilai 0/1 ke GPIO12 (pin 32), yang terhubung ke LED PL1.
Hasil
LED PL1 berkedip dengan siklus penuh: 2 detik ON dan 2 detik OFF, menandakan Node‑RED dan sistem operasi berjalan normal. Pola blink dapat diubah (misalnya ON 200 ms, OFF 800 ms) dengan menyesuaikan konfigurasi inject/delay.
Troubleshooting
- LED tidak berkedip: Pastikan udev rules dan grup gpio aktif (lihat 4.5), lalu uji manual:
  - gpioset 0 12=1 → LED ON
  - gpioset 0 12=0 → LED OFF
- Izin Node‑RED GPIO: Pastikan paket python3‑rpi.gpio terpasang dan user service Node‑RED termasuk grup gpio.
- Mapping pin: Verifikasi GPIO12 berada di gpiochip0 dan terhubung ke PL1:
- gpioinfo | grep -E "gpiochip0|BCM12"

7. Instalasi Rapid SCADA 6.4.3 & Nginx

Di era integrasi OT–IT, OPC UA telah menjadi de facto standar komunikasi industri modern, terutama saat sistem perlu terhubung dengan MES, ERP, maupun platform IIoT.

Dalam konteks ini, Rapid SCADA tidak hanya berfungsi sebagai SCADA tradisional, tetapi juga sebagai data concentrator yang mengekspor seluruh tag dari berbagai driver (Modbus, SNMP, CSV, MQTT, dll.) melalui OPC UA Gateway. Dengan begitu, sistem eksternal seperti PLC, DCS, Historian, atau Grafana dapat langsung mengakses data tanpa perlu memahami protokol aslinya.

Kombinasi berikut membentuk arsitektur edge yang ideal dan future‑proof:

Rapid SCADA → data concentrator & middleware OT–IT
OPC UA → standar komunikasi universal
Node‑RED → logika automasi & integrasi fleksibel
Grafana → visualisasi modern dan analitik real‑time

7.1 .NET 8.0 Runtime

Rapid SCADA 6.4.3 membutuhkan ASP.NET Core Runtime 8.0.x.
Instalasi di Ubuntu 25.10 ARM64:

sudo apt update && sudo apt install -y aspnetcore-runtime-8.0
dotnet --info   # pastikan versi 8.0.x tampil

7.2 Rapid SCADA

Opsi A – Instalasi via Paket `.deb` (disarankan)

Unduh dan ekstrak paket ZIP resmi:

mkdir -p /home/ubuntu/scada
cd /home/ubuntu/scada
wget https://rapidscada.org/download/https://rapidscada.org/download/rapidscada_6.4.3_linux_en.zip
unzip rapidscada_6.4.3_linux_en.zip -d scada
cd scada

Instal paket .deb:

sudo dpkg -i rapidscada_6.4.3-1_all.deb

Aktifkan dan jalankan service:

sudo systemctl enable scadaagent6 scadaserver6 scadacomm6 scadaweb6
sudo systemctl start scadaagent6 scadaserver6 scadacomm6 scadaweb6

Opsi B – Instalasi Manual (opsional)

Digunakan jika .deb gagal atau butuh kustomisasi.

sudo cp -r scada/* /opt/scada/
sudo chmod +x /opt/scada/make_executable.sh
sudo /opt/scada/make_executable.sh
sudo cp daemons/* /etc/systemd/system/
sudo systemctl enable scadaagent6 scadaserver6 scadacomm6 scadaweb6
sudo systemctl start scadaagent6 scadaserver6 scadacomm6 scadaweb6

Catatan Integrasi System Resource Monitoring

Driver: CSV Reader
DecimalSeparator: .
DemoPeriod: OneHour
FieldDelimiter: FieldDelimiter
FileName: /home/ubuntu/uno220_stat.csv
ReadMode: RealTime
TagCount: 5
Map kolom → tag: Timestamp, Temperature, Load, Memory, Uptime, Disk

7.3 RAM Drive untuk Log

sudo mkdir /var/log/scada
sudo cp /etc/fstab /etc/fstab.bak
echo "tmpfs /var/log/scada tmpfs defaults,noatime,size=100m,mode=1777 0 0" | sudo tee -a /etc/fstab
sudo mount -a

7.4 Nginx Reverse Proxy

Instalasi:

sudo apt install nginx -y
sudo systemctl enable nginx

Salin konfigurasi bawaan:

sudo cp /home/ubuntu/scada/scada/nginx/default /etc/nginx/sites-available/scada
sudo ln -s /etc/nginx/sites-available/scada /etc/nginx/sites-enabled/

Validasi & restart:

sudo nginx -t
sudo systemctl restart nginx

SSL:

Self‑signed:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout /etc/ssl/private/nginx-selfsigned.key \
-out /etc/ssl/certs/nginx-selfsigned.crt

Produksi: gunakan Let’s Encrypt (sudo certbot --nginx).

7.5 Keamanan

Gunakan UFW untuk membatasi akses port ScadaAgent (10002) hanya dari jaringan ZeroTier agar remote programming tetap aman:
```
sudo ufw allow from  to any port 10002 proto tcp comment 'Rapid SCADA Agent'
```
Jangan buka port 10002 ke publik (WAN).

7.6 Verifikasi

Cek status service:

systemctl status scadaserver6 scadacomm6 scadaweb6

Akses web:

http:// atau https://
Login default: admin / scada

8. Instalasi Modbus TCP to RTU Gateway

mbusd memungkinkan UNO‑220 menjembatani perangkat Modbus RTU (RS‑232/RS‑485) ke Modbus TCP server. Dengan ini, Node‑RED maupun Rapid SCADA bisa membaca data RTU melalui TCP port 502.

Instalasi

sudo apt update
sudo apt install -y build-essential git cmake
git clone https://github.com/3cky/mbusd.git
cd mbusd
mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr ..
make
sudo make install

Konfigurasi
Buat file /etc/mbusd/mbusd-ttyS0.conf:

device   = /dev/ttyS0
speed    = 9600
mode     = 8N1
rs485    = yes
address  = 0.0.0.0
port     = 502
maxconn  = 32
retries  = 3
pause    = 100
wait     = 500
timeout  = 60
logfile  = /var/log/mbusd.log
verbosity = 2

Jalankan sebagai service

sudo systemctl start mbusd@ttyS0.service
sudo systemctl enable mbusd@ttyS0.service
sudo systemctl status mbusd@ttyS0.service

Uji koneksi
Dari host lain:
```
modpoll -m tcp -t 3 -r 1 -c 10 
```
→ Harus mendapat respons register dari slave RTU.
Integrasi
- Node‑RED: gunakan node node-red-contrib-modbus → Modbus TCP client ke tcp://:502.
- Rapid SCADA: tambahkan channel Modbus TCP pointing ke UNO‑220.
Keamanan
- Gunakan UFW untuk membatasi akses port Modbus TCP (502) hanya dari jaringan ZeroTier:
```
sudo ufw allow from  to any port 502 proto tcp comment 'Modbus TCP'
```
- Jangan buka port 502 ke publik (WAN).

9. Instalasi Scada Grafana Proxy

scada-grafana-proxy adalah server proxy ringan berbasis Node.js yang:

Mengambil data dari Rapid SCADA 6 maupun Rapid SCADA 5 via REST API.
Mengubah format respons menjadi seragam dan kompatibel dengan Grafana Infinity Datasource.
Menyediakan Basic Authentication untuk keamanan.
Mendukung konfigurasi berbasis environment (.env).
Menyediakan health check endpoint untuk monitoring.

Instalasi

# Clone repo
git clone https://github.com/kumajaya/scada-grafana-proxy.git
cd scada-grafana-proxy

# Install dependensi
npm install

Konfigurasi
Salin contoh environment:

cp env-example .env
nano .env

Isi variabel sesuai kebutuhan, misalnya:

PROXY_PORT=3000
PROXY_USER=admin
PROXY_PASS=admin
SCADA_BASE_URL=http://localhost:10008
SCADA_USERNAME=admin
SCADA_PASSWORD=admin
SCADA_ARCHIVEBIT_THRESHOLD=24
SCADA5_BASE_URL=http://localhost/grafanadataprovider

Jalankan
```
npm start
```
Akses proxy di:
http://:3000

Systemd Service
File scada-grafana-proxy.service sudah disediakan. Install:

sudo cp scada-grafana-proxy.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable scada-grafana-proxy
sudo systemctl start scada-grafana-proxy

Cek status:

systemctl status scada-grafana-proxy

Uji health check:

curl -u admin:admin http://:3000/health

Integrasi dengan Grafana
- Tambahkan Infinity Datasource di Grafana.
- Atur URL ke http://:3000.
- Gunakan Basic Auth sesuai .env.
- Query data Rapid SCADA langsung dari Grafana dashboard.
Keamanan
- Gunakan UFW untuk membatasi akses port 3000 hanya dari host Grafana:
```
sudo ufw allow from  to any port 3000 proto tcp comment 'SCADA Grafana Proxy'
```
- Jika Grafana berjalan di server terpisah, gunakan ZeroTier agar komunikasi tetap terenkripsi.

Dengan penambahan ini, UNO‑220 berevolusi dari sekadar gateway dan server SCADA menjadi penyedia data terintegrasi untuk Grafana maupun ERP. Membawa visibilitas real‑time melalui dashboard modern dan tinjauan histori kinerja secara komprehensif, sementara sistem ERP menerima aliran data SCADA yang sudah dinormalisasi. Alur ini tidak hanya memperkaya analitik dan pengambilan keputusan, tetapi juga memastikan integrasi berlangsung dengan cara yang aman, konsisten, dan mudah.

10. Hardening & Optimisasi

10.1 SSH (Secure Shell)

PERINGATAN: Risiko Penguncian Akses Permanen
Mengaktifkan autentikasi berbasis kunci SSH meningkatkan keamanan, tetapi juga meniadakan akses melalui password. Jika kunci privat hilang, perangkat tidak dapat diakses kembali tanpa koneksi fisik ke serial console.
Pastikan autentikasi menggunakan PubkeyAuthentication telah diuji dan berfungsi dengan baik sebelum menonaktifkan PasswordAuthentication.

Generate Key di Host Admin

Linux:

ssh-keygen -t ed25519 -C "admin@uno220"

Windows (PowerShell, OpenSSH bawaan):

ssh-keygen -t ed25519 -C "admin@uno220"

Copy Public Key ke UNO‑220

Linux:

ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu@

Windows PowerShell:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh ubuntu@ "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Uji Login Key‑Based
```
ssh ubuntu@
```
→ Harus langsung masuk tanpa password.

Aktifkan Hardening SSH (setelah uji berhasil)
Edit /etc/ssh/sshd_config:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

Restart:

sudo systemctl restart ssh

10.2 Firewall (UFW)

PERINGATAN: Risiko Kehilangan Akses Remote
Aturan firewall yang terlalu ketat dapat memblokir port penting seperti ZeroTier (9993/UDP) atau SSH (22/TCP). Jika port ini tertutup, perangkat tidak dapat diakses dari jarak jauh, dan pemulihan hanya dapat dilakukan melalui serial console fisik.
Pastikan konfigurasi ufw telah diuji dengan hati-hati sebelum menerapkan aturan baru secara permanen.

Konfigurasi dasar:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh/tcp      # Port 22
sudo ufw allow 80/tcp       # Nginx HTTP
sudo ufw allow 443/tcp      # Nginx HTTPS
sudo ufw allow 9993/udp comment 'ZeroTier'
sudo ufw allow 1880/tcp comment 'Node-RED'
sudo ufw allow from  to any port 10002 proto tcp comment 'Rapid SCADA Agent'
sudo ufw allow from  to any port 3000 proto tcp comment 'SCADA Grafana Proxy'
sudo ufw enable

Verifikasi port terbuka:

sudo ss -tuln

→ Hanya 22, 80, 443, 9993, 1880, 10002, 3000 yang aktif.

10.3 Fail2Ban (Proteksi SSH)

PERINGATAN: Hindari Penguncian Akses Sendiri
Mekanisme ini melindungi perangkat dari serangan brute-force pada SSH, namun berisiko memblokir IP admin atau tim jika terjadi beberapa kali kegagalan login beruntun. Akibatnya, akses remote dapat terputus sementara (default 10 menit).
Pastikan alamat IP tepercaya dimasukkan ke daftar pengecualian sebelum fitur ini diaktifkan di lingkungan produksi.

Instalasi:
```
sudo apt install fail2ban -y
```

Konfigurasi /etc/fail2ban/jail.local:

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log

Tambahkan ignoreip = 127.0.0.1/8 untuk whitelist.

Restart:
```
sudo systemctl restart fail2ban
```
Verifikasi:
```
sudo fail2ban-client status sshd
```

10.4 Auto Security Updates

PERINGATAN: Keseimbangan antara Keamanan dan Stabilitas
Menahan (hold) kernel mencegah pembaruan otomatis yang dapat memicu reboot tak terjadwal, menjaga uptime sistem industri tetap stabil. Namun, risiko muncul jika kernel tertahan terlalu lama: perangkat dapat kehilangan patch keamanan penting.
Lakukan pemantauan manual terhadap rilis kernel baru dan lakukan pembaruan terencana bila tersedia pembaruan kritis.

Instalasi:

sudo apt install unattended-upgrades -y

Enable:

sudo dpkg-reconfigure unattended-upgrades

Pilih Yes.

Edit /etc/apt/apt.conf.d/50unattended-upgrades → pastikan baris berikut aktif:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Uji:
```
sudo unattended-upgrades --dry-run
```
Untuk mencegah upgrade kernel otomatis yang memerlukan reboot, jalankan:
```
sudo apt-mark hold linux-image-* raspberrypi-kernel
```

10.5 Sinkronisasi RTC (Real-Time Clock)

Pastikan NTP aktif:
```
timedatectl status
```

Tambahkan cron job:

sudo crontab -e

Isi:

@daily /usr/sbin/hwclock -w && logger "RTC updated from system clock"
@reboot /usr/sbin/hwclock -s && logger "System clock initialized from RTC"

Uji manual:
```
sudo hwclock -s && hwclock -r
```

10.6 Disable Unused Services

Matikan service yang tidak diperlukan:

sudo systemctl disable bluetooth avahi-daemon

10.7 Disable USB Boot (Optional, Keamanan Fisik untuk Lapangan Rentan)

PERINGATAN: Risiko Gagal Boot Permanen
Langkah ini meningkatkan keamanan fisik dengan membatasi jalur boot hanya dari kartu SD. Namun, konfigurasi EEPROM yang salah dapat menyebabkan kegagalan boot total.
Pemulihan memerlukan akses fisik langsung dan flashing ulang bootloader menggunakan Raspberry Pi Imager.

Disarankan untuk selalu menyertakan SD card dalam urutan BOOT_ORDER. Hal ini untuk memastikan dapat melakukan recovery dengan mudah menggunakan image rescue di microSD, jika konfigurasi boot lain gagal.

Untuk mencegah perangkat boot dari USB eksternal (risiko tampering di lapangan), lakukan konfigurasi EEPROM bootloader agar hanya mengizinkan boot dari microSD.

Install tool EEPROM
```
sudo apt install rpi-eeprom -y
```
Edit konfigurasi EEPROM
```
sudo rpi-eeprom-config --edit
```
Ubah atau tambahkan baris:
```
BOOT_ORDER=0xf41
```
- 0xF41 → SD → USB → ulangi (default modern Pi, aman karena SD tetap ada).
- 0xF0 → hanya SD card (paling ketat, tanpa fallback).
Simpan dan keluar dari editor.
Update EEPROM & reboot
```
sudo rpi-eeprom-update -a
sudo reboot
```
Verifikasi konfigurasi
```
sudo vcgencmd bootloader_config | grep BOOT_ORDER
```
Output harus menampilkan 0xF41 atau 0xF0.

Contoh nilai BOOT_ORDER umum:

Nilai	Urutan Boot	Catatan
`0xF41`	SD → USB → ulangi	Default modern Pi, aman
`0xF14`	USB → SD → ulangi	Masih aman, SD tetap ada
`0xF461`	SD → NVMe → USB → ulangi	Cocok untuk CM4/Pi 5 dengan SSD
`0xF21`	SD → Network (TFTP) → ulangi	Aman untuk network boot, SD tetap ada
`0xF0`	SD only	Paling ketat, tanpa fallback

Catatan:

Gunakan microSD industrial‑grade, karena setelah USB boot dinonaktifkan, recovery hanya bisa dilakukan via Raspberry Pi Imager dengan flashing ulang bootloader image.
Jika update EEPROM gagal, fallback ke metode resmi Raspberry Pi Imager untuk restore bootloader.

10.8 Verifikasi Hardening

SSH hanya menerima key‑based login:
```
ssh ubuntu@
```
Firewall hanya membuka port yang diizinkan:
```
sudo ss -tuln
```
Fail2Ban aktif:
```
sudo fail2ban-client status sshd
```
Update otomatis aktif:
```
systemctl status unattended-upgrades
```
RTC sinkron:
```
hwclock -r
```

10.9 Troubleshooting

Fail2Ban gagal start → cek log:
```
sudo journalctl -u fail2ban
```
SSH terkunci → login via ZeroTier console atau akses fisik, lalu aktifkan kembali PasswordAuthentication yes sementara.
UFW blokir ZeroTier → pastikan sudo ufw allow 9993/udp.

11. Backup & Recovery

11.1 Backup Manual

Node‑RED

cd ~/.node-red && tar czvf nodered_config_backup_$(date +%F).tar.gz flows.json settings.js package.json

Rapid SCADA

sudo tar czvf scada_backup_$(date +%F).tar.gz /opt/scada /etc/systemd/system/scada*.service

ZeroTier

sudo tar czvf zerotier_backup_$(date +%F).tar.gz /var/lib/zerotier-one

11.2 Backup Rutin Otomatis (Cron + rsync ke USB/NAS)

Setup Mount USB/NAS

USB:

sudo mkdir -p /mnt/usb
sudo mount /dev/sda1 /mnt/usb   # ganti sda1 sesuai device

NAS (NFS):

sudo mkdir -p /mnt/nas
sudo mount -t nfs :/share /mnt/nas

NAS (SMB/CIFS):

sudo mkdir -p /mnt/nas
sudo mount -t cifs ///share /mnt/nas -o username=user,password=pass

Buat Script Backup
Simpan sebagai /usr/local/bin/backup_routine.sh:

#!/bin/bash
set -euo pipefail

DATE="$(date +%Y%m%d_%H%M%S)"
SRC_DIRS="/home/ubuntu/.node-red /var/lib/zerotier-one /etc /home/ubuntu/uno220_stat.csv"
DEST="/mnt/usb/backups"   # atau /mnt/nas/backups
LOG="/var/log/backup.log"
 
if ! mountpoint -q /mnt/usb; then
  echo "$(date) - USB tidak ter-mount, backup dibatalkan" | tee -a "$LOG"
  exit 1
fi

mkdir -p "$DEST/$DATE"
rsync -avz --delete --log-file="$LOG" $SRC_DIRS "$DEST/$DATE"

# Hapus backup >7 hari
find "$DEST" -maxdepth 1 -mindepth 1 -type d -mtime +7 -exec rm -rf {} +

# Mirror khusus Rapid SCADA
mkdir -p /mnt/usb/scada_backup
rsync -av --delete /opt/scada /mnt/usb/scada_backup/

Buat executable:

sudo chmod +x /usr/local/bin/backup_routine.sh

Jadwalkan Cron Job

sudo crontab -e

Tambahkan:

0 2 * * * /usr/local/bin/backup_routine.sh   # Harian jam 2 pagi

Verifikasi:

sudo crontab -l

Log tersimpan di /var/log/backup.log.

11.3 Log Retention dengan Logrotate

Cegah log backup membengkak di microSD.

Pastikan logrotate terpasang:
```
sudo apt install logrotate -y
```

Buat config /etc/logrotate.d/backup_logs:

/var/log/backup.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 644 root root
    postrotate
        /usr/bin/killall -q -HUP rsyslogd 2> /dev/null || true
    endscript
}

Uji:

sudo logrotate -d /etc/logrotate.d/backup_logs

Jalankan manual:
```
sudo logrotate -f /etc/logrotate.conf
```

11.4 Recovery

Restore Node‑RED:

tar xzvf nodered_config_backup_*.tar.gz -C ~/.node-red

Restore Rapid SCADA:

sudo tar xzvf scada_backup_*.tar.gz -C /
sudo systemctl daemon-reload
sudo systemctl restart scadaagent6 scadaserver6 scadacomm6 scadaweb6

Restore ZeroTier:

sudo systemctl stop zerotier-one
sudo tar xzvf zerotier_backup_*.tar.gz -C /
sudo systemctl start zerotier-one

Restore dari USB/NAS:
```
sudo rsync -avz /mnt/usb/backups// /
```

11.5 Troubleshooting

rsync gagal ke NAS → pastikan mount sukses (df -h), gunakan SSH keyless (ssh-keygen && ssh-copy-id user@nas_ip).
USB tidak terdeteksi → cek lsblk atau dmesg | grep sd.
Logrotate error permission → sesuaikan baris create 644 root root di config.

12. Testing & Validasi

12.1 Verifikasi Node‑RED

systemctl status nodered.service

Status harus active (running).
Akses editor: http://:1880
Akses dashboard: http://:1880/ui

Contoh Output:

● nodered.service - Node-RED
     Loaded: loaded (/lib/systemd/system/nodered.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-10-22 10:00:00 UTC; 2h ago
   Main PID: 1234 (node)
      Tasks: 15 (limit: 4915)
     Memory: 45.2M
        CPU: 1min 23.456s
     CGroup: /system.slice/nodered.service
             └─1234 /usr/bin/node /usr/lib/node_modules/node-red/red.js

12.2 Verifikasi Rapid SCADA

systemctl status scadaserver6.service scadacomm6.service scadaweb6.service

Semua service harus active (running).
Akses web: http:// atau https://
Login default: admin / scada

12.3 Uji Koneksi ZeroTier

ping

Harus ada balasan ICMP.
Jika gagal: cek zerotier-cli listnetworks dan pastikan node authorized.

12.4 Uji Hardware

RTC
```
hwclock -r
```
Contoh Output:
```
2025-10-22 12:34:56.789012 UTC
```
→ Bandingkan dengan date untuk memastikan sinkron.

GPIO Expander

gpiodetect

Contoh Output:

gpiochip0 [pinctrl-bcm2835] (58 lines)
gpiochip1 [raspberrypi-exp-gpio] (8 lines)
gpiochip2 [pca953x] (8 lines, tca9554@27)

LED PL1

gpioset 0 12=1   # LED ON
gpioset 0 12=0   # LED OFF

TPM

tpm2_getrandom 16 | xxd -p

Contoh Output:

a1b2c3d4e5f6789012345678abcdef90

Serial Port
```
minicom -D /dev/ttyS0 -b 115200
```
→ Pastikan komunikasi serial berjalan.

12.5 Checklist

[ ] Node‑RED dashboard dapat diakses via browser
[ ] Rapid SCADA menampilkan halaman login
[ ] ZeroTier peer dapat saling ping
[ ] RTC terbaca dengan benar (hwclock -r)
[ ] LED PL1 dapat dikendalikan (ON/OFF)
[ ] Port serial berfungsi (minicom)
[ ] Hanya port 22/80/443/9993/1880/10002/3000 terbuka (ss -tuln)
[ ] Fail2Ban aktif (fail2ban-client status sshd)
[ ] Node‑RED logs capture I/O errors (journalctl -u nodered)
[ ] Backup cron berjalan (cek /var/log/backup.log)
[ ] Logrotate config valid (logrotate -d /etc/logrotate.d/backup_logs)
[ ] System metrics dashboard tampil (CPU <80%, RAM <70%, Temp <80°C)
[ ] CSV file update (tail -f uno220_stat.csv) & Rapid SCADA trend visible

12.6 Troubleshooting Cepat

Node‑RED tidak jalan → cek journalctl -u nodered -f
SCADA 502 Bad Gateway → cek journalctl -u scadaweb6 -f
ZeroTier tidak connect → cek zerotier-cli info
RTC error → pastikan overlay aktif (dmesg | grep rtc)
GPIO/LED gagal → cek gpioinfo untuk mapping pin
TPM error → pastikan modul kernel TPM aktif (lsmod | grep tpm)

13. Deployment

Penempatan Perangkat
- Tempatkan UNO‑220 di lokasi lapangan sesuai rencana instalasi.
- Pastikan lingkungan sesuai spesifikasi industri (suhu, kelembaban, getaran).
Koneksi Daya & Jaringan
- Hubungkan ke catu daya 12–24 VDC atau PoE+ (802.3at).
- Catatan: hindari PoE 802.3af karena tidak stabil saat beban tinggi (Node‑RED + SCADA dapat menarik 15–20W).
Verifikasi ZeroTier
- Pastikan device muncul di jaringan ZeroTier:
```
zerotier-cli listnetworks
```
- Cek status ONLINE di controller.
Akses Aplikasi
- Node‑RED: http://:1880
- Rapid SCADA: http:// atau https://
Validasi Fungsi I/O & Flow
- Uji dashboard Node‑RED (sensor, GPIO, expander, serial).
- Uji trending Rapid SCADA (CSV file update → grafik tampil).
- Simulasikan skenario logika industri (misalnya alarm, interlock).
Label Fisik Unit
- Tempel label berisi:
  - ID ZeroTier
  - IP lokal
  - Tanggal deployment
- Gunakan label tahan panas & kelembaban.
Proteksi Daya
- Gunakan UPS mini DC atau supply redundant untuk menjaga kestabilan.
- Catat kapasitas UPS (misalnya 12V/24V, 30–60 menit backup).

14. Penutup

UNO‑220 kini siap beroperasi sebagai edge device industri yang tangguh, dengan konfigurasi yang aman, modular, dan audit‑ready. Seluruh tahapan — mulai dari instalasi sistem operasi, aktivasi fitur perangkat keras, pengamanan layanan, hingga integrasi aplikasi — telah dirancang agar konsisten, mudah direplikasi, dan dapat diaudit.

Komponen utama yang terintegrasi:

Node‑RED → automasi dan dashboard lokal, lengkap dengan logging I/O dan monitoring sistem ke CSV.
Rapid SCADA 6.4.3 → server SCADA dengan integrasi trending CSV untuk histori data yang akurat.
ZeroTier → konektivitas aman dan fleksibel untuk remote management tanpa membuka port publik.
RAM drive & hardening (UFW + Fail2Ban) → perlindungan sistem sekaligus memperpanjang umur media penyimpanan.
Backup rutin + logrotate → memastikan recovery cepat dan manajemen log yang efisien.

Dengan rancangan ini, UNO‑220 dapat dijadikan standar operasional deployment di seluruh fasilitas industri, menjamin konsistensi, keamanan, dan keandalan.

Lebih jauh lagi, kombinasi Rapid SCADA (data concentrator) + OPC UA (standar komunikasi) + Node‑RED (logic) + Grafana (visualisasi) membentuk arsitektur edge yang future‑proof. Dengan pendekatan ini, UNO‑220 tidak hanya berfungsi sebagai gateway lokal, tetapi juga sebagai middleware OT–IT yang siap menghubungkan lapisan produksi dengan MES, ERP, maupun platform IIoT modern.

Catatan: Untuk menjaga keberlanjutan, lakukan validasi berkala (service status, backup, update keamanan) dan selalu cek versi terbaru software dari sumber resmi sebelum upgrade.

Sebagai penutup, Advantech UNO‑220 dapat menjadi fondasi fleksibel bagi evolusi sistem automasi industri. Selain fungsi gateway, perangkat ini bisa diperluas dengan runtime Eclipse 4diac FORTE (IEC 61499) untuk soft logic non‑critical, CODESYS Runtime (IEC 61131‑3) sebagai SoftPLC komersial ringan, maupun OpenPLC Runtime (IEC 61131‑3) sebagai alternatif open source untuk edukasi dan prototyping. Integrasi ini dapat dipadukan dengan TensorFlow Lite untuk predictive maintenance, di mana output dari FORTE, CODESYS, atau OpenPLC diolah oleh model AI untuk deteksi fault real‑time, sehingga UNO‑220 berperan sebagai hybrid edge device yang efisien, modular, dan compliant.

Menghindari Masalah Grounding dan Petir dengan Fiber Optic

2025-12-24T18:05:59+00:00

Latar Belakang

Dalam lingkungan industri, jaringan komunikasi antar perangkat umumnya menggunakan kabel tembaga (Ethernet). Walaupun praktis, kabel tembaga memiliki kelemahan mendasar karena bersifat konduktif. Hal ini menimbulkan risiko:

Gangguan grounding akibat perbedaan potensial antar panel atau perangkat.
Induksi elektromagnetik (EMI) dari peralatan berdaya besar seperti motor atau inverter.
Sambaran petir yang dapat merambat melalui kabel dan merusak perangkat sensitif.

Dampak dari gangguan tersebut tidak hanya berupa kerusakan perangkat, tetapi juga berpotensi menyebabkan downtime operasional yang signifikan serta risiko keselamatan.

Fiber Optic sebagai Solusi

Fiber optic merupakan media komunikasi yang sepenuhnya non-konduktif, sehingga tidak menghantarkan arus listrik. Keunggulan utama yang ditawarkan antara lain:

Isolasi Galvanik Total
Menghilangkan jalur arus listrik antar perangkat, aman dari perbedaan grounding maupun sambaran petir.
Ketahanan terhadap EMI/RFI
Sinyal berbasis cahaya tidak terpengaruh oleh medan elektromagnetik, sehingga komunikasi tetap stabil.
Perlindungan Alami dari Petir
Tidak adanya konduksi listrik membuat fiber optic aman dari energi petir.
Kecepatan dan Jangkauan
Mendukung komunikasi gigabit dengan jarak hingga puluhan kilometer tanpa degradasi berarti.

Penerapan di Industri

Fiber optic dapat diterapkan pada berbagai sistem komunikasi industri, antara lain:

SCADA dan DCS untuk komunikasi antar panel kontrol.
Flowmeter, power meter, atau sensor dalam pengiriman data ke server.
Koneksi antar gedung atau panel untuk mengatasi beda potensial grounding.
Integrasi OPC UA / Modbus TCP yang membutuhkan komunikasi real-time stabil.

Topologi Sistem

graph TD classDef danger fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#b71c1c,rx:15,ry:15 classDef converter fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:#e65100,rx:15,ry:15 A["⚡ Zona Eksternal
Perangkat Lapangan
(Area Rentan)"] B["🛡️ Media Converter
FC311A-20
(Pelindung)"] C["🛡️ Media Converter
FC311B-20
(Pelindung)"] D["🏢 Zona Internal
Server / Data Center
(Area Rentan)"] A --> B B --> C C --> D class A danger class D danger class B,C converter linkStyle 1 stroke-dasharray: 5 5

Topologi Sistem Rancangan Jaringan Fiber Optic

Media Converter

TP-Link FC311A-20 (sisi perangkat)
TP-Link FC311B-20 (sisi server/switch)

FC311A-20 - Gigabit WDM Media Converter

Spesifikasi utama:

Ethernet RJ45 10/100/1000 Mbps
Fiber optic single-mode WDM (BiDi)
Connector SC/UPC, mode simplex (1 core)
Jarak dukung hingga 20 km
Power supply DC 12–48 V
Plug & play tanpa konfigurasi

Kabel Fiber Optic

Single-mode OS2, simplex (1 core)
Connector SC/UPC – SC/UPC
Panjang ±300 m (outdoor, UV resistant)
❌ Tidak boleh multimode
❌ Tidak boleh SC/APC (hijau)

Patch cord single-mode OS2 simplex dengan konektor SC/UPC

Kabel Ethernet

Cat5e/Cat6, panjang ≤5 m
Digunakan hanya di sisi converter (Perangkat → FC311A, FC311B → Server)

Power & Panel

Supply DC 12/24 V untuk masing-masing converter
Converter ditempatkan dalam panel tertutup dengan grounding chassis
Fiber optic masuk panel menggunakan strain relief/gland

Keunggulan Sistem

Isolasi galvanik penuh → aman dari EMI dan petir.
Komunikasi stabil → mendukung protokol OPC UA atau Modbus TCP secara terus-menerus.
Konfigurasi sederhana → point-to-point tanpa kebutuhan pengaturan tambahan.
Siap audit → BOM jelas dan spesifikasi terdokumentasi, memudahkan proses pengadaan dan inspeksi.

Bill of Materials (BOM)

No	Item	Spesifikasi	Qty	Catatan
1	Media Converter FC311A-20	RJ45 1G, FO WDM SC/UPC	1	Sisi perangkat lapangan
2	Media Converter FC311B-20	RJ45 1G, FO WDM SC/UPC	1	Sisi server/switch
3	Kabel FO Outdoor OS2	Simplex SC/UPC–SC/UPC ±300 m	1 roll	Sesuai site
4	Patch Cable RJ45 Cat5e/Cat6	≤5 m	2 pcs	Perangkat & Server
5	Panel / Enclosure	Metal, DIN rail	1 set	Opsional
6	Cable Gland / Strain Relief	Untuk FO	2 pcs	Masuk panel
7	Grounding Accessories	Lug, kabel grounding	1 set	Panel & chassis
8	Label Kabel	FO & Ethernet	1 set	Identifikasi

Best Practice Instalasi

Untuk memastikan sistem fiber optic bekerja optimal dan tahan lama, disarankan:

Manajemen kabel: gunakan tray/ducting, hindari tekukan tajam (radius min. 30 mm).
Proteksi panel: gunakan enclosure dengan rating IP sesuai lingkungan (≥IP54 untuk outdoor).
Grounding konsisten: converter, PSU, dan panel tetap digrounding dengan kabel tembaga memadai.
Label & dokumentasi: beri label jelas pada kabel, dokumentasikan jalur dan titik terminasi.
Strain relief/gland: gunakan gland saat kabel masuk panel untuk mencegah kerusakan mekanis.
Pemeriksaan konektor: bersihkan konektor SC/UPC sebelum instalasi untuk menghindari loss.

Kesimpulan

Penggunaan fiber optic dalam sistem komunikasi industri bukan sekadar peningkatan teknologi, melainkan langkah strategis untuk menghindari masalah grounding dan petir. Dengan isolasi total, ketahanan terhadap EMI, serta keandalan tinggi, fiber optic memastikan komunikasi tetap aman, stabil, dan berkelanjutan.

Zero-Cost Engineering: Workflow FOSS untuk Hasil Profesional

2025-08-09T08:31:13+00:00

Workflow FOSS untuk Hasil Profesional

0:00

/5.184

Pendahuluan

"Apakah kita benar-benar perlu membayar mahal untuk perangkat lunak, jika hasil teknikal yang sama — bahkan lebih baik — bisa dicapai secara gratis?"

Di banyak industri, optimalisasi performa peralatan sering diasosiasikan dengan perangkat lunak berbayar, lisensi berlapis, dan perangkat keras kelas atas. Namun kenyataannya, hasil profesional tidak selalu bergantung pada biaya lisensi. Melalui pendekatan Zero-Cost Engineering — rekayasa berbasis FOSS (Free and Open Source Software) dan metodologi modular — kita dapat menghasilkan output teknis berkualitas tinggi tanpa biaya tambahan. Bayangkan: menyelesaikan analisis teknikal level industri tanpa mengeluarkan biaya lisensi perangkat lunak sama sekali. Ini bukan sekadar teori — studi kasus nyata telah membuktikannya.

Filosofi Zero-Cost Engineering

Zero-Cost Engineering bukan berarti kompromi terhadap kualitas. Yang dimaksud di sini adalah: maksimalkan alat yang tersedia, hilangkan biaya lisensi, dan investasikan waktu untuk memahami proses secara lebih mendalam.

Prinsipnya:

Satu bahasa untuk semuanya → Python
Satu editor untuk semuanya → Visual Studio Code + Jupyter Notebook
Satu alur kerja yang terdokumentasi penuh → mudah direplikasi, modular, dan siap diuji ulang
Satu platform publikasi → Markdown + Joplin + Ghost CMS

Dengan pendekatan ini, kita bukan hanya menghemat biaya — kita membangun ekosistem kerja yang transparan, audit-ready, dan siap dibagikan ke komunitas. Setelah memahami filosofinya, mari kita telusuri alur kerja end-to-end yang digunakan.

Workflow FOSS End-to-End

Digitalisasi Data

Input: Kurva performa vendor (PDF/JPEG/PNG)
Tool: WebPlotDigitizer (gratis, berbasis web)
Hasil: Ekstraksi kurva performa dari gambar statis menjadi dataset numerik siap analisis
Alternatif berbayar: OriginLab Digitizer, MATLAB Toolbox

Analisis dan Visualisasi

Tool: Python (pandas, numpy, matplotlib)
Hasil: Grafik hubungan IGV vs. tekanan/flow, identifikasi zona efisiensi, dan titik operasi aktual
Alternatif berbayar: MATLAB, OriginPro, JMP

Draft Konten Modular

Tool: Markdown di Visual Studio Code atau Joplin, diagram alir dengan Mermaid, diagram teknikal statis di draw.io
Hasil: Naskah teknis yang rapi, modular, dan siap dikonversi
Alternatif berbayar: MS Word + EndNote + Visio, Adobe FrameMaker

Konversi dan Layout PDF

Tool: Pandoc (Markdown → LaTeX) + Overleaf
Hasil: Whitepaper PDF siap cetak dan distribusi, bahkan reproduksi
Alternatif berbayar: Adobe InDesign, Scientific Word

Narasi Audio

Tool: Python TTS (pyttsx3, gTTS)
Hasil: Narasi audio untuk presentasi atau podcast teknis
Alternatif berbayar: Adobe Audition + TTS API

Distribusi

Tool: Ghost CMS (self-hosted) + PDF distribusi
Hasil: Blog post untuk pembaca umum, whitepaper PDF untuk pembaca teknis
Alternatif berbayar: CMS enterprise + Adobe Acrobat Pro DC

Hasil Nyata: Studi Kasus Kompresor Sentrifugal

Workflow ini bukan sekadar teori — ia telah digunakan dalam proyek nyata untuk menganalisis performa kompresor sentrifugal yang gagal mencapai target tekanan. Dengan pendekatan berbasis FOSS, seluruh proses — dari data mentah hingga publikasi — dapat dijalankan secara mandiri, transparan, dan tanpa biaya lisensi.

Hasilnya:

Masalah operasional berhasil diidentifikasi tanpa bantuan perangkat lunak berbayar atau perangkat analisis khusus
Rekomendasi teknis disusun berdasarkan kurva performa yang didigitalisasi dan divisualisasikan secara mandiri
Output akhir berupa blog post yang komunikatif dan whitepaper PDF yang siap diuji ulang — semuanya dibuat dengan alat gratis dan terbuka

Studi kasus ini membuktikan bahwa dengan workflow yang rapi dan alat yang tepat, kreativitas teknis dapat melampaui keterbatasan biaya. Dalam banyak kasus, biaya tidak perlu dialokasikan untuk perangkat lunak berbayar, melainkan lebih baik difokuskan pada perangkat keras, pelatihan operator, dan sumber daya lainnya yang berdampak langsung pada kualitas hasil.

Studi kasus ini membuktikan bahwa hanya dengan satu laptop, satu bahasa, dan satu editor, kita tidak hanya menghemat biaya — kita membangun ekosistem kerja yang siap diuji ulang, dibagikan, dan dikembangkan bersama tim.

Diagram Alir Workflow FOSS

Diagram berikut dirender langsung menggunakan Mermaid — bukan grafis hasil perangkat lunak eksternal apalagi berbayar, melainkan teks yang bisa direproduksi dan direvisi langsung.

flowchart TB subgraph Workspace["Zero-Cost Engineering"] direction TB A["Digitalisasi Data
(WebPlotDigitizer)"]:::Sky B["Analisis & Visualisasi
(Python: matplotlib, numpy)"]:::Sky C["Penulisan & Naskah
(Joplin, Ghost, Mermaid, draw.io)"]:::Sky D1["Blog Post
(Ghost CMS)"]:::Sky D2["Whitepaper PDF
(Pandoc + Overleaf)"]:::Sky D3["Narasi Audio
(Python TTS)"]:::Sky end A --> B B --> C C --> D1 & D2 & D3 D1 --> E["Distribusi Akhir"]:::Pine D2 --> E D3 --> E classDef Sky fill:#F4F8FF,stroke:#2C3E50,color:#2C3E50,stroke-width:1.5px,rx:6px,ry:6px; classDef Pine fill:#2E8B57,stroke:#1E5F3F,color:#FFFFFF,stroke-width:1.5px,rx:6px,ry:6px; classDef Alert fill:#FFF5F5,stroke:#D32F2F,color:#D32F2F,stroke-width:1.5px,rx:6px,ry:6px; style Workspace stroke:#757575,fill:#F5F5F5,rx:8px,ry:8px

Gambar 1: Alur kerja Zero-Cost Engineering — dari data mentah hingga publikasi menggunakan FOSS tools

Salah satu kekuatan dari alur kerja ini adalah kemampuannya untuk mengintegrasikan ekspresi teknikal tingkat lanjut langsung ke dalam publikasi. Dengan menggunakan alat FOSS seperti $\text{\LaTeX}$, rumus teknik yang kompleks dapat dirender dengan kualitas profesional.
Sebagai contoh:

$$ Q_{real} = Q_{design} \times \sqrt{\left( \frac{T_{design}}{T_{real}} \cdot \frac{P_{real}}{P_{design}} \right)} $$

Ini memastikan bahwa dokumentasi ilmiah tetap presisi dan siap dipresentasikan tanpa bergantung pada editor persamaan komersial.

Perbandingan Biaya: FOSS vs Software Komersial

Tahap	FOSS	Software Komersial	Harga Lisensi / Tahun
Digitalisasi data	WebPlotDigitizer	OriginLab Digitizer, MATLAB Toolbox	USD 500–2.000
Analisis & visualisasi	Python	MATLAB, OriginPro	USD 1.000–2.500
Draft konten	Markdown + Joplin	MS Word + Visio	USD 150–1.000
Konversi & layout	Pandoc + Overleaf	Adobe InDesign	USD 250–1.200
Audio narasi	Python TTS	Adobe Audition + TTS API	USD 200–1.000
Distribusi	Ghost CMS	CMS enterprise + Acrobat Pro DC	USD 200–600
Total Estimasi	± USD 0	USD 2.300–8.300	—
Selisih Estimasi	—	—	± Rp 35–125 juta

Catatan: Estimasi harga lisensi bersifat indikatif dan dapat berubah tergantung wilayah, diskon institusi, dan versi. Tidak termasuk biaya pelatihan, integrasi, atau perangkat keras.

Diagram Alur Keputusan

flowchart TD A["Mulai Proyek Teknikal"] --> B{"Pilih Workflow"} B -- FOSS --> C["Zero-Cost Engineering"] B -- Komersial --> D["Software Berbayar"] C --> E1["Biaya Lisensi: ± USD 0"] & G1["Investasi: Waktu, Dokumentasi, Pelatihan"] & H1["Hasil: Whitepaper, Blog, Audio, Diagram"] D --> E2["Biaya Lisensi: USD 2.300–8.300"] & G2["Investasi: Lisensi, Integrasi, Pelatihan"] & H2["Hasil: Sama, tergantung lisensi & platform"] E2 --> F["Rugi Potensial: Rp 35–125 juta"] A@{ shape: rounded} C@{ shape: rounded} D@{ shape: rounded} E1@{ shape: rounded} G1@{ shape: rounded} H1@{ shape: rounded} E2@{ shape: rounded} G2@{ shape: rounded} H2@{ shape: rounded} F@{ shape: rounded} A:::Sky A:::Sky B:::Sky C:::Aqua C:::Pine D:::Ash E1:::Sky G1:::Sky H1:::Sky E2:::Sky G2:::Sky H2:::Sky F:::Rose classDef Ash stroke-width:1px, stroke-dasharray:none, stroke:#999999, fill:#999999, color:#FFFFFF classDef Peach stroke-width:1px, stroke-dasharray:none, stroke:#FBB35A, fill:#FFEFDB, color:#8F632D classDef Pine stroke-width:1px, stroke-dasharray:none, stroke:#254336, fill:#27654A, color:#FFFFFF classDef Rose stroke-width:1px, stroke-dasharray:none, stroke:#FF5978, fill:#FF5978, color:#FFFFFF classDef Sky stroke-width:1px, stroke-dasharray:none, stroke:#374D7C, fill:#E2EBFF, color:#374D7C

Gambar 2: Diagram alur keputusan teknikal — memilih antara workflow FOSS dan software komersial, beserta dampak biaya dan hasilnya

Kesimpulan

Saat pertama kali menggunakan Linux di tahun 2000, saya membayangkan masa depan di mana alat open-source menjadi tulang punggung alur kerja industri dan rekayasa. Dua dekade kemudian, Zero-Cost Engineering membuktikan bahwa visi ini bukan hanya mungkin — tapi sedang terjadi.

Zero-Cost Engineering adalah filosofi bahwa keterbatasan biaya tidak membatasi kualitas hasil — bukan sekadar strategi hemat, melainkan pendekatan sistemik untuk membangun ekosistem kerja yang transparan, modular, dan siap diuji ulang. Hasil teknis yang kompleks bisa disampaikan dengan profesional — setara (bahkan melampaui) workflow berbasis solusi berbayar. Meskipun membutuhkan adaptasi bagi tim yang terbiasa dengan perangkat lunak berbayar, manfaat jangka panjangnya signifikan.

Selain solusi yang digunakan di sini, saya juga mengandalkan Rapid SCADA untuk pemantauan industri, Node-RED untuk otomasi alur kerja, 4diac FORTE untuk kontrol IEC 61499, serta alat lain seperti ZeroTier untuk jaringan virtual yang aman, RutOS/OpenWrt untuk manajemen perangkat edge, mbusd untuk komunikasi Modbus TCP/RTU, dan sistem berbasis Ubuntu atau turunan Debian untuk integrasi IIoT. Semua ini memperkuat filosofi Zero-Cost Engineering — bahwa hasil profesional dapat dicapai tanpa lisensi berbayar, dengan ekosistem kerja yang terbuka, modular, dan siap diuji ulang.

"Siap mencoba Zero-Cost Engineering? Gunakan alat FOSS ini dan mulai proyek Anda dengan efisiensi maksimal."

Kolom Bawah: Terlalu Dingin Bisa Membuat Nitrogen Tercemar Oksigen?

2025-07-27T18:57:54+00:00

Terlalu Dingin Bisa Membuat Nitrogen Tercemar Oksigen?

0:00

/5.064

Pernahkah kamu bertanya, bagaimana udara diubah menjadi oksigen murni atau nitrogen murni? Teknologi di baliknya disebut distilasi kriogenik. Tapi proses ini bukan cuma sekadar membekukan — ia harus dikendalikan dengan sangat presisi.

Distilasi kriogenik adalah jantung dari proses pemisahan udara menjadi oksigen, nitrogen, dan argon. Proses ini sangat bergantung pada suhu dan tekanan yang tepat, karena pemisahan terjadi berdasarkan perbedaan titik didih tiap komponen.

Salah satu bagian paling penting dari proses distilasi kriogenik adalah kolom distilasi bagian bawah. Di sinilah udara cair dipisahkan menjadi dua komponen utama: nitrogen naik ke atas, dan oksigen terkonsentrasi turun ke bawah.

Ya, kita sedang bicara kolom bawah — tempat pertama pemisahan terjadi sebelum masuk ke kolom atas untuk pemurnian lebih lanjut.

Tapi di kolom bawah ini, ada satu hal yang sering membingungkan:
“Kenapa suhu yang terlalu rendah justru membuat produk nitrogen tetap tercemar oksigen?”

Mari kita bahas dengan cara yang masuk akal dan mudah diingat.

Kolom Seperti Tangga

Bayangkan kolom distilasi sebagai tangga vertikal:

Uap naik dari bawah, membawa nitrogen, karena nitrogen paling mudah menguap.
Cairan turun dari atas, membawa oksigen, karena oksigen lebih sulit menguap.

Di setiap tray (semacam lantai kecil di dalam kolom), uap dan cairan bertemu dan saling bertukar komponen. Nitrogen cenderung menguap dan terus naik, sedangkan oksigen lebih mudah mengembun dan terus turun.

Apa yang Terjadi Jika Kolom Terlalu Dingin?

Saat kolom bawah terlalu dingin:

Uap nitrogen tidak terbentuk cukup banyak karena terlalu banyak yang terkondensasi jadi cair.
Aliran naik melemah — tidak ada dorongan uap yang cukup untuk menolak oksigen naik.

Akibatnya:

Oksigen ikut naik ke bagian atas, dan mencemari produk nitrogen.

Logika Tekanan Parsial

Secara termodinamika:

Di bagian atas kolom bawah, dominasi uap nitrogen menciptakan tekanan parsial nitrogen yang tinggi.
Ini seperti “penghalang molekul” yang mencegah oksigen untuk ikut menguap dan naik.

Namun, jika suhu terlalu rendah:

Uap nitrogen tidak cukup kuat.
Penghalang itu melemah, dan oksigen bisa ikut naik ke atas.

Komponen	Titik Didih @ 5.45 barA	Fase pada −170 °C
Nitrogen	−177.97 °C	Uap
Argon	−166.12 °C	Campuran
Oksigen	−163.27 °C	Cair

Biasanya suhu operasi kolom bawah dijaga sedikit di bawah titik didih nitrogen, misalnya sekitar −175 °C, tergantung tekanan operasi (misalnya 5.45 barA), untuk memastikan nitrogen mendidih dan oksigen mengembun secara selektif.

Bagaimana Jika Terlalu Hangat?

Sebaliknya, jika kolom bawah terlalu hangat:

Oksigen tidak cukup mengembun ke bentuk cair, sehingga gagal tertahan di bawah.
Oksigen bisa tetap dalam fase uap dan ikut naik bersama nitrogen.

Akibatnya:

Produk nitrogen tetap tercemar oksigen — tapi kali ini karena oksigen gagal turun, bukan karena naik secara pasif.

Visualisasi Sederhana

Bayangkan tiga kondisi suhu di kolom bawah:

Terlalu Dingin
Uap nitrogen lemah — oksigen ikut naik — nitrogen tidak murni.
Terlalu Hangat
Oksigen gagal mengembun — tetap dalam uap — ikut naik — nitrogen tercemar.
Normal (Ideal)
Tray bekerja optimal — nitrogen naik, oksigen turun — pemisahan sempurna.

Gambar 1. Animasi pemisahan oksigen dan nitrogen dalam kondisi terlalu dingin, normal, dan terlalu hangat.

Keseimbangan suhu = pemisahan optimal.

Mnemonik Mudah

Jika kamu ingin mengingatnya dengan cepat, cukup ingat ini:

“Terlalu dingin, tak ada yang naik. Terlalu hangat, tak ada yang turun.”

Apa yang Terjadi pada Liquid Air?

Cairan di dasar kolom bawah sering disebut sebagai liquid air, karena masih merupakan campuran oksigen, nitrogen, dan argon — belum sepenuhnya terpisah. Komposisinya mencerminkan seberapa baik proses pemisahan berlangsung di kolom bawah.

Suhu dasar kolom sangat mempengaruhi jumlah nitrogen yang tertahan dalam cairan ini:

Terlalu Dingin
Terlalu banyak nitrogen ikut mengembun — volume liquid air meningkat, tapi kandungannya lebih kaya nitrogen. Ini pertanda bahwa nitrogen tidak sepenuhnya menguap dan malah tertahan di dasar kolom.
Terlalu Hangat
Nitrogen sudah menguap sempurna, tapi oksigen dan argon belum cukup banyak yang mengembun.
Akibatnya: liquid air jadi lebih sedikit, tetap kaya oksigen, tapi miskin argon.
Sebagian oksigen ikut naik ke bagian atas, menurunkan kemurnian nitrogen di puncak kolom bawah.

Dalam praktik, komposisi liquid air (dari sensor inline atau analisis laboratorium) sering digunakan sebagai indikator tidak langsung apakah suhu dasar kolom sudah berada pada titik optimal.

Jika cairan di bawah terlalu "encer" (kaya nitrogen), kolom bisa terlalu dingin.
Jika cairannya terlalu "berat" (kaya oksigen), kolom bisa terlalu hangat.

Kesimpulan

Jangan kira semakin dingin itu semakin baik.
Jangan juga membiarkan kolom terlalu hangat.
Di kolom distilasi kriogenik, suhu yang terlalu ekstrem ke salah satu arah bisa membuat pemisahan gagal.
Jaga keseimbangan antara penguapan dan kondensasi agar nitrogen dan oksigen tetap di jalur masing-masing.

Surging pada Kompresor Sentrifugal: Ketika Masalah Besar Berawal dari Modifikasi Kecil

2025-07-21T15:56:15+00:00

Ketika Masalah Besar Berawal dari Modifikasi Kecil

0:00

/6.312

Pendahuluan

Your browser does not support the audio element.

Masalah kronis pada Kompresor Resirkulasi Nitrogen dan Booster Ekspander di unit Pabrik Pemisah Udara sudah muncul sejak commissioning, dipicu oleh modifikasi instalasi yang awalnya dimaksudkan untuk memberikan informasi kecepatan ekspander ke ruang kontrol untuk kepentingan operasional, namun berujung pada dampak teknis jangka panjang.

Perlu hampir sepuluh tahun—sejak saya mulai bekerja di industri ini pada 2007 hingga akhirnya terpecahkan di 2017—untuk benar-benar memahami dan menyelesaikan masalah ini. Dalam kurun waktu tersebut dan pasti juga sebelumnya, berbagai upaya telah dilakukan, namun sebagian besar hanya menyentuh gejalanya—bukan akarnya. Dari perspektif saya, artikel ini merekam perjalanan panjang—dari kecurigaan awal, eksperimen lapangan, hingga penyelesaian yang akhirnya mengembalikan sistem ke logika desain aslinya. Silakan memberikan sanggahan jika dirasa ada yang kurang tepat.

Awal Mula Masalah

Your browser does not support the audio element.

Sejak awal, masalah ini seperti dipahami dengan premis yang keliru: hampir semua perhatian tertuju pada kompresor resirkulasi nitrogen, seolah-olah ia selalu menjadi biang keladi. Namun sejak awal, saya mencurigai ada yang tidak beres—terutama dalam urutan shutdown antara kompresor resirkulasi nitrogen dan booster ekspander.

DCS menunjukkan bahwa kompresor resirkulasi nitrogen trip terlebih dahulu, tetapi saya meragukan kebenaran data ini. Ada kabel interlock yang memungkinkan kompresor resirkulasi nitrogen trip atas permintaan dari booster ekspander, sementara DCS—yang memproses ratusan I/O—bisa mengalami latensi dalam mencatat urutan kejadian, terutama yang terjadi dalam skala milidetik. Ini karena DCS melakukan siklus pemindaian terhadap I/O secara sekuensial, sedangkan sinyal trip bisa muncul tidak sinkron, baik di depan maupun di belakang jalannya siklus.

Demi memastikan urutan shutdown yang sebenarnya, saya merakit sendiri sebuah PLC Siemens S7 sebagai pencatan even berkecepatan tinggi. Resolusi tinggi menjadi satu-satunya cara untuk secara obyektif membuktikan siapa yang benar-benar lebih dulu trip. Hasil pengujiannya konsisten: 100% kejadian menunjukkan bahwa booster-lah yang lebih dulu trip. Ini disebabkan oleh pembukaan bypass booster secara mendadak, yang memicu surging pada kompresor resirkulasi nitrogen, akhirnya kompresor resirkulasi nitrogen ikut trip juga melalui perintah interlock. Tentu tidak semua langsung setuju dengan kesimpulan ini—karena memahami cara kerja DCS dan PLC memang memerlukan keahlian teknis yang mendalam.

Logika Ladder – Deteksi Trip yang Adil

Logika ladder di bawah ini menerapkan sistem deteksi trip yang deterministik dengan menggunakan deteksi rising edge dan penanda memori.
Sistem ini memastikan bahwa input mana pun—kompresor resirkulasi nitrogen atau booster ekspander—yang memicu trip pertama akan dicatat secara objektif, tanpa dipengaruhi oleh urutan pemindaian PLC.

Klik untuk membuka Logika Ladder dan Tabel Simbol PLC

Surging on Centrifugal Compressor: When Big Problems Start from Small Modifications

2025-07-18T19:23:19+00:00

When Big Problems Start from Small Modifications

0:00

/6.84

Introduction

Your browser does not support the audio element.

Chronic issues with the Recycle Nitrogen Compressor and Booster Expander in the Air Separation Plant unit have been present since commissioning, triggered by installation modifications initially intended to provide expander speed information to the control room for operational purposes, but ultimately leading to long-term technical impacts.

It took nearly ten years—from when I started working in this industry in 2007 until the problem was finally resolved in 2017—to truly understand and solve this issue. During that time, and certainly before, various efforts were made, but most only addressed the symptoms—not the root cause. From my perspective, this article records a long journey—from initial suspicions, field experiments, to the resolution that finally restored the system to its original design logic. Please feel free to provide counterarguments if you feel there are inaccuracies.

The Beginning of the Problem

Your browser does not support the audio element.

From the start, this problem seemed to be understood with a flawed premise: almost all attention was focused on the recycle nitrogen compressor, as if it was always the culprit. However, from the beginning, I suspected something was amiss—especially in the shutdown sequence between the recycle nitrogen compressor and booster expander.

DCS showed that the recycle nitrogen compressor tripped first, but I doubted the accuracy of this data. There was a hardwired interlock that allowed the recycle nitrogen compressor to trip upon request from the booster expander, while DCS—which processes hundreds of I/Os—could experience latency in recording the sequence of events, especially those occurring within milliseconds. This is because DCS performs a cyclic scan of I/Os sequentially, whereas trip signals can appear asynchronously, either ahead of or behind the scan cycle.

To ensure the actual shutdown sequence, I assembled a Siemens S7 PLC as a high-speed event logger. High resolution was the only way to objectively prove who actually tripped first. The test results were consistent: 100% of events showed that the booster tripped first. This was caused by the sudden opening of the booster bypass, which triggered surging on the recycle nitrogen compressor, eventually causing the recycle nitrogen compressor to trip as well through interlock commands. Of course, not everyone immediately agreed with this conclusion—because understanding how DCS and PLC work requires deep technical expertise.

Ladder Logic – Fair Trip Detection

The ladder logic below implements a deterministic trip detection system using rising edge recognition and memory flags.
It ensures that whichever input (recycle nitrogen compressor or booster expander) triggers a trip first is recorded objectively—regardless of PLC scan order.

Click to reveal for Ladder Logic and PLC Symbol Table