Dalam satu kesempatan bertemu dengan customer, salah satu permintaan yang kerap dilontarkan adalah: “ Bagaimana saya membangun sebuah system redundant untuk memperoleh kehandalan system yang tinggi?”. Sebuah pertanyaan yang gampang tapi seringkali untuk menjawabnya dibutuhkan penjelasan yang cukup panjang. Biasanya pertanyaan yang saya lontarkan balik ke sisi customer adalah ”redundancy di level mana yang ingin anda bangun?“ . Pertanyaan yang seringkali memunculkan kebingungan buat customer yang membuat saya akhirnya harus menjelaskan secara mendalam tentang system redundant di aplikasi automation.

Sebuah automation system pada saat ini, sudah tidak bisa dipisahkan lagi dengan infrastruktur Information Technology (IT). Jadi pada saat membangun system redundant, selain menyelidiki fungsi terkait dengan redundancy di automation, kita juga harus melihat juga dari sisi IT yang mendukung system redundant yang diinginkan. Tulisan ini membahas berbagai macam level redundancy yang umum dipakai di aplikasi industri yang menggunakan industrial automation software and hardware sebagai tulang punggungnya

Kenapa membangun sebuah system yang redundant?

Ada beberapa alasan kenapa sebuah system dibangun dengan menggunakan konfigurasi secara redundant. Alasan terbesar adalah untuk meningkatkan reliability sebuah system. Bayangkan sebuah proses di perusahaan pembuat ban yang tiba-tiba pada saat bahan baku akan dicetak ternyata system mati. Cairan akan membeku dan jutaan rupiah harus terbuang karena kegagalan system.

Redundant Power Supply

Seringkali karena berpikir ini adalah domain electrical, banyak orang automation yang seringkali lupa untuk memasukkan komponen power supply sebagai ‘makanan’ dari sebuah system untuk bisa tetap hidup. Dalam banyak aplikasi, power supply bisa juga dilewatkan sebuah UPS untuk menjaga kontinuitasnya, karena kebutuhan daya di system automation yang tidak terlalu besar.

Untuk redundant power supply dibedakan menjadi dua, yang pertama adalah power supply dalam 1 rack tetapi dari sumber listrik yang sama. Metode ini hanya bisa mengatasi kejadian modul power supply rusak. Jika sumber listrik mati, maka system juga akan mati. Yang kedua adalah sama dengan diatas, tetapi masing-masing power supply berasal dari sumber listrik yang berbeda. Jika salah satu sumber listrik mati, system masih bisa berjalan normal dengan menggunakan sumber listrik cadangan.

Redundant network.

Pada pembahasan ini, kita akan mengambil contoh di network yang berbasis Ethernet, karena tingkat popularitasnya yang semakin tinggi di industri otomasi. Untuk aplikasi yang sederhana, pemakaian topologi ring sudah lebih dari cukup untuk mencover kegagalan disebabkan oleh rusaknya media. Untuk tingkat keandalan yang lebih tinggi, pemakaian topologi ring bisa dinaikkan dengan memakai media yang juga redundant, seringkali dinamakan sebagai topologi double ring.

Keuntungan lain dengan memakai topologi ring adalah penghematan di sisi instalasi kabel ( biasanya untuk jarak yang jauh memakai kabel serat optic yang cukup mahal ).

Untuk keandalan yang lebih tinggi lagi, bisa digunakan topologi yang mengadopsi topologi mesh, dimana semua node (komputer atau controller) terhubung ke semua node dalam jaringan.

Redundant Controller

Redundancy di level controller (biasanya PLC atau DCS) bertujuan untuk menjaga keandalan system di level controller. Tidak seperti kegagalan di level network yang hanya mengakibatkan kemampuan monitoring dan controlling via PC akan hilang, kegagalan pada system controller akan berdampak secara langsung pada proses yang berakibat system harus mati. Konfigurasi pada level controller kadang-kadang juga diikuti oleh redundancy di level I/O.

Redundant Server

Sebagai bagian dari teknologi IT, server memegang peranan yang cukup vital dalan sebuah proses automation. Sifat terpenting yang harus diperhatikan pada server redundancy adalah kemampuan untuk melakukan sinkronisasi. Tanpa kemampuan snkronisasi, redundancy di sisi server hanya sebuah proses paralel yang membebani controller.

Proses paralel dan redundant dapat dibedakan sebagai berikut: pada proses parallel, semua server akan mengambil data dari controller, sehingga kemungkin yang terjadi adalah loading di sisi controller yang cukup besar karena harus melayani data yang sama ke sejumlah server (tergantung dari jumah redundant server yang dipasang). Untuk Redundant server, hanya ada satu server yang aktif (jadi data yang diambil dari controller Cuma untuk melayani satu server). Standby server akan berkerja hanya jika primary server gagal menjalankan fungsinya. Proses sinkronisasi akan terus dilakukan sehinga primary dan standby akan selalu memperoleh data yang paling update.

Beberapa vendor di automation bahkan seudah mendukung untuk redundancy server di level aplikasi. Kita bisa memisahkan fungsi server ke dalam beberapa task, misalnya untuk alarm, trend, data real. Aplikasi ini kita bisa pisahkan dalam beberapa server untuk mengurang beban dari server.

Untuk pembahasan lebih mendetail di redundancy system pada software aplikasi, khususnya SCADA software, silahkan membaca artikel berikut: Typical system di SCADA application.

Redundant Client

Redundant client adalh hal yang paling mudah untuk diaplikasikan. Fungsi dari client hanya mendeteksi pada server mana client harus mengambil data. Jika primary server gagal, client akan berpindah secara otomatis ke standby server.

Total Redundancy System

Total redundancy systemdibangun dengan mengambil semua persyaratan diatas. Jadi, silahkan di bangun puzzle diatas menjadi sebuah system yang utuh. Selamat mencoba!!!

Jadi system redundant seperti apa yang anda ingin bangun?? Tentunya secara ideal anda ingin membangun system yang total redundancy, tapi tentunya faktor biaya juga akan sangat menjadi pertimbangan. Jadi sampai sejauh mana optimasi yang anda lakukan antara kebutuhan untuk memperoleh keandalan yang tinngi dengan biaya yang anda punya, akan menjadi penentu sampai sejauh mana system redundant yang bisa anda bangun…..

Programmable Logic Controller (PLC) for Dummies

Adalah sebuah hal yang sulit untuk menjelaskan satu hal yang kita sangat pahami tetapi orang lain sama sekali tidak mempunyai gambaran apapun tentang hal tersebut. Salah satu cara terbaik yang saya yakini adalah dengan menggunakan analogi. Hal ini saya alami pada saat saya pindah ke sebuah perusahaan yang sebagian besar karyawannya ber-‘background’ electrical yang selalu menganggap bahwa PLC adalah barang yang sulit untuk dipahami, sehingga menimbulkan semacam alergi bahkan untuk mendengarkan penjelasan dari ‘orang PLC’.

Artikel ini akan membahas sedikit tentang konsep PLC dengan menganalogikannya dengan system biologi tubuh manusia, yang ternyata cukup manjur untuk membantu memberikan pemahaman pada orang yang sangat awam terhadap PLC.

PLC, sesuai dengan namanya adalah controller yang dapat diprogram dengan menggunakan logika. Secara umum, PLC system terdiri dari beberapa bagian yaitu I/O, Central Processing Unit (CPU).

Mari kita mulai membayangkan bahwa PLC system adalah seorang manusia yang komplet dengan panca indera yang dimilikinya sedang menjalankan suatu pekerjaan. Kita mulai dengan sebuah contoh system kecil yaitu pengisian air dalam sebuah tangki. Secara system manusia, langkah pertama yang kita lakukan adalah dengan melihat bahwat tangki tersebut sedang kosong dan kita harus mengisinya dengan cara membuka kran yang ada di dekat tangki tersebut. Sementara menunggu tangki penuh, kita mengamati ketinggian air yang ada di dalam tangki. Pada saat air sudah mencapai titik tertinggi sebelum tumpah, hal yang harus kita lakukan adalah menutup kran sehingga air tidak tumpah. Dalam aplikasi dilapangan dengan memakai PLC, kita bisa melakukan pemrograman di PLC sehingga kran akan otomatis dibuka pada saat ketinggian air mencapai titik minimum dan mematikannya pada ketinggian maksimum. Sebuah proses yang cukup mirip, satu oleh manusia, satu oleh mesin yang dikendalikan oleh PLC.

Input, bisa diumpamakan sebagai panca indera manusia. Dengan input, PLC menangkap sinyal dari luar yang digunakan dalam proses perhitungan. Dalam contoh diatas, input berupa kondisi ketinggian air sebagai dasar pengambilan keputusan di logika yang akan dilakukan oleh output. 

Output adalah tindakan yang dilakukan sesuai dengan program yang dikehendaki. Dalam contoh diatas output melakukan perintah untuk menutup kran air JIKA kondisi ketinggian mencapai level yang diinginkan.

CPU, Central Processing Unit, ini adalah ‘otak’ dari PLC system. Semua perhitungan maupun dasar pengambilan keputusan dilakukan di CPU. Setelah mendeteksi bahwa ketinggian air cukup rendah, CPU akan memproses untuk melakukan tindakan membuka kran air. Setelah air mencapai ketinggian yang diinginkan, input akan mengirim sinyal ke CPU dan CPU akan memproses sinyal untuk menghasilkan output yaitu menutup kran air.

Dari gambaran diatas, kita bisa mendesain PLC untuk keperluan yang lebih besar dengan program yang jauh lebih kompleks. Dalam contoh sehari-hari di industri, kita bisa melihat aplikasi PLC misalnya untuk mengatur sebuah proses di pabrik kimia yang melibatkan ratusan bahkan ribuan kemungkinan untuk memilih output sesuai dengan proses yang dikehendaki.

So simple…..

Bintaro

Tonny Leonard

Bagi orang dengan background Information Technology atau Industrial Automation, mungkin istilah protocol begitu popular, sehingga tidak memerlukan penjelasan lagi jika terjadi diskusi yang hangat untuk membahas masalah komunikasi antar aplikasi, baik di dunia IT maupun di dunia otomasi industri. Tapi bagi orang awam, tentu sangat susah untuk menjelaskan apa itu protocol.

Ada begitu banyak protocol yang ada di pasar saat ini untuk aplikasi otomasi industri. Mulai dari yang serial semacam modbus, DH+, sampai yang berbasis TCP seperti Ethernet IP, ProfiNet maupun Modbus TCP.

Protokol seringkali dipakai dalam aplikasi otomasi industri untuk mengintegrasikan berbagai macam PLC atau DCS untuk bisa saling berkomunikasi. Secara gampang (ini artikel for dummies…), protocol bisa disamakan dengan bahasa dalam komunikasi sehari-hari. Kita bisa bayangkan kalau ada orang dari Jawa dan Sumatra sedang dalam perundingan dan masing-masing hanya menguasai bahasa mereka sendiri. Yang terjadi adalah saling ketidak pahaman yang ujung-ujungnya membuat mereka frustasi. Untuk menjembatani hal tersebut, ada 2 hal yang bisa dilakukan.

Yang pertama adalah membawa penerjemah, sehingga masing-masing pihak bisa memahami lawan bicaranya setelah ‘dilewatkan’ penerjemah. Jadi ada konversi bahasa dari bahasa Jawa ke Sumatra dan sebaliknya.

Cara yang kedua adalah dengan menggunakan bahasa Indonesia, sebagai bahasa yang dipahami oleh keduanya, sehingga tidak perlu ada penerjemah karena masing-masing memakai bahasa yang sama.

Sekarang bayangkan kalau yang berdiskusi adalah dewan PBB yang dihadiri oleh lebih dari 100 negara. Berapa banyak penerjemah yang harus dibawah karena masing-masing pembicara harus memahami lebih dari 100 bahasa untuk bisa memahami keinginan tiap peserta. Jadi bagaimana solusinya? Untungnya PBB punya ‘common language’  lebih universal yaitu bahasa Inggris yang dianggap bisa dipahami oleh ‘sebagian besar’ peserta (saya belum berani bilang semua).

Kita kembali ke otomasi industri. Kenyataan yang ada di lapangan adalah bahwa masing-masing vendor PLC atau DCS memiliki bahasa yang berbeda berdasarkan design yang mereka bikin sendiri, sehingga proses integrasi melibatkan proses yang lebih rumit.

Dalam bahasa otomasi industri, proses penerjemahan bisa diibaratkan sebagai proses pengubahan dari satu protocol ke protocol yang lain. Sebagai contoh, PLC berbasis Allen Bradley memakai protocol Device Net akan diintegrasikan dengan PLC Modicon yang memakai protocol Modbus. Dibutuhkan protocol converter untuk menerjemahkan dari Device net ke Modbus dan sebaliknya.

Sekarang bayangkan kalau PLC dan DCS yang akan diintegrasikan lebih banyak lagi, kira-kira mirip ilustrasi di PBB diatasJ. Harus ada ‘common protocol’yang bisa berfungsi sebagaimana bahasa Inggris dalam kasus diatas. Dari hasil kesepakatan banyak PLC dan DCS vendor, akhirnya salah satu kesepakatan adalah mengembangkan protocol yang lebih universal yaitu OPC. OLE for Process Control di desain dengan spesifikasi yang disepakati oleh sebagian besar vendor (saya tidak berani bilang semua..). Dengan OPC, proses integrasi diantara berbegai protocol menjadi sederhana sebagaimana bahasa Inggris diaplikasikan di sidang PBB diatas. Apa dan bagaimana OPC, akan disambung di artikel mendatang.

Bintaro

Tonny Leonard

OPC sebagai standard komunikasi banyak dipakai oleh vendor automation (dengan kesadaran maupun keterpaksaan menurut penulis). Dengan semakin banyaknya produk yang menyatakan OPC comply, akan semakin mudah sebenarnya untuk kita dalam usaha mempermurah software HMI/SCADA. Dengan harga ratusan dollar, kita sudah bisa memperoleh software HMI/SCADA yang bisa diandalkan. Software HMI/SCADA, pada dasarnya adalah sebuah aplikasi OPC client. OPC client mengambil data dari OPC server. Sayangnya pemain dominan di industri otomasi masih memasang harga yang mahal untuk OPC server yang mereka bikin sebagai usaha untuk tetap membuat produknya eksklusif. Tapi dengan semakin terbukanya standard, kita akan dengan mudah memperoleh OPC server untuk produk-produk yang dominan. Jadi tidak ada lagi masalah untuk mengakses data dari produk tersebut. Yang anda lakukan cukup ketik keyword di google, anda akan menemukan OPC server bahkan beberapa software bisa diperoleh dengan gratis.

Connectivity will be challenge issues, since this discipline diminish the border of industrial automation, information technology and managerial performance domain and merge them become integrated solution.

Here we will discuss many issues from automation integration, Manufacturing Execution System, Enterprise Reources Planning, Performance Improvement base or the combination all of them as a new tool for competing in the manufacturing business.