Implementasi Full Duplex Switched Ethernet Pada Aircraft Data Netwok Berbasis Cots Embedded Device

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


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,


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!


4.1.2 Frame Filtering & Traffic Policing Validity pada ChronOS .......... Error!


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!


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


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


Arrived

Packet

Arrived

Valid


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


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


Arrived

Packet

Arrived

Valid


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


Arrived

Packet

Arrived

Valid


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

Documents

Implementasi Full Duplex Switched Ethernet Pada Aircraft Data Netwok Berbasis Cots Embedded Device