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ö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 running
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
application’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 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.
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
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
1
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 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
2
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 number 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 numbers of
client partitions and timeslot lengths. Task scheduling
used is Yield only. .......................... 50
4.4 Average selects processed during one timeslot for different numbers of
client partitions. . . . . . . . . . . . . . . . . . . . . . . . 51
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.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 timeslots 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
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
3
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 number of
client partitions. . . . . . . . . . . . . . . . . . . . . . . . . 73
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 numbers of
A.10 Average no. selects processed during one timeslot of various
length. ................................ 78
A.11 Maximum selects processed during one timeslot for different numbers of
A.12 Maximum no. selects processed during one timeslot of various
length. ................................ 79
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
4
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. . . . . . . . . . . . . . A.21 Average 86
inserts processed during one timeslot for different num-
ber of client partitions. . . . . . . . . . . . . . . . . . . . . . . . . 87
A.22 Average inserts processed for various timeslot lengths. . . . . . . A.23 88
Maximum inserts processed during one timeslot for different num-
A.24 Maximum inserts processed for various timeslot lengths. . . . . . A.25 89
Average number of updates processed during one timeslot for
different number of client partitions. . . . . . . . . . . . . . . . . A.26 Average 90
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. . . . . A.29 93
Average selects processed during one timeslot for different num-
A.30 Average selects for various timeslot lengths. . . . . . . . . . . . . A.31 95
Maximum selects processed during one timeslot for different num-
A.32 Maximum selects processed for various timeslot lengths. . . . . A.33 96
A.34 Maximum selects processed during one timeslot for different number
of client partitions. The lines represent the maximum pro-
cessed queries using different timeslot lengths. . . . . . . . . . . . A.35 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
A.37 Maximum selects processed during one timeslot for different number 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
A.39 Average and maximum processed selects are displayed. Each
query asks for 128 rows. . . . . . . . . . . . . . . . . . . . . . . . 102
A.40 Average and maximum processed selects are displayed. Each 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 Linköping and examined at
Department of Computer & Information science at Linkö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 memory
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 memory
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 problem 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 communicate 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
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 implement
different databases in an ARINC 653-compliant system and study their behavior.
6
1.3 Problem description
This thesis will study how can databases be embedded in an ARINC
653environment. 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 653system.
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 applicationsand
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.
7
CHAPTER 1. INTRODUCTION
Martin’s part is focused towards ARINC 653 and the interpartition

communication. 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.
8
CHAPTER 2. BACKGROUND
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
Certification, 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 developing
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 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:
9
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

reliedupon to perform their tasks accurately or completely.
• Increased ejuries to a small number of the occupants.ffects on occupants

including seriously or potentially fatal in-
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
failures 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.
10
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
Air Data Management
Mission computer
computer computer
Air Data FMS Mission

Computer
MMU-partitioning Operating
System
Bus
Figure 2.1: A federated architecture and an Integrated Modular Avionics architecture. [6]
2.2.1 Federated architecture

Federated architecture is the traditional approach of implementing avionics
systems. 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
developers 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
11
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 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 constraints. 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
12
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

• 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
13
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
important core functionality of real-time operating systems should work to
comply with the specification. The system functionality is divided into six
categories:
• Partition management
• 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 timeslots, 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
14
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.
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 WARMSTART 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 system

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
15
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 scheduling 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]
Memory allocation
An application can only use memory in its own partition. This memory allocation
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
communicate 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.
16
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]
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
synchronization. Semaphores control access to shared resources while events
coordinate 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
available. 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
17
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 Compliance

Part 2, extended services, contains specifications for:
• File Systems
• Sampling Port Data Structures
• Multiple Module Schedules

• 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. Details
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
between applications, partition OSes and other components. This makes it
possible 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
18
must be given in the configuration file for the module and that resources are
preallocated 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:
• The virtual addresses of shared libraries must be specified. The
addressdepends 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
configuration 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
19
POS-1
App-2 Blackboard
App-1 POS-1
POS-1 POS-2
ConfigRecor ConfigRecord ConfigRecord
POS-2 d
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.
As figure 2.3 illustrates, applications and the core OS consumes more memory
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 allowed 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.
20
2.4.5 Partitions and partition OSes

A module consists of a RTOS and partitions. Each partition contains an application
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 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 drawback is
21
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
performance 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
simulator’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 software.
They are often specialized for a particular application and not that general. 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
evaluated for implementation in the system. It also contains some general
information that may be good to know for better understanding of the system
implementation.
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 support.
22
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
functionality. 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.
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.
23
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 manual
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 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 inmemory
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
24
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
abstract 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
applications. 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 providingfunctionality 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.
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.
26
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
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.
3.1.1 Interpartition communication design

Partitions communicate with each other through ports and channels. This section
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.
27
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.
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 routines
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
associated with this connection. It also holds all
28
statement 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,
* 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 statement 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
29
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 buffers before
the routine exit.
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
30
when using this method due to the inappropriate combination of retransmits and
the partition scheduling algorithm.
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,
synchronizing 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
applications. 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

multithreading 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.
31
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
possibility 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 relinquish
the processor at send and receive timeouts. Timeslot lengths are determined 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
overhead 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.
Id Unique id of a sent query.
32
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 statement 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 statement 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
Command type Data

NONE No package will be sent
QUERY < char >Query as a string
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.
END TRAN < int >∗Commit or Rollback
< int > Nr rows, < int > Nr cols
<name(1)int > length colname(1), < char∗ >
col-
RESPONSE ROWSET ...
33
< 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
34
Figure 3.5: Flowchart of a task in the database server module.

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 reason 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, Portsize = buffer
sizeLarge data streams that cannot fit inside one port bu∗ queue length. ffer 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 protocols:
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 system.
Another reason is that if the Receiver Discard port protocol were to be used, some
35
kind of block functionality would still be necessary. This is because 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
process 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 receive 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 overflow 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
36
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 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 avoidance

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 successfully
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.
Free space
Occupied space
37
Both inports are full - Deadlock!

Figure 3.6: A connection deadlock caused by Sender Block port protocol.
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 application
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.
38
3.4.1 Filesystem
The ARINC 653 specification part 2 specifies a filesystem. This is not implemented
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 overloading
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 functionality.
39
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.
40
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 module
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 ready to be fetched. If
the status code is SQLITE DONE there is nothing more to be done with this
statement.
41
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
transaction, 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().
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.
42
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 single
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.
43
Chapter 4
Benchmarking
Benchmarking is performed to find the implemented system’s thresholds
according 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
desktop 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.
partitions, 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 scheduled
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 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.
44
CHAPTER 4. BENCHMARKING
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 number
of queries fully processed in the server during one timeslot. A fully processed
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 timeslot. 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.
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 ”partition
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 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
benchmarks. They summarize general and abnormal appearances found in the
45
benchmarks. 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.

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]
46
Figure 4.2: Average number of inserts processed during one timeslot of various length.
4.2.2 SQLite task scheduling

This benchmark shows the select performance when using a different task
scheduling. 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.
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 appearance
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.
47
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.
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 difference
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.
48
4.3 Benchmark graphs analysis

This section explains some significant outcomes of the benchmarking experiments.
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 figureffect of the extra required
partition4.7. For every additionally added client, the a switch will be less and less.
1024 queries Fit in one frame
49
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 example
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 to
50
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.
51
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 timeslots
SQLite is processing approximately 150 queries more than Raima. This indicates
that SQLite is performing better for insert queries independent of timeslot length.
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. Timeslots used
in the graphs are 50 ms and 100ms.
52
CHAPTER 5. COMPARISONS BETWEEN SQLITE AND RAIMA
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. Timeslot
lengths are 50 ms and 100 ms.
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.
53
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. Timeslot
lengths are 50 ms and 100 ms.
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.
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
54
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.
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.
55
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.
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.
56
• The 150 ms measurements are often strange and unexpected. This can
beexplained 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 SQLitein 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.
57
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 contains 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 applications 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 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 benchmark were
chosen because they are large enough to work with the simulator’s low
58
CHAPTER 6. DISCUSSION AND CONCLUSION
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.
Therefore 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
communication 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.
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
59
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 inRAM
filesystem by overloading system calls like open() and close().
Improvements It is probably possible to speed up the system by using prepared

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.
Low-level safety-critical software are not allowed to affect high-level
safetycritical 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.
60
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.
61
Bibliography
[1] Airlines electronic engineering committee (AEEC). Mars 2006.
Avionics application software standard interface - ARINC
specification 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, Annual
Symposium. September 7, 2009. Avionic Focus Course (invited
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, José Rufino, Tobias Schoofs, James Windsor. May
2008. AMOBA - ARINC 653 simulator for modular based space
application. Eurospace Data Systems in Aerospace Conference
(DASIA). Palma de Majorca, Spain. [Available at: http://
dario.di.fc.ul.pt/downloads/DASIA08.pdf][viewed 2009-09-
25].
[10] Sérgio Santos, José Rufino, Tobias Schoofs, Cássia Tatibana,
James Windsor. October 2008. A Portable ARINC 653 standard
interface. Digital Avionics Systems Conferance (DASC). St.
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.
62
[12] Alan Burnes, Andy Welling. 2001. Real-Time Systems and
Programming 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. [Available
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].
63
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
module. Provides OS services and schedules
partitions
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
software 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 interface
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
Commission for Aeronautics. Developed DO-
178B
RTOS Real-Time Operating System
SAAB Multinational aircraft vendor

SDDL SQL Data Definition Language. See DDL
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
64
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
variable values for these benchmarks.
65
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.

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.
66
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.
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.
67
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.
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.
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.
68
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.
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
69
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.

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.
70
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 of
client partitions.

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.
A.2.4 Alternate task scheduling

This benchmark shows the number of select queries processed when using a
different task scheduling. The task scehduling used here is the Yield only
scheduling. See table A.5 for non-default variable settings and figure A.13 and
A.14 for benchmark results.
71

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
partitions and timeslot lengths.
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
client partitions and timeslot lengths.
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
72
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
partitions and timeslot lengths.
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.
Maximum performance
The figures A.17 and A.18 displays the maximum numbers of queries processed in
the server during one timeslot.
73

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
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.
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
response 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
74
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.
With sort
response 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
rows
Sort result Yes
75
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.
A.3 Raima
This section contains benchmark results for Raima. The benchmarks are divided
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.
76
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.
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.
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.
77
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 of client
partitions.
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.
A.3.2 Update
In this section update queries has been benchmarked. Table A.10 shows
nondefault values for variables used during the update benchmarks.
Variable Value
Query type Update
78
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.
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.
79
Maximum performance
This benchmark shows the maximum performance regarding updates. In figure
A.27 the lines represent the maximum processed queries for one timeslot using
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 of
client partitions.
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]
80
Figure A.28: Maximum updates processed for various timeslot lengths.
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.

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

650
600
550
500
Queries
450
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.
Maximum performance
This benchmark shows the maximum performance regarding selects. In figure
A.31 the lines represent the maximum processed queries for one timeslot using
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 of client
partitions.
82
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.
A.3.4 Alternate task scheduling

This benchmark shows the number of select queries processed when using a
different task scheduling. The task scheduling used here is the Yield only
scheduling. Table A.12 shows the variables with non-default values used in this
benchmark. Figure A.33 and figure A.34 show the benchmark results for average
respectively maximum performance.

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
partitions.
83
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
partitions. The lines represent the maximum processed queries using different timeslot
lengths.
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.
84

35
50 ms
30 100 ms
150 ms
25
Queries
20
15
10
0
1 2 3 4 5 6 7 8
Clients
partitions. No primary key is used.
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.
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.
85
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
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.
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
response sizes when sorting is applied, see figure A.39. Table A.14 shows
nondefault variables used in this benchmark.
86
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
Figure A.39: Average and maximum processed selects are displayed. Each query asks for
128 rows.
With sort
response 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.
Variable Value
Query type Select
Query response size 128 Rows (16 cols)
Sort result Yes
87
Raima: Average and maximum select performance, 128 sorted rows response
8
5
Queries
2 Average 50 ms
Maximum 50 ms
0
1 2 3 4 5 6 7 8
Clients
Figure A.40: Average and maximum processed selects are displayed. Each query asks for
128. Results are sorted in an ascending order by an non-indexed column.
88
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
extraordinä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 Dept. Of Computer and Information
(elektronisk version) Science
58183 LINKÖPING
2010-06-20
Språk
Typ av publikation
Svenska ISBN (licentiatavhandling)
X Annat (ange nedan) Licentiatavhandling
X Examensarbete
C-uppsats
Engelska/English ISRN LIU-IDA/LITH-EX-A--10/010--SE
D-uppsats
Antal sidor Rapport
105 Serietitel (licentiatavhandling)
Annat (ange nedan)
Serienummer/ISSN (licentiatavhandling)
URL 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.
Antal sidor: 105

Nyckelord
ARINC 653, INTEGRATED MODULAR AVIONICS, EMBEDDED DATABSES, SAFETY-CRITICAL, REAL-TIME
OPERATING SYSTEM, VXWORKS

Full Text 01

Uploaded by

Copyright:

Available Formats

You might also like

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

Martin Fri Jon

Usage of databases in ARINC 653-compatible

Martin Fri Jon

Supervisor: Magnus Vesterlund

3 System design and implementation 26

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

6 Discussion and Conclusion 64

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.

number of client partitions. . . . . . . . . . . . . . . . . . . . . . 92

App 1 App 2 App 3 DB

RTOS (ARINC 653)

• Implement a database API for communication between the applicationsand

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

of simultaneous clients and scheduling. Then evaluate the use of databases in

Martin’s part is focused towards ARINC 653 and the interpartition

• 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

Chapter 4 Contains benchmarking graphs and their analyses.

2.1 Safety-critical airplane systems

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

• Large reduction of safety margins or functional capabilities.

• Physical distress or higher workload such as the crew could not be

• Increased ejuries to a small number of the occupants.ffects on occupants

• Reduction of safety margins or functional capabilities.

• Significant increased workload of the crew.

• Possible discomfort of the occupants including injuries.

No Effect A failure of this type would not affect the operational

Software safety levels

2.2 Avionics architecture

Federated System Integrated Modular Avionics

Air Data FMS Mission

2.2.1 Federated architecture

power system. This leads to more electronics leading to a higher power

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

• Effective use of hardware

• Easy to certify new modules

• COTS, Commercial of the shelf

Drawbacks of an IMA architecture are:

• Complex platform certification

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

2.3 ARINC 653

Specification details The ARINC 653 specification consists of three parts:

• Part 2: Extended services

• Part 3: Test Compliance

2.3.1 Part 1 - Required Services