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

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

Pembimbing 2

Endro Ariyanto,ST.MT
NIP: 04660316-1

Catur Wirawan Wijiutomo,ST,MT

NIP:

ii

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

iii

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

iv

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

KATA PENGANTAR

vi

UCAPAN TERIMA KASIH

vii

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
viii

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

ix

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

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

xi

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.

xii

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.
1

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

1.
2.
3.
4.

Batasan masalah pada tugas akhir ini meliputi :

Standar spesifikasi yang dijadikan acuan adalah ARINC 664.
Media pengkabelan yang digunakan adalah kabel UTP dengan bandwidth
maksimal 100Mb/s
Bagian dari sistem yang ditangani penulis adalah Full Duplex Switched
Ethernet yang dibangun berbasis embedded device menggunakan Linux
Pengujian tidak mencakup performansi Redundancy Management serta
Scheduling system, sehingga scheduling default yang digunakan adalah First
In First Out (FIFO).

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.

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.

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 Part 2 Part 3 Part 4 Part 5 Part 6 Part 7 Part 8 -

Systems Concepts and Overview

Ethernet Physical and Data Link Layer Specifications
Internet-based Protocols and Services
Internet-based Address Structures and Assigned Numbers
Network Interconnection Services and Functional Elements
Reserved
Avionics Full Duplex Switched Ethernet (AFDX) Network
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.

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 pointto-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 EndSystem 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.

Gambar 2.2.Topologi AFDX pada pesawat A380 (Airbus)[5]

Gambar 2.2.Infrastruktur jaringan pada pesawat terbang[5]

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 masingmasing 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]

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 :
9

Tj
= (8 x M) / Nbw + Tmin_gap
Latency untuk frame pertama:
La
= Ts + Tm1 + Tsw + ( 8 x M )/Nbw + Tm2 + Tr
Latency untuk delayed frame:
Lb
= La + Tj
dengan:
Tsw
Tmi
M
Nbw
Tmin_gap
Tj

(2.1)
(2.2)

= hardware latency pada switch, dalam detik

= message timing (length / bandwidth)
= ukuran frame dalam octets
= media bandwidth, dalam bits/s
= minimum inter-frame gap, dalam detik
= 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]

10

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]

11

Aci
Lmax

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

1000

= 400 * 8 *

64

(2.4)

= 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)

MaxJitter 500 s
12

(2.5)

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
Dimana Technological Latency pada sistem = 150ms

13

(2.6)

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].

14

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].

15

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 ff ing dengan sesi l ainnya .
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].

16

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.

17

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

18

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.

19

3.3. Diagram Alur Sistem

No

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

20

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
Lmax
Max Jitter
Max Latency
Lmin
Bandwidth
Jumlah frame dikirim
Validitas frame

Nilai yang didefinisikan

1518 byte
500 Mikroseconds
150 Milliseconds
64 byte
100000 bit/s
10 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.

21

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

Multicast

ES A

ES B & ES C

01

Unicast

ES B

ES A

02

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

22

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

23

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 masingmasing 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 Source Destination Virtual Arrived Hasil Yang

Hasil
Validitas
Number
End
End
Link
Packet Diharapkan
Uji
System
System
ID
Size
1
ES A
ES B
01
100
Packet
Packet
Valid
Arrived
Arrived
2
ESA
ES C
01
100
Packet
Packet
Valid
Arrived
Arrived
3
ES B
ES A
02
100
Packet
Packet
Valid
Arrived
Arrived
4
ES C
ES B
03
80
Packet
Packet
Valid
Arrived
Arrived
5
ES A
ES C
01
80
Packet
Packet
Valid
Arrived
Arrived
6
ES A
ES B
01
80
Packet
Packet
Valid
Arrived
Arrived
7
ES B
ES C
64
Packet
Packet
Valid
Dropped
Dropped
8
ES C
ES A
64
Packet
Packet
Valid
Dropped
Dropped
9
ES A
ES B
01
64
Packet
Packet
Valid
Arrived
Arrived
10
ES A
ES C
01
40
Packet
Packet
Invalid
Dropped
Arrived
% Validity
90%

24

4.1.2 1 Frame Filtering & Traffic Policing Validity pada ChronOS

Tabel 4.2 Hasil uji Frame Filtering & Traffic Policing Validity pada ChronOS

Packet Source Destination Virtual Arrived Hasil Yang

Hasil
Validitas
Number
End
End
Link
Packet Diharapkan
Uji
System
System
ID
Size
1
ES A
ES B
01
100
Packet
Packet
Valid
Arrived
Arrived
2
ESA
ES C
01
100
Packet
Packet
Valid
Arrived
Arrived
3
ES B
ES A
02
100
Packet
Packet
Valid
Arrived
Arrived
4
ES C
ES B
03
80
Packet
Packet
Valid
Arrived
Arrived
5
ES A
ES C
01
80
Packet
Packet
Valid
Arrived
Arrived
6
ES A
ES B
01
80
Packet
Packet
Valid
Arrived
Arrived
7
ES B
ES C
64
Packet
Packet
Valid
Dropped
Dropped
8
ES C
ES A
64
Packet
Packet
Valid
Dropped
Dropped
9
ES A
ES B
01
64
Packet
Packet
Valid
Arrived
Arrived
10
ES A
ES C
01
40
Packet
Packet
Invalid
Dropped
Arrived
% 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

25

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)

1436111914.478907000

0.00005

1436111914.478956000

0.00003

1436111914.478980000

0.00002

1436111914.479002000

0.00002

1436111914.479024000

0.00002

1436111914.479046000

0.00002

1436111914.479068000

0.00002

1436111914.479089000

0.00003

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

26

Packet Number

Packet Sent
Epoch Time

Latency i = (Sent time i (Sent time

i-1))
(seconds)

1436111921.432960

0.0000100

1436111921.432970

0.0000100

1436111921.432980

0.0000099

1436111921.433060

0.0000100

1436111921.433060

0.0000100

1436111921.433060

0.0000200

1436111921.433060

0.0000301

1436111921.433140

0.0000100

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
27

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 =

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)

1436111914.478907000 1436111921.432962000

6.954060078

1436111914.478956000 1436111921.432975000

6.954020023

1436111914.478980000 1436111921.432976000

6.953989983

1436111914.479002000 1436111921.433064000

6.954059839

1436111914.479024000 1436111921.433068000

6.954039812

1436111914.479046000 1436111921.433068000

6.954020023

1436111914.479068000 1436111921.433069000

6.953999996

1436111914.479089000 1436111921.433150000

6.954070091

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.9540200236.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

28

Packet
Number

Packet Sent
Epoch Time

Packet Arrival Epoch

Time

Delay
(seconds)

1436112914.48890

1436112921.42290

6.93400

1436112914.48895

1436112921.44294

6.95399

1436112914.48898

1436112921.44296

6.95398

1436112914.48900

1436112921.44304

6.95404

1436112914.48902

1436112921.44304

6.95402

1436112914.48904

1436112921.44306

6.95402

1436112914.48906

1436112921.44306

6.95400

1436112914.48908

1436112921.44318

6.95410

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.954076.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
29

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
30

[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
Group.University of Cantabria

networks.Computer

and

Real-Time

[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
COTS.Prospective Computer Analyst,Inc.

Readiness

Through

[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

31