Download Institutionen för datavetenskap Usage of databases in ARINC 653-compatible real-time systems Martin Fri

Institutionen för datavetenskap
Department of Computer and Information Science
Final thesis
Usage of databases in ARINC 653-compatible
real-time systems
by
Martin Fri
Jon Börjesson
LIU-IDA/LITH-EX-A——10/010--SE
2010-05-10
Linköpings universitet
SE-581 83 Linköping, Sweden
Linköpings universitet
581 83 Linköping
Linköping University
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
Supervisor:
Magnus Vesterlund
Saab Aerosystems
Examiner:
Professor Simin Nadjm-Tehrani
Department of Computer and Information Science
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, EMBEDDED DATABASES, SAFETY-CRITICAL, REAL-TIME OPERATING
SYSTEM, VXWORKS
Contents
1 Introduction
1.1 Background . . . . .
1.2 Purpose . . . . . . .
1.3 Problem description
1.3.1 Objectives . .
1.3.2 Method . . .
1.3.3 Limitations .
1.4 Document structure
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Background
2.1 Safety-critical airplane systems . . . . .
2.1.1 DO-178B . . . . . . . . . . . . .
2.2 Avionics architecture . . . . . . . . . . .
2.2.1 Federated architecture . . . . . .
2.2.2 IMA architecture . . . . . . . . .
2.3 ARINC 653 . . . . . . . . . . . . . . . .
2.3.1 Part 1 - Required Services . . . .
2.3.2 Part 2 and 3 - Extended Services
2.4 VxWorks . . . . . . . . . . . . . . . . .
2.4.1 Configuration and building . . .
2.4.2 Configuration record . . . . . . .
2.4.3 System image . . . . . . . . . . .
2.4.4 Memory . . . . . . . . . . . . . .
2.4.5 Partitions and partition OSes . .
2.4.6 Port protocol . . . . . . . . . . .
2.4.7 Simulator . . . . . . . . . . . . .
2.5 Databases . . . . . . . . . . . . . . . . .
2.5.1 ODBC . . . . . . . . . . . . . . .
2.5.2 MySQL . . . . . . . . . . . . . .
2.5.3 SQLite . . . . . . . . . . . . . . .
2.5.4 Mimer SQL . . . . . . . . . . . .
2.5.5 Raima . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
8
8
9
9
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
and Test Compliance .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
12
12
13
14
14
18
19
19
19
19
20
21
22
22
22
23
23
23
24
25
.
.
.
.
26
26
28
29
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 System design and implementation
3.1 Architecture overview . . . . . . . . . . . .
3.1.1 Interpartition communication design
3.2 Database modules . . . . . . . . . . . . . .
3.2.1 Client version . . . . . . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
CONTENTS
3.3
3.4
3.5
3.2.2 Server version . . . . . . . . . . . . . . .
3.2.3 Server and Client interaction - Protocol
Transmission module . . . . . . . . . . . . . . .
3.3.1 Ports . . . . . . . . . . . . . . . . . . . .
3.3.2 Transmission protocol . . . . . . . . . .
Databases . . . . . . . . . . . . . . . . . . . . .
3.4.1 Filesystem . . . . . . . . . . . . . . . . .
3.4.2 SQLite specific . . . . . . . . . . . . . .
3.4.3 RAIMA specific . . . . . . . . . . . . . .
Database adapters . . . . . . . . . . . . . . . .
3.5.1 Interface . . . . . . . . . . . . . . . . . .
3.5.2 SQLite adapter . . . . . . . . . . . . . .
3.5.3 Raima adapter . . . . . . . . . . . . . .
3.5.4 Query result . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
33
37
37
38
41
41
42
43
43
43
43
44
45
4 Benchmarking
4.1 Environment . . . . . . . . . . .
4.1.1 Simulator . . . . . . . . .
4.1.2 Variables . . . . . . . . .
4.1.3 Measurement . . . . . . .
4.2 Benchmark graphs . . . . . . . .
4.2.1 SQLite Insert . . . . . . .
4.2.2 SQLite task scheduling . .
4.2.3 SQLite select . . . . . . .
4.2.4 Raima select . . . . . . .
4.3 Benchmark graphs analysis . . .
4.3.1 Deviation . . . . . . . . .
4.3.2 Average calculation issues
4.3.3 Five clients top . . . . . .
4.3.4 Scaling . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
46
46
47
48
48
50
51
52
53
53
53
54
55
5 Comparisons between SQLite and
5.1 Insert performance . . . . . . . .
5.2 Update performance . . . . . . .
5.3 Select performance . . . . . . . .
5.4 No primary key . . . . . . . . . .
5.5 Task scheduling . . . . . . . . . .
5.6 Response sizes . . . . . . . . . .
5.7 Summary . . . . . . . . . . . . .
Raima
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
56
58
59
60
61
62
63
6 Discussion and Conclusion
6.1 Performance . . . . . . . . . .
6.1.1 Database comparison
6.1.2 Scalability . . . . . . .
6.1.3 Measurement issues .
6.2 Design and implementation .
6.3 Usage and Certification . . .
6.4 Future work . . . . . . . . . .
6.5 Final words . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
64
64
64
64
65
65
66
67
67
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
CONTENTS
A Benchmark graphs
A.1 Variables . . . . . . . . . . . . .
A.2 SQLite . . . . . . . . . . . . . . .
A.2.1 Insert . . . . . . . . . . .
A.2.2 Update . . . . . . . . . .
A.2.3 Select . . . . . . . . . . .
A.2.4 Alternate task scheduling
A.2.5 No primary key . . . . . .
A.2.6 Large response sizes . . .
A.3 Raima . . . . . . . . . . . . . . .
A.3.1 Insert . . . . . . . . . . .
A.3.2 Update . . . . . . . . . .
A.3.3 Select . . . . . . . . . . .
A.3.4 Alternate task scheduling
A.3.5 No primary key . . . . . .
A.3.6 Large response sizes . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
70
. 70
. 70
. 70
. 74
. 77
. 80
. 82
. 85
. 87
. 87
. 90
. 94
. 97
. 99
. 102
List of Figures
1.1
An ARINC 653 system. . . . . . . . . . . . . . . . . . . . . . . .
8
2.1
2.2
2.3
A federated architecture and an Integrated Modular Avionics architecture. [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
One cycle using the round robin partition scheduling. [6] . . . . .
VxWorks memory allocation example. [11] . . . . . . . . . . . . .
12
15
20
3.1
3.2
3.3
3.4
3.5
3.6
3.7
System design. . . . . . . . . . . . . . . . . . . . . . . . . . .
Channel design used in this system. . . . . . . . . . . . . . .
Statement, connection and environment relations. . . . . . . .
Flowchart describing the SQLFetch routine. . . . . . . . . . .
Flowchart of a task in the database server module. . . . . . .
A connection deadlock caused by Sender Block port protocol.
Filesystem structure. . . . . . . . . . . . . . . . . . . . . . . .
27
28
30
31
36
40
42
4.1
Average inserts processed during one timeslot for different number of client partitions. . . . . . . . . . . . . . . . . . . . . . . . .
Average number of inserts processed during one timeslot of various length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Average selects processed during one timeslot for different numbers of client partitions and timeslot lengths. Task scheduling
used is Yield only. . . . . . . . . . . . . . . . . . . . . . . . . . .
Average selects processed during one timeslot for different numbers of client partitions. . . . . . . . . . . . . . . . . . . . . . . .
Average selects processed during one timeslot for different number of client partitions. The lines represent the average processed
queries using different timeslot lengths. . . . . . . . . . . . . . . .
With one client, the server manages to process all 1024 queries
in one time frame. . . . . . . . . . . . . . . . . . . . . . . . . . .
With two clients, the server cannot process 2*1024 in two timeslots due to context switches. An extra time frame is required. .
The average processing speed is faster than 1024 queries per
timeslot, but it is not fast enought to earn an entire timeslot. . .
4.2
4.3
4.4
4.5
4.6
4.7
4.8
5.1
5.2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Comparison between average insert values in SQLite and Raima.
Timeslots used in the graphs are 50 ms and 100ms. . . . . . . .
Comparison between average update values in SQLite and Raima.
Timeslot lengths are 50 ms and 100 ms. . . . . . . . . . . . . . .
4
48
49
50
51
52
54
54
54
57
58
LIST OF FIGURES
5.3
5.4
5.5
5.6
5.7
Comparison between average select values in SQLite and Raima.
Timeslot lengths are 50 ms and 100 ms. . . . . . . . . . . . . . .
Comparison between average select values in SQLite and Raima
with and without primary key. Timeslot length is 50 ms. . . . . .
Comparison between average select queries using different task
schedules in SQLite and Raima. Timeslot length is 50 ms. . . . .
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. . . . . . . . . . . . . . . . . . . . .
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. . . . . . . . . . . . . . . . . . . . .
A.1 Average inserts processed during one timeslot for different number of client partitions. . . . . . . . . . . . . . . . . . . . . . . .
A.2 Average no. inserts processed during one timeslot of various
length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Maximum inserts processed during one timeslot for different number of client partitions. . . . . . . . . . . . . . . . . . . . . . . . .
A.4 Maximum inserts processed for various timeslot lengths. . . . . .
A.5 Average updates processed during one timeslot for different number of client partitions. . . . . . . . . . . . . . . . . . . . . . . .
A.6 Average no. updates processed during one timeslot of various
length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.7 Maximum updates processed during one timeslot for different
number of client partitions. . . . . . . . . . . . . . . . . . . . . .
A.8 Maximum updates processed for various timeslot lengths. . . . .
A.9 Average selects processed during one timeslot for different numbers of client partitions. . . . . . . . . . . . . . . . . . . . . . . .
A.10 Average no. selects processed during one timeslot of various
length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.11 Maximum selects processed during one timeslot for different numbers of client partitions. . . . . . . . . . . . . . . . . . . . . . . .
A.12 Maximum no. selects processed during one timeslot of various
length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.13 Average selects processed during one timeslot for different numbers of client partitions and timeslot lengths. . . . . . . . . . . .
A.14 Maximum selects processed during one timeslot for different numbers of client partitions and timeslot lengths. . . . . . . . . . . .
A.15 Average selects processed during one timeslot for different numbers of client partitions and timeslot lengths. . . . . . . . . . . .
A.16 Average no. selects processed during one timeslot of various length.
A.17 Maximum selects processed during one timeslot for different numbers of client partitions and timeslot lengths. . . . . . . . . . . .
A.18 Maximum no. selects processed during one timeslot of various
length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.19 Average and maximum processed select queries. These selects
ask for128 rows. No sorting is applied. . . . . . . . . . . . . . . .
5
59
60
61
62
62
71
72
73
73
74
75
76
76
77
78
79
79
80
81
82
83
84
84
85
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 inserts processed during one timeslot for different number of client partitions. . . . . . . . . . . . . . . . . . . . . . . . .
A.22 Average inserts processed for various timeslot lengths. . . . . . .
A.23 Maximum inserts processed during one timeslot for different number of client partitions. . . . . . . . . . . . . . . . . . . . . . . . .
A.24 Maximum inserts processed for various timeslot lengths. . . . . .
A.25 Average number of updates processed during one timeslot for
different number of client partitions. . . . . . . . . . . . . . . . .
A.26 Average number of updates processed for various timeslot lengths.
91
A.27 Maximum updates processed during one timeslot for different
number of client partitions. . . . . . . . . . . . . . . . . . . . . .
A.28 Maximum updates processed for various timeslot lengths. . . . .
A.29 Average selects processed during one timeslot for different number of client partitions. . . . . . . . . . . . . . . . . . . . . . . . .
A.30 Average selects for various timeslot lengths. . . . . . . . . . . . .
A.31 Maximum selects processed during one timeslot for different number of client partitions. . . . . . . . . . . . . . . . . . . . . . . . .
A.32 Maximum selects processed for various timeslot lengths. . . . .
A.33 Average selects processed during one timeslot for different number of client partitions. . . . . . . . . . . . . . . . . . . . . . . . .
A.34 Maximum selects processed during one timeslot for different number of client partitions. The lines represent the maximum processed queries using different timeslot lengths. . . . . . . . . . . .
A.35 Average selects processed during one timeslot for different number of client partitions. No primary key is used. . . . . . . . . . .
A.36 Average selects processed for various timeslot lengths. No primary key is used. . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.37 Maximum selects processed during one timeslot for different number of client partitions. No primary key is used. . . . . . . . . . .
A.38 Maximum select processed for various timeslot lengths. No primary key is used. . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.39 Average and maximum processed selects are displayed. Each
query asks for 128 rows. . . . . . . . . . . . . . . . . . . . . . . .
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. . . . . . . . . . . . . . . . . . . . . . . .
86
87
88
89
89
90
92
93
94
95
96
96
97
98
99
100
101
101
102
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
7
CHAPTER 1. INTRODUCTION
App 1
partition
App 2
partition
App 3
partition
DB
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.
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 applications
and the database, that will hide the ARINC-layer from the application
and the database.
• Find the system’s performance thresholds according to throughput, number of simultaneous clients and scheduling. Then evaluate the use of
databases in an ARINC 653-system.
1.3.2
Method
The workload will be divided into two parts since there are two participating
students in this thesis.
8
CHAPTER 1. INTRODUCTION
Martin’s part is focused towards ARINC 653 and the interpartition 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.
9
Chapter 2
Background
This section will provide the reader with essential background information.
2.1
Safety-critical airplane systems
Systems embedded in airplanes are safety-critical software. A software failure
in such a system can cause minor to catastrophic events.
When developing safety critical software for aircrafts, there are some special
issues that arises. Since aircraft software is a type of embedded system there are
limitations on the memory available. This causes the developer to use special
techniques to ensure that memory boundaries are not overflowed.
Aircraft software is often also safety-critical real-time systems; in theses
systems timing and reliability are large concerns. First, deadlines for important
tasks should never be missed. This forces the system to have some kind of
scheduling that ensures that deadlines are not overrun. Secondly, safety-critical
real-time systems must be reliable. It would not do if for example an aircraft or
a respirator suddenly stopped working. This issue leads to strict requirements
on not only the software but also the hardware. Hardware available for this kind
of systems must be closely monitored and tested before they are allowed to be
used. These requirements leads to that the hardware available are many years
old and have poor performance compared to the modern, high performance
hardware. [3] [5] [7]
2.1.1
DO-178B
DO-178B, Software Considerations in Airborne Systems and Equipment 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
10
CHAPTER 2. BACKGROUND
know about the result is that it fulfills this poor requirement specification. In
other words, bad input gives bad, but certified output. [3] [5]
Failure categories
Failures in an airborne system can be categorized in five different types according
to the DO-178B document:
Catastrophic A failure that will prevent a continuous safe flight and landing.
Results of a catastrophic failure are multiple fatalities among the occupants and
probably loss of the aircraft.
Hazardous / Severe-Major A failure that would reduce the capabilities
of the aircraft or the ability of the crew to handle more difficult operating
conditions to the extent of:
• Large reduction of safety margins or functional capabilities.
• Physical distress or higher workload such as the crew could not be relied
upon to perform their tasks accurately or completely.
• Increased effects on occupants including seriously or potentially fatal injuries to a small number of the occupants.
Major A failure that would reduce the capabilities of the aircraft and the
ability of the crew to do their work to any extent of:
• Reduction of safety margins or functional capabilities.
• Significant increased workload of the crew.
• Possible discomfort of the occupants including injuries.
Minor A failure that would not significantly reduce the aircraft safety and the
crew’s workload are still within their capabilities. Minor failures may include
slight reduction of safety margins and functional capabilities, a slight increase
in workload or some inconvenience for the occupants.
No Effect A failure of this type would not affect the operational capabilities
of the aircraft or increase crew workload. [3] [4]
Software safety levels
Software in airplanes has different safety levels depending on what kind of 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.
11
CHAPTER 2. BACKGROUND
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.
Integrated Modular Avionics
(IMA)
Federated System
Air Data
computer
Mission computer
Flight
Management
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 power system. This leads to more electronics leading to a higher power
consumption, and that the weight is increased.
In today’s airplanes weight and space is extremely limited. They are so full
of electronics that it is hard to upgrade with new functionality. This together
12
CHAPTER 2. BACKGROUND
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 nature of IMA systems. But when this has been done and the platform,
which is the real-time operating system, RTOS, and the functions provided by
the module OS, is certified, new modules are easy to certify.
Advantages of an IMA architecture are:
• Effective use of hardware
• Easy to certify new modules
13
CHAPTER 2. BACKGROUND
• Reuse of software and hardware
• COTS, Commercial of the shelf
Drawbacks of an IMA architecture are:
• Complex design needed
• Complex platform certification
[5] [7] [8] [9]
2.3
ARINC 653
ARINC 653 is a software specification for space and time partitioning in the
IMA architecture. Real-time operating systems implementing this standard
will be able to cope with the memory and real-time constraints. ARINC is an
abbreviation for Aeronautical Radio, Inc which is the company that developed
the standard.
ARINC 653’s general goal is to provide an interface as well as specifying the
API behaviour between the operating system and the application software.
In ARINC 653, applications are run in independent partitions which are
scheduled by the RTOS. Since each application is run independent of other
applications it is possible for the applications to have different safety levels, e.g.
ARINC 653 supports DO-178B level A-E systems on the same processor. For
more information see section 2.1.1. [1] [7]
Specification details The ARINC 653 specification consists of three parts:
• Part 1: Required services
• Part 2: Extended services
• Part 3: Test Compliance
The required services part defines the minimum functionality provided by
the RTOS to the applications. This is considered to be the industry standard
interface. The extended services define optional functionality while the test
compliance part defines how to establish compliance to part 1. [1]
Currently, there is no RTOS that supports all three parts. In fact, no one
even fully supports part 2 or 3. The existing RTOS’s supporting ARINC 653
only supports part 1. Although, some RTOS’s have implemented some services
defined in part 2, extended services, but these solutions are vendor specific and
do not fully comply with the specification. [5]
2.3.1
Part 1 - Required Services
ARINC 653 specification part 1, required services, describes how the most 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
14
CHAPTER 2. BACKGROUND
• 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
#1
Partition
#2
Partition
#3
Partition
#4
Minor Frame #1
200 ms
Minor Frame #2
150 ms
Minor Frame #3
250 ms
Minor Frame #4
200 ms
Major Frame
repeat
Time
Figure 2.2: One cycle using the round robin partition scheduling. [6]
Modes A partition can be in four different modes: Idle, normal, coldstart and
warmstart.
IDLE When in this mode, the partition is not initialized and it is not executing
any processes. However, the partition’s assigned timeslots are unchanged.
15
CHAPTER 2. BACKGROUND
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 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]
16
CHAPTER 2. BACKGROUND
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.
Queuing mode In queuing mode, messages are stored in a queue at the
port. The size of this queue and its element sizes are configured before execution.
A message sent from the source partition is buffered in the port’s message
queue while waiting to be transmitted by the channel. At the receiving end,
incoming messages are stored in the destination port’s message queue until its
partition receives the message.
Message queues in the queuing mode are following the First In First Out,
FIFO, protocol. This allow ports to indicate overflow occurrences. However,
it is the application’s job to manage the overflow situations and make sure no
messages are lost. [1]
17
CHAPTER 2. BACKGROUND
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
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
18
CHAPTER 2. BACKGROUND
• 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
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:
19
CHAPTER 2. BACKGROUND
• The virtual addresses of shared libraries must be specified. The address
depends on the memory configuration of the core OS, and the size and
address of other shared libraries in the module. To calculate a reasonable
virtual address for each shared library a map of the virtual memory needs
to be created.
• To build applications, stub files for shared libraries used by the applications 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-2
App-1
App-2
Blackboard
Blackboard
POS-2
App-1
App-2
App-1
POS-1
POS-2
ConfigRecord
COS
Rom
Blackboard
POS-1
POS-2
ConfigRecord
POS-1
ConfigRecord ConfigRecord
COS
COS
COS
Ram
App-1
App-2
Figure 2.3: VxWorks memory allocation example. [11]
Physical memory
The physical memory is made up of the read-only memory, ROM, and the
random-access memory, RAM.
20
CHAPTER 2. BACKGROUND
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.
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
21
CHAPTER 2. BACKGROUND
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 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 gen-
22
CHAPTER 2. BACKGROUND
eral. A more general solution would save both time and money, since it would
be easier to reuse.
This chapter contains information about the databases that have been 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. 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.
23
CHAPTER 2. BACKGROUND
The database is written entirely in ANSI-C, and makes use of a very small
subset of the standard C library. It’s very well tested; with tests that have 100%
branch coverage. The source has over 65.000 lines of code while test code and
test scripts have over 45.000.000 lines of code.
It’s possible to get the source code as a single C file. This makes it very easy
to compile and link into an application. When compiled, SQLite only takes
about 300 kB memory space. To make it even smaller, it’s possible to compile
it without some features to make it as small as 190 kB.
Data storage
All data is stored in a single database file. As long as the file is readable for the
process, SQLite can perform lookups in the database. If the file is writable for
the process, SQLite can store or change things in the database. The database file
format is cross-platform, which means that the database can be moved around
among different hardware and software systems. Many other DBMS require
that the database is dumped and restored when moved to another system.
SQLite is using a manifest typing, not static typing as most other DBMS.
This means that any type of data can be stored in any column, except for an
integer primary key column. The data type is a property of the data value itself.
Records have variable lengths. This means that only the amount of disk
space needed to store data in a record is used. Many other DBMS’ have fixed
length records, which mean that a text column that can store up to 100 bytes,
always takes 100 bytes of disk space.
One thing that is still experimental but could be useful, is that it is possible
to specify which memory allocation routines SQLite should use. This is probably
necessary if one wants to be able to certify a system that is using SQLite.
Locking technique
A single database file can be in five different locking states. To keep track of
the locks, SQLite uses a page of the database file. It uses standard file locks to
lock different bytes in this page. One byte for each locking state. The lock page
is never read or written by the database. In a POSIX system setting locks is
done via fcntl() calls.[13]
2.5.4
Mimer SQL
Mimer SQL is a relational database manager system from Mimer Information
Technology AB.
Mimer SQL is a SQL database with full SQL support, transactions, triggers
etc. There is an embedded version of Mimer, with native VxWork-support.
The highly performance-optimized storage mechanism ensures that no 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
24
CHAPTER 2. BACKGROUND
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 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 providing
functionality to lower layer.
• Layer 2 - Database API, Query/Result transport protocol.
• Layer 1 - Interpartition communication.
• ”Layer 0” - RTOS, handled by VxWorks.
Clients and Servers A partition containing a transmission module, database
client module and an application is called a client. A partition containing a
transmission module, database server module, database adapter and a database
is called a server.
This implementation is able to handle multiple clients which use one or more
servers. However, the main configuration is for one server partition and multiple
client partitions.
26
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
Partition scheduling Both client and server partitions are scheduled with
a cyclic schedule that resembles round robin, i.e. all timeslots are of the same
length and each partition has only one timeslot per major cycle. See Partition
Management in section 2.3.1 for more information about partition scheduling
in ARINC 653.
Database partition
Application partition
Adapter
Application
Database
Database module (server)
Database module (client)
Transmission module
Transmission module
RTOS (ARINC 653)
Figure 3.1: System design.
27
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
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.
The benefit with this design is the application independence. E.g. if one
port buffer is overflowed, only this port’s connection will be affected. The other
connections can still continue to function. Another benefit is that the server will
know which client sent a message. This is because all channels are configured
before the system is run.
The drawback with this approach is that it requires many ports and channels
to be configured which requires a lot of memory.
28
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
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
SQLFreeHandle
SQLConnect
SQLDisconnect
SQLExecDirect
SQLFetch
SQLBindCol
SQLNumResultCols
SQLRowCount
SQLEndTran
Allocate handle of type: environment, connection or statement.
Free specified handle.
Connect to specified database.
Disconnect from database.
Execute a query in connected database.
Move results from queries into bound columns.
Bind buffers to database columns.
Get the number of columns in result data set.
Get the number of rows in result data set.
End transaction. A new transaction begins automatically.
Table 3.1: Database API
Design
ODBC specifies three different datatypes. They are as follows:
Statements
Connections
Environments
Contains a query and when returned, the result of
the query.
Every connection contains handles to the ports associated with this connection. It also holds all statement handles used by this connection.
Contains port names and all connections operating
on these ports.
See figure 3.3 for information about how these data types relate to each
other.
Before a query could be sent, an environment must be created. Inside this
environment multiple connections can be created. And inside every connection,
29
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
«datatype»
Statement
*
1
1
1
«datatype»
Connection
*
1
1
1
«datatype»
Environment
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 repeated until a matching result is found. When this happens, the result
is moved into the specified statement. The data is then moved into the bound
30
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
buffers before the routine exit.
SQLFetch is
called with a
specific statement
pointer
Receive and
merge messages
to get one result
from the inport
'RHVWKHUHVXOW¶VLGPDWFKWKH
VSHFLILHGVWDWHPHQW¶VLG?
NO
Move result into the
statement which the
UHVXOWV¶VWDWHPHQW
pointer points to
YES
Move the result into
the specified
Statement and then
move the result to the
bound columns
Exit SQLFetch
Figure 3.4: Flowchart describing the SQLFetch routine.
A short summary : All queries with results stored earlier in the inport queue,
in front of the matching query, will get their results moved into their statements
for faster access in the future. The result belonging to the specified query is
moved into the statement’s bound columns and are made available for layer
three applications. All queries who have their result stored behind the specified
query in the inport queue will not get their result moved into their statements.
These results have to stay in the port queue until another SQLFetch routine is
called in which these operations are repeated.
Analysis of design choices As mentioned in the previous paragraph, all
data in front of the fetch routine’s specified statement in the port are moved to
the statements to which they belong at once. The SQLFetch routine wants the
result of a specific query, and to get that result the system must go through all
data which is located in front of this result. The unwanted data can’t just be
destroyed since there is another statement waiting for just this data. Therefore
the read unwanted data is moved into its statement before the routine continues.
One drawback with locally stored results in statements is that there is a
possibility of memory issues. These can occur when there are many statements
and each of them contains a large rowset as a result.
An alternative solution is to discard unwanted data and retransmit it later.
This approach requires both acknowledges and retransmits and would also cause
a disorder in the statements received. Performance will dramatically decrease
when using this method due to the inappropriate combination of retransmits
and the partition scheduling algorithm.
31
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
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.
32
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
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.
33
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
Id
Statement pointer
Data size
Command type
Unique id of a sent query.
Pointer to the statement holding the query in the client application.
Size of the data following the header.
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 from a query which didn’t generate a rowset or that an error
occurred. Neither one caused a rowset to be created.
Data is transferred in different ways depending on these command types. See
table 3.3.
34
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
Command type
NONE
QUERY
END TRAN
Data
No package will be sent
< char∗ >Query as a string
< int >Commit or Rollback
< int > Nr rows, < int > Nr cols
< int > length colname(1), < char∗ > colname(1)
RESPONSE ROWSET
...
< int > length colname(nr cols), < char∗ >
colname(Nr Cols),
< int > size cell(row1, col1) , < char∗ >
cell(row1, col1)
...
< int > size cell(nr rows, nr cols), < char∗ >
cell(nr rows, nr cols)
RESPONSE ERROR OR NO ROWSET No data
Table 3.3: Data contents
35
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
Connect to db adapter
Receive header size
from transmission
layer
Allocate memory for
data
Receive data from
transmission layer
Parse incoming
data
Execute query in
database adapter
[QUERY]
Type of data
[OTHER]
Print error mesage
[END TRAN]
Adapter has
result
[NO]
Response type =
NONE
[YES]
Get result from adapter
and set Resonse type =
ROWSET_RESPONSE
Send header and
data of response
to client
Free allocated
memory
Figure 3.5: Flowchart of a task in the database server module.
36
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
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, P ortsize =
buf f er size ∗ queue length.
Large data streams that cannot fit inside one port buffer must be split into
several smaller parts. There are three different cases that can occur during the
fragmentation:
Case 1 Message fits in one buffer. It occupies one queue spot.
Case 2 Message doesn’t fit in one buffer but it fits in several buffers. This
message occupies several queue spots but the queue is not full.
Case 3 Message is too large and fills all queue buffers. This means that the
queue is full and the port is overflowed. The port’s behavior in this case
depends on which port protocol that is used.
Note that several large messages can be fragmented into the queue at the
same time which increases the risk of port overflow occurrences.
Port protocols
As mention before in section 2.4.6 VxWorks supports two different port 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 kind of block functionality would still be necessary. This is because
37
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
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
overflows won’t happen. This approach is possible because of the predictability
of the system. All systems must be carefully analyzed and configured not to send
38
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
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.
39
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
Free space
Occupied space
Server inport
Client inport
Client is switched in
Queries
Client sends queries but
gets blocked when the
server inport is full
Server is switched in
The server processes
some of the incoming
queries and sends back
responses. 7KHFOLHQW¶V
inport gets full and the
server thread is blocked
Responses
Client is switched in
Queries
$VWKHVHUYHU¶VLQSRUW
queue is not full anymore,
the client can resume its
execution where it halted,
i.e. continue sending
queries
Both inports are full - Deadlock!
Figure 3.6: A connection deadlock caused by Sender Block port protocol.
40
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
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.
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.
41
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
Figure 3.7: Filesystem structure.
The filesystem can have fixed numbers of files, open files and file descriptors.
Since there is a fixed maximum number of each struct, they are allocated in fixed
sized C arrays.
To avoid unnecessary performance issues, stacks are used to keep track of
free file descriptors and free files. With stacks, free descriptors can be found in a
constant time since there is no need of iterating the array with descriptors. The
filesystem is using files with static sizes. This makes reading and writing fast,
since all data is stored in one big chunk, and not spread over blocks. However,
this may lead to unused memory or full files. This means that the filesystem
must be configured carefully.
File locking
At first, file level locking was implemented. An entire file could be locked, not
parts of the file. However, it turned out that SQLite needs byte level locking,
and the ability to use both read and write locks. All locking related operations
are done via the fcntl() and the flock() functions.
3.4.2
SQLite specific
SQLite source code can be downloaded as a single source file. The code doesn’t
depend on any unusual libraries and is POSIX compatible. This suits very well
for VxWorks 653. It’s therefore not much work needed to get the database up
and running.
42
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
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
43
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
ready to be fetched. If the status code is SQLITE DONE there is nothing more
to be done with this statement.
The status code is used to determine whether the query is a select or not.
If the return value is SQLITE ROW the query must have been a select, or
something else that resulted in one or more rows. However, if the query is a
select that returns no rows, its impossible to determine whether the query is a
select or not. Luckily, the database module only needs to know if there are any
rows, not what type of query that just got executed.
Transactions
SQLite is using pessimistic concurrency control. This, together with it’s locking
techniques makes transactions inefficient when the database is used by multiple
connections.
When a query that results in a write to the database is executed in a 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().
44
CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION
When the SDDL has been parsed the database must be initialized. This is
also, usually, made with a command-line tool, but it’s possible to link these into
the application too and call the main function initdb main(). The result of the
parsing is the database files specified by the SDDL.
Files
Raima is using more files than SQLite, so the filesystem must be planned more
than with SQLite. At least three files is used during runtime, after the database
has been created; database, index and log. During database creation the SDDL
file is needed among others.
Result handling
To fetch the result from a query in Raima is very alike the way it’s done i
SQLite. The result must be iterated, column value types checked to get the size
needed in the row etc.
3.5.4
Query result
If a query results in one or more rows, a rowset can be retrieved with the
adapters fetch function.
A rowset is a collection of rows. It provides an interface for getting 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.
45
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
46
CHAPTER 4. BENCHMARKING
between partitions. Table size is the initialization size of the table used in the
benchmarks. Query response size is the size of the resulting rowset that will be
sent back to the client. Sort result is if the resulting rowset is sorted. Client
send quota is the number of queries each client will send.
Variable
Number of client partitions
Timeslot length
Task scheduling
Primary key
Port buffer size
Port queue length
Table size
Query response size
Sort result
Client send quota
Value
1 .. 8.
50,100,150 ms.
Round robin.
Yes.
1024 bytes.
512.
1000 rows, 16 columns
1 Row(16 cols).
No
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.
N o. sent queries per client ∗ N o. clients
P artition switches required
(4.1)
Every benchmark configuration has been run five times. A mean value has
then been calculated from these five runs. For example, a mean value of ”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
Average no. processed queries =
47
CHAPTER 4. BENCHMARKING
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 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
150 ms
1000
900
800
Queries
700
600
500
400
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure 4.1: Average inserts processed during one timeslot for different number of
client partitions.
48
CHAPTER 4. BENCHMARKING
SQLite: Average insert performance
1100
1000
900
Queries
800
700
1 Client
2 Clients
3 Clients
4 Clients
5 Clients
6 Cleints
7 Clients
8 Clients
600
500
400
300
50
100
Timeslot [ms]
150
Figure 4.2: Average number of inserts processed during one timeslot of various
length.
49
CHAPTER 4. BENCHMARKING
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
100 ms
150 ms
900
800
Queries
700
600
500
400
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure 4.3: Average selects processed during one timeslot for different numbers of
client partitions and timeslot lengths. Task scheduling used is Yield only.
50
CHAPTER 4. BENCHMARKING
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.
SQLite: Average select performance
1100
50 ms
100 ms
150 ms
1000
900
800
Queries
700
600
500
400
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure 4.4: Average selects processed during one timeslot for different numbers of
client partitions.
51
CHAPTER 4. BENCHMARKING
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
Queries
500
400
50 ms
100 ms
150 ms
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure 4.5: Average selects processed during one timeslot for different number of
client partitions. The lines represent the average processed queries using different
timeslot lengths.
52
CHAPTER 4. BENCHMARKING
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 figure 4.7.
For every additionally added client, the affect of the extra required partition
switch will be less and less.
53
CHAPTER 4. BENCHMARKING
1024 queries
Fit in one frame
Database minor frame
Figure 4.6: With one client, the server manages to process all 1024 queries in one
time frame.
1024 queries
Doesn’t fit in one frame
Idling
Database minor frame
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
54
CHAPTER 4. BENCHMARKING
to the task scheduling in the simulator, which seems to work better with five
threads in combination with the partition timeslot length. This is just a guess
from our side since we have no verified explanation.
4.3.4
Scaling
Looking at the insert and update curves, it can be seen how they scale compared
to the timeslot length. Generally, it seems that between 50 ms and 150 ms they
are linear. However, for SQLite, they do not double the number of queries
processed when the timeslot length is doubled which is the case for Raima.
55
Chapter 5
Comparisons between
SQLite and Raima
This chapter contains comparison graphs between SQLite and Raima. The
150 ms curves have been omitted since they are often affected by the average
calculation issue as described in section 4.1.3 and section 4.3.2, i.e. 150 ms curves
are too unreliable. Mostly, only the 50 ms curves are shown in the figures. This
is because too many curves makes the graphs hard to decipher. Also, 50 ms is
the time that mostly resembles a real timeslot length. Only average values are
presented since they are more interesting than the less informative maximum
values.
5.1
Insert performance
Figure 5.1 contains four insert performance curves, two each from SQLite and
Raima. They shows the average number of insert queries processed in the server
during a timeslot of both 50 ms and 100 ms.
The figure clearly states a large speed advantage for SQLite. For both timeslots SQLite is processing approximately 150 queries more than Raima. This
indicates that SQLite is performing better for insert queries independent of
timeslot length.
56
CHAPTER 5. COMPARISONS BETWEEN SQLITE AND RAIMA
Insert comparison
600
Queries
500
400
300
200
Raima 50 ms
Raima 100 ms
SQLite 50 ms
SQLite 100 ms
100
0
1
2
3
4
Clients
5
6
7
8
Figure 5.1: Comparison between average insert values in SQLite and Raima. Timeslots used in the graphs are 50 ms and 100ms.
57
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
Queries
500
400
300
200
Raima 50 ms
Raima 100 ms
SQLite 50 ms
SQLite 100 ms
100
0
1
2
3
4
Clients
5
6
7
8
Figure 5.2: Comparison between average update values in SQLite and Raima. Timeslot lengths are 50 ms and 100 ms.
58
CHAPTER 5. COMPARISONS BETWEEN SQLITE AND RAIMA
5.3
Select performance
This is a comparison between SQLite’s and Raima’s select performance which
can be seen in figure 5.3. Both Raima and SQLite seem to almost double their
number of processed queries when the timeslot length is doubled from 50 ms to
100 ms. SQLite is definitely faster than Raima, especially for larger timeslots.
When looking at select performance, one must remember that these results
include more than just the query execution in the database. The resulting data
is copied to a rowset, which in turn is serialized before sent back to the client.
This overhead is equal for both SQLite and Raima, but affects SQLite more
since it performs queries faster and thereby gets a higher relative performance
loss.
Select comparison
600
Queries
500
400
300
200
Raima 50 ms
Raima 100 ms
SQLite 50 ms
SQLite 100 ms
100
0
1
2
3
4
Clients
5
6
7
8
Figure 5.3: Comparison between average select values in SQLite and Raima. Timeslot lengths are 50 ms and 100 ms.
59
CHAPTER 5. COMPARISONS BETWEEN SQLITE AND RAIMA
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
Queries
250
200
Raima with primary key
Raima without primary key
SQLite without primary key
SQLite with primary key
150
100
50
0
1
2
3
4
Clients
5
6
7
8
Figure 5.4: Comparison between average select values in SQLite and Raima with
and without primary key. Timeslot length is 50 ms.
60
CHAPTER 5. COMPARISONS BETWEEN SQLITE AND RAIMA
5.5
Task scheduling
This task scheduling analysis compares the two task scheduling methods used
in this thesis; Round robin with yield and Yield only. The comparison is made
with the 50 ms average select benchmarks. Figure 5.5 indicates quite similar
curves for the different scheduling approaches.
Yield only is a bit faster than Round robin and yield, for SQLite, but the
variation is quite small. This slight improvement can be credited to fewer task
switches in the database partition. For SQLite, when using round robin, the
number of processed queries in a task timeslot varies more than for Raima. This
leads to tasks finishing their processing in different round robin task cycles. A
finished task will then be switched in again the next cycle, even though it has
nothing to do. The task will yield and hand over to the next task. This adds
overhead and extra partition switches are needed.
For Raima, the tasks process queries with a uniform performance which
make the tasks finish in a consecutive order. This leads to less overhead and
small differences between the curves.
Task scheduling comparison
450
Raima − Round robin and yield
Raima − Yield only
SQLite − Round robin and yield
SQLite − Yield only
400
Queries
350
300
250
200
150
1
2
3
4
Client
5
6
7
8
Figure 5.5: Comparison between average select queries using different task schedules
in SQLite and Raima. Timeslot length is 50 ms.
61
CHAPTER 5. COMPARISONS BETWEEN SQLITE AND RAIMA
5.6
Response sizes
Response sizes of select queries can vary. In this section responses of size 128
rows are used. Figure 5.6 shows curves which either have sorted the results in
an ascending order by a non-indexed column or has unsorted result sets.
An interesting thing to notice is that Raima performs equally good for both
sorted and unsorted results. SQLite performs on the same level as Raima for
sorted results but is faster when the results are unsorted.
Sort comparison
11
SQLite − no sort
SQLite − sort
Raima − no sort
Raima − sort
10
9
8
Queries
7
6
5
4
3
2
1
0
1
2
3
4
Clients
5
6
7
8
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
Rows
1000
500
0
1
2
3
4
Clients
5
6
7
8
Figure 5.7: Comparison between single row select and 128 rows select queries in
SQLite and Raima. Average values are showed in the graph with timeslot length of
50 ms.
62
CHAPTER 5. COMPARISONS BETWEEN SQLITE AND RAIMA
5.7
Summary
In this section we summarize our observations for the selected timeslots and
scheduling approaches given the interpartition communication protocols and
adapters implemented.
• In general it appears that the system perform at its best for five clients,
both in SQLite and Raima, given the selected client loads and timeslots.
• The 150 ms measurements are often strange and unexpected. This can be
explained by the average metric used (equation 4.1) that depends on the
length of the time slot. used. Therefore 150 ms curves are less accurate
than the 50 ms and 100 ms curves.
• Most graphs are linear but a doubled timeslot won’t double the number
of processed queries. Excluded from this is the select performance graph.
• SQLite is overall much faster than Raima. Raima can only match SQLite
in the update performance benchmark.
The above summary is based on the benchmarks made in a simulator with
low time resolution, and the simulation were done in Windows on a desktop
computer. This implies that the benchmark results are not entirely reliable.
The benchmarked system is a system with certain properties. The results
and analyses are produced for this system and might not be applicable on other
systems.
63
Chapter 6
Discussion and Conclusion
This chapter presents a discussion and conclusion of this report.
6.1
Performance
The relation between performance and scalability, database comparisons, and
simulation details are discussed here.
6.1.1
Database comparison
The comparisons in the previous chapter showed that SQLite was overall much
faster than Raima. For us, this was a surprise. We expected Raima to be the
faster one mainly because it is a commercial database. The only test in which
Raima could match SQLite was in the update performance test.
As mentioned in section 2.5.5, Raima has two interfaces for accessing and
modifying data; an ODBC interface and a C interface. We used the ODBC
interface, which probably adds some overhead compared to the C interface.
One slow operation that is not required with the C interface is the SQL string
parsing.
Another thing with the C interface is that it provides C structs that matches
records in the database. This probably increases the performance of fetching
data since all data types and data sizes are known at compile time. In our
solution with ODBC interface, we must check what type of data a column 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
64
CHAPTER 6. DISCUSSION AND CONCLUSION
to use timeslots of zero length and still be able to process queries. This is
obviously impossible. Raima does not have this behavior at all which further
strengthens our conclusion that Raima’s performance is easier to estimate.
It should be noted that there are few different timeslot lengths measured
which makes the above discussion a bit uncertain. To validate these results,
more timeslots must be tested. The three timeslot lengths used in the benchmark were chosen because they are large enough to work with the simulator’s
low resolution, while they are low enough to avoid inappropriate large port
buffers. The timeslot lengths are also multiples of 50 which makes it easy to see
scalability issues.
As seen in most of the graphs, there is a peak at five clients. Even though
it’s not verified, this peak might be due to the combination of timeslot lengths
in the task and partition schedulings, and the VxWorks simulator. To make
things clear about this, new benchmarks in a target environment are needed to
get more trustworthy values.
6.1.3
Measurement issues
The simulator, VxSim, introduces some error sources to the benchmarks. 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.
65
CHAPTER 6. DISCUSSION AND CONCLUSION
ODBC interface An ODBC interface was chosen as the interface towards
application developers, mainly because it is an easy and well known interface.
The developers will be able to use this interface almost as if the system wasn’t
partitioned. However, they have to do some modifications to their programs. For
instance routines which want to fetch a just executed query should be avoided.
This is because the client will be idle the rest of its timeslot since the fetch is
waiting for a result which won’t arrive before its next timeslot. Instead a fetch
should be called sparsely or when it is really necessary.
Databases The databases we tested were both embedded. Probably, the
databases must be embedded if it’s going to be possible to get them up and
running in a ARINC 653-system. If they are not embedded they are probably
designed as some kind of server daemon, and the communication is done via
sockets. In this case one would have to replace the socket communication with
ARINC ports. The performance would probably suffer really bad from this if
one doesn’t also redesign more parts of how the database communicates. A case
that is not desirable is if the database client, after sending a query always, has
to wait for some kind of response from the server. This would then take a whole
time cycle in the ARINC partition schedule.
Another thing that might be required to get the databases up and running is
to implement a filesystem. This is because there are very few, if any, operating
systems that implements ARINC 653 part 2. How advanced the filesystem
should be may vary between the different databases. We implemented an 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.
66
CHAPTER 6. DISCUSSION AND CONCLUSION
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.
This limits the usefulness of these databases since no important data can be
stored inside and no data can be sent to high safety-critical applications.
6.4
Future work
To make it possible to use our system as a safety-critical system, there are a
couple of tasks that must be done.
Target environment To validate the results the benchmarks must be run
in a real hardware environment. The VxWorks simulator is not reliable
enough.
Certification If the system should be certified our implementation must be
changed to use a static memory management and use certain C libraries.
This should not be too hard. However, the database must also use a secure
memory management, otherwise the certification would fail. This issue is
harder to fix as it may require changes to the database source code if it
doesn’t already comply with the certification standard.
6.5
Final words
Obviously, it is possible to implement databases in an ARINC 653-partition.
And the performance measured in both SQLite and Raima are acceptable. It is
enough to sustain small embedded systems which don’t require high workload
on the database. In our system SQLite was the significantly faster database
while Raima seemed to provide more deterministic results.
In our implementation the database resides in the RAM which is much faster
than if the database for example was to be stored in a flash memory. New
benchmarks must be performed on new storage mediums to determine their
performance.
We both agree that ARINC 653 is the future. It makes it easy and flexible
to develop new functionality when the core modules has been made. However,
it will still take some time before this technique has been validated, verified and
certified a million times before aircraft vendors would dare to use it in the really
critical systems like the flight control system. Maybe this will never happen,
but for low to medium level safety-critical systems, IMA architecture is already
here to stay.
67
Bibliography
[1] Airlines electronic engineering committee (AEEC). Mars 2006.
Avionics application software standard interface - ARINC 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-0925].
[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.
68
BIBLIOGRAPHY
Paul, Minnesota, USA. [Available at: http://air.di.fc.ul.
pt/air-ii/downloads/27th-DASC-Paper.pdf][viewed at 200909-25].
[11] Wind River Systems Inc. 2007. VxWorks 653 Configuration and
Build Guide 2.2.
[12] Alan Burnes, Andy Welling. 2001. Real-Time Systems and 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].
69
Glossary
ACID
API
ARINC 653
Core OS
COTS
Atomicity, consistency , isolation, durability.
Set of properties that guaranties transaction are
processed reliably
Application programming interface
A specification for time- and space partitioning
in safety-critical real-time operating systems
Core operating system for a VxWorks 653 module. Provides OS services and schedules partitions
Commercial of The Shelf
DO 178B
Data Definition Language, Used in Raima to
specify databases
Software Considerations in Airborne Systems
and Equipment certification. The avionics software developed by RTCA.
Federated architecture
FIFO
Software run on a single hardware
Queuing protocol: First In, First out
MOS
Module Operation System
OCC
ODBC
Optimistic concurrency control
Open Database Connectivity, Standard interface for using databases
POS
POSIX
Partition Operation System
Portable Operation System Interface for Unix
RAM
ROM
RTCA
RTOS
Random Access Memory
Read-Only Memory
Private company called Radio Technical Commission for Aeronautics. Developed DO-178B
Real-Time Operating System
SAAB
SDDL
Multinational aircraft vendor
SQL Data Definition Language. See DDL
DDL
70
BIBLIOGRAPHY
SDR
SQL
Shared Data Region
Structured Query Language, language used in
databases
vThreads
VxWorks
Partition OS shipped with VxWorks
RTOS which complies to ARINC 653 part 1
71
Appendix A
Benchmark graphs
A.1
Variables
Table A.1 the default values for the variables used during benchmarking. If
nothing else is mentioned in each test case, these were the values that were
used.
Variable
Number of client partitions
Timeslot length
Task scheduling
Primary key
Port buffer size
Port queue length
Table size
Query response size
Sort result
Client send quota
Value
1 .. 8.
50,100,150 ms.
Round robin.
Yes.
1024 bytes.
512.
1000 rows, 16 columns
1 Row(16 cols).
No
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.
72
APPENDIX A. BENCHMARK GRAPHS
Variable
Query type
Query response size
Value
Insert
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
the lines represent the average processed queries for one timeslot using different
timeslot lengths. In figure A.2 the lines represent the average processed queries
for different number of clients.
SQLite: Average insert performance
1100
50 ms
100 ms
150 ms
1000
900
800
Queries
700
600
500
400
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.1: Average inserts processed during one timeslot for different number of
client partitions.
73
APPENDIX A. BENCHMARK GRAPHS
SQLite: Average insert performance
1100
1000
900
Queries
800
700
1 Client
2 Clients
3 Clients
4 Clients
5 Clients
6 Cleints
7 Clients
8 Clients
600
500
400
300
50
100
Timeslot [ms]
150
Figure A.2: Average no. inserts processed during one timeslot of various length.
74
APPENDIX A. BENCHMARK GRAPHS
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
150 ms
800
Queries
700
600
500
400
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.3: Maximum inserts processed during one timeslot for different number of
client partitions.
SQLite: Maximum insert performance
1200
1000
Queries
800
600
1 Client
2 Clients
3 Clients
4 Clients
5 Clients
6 Clients
7 Clients
8 Clients
400
200
0
50
100
Timeslot [ms]
150
Figure A.4: Maximum inserts processed for various timeslot lengths.
75
APPENDIX A. BENCHMARK GRAPHS
A.2.2
Update
The update query benchmarks are showed here. Table A.3 shows non-default
variable settings for these benchmarks.
Variable
Query type
Query response size
Value
Update
0
Table A.3: Variables that differ from the default values.
Average performance
This benchmark shows the average performance regarding updates. In figure A.5
the lines represent the average processed queries for one timeslot using different
timeslot lengths. In figure A.6 the lines represent the average processed queries
during one timeslot for a specific number of clients.
SQLite: Average update performance
1100
50 ms
100 ms
150 ms
1000
900
800
Queries
700
600
500
400
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.5: Average updates processed during one timeslot for different number of
client partitions.
76
APPENDIX A. BENCHMARK GRAPHS
SQLite: Average update performance
1100
1000
Queries
900
800
700
1 Client
2 Clients
3 Clients
4 Clients
5 Clients
6 Clients
7 Clients
8 Clients
600
500
400
300
50
100
Timeslot [ms]
150
Figure A.6: Average no. updates processed during one timeslot of various length.
77
APPENDIX A. BENCHMARK GRAPHS
Maximum performance
This benchmark shows the maximum performance regarding update queries. In
figure A.7 the lines represent the maximum processed queries for one timeslot
using different timeslot lengths. In figure A.8 the lines represent the maximum
processed queries during one timeslot for a specific number of clients.
SQLite: Maximum update performance
1100
1000
900
800
Queries
700
600
500
400
300
50 ms
100 ms
150 ms
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.7: Maximum updates processed during one timeslot for different number
of client partitions.
SQLite: Maximum update performance
1100
1000
Queries
900
800
700
1 Client
2 Clients
3 Clients
4 Clients
5 Clients
6 Clients
7 Clients
8 Clients
600
500
400
300
50
100
Timeslot length [ms]
150
Figure A.8: Maximum updates processed for various timeslot lengths.
78
APPENDIX A. BENCHMARK GRAPHS
A.2.3
Select
The select query benchmarks are showed here. Table A.4 lists the non-default
variable values for these benchmarks.
Variable
Query type
Value
Select
Table A.4: Variables that differ from the default values.
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
timeslot lengths. In figure A.10 the lines represent the average processed queries
during one timeslot for a specific number of clients.
SQLite: Average select performance
1100
50 ms
100 ms
150 ms
1000
900
800
Queries
700
600
500
400
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.9: Average selects processed during one timeslot for different numbers of
client partitions.
79
APPENDIX A. BENCHMARK GRAPHS
SQLite: Average select performance
1100
1000
900
800
Queries
700
600
500
1 Client
2 Clients
3 Clients
4 Clients
5 Clients
6 Clients
7 Clients
8 Clients
400
300
200
100
0
50
100
Timeslot [ms]
150
Figure A.10: Average no. selects processed during one timeslot of various length.
80
APPENDIX A. BENCHMARK GRAPHS
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
Queries
700
600
500
400
300
200
50 ms
100 ms
150 ms
100
0
1
2
3
4
Client
5
6
7
8
Figure A.11: Maximum selects processed during one timeslot for different numbers
of client partitions.
SQLite: Maximum select performance
1100
1000
900
800
Queries
700
600
500
1 Client
2 Clients
3 Clients
4 Clients
5 Clients
6 Clients
7 Clients
8 Clients
400
300
200
100
0
50
100
Timeslot [ms]
150
Figure A.12: Maximum no. selects processed during one timeslot of various length.
81
APPENDIX A. BENCHMARK GRAPHS
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.
Variable
Query type
Task scheduling
Value
Select
Yield only
Table A.5: Variables that differ from the default values.
SQLite: Average select perfomance − different task
scheduling
1100
1000
50 ms
100 ms
150 ms
900
800
Queries
700
600
500
400
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.13: Average selects processed during one timeslot for different numbers of
client partitions and timeslot lengths.
82
APPENDIX A. BENCHMARK GRAPHS
SQLite: Maximum select performance − different task scheduling
1100
1000
50 ms
100 ms
150 ms
900
800
Queries
700
600
500
400
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.14: Maximum selects processed during one timeslot for different numbers
of client partitions and timeslot lengths.
83
APPENDIX A. BENCHMARK GRAPHS
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
Query type
Primary key
Value
Select
No
Table A.6: Variables that differ from the default values.
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
Queries
120
100
80
60
40
50 ms
100 ms
150 ms
20
0
1
2
3
4
Clients
5
6
7
8
Figure A.15: Average selects processed during one timeslot for different numbers of
client partitions and timeslot lengths.
84
APPENDIX A. BENCHMARK GRAPHS
SQLite: Average select performance − no primary key
160
140
Queries
120
100
1 Client
2 Clients
3 Clients
4 Clients
5 Clients
6 Clients
7 Clients
8 Clients
80
60
40
50
100
Timeslot [ms]
150
Figure A.16: Average no. selects processed during one timeslot of various length.
85
APPENDIX A. BENCHMARK GRAPHS
Maximum performance
The figures A.17 and A.18 displays the maximum numbers of queries processed
in the server during one timeslot.
SQLite: Maximum select performance
180
160
140
50 ms
100 ms
150 ms
Queries
120
100
80
60
40
20
0
1
2
3
4
Clients
5
6
7
8
Figure A.17: Maximum selects processed during one timeslot for different numbers
of client partitions and timeslot lengths.
SQLite: Maximum select performance − no primary key
180
160
Queries
140
120
100
1 Client
2 Clients
3 Clients
4 Clients
5 Clients
6 Clients
7 Clients
8 Clients
80
60
40
50
60
70
80
90
100
110
Timeslot [ms]
120
130
140
150
Figure A.18: Maximum no. selects processed during one timeslot of various length.
86
APPENDIX A. BENCHMARK GRAPHS
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
Query type
QUery response size
Value
Select
128 rows
Table A.7: Variables that differ from the default values.
SQLite: Average and maximum select performance − 128 rows response
14
12
Queries
10
8
6
4
2
Average 50 ms
Maximum 50 ms
0
1
2
3
4
Client
5
6
7
8
Figure A.19: Average and maximum processed select queries. These selects ask
for128 rows. No sorting is applied.
87
APPENDIX A. BENCHMARK GRAPHS
With sort
This benchmark shows average and maximum performance regarding large 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
Query type
Query response size
Sort result
Value
Select
128 rows
Yes
Table A.8: Variables that differ from the default values.
SQLite: Average and maximum select performance, 128 sorted rows response
11
Average 50 ms
Maximum 50 ms
10
9
8
Queries
7
6
5
4
3
2
1
0
1
2
3
4
5
6
7
8
Clients
Figure A.20: Average and maximum processed selects are displayed. Each query
asks for a 128 rows response. Results are sorted in an ascending order by an unindexed
column.
88
APPENDIX A. BENCHMARK GRAPHS
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
Query type
Query response size
Value
Insert
0
Table A.9: Variables that differ from the default values.
Average performance
This benchmark show the average performance regarding inserts. In figure A.21
the lines represent the average processed queries for one timeslot using different
timeslot lengths. In figure A.22 the lines represent the average number of queries
processed during one timeslot for a specific number of clients.
Raima: average insert performance
900
800
700
Queries
600
500
400
300
200
50 ms
100 ms
150 ms
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.21: Average inserts processed during one timeslot for different number of
client partitions.
89
APPENDIX A. BENCHMARK GRAPHS
Raima: average insert performance
900
1 clients
2 clients
3 clients
4 clients
5 clients
6 clients
7 clients
8 clients
800
Queries
700
600
500
400
300
200
50
100
Timeslot [ms]
150
Figure A.22: Average inserts processed for various timeslot lengths.
90
APPENDIX A. BENCHMARK GRAPHS
Maximum performance
This benchmark shows the maximum performance regarding inserts. In figure
A.23 the lines represent the maximum processed queries using different timeslot
lengths. In figure A.24 the lines represent the maximum number of queries
processed during one timeslot for a specific number of clients.
Raima: maximum insert performance
800
700
600
Queries
500
400
300
200
50 ms
100 ms
150 ms
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.23: Maximum inserts processed during one timeslot for different number
of client partitions.
Raima: maximum insert performance
800
700
Queries
600
500
1 clients
2 clients
3 clients
4 clients
5 clients
6 clients
7 clients
8 clients
400
300
200
50
100
Timeslot [ms]
150
Figure A.24: Maximum inserts processed for various timeslot lengths.
91
APPENDIX A. BENCHMARK GRAPHS
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
Query type
Query response size
Value
Update
0
Table A.10: Variables that differ from the default values.
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
Queries
700
50 ms
100 ms
150 ms
600
500
400
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.25: Average number of updates processed during one timeslot for different
number of client partitions.
92
APPENDIX A. BENCHMARK GRAPHS
Raima: average update performance
1100
1000
900
Queries
800
700
600
1 clients
2 clients
3 clients
4 clients
5 clients
6 clients
7 clients
8 clients
500
400
300
50
100
Timeslot [ms]
150
Figure A.26: Average number of updates processed for various timeslot lengths.
93
APPENDIX A. BENCHMARK GRAPHS
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
Queries
800
50 ms
100 ms
150 ms
600
400
200
0
1
2
3
4
Clients
5
6
7
8
Figure A.27: Maximum updates processed during one timeslot for different number
of client partitions.
94
APPENDIX A. BENCHMARK GRAPHS
Raima: maximum update performance
1200
1100
1000
Queries
900
1 clients
2 clients
3 clients
4 clients
5 clients
6 clients
7 clients
8 clients
800
700
600
500
400
300
50
100
Timeslot [ms]
150
Figure A.28: Maximum updates processed for various timeslot lengths.
95
APPENDIX A. BENCHMARK GRAPHS
A.3.3
Select
In this section the select performance has been benchmarked. It is performed
with the non default variable values seen in table A.11.
Variable
Query type
Value
Select
Table A.11: Variables that differ from the default values.
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.
Raima: average select performance
600
Queries
500
400
50 ms
100 ms
150 ms
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.29: Average selects processed during one timeslot for different number of
client partitions.
96
APPENDIX A. BENCHMARK GRAPHS
Raima: average select performance
650
600
550
Queries
500
450
400
1 clients
2 clients
3 clients
4 clients
5 clients
6 clients
7 clients
8 clients
350
300
250
200
150
50
100
Timeslot [ms]
Figure A.30: Average selects for various timeslot lengths.
97
150
APPENDIX A. BENCHMARK GRAPHS
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
Queries
500
400
300
200
50 ms
100 ms
150 ms
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.31: Maximum selects processed during one timeslot for different number
of client partitions.
Raima: maximum select performance
700
600
Queries
500
400
1 clients
2 clients
3 clients
4 clients
5 clients
6 clients
7 clients
8 clients
300
200
100
50
100
Timeslot [ms]
150
Figure A.32: Maximum selects processed for various timeslot lengths.
98
APPENDIX A. BENCHMARK GRAPHS
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.
Variable
Query type
Task scheduling
Value
Select
Yield only
Table A.12: Variables that differ from the default values.
Raima: average select performance, with yield
600
Queries
500
400
50 ms
100 ms
150 ms
300
200
100
0
1
2
3
4
Clients
5
6
7
8
Figure A.33: Average selects processed during one timeslot for different number of
client partitions.
99
APPENDIX A. BENCHMARK GRAPHS
Raima: maximum select performance, with yield
600
500
Queries
400
300
200
100
50 ms
100 ms
150 ms
0
1
2
3
4
Clients
5
6
7
8
Figure A.34: Maximum selects processed during one timeslot for different number
of client partitions. The lines represent the maximum processed queries using different
timeslot lengths.
100
APPENDIX A. BENCHMARK GRAPHS
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
Query type
Primary key
Value
Select
No
Table A.13: Variables that differ from the default values.
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.
Raima: average select performance
35
50 ms
100 ms
150 ms
30
Queries
25
20
15
10
5
0
1
2
3
4
Clients
5
6
7
8
Figure A.35: Average selects processed during one timeslot for different number of
client partitions. No primary key is used.
101
APPENDIX A. BENCHMARK GRAPHS
Raima: average select performance, no primay key
35
Queries
30
25
1 clients
2 clients
3 clients
4 clients
5 clients
6 clients
7 clients
8 clients
20
15
10
50
100
Timeslot [ms]
150
Figure A.36: Average selects processed for various timeslot lengths. No primary key
is used.
102
APPENDIX A. BENCHMARK GRAPHS
Maximum performance
This benchmark shows the maximum performance regarding selects when no
primary key is used. In figure A.37 the lines represent the maximum processed
queries for one timeslot using different timeslot lengths. In figure A.38 the lines
represent the maximum number of queries processed during one timeslot for
different number of clients.
Raima: average select performance, no primary key
40
35
Queries
30
25
20
15
10
50 ms
100 ms
150 ms
5
0
1
2
3
4
Clients
5
6
7
8
Figure A.37: Maximum selects processed during one timeslot for different number
of client partitions. No primary key is used.
Raima: maximum select performance, no primary key
40
35
Queries
30
25
1 clients
2 clients
3 clients
4 clients
5 clients
6 clients
7 clients
8 clients
20
15
10
50
100
Timeslot [ms]
150
Figure A.38: Maximum select processed for various timeslot lengths. No primary
key is used.
103
APPENDIX A. BENCHMARK GRAPHS
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
This benchmark shows average and maximum performance regarding large response sizes when sorting is applied, see figure A.39. Table A.14 shows nondefault variables used in this benchmark.
Variable
Query type
Query response size
Value
Select
128 Rows (16 cols)
Table A.14: Variables that differ from the default values.
Raima: Average and maximum select performance, 128 rows response
8
Average 50 ms
Maximum 50 ms
7
6
Queries
5
4
3
2
1
0
1
2
3
4
Clients
5
6
7
8
Figure A.39: Average and maximum processed selects are displayed. Each query
asks for 128 rows.
With sort
This benchmark shows average and maximum performance regarding large 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.
104
APPENDIX A. BENCHMARK GRAPHS
Variable
Query type
Query response size
Sort result
Value
Select
128 Rows (16 cols)
Yes
Table A.15: Variables that differ from the default values.
Raima: Average and maximum select performance, 128 sorted rows response
8
7
6
Queries
5
4
3
2
Average 50 ms
Maximum 50 ms
1
0
1
2
3
4
Clients
5
6
7
8
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.
105
På svenska
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga 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
2010-02-26
Institution och avdelning
Publiceringsdatum (elektronisk version)
2010-06-20
IDA,
Dept. Of Computer and Information
Science
58183 LINKÖPING
Språk
T yp av publikation
Svenska
X Annat (ange nedan)
Licentiatavhandling
X Examensarbete
C-uppsats
D-uppsats
Rapport
Annat (ange nedan)
Engelska/English
A ntal sidor
105
ISBN (licentiatavhandling) ISRN LIU-­IDA/LITH-­EX-­A-­-­10/010-­-­SE Serietitel (licentiatavhandling) Serienummer/ISSN (licentiatavhandling) U R L för elektronisk version
http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-­57473
Publikationens titel
Usage of databases in ARINC 653-compatible real-time system
Författare
Martin Fri och Jon Börjesson
Sammanfattning
The Integrated Modular Avionics architecture , IMA, provides means for runningmultiple safety-critical
applications on the same hardware. ARINC 653 is a specification for this kind of architecture. It is a specification
for space and time partition in safety-critical real-WLPHRSHUDWLQJV\VWHPVWRHQVXUHHDFKDSSOLFDWLRQ¶V integrity.
This Master thesis describes how databases can be implemented and used in an ARINC 653 system. The
addressed issues are interpartition communication, deadlocks and database storage. Two alternative embedded
databases are integrated in an IMA system to be accessed from multiple clients from different partitions.
Performance benchmarking was used to study the differences in terms of throughput, number of simultaneous
clients, and scheduling. Databases implemented and benchmarked are SQLite and Raima. The studies
indicated a clear speed advantage in favor of SQLite, when Raima was integrated using the ODBC interface.
Both databases perform quite well and seem to be good enough for usage in embedded systems. However,
since neither SQLite or Raima have any real-time support, their usage in safety-critical systems are limited. The
testing was performed in a simulated environment which makes the results somewhat unreliable. To validate the
benchmark results, further studies must be performed, preferably in a real target environment.
A ntal sidor: 105
Nyckelord
ARINC 653, INTEGRATED MODULAR AVIONICS, EMBEDDED DATABSES, SAFETY-CRITICAL, REAL-TIME
OPERATING SYSTEM, VXWORKS