BAB II DASAR TEORI Sistem Instrumentasi Uji Terbang

Bab II Dasar Teori II-1

DASAR TEORI

Bab ini berisi mengenai tinjauan terhadap dasar teori yang berhubungan dengan permasalahan tesis. Berdasarkan permasalahan yang ada maka dasar teori ini dapat dikelompokkan menjadi beberapa sub bab, yaitu sistem instrumentasi uji terbang, klasifikasi parameter uji terbang, metodologi pengembangan perangkat lunak yang akan digunakan, dan tinjauan sistem waktu nyata.

2.1. Sistem Instrumentasi Uji Terbang

Sistem instrumentasi uji terbang merupakan sistem/peralatan yang digunakan untuk instrumentasi uji terbang. Dalam tesis ini yang dibahas adalah sistem instrumentasi uji terbang AIS. Sistem ini biasanya terdiri dari beberapa sistem yang lebih kecil lagi, yaitu: sistem akuisisi data dan sistem pemrosesan data. Hubungan antara sistem-sistem yang lebih kecil tersebut diperlihatkan pada gambar 2.1 dalam bentuk blok diagram sebagai berikut[10]: Sensor/ Tranduser Sistem Akuisisi Data Sistem Pemrosesan Data

Gambar 2.1:"Blok Digram Sistem Instrumentasi Uji Terbang"

Selanjutnya keterangan mengenai gambar 2.1 tersebut diberikan pada sub bab berikut.

2.1.1. Sensor/Tranduser

Sensor/tranduser adalah suatu alat yang mampu mendeteksi besaran fisik pesawat udara, kemudian mengubahnya menjadi nilai keluaran yang sesuai dengan peralatan akuisisi data[11].

Di dalam melakukan pengukuran terhadap parameter-parameter tertentu yang ada di pesawat udara, digunakan suatu sensor/tranduser yang dipasang pada titik-titik tertentu yang akan diukur. Keluaran dari sensor/transduser tersebut dikirim oleh suatu sistem akuisisi data.

2.1.2. Sistem Akuisisi Data

Sistem akuisisi data yang di bahas pada tesis ini adalah On Board Data Acquisition System (OBDAS), karena sistem akuisisi data ini yang sering dipakai di pasawat udara, seperti CN235 dan N250. Pada saat ini sistem akuisisi data OBDAS ada beberapa macam tipe yang ada di pasaran, seperti tipe Teledyne dan Aydin Vector dimana masing-masing tipe tersebut mempunyai karakteristik akuisisi yang berbeda dalam penyusunan format datanya.

Data dari OBDAS berbentuk Pulse Code Modulation (PCM) dengan lebar 12 bit. PCM merupakan metode pemformatan data yang umum dipakai dalam suatu uji terbang pesawat udara. Metode ini mengkonversi sinyal analog menjadi sinyal digital [12]. Data PCM ini dikirim ke sistem pemrosesan data yang mengolah data tersebut menjadi data enjiniring dan menyajikan data tersebut sesuai dengan keinginan pengguna. Sistem pemrosesan data ini sebagaimana telah dijelaskan pada bab sebelumnya ada 2 macam, yaitu sistem pemrosesan data “Ground based Data Processing”, dan sistem pemrosesan data AIS, dimana sistem yang kedua yang dibahas pada tesis ini.

2.1.3. Sistem Pemrosesan Data AIS

Sistem Pemrosesan Data AIS adalah suatu fasilitas yang dipasang pada pesawat uji untuk melakukan pengamatan dan pengolahan data uji terbang dalam waktu nyata[18]. Sistem menerima data digital dari OBDAS dan menyajikan beberapa aktivitas seperti pemrosesan data (mengubah data elektrik menjadi data enjiniring, juga melakukan perhitungan-perhitungan terhadap parameter perluasan (extended parameter)) dalam waktu nyata, penyajian data dalam bentuk tabel, grafik, maupun campuran (tabel dan grafik) ke display, dan penyimpanan data ke disk. Ditinjau dari perangkat kerasnya, Sistem Pemrosesan Data AIS yang akan dibahas ini terdiri dari ARTISt Card yang berfungsi sebagai data dekoder dan seperangkat komputer yang melakukan pemrosesan dan penyajian data. Dalam pengoperasiannya, Sistem Pemrosesan Data AIS membutuhkan suatu file yang biasa disebut file description atau file kalibrasi yang berisi informasi mengenai parameter-parameter yang akan diolah. Informasi ini antara lain berupa nama parameter, alamat parameter dalam suatu data stream, simbol parameter, satuan/unit parameter, dan data kalibrasi dari parameter.

2.2. Klasifikasi Parameter Uji Terbang

Parameter-parameter uji terbang yang diterima Sistem Pemrosesan Data

AIS dapat diklasifikasikan menjadi 3 kategori, yaitu

1. berdasarkan format data 2. berdasarkan tipe data kalibrasi.

2.2.1. Klasifikasi Berdasarkan Format Data

2.2.1.1. Parameter 12 bit

Parameter dengan format data 12 bit merupakan parameter yang diperoleh dari suatu sensor/tranduser dan diformat oleh sistem akusisi data OBDAS menjadi 12 bit data.

Terkadang dari data 12 bit ini tidak semua bit yang tercakup dipakai semua, tetapi hanya satu bit tertentu saja yang digunakan dalam pengukuran. Parameter dengan hanya satu bit data yang digunakan dari data 12 bit ini biasa disebut sebagai parameter “bit mask”.

Data parameter “bit mask” ini hanya akan menghasilkan dua nilai, yaitu 1 (high) atau 0 (low). Penafsiran terhadap kondisi tersebut ada dua, yaitu:

- non inverting logic

kondisi ini menyatakan high = true dan low = false. - inverting logic

Pada keadaan ini berarti terjadi inverting, sehingga nilai yang ditulis/terbaca merupakan kebalikan dari harga sebenarnya, yaitu high = false dan low = true. Contoh data yang merupakan parameter Bit Mask adalah landing gear, yang memiliki nilai up atau down.

2.2.1.2. Parameter 32 bit

Parameter dengan format data 32 bit ini disebut juga sebagai parameter Aeronautical Radio INCorporated (ARINC). ARINC merupakan suatu standar transfer data yang digunakan dalam komunikasi data antar peralatan avionik di pesawat udara. ARINC-429 digunakan untuk transmisi data serial. Transmisi data ARINC merupakan komunikasi dari

satu titik ke satu titik atau beberapa titik. Transmisi data ARINC memiliki 2 bentuk, yaitu:

- one way : transmisi terjadi dari satu sumber dan satu penerima yang terpisah.

- open loop : transmisi data terjadi antara pemakai yang lebih dari satu dengan satu sumber

Data ARINC terformat atas suatu word digital 32 bit. Secara umum format data ARINC terdiri atas label 8 bit, Source Destination Index (SDI) 2 bit, data field 29 bit, Sign Status Matrix (SSM) 2 bit, dan bit paritas (P) 1 bit seperti terlihat pada gambar 2.2 berikut: [19]

P SSM Data SDI LABEL

32 31 30 29 28 . . . 12 11 10 9 8 ... 3 2 1 Gambar 2.2:"Format Data ARINC-429"

Data ARINC diterjemahkan oleh data akuisisi (OBDAS) menjadi 3 word data.

2.2.2. Klasifikasi Berdasarkan Tipe Kalibrasi

2.2.2.1. Tipe Kalibrasi Linier

Parameter dengan tipe kalibrasi linier merupakan suatu parameter dengan suatu model matematika berupa garis lurus, atau dapat ditulis: y = ax + b dimana : y – data enjiniring x – data terukur a – gradient/slope b – offset

Berikut ini contoh gambar persamaan linier [17]: y = ax + b y2 = ax2 + b y1 = ax1 + b y (Engineering data) x (Electrical data) 0 x1 x2 y1 y2

Gambar 2.3:"Grafik Persamaan Linier"

Data-data yang diterima sensor/tranduser tidak selalu dapat dibuat betul-betul linier, tetapi kadang berbentuk kurva/polinomial. Untuk mempermudah pengkalibrasian data tersebut, kadang perlu dibuat model breakpoint, sehingga mudah dalam perhitungan dan deviasi data tidak terlalu besar dibanding model linier dan lebih sederhana bentuknya dibanding model polinomial. Tipe breakpoint maksudnya dengan menghubungkan titik-titik data yang didapat dari garis linier.

Data hasil kalibrasi untuk parameter bertipe linier/break-point terdiri dari jumlah titik hasil pengukuran dan pasangan nilai x dan y hasil pengukuran. Sehingga untuk menentukan nilai y (engineering data) hasil pengukuran dapat dilakukan dengan menghitung dulu slope/gradient dan offsetnya, selanjutnya tinggal dimasukkan ke rumus yang telah ditentukan.

Berikut merupakan gambar model breakpoint: y = a2x + b2 y = a1x + b1 y (Engineering data) x (Electrical data) 0 x1 x2 y1 y2

Gambar 2.4:"Grafik Persamaan Break-point"

Dari bentuk/model ini, maka perhitungan data enjiniringnya (y) didasarkan pada posisi data yang terukur (x). Jika data terukur pada posisi 0

≤

x

≤

x1, maka perhitungan y menggunakan slope a1 dan offset b1. Jika data terukur pada posisi x1

≤

x

≤

x2, maka perhitungan y menggunakan slope a2 dan offset b2, demikian juga seterusnya.

2.2.2.2. Tipe Kalibrasi Polinomial

Bentuk umum model parameter dengan tipe kalibrasi polinomial orde n adalah[17]:

Data yang dihasilkan dengan model ini akan berbentuk suatu kurva. Dari hasil kalibrasi terhadap suatu parameter polinomial, biasanya sudah ditentukan orde dan koefisien-koefisien dari parameter tersebut. Sehingga dalam perhitungannya, tinggal menerapkan rumus yang telah

0 1 2 2 1 1

x

...

c

x

c

x

c

c

x

c

y

=

_n n

+

_n− n−

+

+

+

+

ditentukan tersebut. Bentuk polinomial ini bila jumlah koefisiennya 1 pada dasarnya merupakan parameter dengan tipe kalibrasi liniear dengan nilai koefisien yang telah diketahui, bila jumlah koefisiennya 2 maka model ini disebut dengan model kuadratik.

y = c x + c x + ... + c x + c x + c (x1,y1) y (Engineering data) x (Electrical data) 0 x1 y1 n n n-1 n-1 2 2 1 0

Gambar 2.5:"Grafik Persamaan Polinomial"

Perhitungan data kalibrasi dengan model polinomial, dalam kenyataannya jarang digunakan dan lebih disukai model break-point yang bentuknya mendekati polinomial.

2.2.3. Parameter Perluasan

Parameter perluasan (extended parameter) merupakan parameter yang memerlukan pengolahan lebih lanjut dari data-data yang terukur. Parameter ini diperlukan karena tidak adanya sensor/tranduser yang dapat mengukur langsung parameter-parameter tertentu yang diperlukan dalam suatu uji terbang.

Pengolahan lebih lanjut dari data-data yang terukur ini bisa merupakan operasi penjumlahan (+), pengurangan (-), perkalian (x), dan pembagian (/) antara dua atau lebih parameter terukur. Disamping itu juga bisa terhadap operasi sinus, cosinus, tangen, dan akar ( √ ) terhadap parameter terukur. Misal terdapat parameter terukur sebagai berikut: - tekanan udara total (Pt) [N/m2]

- tekanan udara statik (Ps) [N/m2] - temperatur udara (T) [0K]

Maka dapat dihitung kecepatan terbang pesawat udara V [m/s] sebagai berikut:[23]

ρ

ρ

2

(

)

2

/

1

V

2

V

Pt

Ps

Ps

Pt

−

=

⇒

=

−

dengan ρ : kerapatan udara [kg/ m3

] yang dihitung sebagai berikut:

RT

Ps

=

ρ

dimana R adalah konstanta gas, dengan R=287,06 [m2/s2 0K] Begitu juga untuk operasi-operasi terhadap parameter yang lain.

2.3. Metodologi Pengembangan Perangkat Lunak

2.3.1. Tahapan Pengembangan Perangkat Lunak

Pengembangan perangkat lunak sebagai penyelesaian atas persoalan yang teridentifikasi dilakukan dengan mengikuti tahapan-tahapan siklus V, yang mengacu pada baseline dari Thomson-CSF, lihat gambar 2.6.

SDP Analisis Kebutuhan (SA-RT) Perancangan Awal (TOOD) Perancangan Terinci (TOOD) Implementasi (C) Pengujian Unit Pengujian Integrasi Pengujian Validasi Integration Test Unit Test Validation/ Qualification IRS SRS pSTRp STRp pSDD SDD SPS CDR TRR PDR SSR Code VDD

Gambar 2. 6:”Tahapan pengembangan perangkat lunak siklus V”

Penggunaan model siklus V yang mengacu pada baseline dari Thomson-CSF ini didasarkan pada pertimbangan-pertimbangan sebagai berikut:

1. Model siklus V merupakan penyempurnaan dari model waterfall, model prototyping, dan model spiral.

2. Dalam setiap tahapan, akan dipantau perkembangannya dengan adanya review dan akan terdokumentasi dengan baik dengan dihasilkannya dokumen pada setiap tahapan tersebut.

Masing-masing tahapan dilaksanakan dengan menggunakan metode yang sesuai untuk setiap tahapan.

(1) Tahapan Analisis Kebutuhan Perangkat Lunak

− Tahapan analisis kebutuhan perangkat lunak (software requirements analysis) ini bertujuan untuk menentukan kebutuhan dari perangkat lunak dan kebutuhan-kebutuhan antarmuka perangkat lunak dengan lingkungannya . Pada pelaksanaan analisis kebutuhan ini didasarkan pada rencana pengembangan perangkat lunak yang telah ditetapkan di dalam Software Development Plan (SDP)[1]. Demikian juga untuk pelaksanaan pada tahap berikutnya.

− Pada tahapan ini, digunakan metode SA/RT (Structured Analysis/Real Time) [15], antara lain dengan pertimbangan bahwa SA/RT merupakan metode yang terstruktur, dapat digunakan untuk memodelkan transformasi fungsional, dapat menampilkan perilaku dinamis dari perangkat lunak dan menyediakan informasi internal dan external yang ditangani perangkat lunak. Disamping itu, pengguna lebih mudah memahami pendekatan fungsional dibanding pendekatan objek. Pada tahapan ini dihasilkan dokumen Software Requirements Specification (SRS) [3] dan Interface Requirements Specification (IRS) [2] serta diakhiri oleh Software Specification Review (SSR) untuk mengevaluasi hasil dari tahapan ini

(2) Tahapan Perancangan Awal dan Perancangan Terinci

− Tahapan perancangan awal (preliminary design) ini bertujuan untuk menentukan arsitektur umum dari rancangan perangkat lunak yang akan dikembangkan (CSCI, Computer Software Configuration Item). Arsituktur umum ini tersusun dari sekelompok komponen perangkat lunak (Computer Software Component, CSC). Metode yang digunakan untuk menentukan arsitektur umum adalah TOOD (Thecnique Object Oriented Design) [16].

− Tahapan perancangan terinci (detailed design) ini bertujuan untuk menyelesaikan arsitektur umum rancangan perangkat lunak yang akan dikembangkan. Komponen perangkat lunak CSC dari arsitektur umum diturunkan menjadi unit-unit sebagai komponen perangkat lunak tingkat terendah dari perangkat lunak (Computer software unit, CSU). Metode yang digunakan untuk menentukan arsitektur umum adalah TOOD.

Dalam perancangan awal dan perancangan terinci, metode yang digunakan adalah metode TOOD dengan pertimbangan bahwa TOOD merupakan metode berorientasi objek sehingga perancangan dapat dilakukan berdasarkan modul-modul yang dibuat sedemikian rupa sehingga mempunyai karakteristik high cohesion (hubungan keterkaitan yang erat antar fungsi/prosedur dalam satu modul) dan low coupling (hubungan antar modul saling bebas), juga dengan metode ini dapat diimplementasikan menggunakan bahasa pemrograman Ada dan C yang merupakan bahasa yang banyak digunakan untuk pemrograman waktu nyata [16].

Pada akhir dari tahapan ini dihasilkan dokumen Software Design Document (SDD) [4] dan dilakukan Critical Design Review (CDR). (3) Tahapan Implementasi

− Pada tahapan implementasi ini, hasil dari perancangan awal dan terinci yang telah dilakukan, diimplementasikan dengan menggunakan bahasa pemrograman yang digunakan (coding). (4) Tahapan Pengujian Unit dan Integrasi

− Tahapan pengujian unit (unit testing) ini bertujuan untuk menguji masing-masing unit perangkat lunak yang sudah dimplementasikan. Masing-masing unit diuji secara terpisah tanpa melibatkan unit lainnya. Pengujian dilakukan dengan cara mengeksekusi fungsi-fungsi layanan external dengan menggunakan metode fungsional (black box), untuk meyakinkan bahwa implementasi dari masing-masing unit sesuai dengan perancangan sebelumnya.

− Tahapan pengujian integrasi (CSC testing) ini bertujuan untuk menguji hasil integrasi dari unit-unit yang ada dalam satu komponen. Seperti pada pengujian unit, pengujian integrasi dilakukan dengan cara mengeksekusi fungsi-fungsi layanan external dengan menggunakan metode fungsional (black box). (5) Tahapan Pengujian Validasi

− Tahapan pengujian validasi (CSCI testing) ini bertujuan untuk membuktikan bahwa perangkat lunak yang sudah diimplementasikan memenuhi kebutuhan-kebutuhan yang sudah ditetapkan pada tahapan analisis kebutuhan sebelumnya.

− Metode yang digunakan untuk melakukan pengujian validasi adalah :

(a) Demonstrasi, yaitu kebutuhan data keluaran atau hasil dari proses, dan kemampuan sistem dapat dilihat secara langsung. (b) Analisis, yaitu kebutuhan data keluaran dapat disimpan ke

dalam file sehingga dapat dilakukan analisis lebih lanjut. (c) Inspeksi, yaitu jika kebutuhan yang akan diuji tidak diminta

untuk ditampilkan, seperti data internal.

Pada akhir dari tahapan ini dihasilkan dokumen Software Test Report (STRp) [5], Software Product Specification (SPS) [6], dan Version Description Document (VDD) [7].

2.3.2. Transformasi SA/RT ke TOOD

Sebagaimana telah dijelaskan pada sub bab 2.3.1 bahwa pada tahap analisis kebutuhan digunakan metode SA/RT yang merupakan metode dengan pendekatan fungsional, sedangkan pada tahap perancangan digunakan metode TOOD yang merupakan pendekatan objek. Untuk itu diperlukan suatu cara untuk mentransformasikan dari SA/RT ke TOOD yang diperlihatkan pada tabel 2.1 sebagai berikut:

SA/RT TOOD

Terminator mesin, sub-aplikasi

Aliran data Abstract Data Type (ADT)

Data Storage objek

Nama Proses

⇒

Fungsi/Prosedur Tabel 2.1 : “Transformasi SA/RT ke TOOD”

Dari tabel 2.1 terlihat bahwa Terminator di SA/RT merupakan kandidat menjadi mesin atau sub-aplikasi di TOOD, aliran data kandidat menjadi

ADT di TOOD, data. storage kandidat menjadi objek, dan nama proses kandidat menjadi fungsi/prosedur di TOOD.

2.4. Tinjauan Sistem Waktu Nyata

Yang disebut sebagai sistem waktu nyata (real time system) adalah Sistem dimana aspek waktu ketika output dihasilkan merupakan hal yang signifikan. Hal ini karena inputnya biasanya berhubungan dengan aktifitas dari benda nyata (physical word), dan outputnya harus bersesuaian dengan aktifitas benda nyata tersebut. Sedangkan waktu jeda antara input dan output yang dihasilkan haruslah dapat diterima (acceptable) dalam skala waktu yang relatif kecil yang telah ditentukan.[20]

Selain itu terdapat definisi lain tentang sistem waktu nyata sebagai berikut:

sistem yang harus memenuhi batasan (constraint) waktu yang secara eksplisit dinyatakan, atau memenuhi konsekuensi dari resiko kegagalan. [21]

sistem yang kebenaran logikanya didasarkan pada kebenaran keluaran (output) dan pemenuhan terhadap skala waktunya. [21] Dari definisi-definisi diatas dapat disimpulkan bahwa sistem waktu nyata merupakan sistem yang mensyaratkan aspek waktu dan kebenaran logika dari sistem tersebut. Aspek waktu yang disyaratkan untuk aplikasi pesawat udara adalah dalam mili detik [20]. Sedangkan yang disebut sebagai program waktu nyata adalah program dimana kebenaran operasinya bergantung pada aspek perhitungan logika dan aspek waktu tanggap (respon time) yang dihasilkan.

Pada bab berikutnya akan dijelaskan analisis kebutuhan perangkat lunak dan analisis kebutuhan antar muka perangkat lunak yang dikembangkan. Analisis kebutuhan perangkat lunak mencakup analisis kebutuhan fungsional dan non-fungsional perangkat lunak