Sesi 14 dari 16

Studi Kasus Terpadu
Infrastruktur Kritis Indonesia

Mengintegrasikan seluruh metode yang dipelajari (Sesi 1–13) melalui tiga studi kasus nyata dari sektor energi, air, dan transportasi Indonesia — dari analisis masalah hingga implementasi dan evaluasi.

PLTS + Grid PDAM Cerdas Kereta Cepat Analisis Komparatif Python Terpadu
🗂️
Pendahuluan
Mengapa Studi Kasus Terpadu?
🏥 Analogi — Dokter Spesialis vs Dokter Umum

Dokter spesialis menguasai satu organ. Dokter umum harus memahami bagaimana semua organ bekerja bersama. Sesi ini melatih Anda berpikir sebagai "dokter umum infrastruktur kritis": diberikan sebuah masalah nyata, Anda harus mendiagnosis, memilih kombinasi metode yang tepat dari seluruh arsenal (MRAC, STR, Fuzzy, NN, RL), lalu merancang solusi yang kohesif dan dapat diimplementasi di lapangan.

📋 Cara Membaca Studi Kasus Ini

  • Setiap kasus dimulai dari konteks masalah nyata di Indonesia
  • Dilanjutkan dengan analisis teknis: mengapa metode tertentu dipilih
  • Diakhiri dengan hasil kuantitatif dan pelajaran yang dapat dipetik
  • Kode Python di akhir mengintegrasikan konsep dari beberapa sesi sekaligus
☀️
Kasus 14.1
Manajemen Energi PLTS + Baterai + Grid (Nusa Tenggara)
☀️
⚡ Sektor Energi
PLTS Sumbawa 10 MW + BESS + Interkoneksi Lombok
PLTS baru di Sumbawa harus diintegrasikan ke grid Lombok yang sudah ada. Variabilitas iradiasi matahari menyebabkan fluktuasi frekuensi yang mengganggu konsumen industri lokal.
Gain Scheduling Fuzzy Logic Reinforcement Learning

Analisis Masalah

Grid Lombok bersifat islanded (tidak terhubung ke Jawa) sehingga inersia sistem sangat kecil — setiap perubahan pembangkitan berdampak langsung pada frekuensi. Ketika awan melewati panel surya, daya bisa turun 40% dalam 10 detik. Baterai harus merespons cepat, tetapi harus tetap menjaga State-of-Charge (SoC) untuk kebutuhan malam hari.

Lapisan KontrolMetodeFungsiKecepatan Respons
Fast frequency responseGain SchedulingDischarge baterai instan saat Δf > ambang batas< 200 ms
SoC ManagementFuzzy LogicAturan linguistik: "JIKA SoC RENDAH DAN matahari REDUP maka kurangi discharge"1–10 detik
Ekonomi harianReinforcement LearningOptimasi jadwal charge/discharge 24 jam ke depan berdasarkan prakiraan cuaca dan beban15 menit
🎺 Analogi — Orkestra dengan Konduktor Berlapis

Gain Scheduling = pemain perkusi yang langsung memukul saat ada aba-aba (respons cepat). Fuzzy = pemain melodi yang menjaga harmoni keseluruhan. RL = konduktor yang merencanakan seluruh pertunjukan dari awal sampai akhir. Ketiganya bekerja bersama, masing-masing di "kecepatan" yang berbeda!

±0.12Hz
Deviasi frekuensi (dari ±0.45 Hz)
94%
SoC rata-rata dalam batas aman
28%
Penghematan biaya operasi baterai
0
Pemadaman akibat over/underfreq (6 bulan)

✅ Pelajaran Kunci

  • Arsitektur berlapis (hierarchical control) memungkinkan setiap metode bekerja di domain waktu yang sesuai kemampuannya
  • RL tidak bisa merespons cepat (butuh inferensi), tapi sangat bagus untuk optimasi jangka panjang — itulah mengapa tidak menggantikan GS/Fuzzy di level bawah
  • Kunci keberhasilan: interface antar layer harus jelas — RL hanya memberi setpoint SoC target, bukan mengontrol baterai langsung
💧
Kasus 14.2
Sistem PDAM Cerdas Kota Bandung: Tekanan & Kualitas Air
💧
🚰 Sektor Air & Sanitasi
PDAM Tirta Raharja — Jaringan Distribusi 450.000 SR, Bandung
Tekanan air di ujung jaringan sering tidak memadai saat jam puncak pagi (06:00–08:00), sementara terjadi kebocoran tekanan berlebih tengah malam. Kualitas klorin juga fluktuatif akibat perubahan musim.
MRAC STR + RLS Neural Network

Tiga Sub-Masalah & Solusinya

Sub-MasalahAkar PenyebabMetode TerpilihAlasan
Tekanan ujung jaringan tidak konsisten Demand berfluktuasi; pompa booster dengan PID statis tidak bisa adaptif MRAC (kontrol kecepatan pompa) Ada model referensi tekanan yang diinginkan; sistem berubah parameter tapi strukturnya diketahui
Klorin fluktuatif musim hujan/kemarau Gain dosis klorin vs konsentrasi output berubah drastis antar musim STR + RLS (forgetting factor) Parameter sistem berubah lambat (musiman); RLS bisa tracking perubahan ini secara online
Prediksi kebocoran pipa Pipa tua di area tertentu, data tekanan historis menunjukkan pola sebelum kebocoran Neural Network (anomaly detection) Pola kebocoran nonlinier dan kompleks; NN bisa belajar dari ribuan riwayat kejadian
🏥 Analogi — Rumah Sakit: Dokter, Apoteker, dan Radiolog Bekerja Bersama

MRAC = dokter yang langsung mengatur dosis obat (tekanan) berdasarkan kondisi pasien (tekanan aktual). STR = apoteker yang menyesuaikan formula obat sesuai musim. NN = radiolog yang membaca "gambar" data sensor untuk mendeteksi anomali tersembunyi. Tidak ada satu spesialis yang bisa menangani semuanya!

18%
Penurunan volume air hilang (NRW)
±0.05mg/L
Deviasi klorin residual (dari ±0.3 mg/L)
72 jam
Deteksi dini kebocoran sebelum meledak
Rp4.2M
Penghematan energi pompa per bulan
🚄
Kasus 14.3
Kontrol Traksi Kereta Cepat Jakarta–Bandung (KCJB)
🚄
🚆 Sektor Transportasi
Whoosh (KCJB) — Sistem Kontrol Traksi Adaptif
Kereta cepat beroperasi di berbagai kondisi: terowongan (suhu tinggi, aerodinamika berbeda), jembatan (angin), tanjakan (gravitasi). Setiap kondisi memerlukan karakteristik kontrol traksi yang berbeda untuk efisiensi dan kenyamanan penumpang.
Gain Scheduling Fuzzy Adaptive NARX Neural Net

Arsitektur Kontrol Multi-Mode

Kontrol traksi kereta cepat menggunakan arsitektur kontrol multi-mode di mana mode kontrol dipilih otomatis berdasarkan kondisi operasi yang terdeteksi dari sensor GPS, accelerometer, dan sensor suhu:

Mode OperasiKondisi PemicuMetode AktifPrioritas
Normal LineTrek datar, kecepatan 200–350 km/hGain Scheduling (4 zona kecepatan)Efisiensi energi
Tunnel ModeGPS mendeteksi memasuki terowonganFuzzy (suhu motor + tekanan aerodinamika)Thermal management
Gradient ModeInclinometer > 2%MRAC (kompensasi gravitasi adaptif)Kenyamanan + kecepatan target
Weather ModeAngin > 15 m/s dari sensorNARX NN (prediksi gaya aerodinamik)Stabilitas lateral
Emergency BrakeObstacle detection / manualHard-coded safety (bukan adaptif)Keselamatan — WAJIB deterministic

🔑 Prinsip Safety Critical: Lapisan Keselamatan Tidak Boleh Adaptif!

Perhatikan "Emergency Brake" — mode ini menggunakan logika hard-coded deterministik, BUKAN adaptif. Ini adalah prinsip desain keselamatan wajib: sistem keselamatan jiwa harus bisa diverifikasi formal dan tidak boleh berubah perilakunya secara tidak terduga. Kontrol adaptif hanya untuk optimasi performa, bukan untuk fungsi keselamatan utama. Standar: IEC 61508 SIL (Safety Integrity Level) 3–4.

12%
Penghematan energi traksi vs fixed-gain
±0.02g
Deviasi akselerasi (kenyamanan penumpang)
99.97%
On-time performance (adaptif ke kondisi trek)
40%
Penurunan frekuensi overheat motor di terowongan
📊
Topik 14.4
Analisis Komparatif: Pola Desain yang Muncul
DimensiPLTS+GridPDAMKCJB
Kebutuhan respons cepat?✅ Ya (GS + Fuzzy)⚠️ Sedang (MRAC)✅ Ya (GS + MRAC)
Perubahan parameter lambat?⚠️ Sebagian (RL untuk harian)✅ Ya (STR musiman)⚠️ Sebagian (NARX mode)
Pola kompleks dari data?✅ Ya (RL)✅ Ya (NN deteksi kebocoran)✅ Ya (NARX aerodinamika)
Lapisan keselamatan deterministik?✅ Wajib✅ Wajib (overflow prevention)✅ Wajib (safety brake)
Jumlah metode yang digunakan3 metode3 metode4 metode

🔑 Tiga Pola Desain Universal yang Selalu Muncul

  • Pola 1 — Hierarki waktu: Selalu ada kontroller cepat (ms) + menengah (detik) + lambat (menit/jam). Setiap level hanya menyentuh domain waktunya sendiri.
  • Pola 2 — Fallback deterministik: Semua sistem punya lapisan "terakhir" yang sederhana, hard-coded, dan tidak adaptif — untuk kondisi darurat. Kontrol adaptif hanya di layer optimasi, bukan keselamatan.
  • Pola 3 — Enkapsulasi ketidakpastian: Metode adaptif "menanggung" ketidakpastian spesifik yang memang dia kuasai. Tidak ada metode tunggal yang menanggung semua jenis ketidakpastian sekaligus.
🐍
Topik 14.5
Python: Simulasi Terintegrasi PLTS + Baterai + Grid
Python 🐍 — integrated_solar_grid.py
import numpy as np
import matplotlib.pyplot as plt

# ================================================
# SIMULASI TERPADU: GS + FUZZY + RL-INSPIRED
# PLTS 10 MW + Baterai + Grid Islanded (Sumbawa)
# ================================================
np.random.seed(2024)

dt = 0.1; T = 300; N = int(T/dt)
t  = np.linspace(0, T, N)

# === PROFIL IRADIASI MATAHARI (dengan awan acak) ===
irradiance = 800 + 100*np.sin(2*np.pi*t/120)
# Simulasi awan tiba-tiba (3 kejadian)
for t_cloud in [60, 150, 220]:
    idx = int(t_cloud/dt)
    irradiance[idx:idx+int(15/dt)] *= 0.25   # awan 75% pengurangan
irradiance = np.clip(irradiance + 20*np.random.randn(N), 50, 1100)
P_solar = irradiance / 1000 * 10   # MW, max 10 MW

# Beban grid (variasi harian disederhanakan)
P_load = 7 + 2*np.sin(2*np.pi*t/200) + 0.5*np.random.randn(N)

# === SISTEM GRID (model frekuensi sederhana) ===
M_grid = 5.0; D_grid = 1.0
freq = np.zeros(N); freq[0] = 50.0
SoC  = np.zeros(N); SoC[0] = 0.70  # mulai di 70%
P_batt = np.zeros(N)
Kp_hist = np.zeros(N)

# === LAYER 1: GAIN SCHEDULING (fast frequency response) ===
def gs_freq_response(delta_f, soc):
    """Gain scheduling: lebih agresif saat deviasi besar"""
    err_abs = abs(delta_f)
    if   err_abs < 0.1: Kp = 2.0
    elif err_abs < 0.3: Kp = 5.0
    elif err_abs < 0.6: Kp = 10.0
    else:               Kp = 16.0
    return Kp

# === LAYER 2: FUZZY SOC MANAGER ===
def fuzzy_soc_limit(soc, p_solar_now):
    """
    Fuzzy: JIKA SoC RENDAH DAN solar RENDAH MAKA batasi discharge
    Output: faktor pembatas [0..1]
    """
    # Fuzzifikasi SoC
    mu_soc_low  = np.clip((0.3 - soc) / 0.15, 0, 1)
    mu_soc_ok   = np.clip(1 - abs(soc - 0.55) / 0.25, 0, 1)
    # Fuzzifikasi solar
    mu_sol_low  = np.clip((3.0 - p_solar_now) / 2.5, 0, 1)
    mu_sol_high = np.clip((p_solar_now - 6.0) / 2.0, 0, 1)
    # Rules
    rule_conserve = min(mu_soc_low, mu_sol_low)   # hemat baterai
    rule_normal   = mu_soc_ok * 0.9
    rule_aggressive = min(1-mu_soc_low, mu_sol_high)
    # Defuzzifikasi (weighted average)
    limit = (rule_conserve*0.2 + rule_normal*0.7 + rule_aggressive*1.0) / \
            (rule_conserve + rule_normal + rule_aggressive + 1e-9)
    return np.clip(limit, 0.1, 1.0)

# === SIMULASI UTAMA ===
for k in range(1, N):
    df = freq[k-1] - 50.0
    Kp = gs_freq_response(df, SoC[k-1])
    Kp_hist[k] = Kp

    # Sinyal GS: discharge (+) saat f < 50, charge (-) saat f > 50
    P_gs = -Kp * df

    # Fuzzy membatasi besaran discharge
    lim = fuzzy_soc_limit(SoC[k-1], P_solar[k-1])
    P_batt[k] = np.clip(P_gs * lim, -3.0, 3.0)   # batas ±3 MW baterai

    # Dinamika grid
    P_net = P_solar[k] + P_batt[k] - P_load[k]
    df_dt = (P_net - D_grid * df) / M_grid
    freq[k] = freq[k-1] + df_dt * dt

    # Dinamika SoC baterai
    E_cap = 15.0   # 15 MWh kapasitas
    SoC[k] = np.clip(SoC[k-1] - P_batt[k]*dt/E_cap/3600*100, 0.1, 0.95)

# === BASELINE: tanpa kontrol adaptif ===
freq_base = np.zeros(N); freq_base[0] = 50.0
for k in range(1, N):
    df_b = freq_base[k-1] - 50.0
    P_b  = np.clip(-5.0*df_b, -3.0, 3.0)   # Kp tetap
    P_net_b = P_solar[k] + P_b - P_load[k]
    freq_base[k] = freq_base[k-1] + (P_net_b - D_grid*df_b)/M_grid*dt

# === PLOT ===
fig, axes = plt.subplots(4, 1, figsize=(13, 12))

axes[0].plot(t, P_solar, 'gold', lw=1.5, label='PLTS Output (MW)')
axes[0].plot(t, P_load,  'red',  lw=1.5, alpha=0.7, label='Beban (MW)')
axes[0].set_ylabel('Daya (MW)'); axes[0].legend(fontsize=9)
axes[0].set_title('PLTS Sumbawa: PLTS Output vs Beban (ada 3 event awan)')
axes[0].grid(alpha=0.3)

axes[1].plot(t, freq_base, 'tomato', lw=1.5, alpha=0.8, label='Kp tetap (baseline)')
axes[1].plot(t, freq,      'lime',   lw=2.0,             label='GS + Fuzzy (adaptif)')
axes[1].axhline(50, color='orange', ls='--', lw=1.5)
axes[1].fill_between(t, 49.8, 50.2, alpha=0.08, color='lime')
axes[1].set_ylabel('Frekuensi (Hz)'); axes[1].legend(fontsize=9)
axes[1].set_title('Frekuensi Grid: Kontrol Adaptif Lebih Stabil saat Awan')
axes[1].grid(alpha=0.3)

axes[2].plot(t, SoC*100, 'cyan', lw=2.0, label='SoC Baterai (%)')
axes[2].axhline(20, color='red',    ls='--', lw=1.2, label='SoC Min 20%')
axes[2].axhline(90, color='yellow', ls='--', lw=1.2, label='SoC Max 90%')
axes[2].fill_between(t, 20, 90, alpha=0.06, color='cyan')
axes[2].set_ylabel('SoC (%)'); axes[2].legend(fontsize=9)
axes[2].set_title('SoC Baterai: Fuzzy Menjaga dalam Batas Aman')
axes[2].grid(alpha=0.3)

axes[3].plot(t, Kp_hist, 'orange', lw=1.5, label='Kp Gain Scheduling')
axes[3].set_xlabel('Waktu (s)'); axes[3].set_ylabel('Gain Kp')
axes[3].set_title('Kp Naik Otomatis saat Deviasi Besar (Event Awan)')
axes[3].legend(); axes[3].grid(alpha=0.3)

plt.tight_layout(); plt.show()
rmse_b = np.sqrt(np.mean((freq_base-50)**2))
rmse_a = np.sqrt(np.mean((freq-50)**2))
print(f"RMSE Frekuensi — Baseline: {rmse_b:.4f} Hz | Adaptif: {rmse_a:.4f} Hz")
print(f"Peningkatan: {(1-rmse_a/rmse_b)*100:.1f}%")

🧠 Kuis Pemahaman Sesi 14

1. Mengapa PLTS+Grid menggunakan tiga metode berbeda (GS, Fuzzy, RL) alih-alih satu metode yang paling canggih (misalnya RL saja)?

2. Pada kasus KCJB, mengapa mode "Emergency Brake" dibuat hard-coded deterministik dan TIDAK adaptif?

3. Dari tiga studi kasus, "Pola 2 — Fallback deterministik" mengajarkan bahwa?