-
i
IMPLEMENTASI FULL DUPLEX SWITCHED
ETHERNET PADA AIRCRAFT DATA NETWORK
BERBASIS COTS EMBEDDED DEVICE
Buku Tugas Akhir
Kelompok Keahlian: Telematika
Faisal Defry Hussainy
1103110214
Program Studi Teknik Informatika
Fakultas Informatika
Telkom University
Bandung
2015
-
ii
Lembar Persetujuan
Implementasi Full Duplex Switched Ethernet Pada Aircraft Data
Netwok
Berbasis Cots Embedded Device
Implementation of Full Duplex Switched Ethernet on Aircraft Data
Netword
Based on COTS Embedded Device
Faisal Defry Hussainy
1103110214
Tugas Akhir ini telah diterima dan disahkan untuk memenuhi
sebagian dari syarat
untuk memperoleh gelar Sarjana Teknik
Fakultas Informatika
Universitas Telkom
Bandung, 1 Juli 2015
Menyetujui
Pembimbing 1
Endro Ariyanto,ST.MT
NIP: 04660316-1
Pembimbing 2
Catur Wirawan Wijiutomo,ST,MT
NIP:
-
iii
Lembar Pernyataan
Dengan ini saya menyatakan bahwa Tugas Akhir dengan judul
Implementasi
Full Duplex Switched Ethernet Pada Aircraft Data Netwok Berbasis
Cots
Embedded Device beserta seluruh isinya adalah benar-benar karya
saya sendiri dan saya tidak melakukan penjiplakan atau pengutipan
dengan cara-cara yang tidak sesuai
dengan etika keilmuan yang berlaku dalam masyarakat keilmuan.
Atas pernyataan ini,
saya siap menanggung resiko atau sanksi yang dijatuhkan kepada
saya apabila
kemudian ditemukan adanya pelanggaran terhadap etika keilmuan
dalam karya saya
ini, atau ada claim dari pihak lain terhadap keaslian karya saya
ini.
Bandung, Juli 2015
Yang membuat pernyataan,
Faisal Defry Hussainy
-
iv
Abstrak
Aircraft Data Network (ADN) adalah sebuah konsep komunikasi data
yang
dikembangkan khusus untuk diimplementasikan di environment
pesawat terbang.
Karena ADN berada pada aircraft environment, maka otomatis
diperlukan sebuah
sistem yang dapat bekerja secara real time serta memiliki
tingkat kehandalan yang
tinggi. Avionics Full-Duplex Switched Ethernet (AFDX) adalah
sebuah standar
komunikasi data untuk ADN yang diimplementasikan berdasarkan
spesifikasi ARINC
664. AFDX dibangun berdasarkan teknologi IEEE 802.3 (Ethernet)
menggunakan
komponen Commercial-Off-The-Shelf (COTS). Masalah yang biasa
dihadapi dalam
pengembangan teknologi penerbangan adalah lamanya waktu
pengembangan serta
besarnya biaya yang dibutuhkan untuk riset dan pembuatan
alat-alat industri baru
untuk memproduksi teknologi yang dibuat secara khusus untuk
suatu vendor tertentu,
namun dengan penggunaan teknologi Ethernet yang memiliki standar
global, hal-hal
tersebut tentu akan dapat ditekan. Hal terpenting dalam
pengembangan AFDX adalah
harus dilakukan perancangan dan implementasi sistem yang
bersifat deterministik,
yaitu sistem yang dapat menangani fungsi traffic policing dan
frame filtering dengan
performansi yang memenuhi standar spesifikasi. Selain itu,
karena cost-effective
merupakan salah satu tujuan AFDX, penggunaan komponen COTS untuk
menekan
biaya juga harus menjadi pertimbangan.
Pada tugas akhir ini, telah dilakukan implementasi Aircraft Data
Network
yang ditujukan untuk memenuhi standar ARINC 664/AFDX
menggunakan
komponen-komponen COTS. Telah dilakukan perancangan embedded
device
berbasis PC / 1386 Processor dengan menggunakan Linux sebagai
sistem operasinya.
Sistem yang dibangun sudah dapat menerima dan meneruskan paket
sesuai dengan
rule traffic policing dan frame filtering yang didefinisikan.
Selain itu, uji performansi
juga telah dilakukan dan didapatkan nilai latency yang memenuhi
standar spesifikasi
ARINC 664 yaitu lebih kecil dari 150 miliseconds, namun nilai
jitter yang didapat
masih belum bisa memenuhi standar yaitu lebih kecil dari 500
microseconds. sehingga
sistem yang dibangun belum dapat dikatakan deterministik
sepenuhnya.
Kata kunci: Aircraft Data Network (ADN), Avionics Full-Duplex
Switched Ethernet
(AFDX), commercial-cff-the-shelf (COTS), ARINC 664
-
v
Abstract
Aircraft Data Network (ADN) is a data communication concept
developed
specifically for implementation in the aircraft environment. ADN
introduced by the
Airlines Electronic Engineering Commite (AEEC) on the
specification ARINC 664.
Because of AND using in the aircraft environment, it
automatically need a system that
can works in real time and has a high level of reliability. The
system can be in real
time if the conditions of operation is limited by the span and
have a clear limit-time
(deadline). In other words, a work must be completed within a
certain time.
Avionics Full-Duplex Switched Ethernet (AFDX) is a data
communications
standar for the AND that implemented by ARINC 664
specification.The reason of
made AFDX is special because it built on technology based IEEE
802.3 (Ethernet)
using components of Commercial-Off-The-Shelf (COTS). This
condition will certainly
save time and development costs, because Ethernet itself is a
powerful technology that
is constantly evolving and has a high degree of reliability.
In this final project, there will be the implementation of a
real time system
based Aircraft Data Network which can fullfil the standar ARINC
664 / AFDX. The
system built using COTS components. This final project will
handle the design and
implementation specialy based of embedded linux that can handle
switching functions
required by the system. Problems that can be faced here is to
design a frame function
filtering and traffic policing perfectly to be able ensure that
all communication
between End System which has a deterministic nature so that it
can reliably apply to
the Aircraft Data Network.
Key Words: Aircraft Data Network (ADN), Avionics Full-Duplex
Switched Ethernet
(AFDX), commercial-cff-the-shelf (COTS),ARINC 664
-
vi
KATA PENGANTAR
-
vii
UCAPAN TERIMA KASIH
-
viii
DAFTAR ISI
LEMBAR SAMPUL
...................................................................................................Error!
Bookmark not defined.
LEMBAR PENGESAHAN ..................................... Error!
Bookmark not defined.
LEMBAR PERNYATAAN ORISINALITAS ...... Error! Bookmark not
defined.i
ABSTRAK
.................................................................................................................
iv
ABSTRACT
..............................................................
Error! Bookmark not defined.
KATA PENGANTAR
..............................................................................................
vii
UCAPAN TERIMA KASIH
..................................................................................
viii
DAFTAR ISI
............................................................................................................
viii
DAFTAR GAMBAR
..................................................................................................
x
DAFTAR TABEL
.....................................................................................................
xi
DAFTAR ISTILAH
.................................................................................................
xii
BAB I PENDAHULUAN .........................................
Error! Bookmark not defined.
1.1 Latar
Belakang................................................. Error!
Bookmark not defined.
1.2 Tujuan
..............................................................
Error! Bookmark not defined.
1.3 Rumusan Masalah ...........................................
Error! Bookmark not defined.
1.4 Batasan Masalah
.............................................. Error! Bookmark not
defined.
1.5 Metodologi
...................................................... Error!
Bookmark not defined.
1.6 Sistematika Penulisan ......................................
Error! Bookmark not defined.
BAB II LANDASAN TEORI .................................. Error!
Bookmark not defined.
2.1 ARINC 664 Specification, Part 7 .................... Error!
Bookmark not defined.
2.1.1 ARINC 664
.................................................................................................
5
2.1.2 AFDX .....................................................
Error! Bookmark not defined.6
2.2 Full Duplex Switched Ethernet
.........................................................................
8
2.3 Virtual Links
....................................................................................................
10
BAB III PERANCANGAN DAN IMPLEMENTASI SISTEM Error! Bookmark
not defined.
3.1 Deskripsi dan Analisis Sistem .........................
Error! Bookmark not defined.
3.1.1 Perangkat Keras
......................................................................................
15
3.1.2 Perangkat Lunak
......................................................................................
16
3.1.3 Platform
....................................................................................................
16
-
ix
3.2 Perancangan Sistem .........................................
Error! Bookmark not defined.
3.2.1 Struktur Frame Paket
AFDX....................................................................
15
3.2.2 AFDX Packet Transmitter
.......................................................................
18
3.2.3 AFDX Switch
...........................................................................................
18
3.3 Diagram Alur Sistem .......................................
Error! Bookmark not defined.
3.4 Rancangan Pengujian
......................................................................................
20
3.5 Skenario Pengujian
..........................................................................................
22
BAB IV PENGUJIAN DAN ANALISIS ................ Error! Bookmark
not defined.
4.1 Pengujian Frame Filtering & Traffic Policing Validity .
Error! Bookmark not
defined.
4.1.1 Frame Filtering & Traffic Policing Validity pada
Ubuntu 14.04 ..... Error!
Bookmark not defined.
4.1.2 Frame Filtering & Traffic Policing Validity pada
ChronOS .......... Error!
Bookmark not defined.
4.1.3 Analisis Perbandingan Validity pada Kedua Platform
............................ 24
4.2 Pengujian Latency
...........................................................................................
25
4.2.1 Latency pada Ubuntu 14.04
.....................................................................
25
4.2.2 Latency pada ChronOS ............................ Error!
Bookmark not defined.
4.2.3 Analisis Perbandingan Latency pada Kedua Platform
............................. 26
4.3 Pengujian Jitter
................................................................................................
27
4.3.1 Jitter pada Ubuntu 14.04
..........................................................................
27
4.3.2 Jitter pada ChronOS
.................................................................................
28
4.3.3 Analisis Perbandingan Jitter pada Kedua
Platform.................................. 29
BAB V KESIMPULAN DAN SARAN
...................................................................
30
5.1 Kesimpulan
......................................................................................................
30
5.2 Saran
................................................................................................................
30
DAFTAR PUSTAKA
...............................................................................................
31
LAMPIRAN A : KODE PROGRAM AFDX TRANSMITTER ...................
Error!
Bookmark not defined.
LAMPIRAN B : KODE PROGRAM AFDX SWITCH
....................................... 34
-
x
DAFTAR GAMBAR
Gambar 2.1 Jaringan AFDX..6
Gambar 2.2 Topologi AFDX padaa pesawat A380..7
Gambar 2.3 Infrastruktur jaringan pada pesawat terbang.....7
Gambar 2.4 Ethernet timing.....9
Gambar 2.5 Virtual Link pada jaringan AFDX...11
Gambar 2.6 Transmission Flow .....12
Gambar 2.7 Verifikasi BAG oleh switch....13
Gambar 2.8 Latency pada jaringan AFDX.....14
Gambar 3.1 PC yang digunakan untuk implementasi
sistem.....15
Gambar 3.2 Struktur Frame AFDX....17
Gambar 3.3 Diagram Alur Sistem..19
Gambar 3.4 Rancangan topologi pengujian...21
-
xi
DAFTAR TABEL
Tabel 3.1 Rancangan Parameter pengujian..20
Tabel 4.1 Hasil uji Frame Filtering Validity pada Ubuntu 23
Tabel 4.2 Hasil uji Frame Filtering Validity pada ChronOS
..24
Tabel 4.3 Hasil uji Latency pada Ubuntu 25
Tabel 4.4 Hasil uji Latency pada ChronOS ..26
Tabel 4.5 Hasil uji Jitter pada Ubuntu .27
Tabel 4.6 Hasil uji Jitter pada ChronOS ...28
-
xii
DAFTAR ISTILAH
AFDX Implementasi dari standar ARINC 664 yang dibangun
dengan menggunakan komponen komponen COTS berbasis IEEE 802.3
(Ethernet).Pada layer fisik, AFDX
menggunakan topologi star dengan full-duplexed
switched Ethernet.Jaringan pada AFDX bersifat
profiled, artinya, seluruh koneksi, addressing, serta
bandwidth pada jaringan sudah di tentukan dari
awal.Jalur yang ada dari setiap bagian jaringan telah
ditentukan secara spesifik.
.
Commercial Of The Self Adalah produk-produk yang dapat berupa
suatu paket
aplikasi, sub sistem ataupun modul-modul perangkat
lunak maupun perangkat keras yang telah dirancang
sesuai dengan suatu standar proses bisnis tertentu dan
tersedia secara luas dipasar untuk dapat digunakan
dengan modifikasi sesuai kebutuhan masing masing.
Delay Jarak waktu antar kedatangan paket
Frame Filtering Fungsionalitas yang memungkinkan sistem
untuk
melakukan penyaringan terhadap frame-frame yang
melewati Switch, kemudian memilih keputusan tentang
apa yang harus dilakukan terhadap frame-frame
tersebut berdasarkan rule yang telah dibuat.
Jitter Variasi dari waktu delay.
Latency waktu antara ketika paket siap untuk transmisikan,
dengan waktu transmisi tersebut selesai dilakukan[12]
Traffic Policing Fungsionalitas yang memungkinkan sistem untuk
untuk
mendefinisikan jalur yang dapat dan yang tidak dapat
dilewati oleh frame-frame serta melakukan optimasi
untuk memastikan frame-frame tersebut dapat terkirim
dalam waktu yang telah ditentukan.
-
1
BAB I
PENDAHULUAN
1.1 LATAR BELAKANG MASALAH
Pada saat ini, pertukaran informasi antar avionics subsystem
yang berada
pada pesawat terbang telah menjadi hal yang sangat krusial. Hal
ini disebabkan karena
sejak tahun 1988 yang dipelopori oleh pesawat Airbus A320,
industri pesawat terbang
telah beralih menggunakan sistem all-electronic fly-by-wire
dimana pesawat dikontrol
penuh menggunakan sinyal elektrik, tidak lagi menggunakan sinyal
mekanik. Sebagai
safely-critical system, penggunaan sinyal elektrik tentu membuat
pesawat
membutuhkan komunikasi yang reliable, real time serta high speed
antara avionic
subsystem yang berada di dalam pesawat.
Berdasarkan masalah dan kebutuhan tersebut, Airbus mengembangkan
dan
memperkenalkan sebuah platform yaitu Aircraft Full Duplex
Switched Ethernet
(AFDX) yang diimplementasikan berdasarkan standar spesifikasi
baru ARINC 664
serta komponen Commercial Off The Shelf (COTS), yaitu IEEE 802.3
(Ethernet).
Masalah yang biasa dihadapi dalam pengembangan teknologi
penerbangan adalah
lamanya waktu pengembangan serta besarnya biaya yang dibutuhkan
untuk riset dan
pembuatan alat-alat industri baru untuk memproduksi teknologi
yang dibuat secara
khusus untuk suatu vendor tertentu. Penggunaan Ethernet sebagai
komponen COTS
tentu akan sangat menghemat waktu dan biaya pengembangan karena
Ethernet sesuai
standar spesifikasi IEEE 802.3 sudah merupakan teknologi yang
matang dan terus
berkembang sejak tahun 1970.[4] Namun, merancang sistem yang
hanya bermodalkan
komponen COTS untuk mencapai performansi yang deterministik
sesuai system
requirement, menjadi tantangan tersendiri pada penelitian ini.
Sifat deterministik pada
penelitian ini diartikan sebagai jaringan yang memiliki nilai
jitter < 500 mikrosecond
untuk menjamin variansi delay yang nyaris nihil, nilai latency
< 150 ms, hanya
menerima paket yang memenuhi aturan frame filtering serta dapat
menjamin seluruh
transmisi data hanya dilakukan pada jalur dan tujuan yang
didefinisikan sesuai aturan
traffic policing.
Berangkat dari konsep tersebut, penulis akan melakukan studi
dan
implementasi untuk merancang platform Aircraft Data Network
berbasis real time
system, yang akan menggunakan Embedded PC berbasis Linux sebagai
komponen
COTS serta dapat memenuhi standar spesifikasi ARINC 664. Masalah
yang dihadapi
pada penelitian ini adalah harus dilakukan perancangan dan
pembuatan software,
hardware, serta rule list yang sesuai dengan kebutuhan sistem
sebelum akhirnya
dilakukan pengujian untuk dapat menyimpulkan apakah sistem yang
dibuat
sepenuhnya dengan komponen COTS dapat memenuhi sifat jaringan
deterministik
yang diharapkan oleh Aircraft Data Network (ADN), seperti yang
dilakukan AFDX.
Pada sistem yang diimplementasikan dalam lingkup ADN, dibutuhkan
jaringan yang
bersifat deterministik, sehingga switch yang dirancang harus
dapat menangani fungsi
frame filtering serta traffic policing untuk menjamin semua
transmisi frame data pada
sistem berjalan secara deterministik.
-
2
1.2 Rumusan Masalah Rumusan masalah dalam pengerjaan tugas akhir
ini adalah sebagai berikut
1. Bagaimana cara pengaplikasian fungsi frame filtering serta
traffic policing untuk switched Ethernet berbasis embedded PC?
2. Apakah sistem yang dibuat sudah deterministik dan memenuhi
standar spesifikasi ARINC 664?.
1.3 Tujuan
Tujuan penulisan Tugas Akhir ini adalah sebagai berikut :
1. Merancang dan mengimplementasikan Aircraft Full Duplex
Switched Ethernet (AFDX ) berbasis embedded device menggunakan
Linux yang
dapat menangani frame filtering serta traffic policing untuk
sistem.
2. Menganalisis karakteristik jaringan AFDX berdasarkan frame
filtering serta traffic policing yang telah diimplementasikan.
3. Menganalisis performansi kernel Linux standar dengan kernel
Linux kustom sebagai komponen COTS yang lebih handal berdasarkan
nilai
jitter dan latency-nya serta membuktikan bahwa performansi
sistem yang
dibuat sudah memenuhi standar spesifikasi ARINC 664.
1.4 Batasan Masalah
Batasan masalah pada tugas akhir ini meliputi :
1. Standar spesifikasi yang dijadikan acuan adalah ARINC 664. 2.
Media pengkabelan yang digunakan adalah kabel UTP dengan
bandwidth
maksimal 100Mb/s
3. Bagian dari sistem yang ditangani penulis adalah Full Duplex
Switched Ethernet yang dibangun berbasis embedded device
menggunakan Linux
4. Pengujian tidak mencakup performansi Redundancy Management
serta Scheduling system, sehingga scheduling default yang digunakan
adalah First
In First Out (FIFO).
-
3
1.5 METODOLOGI PENELITIAN
Metodologi penelitian yang akan digunakan dalam penyelesaian
tugas akhir
ini adalah :
a) Studi Literatur Pada fase ini dilakukan tahap mencari,
mengumpulkan, dan mempelajari
informasi referensi yang bersumber dari buku, jurnal maupun
sumber lain
dari internet sebagai landasan teori dalam pengerjaan dan
penyusunan
tugas akhir ini. Khususnya referensi yang berkaitan dengan ARINC
664,
Real Time System dan Network Programming berbasis linux. Tahap
ini
dilakukan selama pengerjaan tugas akhir berlangsung.
b) Konsultasi Pada fase ini dilakukan bimbingan dengan dosen
pembimbing & dosen
lainnya yang terkait dengan masalah yang terdapat pada Tugas
Akhir ini.
c) Perancangan Sistem Pada fase ini dilakukan perancangann
topologi jaringan, mendefinisikan
addressing serta bandwidth requirement tiap virtual link,
serta
mendefinisikan filtering frame yang valid.
d) Implementasi Sistem Pada fase ini dilakukan implementasi
rancangan sistem ke dalam
embedded device yang dibangun menggunakan Linux untuk dapat
menangani bagian kebutuhan fungsi switching dari keseluruhan
sistem.
e) Pengujian dan Analisis Hasil Implementasi Sistem Pada fase
ini dilakukan pengujian dari sistem yang telah
diimplementasikan, kemudian dilanjutkan dengan menganalisis
hasil
implementasi berupa validitas dan integritas dari frame
filtering serta
traffic policing berdasarkan komunikasi data yang dilakukan
switch.
f) Pembuatan Laporan Tugas Akhir Pada fase ini dilakukan
dokumentasi dari penyelesaian tugas akhir ini ke
dalam bentuk laporan tertulis.
-
4
1.6 SISTEMATIKA PENULISAN
Penulisan tugas akhir ini memiliki sistematika sebagai berikut
:
BAB I PENDAHULUAN
Pada bab ini jelaskan mengenai latar belakang, tujuan
penelitian,
rumusan masalah, batasan masalah, metode penelitian dan
sistematika
penulisan tugas akhir.
BAB II DASAR TEORI
Pada bab ini dimuat teori pendukung mengenai Aircraft Data
Network,
socket programming, Aircraft Full Duplex Switched Ethernet dan
Qos
pada jaringan untuk mendukung penyelesaian penelitian ini.
BAB III PERANCANGAN SISTEM
Pada bab ini dijelaskan mekanisme sistem perangkat keras dan
perangkat lunak, pengujian yang akan dilakukan dan spesifikasi
dari
sistem yang mendukung untuk tugas akhir.
BAB IV PENGUJIAN DAN ANALISIS
Pada bab ini dibahas tahap-tahap pengujian dan analisis dari
hasil yang
didapat mengenai performansi sistem yang dibangun serta
tingkat
kelayakannya terhadap spesifikasi ARINC 664
BAB V KESIMPULAN DAN SARAN
Pada bab ini dijabarkan kesimpulan dari hasil analisa
perancangan
sistem AFDX berbasis komponen COTS dan saran saran yang
mendukung untuk penelitian selanjutnya.
-
5
BAB 2
Landasan Teori
2.1 ARINC 664 Specification, Part 7
2.1.1. ARINC 664
ARINC 664 adalah sebuah standar spesifikasi yang
mengimplementasikan
pemakaian Ethernet data network di dalam pesawat terbang. ARINC
664
dikembangkan dan dispesifikasikan kedalam beberapa bagian, yaitu
:
Part 1 - Systems Concepts and Overview
Part 2 - Ethernet Physical and Data Link Layer
Specifications
Part 3 - Internet-based Protocols and Services
Part 4 - Internet-based Address Structures and Assigned
Numbers
Part 5 - Network Interconnection Services and Functional
Elements
Part 6 - Reserved
Part 7 - Avionics Full Duplex Switched Ethernet (AFDX)
Network
Part 8 - Upper Layer Services
ARINC 664 merupakan standar baru yang dibuat untuk memenuhi
kebutuhan
industri pesawat terbang modern yang membutuhkan bandwidth yang
tinggi untuk
koneksi data antar subsystem nya serta menggunakan pengkabelan
seminimal
mungkin untuk mengurangi beban pesawat. Hal ini, sayangnya belum
dapat terpenuhi
oleh pendahulunya, ARINC 429.[4]
Bagian ke 7 dari ARINC 664 membahas tentang penerapan dari
standar
spesifikasi ARINC 664 yang menggunakan jaringan switch berbasis
Ethernet pada
Aircraft Data Network, sehingga sistem yang dibangun dapat
dikatakan layak apabila
mampu memenuhi standar dari dokumen ini.
Pada sebuah sistem yang memiliki banyak end points seperti
pesawat Airbus,
tentu penggunaan unidirectional data bus yang bekerja secara
point-to-point menjadi
sangat tidak efektif. Hal ini menjadi kelemahan ARINC 429, yang
menggunakan
standar tersebut karena konsep tersebut akan membutuhkan banyak
pengkabelan yang
akan menambah beban pesawat. Di sisi lain, ARINC 664 yang
dapat
mengimplementasikan pemakaian Ethernet, dapat menggunakan teknik
switching
untuk dapat memenuhi kebutuhan infrastruktur yang sama, dengan
pengkabelan yang
lebih minimum.
-
6
2.1.2. AFDX
AFDX merupakan implementasi dari standar ARINC 664 yang
dibangun
dengan menggunakan komponenkomponen COTS berbasis IEEE 802.3
(Ethernet).Pada layer fisik, AFDX menggunakan topologi star dengan
full-duplexed
switched Ethernet. Jaringan pada AFDX bersifat profiled,
artinya, seluruh koneksi,
addressing, serta bandwidth pada jaringan sudah ditentukan dari
awal. Jalur yang ada
dari setiap bagian jaringan telah ditentukan secara
spesifik.
AFDX menggunakan konsep virtual link untuk menggantikan
konsep
unidirectional bus connection yang digunakan oleh standar
sebelum nya, yaitu
ARINC 429. Dengan menggunakan virtual link, dapat dibuat banyak
koneksi point-
to-point dalam jaringan tanpa membutuhkan kabel fisik untuk
setiap link yang ada.
Sehingga, pengkabelan pada pesawat terbang dapat dilakukan
seminimum
mungkin.[9] Karena jaringan pada AFDX bersifat profiled, maka
addressing dan
bandwidth requirement pada setiap VL juga harus didefinisikan di
awal. Dan harus di
update secara manual ketika ada upgrade atau perubahan yang
dilakukan pada
subsystem pesawat.
Pada topologi fisiknya, AFDX terdiri dari 3 komponen, yaitu
Avionics
Subsystem, End systems dan AFDX Interconnect (Switch).[9]
Gambar 2.1.Jaringan AFDX[9]
End system menyediakan layanan interface untuk avionic subsystem
agar
dapat terhubung dengan jaringan. Suatu End-System dapat
terhubung dengan End-
System lain dengan menggunakan switch, melalui virtual links
yang telah didefinisikan
di awal. Setiap switch dapat terhubung sampai dengan 24 Switch.
Pada gambar di
bawah, dapat dilihat praktik nyata penerapan topologi AFDX pada
pesawat A380.
-
7
Gambar 2.2.Topologi AFDX pada pesawat A380 (Airbus)[5]
Gambar 2.2.Infrastruktur jaringan pada pesawat terbang[5]
-
8
2.2 Full Duplex Switched Ethernet
Pada mode half duplex, komunikasi point-to-point hanya dapat
dilakukan
secara satu arah. Komunikasi tidak dapat dilakukan dengan
serentak, artinya ketika
sebuah end system sedang melakukan transmisi, end system lainnya
harus menunggu
untuk menerima transmisi, agar kemudian dapat bergantian
mendapat giliran untuk
melakukan transmisi. Hal ini tentu akan menjadi masalah ketika
ada banyak host yang
terhubung ke media komunikasi yang sama, Collision akan sering
terjadi. Untuk
mengatasi hal tersebut, maka di perlukan Full-duplex Switched
Ethernet. Komunikasi
full duplex dapat melakukan transmisi dan penerimaan paket
secara bersamaan. Hal
ini akan mengatasi kemungkinan terjadi collision ketika ada
transmisi yang terjadi.
Jika banyak collision terjadi, delay transmission yang besar
juga mungkin terjadi, hal
ini tentu tidak dapat diterima di aircraft data network yang
memerlukan koneksi yang
reliable dan real time. Hal ini mendasari kenapa Full-Duplex
Switched Ethernet yang
dapat menghilangkan kemungkinan collision, menjadi standar
mutlak pada ADN.
Pada gambar dibawah dapat dilihat setiap End-System yang
tertanam pada masing-
masing avionics subsystem terhubung ke switch melalui
Full-duplex link yang terdiri
dari twisted pair untuk transmit (Tx) dan twisted pair untuk
receive (Rx).[2]
Rx buffer dan Tx buffer dapat menangani banyak paket yang keluar
dan masuk
dengan urutan FIFO. Fungsi CPU adalah memeriksa paket mana yang
akan diteruskan
selanjutnya dengan menentukan virtual link identifier pada Rx
buffer, kemudian
menggunakan Forwarding Table untuk menentukan Tx buffer mana
yang akan
menerima paket tersebut. Secara teori, dapat terjadi kemungkinan
buffer overflow
pada Rx buffer maupun Tx buffer, namun apa bila buffer
requirement telah diukur
dengan tepat. Kemungkinan overflow dapat dihindari.[3]
-
9
Gambar 2.3 Full duplex switched Ethernet
Gambar 2.4 Ethernet timing
Salah satu masalah lain yang menjadi ancaman pada arsitektur
switching
seperti ini adalah jitter yang dapat terjadi karena random delay
saat suatu paket
menunggu paket lain untuk dikirimkan. Pada contoh sederhana pada
gambar 2.4,
misalkan ES a dan ES b mentransmisikan data ke ES c. Frame-frame
data dikirimkan
melalui switch SWa. Switch SWa akan menangani frame yang datang
serentak dari ES
a dan ES b dengan melakukan sequencing pada dua frame tersebut
kemudian
ditransmikan ulang ke ES c. Maksimum jitter bergantung pada
panjang pesan :
-
10
Tj = (8 x M) / Nbw + Tmin_gap (2.1)
Latency untuk frame pertama:
La = Ts + Tm1 + Tsw + ( 8 x M )/Nbw + Tm2 + Tr (2.2)
Latency untuk delayed frame:
Lb = La + Tj
dengan:
Tsw = hardware latency pada switch, dalam detik
Tmi = message timing (length / bandwidth)
M = ukuran frame dalam octets
Nbw = media bandwidth, dalam bits/s
Tmin_gap = minimum inter-frame gap, dalam detik
Tj = jitter time
Peran terpenting AFDX switch menurut ARINC Specification, Part 7
adalah
menangani Filtering & Policing dimana setiap frame yang tiba
di-switch akan di filter
dalam beberapa langkah. Aturan-aturan yang dibuat meliputi frame
integrity, frame
length, traffic budget dan acceptable destination. Setiap frame
yang tidak memenuhi
aturan akan di drop oleh switch. Setiap frame yang lolos tahap
filter akan diteruskan
ke port tujuannya sesuai dengan data konfigurasi statis pada
Configuration Tables.[4]
2.3 Virtual Links
Ide utama dari virtual links berdasarkan ARINC 664, Part 7
adalah untuk
mempertahankan konsep point-to-point links, namun mengurangi
jumlah pengkabelan
dengan cara mengubah penggunaan jalur fisik pada koneksi
point-to-point seperti
pada ARINC 429, menjadi penggunaan jalur virtual yang
didefinisikan secara
spesifik.[3] Berikut ini merupakan beberapa spesifikasi Virtual
Links berdasarkan
standar ARINC 664 :
Secara teori, sebuah jaringan dapat mendefinisikan sampai 64k
(216) Virtual Links berdasarkan 16-Bit Identifier pada MAC
Destination Field dalam Ethernet Frame.
Sebuah End-System dapat memiliki lebih dari satu Virtual
Links
End-System melakukan Traffic shaping dan Integrity Checking pada
setiap Virtual Link
Switch melakukakan Traffic policing pada setiap Virtual Link
Dengan mengkombinasikan Traffic shaping dan policing,
pembentukan dari garis besar perilaku deterministik jaringan dapat
dilakukan.[4]
-
11
Gambar 2.5 Virtual Link pada jaringan AFDX[4]
2.3.1 Bandwidth Allocation GAP (BAG) dan Lmax
BAG adalah minimum interval dalam milidetik antar Ethernet Frame
yang
ditransmisikan melalui Virtual Link.
Untuk melakukan traffic shaping, End-System akan mengontrol
transmission
flow pada setiap Virtual Link sesuai dengan BAG nya, sedangkan
untuk melakukan
traffic policing, Switch akan memverifikasi BAG.
Gambar 2.6 Transmission flow berdasarkan BAG[3]
-
12
Gambar 2.7 Verifikasi BAG oleh switch[3]
Frame pada Virtual Link dapat ditransmisikan lebih lambat dari
BAG nya
tanpa memberi dampak pada switching. Namun, mentransmisikan
frame pada Virtual
Link lebih cepat dari BAG nya akan memberi dampak pada
switching. Nilai dari BAG
adalah 2n Dimana n < 8, sehingga nilai yang diterima untuk
BAG adalah :
1,2,4,8,16,32,64,128. Adapun jumlah maksimal frame yang dapat
ditransmisikan
sebuah Virtual Link dapat dihitung dengan rumus :
Max frame per second = 1000
(2.3)
Misalkan sebuah Virtual Link dengan VLID 1 mempunyai nilai BAG
64
milidetik, maka setiap frame pada VLID akan ditransmisikan
paling cepat tiap 64
milidetik pula.
Lmax adalah Ethernet frame terbesar yang diizinkan untuk
ditransmisikan
melalui Virtual Link, yang diukur dengan satuan bytes.Misalkan
VLID 1 tadi memiliki
Lmax bernilai 400 bytes. Maka Bandwidth maksimal pada VLID 1
adalah sebesar
50.000 bits per detik, yang dapat dihitung dengan rumus :
Bandwidth Maksimal = Lmax * 8 * 1000
(2.4)
= 400 * 8 * 1000
64 = 50.000 bit / detik.
2.3.2 Jitter
Jitter adalah selisih antara waktu minimum dan maksimum dari
ketika sebuah
End-System mengirim sebuah frame hingga End-System lain nya
menerima frame
tersebut melalui Virtual Link[3]. Jitter dapat juga dikatakan
variasi dari delay.
Maximum allowed jitter adalah standar parameter untuk
mempertahankan Quality of
Service dari Account pada setiap Virtual Link. Maximum allowed
jitter dapat
dihitung dengan rumus :
MaxJitter 40 s + ((20+ i).8) { }
(2.5)
MaxJitter 500 s
Aci
Lmax
-
13
Dimana :
Nbw adalah Bandwidth pada Ethernet link dalam bits per detik 40
s adalah standar minimum dari fixed technological jitter Lmax
adalah Maximum size dari frames dalam byte 500 s adalah batasan
mutlak dari maximum jitter SetofVLs adalah jumlah virtual link yang
didefinisikan sistem
End-System bertugas untuk melakukan traffic shaping untuk dapat
menjaga traffic
flow agar kondisi Jitter Max. allowed jitter dapat
terpenuhi.
2.3.3 Latency
Latency pada transmisi didefinisikan sebagai durasi antara
beberapa point
pengukuran yang diilustrasikan dalam gambar 2.8 di bawah.
Awal: Bit terakhir dari sebuah hosted partion data tersedia
untuk communication service pada End-System.
Akhir: Bit terakhir dari Ethernet frame[4] Adapun latency
maksimal yang diizinkan pada sistem akan dihitung dengan rumus
sebagai berikut :
MaxLatency BAG +MaxJitter +Technological Latency (2.6)
Dimana Technological Latency pada sistem = 150ms
-
14
Gambar 2.8 Latency pada jaringan AFDX[4]
2.4 Embedded Linux
Linux merupakan kernel sistem operasi yang telah berkembang
pesat
semenjak pertama kali dirilis pada tahun 1991. Linux pada
awalnya dikembangkan
untuk personal computer berbasis arsitektur Intel x86, namun
pada saat ini, linux telah
banyak dikembangkan untuk digunakan pada platform-platform lain
seperti untuk
server, mainframe computers sampai supercomputer. Linux mampu
dijalankan mulai
dari prosessor berkapasitas besar sampai dengan microprossor
dengan kemampuan
rendah. Karena kemampuan Linux yang sangat fleksibel sehingga
mudah dikustomasi
sesuai dengan kebutuhan khusus masing-masing pihak, ditambah
lagi lisensi Linux
yang mengizinkan semua orang untuk mengembangkan serta
mengkustomasi Linux
secara gratis sehingga akan menghemat biaya pengembangan, Linux
sering dijadikan
pilihan utama untuk pengembangan embedded systems. Contoh
embedded system
yang sering dikembangkan dengan menggunakan Linux adalah
komputer tablet,
router jaringan, alat-alat otomasi industri, sampai sistem
akuisisi data dan navigasi
pada pesawat terbang[14].
-
15
2.4.1 Ubuntu
Ubuntu merupakan salah satu distribusi Linux yang paling popular
karena
sangat user-friendly serta karena kehandalan nya. Sebagai salah
satu distribusi Linux,
pada pemrograman C di Ubuntu, kita dapat mengandalkan system
call seperti fork,
serta dapat menggunakan native library untuk pembentukan paket
yang diperlukan
dalam sistem.
Ubuntu sering dijadikan pilihan oleh para developer untuk
mengembangkan
embedded system karena selain lisensi Ubuntu yang gratis,
sehingga dapat menghemat
biaya pengembangan, Environment Ubuntu yang sangat familiar bagi
kebanyakan
orang, mempunyai kernel yang stabil, mudah di cross compile
untuk dapat
diaplikasikan di platform lain, Ubuntu juga disukai karena
mudahnya konfigurasi
jaringan serta banyak disediakan services untuk melakukan
analisa jaringan.
Walaupun Ubuntu sebenarnya tidak dikembangkan khusus untuk
digunakan
pada Embedded PC, namun karena kemampuan Ubuntu untuk dapat
dikustomasi
dengan bebas menjadikan user dapat dapat membuang modul-modul
yang tidak
diperlukan serta hanya menyisakan modul-modul yang diperlukan
untuk keperluan
sistem secara spesifik. Hal ini menjadikan Ubuntu dapat
dijadikan Embedded System,
karena secara definisi Embedded System adalah Kombinasi dari
hardware dan software, dan bisa juga komponen-komponen tambahan
lain, didesain untuk
melakukan sebuah fungsi khusus. Pada banyak kasus, Embedded
System adalah
sebuah bagian dari sistem yang lebih besar[15].
2.4.2 ChronOS
Sama seperti Ubuntu, sebagai distribusi Linux, ChronOS
mewarisi
kemampuan untuk melakukan system call serta memiliki native
library yang
dibutuhkan untuk pembuatan sistem. ChronOS dikembangkan untuk
menjawab
interseksi dari tiga kebutuhan berikut:
a) Dukungan sistem operasi untuk memperoleh best-effort timing
assurances. b) Kernel realtime Linux yang ditanamkan menggunakan
PREEMPT_RT patch,
yaitu sebuah realtime patch yang mengizinkan preemption secara
penuh pada
Linux, serta meningkatkan interrupt latencies.
c) Dukungan sistem operasi untuk melakukan realtime scheduling
pada chip multiprocessor
ChronOS juga menyediakan berbagai macam APIs serta
infrastruktur
scheduler plugin yang dapat digunakan untuk mengimplementasikan
serta
mengevaluasi berbagai macam algoritma scheduling untuk single
processor maupun
multi processor. Karena ChronOS menggunakan custom kernel yang
menjadikannya
realtime linux dengan kemampuan realtime-scheduling dan resource
management,
sehingga diharapkan dapat memiliki performansi lebih tinggi
dibanding linux dengan
kernel standar seperti Ubuntu[16].
-
16
2.4 LibPcap
Libpcap merupakan library C/C++ yang dapat diandalkan untuk
menangkap
serta mengirim paket data pada datalink layer. Sehingga
memungkinkan aplikasi
untuk membangun sendiri protocol stack untuk paket AFDX. Risso
dan
Degioanni[10] mengklaim bahwa Arsitektur WinPcap (Libpcap versi
windows) adalah open system pertama untuk keperluan packet capture
yang dapat mengisi gap
penting antara Unix dan Windows. Selain itu Libpcap juga
mengutamakan performansi sehingga sanggup untuk memenuhi kebutuhan
hampir seluruh aplikasi. Hal ini juga diperkuat dengan fakta
sebagian besar tools jaringan terkenal dibangun
menggunakan Libpcap seperti Wireshark, TCPDump, Nmap, Snort, dan
lain-lain.
Adapun alur proses kerja Libpcap secara umum terdiri dari
proses-proses
sebagai berikut :
1. Awalnya pcap akan menentukan interface mana yang akan di
sniff. Biasanya interface-interface pada Linux akan memiliki nama
seperti eth0, eth1, wlan0,
dan lain-lain. Kita bisa mendefinisikan sendiri interface yang
ingin digunakan
menggunakan string, atau menggunakan modul dari pcap untuk
membuat list
dari interface yang bisa digunakan.
2. Inisialisasi pcap. Pada tahap ini interface yang
didefinisikan akan akan mulai membuka sesi sniffing. Pcap bahkan
bisa melakukan sniffing pada banyak
interface sekaligus menggunakan file handles untuk bisa
membedakan satu sesi
sni f f ing dengan sesi lainnya .
3. Ketika dibutuhkan sniffing untuk traffic tertentu saja,
misalnya hanya paket UDP, hanya paket yang menuju port 21, pcap
dapat membuat rule set yang
disimpan dalam string atau file yang dapat dibaca, meng-compile
rule tersebut,
kemudian mengaplikasikannya pada traffic yang di-sniffing.
4. Pada tahap ini pcap akan melakukan proses loop eksekusi
utamanya. Pcap akan menunggu dan menerima setiap paket-paket yang
menuju atau melewati
interface yang ditentukan serta sesuai dengan rule set yang
telah di-compile
sebelumnya. Setiap sebuah paket diterima, Pcap memanggil fungsi
lain yang
dapat didefinisikan user untuk menentukan aksi apa yang akan
dilakukan untuk
paket-paket tersebut, seperti menampilkan isi paket tersebut,
menyimpannya ke
dalam file, atau meneruskan paket tersebut ke interface
lain.
5. Setelah proses sniffing telah selesai atau cukup dilakukan,
pcap akan menutup sesi dan seluruh proses selesai
dilakukan[10].
-
17
BAB 3
PERANCANGAN DAN IMPLEMENTASI SISTEM
3.1. Deskripsi dan Analisis Sistem
Untuk membuktikan bahwa implementasi AFDX dapat dibangun
menggunakan komponen COTS (produk komersial yang beredar luas di
pasaran),
maka dilakukan perancangan AFDX switch serta AFDX packet
transmitter dengan
pendekatan Software Defined Networking. Pengembangan software
dilakukan di
sistem operasi Linux menggunakan Bahasa C dan didukung dengan
library Libpcap.
Distribusi Linux yang akan digunakan adalah Ubuntu 14.04 dan
ChronoOS.
3.1.1 Perangkat Keras
Implementasi sistem dilakukan menggunakan 4 unit PC dengan
spesifikasi
sebagai berikut:
a. Prosesor Intel Core i5-3230M 2.6 GHz
b. Realtek PCIE GBE Family Controller (Ethernet Adapter) c. RAM
DDR3 4GB Tiga unit PC akan berperan sebagai AFDX transmitter/End
System sedangkan 1
unit PC akan berperan sebagai AFDX Switch.
3.1.2 Perangkat Lunak
Perangkat lunak yang digunakan dalam pengembangan sistem ini
adalah
sebagai berikut :
a. GCC/G++ Kode sistem ditulis dengan Bahasa C menggunakan GCC
dan G++ sebagai
compiler nya. GCC dan G++ merupakan compiler powerful yang
berjalan di
Linux, serta memiliki kemampuan untuk meng compile library
tambahan.
b. Libpcap Libpcap merupakan library C/C++ yang dikembangkan
serta digunakan untuk
menangkap serta mengirim paket data pada datalink layer.
c. Wireshark
Wireshark merupakan packet analyzer yang digunakan untuk
menguji
performansi dari sistem. Wireshark digunakan untuk
membandingkan
validitas paket yang dikirim serta benchmarking dari pengiriman
paket-paket
tersebut.
-
18
3.1.3 Platform
Umumnya, pada safely-critical system seperti Aircraft Data
Network, para
pengembang sistem akan lebih memilih menggunakan RTOS (Real Time
Operation
System) handal seperti RTLinux, VMworks, Integrity, dan
lain-lain[11]. Namun,
karena RTOS-RTOS tersebut merupakan sistem dengan lisensi cukup
mahal serta
salah satu tujuan dari penelitian ini adalah untuk
mengoptimalkan pendekatan cost
efficiency, maka sistem operasi Linux akan dipilih sebagai
platform yang open source
dan handal. Distribusi Linux yang digunakan serta dibandingkan
performansi pada
sistem adalah Ubuntu 14.04 dan ChronOS.
3.2. Perancangan Sistem
Sistem yang dibangun terdiri dari dua bagian, yaitu AFDX
Packet
Transmitter yang bertanggung jawab untuk mengirimkan paket AFDX
serta AFDX
Switch yang bertanggung jawab untuk menerima paket tersebut
serta melakukan
forwarding ke port lain berdasarkan rule yang telah dibuat
sebelum nya. AFDX Packet
Transmitter akan ditanamkan pada semua PC yang berperan sebagai
End System
sedangkan AFDX Switch kan ditanamkan pada semua PC yang berperan
sebagai
Switch.
Karena struktur paket AFDX berbeda dengan paket TCP/IP biasa,
maka
dibutuhkan programming pada level data link layer untuk dapat
memanipulasi raw
packet menjadi paket AFDX yang memenuhi spesifikasi standar
ARINC 664. Libpcap
sebagai library yang dapat memanipulasi frame paket pada level
kernel serta mampu
menangkap dan mengirim raw packet tanpa mempedulikan protocol
stack digunakan
pada penelitian ini untuk menjadi solusi dari masalah
tersebut.
Gambar 3.2 Rancangan topologi sistem untuk pengujian
-
19
3.2.1 Perancangan Frame Paket AFDX
Pada tugas akhir ini, paket AFDX dibangun dengan
mengandalkan
kemampuan manipulasi datalink layer dari libpcap serta native
library linux yang
memiliki kemampuan memanipulasi serta mendefinisikan sendiri
header dan isi dari
suatu raw Ethernet frame. Pada sistem yang dibangun, struktur
paket AFDX
didefinisikan terdiri dari 14 Bytes Ethernet Header (6 Bytes
Destination Address, 6
Bytes Source Address, 2 Bytes Type), 20 Bytes IP Header, 8 Bytes
UDP Header dan
58 Bytes AFDX Payload yang dibungkus dan definisikan menjadi
sebuah struct yang
nantinya akan diinject ke paket yang akan dikirim AFDX Packet
Transmitter.
Gambar 3.2 Struktur Frame AFDX[12]
3.2.2 AFDX Packet Transmitter
AFDX Packet Transmitter merupakan bagian dari sistem yang
bertugas untuk
mengirimkan paket AFDX yang telah didefinisikan dan dibangun
sebelumnya dari PC
End System menuju End System lainnya melalui PC Switch yang
telah tertanam
AFDX Switch di dalamnya. AFDX Packet Transmitter ditulis dalam
Bahasa C, di
compile menggunakan GCC dan didukung oleh library libpcap dan
native library dari
linux sehingga memungkinkan aplikasi yang dibangun untuk
mengirim paket AFDX
ke jaringan. Pada tugas akhir ini, perancangan Packet
Transmitter tidak mencakup
fungsi scheduling dan redundancy management.
3.2.3 AFDX Switch
AFDX Switch merupakan bagian dari sistem yang bertugas untuk
melakukan
frame filtering serta traffic policing dari paket yang dikirim
oleh AFDX Packet
Transmitter. Setelah menerima paket AFDX yang dikirim oleh
transmitter, AFDX
Switch akan memeriksa validitas paket yang diterima, jika paket
tersebut memenuhi
rule yang telah dibuat, maka paket tersebut akan di-forward ke
EndSystem yang dituju
berdasarkan Virtual Link ID yang didefinisikan. Sama seperti
AFDX Packet
Transmitter, AFDX Switch juga ditulis dalam Bahasa C, di compile
menggunakan
GCC dan didukung oleh library libpcap dan native library dari
linux sehingga
memungkinkan aplikasi yang dibangun untuk menerima serta
meneruskan paket
AFDX ke jaringan. Penggunaan System Call Fork dari Linux juga
memungkinkan
aplikasi untuk dapat meng-handle banyak network interface
adapter sekaligus.
-
20
3.3. Diagram Alur Sistem
Gambar 3.3 Diagram Alur Sistem
Adapun penjelasan dari diagram di atas adalah sebagai berikut
:
a. Pada tahap inisiasi, Packet Transmitter akan membangun paket
AFDX dari datalink layer kemudian mendefinisikan nilai Virtual Link
ID paket
tersebut
b. Transmitter akan mengirim paket AFDX ke End System tujuan
sesuai Virtual Link ID yang didefinisikan
c. Ketika Switch menerima paket, awalnya akan dilakukan
pengecekan apakah paket yang datang berasal dari Virtual Link ID
yang sesuai, jika
tidak, paket akan di-drop, jika sesuai maka akan dilakukan frame
filtering
sesuai rule yang didefinisikan. Jika paket tidak sesuai rule,
maka paket
akan di-drop, sebaliknya jika sesuai maka paket akan diteruskan
melalui
No
-
21
out-interface sesuai definisi Virtual Link ID yang telah
diberikan
sebelumnya
d. Jika pada port out-interface paket masih melewati Switch
lagi, maka akan dilakukan pengecekan dan forwarding lagi, namun
jika tidak, paket dapat
langsung diterima oleh End System tujuan.
3.4. Rancangan Skenario Pengujian
Pengujian akan dilakukan menggunakan bantuan tools Wireshark.
Tools
tersebut digunakan untuk menganalisa paket-paket yang berada
pada jaringan.
Pengujian akan dilakukan dengan menggunakan spesifikasi sebagai
berikut :
Tabel 3.1 Rancangan spesifikasi pengujian
Parameter Nilai yang didefinisikan
Lmax 1518 byte
Max Jitter 500 Mikroseconds
Max Latency 150 Milliseconds
Lmin 64 byte
Bandwidth 100000 bit/s
Jumlah frame dikirim 10 frame
Validitas frame Valid/tidak valid
Pengukuran performansi dilakukan dengan memanfaatkan data
waktu
pengiriman serta penerimaan paket. Selain itu, akan dilakukan
pengecekan bahwa
paket-paket yang terkirim sudah memenuhi syarat-syarat yang
didefinisikan pada rule
set yaitu memiliki ukuran paket lebih besar dari Lmin dan lebih
kecil dari Lmax serta
paket hanya dapat terkirim melalui jalur yang didefinisikan pula
(paket yang tidak
sesuai rule harus di-drop) untuk dapat menarik kesimpulan bahwa
traffic policing serta
frame filtering telah bekerja dengan sukses.
Berikut ini merupakan beberapa aspek yang akan diperiksa untuk
frame filtering :
Destination address validity ( Ethernet address harus melalui
Virtual Link yang valid dan harus konstan)
Virtual link yang digunakan harus terdaftar pada rule set
Ethernet frame size (S) harus Antara 64-1518 Bytes serta harus
lebih kecil atau sama dengan Lmax
Ethernet frame size harus lebih besar atau sama dengan Lmin
Aturan serta ketentuanketentuan di atas digunakan untuk
memastikan frame yang melewati switch hanya frame yang valid,
menuju Virtual Link yang
valid, serta memiliki Jitter dan Latency sesuai spesifikasi.
Ketika semua syarat
tersebut dapat terpenuhi maka jaringan yang dibangun dapat
dikatakan bersifat
deterministik dan dapat memenuhi standar ARINC 664.
-
22
Pengujian akan dilakukan sebanyak 5 kali per skenario pada
masing masing
platform dengan cara mengirimkan 10 sample frame paket pada tiap
pengujiannya,
sehingga akan didapatkan pula perbandingan performansi antara
sistem yang
diimplementasikan pada Ubuntu yang menggunakan kernel Linux
biasa, dengan
sistem yang diimplementasikan pada ChronOS yang menggunakan
kernel Linux
kustom yang dirancang untuk mencapai standar real time
system.
Berikut skenario pengujian yang dirancang :
1. Pengujian Traffic Policing Validity
Pengujian ini dilakukan untuk menguji apakah sistem berhasil
mengirimkan
paket sesuai tujuannya berdasarkan rule Traffic Policing yang
didefinisikan
pada tabel di bawah. Tabel 3.2 Rule Traffic Policing
No. Multicast/Unicast Asal Tujuan Virtual
Link ID
1 Multicast ES A ES B & ES C 01
2 Unicast ES B ES A 02
3 Unicast ES C ES B 03
Pengujian Traffic Policing Validity akan dilakukan dengan dua
kondisi pada
setiap End System. Paket yang dikirimkan adalah paket AFDX yang
telah
didefinisikan sebelumnya dengan Payload sebesar 1470 bytes. Pada
kondisi
pertama, paket akan dikirimkan ke tujuan sesuai dengan rule set
yang diberikan
pada tabel di atas. Karena paket dikirim ke tujuan dan Virtual
Link yang sesuai,
maka pengujian dikatakan berhasil apabila paket dapat diterima
oleh tujuannya
masing-masing. Pada kondisi kedua, paket akan dikirimkan ke
tujuan yang
bertolak belakang atau melanggar rule traffic yang telah dibuat,
misalnya paket
dikirimkan dari End System (ES) A menuju ES B secara Unicast,
atau paket
dikirimkan dari ES C menuju ES B melalui Virtual Link ID 01.
Karena pengujian
dilakukan menggunakan rule yang tidak sesuai, maka pengujian
dikatakan
berhasil apabila paket gagal untuk sampai ke tujuan.
2. Pengujian Frame Filtering Validity
Pengujian ini dilakukan untuk menguji apakah sistem berhasil
mengirimkan
paket sesuai tujuannya berdasarkan rule frame filtering yang
didefinisikan.
Lmax atau besar frame maksimal yang diizinkan adalah 1518 bytes,
sedangkan
Lmin atau besar frame minimum yang diizinkan adalah 64 bytes
sehingga setiap
frame yang dikirimkan harus berukuran lebih kecil atau sama
dengan 1518 bytes
-
23
dan lebih besar atau sama dengan 64 bytes, setiap frame yang
berukuran selain
dari itu harus di drop.
Pengujian akan dilakukan dengan tiga kondisi dari masing-masing
End System
ke tujuannya masing-masing sesuai dengan rule set dari tabel
3.2. Paket yang
dikirimkan adalah paket AFDX yang telah didefinisikan sebelumnya
dengan
payload bervariasi pada tiap pengujian. Pada kondisi pertama,
paket akan
dikirimkan dengan besar paket di antara Lmax dan Lmin, sehingga
pengujian akan
dikatakan berhasil apabila paket sampai ke tujuan. Pada kondisi
kedua, paket akan
dikirim dengan ukuran di atas Lmax dan pada kondisi ketiga,
paket akan
dikirimkan dengan ukuran lebih kecil daripada Lmin, sehingga
pada kondisi kedua
dan ketiga pengujian dikatakan berhasil apabila paket berhasil
di-drop atau tidak
sampai pada tujuannya karena tidak sesuai dengan rule traffic
yang telah
didefinisikan.
3. Pengujian Jitter dan Latency pada sistem
Pengujian ini akan dilakukan untuk mengukur performansi sistem,
sehingga
dapat disimpulkan apakah sistem yang dibangun sudah cukup handal
dan sesuai
dengan standar ARINC 664.
Pengukuran akan dilakukan dengan melakukan pengiriman 10 paket
AFDX
dengan payload sebesar 1470 bytes dari masing-masing End System
ke tujuannya
masing-masing sesuai dengan rule set dari tabel 3.2. Pengukuran
dilakukan dengan
bantuan tools Wireshark dengan memanfaatkan data waktu
pengiriman serta
penerimaan paket.
3.5. Implementasi Sistem
BAB 4
PENGUJIAN DAN ANALISIS
-
24
Pada bab ini akan dibahas tentang pengujian dan analisis sistem
yang telah
dirancang. Pengujian dan analisis dilakukan dengan bantuan tools
Wireshark yang
akan digunakan untuk mengukur performansi sistem. Sistem diuji
pada dua platform
yaitu Ubuntu 14.04 dan ChronOS. Hasil uji kedua platform
kemudian dibandingkan
sehingga bisa ditarik kesimpulan platform mana yang lebih handal
untuk
implementasi sistem.
4.1. Pengujian Frame Filtering & Traffic Policing
Validity
Pengujian akan dilakukan berdasarkan scenario yang telah
dibuat
sebelumnya, Pengiriman paket dilakukan masing-masing 10 kali
pada masing-
masing platform. Hal yang di uji disini adalah kemampuan switch
dalam
mengenali paket mana yang harus di-Drop dan paket mana yang
harus
diteruskan sesuai Virtual Link ID-nya.
4.1.1 Frame Filtering & Traffic Policing Validity pada
Ubuntu 14.04
Tabel 4.1 Hasil uji Frame Filtering & Traffic Policing
Validity pada Ubuntu
Packet
Number
Source
End
System
Destination
End
System
Virtual
Link
ID
Arrived
Packet
Size
Hasil Yang
Diharapkan
Hasil
Uji
Validitas
1 ES A ES B 01 100 Packet
Arrived
Packet
Arrived
Valid
2 ESA ES C 01 100 Packet
Arrived
Packet
Arrived
Valid
3 ES B ES A 02 100 Packet
Arrived
Packet
Arrived
Valid
4 ES C ES B 03 80 Packet
Arrived
Packet
Arrived
Valid
5 ES A ES C 01 80 Packet
Arrived
Packet
Arrived
Valid
6 ES A ES B 01 80 Packet
Arrived
Packet
Arrived
Valid
7 ES B ES C - 64 Packet
Dropped
Packet
Dropped
Valid
8 ES C ES A - 64 Packet
Dropped
Packet
Dropped
Valid
9 ES A ES B 01 64 Packet
Arrived
Packet
Arrived
Valid
10 ES A ES C 01 40 Packet
Dropped
Packet
Arrived
Invalid
% Validity 90%
-
25
4.1.2 1 Frame Filtering & Traffic Policing Validity pada
ChronOS
Tabel 4.2 Hasil uji Frame Filtering & Traffic Policing
Validity pada ChronOS
Packet
Number
Source
End
System
Destination
End
System
Virtual
Link
ID
Arrived
Packet
Size
Hasil Yang
Diharapkan
Hasil
Uji
Validitas
1 ES A ES B 01 100 Packet
Arrived
Packet
Arrived
Valid
2 ESA ES C 01 100 Packet
Arrived
Packet
Arrived
Valid
3 ES B ES A 02 100 Packet
Arrived
Packet
Arrived
Valid
4 ES C ES B 03 80 Packet
Arrived
Packet
Arrived
Valid
5 ES A ES C 01 80 Packet
Arrived
Packet
Arrived
Valid
6 ES A ES B 01 80 Packet
Arrived
Packet
Arrived
Valid
7 ES B ES C - 64 Packet
Dropped
Packet
Dropped
Valid
8 ES C ES A - 64 Packet
Dropped
Packet
Dropped
Valid
9 ES A ES B 01 64 Packet
Arrived
Packet
Arrived
Valid
10 ES A ES C 01 40 Packet
Dropped
Packet
Arrived
Invalid
% Validity 90%
4.1.3 Analisis Perbandingan Frame Filtering & Traffic
Policing pada Kedua
Platform
Dari kedua pengujian, dapat dilihat bahwa tidak ada perbedaan
antara kedua
platform. Dari hal ini bisa disimpulkan bahwa kernel realtime
Linux tidak terlalu
menambah poin lebih dalam hal memastikan validitas frame yang
lewat melalui
fungsi filtering yang dimiliki oleh sistem. Dari hal ini pula
dapat kita simpulkan
bahwa komponen COTS sudah cukup handal untuk memastikan
validitas paket
AFDX serta mendefinisikan virtual link yang dapat dilalui oleh
paket AFDX.
4.2. Pengujian Latency
Pada spesifikasi AFDX di ARINC 664, latency didefinisikan
sebagai waktu
antara ketika paket siap untuk transmisikan, dengan waktu
transmisi tersebut selesai
dilakukan[12] . Sehingga pada tugas akhir ini, latency dianggap
sebagai rata-rata dari
selisih waktu transmisi antar paket
-
26
4.2.1 Latency pada Ubuntu 14.04
Tabel 4.3 Hasil uji Latency Ubuntu
Packet
Number
Packet Sent
Epoch Time
Latency i = (Sent time i (Sent time i-1))
(seconds)
1 1436111914.478907000 0.00005
2 1436111914.478956000 0.00003
3 1436111914.478980000 0.00002
4 1436111914.479002000 0.00002
5 1436111914.479024000 0.00002
6 1436111914.479046000 0.00002
7 1436111914.479068000 0.00002
8 1436111914.479089000 0.00003
9 1436111914.479112000 0.00002
10 1436111914.479133000 0.00005
Rata rata Latency 200 microseconds
Max Latency = 500 microseconds
Min Latency = 200 microseconds
4.2.2 Latency pada ChronOS
Tabel 4.4 Hasil uji Latency ChronOS
-
27
Packet Number Packet Sent
Epoch Time
Latency i = (Sent time i (Sent time i-1))
(seconds)
1 1436111921.432960 0.0000100
2 1436111921.432970 0.0000100
3 1436111921.432980 0.0000099
4 1436111921.433060 0.0000100
5 1436111921.433060 0.0000100
6 1436111921.433060 0.0000200
7 1436111921.433060 0.0000301
8 1436111921.433140 0.0000100
9 1436111921.433150 0.0000100
10 1436111921.433160 0.0000100
Rata rata Latency 130 microseconds
Max Latency = 301 microseconds
Min Latency = 99 microseconds
4.2.3 Analisis Perbandingan Latency pada Kedua Platform
Pada kedua pengujian dapat dibandingkan bahwa sistem yang
diimplementasikan pada ChronOS memiliki nilai latency yang lebih
rendah dari
sistem yang diimplementasikan pada Ubuntu. Dari hal ini dapat
ditarik kesimpulan
bahwa kernel realtime Linux yang dimiliki ChronOS merupakan
faktor yang
berpengaruh pada kinerja sistem. Selain itu, dibuktikan pula
bahwa komponen COTS
sudah cukup handal untuk memenuhi requirement nilai max latency
< 150 ms[4]
menurut standar spesifikasi ARINC 664.
4.3. Pengujian Jitter
-
28
Pengukuran besar Jitter pada sistem dilakukan menggunakan tools
Wireshark.
AFDX transmitter akan mengirim paket dari End System A ke End
System B.
Wireshark dipasang pada kedua End System, kemudian waktu
pengiriman dan
kedatangan paket akan dicatat dan dicari selisihnya untuk
mendapatkan nilai delay.
Kemudian nilai jitter akan dicari dengan rumus :
Jitter =
1
4.3.1 Jitter pada Ubuntu 14.04
Tabel 4.5 Hasil uji Jitter Ubuntu
Packet
Number
Packet Sent
Epoch Time
Packet Arrival Epoch
Time
Delay (seconds)
1 1436111914.478907000 1436111921.432962000 6.954060078
2 1436111914.478956000 1436111921.432975000 6.954020023
3 1436111914.478980000 1436111921.432976000 6.953989983
4 1436111914.479002000 1436111921.433064000 6.954059839
5 1436111914.479024000 1436111921.433068000 6.954039812
6 1436111914.479046000 1436111921.433068000 6.954020023
7 1436111914.479068000 1436111921.433069000 6.953999996
8 1436111914.479089000 1436111921.433150000 6.954070091
9 1436111914.479112000 1436111921.433153000 6.954040051
10 1436111914.479133000 1436111921.433153000 6.954020023
Jitter 0.0023333528689
seconds
Variansi Delay = (6.954020023-6.954060078)+(
6.953989983-6.954020023)+(
6.954059839-6.953989983)+( 6.954039812-6.954059839)-(
6.954020023-
6.954039812)+(6.953999996-6.954020023)+(6.954070091-6.953999996)+(
6.954040051-6.954070091)+( 6.954020023-6.954040051)
Variansi Delay = 0.0210
Jitter = 0.0210001/9 = 0.0023333528689 second = 2 ms
4.3.2 Jitter pada ChronOS
Tabel 4.6 Hasil uji Jitter ChronOS
-
29
Packet
Number
Packet Sent
Epoch Time
Packet Arrival Epoch
Time
Delay
(seconds)
1 1436112914.48890 1436112921.42290 6.93400
2 1436112914.48895 1436112921.44294 6.95399
3 1436112914.48898 1436112921.44296 6.95398
4 1436112914.48900 1436112921.44304 6.95404
5 1436112914.48902 1436112921.44304 6.95402
6 1436112914.48904 1436112921.44306 6.95402
7 1436112914.48906 1436112921.44306 6.95400
8 1436112914.48908 1436112921.44318 6.95410
9 1436112914.48911 1436112921.44318 6.95407
10 1436112914.48913 1436112921.44418 6.95505
Jitter 0.00140001233
Variansi Delay = (6.95399-6.93400)+( 6.95398-6.95399)+(
6.95404
-6.95398)+( 6.95402-6.95404)-( 6.95400-6.95403)+(
6.95399-6.95402)+( 6.95407-
6.9539)+( 6.9540-6.95407)+( 6.95402-6.95404)
Variansi Delay = 0.01267100111
Jitter = 0.01267100111/9 = 0.00140001233 second = 1 ms
4.3.3 Analisis Jitter pada Kedua Platform
Pada kedua pengujian dapat dibandingkan bahwa sistem yang
diimplementasikan pada ChronOS memiliki nilai jitter yang lebih
rendah dari sistem
yang diimplementasikan pada Ubuntu. Dari hal ini dapat ditarik
kesimpulan bahwa
kernel realtime linux yang dimiliki ChronOS merupakan faktor
yang berpengaruh
pada kinerja sistem. Namun, sayangnya, nilai jitter 1ms atau
1000 mikroseconds yang
diperoleh masih belum memenuhi spesifikasi ARINC 664 yaitu max
jitter = 500
mikroseconds[4]. Untuk dapat memenuhi spesifikasi ini, pada
penelitian selanjutnya,
disarankan menggunakan platform Real Time Operation System yang
memang
dirancang untuk memenuhi spesifikasi Flight-Critical System
serta menggunakan
Ethernet Adapter yang lebih handal.
BAB 5
KESIMPULAN DAN SARAN
-
30
Pada bab sebelumnya telah ditampilkan dan dijelaskan mengenai
hasil dari
simulasi yang dilakukan oleh penulis, sehingga dari hasil
analisis didapat beberapa
kesimpulan dan saran untuk penelitian selanjutnya sebagai
berikut:
5.1 Kesimpulan
Berdasarkan pengujian yang telah dilakukan dalam tugas akhir
ini, dapat
ditarik kesimpulan sebagai berikut :
1. Komponen COTS dapat melalukan fungsi pembentukan paket AFDX
menggunakan raw Ethernet packet, melakukan pemeriksaan
validitas
paket AFDX, serta mendefinisikan jalur virtual link untuk
paket-paket
tersebut dengan baik.
2. Nilai latency untuk pengiriman paket yang dilakukan oleh
sistem sudah cukup baik, namun sayangnya hal ini masih terbatasi
oleh nilai
transmission delay yang masih jelek.
3. Nilai jitter yang dicapai sistem masih kurang baik, sehingga
sistem yang dibangun masih belum bisa dikatakan mencapai sistem
yang
bersifat deterministic
4. Kernel sistem operasi sangat berpengaruh terhadap kinerja
pemrosesan paket. Sistem yang memiliki kernel yang dirancang untuk
mencapai
sifat realtime cenderung memiliki performa lebih baik.
5.2 Saran
1. Perlu ditambahkan Frame Check Sequence untuk dapat melakukan
pengecekan frame dengan lebih akurat.
2. Fungsi Scheduling pada sistem merupakan faktor yang penting
pada pengujian, agar BAG rate dari sistem dapat diatur dan
diukur.
3. Gunakan Realtime Operating Sistem yang memang dirancang untuk
Flight-Critical System seperti RTLinux dan VMWorks agar
performansi dapat mencapai nilai yang deterministik.
DAFTAR PUSTAKA
[1] AFDX/ARINC664 Switch Testing,Jerman,AIM GmbH
-
31
[2] AFDX Tutorial(Mei 2005), Condor Engineering, Inc
[3] AFDX Training(Maret 2010),Jerman,AIM GmbH
[4] AIRLINES ELECTRONIC ENGINEERING COMMITTEE, "AIRCRAFT
DATA NETWORK PART 7 AVIONICS FULL DUPLEX SWITCHED
ETHERNET (AFDX) NETWORK," in ARINC SPECIFICATION 664,
Maryland, AERONAUTICAL RADIO, INC., 2005
[5] Fan,Sui. Comparison between ADN (Aircraft Data Network) and
Internet world.
Department of Electronics Engineer ,Beijing University of Posts
and
Telecommunications
[6] Gurjar,Shyoram.Lakshmi,B.Optimal Scheduling Policy for
Jitter Control in
AFDX End-System.India.National Institute of Technology
[7] Gutierrez,J.Javier.2011.AFDX networks.Computer and
Real-Time
Group.University of Cantabria
[8] http://wiki.openwrt.org/doc/start diakses pada (02-011-2014)
pukul 20.15
[9] Land,Ian. Elliot, Jeff.2009. Architecting ARINC 664, Part 7
(AFDX) Solutions.
[10] Risso, F., Degioanni, L. An Architecture for High
Performance Network Analysis, Proceeding of the 6th IEEE Symposium
on Computers and Communications, July 2001
[11] Sriadi,Bambang.2009,Sistem waktu nyata, teori dan
implementasinya dalam
Bahasa C dan Ada.Penerbit Informatika
[12] Serdinc,Emre.2010,Soft AFDX End System Implementation With
Standar PC
and Ethernet Card.Middle East Technical University
[13] Tso,Philip.Galaviz,Pete.Improved Aircraft Readiness
Through
COTS.Prospective Computer Analyst,Inc.
[14] Xiao Y., Li, L., Wen, J. Network Program Architecture Based
Winpcap and Sock, Ordnance Industry Automation, Vol.24 Issue 5,
Pages: 49-50, 2005
[15] Zhao X., Li X. Methods of Capturing Network Packets,
Application of Computers, Vol.21Issue 8, Pages: 242-243, 2004