Full Text 01

Institutionen för datavetenskap
Department of Computer and Information Science
Final thesis
Usage of databases in ARINC 653-compatible

real-time systems
by
Martin Fri
Jon Börjesson
LIU-IDA/LITH-EX-A—10/010--SE
2010-05-10
Linköpings universitet Linköpings universitet

SE-581 83 Linköping, Sweden 581 83 Linköping
Linköping University
Final Thesis
Usage of databases in ARINC 653-compatible

real-time systems
by
Martin Fri
Jon Börjesson
LIU-IDA/LITH-EX-A—10/010--SE
2010-05-10
Supervisor: Magnus Vesterlund

Saab Aerosystems
Examiner: Professor Simin Nadjm-Tehrani
Linköping University
Abstract
The Integrated Modular Avionics architecture , IMA, provides means for run-
ning multiple safety-critical applications on the same hardware. ARINC 653 is a
specification for this kind of architecture. It is a specification for space and time
partition in safety-critical real-time operating systems to ensure each applica-
tion’s integrity. This Master thesis describes how databases can be implemented
and used in an ARINC 653 system. The addressed issues are interpartition
communication, deadlocks and database storage. Two alternative embedded
databases are integrated in an IMA system to be accessed from multiple clients
from different partitions. Performance benchmarking was used to study the dif-
ferences in terms of throughput, number of simultaneous clients, and scheduling.
Databases implemented and benchmarked are SQLite and Raima. The studies
indicated a clear speed advantage in favor of SQLite, when Raima was integrated
using the ODBC interface. Both databases perform quite well and seem to be
good enough for usage in embedded systems. However, since neither SQLite
or Raima have any real-time support, their usage in safety-critical systems are
limited. The testing was performed in a simulated environment which makes
the results somewhat unreliable. To validate the benchmark results, further
studies must be performed, preferably in a real target environment.
Keywords : ARINC 653, INTEGRATED MODULAR AVIONICS, EM-
BEDDED DATABASES, SAFETY-CRITICAL, REAL-TIME OPERATING
SYSTEM, VXWORKS
Contents
1 Introduction 7
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Problem description . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Document structure . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Background 10
2.1 Safety-critical airplane systems . . . . . . . . . . . . . . . . . . . 10
2.1.1 DO-178B . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Avionics architecture . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Federated architecture . . . . . . . . . . . . . . . . . . . . 12
2.2.2 IMA architecture . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 ARINC 653 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Part 1 - Required Services . . . . . . . . . . . . . . . . . . 14
2.3.2 Part 2 and 3 - Extended Services and Test Compliance . . 18
2.4 VxWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1 Configuration and building . . . . . . . . . . . . . . . . . 19
2.4.2 Configuration record . . . . . . . . . . . . . . . . . . . . . 19
2.4.3 System image . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.4 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.5 Partitions and partition OSes . . . . . . . . . . . . . . . . 21
2.4.6 Port protocol . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.7 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.1 ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.3 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.4 Mimer SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.5 Raima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 System design and implementation 26

3.1 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 Interpartition communication design . . . . . . . . . . . . 28
3.2 Database modules . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Client version . . . . . . . . . . . . . . . . . . . . . . . . . 29
1
CONTENTS
3.2.2 Server version . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.3 Server and Client interaction - Protocol . . . . . . . . . . 33
3.3 Transmission module . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 Transmission protocol . . . . . . . . . . . . . . . . . . . . 38
3.4 Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.1 Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.2 SQLite specific . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.3 RAIMA specific . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 Database adapters . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5.2 SQLite adapter . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5.3 Raima adapter . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.4 Query result . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Benchmarking 46
4.1 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.1 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.2 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.3 Measurement . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Benchmark graphs . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.1 SQLite Insert . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.2 SQLite task scheduling . . . . . . . . . . . . . . . . . . . . 50
4.2.3 SQLite select . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.4 Raima select . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Benchmark graphs analysis . . . . . . . . . . . . . . . . . . . . . 53
4.3.1 Deviation . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.2 Average calculation issues . . . . . . . . . . . . . . . . . . 53
4.3.3 Five clients top . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.4 Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5 Comparisons between SQLite and Raima 56

5.1 Insert performance . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2 Update performance . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3 Select performance . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4 No primary key . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.5 Task scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.6 Response sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6 Discussion and Conclusion 64

6.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.1.1 Database comparison . . . . . . . . . . . . . . . . . . . . 64
6.1.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.1.3 Measurement issues . . . . . . . . . . . . . . . . . . . . . 65
6.2 Design and implementation . . . . . . . . . . . . . . . . . . . . . 65
6.3 Usage and Certification . . . . . . . . . . . . . . . . . . . . . . . 66
6.4 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.5 Final words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2
CONTENTS
A Benchmark graphs 70
A.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.2 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.2.1 Insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.2.2 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.2.3 Select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.2.4 Alternate task scheduling . . . . . . . . . . . . . . . . . . 80
A.2.5 No primary key . . . . . . . . . . . . . . . . . . . . . . . . 82
A.2.6 Large response sizes . . . . . . . . . . . . . . . . . . . . . 85
A.3 Raima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.3.1 Insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.3.2 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.3.3 Select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.3.4 Alternate task scheduling . . . . . . . . . . . . . . . . . . 97
A.3.5 No primary key . . . . . . . . . . . . . . . . . . . . . . . . 99
A.3.6 Large response sizes . . . . . . . . . . . . . . . . . . . . . 102
3
List of Figures
1.1 An ARINC 653 system. . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 A federated architecture and an Integrated Modular Avionics ar-

chitecture. [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 One cycle using the round robin partition scheduling. [6] . . . . . 15
2.3 VxWorks memory allocation example. [11] . . . . . . . . . . . . . 20
3.1 System design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Channel design used in this system. . . . . . . . . . . . . . . . . 28
3.3 Statement, connection and environment relations. . . . . . . . . . 30
3.4 Flowchart describing the SQLFetch routine. . . . . . . . . . . . . 31
3.5 Flowchart of a task in the database server module. . . . . . . . . 36
3.6 A connection deadlock caused by Sender Block port protocol. . . 40
3.7 Filesystem structure. . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Average inserts processed during one timeslot for different num-
ber of client partitions. . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Average number of inserts processed during one timeslot of vari-
ous length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Average selects processed during one timeslot for different num-
bers of client partitions and timeslot lengths. Task scheduling
used is Yield only. . . . . . . . . . . . . . . . . . . . . . . . . . . 50
bers of client partitions. . . . . . . . . . . . . . . . . . . . . . . . 51
ber of client partitions. The lines represent the average processed
queries using different timeslot lengths. . . . . . . . . . . . . . . . 52
4.6 With one client, the server manages to process all 1024 queries
in one time frame. . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 With two clients, the server cannot process 2*1024 in two times-
lots due to context switches. An extra time frame is required. . 54
4.8 The average processing speed is faster than 1024 queries per
timeslot, but it is not fast enought to earn an entire timeslot. . . 54
5.1 Comparison between average insert values in SQLite and Raima.

Timeslots used in the graphs are 50 ms and 100ms. . . . . . . . 57
5.2 Comparison between average update values in SQLite and Raima.
Timeslot lengths are 50 ms and 100 ms. . . . . . . . . . . . . . . 58
4
LIST OF FIGURES
5.3 Comparison between average select values in SQLite and Raima.

Timeslot lengths are 50 ms and 100 ms. . . . . . . . . . . . . . . 59
5.4 Comparison between average select values in SQLite and Raima
with and without primary key. Timeslot length is 50 ms. . . . . . 60
5.5 Comparison between average select queries using different task
schedules in SQLite and Raima. Timeslot length is 50 ms. . . . . 61
5.6 Comparison between average selects with and without sorting in
SQLite and Raima. The resulting rowsets are of size 128 rows
and timeslot length is 50 ms. . . . . . . . . . . . . . . . . . . . . 62
5.7 Comparison between single row select and 128 rows select queries
in SQLite and Raima. Average values are showed in the graph
with timeslot length of 50 ms. . . . . . . . . . . . . . . . . . . . . 62
A.1 Average inserts processed during one timeslot for different num-
ber of client partitions. . . . . . . . . . . . . . . . . . . . . . . . 71
A.2 Average no. inserts processed during one timeslot of various
length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.3 Maximum inserts processed during one timeslot for different num-
A.4 Maximum inserts processed for various timeslot lengths. . . . . . 73
A.5 Average updates processed during one timeslot for different num-
ber of client partitions. . . . . . . . . . . . . . . . . . . . . . . . 74
A.6 Average no. updates processed during one timeslot of various
length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.7 Maximum updates processed during one timeslot for different
number of client partitions. . . . . . . . . . . . . . . . . . . . . . 76
A.8 Maximum updates processed for various timeslot lengths. . . . . 76
A.9 Average selects processed during one timeslot for different num-
A.10 Average no. selects processed during one timeslot of various
length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.11 Maximum selects processed during one timeslot for different num-
A.12 Maximum no. selects processed during one timeslot of various
length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
bers of client partitions and timeslot lengths. . . . . . . . . . . . 80
A.16 Average no. selects processed during one timeslot of various length. 83
A.18 Maximum no. selects processed during one timeslot of various
length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.19 Average and maximum processed select queries. These selects
ask for128 rows. No sorting is applied. . . . . . . . . . . . . . . . 85
5
A.20 Average and maximum processed selects are displayed. Each
query asks for a 128 rows response. Results are sorted in an
ascending order by an unindexed column. . . . . . . . . . . . . . 86
A.21 Average inserts processed during one timeslot for different num-
A.22 Average inserts processed for various timeslot lengths. . . . . . . 88
A.23 Maximum inserts processed during one timeslot for different num-
A.24 Maximum inserts processed for various timeslot lengths. . . . . . 89
A.25 Average number of updates processed during one timeslot for
different number of client partitions. . . . . . . . . . . . . . . . . 90
A.26 Average number of updates processed for various timeslot lengths.
91
A.27 Maximum updates processed during one timeslot for different
number of client partitions. . . . . . . . . . . . . . . . . . . . . . 92
A.28 Maximum updates processed for various timeslot lengths. . . . . 93
A.30 Average selects for various timeslot lengths. . . . . . . . . . . . . 95
A.32 Maximum selects processed for various timeslot lengths. . . . . 96
ber of client partitions. The lines represent the maximum pro-
cessed queries using different timeslot lengths. . . . . . . . . . . . 98
ber of client partitions. No primary key is used. . . . . . . . . . . 99
A.36 Average selects processed for various timeslot lengths. No pri-
mary key is used. . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
ber of client partitions. No primary key is used. . . . . . . . . . . 101
A.38 Maximum select processed for various timeslot lengths. No pri-
mary key is used. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
query asks for 128 rows. . . . . . . . . . . . . . . . . . . . . . . . 102
query asks for 128. Results are sorted in an ascending order by
an non-indexed column. . . . . . . . . . . . . . . . . . . . . . . . 103
Chapter 1
Introduction
This document is a Master thesis report conducted by two final year Computer
science and Engineering students. It corresponds to 60 ECTS, 30 ECTS each.
The work has been carried out at Saab Aerosystems Linköping and examined
at Department of Computer & Information science at Linköping University.
The report starts with a description of the thesis and some background
information. Following this, the system design and work results are described.
Finally, the document ends with an analysis, and a discussion and conclusion
section.
1.1 Background
Safety-critical aircraft systems often run on a single computer to prevent mem-
ory inconsistency and to ensure that real-time deadlines are held. If multiple
applications are used on the same hardware they may affect each other’s mem-
ory or time constraints. However, a need for multiple applications to share
hardware has arisen. This is mostly due to the fact that modern aircrafts are
full of electronics; no space is left for new systems. One solution to this prob-
lem is to use an Integrated Modular Avionics, IMA, architecture. The IMA
architecture provides means for running multiple safety-critical applications on
the same hardware. The usage of Integrated Modular Avionics is an increasing
trend in most aircraft manufacturers and Saab Aerosystems is no exception.
ARINC 653 is a software specification for space and time partitioning in
the IMA architecture. Each application is run inside its own partition which
isolates it from other applications. Real-time operating systems implementing
this standard will be able to cope with the memory and real-time constraints.
This increases the flexibility but also introduces problems such as how to com-
municate between partitions and how the partition scheduling will influence the
design. A brief overview of an ARINC 653-system can be seen in figure 1.1.
1.2 Purpose
As described in the previous section the trend of avionics software has shifted
towards Integrated Modular Avionics systems. ARINC 653 is a specification for
this kind of systems and is used in many modern aircrafts [8]. Saab is interested
7
CHAPTER 1. INTRODUCTION
App 1 App 2 App 3 DB

partition partition partition partition
RTOS (ARINC 653)
Hardware
Figure 1.1: An ARINC 653 system.
in knowing how databases can be used for sharing data among partitions of an
ARINC 653-system. Therefore the purpose of this master thesis is to imple-
ment different databases in an ARINC 653-compliant system and study their
behavior.
1.3 Problem description

This thesis will study how can databases be embedded in an ARINC 653-
environment. Saab Aerosystems has not previously used databases together
with ARINC 653 and now wants to know what such a system is capable of.
There will be multiple applications of various safety-criticality levels that may
want to use the database services. The database in itself would not contain
safety-critical data. The problem to solve is how to implement databases in
an ARINC 653-compliant system and how to make them communicate with
applications.
Important aspects to consider are design and configuration for efficient database
usage, performance implications and usefulness of this kind of ARINC 653-
system.
1.3.1 Objectives
Goals and objectives for this master thesis:
• Port and integrate alternative databases within an ARINC 653-partition.
• Implement a database API for communication between the applications

and the database, that will hide the ARINC-layer from the application
and the database.
• Find the system’s performance thresholds according to throughput, num-

ber of simultaneous clients and scheduling. Then evaluate the use of
databases in an ARINC 653-system.
1.3.2 Method
The workload will be divided into two parts since there are two participating
students in this thesis.
8
CHAPTER 1. INTRODUCTION
Martin’s part is focused towards ARINC 653 and the interpartition com-
munication. The goals for this part is to abstract the underlying ARINC 653
layer and provide a database API to an application developer. The application
developer shall not notice that the system is partitioned, he/she should be able
to use the database as usual. This part is responsible for the communication
between the application and the database.
Jon’s part is to study databases and how to port them to the ARINC 653
system. This includes to choose two databases and motivate the choices. One
of the databases shall be an open source database. The goals of Jon’s part is to
port the chosen databases and make them work in an ARINC 653-compatible
real-time operating system. This requires for instance an implementation of a
file system and one database adapter per database.
Testing and benchmarking of the implemented system has been done by both
Martin and Jon.
1.3.3 Limitations
Limitations for this project are:
• VxWorks shall be the ARINC 653-compatible real-time operating system.
Saab already uses this operating system in some of their projects.
• The implementation will primarily be tested in a simulated environment.

Tests in a target environment are subject to additional time.
1.4 Document structure

A short description of the document structure is provide below.
Chapter 1 Contains an introduction to the master thesis.
Chapter 2 Essential background information needed to understand the thesis.
Chapter 3 The design of the implemented system is described here.
Chapter 4 Contains benchmarking graphs and their analyses.
Chapter 5 Contains a comparison between chosen databases.
Chapter 5 Contains discussions and conclusions about the thesis result.
9
Chapter 2
Background
This section will provide the reader with essential background information.
2.1 Safety-critical airplane systems

Systems embedded in airplanes are safety-critical software. A software failure
in such a system can cause minor to catastrophic events.
When developing safety critical software for aircrafts, there are some special
issues that arises. Since aircraft software is a type of embedded system there are
limitations on the memory available. This causes the developer to use special
techniques to ensure that memory boundaries are not overflowed.
Aircraft software is often also safety-critical real-time systems; in theses
systems timing and reliability are large concerns. First, deadlines for important
tasks should never be missed. This forces the system to have some kind of
scheduling that ensures that deadlines are not overrun. Secondly, safety-critical
real-time systems must be reliable. It would not do if for example an aircraft or
a respirator suddenly stopped working. This issue leads to strict requirements
on not only the software but also the hardware. Hardware available for this kind
of systems must be closely monitored and tested before they are allowed to be
used. These requirements leads to that the hardware available are many years
old and have poor performance compared to the modern, high performance
hardware. [3] [5] [7]
2.1.1 DO-178B
DO-178B, Software Considerations in Airborne Systems and Equipment Cer-
tification, is an industry accepted guidance about how to satisfy airworthiness
of aircrafts. It focuses only on the software engineering methods and processes
used when developing aircraft software and nothing on the actual result. This
means that if an airplane is certified with DO-178B, you know that the devel-
oping process for developing an airworthiness aircraft has been followed, but
you do not really know if the airplane can actually fly. A system with a poor
requirement specification can go thorough the entire product development life
cycle and fulfill all of the DO-178B requirements. However, the only thing you
10
CHAPTER 2. BACKGROUND
know about the result is that it fulfills this poor requirement specification. In
other words, bad input gives bad, but certified output. [3] [5]
Failure categories
Failures in an airborne system can be categorized in five different types according
to the DO-178B document:
Catastrophic A failure that will prevent a continuous safe flight and landing.
Results of a catastrophic failure are multiple fatalities among the occupants and
probably loss of the aircraft.
Hazardous / Severe-Major A failure that would reduce the capabilities

of the aircraft or the ability of the crew to handle more difficult operating
conditions to the extent of:
• Large reduction of safety margins or functional capabilities.
• Physical distress or higher workload such as the crew could not be relied
upon to perform their tasks accurately or completely.
• Increased effects on occupants including seriously or potentially fatal in-

juries to a small number of the occupants.
Major A failure that would reduce the capabilities of the aircraft and the
ability of the crew to do their work to any extent of:
• Reduction of safety margins or functional capabilities.
• Significant increased workload of the crew.
• Possible discomfort of the occupants including injuries.
Minor A failure that would not significantly reduce the aircraft safety and the
crew’s workload are still within their capabilities. Minor failures may include
slight reduction of safety margins and functional capabilities, a slight increase
in workload or some inconvenience for the occupants.
No Effect A failure of this type would not affect the operational capabilities
of the aircraft or increase crew workload. [3] [4]
Software safety levels

Software in airplanes has different safety levels depending on what kind of fail-
ures they can cause. These are according to the DO-178B document:
Level A Software of level A that doesn’t work as intended may cause a failure
of catastrophic type.
Level B Software of level B that doesn’t work as intended may cause a failure
of Hazardous/Severe-Major type.
11
Level C Software of level C that doesn’t work as intended may cause a failure
of Major type.
Level D Software of level D that doesn’t work as intended may cause a failure
of Minor type.
Level E Software of level E that doesn’t work as intended may cause as failure
of No Effect type. [3] [4]
2.2 Avionics architecture

There are two main types of architectures used in aircraft avionics. These are,
the traditionally used federated architecture, and the new Integrated Modular
Avionics architecture. See figure 2.1.
Federated System Integrated Modular Avionics

(IMA)
Flight Mission
Air Data Air Data FMS
Mission computer Management Computer
computer computer
MMU-partitioning Operating System
Bus
Figure 2.1: A federated architecture and an Integrated Modular Avionics architec-

ture. [6]
2.2.1 Federated architecture

Federated architecture is the traditional approach of implementing avionics sys-
tems. This approach uses distributed standalone systems which run on their
own separate hardware. This is a well known approach that has been used for
a long time.
One advantage of a federated architecture is that many experienced develop-
ers are available. These people have worked with this kind of architecture for a
long time and they know where the pitfalls are. Another advantage is that since
each system is separate both hardware and software wise, this leads to easy
verification and validation processes for these systems. This saves the company
a lot of time and money since aircraft certification is extremely expensive.
The disadvantage of this type of architecture is that each standalone system
has a specific function. This requires that each system must be specifically
developed in aspects of hardware and software. Reuse of software and hardware
components are very rare. Federated architectures also require more power
control mechanisms due to the fact that each separate system must have its
own power system. This leads to more electronics leading to a higher power
consumption, and that the weight is increased.
In today’s airplanes weight and space is extremely limited. They are so full
of electronics that it is hard to upgrade with new functionality. This together
12
with the other disadvantages of the federated approach forced the developers to
find a new solution: Integrated Modular Avionics.
Advantages of a federated architecture are:
• Traditionally used
• ”Easy” to certify
Drawbacks of a federated architecture are:
• Hard to reuse software and hardware
• More hardware needed, increases weight and space required
• High power consumption
[5] [7] [8] [9]
2.2.2 IMA architecture

The Integrated Modular Avionics architecture allows multiple applications to
run on a single hardware. This works almost as a regular desktop computer in
which different applications get access to resources like the CPU. The largest
concern with this kind of system is to enforce the memory- and real-time con-
straints. In today’s aircrafts only a few systems are using IMA approaches, but
the trend is going towards more systems designed using this architecture.
One big advantage with IMA architecture is that it is relatively cheap to
make changes to the system. This is because developers are able to design
modular programs and reuse software and hardware components. Compared to
the federated architecture the IMA approach uses hardware a lot more efficiently.
Here, there are multiple software systems sharing the same hardware. This
decreases the amount of hardware needed which also leads to less heat generation
and lower power consumption. Another advantage with IMA architecture is
that specialized developed hardware is not needed. Instead it is possible to
use Commercial Off The Shelf, COTS, products. Since COTS products are
a lot cheaper than specifically developed hardware this possibility makes the
companies more excited about IMA.
However, there are some drawbacks with the IMA architecture. One major
drawback is that the design of IMA system must be quite complex. Complex
systems are tougher to develop and they require more time and experienced
personnel. The personnel issue is another drawback, the IMA architecture is a
quite new way to develop systems and therefore there is a lack of experienced
persons within this area. However, this is already changing fast because more
systems are switching to IMA architectures. Certification is both a drawback
and an advantage. The first certification of a system is expensive due to the
complex nature of IMA systems. But when this has been done and the platform,
which is the real-time operating system, RTOS, and the functions provided by
the module OS, is certified, new modules are easy to certify.
Advantages of an IMA architecture are:
• Effective use of hardware
• Easy to certify new modules
13
• Reuse of software and hardware
• COTS, Commercial of the shelf
Drawbacks of an IMA architecture are:
• Complex design needed

• Complex platform certification
[5] [7] [8] [9]
2.3 ARINC 653

ARINC 653 is a software specification for space and time partitioning in the
IMA architecture. Real-time operating systems implementing this standard
will be able to cope with the memory and real-time constraints. ARINC is an
abbreviation for Aeronautical Radio, Inc which is the company that developed
the standard.
ARINC 653’s general goal is to provide an interface as well as specifying the
API behaviour between the operating system and the application software.
In ARINC 653, applications are run in independent partitions which are
scheduled by the RTOS. Since each application is run independent of other
applications it is possible for the applications to have different safety levels, e.g.
ARINC 653 supports DO-178B level A-E systems on the same processor. For
more information see section 2.1.1. [1] [7]
Specification details The ARINC 653 specification consists of three parts:
• Part 1: Required services
• Part 2: Extended services
• Part 3: Test Compliance
The required services part defines the minimum functionality provided by

the RTOS to the applications. This is considered to be the industry standard
interface. The extended services define optional functionality while the test
compliance part defines how to establish compliance to part 1. [1]
Currently, there is no RTOS that supports all three parts. In fact, no one
even fully supports part 2 or 3. The existing RTOS’s supporting ARINC 653
only supports part 1. Although, some RTOS’s have implemented some services
defined in part 2, extended services, but these solutions are vendor specific and
do not fully comply with the specification. [5]
2.3.1 Part 1 - Required Services

ARINC 653 specification part 1, required services, describes how the most im-
portant core functionality of real-time operating systems should work to comply
with the specification. The system functionality is divided into six categories:
• Partition management
14
• Process management
• Time management
• Memory allocation
• Interpartition communication
• Intrapartition communication
There is also a section about the fault handler called Health Monitor. [1]
Partition management
Partitions are an important part of the ARINC 653 specification. They are used
to separate the memory space of applications so each application has its own
”private” memory space.
Scheduling Partitions are scheduled in a strictly deterministic way, they have

a fixed cyclic schedule maintained by the core OS. A cyclic scheduling works as
a loop, the scheduled parts are repeated in the same way forever as shown in
figure 2.2. The cycle repeating itself is called a major cycle and it is defined as
a multiple of the least common multiple of all partition periods in the module.
Inside the major cycle each partition is assigned to one or more specified times-
lots, called minor frames or minor cycles. No priorities are set to the partitions
as the specified scheduling order cannot change during runtime. It is the system
integrators job to set the order, frequency and length of each partition’s frame.
As frequency implies, a partition can be assigned to more than one frame in
each major cycle. The configuration is loaded during system initialization and
cannot change during runtime.
Partition Partition Partition Partition

#1 #2 #3 #4
Minor Frame #1 Minor Frame #2 Minor Frame #3 Minor Frame #4

200 ms 150 ms 250 ms 200 ms
Major Frame repeat
Time
Figure 2.2: One cycle using the round robin partition scheduling. [6]
Modes A partition can be in four different modes: Idle, normal, coldstart and
warmstart.
IDLE When in this mode, the partition is not initialized and it is not executing
any processes. However, the partition’s assigned timeslots are unchanged.
15
NORMAL All processes have been created and are ready to run.
COLDSTART In this mode, the partition is in the middle of the initialization

process.
WARMSTART In this mode, the partition is in the initialization phase. The

difference between WARMSTART and COLDSTART is that WARM-
START is used when some things in the initialization phase do not need
to be done. E.g. if the RAM memory is still intact after some kind of
failure, the partition will start in WARMSTART mode. [1]
Process management
Inside a partition an application resides which consists of one or more processes.
A process has its own stack, priority, and deadline. The processes in a partition
run concurrently and can be scheduled in both a periodic and an aperiodic way.
It is the partition OS that is responsible for controlling the processes inside
its partition.
States A process can be in four different states: Dormant, Ready, Running

and Waiting.
Dormant Cannot receive resources. Processes are in this state before they are
started and after they have been terminated.
Ready Ready to be executed.
Running The process is assigned to a processor. Only one process can be in

running state at the same time.
Waiting Not allowed to use resources because the process is waiting for an
event. E.g. waiting on a delay.
Scheduling Process scheduling is controlled by the partition operating sys-

tem and is using a priority preemptive scheduling method. Priority preemptive
scheduling means that the controlling OS can at anytime stop the execution of
the current process in favor for a higher prioritized process which is in ready
mode. If two processes have the same priority during a rescheduling event the
scheduler chooses the oldest process in ready mode to be executed.
Time management
Time management is extremely important in ARINC 653 systems. One of the
main points of ARINC 653 is that systems can be constructed so applications
will be able to run before their deadlines. This is possible since partition schedul-
ing is, as already mentioned, time deterministic. A time deterministic scheduling
means that the time each partition will be assigned to a CPU is already known.
This knowledge can be used to predict the system’s behavior and thereby create
systems that will fulfill their deadline requirements. [1]
16
Memory allocation
An application can only use memory in its own partition. This memory alloca-
tion is defined during configuration and initialized during start up. There is no
memory routines specified in the core OS that can be called during runtime. [1]
Interpartition communication
The interpartition communication category contains definitions for how to com-
municate between different partitions in the same core module. Communication
between different core modules and to external devices is also covered.
Interpartition communication is performed by message passing, a message
of finite length is sent from a single source to one or more destinations. This is
done through ports and channels.
Ports and Channels A channel is a logical link between a source and one or
more destinations. The channel also defines the transfer mode of the messages.
To access a channel, partitions need to use ports which work as access points.
Ports can be of source or destination type and they allow partitions to send or
receive messages to/from another partition through the channel. A source port
can be connected to one or more destination ports. Each port has its own buffer
and a message queue which both are of predefined sizes. Data which is larger
then this buffer size must be fragmented before sending and then merged when
receiving.
All channels and all ports must be configured by the system integrator before
execution. It is not possible to change these during runtime.
Transfer modes There are two transfer modes available to chose from when
configuring a channel. They are sampling mode and queuing mode.
Sampling mode In sampling mode, messages are overwritten at the port

buffer which means that only the latest, most up to date, value remains in the
buffer. No queuing is performed in this mode.
The send routine for a sampling port will overwrite the sending port’s buffer
with the new value and then sends the value directly. At the receiving end the
message is copied into the receiving port’s buffer overwriting the previous value.
Queuing mode In queuing mode, messages are stored in a queue at the

port. The size of this queue and its element sizes are configured before execution.
A message sent from the source partition is buffered in the port’s message
queue while waiting to be transmitted by the channel. At the receiving end,
incoming messages are stored in the destination port’s message queue until its
partition receives the message.
Message queues in the queuing mode are following the First In First Out,
FIFO, protocol. This allow ports to indicate overflow occurrences. However,
it is the application’s job to manage the overflow situations and make sure no
messages are lost. [1]
17
Intrapartition communication
Intrapartition communication is about how to communicate within a partition.
This can also be called interprocess communication because it is about how
processes communicate with each other. Mechanisms defined here are buffers,
blackboards, semaphores and events.
Buffers and Blackboards Buffers and Blackboards work like a protected

data area that only one process can access at a give time. Buffers can store
multiple messages in FIFO queues which are configured before execution while
Blackboards have only one spot for messages though have the advantage of
immediate updates. Processes waiting for the buffer or blackboard are queued
in a FIFO or priority order. Overall, buffers and blackboards have quite a lot in
common with the queuing and sampling modes respectively in the interpartition
communication section.
Semaphores and Events Semaphores and events are used for process syn-
chronization. Semaphores control access to shared resources while events coor-
dinate the control flow between processes.
Semaphores in ARINC 653 are counting semaphores and they are used to
control partition resources. The count represents the number of resources avail-
able. A process accessing a resource has to wait on a semaphore before accessing
it and when finished the semaphore must be released. If multiple processes wait
for the same semaphore, they will be queued in FIFO or priority order depending
on the configuration.
Events are used to notify other processes of special occurrences and they
consist of a bi-valued state variable and a set of waiting processes. The state
variable can be either ”up” or ”down”. A process calling the event ”up” will
put all processes in the waiting processes set into the ready mode. A process
calling the event ”down” will be put into the waiting processes set.[1]
Health Monitor
Fault handling in ARINC 653 is performed by an OS function called Health
Monitor(HM). The health monitor is responsible for finding and reporting faults
and failures.
Errors that are found have different levels depending on where they occurred.
The levels are process level, partition level and OS level. Responses and actions
taken are different depending on which error level the failure has and what has
been set in the configuration. [1] [10]
2.3.2 Part 2 and 3 - Extended Services and Test Compli-

ance
Part 2, extended services, contains specifications for:
• File Systems
• Sampling Port Data Structures
• Multiple Module Schedules
18
• Logbook System
• Sampling Port Extensions
• Service Access Points
The only relevant topic among these is file systems. However, this file system
specification will not be used in this master thesis, see 3.4.1 for more information.
[1] [2]
Part 3 of the ARINC 653 specification defines how to test part 1, required
services. This is out of the scope of this master thesis.
2.4 VxWorks
VxWorks 653 is an ARINC 653 compatible real-time operating system. This
section mostly consists of information regarding VxWorks’ configuration. De-
tails below are described in VxWorks 653 Configuration and Build Guide 2.2
[11].
2.4.1 Configuration and building

VxWorks 653’s configuration system is designed to minimize dependencies be-
tween applications, partition OSes and other components. This makes it possi-
ble to certify components separately. The configuration system is also designed
to support incremental building of a module, meaning that the numbers of files
needed to be rebuilt when a change is made are reduced. The configuration
system also facilitates development of different components of the module by
different developers.
2.4.2 Configuration record

A module’s configuration record resides as a record in the part of the module’s
payload. It is read by the core OS at boot time and at run-time to configure
the module.
The configuration record is built as a separate binary file, independent from
other parts of the module. This means that memory and resource information
must be given in the configuration file for the module and that resources are pre-
allocated for each application, shared library and shared data region. Since the
configuration record is a separate component of the module, it can be certified
separately.
2.4.3 System image

When the module parts are linked, the applications and shared libraries must
conform to the allocated resources in the configuration record. After linking
the configuration record binary with all other components, a bootable system
image can be generated.
The build system is made up of makefiles and is designed to support building
of separate components. To be able to link all components together into a system
module file there are two requirements that must be met:
19
• The virtual addresses of shared libraries must be specified. The address

depends on the memory configuration of the core OS, and the size and
address of other shared libraries in the module. To calculate a reasonable
virtual address for each shared library a map of the virtual memory needs
to be created.
• To build applications, stub files for shared libraries used by the applica-
tions must be created. This is done as a part of the shared library build.
2.4.4 Memory
The memory configuration is made up of two parts; the physical memory con-
figuration and the virtual memory configuration. An example of the memory
organization can be seen in figure 2.3.
Physical memory Virtual memory
App-1 App-2
App-2
Blackboard Blackboard
App-1 POS-2
POS-1
App-2 Blackboard
App-1 POS-1
POS-1 POS-2
POS-2 ConfigRecord ConfigRecord ConfigRecord
ConfigRecord
COS COS COS
COS
Rom Ram App-1 App-2
Figure 2.3: VxWorks memory allocation example. [11]
Physical memory
The physical memory is made up of the read-only memory, ROM, and the
random-access memory, RAM.
20
As figure 2.3 illustrates, applications and the core OS consumes more mem-
ory in RAM than in ROM. This is because each application requires additional
memory for the stack and the heap. This also applies to the core OS. Each
application has its own stack and heap, since there is no memory sharing al-
lowed between applications. If an application is using any shared libraries, it
also needs to set aside memory for the libraries’ stacks and heaps. How much
memory each application gets allocated is specified in the configuration record.
Partition OSes, POS, and shared libraries, SL, require no additional space in
RAM. This is because the application that is using the POS/SL is responsible
for the stack and the heap space.
SDR-Blackboard is a shared data region (SDR). It is a memory area set
aside for two or more applications as a place to exchange data.
App-1 and App-2, seen in figure 2.3 are loaded in to separate RAM areas.
They share no memory excepts for the SDR areas.
Virtual memory
Every component, except for the applications, has a fixed, unique address in the
virtual memory. All applications have the same address. This makes it possible
to configure an application as if it is the only application in the system. Each
application exists in a partition, which is a virtual container. The partition
configuration controls which resources that are available to the application.
2.4.5 Partitions and partition OSes

A module consists of a RTOS and partitions. Each partition contains an ap-
plication and a partition OS, POS, in which the application runs. When the
application accesses a shared library or any I/O region, it is done via the POS
which regulates the access. The partition provides the stack and heap space
that is required by the application. It also supplies any shared library code that
the application uses.
There can be multiple POS instances in a module; one instance per partition.
The instances are completely unaware of each other.
Partition OSes are stored in system shared libraries. This is to conserve
resources. If two partitions are running the same POS, they reference the same
system shared library, but must provide their own copy of the read/write parts
of the library to maintain the isolation between partitions. They must also
provide the required stack and heap size for the library to run. A partition can
only access one system shared library. A system shared library can only contain
one POS.
When the POS is built, stub files are created. The stub files are needed when
building applications since they contain routine stubs that the applications link
to. To map the stubs to the POS routines, an entry-point table is created as a
part of the POS. VxWorks resolves the stub calls to the POS routines when the
application is initializing.
vThreads
VxWorks 653 comes with a partition OS called vThreads. vThreads is based
on VxWorks 5.5, and is a multithreading technology. It consists of a kernel and
21
a subset of the libraries supported in VxWorks 5.5. vThreads runs under the
core OS in user mode.
The threads in vThreads are scheduled by the partition scheduler. The core
OS is not involved in this scheduling. To communicate with other vThreads
domains, the threads are making system calls to the core OS.
vThreads get its memory heap from the core OS during startup. The heap
is used by vThreads to manage memory allocations from its objects. This heap
memory is the only memory available for vThreads; it’s unable to access any
other memory. All attempts to access memory outside the given range will be
trapped by the core OS.
2.4.6 Port protocol

The ARINC 653 standard leaves it up to the implementation to specify port
protocols. VxWorks implements two different; sender block and receiver discard.
The sender block protocol means that a message is sent to all destination
ports. When a destination port is full, messages get queued in the source port.
If the source port gets full the application will be blocked at the send command
until the message has been sent or queued. As soon as a full destination port
is emptied a retransmission will occur. Whether the retransmission succeeds or
not depends on the state of all the other destination ports. If any of these ports
are full, the retransmission will fail.
The advantage of using sender block is that it ensures that a message arrives
at the destination. No messages will be lost, as ARINC 653 requires. A draw-
back is that partitions get coupled to each other, meaning that one application
may block all the others.
The other protocol, receiver discard, will drop messages when a destination
port is full. This will avoid one application with a full destination buffer to
block all the others. If all destination ports are full, an overflow flag will be set
to notify the application that the message was lost.
2.4.7 Simulator
VxWorks comes with a simulator. It makes it possible to run VxWorks 653
applications on a host computer. Since it’s a simulator, not an emulator, there
are some limitations compared to the target environment. The simulator’s per-
formance is affected by the host hardware and other software running on it.
The only clock available in the simulator is the host system clock. The simu-
lator’s internal tick counter is updated with either 60 Hz or 100 Hz, which gives
very low resolution measures. 60 Hz implies that partitions can’t be scheduled
with a timeslot shorter than 16 ms. With 100 Hz it’s possible to schedule as
short as 10 ms.
One feature that isn’t available in the simulator is the performance monitor,
which is used for monitoring CPU usage.
2.5 Databases
Today Saab is using their own custom storage solutions in their avionics soft-
ware. They are often specialized for a particular application and not that gen-
22
eral. A more general solution would save both time and money, since it would
be easier to reuse.
This chapter contains information about the databases that have been evalu-
ated for implementation in the system. It also contains some general information
that may be good to know for better understanding of the system implementa-
tion.
2.5.1 ODBC
Open Database Connectivity, ODBC, is an interface specification for accessing
data in databases. It was created by Microsoft to make it easier for companies
to develop Database Management System, DBMS, independent applications.
Applications call functions in the ODBC interface, which are implemented in
DBMS-specific modules called drivers.
ODBC is designed to expose the database capabilities, not supplement them.
This does not mean that just because one is using an ODBC interface to access
a simple database, the database will transform into a fully featured relational
database engine. If the driver is made for a DBMS that does not use SQL, the
developer of the driver must implement at least some minimal SQL functionality.
[17]
2.5.2 MySQL
MySQL is one of the worlds most popular open source databases. It is a high
performance, reliable relational database with a powerful transactional sup-
port. It includes complete ACID (atomicity, consistency, isolation, durability)
transaction support, unlimited row-level locking, and multi-version transaction
support. The latter means that readers never block writers and vice-versa.
The embedded version of MySQL has a small footprint with preserved func-
tionality. It supports stored procedures, triggers, functions, ANSI-standard
SQL and more. Even though MySQL is open-source, the embedded version is
released under a commercial license. [16]
2.5.3 SQLite
SQLite is an open source embedded database that is reliable, small and fast.
These three factors come as a result of the main goal with SQLite - to be a
simple database. One could look at SQLite as a replacement to fopen() and
other filesystem functions, almost like an abstraction of the file system. There
is no need for any configuration or any server to start or stop.
SQLite is serverless. This means that it does not need any communication
between processes. Every process that needs to read or write to the database
opens the database file and reads/writes directly from/to it. One disadvantage
with a serverless database is that it does not allow more complicated and finer
grained locking methods.
SQLite supports in-memory databases. However, it’s not possible to open
a memory database more than once since a new database is created at every
opening. This means that it’s not possible to have two separate sessions to one
memory database.
23
The database is written entirely in ANSI-C, and makes use of a very small
subset of the standard C library. It’s very well tested; with tests that have 100%
branch coverage. The source has over 65.000 lines of code while test code and
test scripts have over 45.000.000 lines of code.
It’s possible to get the source code as a single C file. This makes it very easy
to compile and link into an application. When compiled, SQLite only takes
about 300 kB memory space. To make it even smaller, it’s possible to compile
it without some features to make it as small as 190 kB.
Data storage
All data is stored in a single database file. As long as the file is readable for the
process, SQLite can perform lookups in the database. If the file is writable for
the process, SQLite can store or change things in the database. The database file
format is cross-platform, which means that the database can be moved around
among different hardware and software systems. Many other DBMS require
that the database is dumped and restored when moved to another system.
SQLite is using a manifest typing, not static typing as most other DBMS.
This means that any type of data can be stored in any column, except for an
integer primary key column. The data type is a property of the data value itself.
Records have variable lengths. This means that only the amount of disk
space needed to store data in a record is used. Many other DBMS’ have fixed
length records, which mean that a text column that can store up to 100 bytes,
always takes 100 bytes of disk space.
One thing that is still experimental but could be useful, is that it is possible
to specify which memory allocation routines SQLite should use. This is probably
necessary if one wants to be able to certify a system that is using SQLite.
Locking technique
A single database file can be in five different locking states. To keep track of
the locks, SQLite uses a page of the database file. It uses standard file locks to
lock different bytes in this page. One byte for each locking state. The lock page
is never read or written by the database. In a POSIX system setting locks is
done via fcntl() calls.[13]
2.5.4 Mimer SQL

Mimer SQL is a relational database manager system from Mimer Information
Technology AB.
Mimer SQL is a SQL database with full SQL support, transactions, triggers
etc. There is an embedded version of Mimer, with native VxWork-support.
The highly performance-optimized storage mechanism ensures that no man-
ual reorganization of the database is ever needed.
In Mimer, a transaction is an atomic operation. Since Mimer uses optimistic
concurrency control, OCC, deadlocks never occur in the database. Change
requests are stored in a write-set during the build-up phase of the transaction.
The build-up phase is when all database operations are requested. During this
phase the changes in the write-set is hidden from other users of the system. The
changes will be visible to the other users after a successful commit. Besides the
24
write-set, there is a read-set. It records the state of the database with intended
changes. If there is a conflict between the database state and the read-set, a
rollback will be performed and the conflict is reported. This could happen e.g.
if one user deletes a row that is to be updated by another user. It’s up to the
application how to handle this. [14]
2.5.5 Raima
Raima is designed to be an embedded database. It has support for both in-
memory and on-disk storage. It also has native support for VxWorks, and
should therefore needs less effort to get up and running in VxWorks 653. It is
widely used, among others is the aircraft vendor Boeing.
Raima has both an SQL API and a native C API. The SQL API conforms
to a subset of ODBC 3.5.
Raima uses a data definition language, DDL, to specify the database design.
Each database needs its own DDL file. The DDL file is parsed with a command
line tool that generates a database file and a C header file. The header file
contains C struct definitions for the database records defined in the DDL and
constants for the field names. These structs and constants are used with Raima’s
C API. The DDL parsing tool also generates index files for keys. Each index
file must be specified in the DDL.
There are two types of DDL in Raima. One which has a C like syntax,
DDL, and one with a SQL like syntax, SDDL. Both types must be parsed by
a special tool. Its not possible to create databases or tables during runtime
with SQL queries. Fortunately, its possible to link Raima’s DDL/SDDL parsers
into applications. This allows creation of DDL/SDDL files during runtime, that
could be parsed by the linked code.
Raima is storing data in fixed length records. This is not per table basis,
but file basis. If there are multiple tables in the same file, the record size will
be the size of the biggest record needed by any of the tables. This means that
there may be a lot of space wasted, but it should result in better performance.
[15]
25
Chapter 3
System design and

implementation
In this chapter an experimental system is described, whose purposes are to ab-

stract ARINC 653 and make a database available for applications. The database
can easily be replaced by another database without modifications to the rest of
the system. This system is later benchmarked to find different thresholds, see
chapter 4.
3.1 Architecture overview

The system is based on a three layered architecture. Layer one consists of the
transmission module and is responsible for transmitting data between ARINC
653-partitions. Layer two includes two database modules. The purpose of these
modules are to transfer queries and results back and forth between each other.
Layer three consists of the actual database, a database adapter and client ap-
plications. See figure 3.1 for a system overview.
Below these three layers, the ARINC 653-compatible real-time operating
system resides. This can be seen as a separate layer.
• Layer 3 - Applications executing routines, database adapter providing

functionality to lower layer.
• Layer 2 - Database API, Query/Result transport protocol.
• Layer 1 - Interpartition communication.
• ”Layer 0” - RTOS, handled by VxWorks.
Clients and Servers A partition containing a transmission module, database

client module and an application is called a client. A partition containing a
transmission module, database server module, database adapter and a database
is called a server.
This implementation is able to handle multiple clients which use one or more
servers. However, the main configuration is for one server partition and multiple
client partitions.
26
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
Partition scheduling Both client and server partitions are scheduled with
a cyclic schedule that resembles round robin, i.e. all timeslots are of the same
length and each partition has only one timeslot per major cycle. See Partition
Management in section 2.3.1 for more information about partition scheduling
in ARINC 653.
Database partition Application partition
Adapter
Application
Database
Database module (server) Database module (client)
Transmission module Transmission module
RTOS (ARINC 653)
Figure 3.1: System design.
27
3.1.1 Interpartition communication design

Partitions communicate with each other through ports and channels. This sec-
tion describes the channel design for this implementation.
In this design, each client partition has one outgoing and one ingoing channel
connected to the database partition. This means that between a database and
a client application, the ingoing / outgoing pair of channels are exclusively used
for just this connection. See figure 3.2.
Figure 3.2: Channel design used in this system.
The benefit with this design is the application independence. E.g. if one
port buffer is overflowed, only this port’s connection will be affected. The other
connections can still continue to function. Another benefit is that the server will
know which client sent a message. This is because all channels are configured
before the system is run.
The drawback with this approach is that it requires many ports and channels
to be configured which requires a lot of memory.
28
3.2 Database modules

There are two different database modules. One is for client partitions and
provide a database API to applications. The other one is for server partitions,
and handle the database adapter connections.
3.2.1 Client version

The client version of the database modules is responsible for providing a database
API to the application developer. The routines can be used to interact with the
database, e.g. send and receive queries and results.
Database API
The database API follows the ODBC standard interface. However, not all rou-
tines specified in the ODBC interface are implemented, only a subset of the
ODBC routines that provide enough functionality to get the system to work.
The names and short descriptions of the implemented routines are listed in
table 3.1.
SQLAllocHandle Allocate handle of type: environment, connection or statement.

SQLFreeHandle Free specified handle.
SQLConnect Connect to specified database.
SQLDisconnect Disconnect from database.
SQLExecDirect Execute a query in connected database.
SQLFetch Move results from queries into bound columns.
SQLBindCol Bind buffers to database columns.
SQLNumResultCols Get the number of columns in result data set.
SQLRowCount Get the number of rows in result data set.
SQLEndTran End transaction. A new transaction begins automatically.
Table 3.1: Database API
Design
ODBC specifies three different datatypes. They are as follows:
Statements Contains a query and when returned, the result of

the query.
Connections Every connection contains handles to the ports asso-
ciated with this connection. It also holds all state-
ment handles used by this connection.
Environments Contains port names and all connections operating
on these ports.
See figure 3.3 for information about how these data types relate to each
other.
Before a query could be sent, an environment must be created. Inside this
environment multiple connections can be created. And inside every connection,
29
* 1 * 1
«datatype» «datatype» «datatype»
Statement Connection Environment
1 1 1 1
Figure 3.3: Statement, connection and environment relations.
multiple statements can be created. A statement will contain the query and,
when the response comes from the server, a rowset.
Send queries When a statement has been created, it can be loaded with a
query and then sent by calling function SQLExecDirect with the specific state-
ment as a parameter.
Efficiency would be greatly diminished if the execute/send routine would be
of a ”blocking” type, i.e. the execution would halt while waiting for a response
to return. If this was the case, every client would only be able to execute one
query per timeslot. This is due to the fact that a query answer cannot be
returned to the sender application before the query has been executed in the
database. The database partition must therefore be assigned to the CPU and
process the query before a response can be sent back. Since the partitions are
scheduled with a round robin scheduling with only one timeslot per partition,
the sender application will get the response at earliest at its next scheduled
timeslot.
Our design does not use a ”blocking” execute. Instead it works as ODBC
describes and passes a handle to the execute routine which sends the query and
then continue its execution. The handle is later needed by the fetch/receive
routine for knowing which answer should be fetched. This approach supports
multiple sent queries during one timeslot. However, the fetch routine gets a bit
more complicated.
Receive results To receive results from an executed query, SQLFetch must

be called, see figure 3.4 for a SQLFetch flowchart. It is the SQLFetch routine
that moves responses into statements where they are available for the user. More
precisely, when SQLFetch is called with a specific statement handle, the client
receives data from the in port belonging to the current connection. The data is
then merged and converted into a result which is matched towards the specified
statement. If there isn’t a match, the routine moves the result’s data into the
correct statement. This is possible since the result knows which statement it
belong to. In this way, a later SQLFetch might not need to receive any data
since its result is already stored in the right statement. The above operations
are repeated until a matching result is found. When this happens, the result
is moved into the specified statement. The data is then moved into the bound
30
buffers before the routine exit.

SQLFetch is
called with a
specific statement
pointer
Receive and
merge messages
to get one result
from the inport
Move result into the

'RHVWKHUHVXOW¶VLGPDWFKWKH statement which the
NO
VSHFLILHGVWDWHPHQW¶VLG? UHVXOWV¶VWDWHPHQW
pointer points to
YES
Move the result into

the specified
Statement and then
move the result to the
bound columns
Exit SQLFetch
Figure 3.4: Flowchart describing the SQLFetch routine.
A short summary : All queries with results stored earlier in the inport queue,
in front of the matching query, will get their results moved into their statements
for faster access in the future. The result belonging to the specified query is
moved into the statement’s bound columns and are made available for layer
three applications. All queries who have their result stored behind the specified
query in the inport queue will not get their result moved into their statements.
These results have to stay in the port queue until another SQLFetch routine is
called in which these operations are repeated.
Analysis of design choices As mentioned in the previous paragraph, all

data in front of the fetch routine’s specified statement in the port are moved to
the statements to which they belong at once. The SQLFetch routine wants the
result of a specific query, and to get that result the system must go through all
data which is located in front of this result. The unwanted data can’t just be
destroyed since there is another statement waiting for just this data. Therefore
the read unwanted data is moved into its statement before the routine continues.
One drawback with locally stored results in statements is that there is a
possibility of memory issues. These can occur when there are many statements
and each of them contains a large rowset as a result.
An alternative solution is to discard unwanted data and retransmit it later.
This approach requires both acknowledges and retransmits and would also cause
a disorder in the statements received. Performance will dramatically decrease
when using this method due to the inappropriate combination of retransmits
and the partition scheduling algorithm.
31
A client’s processing performance is an important issue. An idea to speed

this up is to send multiple partial rowsets instead of sending the entire rowset
at one time. Benefits would be that clients could start their result processing
earlier, i.e. start processing the first part directly instead of having to wait for
the entire rowset to be transmitted. This is a good idea if the partitions would
have been running concurrently. However since they do run in a round-robin
scheduling this idea loses its advantage. A client which receives a partial row set
can start to process directly, but when the processing has finished it has to wait
a whole cycle to get the next part of the partial row set before it can continue its
processing. This leads to an inefficient behavior where the client application can
only process one partial rowset per timeslot. However, it is possible to achieve
good performance using this method but then the client’s performance must be
known in advance. If that is the case, the server can send precise sized rowsets
which the client would just be able to cope with.
3.2.2 Server version

The server version of the database module is the link between the database
adapter and the transmission layer. It is responsible for receiving queries, syn-
chronizing access to the database and sending back the results to the client
applications.
Multitasking
The server module must be able to be connected to multiple client applications.
The server process will therefore spawn additional tasks to handle these appli-
cations. Each server-client connection is run inside its own single task. This is
to deny connections from occupying too much time and to prevent the database
from being locked down in case of a connection deadlock.
A task is similar to a thread. They are stored in the partition memory and
can access most of the resources inside the partition.
Each task handles one and only one of the connections. Its job is to manage
this connection, i.e. receive queries, processes queries and return answers until
the task is terminated. See figure 3.5 for a task job flowchart.
The advantage of a threaded environment is that if a deadlock occurs in
one connection, it won’t affect any other connections. Also, threads can be
scheduled to make the server process queries in different ways depending on the
system’s purpose. One disadvantage with threading is that the system becomes
more complex. Added issues are for example synchronization and multitasking
design.
Synchronization The access to the database is synchronized to prevent mul-

tithreading issues within the database. This means that only one thread at a
time can be executing a query in the database. The processing of this query
must be completed before the lock is lifted and another thread can access the
database.
32
Scheduling
In ARINC, scheduling of tasks is done in a preemptive priority-based way. In
the implemented system the priority is set to the same number for all tasks.
This implies that the tasks will be scheduled in a first in first out, FIFO, order.
There are two schedules of interest here; Round robin with yield and Yield
only.
Round robin with yield works as a round robin scheduling but has the possi-
bility to release the CPU earlier at its own command. This scheduling doesn’t
force the task to occupy its entire timeslot. Instead it will automatically relin-
quish the processor at send and receive timeouts. Timeslot lengths are deter-
mined by the number of ticks set by the KernelTimeSlice routine. Since all tasks
have the same priority, all tasks will enjoy about the same execution time. If
the partition timeslot is large enough and the KernelTimeSlice is small enough,
all clients will get some responses every cycle.
Another available scheduling is Yield only. This scheduling lets a task run
until itself relinquishes the CPU. The tasks do not have a maximum continuous
execution time. When used in this system, the CPU is released only at send
and receive timeouts.
3.2.3 Server and Client interaction - Protocol

The server and client interact with each other using a protocol. A package
transmitted using this protocol always starts with a fixed sized header before
the actual data follows. The data can be of any size since queries and result
sizes can vary. This variable data is unknown for the receiver and can therefore
not be received directly. The receive routine wants to know how many bytes it
should read from the inport. Also, the receiver needs the data size to be able
to allocate a buffer of an appropriate size.
A fixed maximum data size is the alternative, but will generate a huge over-
head because of the large size difference between the smallest result set and the
largest result set. However, this approach is the only choice if the system should
be certified. See section 6.4 for more information.
Since this system uses a variable data size, the receive routine only knows
about the header size. Therefore only the header is read from the inport at first,
leaving the data behind. Then the receiver checks the header for the data size
value, see table 3.2, and allocates a buffer of the correct size. As the data size
now is known, the receiver can read the data from the port and put the data in
the newly allocated buffer.
Header
The header contains an id, a statement pointer, a data size and a command
type as showed in table 3.2.
The statement pointer is used to distinguish to which statement a query
belongs. This is to make sure that database responses are moved into the correct
statements. An id is required because there are some special occurrences where
the statement pointer isn’t enough to determine which statement is the correct
one. The id is a sequence number that is increased and added to the header at
every send called by SQLExecDirect in the client application.
33
Id Unique id of a sent query.

Statement pointer Pointer to the statement holding the query in the client application.
Data size Size of the data following the header.
Command type Type of the following data.
Table 3.2: Header and data
Example of a case in which an id is required: Statement A contains a query

which is sent to the database. Before the server could return a response, the
client frees statement A and allocates a new statement called B. By doing this
statement A is no longer valid, and there is a possibility that the new state-
ment B is allocated at the memory location A used to have. When the client
application receives the server’s reply which belongs to statement A, the state-
ment pointer located in the header is still valid but is erroneously pointing to
statement B. Therefore the response will be moved into statement B. This is an
incorrect behavior since the response’s real statement has been freed and the
response should thereby be discarded.
An id added to the header struct solves this issue since it is unique for each
query. In the above situation, statement B’s id wouldn’t match the response’s
id since the id of statement B either is unassigned or has a different value.
The data size field in the header specifies the size of the payload while the
command type specifies the type of the payload. Available command types are:
NONE is set when nothing should be sent, i.e. the module will skip sending
messages of this type.
QUERY indicates that the package contains a SQL query. Messages of this
type will always generate a response.
END TRAN is a command type for messages containing an end transaction.

No response will be generated.
RESPONSE ROWSET is the response type of queries which resulted in

rowsets.
RESPONSE ERROR OR NO ROWSET indicates that the message is a
response from a query which didn’t generate a rowset or that an error
occurred. Neither one caused a rowset to be created.
Data is transferred in different ways depending on these command types. See
table 3.3.
34
Command type Data

NONE No package will be sent
QUERY < char∗ >Query as a string
END TRAN < int >Commit or Rollback
< int > Nr rows, < int > Nr cols
< int > length colname(1), < char∗ > col-
name(1)
RESPONSE ROWSET ...
< int > length colname(nr cols), < char∗ >
colname(Nr Cols),
< int > size cell(row1, col1) , < char∗ >
cell(row1, col1)
...
< int > size cell(nr rows, nr cols), < char∗ >
cell(nr rows, nr cols)
RESPONSE ERROR OR NO ROWSET No data
Table 3.3: Data contents
35
Connect to db adapter
Receive header size

from transmission
layer
Allocate memory for

data
Receive data from

transmission layer
Parse incoming
data
Execute query in
[QUERY] Type of data [OTHER] Print error mesage
database adapter
[END TRAN]
Adapter has Response type =

[NO]
result NONE
[YES]
Get result from adapter Send header and

Free allocated
and set Resonse type = data of response
memory
ROWSET_RESPONSE to client
Figure 3.5: Flowchart of a task in the database server module.
36
3.3 Transmission module

The transmission module is responsible for transmitting data between different
partitions. A simplified communication interface is provided to the upper layers.
This is done by abstracting the ARINC 653 ports and everything regarding the
communication. Things that are taken care of are fragmentation, retransmits
and port overflows. Everything that is sent through the module will eventually
arrive at the destination in the sent order.
The transmission control works as when using a socket, i.e. the routines
use a handle to identify which connection to use. It is the above layer that is
responsible for storing this handle. The transmission layer does not care what
kind of data it is transporting, it just makes sure the specified data will be
transmitted successfully through the connection.
3.3.1 Ports
The implementation of our test system uses ports of queuing type. The rea-
son for this is that no messages are allowed to be lost, as might be the case
when using sampling type ports. The transmission module shall also be able to
transfer data of large sizes. This also requires the usage of queuing ports since
large data must be fragmented to fit inside port buffers. This is impossible with
sampling ports.
Fragmentation
Buffer size and queue length are two important settings for a queuing port. Total
size required by a port is the buffer size times the queue length, P ortsize =
buf f er size ∗ queue length.
Large data streams that cannot fit inside one port buffer must be split into
several smaller parts. There are three different cases that can occur during the
fragmentation:
Case 1 Message fits in one buffer. It occupies one queue spot.
Case 2 Message doesn’t fit in one buffer but it fits in several buffers. This
message occupies several queue spots but the queue is not full.
Case 3 Message is too large and fills all queue buffers. This means that the
queue is full and the port is overflowed. The port’s behavior in this case
depends on which port protocol that is used.
Note that several large messages can be fragmented into the queue at the
same time which increases the risk of port overflow occurrences.
Port protocols
As mention before in section 2.4.6 VxWorks supports two different port proto-
cols: Sender Block and Receiver Discard.
The transmission module uses the Sender Block port protocol. The reason
for this is that it removes the issue of retransmissions entirely for our test sys-
tem. Another reason is that if the Receiver Discard port protocol were to be
used, some kind of block functionality would still be necessary. This is because
37
Receiver Discard drops messages if port queues are full. As no data is allowed to
be lost, retransmits must occur. Since the receiver’s buffer queue is full, the data
cannot be resent. Therefore the partition will be blocked from sending messages
to the receiver. Even though the partition can continue doing other stuff, the
best argument of using the Receiver Discard port protocol is diminished.
3.3.2 Transmission protocol

The transmission protocol describes how the transmission module transmits
data. The protocol takes any kind of data of any length and transfers it over
the specified connection. If the data does not fit inside a single message, the
data is divided into smaller fragments and then multiple sends are executed.
No retransmits occur in this transmission protocol. Instead the Sender Block
port protocol makes sure that no messages are lost by blocking the sender pro-
cess when it is trying to send data to a full port buffer queue. If both a client
application and its corresponding server thread have full inport queues and
both are in send mode, a deadlock will occur since both are blocked by the port
protocol.
Deadlocks
Deadlocks that regard the entire server’s uptime has been taken care of by
special design and configuration at another level. A multithreaded server and
the channel design will prevent one client to block the entire server because
only a single thread becomes locked. See section 3.1.1 and section 3.2.2 for
more information. However, deadlocks inside a single database thread might
still occur. This kind of deadlock prevents the specific database thread and its
corresponding application to execute successfully.
This deadlock type occurs when the client application executes a lot of
queries and thereby overflowing the server thread’s port buffer. This causes the
client application to block itself waiting for the occupied spots in the database
port queue to diminish. Then the server partition is switched in and it will re-
ceive and execute a few of the queries in the database and send back the results
to the client application. If the database responses are large enough to over-
flow the client application’s port buffer the server will be blocked too. Now the
client application is switched back in and since the database did some receives
before getting blocked, the client is no longer blocked. The client application
therefore resumes its execution at the same place where it was stopped before,
i.e. it continues sending a lot of queries. This causes the client application to
be blocked again soon. At this point both the client application and the server
thread are blocked since both of their inbound ports are overflowed. See figure
3.6.
To handle single thread deadlocks as described above, there are three options:
prevent, avoid, or detect and recover. In this system deadlock prevention has
been used.
Deadlock prevention Single thread deadlocks can be prevented by always

making sure that the ports will always be large enough to hold all data, i.e. port
overflows won’t happen. This approach is possible because of the predictability
of the system. All systems must be carefully analyzed and configured not to send
38
too much data too often. This is an effective but not a very flexible solution.
You also need to use large margins to make it work safely.
When using this deadlock solution the receive routine works as follows; it
will receive data from the ports with the amount of data to receive specified as
a parameter. I.e, it will read from port, merge messages and then return a data
stream of the specified length.
Deadlock recovery Deadlock recovery is used when a deadlock has already

occurred. One solution to recover is to restart one of the involved processes.
Another solution is to introduce timeouts. A send routine which got blocked
due to a full inport queue at receiver, will timeout after a specific time. This will
break the block and the execution continues. However, the execution cannot
continue as normal since the failed send’s data must be transferred. A retransmit
won’t solve this issue as the task will just be blocked and cause a deadlock again.
The data must therefore be discarded. This will be similar to the receiver discard
port protocol in VxWorks.
Both of the above recovery methods results in data loss, which is not wanted
in our system.
Deadlock avoidance It would be impossible to implement an deadlock avoid-

ance that does not affect the application design. An application developer would
have to make a check after each query executed, to see if it was executed suc-
cessfully or not. If unsuccessful due to a full destination port, the application
must call fetch with a valid statement handle to empty its own inport queue.
This will avoid deadlock.
This application dependency is unwanted and therefore this approach is
rejected.
39
Free space
Occupied space
Server inport Client inport
Client is switched in
Client sends queries but

Queries gets blocked when the
server inport is full
Server is switched in
The server processes

some of the incoming
queries and sends back
responses. 7KHFOLHQW¶V Responses
inport gets full and the
server thread is blocked
Client is switched in
$VWKHVHUYHU¶VLQSRUW
queue is not full anymore,
the client can resume its
Queries
execution where it halted,
i.e. continue sending
queries
Both inports are full - Deadlock!

Figure 3.6: A connection deadlock caused by Sender Block port protocol.
40
3.4 Databases
SQLite and Raima has been implemented and benchmarked. Unfortunately, it
was impossible to get Mimer up and running, since they only had pre-compiled
binaries for standard VxWorks. When linking these binaries with an applica-
tion there ware many linking errors because of missing libraries in VxWorks
653. MySQL fell off since the embedded version only exists under a commercial
license.
3.4.1 Filesystem
The ARINC 653 specification part 2 specifies a filesystem. This is not im-
plemented in VxWorks 653. However, there is a filesystem implemented in
VxWorks. This filesystem is not used in this project. One reason for this is
to avoid too much coupling to VxWorks 653-specific implementations. Another
reason is the VxWorks simulator. Since it’s a simulator, not an emulator, the
benchmarking may be even more inaccurate if disk read and write accesses are
done via the host operating system.
The filesystem that is used is an in-ram filesystem. It has been implemented
by overloading filesystem related functions like open() and close(). The over-
loading can be made since VxWorks lets you specify which functions that should
be linked from shared libraries and which shouldn’t.
Filesystem usage
Before using the filesystem it must be initialized. The initialization needs an
array with pointers to memory regions, one region per file, and the size of the
region. These memory regions can be of arbitrary sizes and are configured by
the application developer.
When creating a file, using open() or creat(), the first unused memory region
that was given during the initialization is used. This means that one must open
the files in the correct order to make sure that a file gets the wanted memory
region.
E.g. if one needs two files in an application, 1MB.txt and 1kB.txt, the
filesystem needs to be initialized with two pointers in the initialization array. If
the first pointer points to a 1MB memory region and the second pointer points
to a 1kB memory region, the 1MB.txt file must be created first since the 1MB
memory region is the first element of the pointer array.
Filesystem structure
To keep track of open files two different structs are used, as seen in figure 3.7.
The first one, file t, is the actual file struct. It has a pointer to where in the
memory the file data is located. This struct also holds all locks, the filename,
and the capacity and the size of the file. The second struct is ofile t. The o is for
open. This struct keeps track of access mode flags and the current file pointer
position. The last struct, fd t, is the file descriptor struct. It holds information
about operation mode flags.
The file descriptor struct and the open file struct could be merged to one,
but then it would be impossible to implement file descriptor duplication func-
tionality.
41
Figure 3.7: Filesystem structure.
The filesystem can have fixed numbers of files, open files and file descriptors.
Since there is a fixed maximum number of each struct, they are allocated in fixed
sized C arrays.
To avoid unnecessary performance issues, stacks are used to keep track of
free file descriptors and free files. With stacks, free descriptors can be found in a
constant time since there is no need of iterating the array with descriptors. The
filesystem is using files with static sizes. This makes reading and writing fast,
since all data is stored in one big chunk, and not spread over blocks. However,
this may lead to unused memory or full files. This means that the filesystem
must be configured carefully.
File locking
At first, file level locking was implemented. An entire file could be locked, not
parts of the file. However, it turned out that SQLite needs byte level locking,
and the ability to use both read and write locks. All locking related operations
are done via the fcntl() and the flock() functions.
3.4.2 SQLite specific

SQLite source code can be downloaded as a single source file. The code doesn’t
depend on any unusual libraries and is POSIX compatible. This suits very well
for VxWorks 653. It’s therefore not much work needed to get the database up
and running.
42
3.4.3 RAIMA specific

Raima has native VxWorks 653 support and there is almost no coding needed
to make it work. The only thing needed are some stubs for socket functions.
These stubs are just empty functions with hardcoded return values. Since no
sockets are used, it would be waste of memory to link a full socket library.
3.5 Database adapters

To give all databases a uniform interface towards the database module, they
are wrapped in adapters. The interface is made simple since it doesn’t need
to provide more functionality than the ODBC interface in the database mod-
ule requires. Except for executing pure queries the adapter interface provides
functionality for transactions and for fetching a select’s resulting rowset.
If the query results in one or more rows, the has result flag must be set.
The adapter should also provide how many rows that were affected by the last
query, i.e. how many rows got updated, deleted, inserted or selected.
3.5.1 Interface
The interface for the adapters is very simple. It basically provides support for
running queries and fetching results.
dba init() Initializes the adapter.
dba connect() Connects to the database.
dba disconnect() Disconnects from the database.
dba query() Executes a query.

dba fetch() Fetches resulting rowset.
dba has result() Records whether last query resulted in a rowset.
dba affected rows() Records how many rows that were affected by last query.
dba begin transaction() Begins transaction.
dba commit() Commits transaction.
dba rollback() Rolls back transaction.
3.5.2 SQLite adapter

SQLite’s API provides two ways of executing a SQL query; via direct execution
and via prepared statements. The former method is an wrapper around the
latter method. This leads to less control of the execution flow. Therefore all
queries are executed as prepared statements. After a query has been prepared,
the statement is passed to a step function. The first thing this function does is
to execute the statement, if it hasn’t been executed. It will then return a status
code about the execution. If this status code is SQLITE ROW, there is a row
43
ready to be fetched. If the status code is SQLITE DONE there is nothing more
to be done with this statement.
The status code is used to determine whether the query is a select or not.
If the return value is SQLITE ROW the query must have been a select, or
something else that resulted in one or more rows. However, if the query is a
select that returns no rows, its impossible to determine whether the query is a
select or not. Luckily, the database module only needs to know if there are any
rows, not what type of query that just got executed.
Transactions
SQLite is using pessimistic concurrency control. This, together with it’s locking
techniques makes transactions inefficient when the database is used by multiple
connections.
When a query that results in a write to the database is executed in a trans-
action, this transaction will lock the entire database with an exclusive lock until
it’s committed. This means that all other transactions have to wait for the lock
to be released before they can execute any more queries.
If there is one transaction per task in the database module and one of these
transactions holds an exclusive lock, and the task suddenly is switched out, the
other tasks won’t be able to perform any database queries. This will decrease
the database module’s performance. A solution could be to use mutex locks
and semaphores in the database module or disabling task switching to prevent
nested transactions.
Result handling
When a select query has been executed the result should be stored in a rowset.
To build the rowset the result from the database is iterated. For each iteration
a row is created and added to the rowset. To be able to add data to the rowset,
the size of the data must be known. This is done by checking the data type for
each column in the database.
3.5.3 Raima adapter

The Raima adapter uses Raima’s ODBC interface. It runs queries via prepared
statements. It’s not possible to create tables this way. This is done using
Raima’s SQL Data Definition Language, SDDL, in a specialized initialization
routine.
Initialization
Since Raima is unable to create tables via normal SQL queries, a specialized
initialization function must be used. This initialization function takes a pointer
to a pointer to a string containing Raima SDDL statements. The SDDL cannot
parsed right away. It has be written to a file first.
Normally, this file would be parsed with Raima’s command-line SDDL tool,
which is not possible in VxWorks since you cant use exec() to execute other
applications. However, it is possible to link Raima’s binaries with your own and
make a call to the SDDL tool’s main function sddl main().
44
When the SDDL has been parsed the database must be initialized. This is
also, usually, made with a command-line tool, but it’s possible to link these into
the application too and call the main function initdb main(). The result of the
parsing is the database files specified by the SDDL.
Files
Raima is using more files than SQLite, so the filesystem must be planned more
than with SQLite. At least three files is used during runtime, after the database
has been created; database, index and log. During database creation the SDDL
file is needed among others.
Result handling
To fetch the result from a query in Raima is very alike the way it’s done i
SQLite. The result must be iterated, column value types checked to get the size
needed in the row etc.
3.5.4 Query result

If a query results in one or more rows, a rowset can be retrieved with the
adapters fetch function.
A rowset is a collection of rows. It provides an interface for getting sin-
gle rows, get how many rows there are, get how many columns there are and
get how much memory the stored data are using. Rowsets are created with
sql rowset create(), which in turn is using malloc. This means that a rowset
must be freed. This is done with the sql rowset free() function.
A row is a collection of data. It doesn’t know what type of data it holds. It’s
up to the user to know how to treat and transform the data. The row interface
provides functionality to get column data, add column data, get number of
columns and get the size of memory the data uses. A row is created with
sql row create(), which in turn is using malloc. To free a row sql row free() is
used.
When freeing a rowset all rows in that rowset is also freed, and when a row
is freed all data in that row is freed.
To keep down the usage of dynamic memory a rowset can only have up
to a fixed number of rows and a row can only have up to a fixed number of
columns/values. However, memory for the column values are still allocated
dynamically.
45
Chapter 4
Benchmarking
Benchmarking is performed to find the implemented system’s thresholds ac-

cording to throughput, number of simultaneously clients and scheduling. This
is required to be able to evaluate the usage of databases in an ARINC 653
environment.
In the following sections, the benchmarking environment and results are
described and analyzed. Comparisons between SQLite and Raima can be found
in the next chapter.
4.1 Environment
The benchmarking is performed in a VxWorks 653 simulator on Windows desk-
top computer. This section describes how measurements are performed and
what default values are used for the benchmarking variables.
4.1.1 Simulator
The simulator simulates the VxWorks 653 real-time operating system, i.e. par-
titions, scheduling and the interpartition communication.
The low resolution of the simulator’s tick counter forces us to mostly use
long timeslots. We use 50 ms, 100 ms and 150 ms as our standard lengths but
in a real system these intervals are very long. A real system often uses partition
timeslots of length 5 ms or shorter. These short timeslots cannot be simulated,
but have to be run on a target hardware.
4.1.2 Variables
Table 4.1 shows the default values for the variables used during benchmarking.
If nothing else is mentioned in each test case, these were the values that were
used.
Number of client partitions describes how many client partitions are sched-
uled by the round robin partition scheduling in the core OS. Timeslot length
is the length in milliseconds of each partition window in the above scheduling.
Task scheduling describes the process scheduling inside a partition. Primary
key is if the query is using the primary column for selecting single rows. Port
buffer size and Port queue length are port attributes needed for communication
46
CHAPTER 4. BENCHMARKING
between partitions. Table size is the initialization size of the table used in the
benchmarks. Query response size is the size of the resulting rowset that will be
sent back to the client. Sort result is if the resulting rowset is sorted. Client
send quota is the number of queries each client will send.
Variable Value
Number of client partitions 1 .. 8.
Timeslot length 50,100,150 ms.
Task scheduling Round robin.
Primary key Yes.
Port buffer size 1024 bytes.
Port queue length 512.
Table size 1000 rows, 16 columns
Query response size 1 Row(16 cols).
Sort result No
Client send quota 1024
Table 4.1: Variables - default values
4.1.3 Measurement
The benchmarks are created by setting different numbers of clients sending a
predefined number of queries to the server. The server will then process these
queries as fast as it can and measure its average and maximum number of
processed queries for each of its timeslots. The minimum value was skipped
since it will almost always show the value from the last timeslot where the final
remaining queries are processed.
The number of queries sent by each client is 1024. This value is large enough
to cause full load on the database, but low enough to not need too much memory.
Benchmarks in this thesis measure the server’s throughput, that is the num-
ber of queries fully processed in the server during one timeslot. A fully pro-
cessed query is a query that has been received from the in port, executed in the
database and its result has been sent to the out port. A query that is processed
in the database when a context switch occur, will be recorded in the next times-
lot. The average number of the processed queries are calculated at the end of a
test run by dividing the total number of queries sent to the server by the total
number of timeslots the server required to finish, see equation (4.1).
This measurement approach was chosen because of the simulator’s inaccurate
time measurement and that queries processed is an easily understandable unit.
N o. sent queries per client ∗ N o. clients

Average no. processed queries =
P artition switches required
(4.1)
Every benchmark configuration has been run five times. A mean value has
then been calculated from these five runs. For example, a mean value of ”parti-
tion switches required” is used in equation 4.1 to calculate the average number
of processed queries during one timeslot.
For both databases the same benchmark configurations and the same queries
have been used. The only thing different between the database benchmarks is
47
the database adapter. The difference between the adapters are very small and
adds as almost no overhead to the database performance and should not affect
the result.
4.2 Benchmark graphs

This section shows some graphs that are representative for most of the bench-
marks. They summarize general and abnormal appearances found in the bench-
marks. All benchmarks can be found in appendix A. In all graphs below the
x axis shows the number of client partitions in the experiment, and the y axis
shows the average number of queries as given in equation 4.1 earlier.
4.2.1 SQLite Insert

This benchmark shows the average performance regarding inserts. In figure 4.1
the lines represent the average processed queries for one timeslot using different
timeslot lengths (50, 100, and 150 ms respectively).
One thing to notice is the minimum that occurs for two clients in the 150 ms
curve. This appears in almost all SQLite benchmark graphs and is explained
in section 4.3.2. Another thing to notice is that a doubling of timeslot lengths
does not imply a doubling of the number of processed queries.
The dissimilar characteristics between the 150 ms and the 100 ms curves
in figure 4.1 are seen as line crossings in figure 4.2. The lines in this figure
represent the average processed queries for different number of clients.
Overall, all SQLite graphs are very similar to each other. It is only the 150
ms curve that differ.
SQLite: Average insert performance

1100
50 ms
100 ms
1000 150 ms
900
800
700
Queries
600
500
400
300
200
100
0
1 2 3 4 5 6 7 8
Clients
Figure 4.1: Average inserts processed during one timeslot for different number of
client partitions.
48

1100
1000
900
800
Queries
700
600 1 Client
2 Clients
3 Clients
4 Clients
500
5 Clients
6 Cleints
7 Clients
400 8 Clients
300
50 100 150
Timeslot [ms]
Figure 4.2: Average number of inserts processed during one timeslot of various
length.
49
4.2.2 SQLite task scheduling

This benchmark shows the select performance when using a different task schedul-
ing. Yield only task scheduling is used in this benchmark, while Round robin
and yield is used in the other benchmarks. See figure 4.3 for this benchmark’s
result.
As can be seen in the figure, the 150 ms curve is a straight horizontal line.
This has to do with how the average value is calculated and is further explained
in 4.3.2.
SQLite: Average select perfomance − different task
scheduling
1100
1000
50 ms
900 100 ms
150 ms
800
700
Queries
600
500
400
300
200
100
0
1 2 3 4 5 6 7 8
Clients
Figure 4.3: Average selects processed during one timeslot for different numbers of
client partitions and timeslot lengths. Task scheduling used is Yield only.
50
4.2.3 SQLite select

This benchmark shows the average performance regarding select queries in
SQLite. As seen in figure 4.4, the 150 ms curve has the same strange ap-
pearance as in the insert benchmark graph. For the other two curves a small
maximum can be seen at five clients. This top reoccurs in almost all graphs;
both for Raima and SQLite. This is discussed in section 4.3.3.
SQLite: Average select performance

1100
50 ms
100 ms
1000
150 ms
900
800
700
Queries
600
500
400
300
200
100
0
1 2 3 4 5 6 7 8
Clients
Figure 4.4: Average selects processed during one timeslot for different numbers of
client partitions.
51
4.2.4 Raima select

This benchmark shows the average performance regarding select queries in
Raima, see figure 4.5.
The curves appearance for Raima is similar to those for SQLite. In differ-
ence from SQLite, Raima does not have the 150 ms curve with the dip in the
beginning. Raima is also slower than SQLite. A more in depth comparison can
be found in the next chapter.
Raima: average select performance
600
500
400
Queries
50 ms
100 ms
300 150 ms
200
100
0
1 2 3 4 5 6 7 8
Clients
Figure 4.5: Average selects processed during one timeslot for different number of
client partitions. The lines represent the average processed queries using different
timeslot lengths.
52
4.3 Benchmark graphs analysis

This section explains some significant outcomes of the benchmarking experi-
ments.
4.3.1 Deviation
Five runs with the same configuration were run to ensure better values. The
number of partition switches required in the benchmarks were almost always
the same during the five runs. When the values did differ, it was only by one
partition switch and this only occurred when many partitions were scheduled.
The worst deviation case that occurred during the benchmarks were that
three test runs returned the value 11 while two test runs gave 12 partition
switches. The mean value for this case is 11,4 partition switches, which gives
the standard deviation 0,49. The relative standard deviation is 4, 3%.
The maximum performance benchmarks do not rely on partition switches.
Instead they use the mean value of the maximum number of queries processed
in one timeslot. The relative standard deviation here is lower than 5, 3%.
4.3.2 Average calculation issues

All 150 ms curves seems to be quite strange when compared to the 50 ms and
100 ms curves. There are two different 150 ms curve appearances that are more
frequent than others: ”dip at beginning” and ”always max”.
Dip at beginning
The ”dip at beginning” appearance occurs in the SQLite insert, update and
select graphs (See figures A.1, A.5 and A.9). This strange curve is explained by
the average calculation method, see equation (4.1) on page 47. Since this method
uses the number of sent queries, divided by the number of required timeslots,
the calculation is very dependent on the timeslot length. A longer timeslot
length leads to more queries getting processed per timeslot and thereby fewer
partition switches are needed. With few clients, a small change in the number
of required partition switches will have huge affect on the calculation result.
If the average number of processed queries is less than a client’s total send
quota, in the benchmarks set to 1024, the server will need more than one timeslot
per client to finish. This means that the denominator in the average calculation
increases and thereby the average performance will be reduced.
With only one client running, the server manages to perform all of the client’s
1024 queries in one timeslot. When the number of clients is more than one,
context switches will occur in the server that adds some overhead. This overhead
makes, in the case of two clients, the server unable to perform all 2∗1024 queries
in two timeslots. This means that an extra timeslot is needed, and the average
performance is therefore heavily decreased. The calculations for the two cases
are 1024/1 and (2 ∗ 1024)/3. See figure 4.6 and figure 4.7.
For every additionally added client, the affect of the extra required partition
switch will be less and less.
53
1024 queries Fit in one frame
Database minor frame
Figure 4.6: With one client, the server manages to process all 1024 queries in one
time frame.
1024 queries Doesn’t fit in one frame
Database minor frame Idling
Figure 4.7: With two clients, the server cannot process 2*1024 in two timeslots due
to context switches. An extra time frame is required.
Always max
The average calculation can also explain some other 150 ms curves. For exam-
ple figure 4.3 shows select with Yield only scheduling. Its 150 ms curve is a
horizontal straight line which always has the value 1024.
In this case, the average value is in reality slightly above the calculated
average value of 1024. This leads to that the server will finish its processing
faster. However it is not fast enough to gain an entire timeslot and skip the last
partition switch. The number of partition switches are therefore the same and
leads to an erroneous calculated average value. See figure 4.8.
1024 queries To slow to earn one frame
Database minor frame
Figure 4.8: The average processing speed is faster than 1024 queries per timeslot,
but it is not fast enought to earn an entire timeslot.
4.3.3 Five clients top

As can bee seen in most of the average graphs, the 50 ms and the 100 ms curves
often show a local maximum when five clients are used. The curves increase
slightly up to four clients, then a larger hop up to the maximum value at five
clients and then a hop down to six clients. This local maximum might be related
54
to the task scheduling in the simulator, which seems to work better with five
threads in combination with the partition timeslot length. This is just a guess
from our side since we have no verified explanation.
4.3.4 Scaling
Looking at the insert and update curves, it can be seen how they scale compared
to the timeslot length. Generally, it seems that between 50 ms and 150 ms they
are linear. However, for SQLite, they do not double the number of queries
processed when the timeslot length is doubled which is the case for Raima.
55
Chapter 5
Comparisons between
SQLite and Raima
This chapter contains comparison graphs between SQLite and Raima. The
150 ms curves have been omitted since they are often affected by the average
calculation issue as described in section 4.1.3 and section 4.3.2, i.e. 150 ms curves
are too unreliable. Mostly, only the 50 ms curves are shown in the figures. This
is because too many curves makes the graphs hard to decipher. Also, 50 ms is
the time that mostly resembles a real timeslot length. Only average values are
presented since they are more interesting than the less informative maximum
values.
5.1 Insert performance

Figure 5.1 contains four insert performance curves, two each from SQLite and
Raima. They shows the average number of insert queries processed in the server
during a timeslot of both 50 ms and 100 ms.
The figure clearly states a large speed advantage for SQLite. For both times-
lots SQLite is processing approximately 150 queries more than Raima. This
indicates that SQLite is performing better for insert queries independent of
timeslot length.
56
CHAPTER 5. COMPARISONS BETWEEN SQLITE AND RAIMA
Insert comparison
600
500
400
Queries
300
200
Raima 50 ms
100 Raima 100 ms
SQLite 50 ms
SQLite 100 ms
0
1 2 3 4 5 6 7 8
Clients
Figure 5.1: Comparison between average insert values in SQLite and Raima. Times-
lots used in the graphs are 50 ms and 100ms.
57
5.2 Update performance

A comparison between SQLite’s and Raima’s update performance can be seen
in figure 5.2. The four curves describe the average queries processed for 50 ms
and 100 ms timeslots.
SQLite and Raima perform about the same, Raima even outperforms SQLite
in 100 ms timeslot. Raima was clearly behind SQLite in the insert performance
benchmark, but they are now almost equal.
One possible reason for this is that Raima stores rows with fixed sized
columns while SQLite stores rows with variable sized columns. This forces
SQLite to fetch a row in order to be able do an update, since it does not know
where in the row the column is, or if the new data fits in the current allocated
space. SQLite may be forced to reorganize the database. Raima on the other
hand, already knows exactly where in the row the column is. This means that
Raima don’t have to fetch the row to find out where the column is. Since the
column size is fixed, Raima can be sure that the new data fits and thereby
perform the update without any reorganization of the database.
Update comparison
700
600
500
Queries
400
300
200
Raima 50 ms
100 Raima 100 ms
SQLite 50 ms
SQLite 100 ms
0
1 2 3 4 5 6 7 8
Clients
Figure 5.2: Comparison between average update values in SQLite and Raima. Times-
lot lengths are 50 ms and 100 ms.
58
5.3 Select performance

This is a comparison between SQLite’s and Raima’s select performance which
can be seen in figure 5.3. Both Raima and SQLite seem to almost double their
number of processed queries when the timeslot length is doubled from 50 ms to
100 ms. SQLite is definitely faster than Raima, especially for larger timeslots.
When looking at select performance, one must remember that these results
include more than just the query execution in the database. The resulting data
is copied to a rowset, which in turn is serialized before sent back to the client.
This overhead is equal for both SQLite and Raima, but affects SQLite more
since it performs queries faster and thereby gets a higher relative performance
loss.
Select comparison
600
500
400
Queries
300
200
Raima 50 ms
100 Raima 100 ms
SQLite 50 ms
SQLite 100 ms
0
1 2 3 4 5 6 7 8
Clients
Figure 5.3: Comparison between average select values in SQLite and Raima. Times-
lot lengths are 50 ms and 100 ms.
59
5.4 No primary key

Figure 5.4 shows a comparison between select performance with and without
primary key. SQLite is outperforming Raima with leaps and bounds while not
using a primary key. When primary key is used, SQLite is still faster than
Raima, but the relative difference is lower.
For both databases there are huge performance differences between whether
the primary key is used or not.
Primary key comparison

350
300
250
Queries
200
Raima with primary key

150
Raima without primary key
SQLite without primary key
SQLite with primary key
100
50
0
1 2 3 4 5 6 7 8
Clients
Figure 5.4: Comparison between average select values in SQLite and Raima with
and without primary key. Timeslot length is 50 ms.
60
5.5 Task scheduling

This task scheduling analysis compares the two task scheduling methods used
in this thesis; Round robin with yield and Yield only. The comparison is made
with the 50 ms average select benchmarks. Figure 5.5 indicates quite similar
curves for the different scheduling approaches.
Yield only is a bit faster than Round robin and yield, for SQLite, but the
variation is quite small. This slight improvement can be credited to fewer task
switches in the database partition. For SQLite, when using round robin, the
number of processed queries in a task timeslot varies more than for Raima. This
leads to tasks finishing their processing in different round robin task cycles. A
finished task will then be switched in again the next cycle, even though it has
nothing to do. The task will yield and hand over to the next task. This adds
overhead and extra partition switches are needed.
For Raima, the tasks process queries with a uniform performance which
make the tasks finish in a consecutive order. This leads to less overhead and
small differences between the curves.
Task scheduling comparison

450
Raima − Round robin and yield
Raima − Yield only
SQLite − Round robin and yield
400 SQLite − Yield only
350
Queries
300
250
200
150
1 2 3 4 5 6 7 8
Client
Figure 5.5: Comparison between average select queries using different task schedules
in SQLite and Raima. Timeslot length is 50 ms.
61
5.6 Response sizes

Response sizes of select queries can vary. In this section responses of size 128
rows are used. Figure 5.6 shows curves which either have sorted the results in
an ascending order by a non-indexed column or has unsorted result sets.
An interesting thing to notice is that Raima performs equally good for both
sorted and unsorted results. SQLite performs on the same level as Raima for
sorted results but is faster when the results are unsorted.
Sort comparison
11
SQLite − no sort
10 SQLite − sort
Raima − no sort
9 Raima − sort
7
Queries
0
1 2 3 4 5 6 7 8
Clients
Figure 5.6: Comparison between average selects with and without sorting in SQLite
and Raima. The resulting rowsets are of size 128 rows and timeslot length is 50 ms.
Figure 5.7 compares the number of rows fetched from the database for single
row queries and 128 rows queries. As expected, both databases can fetch many
more rows during one timeslot when requesting larger rowsets as results. The
database will fetch rows faster and the interpartition communication will be
more effective. Fewer sends decreases the overhead.
Large responses comparison
1500
SQLite − 1 row per query
Raima − 1 row per query
SQLite − 128 rows per query
Raima − 128 rows per query
1000
Rows
500
0
1 2 3 4 5 6 7 8
Clients
Figure 5.7: Comparison between single row select and 128 rows select queries in
SQLite and Raima. Average values are showed in the graph with timeslot length of
50 ms.
62
5.7 Summary
In this section we summarize our observations for the selected timeslots and
scheduling approaches given the interpartition communication protocols and
adapters implemented.
• In general it appears that the system perform at its best for five clients,
both in SQLite and Raima, given the selected client loads and timeslots.
• The 150 ms measurements are often strange and unexpected. This can be
explained by the average metric used (equation 4.1) that depends on the
length of the time slot. used. Therefore 150 ms curves are less accurate
than the 50 ms and 100 ms curves.
• Most graphs are linear but a doubled timeslot won’t double the number
of processed queries. Excluded from this is the select performance graph.
• SQLite is overall much faster than Raima. Raima can only match SQLite
in the update performance benchmark.
The above summary is based on the benchmarks made in a simulator with

low time resolution, and the simulation were done in Windows on a desktop
computer. This implies that the benchmark results are not entirely reliable.
The benchmarked system is a system with certain properties. The results
and analyses are produced for this system and might not be applicable on other
systems.
63
Chapter 6
Discussion and Conclusion
This chapter presents a discussion and conclusion of this report.
6.1 Performance
The relation between performance and scalability, database comparisons, and
simulation details are discussed here.
6.1.1 Database comparison

The comparisons in the previous chapter showed that SQLite was overall much
faster than Raima. For us, this was a surprise. We expected Raima to be the
faster one mainly because it is a commercial database. The only test in which
Raima could match SQLite was in the update performance test.
As mentioned in section 2.5.5, Raima has two interfaces for accessing and
modifying data; an ODBC interface and a C interface. We used the ODBC
interface, which probably adds some overhead compared to the C interface.
One slow operation that is not required with the C interface is the SQL string
parsing.
Another thing with the C interface is that it provides C structs that matches
records in the database. This probably increases the performance of fetching
data since all data types and data sizes are known at compile time. In our
solution with ODBC interface, we must check what type of data a column con-
tains to make sure we treat it correctly. If one wants to use the C interface
in a server-client like environment, the database interface used in the applica-
tions can’t be SQL based like ODBC. It would probably need to be a system
dependent solution.
The curves in Raima’s graphs show less fluctuations compared to SQLite’s
graphs. This indicates that Raima’s performance is more deterministic.
6.1.2 Scalability
Most benchmarking graphs are quite linear which is good since then it is possible
to estimate results. If we use extrapolation on the curves we notice that curves
in insert and update graphs won’t cross origo. This implies that the linearity
won’t hold for low timeslot values. If the linearity did hold, it would be possible
64
CHAPTER 6. DISCUSSION AND CONCLUSION
to use timeslots of zero length and still be able to process queries. This is
obviously impossible. Raima does not have this behavior at all which further
strengthens our conclusion that Raima’s performance is easier to estimate.
It should be noted that there are few different timeslot lengths measured
which makes the above discussion a bit uncertain. To validate these results,
more timeslots must be tested. The three timeslot lengths used in the bench-
mark were chosen because they are large enough to work with the simulator’s
low resolution, while they are low enough to avoid inappropriate large port
buffers. The timeslot lengths are also multiples of 50 which makes it easy to see
scalability issues.
As seen in most of the graphs, there is a peak at five clients. Even though
it’s not verified, this peak might be due to the combination of timeslot lengths
in the task and partition schedulings, and the VxWorks simulator. To make
things clear about this, new benchmarks in a target environment are needed to
get more trustworthy values.
6.1.3 Measurement issues

The simulator, VxSim, introduces some error sources to the benchmarks. There-
fore the results should only be compared relative to each other.
Since it’s a simulator, not an emulator, it will execute all code directly in
the host CPU. If it had been an emulator it would have had it’s own virtual
CPU executing the code. Two executions of the same application with the same
configuration would then result in two identical executions independent of the
computer hardware. In an emulator it would have been possible to implement
functionality to even count single CPU instructions.
During the benchmarking, partition timeslots of length 50 ms, 100 ms and
150 ms were used. When the round-robin schedule was used, the task timeslots
was set to 1 tick. With 100 Hz resolution of the tick counter the timeslot for a
task corresponds to 10 ms. This means that the minimum possible schedule of
a task is 10 ms which implies that, if all tasks have full load, only five will have
the time to do work during one partition timeslot of 50 ms.
6.2 Design and implementation

Scheduling One of the main problems we encountered was how to design
the database requests and answers while considering the round robin partition
scheduling. It is quite different when you always have to wait an entire cycle
for a response. Also, measures must be taken to minimize the idle time in
partitions. To solve this we chose to use non-blocking execution routines and
the results are stored in statements, as described in section 3.2.1.
We also tried to minimize interpartition communication when designing this
system as it is one of the main time consuming tasks. It is much better to do a
few large sends compared to many small sends.
To remove the above issues regarding performance, scheduling and commu-
nication you can always embed the database in the application. When doing
this, both the application and the database must be of the same safety-critical
level. This approach is not suitable for systems where multiple applications
want to share a database.
65
ODBC interface An ODBC interface was chosen as the interface towards

application developers, mainly because it is an easy and well known interface.
The developers will be able to use this interface almost as if the system wasn’t
partitioned. However, they have to do some modifications to their programs. For
instance routines which want to fetch a just executed query should be avoided.
This is because the client will be idle the rest of its timeslot since the fetch is
waiting for a result which won’t arrive before its next timeslot. Instead a fetch
should be called sparsely or when it is really necessary.
Databases The databases we tested were both embedded. Probably, the

databases must be embedded if it’s going to be possible to get them up and
running in a ARINC 653-system. If they are not embedded they are probably
designed as some kind of server daemon, and the communication is done via
sockets. In this case one would have to replace the socket communication with
ARINC ports. The performance would probably suffer really bad from this if
one doesn’t also redesign more parts of how the database communicates. A case
that is not desirable is if the database client, after sending a query always, has
to wait for some kind of response from the server. This would then take a whole
time cycle in the ARINC partition schedule.
Another thing that might be required to get the databases up and running is
to implement a filesystem. This is because there are very few, if any, operating
systems that implements ARINC 653 part 2. How advanced the filesystem
should be may vary between the different databases. We implemented an in-
RAM filesystem by overloading system calls like open() and close().
Improvements It is probably possible to speed up the system by using pre-

pared statements in a smarter way. One could have the applications send all
their queries to the database. The database prepares the queries to statements,
which are stored in a list. When the application then wants to perform a query,
it just has to send an id for that query together with necessary parameters. In
this way, the database server only needs to parse each SQL query once.
6.3 Usage and Certification

It is not possible to use our system within a high level safety-critical system.
Neither SQLite or Raima provides any real-time guarantees which makes it
impossible to predict worst case scenarios. This implies a maximum certification
level of D or E for the databases. The Mimer database engine could provide
real-time guarantees when writing data to the database. If it was to be used, it
might be possible to certify for higher safety-critical levels. There may still be
other areas that can influence the certification success like storage safety, but is
claimed to be resolved by them.
Our implementation uses dynamic memory because it provides flexible code
which makes benchmarking easier. However, this prohibits the system to get
certified. Dynamic memory is not allowed except during initialization because
it causes an increased risk of failure and a less predictable system. The good
thing is that switching to a static-only memory management does not require
especially much work.
66
Low-level safety-critical software are not allowed to affect high-level safety-

critical software since its integrity would be compromised. In our case a level
A application can not use a SQLite database for important tasks. It might be
possible to use SQLite for saving unimportant data which is good to have but
not necessary.
This limits the usefulness of these databases since no important data can be
stored inside and no data can be sent to high safety-critical applications.
6.4 Future work

To make it possible to use our system as a safety-critical system, there are a
couple of tasks that must be done.
Target environment To validate the results the benchmarks must be run
in a real hardware environment. The VxWorks simulator is not reliable
enough.
Certification If the system should be certified our implementation must be

changed to use a static memory management and use certain C libraries.
This should not be too hard. However, the database must also use a secure
memory management, otherwise the certification would fail. This issue is
harder to fix as it may require changes to the database source code if it
doesn’t already comply with the certification standard.
6.5 Final words

Obviously, it is possible to implement databases in an ARINC 653-partition.
And the performance measured in both SQLite and Raima are acceptable. It is
enough to sustain small embedded systems which don’t require high workload
on the database. In our system SQLite was the significantly faster database
while Raima seemed to provide more deterministic results.
In our implementation the database resides in the RAM which is much faster
than if the database for example was to be stored in a flash memory. New
benchmarks must be performed on new storage mediums to determine their
performance.
We both agree that ARINC 653 is the future. It makes it easy and flexible
to develop new functionality when the core modules has been made. However,
it will still take some time before this technique has been validated, verified and
certified a million times before aircraft vendors would dare to use it in the really
critical systems like the flight control system. Maybe this will never happen,
but for low to medium level safety-critical systems, IMA architecture is already
here to stay.
67
Bibliography
[1] Airlines electronic engineering committee (AEEC). Mars 2006.

Avionics application software standard interface - ARINC speci-
fication 653 Part 1.
[2] Airlines electronic engineering committee (AEEC). November
2006. Avionics application software standard interface - ARINC
specification 653 Part 2.
[3] RTCA Inc. December 1992. DO-178B, Software Considerations
in Airborne Systems and Equipment Certification.
[4] Aviation glossary. [Available at: http://aviationglossary.
com][viewed 2009-10-14].
[5] 20th Society of Flight Test Engineers - European Chapter, An-
nual Symposium. September 7, 2009. Avionic Focus Course (in-
vited talk). Konsert & Kongress Linkping. Odd Romell, adjunct
professor at Malardalens hogskola.
[6] Paul Parkinson. September 2007. ARINC 653 partition jitter
& scalability. WindRiver Systems blog. [Available at: http:
//blogs.windriver.com/parkinson/][viewed at 2009-10-08].
[7] WindRiver Systems / IEEE Seminar. August 2008. ARINC 653
- An Avionics Standard for Safe, Partitioned Systems. [Available
at: http://www.computersociety.it/wp-content/uploads/
2008/08/ieee-cc-arinc653 final.pdf][viewed 2009-09-15].
[8] Rahul.G. Avionics Industry Moving towards Open systems. HCL
Technologies, India. [Available at: http://www.nasscom.in/
Nasscom/templates/NormalPage.aspx?id=55495][2009-11-02].
[9] Edgar Pascoal, José Rufino, Tobias Schoofs, James Windsor.
May 2008. AMOBA - ARINC 653 simulator for modular based
space application. Eurospace Data Systems in Aerospace Confer-
ence (DASIA). Palma de Majorca, Spain. [Available at: http://
dario.di.fc.ul.pt/downloads/DASIA08.pdf][viewed 2009-09-
25].
[10] Sérgio Santos, José Rufino, Tobias Schoofs, Cássia Tatibana,
James Windsor. October 2008. A Portable ARINC 653 stan-
dard interface. Digital Avionics Systems Conferance (DASC). St.
68
BIBLIOGRAPHY
Paul, Minnesota, USA. [Available at: http://air.di.fc.ul.

pt/air-ii/downloads/27th-DASC-Paper.pdf][viewed at 2009-
09-25].
[11] Wind River Systems Inc. 2007. VxWorks 653 Configuration and
Build Guide 2.2.
[12] Alan Burnes, Andy Welling. 2001. Real-Time Systems and Pro-
gramming Languages. Third edition. Pages 486 - 488.
[13] SQLite Documentation. [Available at http://www.sqlite.org/
docs.html][viewed 2010-01-15].
[14] Mimer Information Technology. Mimer SQL homepage. [Avail-

able at: http://www.mimer.com][viewed at 2009-11-16].
[15] Birdstep Technology. Raima Embedded 9.1 documentation.

[Available at: http://www.raima.com/docs/rdme/9 1/][viewed
2010-01-18].
[16] Sun Microsystems. MySQL’s official website. [Available at:

http://www.mysql.com][viewed 2009-11-20].
[17] Microsoft. MSDN: What is ODBC?. [Available at:

http://msdn.microsoft.com/en-us/library/ms714591(VS.
85).aspx][viewed 2010-01-20].
69
Glossary
ACID Atomicity, consistency , isolation, durability.

Set of properties that guaranties transaction are
processed reliably
API Application programming interface
ARINC 653 A specification for time- and space partitioning
in safety-critical real-time operating systems
Core OS Core operating system for a VxWorks 653 mod-

ule. Provides OS services and schedules parti-
tions
COTS Commercial of The Shelf
DDL Data Definition Language, Used in Raima to

specify databases
DO 178B Software Considerations in Airborne Systems
and Equipment certification. The avionics soft-
ware developed by RTCA.
Federated architecture Software run on a single hardware

FIFO Queuing protocol: First In, First out
MOS Module Operation System
OCC Optimistic concurrency control

ODBC Open Database Connectivity, Standard inter-
face for using databases
POS Partition Operation System

POSIX Portable Operation System Interface for Unix
RAM Random Access Memory

ROM Read-Only Memory
RTCA Private company called Radio Technical Com-
mission for Aeronautics. Developed DO-178B
RTOS Real-Time Operating System
SAAB Multinational aircraft vendor

SDDL SQL Data Definition Language. See DDL
70
BIBLIOGRAPHY
SDR Shared Data Region

SQL Structured Query Language, language used in
databases
vThreads Partition OS shipped with VxWorks

VxWorks RTOS which complies to ARINC 653 part 1
71
Appendix A
Benchmark graphs
A.1 Variables
Table A.1 the default values for the variables used during benchmarking. If
nothing else is mentioned in each test case, these were the values that were
used.
Variable Value
Number of client partitions 1 .. 8.
Timeslot length 50,100,150 ms.
Task scheduling Round robin.
Primary key Yes.
Port buffer size 1024 bytes.
Port queue length 512.
Table size 1000 rows, 16 columns
Query response size 1 Row(16 cols).
Sort result No
Client send quota 1024
Table A.1: Variables - default values
A.2 SQLite
This section shows benchmarks concerning SQLite. They are divided into six
categories: Insert, Update, Select, No primary key, Alternate task scheduling
and Large response sizes.
A.2.1 Insert
Insert query benchmarks are discussed here. Table A.2 shows non-default vari-
able values for these benchmarks.
72
APPENDIX A. BENCHMARK GRAPHS
Variable Value
Query type Insert
Query response size 0
Table A.2: Variables that differ from the default values
Average performance
This benchmark shows the average performance regarding inserts. In figure A.1
timeslot lengths. In figure A.2 the lines represent the average processed queries
for different number of clients.

1100
50 ms
100 ms
1000 150 ms
900
800
700
Queries
600
500
400
300
200
100
0
1 2 3 4 5 6 7 8
Clients
Figure A.1: Average inserts processed during one timeslot for different number of
client partitions.
73

1100
1000
900
800
Queries
700
600 1 Client
2 Clients
3 Clients
4 Clients
500
5 Clients
6 Cleints
7 Clients
400 8 Clients
300
50 100 150
Timeslot [ms]
Figure A.2: Average no. inserts processed during one timeslot of various length.
74
Maximum performance
This benchmark shows the maximum performance regarding the insert queries.
In figure A.3 the lines represent the maximum processed queries for one timeslot
using different timeslot lengths. In figure A.4 the lines represent the maximum
processed queries during one timeslot for a specific number of clients.
SQLite: Maximum insert performance

1100
1000
900
50 ms
100 ms
800
150 ms
700
Queries
600
500
400
300
200
100
0
1 2 3 4 5 6 7 8
Clients
Figure A.3: Maximum inserts processed during one timeslot for different number of
client partitions.
SQLite: Maximum insert performance

1200
1000
800
Queries
600
1 Client
2 Clients
3 Clients
400 4 Clients
5 Clients
6 Clients
7 Clients
8 Clients
200
0
50 100 150
Timeslot [ms]
Figure A.4: Maximum inserts processed for various timeslot lengths.
75
A.2.2 Update
The update query benchmarks are showed here. Table A.3 shows non-default
variable settings for these benchmarks.
Variable Value
Query type Update
Table A.3: Variables that differ from the default values.
Average performance
This benchmark shows the average performance regarding updates. In figure A.5
during one timeslot for a specific number of clients.
SQLite: Average update performance

1100
50 ms
1000 100 ms
150 ms
900
800
700
Queries
600
500
400
300
200
100
0
1 2 3 4 5 6 7 8
Clients
Figure A.5: Average updates processed during one timeslot for different number of
client partitions.
76
SQLite: Average update performance

1100
1000
900
800
Queries
700
600 1 Client
2 Clients
3 Clients
500 4 Clients
5 Clients
6 Clients
400
7 Clients
8 Clients
300
50 100 150
Timeslot [ms]
Figure A.6: Average no. updates processed during one timeslot of various length.
77
Maximum performance
This benchmark shows the maximum performance regarding update queries. In
figure A.7 the lines represent the maximum processed queries for one timeslot
using different timeslot lengths. In figure A.8 the lines represent the maximum
processed queries during one timeslot for a specific number of clients.
SQLite: Maximum update performance

1100
1000
900
800
700
Queries
600
500
400
300
50 ms
200 100 ms
150 ms
100
0
1 2 3 4 5 6 7 8
Clients
Figure A.7: Maximum updates processed during one timeslot for different number
of client partitions.
SQLite: Maximum update performance

1100
1000
900
800
Queries
700 1 Client
2 Clients
600 3 Clients
4 Clients
5 Clients
500 6 Clients
7 Clients
8 Clients
400
300
50 100 150
Timeslot length [ms]
Figure A.8: Maximum updates processed for various timeslot lengths.
78
A.2.3 Select
The select query benchmarks are showed here. Table A.4 lists the non-default
variable values for these benchmarks.
Variable Value
Query type Select
Average performance
This benchmark shows the average performance regarding selects. In figure
A.9 the lines represent average processed queries for one timeslot using different
during one timeslot for a specific number of clients.

1100
50 ms
100 ms
1000
150 ms
900
800
700
Queries
600
500
400
300
200
100
0
1 2 3 4 5 6 7 8
Clients
Figure A.9: Average selects processed during one timeslot for different numbers of
client partitions.
79

1100
1000
900
800
700
Queries
600
500 1 Client
2 Clients
400
3 Clients
4 Clients
300
5 Clients
200 6 Clients
7 Clients
100 8 Clients
0
50 100 150
Timeslot [ms]
Figure A.10: Average no. selects processed during one timeslot of various length.
80
Maximum performance
This benchmark shows the maximum performance regarding selects. In figure
A.11 the lines represent maximum processed queries using different timeslot
lengths. In figure A.12 the lines represent the maximum processed queries during
one timeslot for a specific number of clients.
SQLite: Maximum select performance

1100
1000
900
800
700
Queries
600
500
400
300
200
50 ms
100 100 ms
150 ms
0
1 2 3 4 5 6 7 8
Client
Figure A.11: Maximum selects processed during one timeslot for different numbers

1100
1000
900
800
700
Queries
600
500
1 Client
400 2 Clients
3 Clients
300 4 Clients
5 Clients
200 6 Clients
7 Clients
100 8 Clients
0
50 100 150
Timeslot [ms]
Figure A.12: Maximum no. selects processed during one timeslot of various length.
81
A.2.4 Alternate task scheduling

This benchmark shows the number of select queries processed when using a dif-
ferent task scheduling. The task scehduling used here is the Yield only schedul-
ing. See table A.5 for non-default variable settings and figure A.13 and A.14 for
benchmark results.
Variable Value
Query type Select
Task scheduling Yield only
SQLite: Average select perfomance − different task

scheduling
1100
1000
50 ms
900 100 ms
150 ms
800
700
Queries
600
500
400
300
200
100
0
1 2 3 4 5 6 7 8
Clients
client partitions and timeslot lengths.
82
SQLite: Maximum select performance − different task scheduling

1100
1000
900 50 ms
100 ms
800 150 ms
700
Queries
600
500
400
300
200
100
0
1 2 3 4 5 6 7 8
Clients
of client partitions and timeslot lengths.
83
A.2.5 No primary key

In this benchmark a non primary key column is used, i.e. the database can not
get any benefits from an index. Table A.6 shows non default variable values
used during this benchmark.
Variable Value
Query type Select
Primary key No
Average performance
This benchmark shows the average performance obtained when using selects
without a primary key. See figure A.15 and figure A.16 for the results.
SQLite: Average select perfomance − no primary key

160
140
120
100
Queries
80
60
40
50 ms
20
100 ms
150 ms
0
1 2 3 4 5 6 7 8
Clients
client partitions and timeslot lengths.
84
SQLite: Average select performance − no primary key

160
140
120
Queries
100
1 Client
2 Clients
80 3 Clients
4 Clients
5 Clients
60 6 Clients
7 Clients
8 Clients
40
50 100 150
Timeslot [ms]
Figure A.16: Average no. selects processed during one timeslot of various length.
85
Maximum performance
The figures A.17 and A.18 displays the maximum numbers of queries processed
in the server during one timeslot.

180
160
140
50 ms
100 ms
120 150 ms
Queries
100
80
60
40
20
0
1 2 3 4 5 6 7 8
Clients
of client partitions and timeslot lengths.
SQLite: Maximum select performance − no primary key

180
160
140
Queries
120
100 1 Client
2 Clients
3 Clients
80 4 Clients
5 Clients
6 Clients
60 7 Clients
8 Clients
40
50 60 70 80 90 100 110 120 130 140 150
Timeslot [ms]
Figure A.18: Maximum no. selects processed during one timeslot of various length.
86
A.2.6 Large response sizes

In this section benchmarks are performed on select queries that request 128
rows each time. It has been done with and without sort applied to the result.
Without sort
This benchmark shows average and maximum performance regarding large re-
sponse sizes. No sorting is applied in the database on the results. See table A.7
for non default variable values and figure A.19 for benchmark result.
Variable Value
Query type Select
QUery response size 128 rows
SQLite: Average and maximum select performance − 128 rows response

14
12
10
Queries
2
Average 50 ms
Maximum 50 ms
0
1 2 3 4 5 6 7 8
Client
Figure A.19: Average and maximum processed select queries. These selects ask
for128 rows. No sorting is applied.
87
With sort
sponse sizes when sorting is applied, see table A.8 for non default variable values.
Resulting rows are sorted ascending order by an unindexed column. See figure
A.20 for the benchmark result.
Variable Value
Query type Select
Query response size 128 rows
Sort result Yes
SQLite: Average and maximum select performance, 128 sorted rows response
11
Average 50 ms
Maximum 50 ms
10
7
Queries
0
1 2 3 4 5 6 7 8
Clients
Figure A.20: Average and maximum processed selects are displayed. Each query
asks for a 128 rows response. Results are sorted in an ascending order by an unindexed
column.
88
A.3 Raima
This section contains benchmark results for Raima. The benchmarks are di-
vided into six categories: Insert, Update, Select, No primary key, Alternate
task scheduling and Large response sizes.
A.3.1 Insert
The benchmarks in this section shows Raima’s performance with respect to
insert queries. Table A.9 shows the non-default values for variables used during
the insert benchmarks.
Variable Value
Query type Insert
Average performance
This benchmark show the average performance regarding inserts. In figure A.21
timeslot lengths. In figure A.22 the lines represent the average number of queries
processed during one timeslot for a specific number of clients.
Raima: average insert performance

900
800
700
600
Queries
500
400
300
200
50 ms
100 100 ms
150 ms
0
1 2 3 4 5 6 7 8
Clients
Figure A.21: Average inserts processed during one timeslot for different number of
client partitions.
89
Raima: average insert performance

900
1 clients
800 2 clients
3 clients
4 clients
700 5 clients
6 clients
7 clients
Queries
600 8 clients
500
400
300
200
50 100 150
Timeslot [ms]
Figure A.22: Average inserts processed for various timeslot lengths.
90
Maximum performance
This benchmark shows the maximum performance regarding inserts. In figure
A.23 the lines represent the maximum processed queries using different timeslot
lengths. In figure A.24 the lines represent the maximum number of queries
processed during one timeslot for a specific number of clients.
Raima: maximum insert performance

800
700
600
500
Queries
400
300
200
50 ms
100
100 ms
150 ms
0
1 2 3 4 5 6 7 8
Clients
Figure A.23: Maximum inserts processed during one timeslot for different number
Raima: maximum insert performance

800
700
600
Queries
500
1 clients
2 clients
400 3 clients
4 clients
5 clients
300 6 clients
7 clients
8 clients
200
50 100 150
Timeslot [ms]
Figure A.24: Maximum inserts processed for various timeslot lengths.
91
A.3.2 Update
In this section update queries has been benchmarked. Table A.10 shows non-
default values for variables used during the update benchmarks.
Variable Value
Query type Update
Average performance
This benchmark shows the average performance regarding updates. In figures
A.25 the lines represent the average processed queries for one timeslot using
different timeslot lengths. In figure A.26 the lines represent the average number
of queries processed during one timeslot for a specific number of clients.
Raima: average update performance

1100
1000
900
800
700
Queries
600 50 ms
100 ms
500 150 ms
400
300
200
100
0
1 2 3 4 5 6 7 8
Clients
Figure A.25: Average number of updates processed during one timeslot for different
number of client partitions.
92
Raima: average update performance

1100
1000
900
800
Queries
700
600
1 clients
500 2 clients
3 clients
4 clients
5 clients
400 6 clients
7 clients
8 clients
300
50 100 150
Timeslot [ms]
Figure A.26: Average number of updates processed for various timeslot lengths.
93
Maximum performance
This benchmark shows the maximum performance regarding updates. In figure
A.27 the lines represent the maximum processed queries for one timeslot us-
ing different timeslot lengths. In figure A.28 the lines represent the maximum
number of queries processed during one timeslot for a specific number of clients
Raima: maximum update performance

1200
1000
800
Queries
50 ms
600 100 ms
150 ms
400
200
0
1 2 3 4 5 6 7 8
Clients
Figure A.27: Maximum updates processed during one timeslot for different number
94
Raima: maximum update performance

1200
1100
1000
900
1 clients
2 clients
Queries
800 3 clients
4 clients
5 clients
700 6 clients
7 clients
8 clients
600
500
400
300
50 100 150
Timeslot [ms]
Figure A.28: Maximum updates processed for various timeslot lengths.
95
A.3.3 Select
In this section the select performance has been benchmarked. It is performed
with the non default variable values seen in table A.11.
Variable Value
Query type Select
Average performance
This benchmark shows the average average performance regarding selects. In
figure A.29 the lines represent the average processed queries for one timeslot
using different timeslot lengths. In figure A.30 the lines represent the number
of select queries processed during one timeslot for different number of clients.
600
500
400
Queries
50 ms
100 ms
300 150 ms
200
100
0
1 2 3 4 5 6 7 8
Clients
Figure A.29: Average selects processed during one timeslot for different number of
client partitions.
96

650
600
550
500
450
Queries
400
1 clients
350
2 clients
3 clients
300
4 clients
5 clients
250
6 clients
7 clients
200
8 clients
150
50 100 150
Timeslot [ms]
Figure A.30: Average selects for various timeslot lengths.
97
Maximum performance
This benchmark shows the maximum performance regarding selects. In figure
A.31 the lines represent the maximum processed queries for one timeslot us-
ing different timeslot lengths. In figure A.32 the lines represent the maximum
processed queries for one timeslot using different number of clients.
Raima: maximum select performance

700
600
500
Queries
400
300
200
100 50 ms
100 ms
150 ms
0
1 2 3 4 5 6 7 8
Clients
Figure A.31: Maximum selects processed during one timeslot for different number
Raima: maximum select performance

700
600
500
Queries
400
1 clients
2 clients
300 3 clients
4 clients
5 clients
200 6 clients
7 clients
8 clients
100
50 100 150
Timeslot [ms]
Figure A.32: Maximum selects processed for various timeslot lengths.
98
A.3.4 Alternate task scheduling

This benchmark shows the number of select queries processed when using a dif-
ferent task scheduling. The task scheduling used here is the Yield only schedul-
ing. Table A.12 shows the variables with non-default values used in this bench-
mark. Figure A.33 and figure A.34 show the benchmark results for average
respectively maximum performance.
Variable Value
Query type Select
Task scheduling Yield only
Raima: average select performance, with yield
600
500
400
Queries
50 ms
100 ms
300 150 ms
200
100
0
1 2 3 4 5 6 7 8
Clients
client partitions.
99
Raima: maximum select performance, with yield
600
500
400
Queries
300
200
100
50 ms
100 ms
150 ms
0
1 2 3 4 5 6 7 8
Clients
of client partitions. The lines represent the maximum processed queries using different
timeslot lengths.
100
A.3.5 No primary key

In this benchmark a non primary key column is used, i.e. the database can not
get any benefits from an index. Table A.13 shows the values for the variables
that has non-default values.
Variable Value
Query type Select
Primary key No
Average performance
This benchmark shows the average queries processed when no primary key
is used. In figure A.35 the lines represent the average processed queries for
one timeslot using different timeslot lengths. In figure A.36 the lines represent
the number of queries processed during one timeslot using different number of
clients.

35
50 ms
30 100 ms
150 ms
25
Queries
20
15
10
0
1 2 3 4 5 6 7 8
Clients
client partitions. No primary key is used.
101
Raima: average select performance, no primay key

35
30
25
Queries
1 clients
20
2 clients
3 clients
4 clients
5 clients
15
6 clients
7 clients
8 clients
10
50 100 150
Timeslot [ms]
Figure A.36: Average selects processed for various timeslot lengths. No primary key
is used.
102
Maximum performance
This benchmark shows the maximum performance regarding selects when no
primary key is used. In figure A.37 the lines represent the maximum processed
queries for one timeslot using different timeslot lengths. In figure A.38 the lines
represent the maximum number of queries processed during one timeslot for
different number of clients.
Raima: average select performance, no primary key

40
35
30
25
Queries
20
15
10
50 ms
5
100 ms
150 ms
0
1 2 3 4 5 6 7 8
Clients
of client partitions. No primary key is used.
Raima: maximum select performance, no primary key

40
35
30
Queries
25
1 clients
2 clients
20 3 clients
4 clients
5 clients
15 6 clients
7 clients
8 clients
10
50 100 150
Timeslot [ms]
Figure A.38: Maximum select processed for various timeslot lengths. No primary
key is used.
103
A.3.6 Large response sizes

In this section benchmarks are performed on select queries that request 128
rows each time. It has been done with and without sort applied to the result.
Without sort
sponse sizes when sorting is applied, see figure A.39. Table A.14 shows non-
default variables used in this benchmark.
Variable Value
Query type Select
Query response size 128 Rows (16 cols)
Raima: Average and maximum select performance, 128 rows response

8
Average 50 ms
Maximum 50 ms
5
Queries
0
1 2 3 4 5 6 7 8
Clients
asks for 128 rows.
With sort
sponse sizes when sorting is applied, see table A.15 for non default variable
values. Resulting rows are sorted in ascending order by an non indexed column.
See figure A.40 for the benchmark result.
104
Variable Value
Query type Select
Query response size 128 Rows (16 cols)
Sort result Yes
Raima: Average and maximum select performance, 128 sorted rows response
8
5
Queries
2 Average 50 ms
Maximum 50 ms
1
0
1 2 3 4 5 6 7 8
Clients
asks for 128. Results are sorted in an ascending order by an non-indexed column.
105
På svenska
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –

under en längre tid från publiceringsdatum under förutsättning att inga extra-
ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida http://www.ep.liu.se/
In English
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page: http://www.ep.liu.se/
© Martin Fri & Jon Börjesson

Presentationsdatum Institution och avdelning
2010-02-26
IDA,
Publiceringsdatum (elektronisk version) Dept. Of Computer and Information
Science
2010-06-20 58183 LINKÖPING
Språk T yp av publikation
ISBN (licentiatavhandling)

Svenska Licentiatavhandling
ISRN LIU-IDA/LITH-EX-A--10/010--SE
X Annat (ange nedan) X Examensarbete
C-uppsats Serietitel (licentiatavhandling)
D-uppsats
Engelska/English Rapport
A ntal sidor Annat (ange nedan) Serienummer/ISSN (licentiatavhandling)
105
U R L för elektronisk version

http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-57473
Publikationens titel
Usage of databases in ARINC 653-compatible real-time system
Författare
Martin Fri och Jon Börjesson
Sammanfattning
The Integrated Modular Avionics architecture , IMA, provides means for runningmultiple safety-critical
applications on the same hardware. ARINC 653 is a specification for this kind of architecture. It is a specification
for space and time partition in safety-critical real-WLPHRSHUDWLQJV\VWHPVWRHQVXUHHDFKDSSOLFDWLRQ¶V integrity.
This Master thesis describes how databases can be implemented and used in an ARINC 653 system. The
addressed issues are interpartition communication, deadlocks and database storage. Two alternative embedded
databases are integrated in an IMA system to be accessed from multiple clients from different partitions.
Performance benchmarking was used to study the differences in terms of throughput, number of simultaneous
clients, and scheduling. Databases implemented and benchmarked are SQLite and Raima. The studies
indicated a clear speed advantage in favor of SQLite, when Raima was integrated using the ODBC interface.
Both databases perform quite well and seem to be good enough for usage in embedded systems. However,
since neither SQLite or Raima have any real-time support, their usage in safety-critical systems are limited. The
testing was performed in a simulated environment which makes the results somewhat unreliable. To validate the
benchmark results, further studies must be performed, preferably in a real target environment.
A ntal sidor: 105
Nyckelord
ARINC 653, INTEGRATED MODULAR AVIONICS, EMBEDDED DATABSES, SAFETY-CRITICAL, REAL-TIME
OPERATING SYSTEM, VXWORKS

Full Text 01

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full Text 01

Uploaded by

Copyright:

Available Formats

Institutionen för datavetenskap

Department of Computer and Information Science

Usage of databases in ARINC 653-compatible

Linköpings universitet Linköpings universitet

Usage of databases in ARINC 653-compatible

Supervisor: Magnus Vesterlund

3 System design and implementation 26

3.2.2 Server version . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Comparisons between SQLite and Raima 56

6 Discussion and Conclusion 64

1.1 An ARINC 653 system. . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 A federated architecture and an Integrated Modular Avionics ar-

3.1 System design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1 Comparison between average insert values in SQLite and Raima.

5.3 Comparison between average select values in SQLite and Raima.

App 1 App 2 App 3 DB

RTOS (ARINC 653)

Figure 1.1: An ARINC 653 system.

1.3 Problem description

• Implement a database API for communication between the applications

• Find the system’s performance thresholds according to throughput, num-

• The implementation will primarily be tested in a simulated environment.

1.4 Document structure

Chapter 1 Contains an introduction to the master thesis.

Chapter 2 Essential background information needed to understand the thesis.

Chapter 3 The design of the implemented system is described here.

Chapter 4 Contains benchmarking graphs and their analyses.

Chapter 5 Contains a comparison between chosen databases.

Chapter 5 Contains discussions and conclusions about the thesis result.

2.1 Safety-critical airplane systems

Hazardous / Severe-Major A failure that would reduce the capabilities

• Large reduction of safety margins or functional capabilities.

• Increased eﬀects on occupants including seriously or potentially fatal in-

• Significant increased workload of the crew.

• Possible discomfort of the occupants including injuries.

Software safety levels

2.2 Avionics architecture

Federated System Integrated Modular Avionics

MMU-partitioning Operating System

Figure 2.1: A federated architecture and an Integrated Modular Avionics architec-

2.2.1 Federated architecture

Drawbacks of a federated architecture are:

• Hard to reuse software and hardware

• More hardware needed, increases weight and space required

• High power consumption

[5] [7] [8] [9]

2.2.2 IMA architecture

• Easy to certify new modules

• Reuse of software and hardware

• COTS, Commercial of the shelf

Drawbacks of an IMA architecture are:

• Complex design needed

[5] [7] [8] [9]

2.3 ARINC 653

Specification details The ARINC 653 specification consists of three parts:

• Part 1: Required services

• Part 2: Extended services

• Part 3: Test Compliance

The required services part defines the minimum functionality provided by

2.3.1 Part 1 - Required Services

Scheduling Partitions are scheduled in a strictly deterministic way, they have

Partition Partition Partition Partition

Minor Frame #1 Minor Frame #2 Minor Frame #3 Minor Frame #4

Major Frame repeat