KONSEP TAHAPAN PENGEMBANGAN APLIKASI SISTEM PAKAR DI PABRIK UREA

Transkripsi

1 BAB VIII KONSEP TAHAPAN PENGEMBANGAN APLIKASI SISTEM PAKAR DI PABRIK UREA VIII.1 Pendahuluan Pada bab sebelumnya telah dibuat dan diuraikan pembahasan sebuah model sistem pakar panduan troubleshooting proses di reaktor urea Kaltim-1 sebagai sebuah contoh sistem berbasis pengetahuan yang mungkin diimplementasikan di pabrik. Model tersebut masih sangat sederhana dan untuk bisa benar-benar diaplikasikan dan bermanfaat di lapangan masih memerlukan banyak pengembangan. Pada bab ini akan diuraikan konsep tahapan dalam pengembangan sebuah sistem berbasis pengetahuan yang ditujukan menjadi sebuah sistem pakar yang akan diaplikasikan khususnya di lingkungan pabrik, meskipun dengan penyesuaian dapat pula diadopsi untuk aplikasi di lingkungan non pabrik. Potensi area aplikasi sistem pakar di pabrik urea sangat luas dan beberapa telah dibahas sebelumnya yaitu troubleshooting dan diagnosis masalah proses serta monitoring dan pengendalian proses. Selain itu aplikasi lain yang mungkin adalah pelatihan operator pabrik, studi HAZOP (hazard and operability), atau aplikasi untuk sistem reliabilitas & pemeliharaan peralatan pabrik. Tahapan pengembangan sebuah sistem pakar secara garis besar dapat dikelompokkan dalam empat tahapan utama yaitu perencanaan, akuisisi pengetahuan, perancangan sistem, dan evaluasi seperti ditunjukkan pada Gambar VIII.1. VIII.2 Perencanaan Tahap perencanaan dalam pengembangan sistem pakar mencakup tujuan yang akan dicapai dan spesifikasi yang disyaratkan. Pada tahap ini harus ditentukan 84

2 Usulan aplikasi area pengguna PERENCANAAN heuristis model proses validasi model proses vs heuristis software representasi integrasi AKUISISI PENGETAHUAN PERANCANGAN SISTEM EVALUASI validasi verifikasi OK revisi Implementasi Gambar VIII.1 Blok diagram tahap-tahap pengembangan sistem berbasis pengetahuan dengan jelas definisi dan spesifikasi sistem pakar yang akan dibuat, anggaran, jadwal pelaksanaan, serta sumber daya yang dibutuhkan. Aplikasi sistem pakar yang dipilih bisa salah satu atau kombinasi aplikasi seperti telah disebutkan di atas misalnya troubleshooting dan diagnosis proses, pengendalian proses atau pelatihan operator. Batasan area unit proses harus 85

3 ditentukan dengan jelas, misalnya untuk keseluruhan proses pabrik urea atau hanya untuk unit proses tertentu seperti : unit sintesis, resirkulasi, evaporasi, produk akhir atau pengolahan limbah. Untuk awal akan lebih mudah jika sistem pakar dibuat dalam modul-modul untuk unit proses yang lebih kecil atau masalahmasalah yang spesifik, yang nantinya dapat dikembangkan lebih lanjut menjadi sistem pakar yang lengkap untuk proses di satu pabrik urea. Selanjutnya sasaran pengguna sistem pakar tersebut harus jelas, misalnya operator lapangan, operator ruang kendali atau senior operator. Sebagai contoh, didefinisikan bahwa yang akan dibuat adalah : sistem pakar diagnosis masalah proses di pabrik Urea secara offline untuk operator ruang kendali. Ada dua peran penting yang terlibat dalam pengembangan sebuah sistem pakar. Yang pertama adalah ahli proses/operasi sebagai sumber pengetahuan dan yang kedua adalah knowledge engineer dari pihak pengembang sistem pakar yang akan mengambil pengetahuan dari seorang ahli dan menjadikannya sebagai basis pengetahuan di dalam sistem pakar. Ahli proses/operasi adalah orang yang memiliki pengetahuan atau keahlian dalam bidang proses dan pengoperasian pabrik urea, sehingga mampu menyelesaikan atau memberikan rekomendasi jika terjadi masalah proses di pabrik urea. Yang mungkin dianggap sebagai ahli proses/operasi antara lain adalah kepala regu, mandor, penyelia, kepala bagian hingga manajer pabrik dari Departemen Operasi dan insinyur proses senior dari Biro Teknologi. Sebagai pendukung, insinyur ahli dari Bagian Pemeliharaan atau Inspeksi Teknik yang terkait mungkin pula dibutuhkan. Knowledge engineer adalah orang yang menguasai teknik-teknik akuisisi dan representasi pengetahuan, serta memahami pemrograman dengan perangkat lunak untuk pengembangan sistem pakar. Dalam hal ini bisa melibatkan staf dari Biro Sistem Informasi jika memiliki kualifikasi yang sesuai atau dari pihak ketiga. Dengan definisi yang jelas mengenai sistem pakar yang diusulkan, maka berikutnya dapat ditentukan perangkat keras dan perangkat lunak yang tepat, yang akan digunakan untuk menjalankan sistem pakar. Dari sisi perangkat keras, 86

4 dengan perkembangan teknologi komputer yang sangat pesat, spesifikasi komputer saat ini (Personal Computer) pada umumnya sudah mencukupi untuk menjalankan sistem pakar dengan aplikasi seperti diagnostik masalah proses secara offline. Kemudian dari sisi perangkat lunak, tersedia banyak pilihan perangkat lunak untuk pengembangan sistem pakar mulai dari yang bersifat bebas dan terbuka hingga yang komersial. Perangkat lunak tersebut bisa berupa bahasa pemrograman seperti PROLOG (programming in logic) dan LISP (list processing), atau yang sudah berupa expert system shell seperti CLIPS dan G2 dari Gensym ( yang bersifat komersial. VIII.3 Akuisisi Pengetahuan Akuisisi pengetahuan merupakan tahapan kunci dan yang paling sulit dari keseluruhan proyek. Pada tahapan ini dibutuhkan kemampuan knowledge engineer untuk menangkap/mendapatkan pengetahuan dari ahli yang kemungkinan sulit untuk mengungkapkan secara jelas tentang pengetahuan/keahlian yang dimilikinya. Pengetahuan baik yang berupa pengetahuan heuristis maupun pengetahuan proses dalam bentuk model proses, keseluruhannya merupakan sumber-sumber yang akan membentuk basis pengetahuan yang lengkap. Pada Gambar VIII.2 ditunjukkan mengenai peran pengetahuan heuristis (shallow knowledge) dan pengetahuan proses (deep knowledge) sebagai sumber untuk akuisisi pengetahuan dalam menyelesaikan masalah proses. Basis data masalah berisikan kumpulan data masalah proses yang ada di pabrik. Analisis untuk penyelesaian masalah dalam basis data tersebut dilakukan dengan berdasarkan pada pengetahuan heuristis dan pengetahuan proses yang telah dikuasai, yang telah terbukti valid dan tidak ada ketidaksesuaian dari kedua sumber pengetahuan tersebut. Dalam hal ada ketidaksesuaian antara pengetahuan heuristis dan pengetahuan proses, harus dilakukan evaluasi untuk merevisi pengetahuan heuristis atau model pengetahuan proses yang dibuat. Informasi pengetahuan yang valid menjadi sumber pengetahuan dalam menyelesaikan masalah proses. 87

5 Dalam menghadapi sebuah masalah proses, diperiksa terlebih dahulu apakah masalah tersebut sudah ada di dalam basis data masalah atau merupakan masalah proses yang baru. Untuk masalah yang telah ada di dalam basis data, maka penyelesaiannya tentu mengikuti analisis berdasarkan sumber pengetahuan yang telah tersedia. Jika masalah proses tersebut adalah baru, maka harus dilakukan analisis baru dengan pengetahuan proses yang sesuai yang dapat menjelaskan masalah yang terjadi, sehingga penyebab dan cara penyelesaian masalah dapat diputuskan. Pengetahuan Heuristis (shallow knowledge) : - trouleshooting proses - perbaikan alat - rule of thumbs - best practices Basis data Masalah Evaluasi tidak valid? ya Pengetahuan Proses (deep knowledge) : - Simulasi proses - Model dinamika fluida - Interaksi fluida struktur - Data bahan konstruksi - Instrumentasi / kelistrikan Sumber Pengetahuan Akuisisi Pengetahuan Masalah Proses baru? Gambar VIII.2 Akuisisi pengetahuan untuk penyelesaian masalah proses 88

6 Sumber pengetahuan di pabrik dapat pula diperoleh dari sumber pendukung berupa dokumentasi yang telah ada atau sistem yang telah dijalankan. Beberapa dokumen proses pabrik yang tersedia adalah diagram alir proses, diagram perpipaan dan instrumentasi, serta manual operasi. Di samping itu sudah ada beberapa sistem atau kegiatan telah dijalankan yang terkait sangat erat dengan pengelolaan pengetahuan khususnya pengetahuan proses di pabrik. Beberapa aktivitas tersebut adalah pendokumentasian kejadian-kejadian penting saat pengoperasian pabrik dalam bentuk memo to file, penerapan standar sistem manajemen mutu dan lingkungan, serta yang belum lama ini mulai diadopsi yaitu penerapan standar praktek terbaik dalam bidang manufaktur yang disebut Manufacturing Excellence (Manufex). Memo to file (MTF) merupakan dokumentasi kejadian penting dalam pengoperasian proses produksi sehari-hari yang diterbitkan oleh bagian operasi, yang biasanya berkaitan dengan kondisi operasi yang tidak normal seperti shutdown mendadak, kerusakan peralatan utama proses, gangguan pada kualitas produk, pencemaran lingkungan karena gangguan proses atau kejadian yang mengakibatkan kecelakaan kerja. Isi dari MTF mencakup kronologi kejadian, masalah yang terjadi serta analisis masalah dan tindakan yang dilakukan saat kejadian serta usulan perbaikan untuk mencegah terulangnya masalah. Penerapan sistem manajemen mutu (ISO-9001:2000) dan sistem manajemen lingkungan (ISO-14001) menghasilkan prosedur-prosedur dan instruksi kerja tertulis yang menjadi acuan baku bagi perusahaan sesuai pasal-pasal yang disyaratkan dalam standar tersebut. Termasuk di dalamnya adalah prosedur, instruksi kerja serta baku mutu terkait pengoperasian pabrik. Beberapa di antaranya merupakan sumber pengetahuan yang mungkin mendukung sistem pakar yang akan dibuat. Dari pelaksanaan implementasi sistem Manufex di pabrik terbentuk basis data masalah-masalah yang mengakibatkan tidak tercapainya sasaran kinerja pabrik. 89

7 Sebuah metodologi yang digunakan dalam menyelesaikan masalah-masalah tersebut adalah dengan cara melakukan tindakan perbaikan berdasarkan pada hasil identifikasi, analisis dan temuan akar penyebab dari masalah tersebut (root cause analysis/rca). Struktur analisis masalah dengan RCA sangat sesuai dengan struktur diagnosis masalah proses pada pembuatan sistem pakar, sehingga pengetahuan dan pengalaman dari basis data manufex tersebut merupakan sumber pengetahuan penyelesaian masalah proses yang sangat penting. Akuisisi pengetahuan dapat dilakukan melalui dua cara yaitu manual dan otomatis. Metode manual menggunakan cara-cara seperti wawancara dan pengamatan untuk mendapatkan pengetahuan yang dikuasai ahli dalam menyelesaikan kasus. Sementara metode otomatis adalah dengan memanfaatkan alat bantu yang memfasilitasi akuisisi pengetahuan, misalnya dengan perangkat lunak bantu yang telah dirancang untuk kegiatan akuisisi pengetahuan. Pemrograman dengan perangkat lunak untuk sistem pakar seperti CLIPS juga dapat digunakan untuk akuisisi pengetahuan secara otomatis [Chen, 1999]. Produk dari tahapan akuisisi pengetahuan ini adalah basis pengetahuan kemudian harus direpresentasikan oleh knowledge engineer ke dalam format yang sesuai untuk dimasukkan ke dalam perangkat lunak pengembangan sistem pakar. VIII.4 Perancangan Sistem Setelah dilakukan akuisisi pengetahuan, tahapan selanjutnya adalah merancang dan memformulasikan sistem yang akan dibuat dan menuliskannya dalam kode program yang sesuai. Pekerjaan pada tahap ini berhubungan dengan format representasi pengetahuan sesuai jenis aplikasi sistem pakar dan perangkat lunak pembuatan sistem pakar yang telah dipilih. Sebagaimana telah diketahui ada beberapa metode representasi pengetahuan yaitu berbasis aturan, berbasis frame, berbasis obyek, serta berbasis model kasus. Metode yang banyak digunakan adalah representasi pengetahuan dengan basis 90

8 aturan yang disebut juga sistem produksi, seperti yang dipakai oleh perangkat lunak pengembangan sistem pakar G2 dan CLIPS yang diaplikasikan untuk membuat model panduan troubleshooting proses reaktor urea pada bab V. Untuk sistem pakar yang dibuat dengan basis aturan, maka basis pengetahuan dituliskan dalam bentuk aturan-aturan. Pembahasan penulisan aturan sebagai bentuk representasi pengetahuan dengan CLIPS telah diuraikan di bab sebelumnya. Pada aplikasi sistem pakar di pabrik diharapkan agar dibuat rancangan antarmuka grafis yang akan memudahkan pengguna berinteraksi dengan sistem pakar. Selain itu perlu dipertimbangkan apakah sistem pakar hanya akan berdiri sendiri (offline) atau ada kemungkinan keterkaitan antara perangkat lunak sistem pakar (yang terdiri dari basis pengetahuan dan mesin pengambilan kesimpulan) dengan basis data operasi pabrik, sistem pengendalian proses serta model simulasi proses yang tersedia, sehingga perlu diperhatikan kompatibilitas antar perangkat lunak. Hal ini terkait dengan kemampuan perangkat lunak sistem pakar yang dipilih. Sebagai gambaran aplikasi sistem pakar untuk deteksi dan diagnosis kesalahan yang dibuat dengan G2 dapat berinteraksi dengan program simulasi proses dan sistem kendali di unit granulasi (Corrie, 2001). VIII.5 Evaluasi Evaluasi dilakukan setelah pemrograman sistem pakar selesai untuk memastikan bahwa sistem pakar telah memenuhi spesifikasi yang disyaratkan seperti yang telah didefinisikan saat awal proyek pengembangan sistem pakar. Dua cara yang umum dilakukan untuk mengevaluasi sistem pakar adalah verifikasi dan validasi. Dengan verifikasi dan validasi akan diperoleh kepastian kualitas sistem pakar yang dikembangkan. Verifikasi adalah langkah untuk memeriksa dan memastikan bahwa basis pengetahuan dan mesin pengambilan kesimpulan pada sistem pakar telah memenuhi spesifikasi yang disyaratkan dan bebas dari kesalahan. Pada sistem 91

9 pakar yang dikembangkan dengan expert system shell, verifikasi dapat difokuskan pada isi basis-pengetahuan yang dihasilkan dari akuisisi pengetahuan dan dimasukkan dalam sistem pakar. Verifikasi dilakukan dengan cara memeriksa kemungkinan kesalahan-kesalahan pada pembuatan atau penulisan rules yang membentuk basis pengetahuan. Langkah validasi dilakukan untuk memastikan bahwa hasil akhir sistem yang dibuat adalah benar dan memenuhi kebutuhan pengguna. Teknik validasi yang paling umum dilakukan adalah pengujian, dengan cara membandingkan hasil yang diperoleh dari sistem pakar dengan penyelesaian jika dilakukan oleh seorang ahli terhadap kasus yang tercakup dalam sistem pakar. Sebagai tolok ukur adalah tingkat akurasi yang menunjukkan prosentasi hasil yang sesuai dari sistem pakar dan tingkat kecukupan dari sistem pakar dalam memberikan alternatif penyelesaian terhadap sebuah kasus. Selain itu hasil dari sistem pakar juga dapat dibandingkan dengan hasil standar yang sudah diketahui atau dari model teoritis. Pada masalah proses kimia di pabrik, simulasi proses yang telah dibuat sebelumnya dan terbukti validitasnya juga dapat digunakan untuk validasi sistem pakar. Berdasarkan hasil evaluasi dari langkah-langkah di atas dapat dilakukan perbaikan-perbaikan pada sistem pakar yang telah dibuat hingga sistem pakar dapat diterima dan siap untuk diimplementasikan dan dipakai oleh pengguna akhir sesuai dengan tujuan semula. Selama diimplementasikan, sangat mungkin perbaikan dan pengembangan dilakukan berkelanjutan sesuai dengan perkembangan pengetahuan terkait basis pengetahuan atau perluasan aplikasi sistem pakar tersebut. 92