Sejarah SCADA Distribusi Pengawas Pengendalian Dan Data Akuisisi (SCADA) merupakan dasar untuk sistem otomatisasi distribusi.

Pemadaman listrik tahun 1965 mendorong Komisi Power US Federal untuk merekomendasikan koordinasi yang lebih erat antara kelompok koordinasi regional (Aturan Keandalan Tenaga Listrik UU 1967), dan memberikan dorongan untuk pembentukan berikutnya Nasional Electric Reliability Council (1970). Dari waktu itu (1970) ke depan, prioritas dari utilitas listrik adalah untuk insinyur dan pembangunan suatu infrastruktur transmisi yang sangat handal dan aman. Pada pertengahan 1980-an, EPRI menerbitkan definisi untuk otomatisasi distribusi dan unsure terkait. Industri pada umumnya menggabungkan otomatisasi distribusi dengan instalasi perangkat otomatisasi jaringan distribusi, seperti switch, reclosers, sectionalizers, dll. Definisi penulis, otomatisasi distribusi meliputi otomatisasi dari gardu distribusi dan perangkat jaringan distribusi. Gardu distribusi yang diotomatisasi dan perangkat otomatisasi jaringan distribusi tersebut kemudian dioperasikan sebagai satu sistem untuk memudahkan pengoperasian system distribusi listrik. Bagian Pertama: Perencanaan Pembuatan SCADA DMS SCADA System Elements Pada tingkat tinggi, elemen-elemen dari sistem otomatisasi distribusi dapat dibagi menjadi tiga bidang utama: Aplikasi SCADA dan server (s) Aplikasi DMS dan server (s) Aplikasi manajemen Trouble dan server (s) SCADA Distribusi Seperti yang telah dinyatakan dalam pendahuluan, Pengawasan Control Dan Akuisisi Data (SCADA) sistem merupakan jantung dari arsitektur Distribusi Management System (DMS). Suatu sistem SCADA harus memiliki semua elemen infrastruktur untuk mendukung sifat multifaset dari otomatisasi distribusi dan aplikasi-aplikasi yang lebih tinggi dari DMS. Salah satu fungsi utama sistem SCADA Distribusi adalah untuk mendukung operasi telemetri distribusi, alarming, rekaman kejadian, dan remote control untuk peralatan lapangan. Suatu sistem SCADA modern harus mendukung anggaran rekayasa dan fungsi perencanaan dengan menyediakan akses ke data sistem tenaga tanpa harus memiliki sebuah workstation operasional. Elemen-elemen utama dari suatu sistem SCADA adalah: Host peralatan Infrastruktur komunikasi (jaringan dan serial komunikasi) Perangkat di lapangan (dalam jumlah yang cukup untuk mendukung operasi dan persyaratan telemetri dari platform DMS) Taktik dan Strategi Implemensi Dengan pemberlakuan deregulasi dan munculnya persaingan, retensi pelanggan industri dan komersial yangbesar akan menjadi prioritas untuk utilitas listrik. Setiap keuntungan akan dicari oleh utilitas listrik untuk membedakan dirinya dari utilitas lain. Layanan yang handal, kepuasan pelanggan, restorasi badai cepat, dan kualitas daya akan menjadi tujuan utilitas. Strategi-strategi yang berbeda akan dipekerjakan berbasiskan pelanggan dalam pertanyaan dan berbagai tujuan tertentu yang utilitas rasakan akan dapat membawa loyalitas pelanggan. Untuk pelanggan besar industri dan komersial, di mana keandalan layanan listrik penting dan pemadaman yang lebih dari beberapa detik bisa berarti kerugian pada proses produksi atau kehilangan keuntungan, taktik dengan solusi otomatisasi mungkin diperlukan. Taktik solusi biasanya berupa skema transfer atau skema switching yang dapat merespon secara independen tindakan operator, melaporkan tindakan yang telah diinisialisi dalam menanggapi hilangnya layanan yang disukai dan / atau failure pada jaringan. Persyaratan untuk mentransfer sumber

daya, atau mengkonfigurasi ulang bagian dari sistem distribusi listrik untuk mengisolasi dan menghubungkan kembali dalam hitungan detik adalah kriteria utama. Ketika persyaratan yang sama diterapkan ke area yang luas dan / atau berbasiskan pelanggan, suatu solusi strategis berdasarkan platform manajemen distribusi lebih disukai. Solusi ini memerlukan DMS dengan model sistem operasional yang mencerminkan konfigurasi sistem distribusi listrik pada saat itu. Isolasi kesalahan dan aplikasi restorasi secara otomatis yang dapat mengkonfigurasi ulang sistem distribusi listrik, memerlukan sebuah pemodelan "seluruh sistem" untuk mengoperasikan dengan benar dan efisien. Pertimbangan Praktis Pemilihan Vendor Pemilihan suatu Platform Vendor Dalam memilih sebuah platform (SCADA, DMS, TMS) vendor ada beberapa karakteristik yang harus diingat (ini harus dipertimbangkan sebagai aturan praktis berdasarkan pengalaman yang berhasil dan yang tidak). Memilih vendor yang tepat sama pentingnya dengan memilih paket perangkat lunak yang tepat. Karakteristik Vendor bahwa penulis anggap penting adalah: Sebuah "produk" yang mempunyai filsafat kuat. Memiliki filsafat produk yang kuat biasanya proposisi ayam dan telur. Yang datang pertama, produk atau filosofi? Memiliki baseline aplikasi SCADA dapat menjadi tanda kematangan dan stabilitas. Apakah vendor platform yang sampai di sana dengan desain atau mereka kembali ke dalamnya? Bukti dari filosofi produk termasuk sistem dasar yang ada di dalam produksi dan perangkat tambahan yang terintegrasi secara terencana dengan pengujian menyeluruh pada pengujian peningkatan dan regresi pada produk bersama dengan dokumentasi lengkap dan komprehensif. Perkembangan yang didokumentasikan dan release path yang diproyeksikan tiga sampai lima tahun ke depan. Dengan menyimpulkan dari dua point pertama, vendor merencanakan dana untuk peningkatan produk dari dana internal. Grup User yang kuat dan aktif merupakan representasi dari industri dan drivers industri. Sebuah vendor platform yang secara aktif mendorong User Group mereka dengan insentif (misalnya, bagian mendedikasikan dana tambahan untuk inisiatif User Group). A vendor that is generally conservative in moving its platform to a new technology; one that does not overextend its own resources. Sebuah vendor yang umumnya konservatif dalam pergerakkan platform untuk sebuah teknologi baru, salah satu yang tidak hanya menggunakan sumber daya sendiri. Pertimbangan Lainnya Sebisa mungkin, membeli platform yang off-the-shelf product (yaitu, menahan keinginan/ketergantungan untuk meminta modifikasi/kustomisasi yang mendrive sistem Anda jauh dari vendor baseline). Jika memungkinkan, memelihara / mengembangkan staf pendukung Anda sendiri Semua "kustomisasi"harus dibangun di sekitar kemampuan yang melekat dan fleksibilitas dari sistem (yakni, tidak menimbulkan jumlah yang berlebihan kode baru). Ingat, Anda harus mengajukan permohonan kembali pengembangan kode apapun yang mungkin Anda miliki untuk setiap rilis baru, atau lebih buruk, Anda akan harus membayar vendor untuk melakukannya untuk Anda. Standards Internal Standards Para penulis sangat merekomendasikan penggunaan standar (internal untuk organisasi Anda) sebagai dasar untuk menjamin otomatisasi distribusi atau program SCADA berhasil. Pendokumentasikan yang baik standar konstruksi yang ditentukan untuk instalasi RTUs, switch, dan sensor sesuai dengan spesifikasi mekanis dan listrik akan memastikan instalasi peralatan yang konsisten dari site ke site.

Standar yang mencakup nontrivial, tetapi sering menjadi isu-isu yang diabaikan dapat menjadi perbedaan mengeja antara penerimaan dan penolakan oleh pengguna operasional dan memberikan manfaat tambahan dari sistem yang dimiliki "dipertahankan" selama tahun 10-20 (atau lebih) hidup sistem. Standar yang termasuk dalam kategori ini termasuk standar yang mencakup titik-konvensi penamaan, standar simbol, tampilan standar, dan Operasi Manual yang sangat penting. Industry Standards Secara umum, standar jatuh ke dalam dua kategori: standar yang dikembangkan oleh organisasi dan komisi (misalnya, EPRI, IEEE, ANSI, CCITT, ISO, dll) dan de facto standar yang menjadi standar berdasarkan penerimaan luas. Sebagai contoh dari apa yang dapat terjadi, pembaca diundang untuk mempertimbangkan apa yang terjadi dalam protokol jaringan selama masa lalu berkaitan dengan model OSI dan TCP / IP. Sejarah masa lalu SCADA dan otomatisasi telah didominasi oleh sifat kepemilikan dari penawaran vendor berbagai sistem. Database dan skema protokol komunikasi RTU adalah teladan dari filosofi desain eksklusif digunakan oleh vendor platform SCADA dan RTU. Utilitas Listrik yang mengoperasikan sebagian dari jaringan listrik interkoneksi telah frustrasi dengan kurangnya kemampuan untuk data sistem berbagi kekuasaan antara sistem manajemen energy yang berbeda. Frustrasi yang sama ada di tingkat perangkat; RTU vendor, PLC vendor, vendor relay elektronik, dan vendor meter masing-masing memiliki protokol sendiri produk telah menciptakan sebuah "Menara Babel" masalah bagi utilitas. Baru-baru ini beberapa standar komunikasi organisasi dan konsorsium vendor telah mengusulkan standar untuk mengatasi kekurangan-kekurangan ini dalam pertukaran data antar sistem, intrasystem pertukaran data (pertukaran data perusahaan), dan perangkat interkonektivitas tingkat. Beberapa contoh yang lebih penting dari standar komunikasi jaringan protokol adalah ICCP (Control Protocol Center Inter), UCA (Utility Arsitektur Komunikasi), CCAPI (Control Pusat Aplikasi Interface), dan UIB (Utility Bus Integrasi). Untuk skema database, EPRI's CIM (Common Information Model) adalah mendapatkan pendukung. Dalam RTU, PLC, dan komunikasi IED, DNP 3.0 juga telah menerima tekanan industri. Mengingat jumlah standar yang telah muncul (dan kemudian menghilang) dan jumlah mungkin bersaing "standar" yang tersedia saat ini, para penulis, sementara mengakui nilai standar, lebih memilih untuk mengambil (dan merekomendasikan) pendekatan yang hati-hati untuk standar. Sebuah sikap menunggu dan melihat mungkin merupakan strategi yang efektif. Standar dengan definisi harus telah membuktikan sendiri sepanjang waktu. Kesulitan dalam segera merangkul standar baru karena sebagian pedagang telah diizinkan untuk melaksanakan hanya bagian standar, sehingga meniadakan yang mudah-mudahan "plug-and-play" aspek untuk menambah perangkat baru. Selain itu, tren dalam protokol komunikasi telah menambahkan fungsi dalam upaya untuk menjadi semua-inklusif, yang telah mengakibatkan kebutuhan meningkat pada bandwidth. Praktis berbicara, utilitas yang sudah ada infrastruktur yang mungkin akan ekonomis untuk menahan penyebaran protokol baru. Dalam analisis akhir, seperti dalam setiap keputusan bisnis, "standar" harus diterima hanya jika itu menambah nilai dan manfaat yang melebihi biaya pelaksanaan dan penyebaran. Bagian Kedua: Penerapan SCADA DMS Distribution Management Platform Distribution Management System Fungsi Manajemen Distribusi System (DMS) platform harus sepenuhnya terintegrasi dengan sistem SCADA distribusi. Antarmuka SCADA-DMS harus sepenuhnya diimplementasikan dengan kemampuan melewatkan data [indikasi diskrit (status) dan nilai (analog)] secara bidireksional. Antarmuka SCADA juga harus mendukung kontrol peralatan. Gambar 6.37 rincian komponenkomponen

dari sebuah DMS.

Trouble Management Platform Trouble Management System Sebagai tambahan untuk fungsi-fungsi dasar SCADA dan fungsi tingkat tinggi aplikasi DMS, sistem otomatisasi distribusi yang lengkap akan mencakup Trouble Management System (TMS). Sistem Manajemen Trouble mengumpulkan panggilan gangguan yang diterima oleh operator manusia dan Interactive Voice Recorders (IVR). Trouble Call dimasukkan ke suatu mesin analisa / prediksi mesin yang memiliki satu model sistem distribusi dengan pelanggan untuk membentuk hubungan alamat listrik pelanggan. Prediksi outage disajikan pada tampilan grafis penuh yang meletakkan sistem distribusi di atas CAD yang berbasiskan informasi. Sebuah TMS juga menyediakan fasilitas pengiriman dan pengelolaan kru, callback pelanggan, akuntansi, dan laporan. Sebuah antarmuka SCADA ke TMS menyediakan sarana untuk memberikan konfirmasi (SCADA telemetri) informasi outage ke mesin prediksi. Gambar 6,38 menunjukkan tipikal TMS.

Bagian Ketiga: Pengoperasian SCADA DMS Konklusi

Pembangunan SCADA/DMS perlu direncanakan secara matang dan terstuktur dengan mempertimbangkan faktor elemen-elemen dibutuhkan. Perencanaan secara komprehensive dari mulai dari awal pembangunan, pengoperasian dan maintenance serta ketersediaan dan pengembangan sumber daya manusia juga harus dipertimbangkan.