Institutionen för datavetenskap Department of Computer and Information Science

Final thesis Usage of databases in ARINC 653-compatible real-time systems

by Martin Fri Jon Börjesson

LIU-IDA/LITH-EX-A—10/010--SE

2010-05-10

Linköpings universitet Linköpings universitet SE-581 83 Linköping, Sweden 581 83 Linköping

Linköping University 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 run- ning multiple safety-critical applications on the same hardware. ARINC 653 is a specification for this kind of architecture. It is a specification for space and time partition in safety-critical real-time operating systems to ensure each applica- tion’s integrity. This Master thesis describes how databases can be implemented and used in an ARINC 653 system. The addressed issues are interpartition communication, deadlocks and database storage. Two alternative embedded databases are integrated in an IMA system to be accessed from multiple clients from different partitions. Performance benchmarking was used to study the dif- ferences in terms of throughput, number of simultaneous clients, and scheduling. Databases implemented and benchmarked are SQLite and Raima. The studies indicated a clear speed advantage in favor of SQLite, when Raima was integrated using the ODBC interface. Both databases perform quite well and seem to be good enough for usage in embedded systems. However, since neither SQLite or Raima have any real-time support, their usage in safety-critical systems are limited. The testing was performed in a simulated environment which makes the results somewhat unreliable. To validate the benchmark results, further studies must be performed, preferably in a real target environment. Keywords : ARINC 653, INTEGRATED MODULAR AVIONICS, EM- BEDDED DATABASES, SAFETY-CRITICAL, REAL-TIME OPERATING SYSTEM, VXWORKS Contents

1 Introduction 7 1.1 Background ...... 7 1.2 Purpose ...... 7 1.3 Problem description ...... 8 1.3.1 Objectives ...... 8 1.3.2 Method ...... 8 1.3.3 Limitations ...... 9 1.4 Document structure ...... 9

2 Background 10 2.1 Safety-critical airplane systems ...... 10 2.1.1 DO-178B ...... 10 2.2 Avionics architecture ...... 12 2.2.1 Federated architecture ...... 12 2.2.2 IMA architecture ...... 13 2.3 ARINC 653 ...... 14 2.3.1 Part 1 - Required Services ...... 14 2.3.2 Part 2 and 3 - Extended Services and Test Compliance . . 18 2.4 VxWorks ...... 19 2.4.1 Configuration and building ...... 19 2.4.2 Configuration record ...... 19 2.4.3 System image ...... 19 2.4.4 Memory ...... 20 2.4.5 Partitions and partition OSes ...... 21 2.4.6 Port protocol ...... 22 2.4.7 Simulator ...... 22 2.5 Databases ...... 22 2.5.1 ODBC ...... 23 2.5.2 MySQL ...... 23 2.5.3 SQLite ...... 23 2.5.4 Mimer SQL ...... 24 2.5.5 Raima ...... 25

3 System design and implementation 26 3.1 Architecture overview ...... 26 3.1.1 Interpartition communication design ...... 28 3.2 Database modules ...... 29 3.2.1 Client version ...... 29

1 CONTENTS

3.2.2 Server version ...... 32 3.2.3 Server and Client interaction - Protocol ...... 33 3.3 Transmission module ...... 37 3.3.1 Ports ...... 37 3.3.2 Transmission protocol ...... 38 3.4 Databases ...... 41 3.4.1 Filesystem ...... 41 3.4.2 SQLite specific ...... 42 3.4.3 RAIMA specific ...... 43 3.5 Database adapters ...... 43 3.5.1 Interface ...... 43 3.5.2 SQLite adapter ...... 43 3.5.3 Raima adapter ...... 44 3.5.4 Query result ...... 45

4 Benchmarking 46 4.1 Environment ...... 46 4.1.1 Simulator ...... 46 4.1.2 Variables ...... 46 4.1.3 Measurement ...... 47 4.2 Benchmark graphs ...... 48 4.2.1 SQLite Insert ...... 48 4.2.2 SQLite task scheduling ...... 50 4.2.3 SQLite select ...... 51 4.2.4 Raima select ...... 52 4.3 Benchmark graphs analysis ...... 53 4.3.1 Deviation ...... 53 4.3.2 Average calculation issues ...... 53 4.3.3 Five clients top ...... 54 4.3.4 Scaling ...... 55

5 Comparisons between SQLite and Raima 56 5.1 Insert performance ...... 56 5.2 Update performance ...... 58 5.3 Select performance ...... 59 5.4 No primary key ...... 60 5.5 Task scheduling ...... 61 5.6 Response sizes ...... 62 5.7 Summary ...... 63

6 Discussion and Conclusion 64 6.1 Performance ...... 64 6.1.1 Database comparison ...... 64 6.1.2 Scalability ...... 64 6.1.3 Measurement issues ...... 65 6.2 Design and implementation ...... 65 6.3 Usage and Certification ...... 66 6.4 Future work ...... 67 6.5 Final words ...... 67

2 CONTENTS

A Benchmark graphs 70 A.1 Variables ...... 70 A.2 SQLite ...... 70 A.2.1 Insert ...... 70 A.2.2 Update ...... 74 A.2.3 Select ...... 77 A.2.4 Alternate task scheduling ...... 80 A.2.5 No primary key ...... 82 A.2.6 Large response sizes ...... 85 A.3 Raima ...... 87 A.3.1 Insert ...... 87 A.3.2 Update ...... 90 A.3.3 Select ...... 94 A.3.4 Alternate task scheduling ...... 97 A.3.5 No primary key ...... 99 A.3.6 Large response sizes ...... 102

3 List of Figures

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

2.1 A federated architecture and an Integrated Modular Avionics ar- chitecture. [6] ...... 12 2.2 One cycle using the round robin partition scheduling. [6] . . . . . 15 2.3 VxWorks memory allocation example. [11] ...... 20

3.1 System design...... 27 3.2 Channel design used in this system...... 28 3.3 Statement, connection and environment relations...... 30 3.4 Flowchart describing the SQLFetch routine...... 31 3.5 Flowchart of a task in the database server module...... 36 3.6 A connection deadlock caused by Sender Block port protocol. . . 40 3.7 Filesystem structure...... 42

4.1 Average inserts processed during one timeslot for different num- ber of client partitions...... 48 4.2 Average number of inserts processed during one timeslot of vari- ous length...... 49 4.3 Average selects processed during one timeslot for different num- bers of client partitions and timeslot lengths. Task scheduling used is Yield only...... 50 4.4 Average selects processed during one timeslot for different num- bers of client partitions...... 51 4.5 Average selects processed during one timeslot for different num- ber of client partitions. The lines represent the average processed queries using different timeslot lengths...... 52 4.6 With one client, the server manages to process all 1024 queries in one time frame...... 54 4.7 With two clients, the server cannot process 2*1024 in two times- lots due to context switches. An extra time frame is required. . 54 4.8 The average processing speed is faster than 1024 queries per timeslot, but it is not fast enought to earn an entire timeslot. . . 54

5.1 Comparison between average insert values in SQLite and Raima. Timeslots used in the graphs are 50 ms and 100ms...... 57 5.2 Comparison between average update values in SQLite and Raima. Timeslot lengths are 50 ms and 100 ms...... 58

4 LIST OF FIGURES

5.3 Comparison between average select values in SQLite and Raima. Timeslot lengths are 50 ms and 100 ms...... 59 5.4 Comparison between average select values in SQLite and Raima with and without primary key. Timeslot length is 50 ms...... 60 5.5 Comparison between average select queries using different task schedules in SQLite and Raima. Timeslot length is 50 ms. . . . . 61 5.6 Comparison between average selects with and without sorting in SQLite and Raima. The resulting rowsets are of size 128 rows and timeslot length is 50 ms...... 62 5.7 Comparison between single row select and 128 rows select queries in SQLite and Raima. Average values are showed in the graph with timeslot length of 50 ms...... 62

A.1 Average inserts processed during one timeslot for different num- ber of client partitions...... 71 A.2 Average no. inserts processed during one timeslot of various length...... 72 A.3 Maximum inserts processed during one timeslot for different num- ber of client partitions...... 73 A.4 Maximum inserts processed for various timeslot lengths...... 73 A.5 Average updates processed during one timeslot for different num- ber of client partitions...... 74 A.6 Average no. updates processed during one timeslot of various length...... 75 A.7 Maximum updates processed during one timeslot for different number of client partitions...... 76 A.8 Maximum updates processed for various timeslot lengths. . . . . 76 A.9 Average selects processed during one timeslot for different num- bers of client partitions...... 77 A.10 Average no. selects processed during one timeslot of various length...... 78 A.11 Maximum selects processed during one timeslot for different num- bers of client partitions...... 79 A.12 Maximum no. selects processed during one timeslot of various length...... 79 A.13 Average selects processed during one timeslot for different num- bers of client partitions and timeslot lengths...... 80 A.14 Maximum selects processed during one timeslot for different num- bers of client partitions and timeslot lengths...... 81 A.15 Average selects processed during one timeslot for different num- bers of client partitions and timeslot lengths...... 82 A.16 Average no. selects processed during one timeslot of various length. 83 A.17 Maximum selects processed during one timeslot for different num- bers of client partitions and timeslot lengths...... 84 A.18 Maximum no. selects processed during one timeslot of various length...... 84 A.19 Average and maximum processed select queries. These selects ask for128 rows. No sorting is applied...... 85

5 A.20 Average and maximum processed selects are displayed. Each query asks for a 128 rows response. Results are sorted in an ascending order by an unindexed column...... 86 A.21 Average inserts processed during one timeslot for different num- ber of client partitions...... 87 A.22 Average inserts processed for various timeslot lengths...... 88 A.23 Maximum inserts processed during one timeslot for different num- ber of client partitions...... 89 A.24 Maximum inserts processed for various timeslot lengths...... 89 A.25 Average number of updates processed during one timeslot for different number of client partitions...... 90 A.26 Average number of updates processed for various timeslot lengths. 91 A.27 Maximum updates processed during one timeslot for different number of client partitions...... 92 A.28 Maximum updates processed for various timeslot lengths. . . . . 93 A.29 Average selects processed during one timeslot for different num- ber of client partitions...... 94 A.30 Average selects for various timeslot lengths...... 95 A.31 Maximum selects processed during one timeslot for different num- ber of client partitions...... 96 A.32 Maximum selects processed for various timeslot lengths. . . . . 96 A.33 Average selects processed during one timeslot for different num- ber of client partitions...... 97 A.34 Maximum selects processed during one timeslot for different num- ber of client partitions. The lines represent the maximum pro- cessed queries using different timeslot lengths...... 98 A.35 Average selects processed during one timeslot for different num- ber of client partitions. No primary key is used...... 99 A.36 Average selects processed for various timeslot lengths. No pri- mary key is used...... 100 A.37 Maximum selects processed during one timeslot for different num- ber of client partitions. No primary key is used...... 101 A.38 Maximum select processed for various timeslot lengths. No pri- mary key is used...... 101 A.39 Average and maximum processed selects are displayed. Each query asks for 128 rows...... 102 A.40 Average and maximum processed selects are displayed. Each query asks for 128. Results are sorted in an ascending order by an non-indexed column...... 103 Chapter 1

Introduction

This document is a Master thesis report conducted by two final year Computer science and Engineering students. It corresponds to 60 ECTS, 30 ECTS each. The work has been carried out at Saab Aerosystems Link¨oping and examined at Department of Computer & Information science at Link¨oping University. The report starts with a description of the thesis and some background information. Following this, the system design and work results are described. Finally, the document ends with an analysis, and a discussion and conclusion section.

1.1 Background

Safety-critical aircraft systems often run on a single computer to prevent mem- ory inconsistency and to ensure that real-time deadlines are held. If multiple applications are used on the same hardware they may affect each other’s mem- ory or time constraints. However, a need for multiple applications to share hardware has arisen. This is mostly due to the fact that modern aircrafts are full of electronics; no space is left for new systems. One solution to this prob- lem is to use an Integrated Modular Avionics, IMA, architecture. The IMA architecture provides means for running multiple safety-critical applications on the same hardware. The usage of Integrated Modular Avionics is an increasing trend in most aircraft manufacturers and Saab Aerosystems is no exception. ARINC 653 is a software specification for space and time partitioning in the IMA architecture. Each application is run inside its own partition which isolates it from other applications. Real-time operating systems implementing this standard will be able to cope with the memory and real-time constraints. This increases the flexibility but also introduces problems such as how to com- municate between partitions and how the partition scheduling will influence the design. A brief overview of an ARINC 653-system can be seen in figure 1.1.

1.2 Purpose

As described in the previous section the trend of avionics software has shifted towards Integrated Modular Avionics systems. ARINC 653 is a specification for this kind of systems and is used in many modern aircrafts [8]. Saab is interested

7 CHAPTER 1. INTRODUCTION

App 1 App 2 App 3 DB partition partition partition partition

RTOS (ARINC 653)

Hardware

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

1.3 Problem description

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

1.3.1 Objectives Goals and objectives for this master thesis:

Port and integrate alternative databases within an ARINC 653-partition. • Implement a database API for communication between the applications • and the database, that will hide the ARINC-layer from the application and the database.

Find the system’s performance thresholds according to throughput, num- • ber of simultaneous clients and scheduling. Then evaluate the use of databases in an ARINC 653-system.

1.3.2 Method The workload will be divided into two parts since there are two participating students in this thesis.

8 CHAPTER 1. INTRODUCTION

Martin’s part is focused towards ARINC 653 and the interpartition com- munication. The goals for this part is to abstract the underlying ARINC 653 layer and provide a database API to an application developer. The application developer shall not notice that the system is partitioned, he/she should be able to use the database as usual. This part is responsible for the communication between the application and the database. Jon’s part is to study databases and how to port them to the ARINC 653 system. This includes to choose two databases and motivate the choices. One of the databases shall be an open source database. The goals of Jon’s part is to port the chosen databases and make them work in an ARINC 653-compatible real-time operating system. This requires for instance an implementation of a file system and one database adapter per database. Testing and benchmarking of the implemented system has been done by both Martin and Jon.

1.3.3 Limitations Limitations for this project are: VxWorks shall be the ARINC 653-compatible real-time operating system. • Saab already uses this operating system in some of their projects.

The implementation will primarily be tested in a simulated environment. • Tests in a target environment are subject to additional time.

1.4 Document structure

A short description of the document structure is provide below.

Chapter 1 Contains an introduction to the master thesis.

Chapter 2 Essential background information needed to understand the thesis.

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

Chapter 4 Contains benchmarking graphs and their analyses.

Chapter 5 Contains a comparison between chosen databases.

Chapter 5 Contains discussions and conclusions about the thesis result.

9 Chapter 2

Background

This section will provide the reader with essential background information.

2.1 Safety-critical airplane systems

Systems embedded in airplanes are safety-critical software. A software failure in such a system can cause minor to catastrophic events. When developing safety critical software for aircrafts, there are some special issues that arises. Since aircraft software is a type of embedded system there are limitations on the memory available. This causes the developer to use special techniques to ensure that memory boundaries are not overflowed. Aircraft software is often also safety-critical real-time systems; in theses systems timing and reliability are large concerns. First, deadlines for important tasks should never be missed. This forces the system to have some kind of scheduling that ensures that deadlines are not overrun. Secondly, safety-critical real-time systems must be reliable. It would not do if for example an aircraft or a respirator suddenly stopped working. This issue leads to strict requirements on not only the software but also the hardware. Hardware available for this kind of systems must be closely monitored and tested before they are allowed to be used. These requirements leads to that the hardware available are many years old and have poor performance compared to the modern, high performance hardware. [3] [5] [7]

2.1.1 DO-178B DO-178B, Software Considerations in Airborne Systems and Equipment Cer- tification, is an industry accepted guidance about how to satisfy airworthiness of aircrafts. It focuses only on the software engineering methods and processes used when developing aircraft software and nothing on the actual result. This means that if an airplane is certified with DO-178B, you know that the devel- oping process for developing an airworthiness aircraft has been followed, but you do not really know if the airplane can actually fly. A system with a poor requirement specification can go thorough the entire product development life cycle and fulfill all of the DO-178B requirements. However, the only thing you

10 CHAPTER 2. BACKGROUND know about the result is that it fulfills this poor requirement specification. In other words, bad input gives bad, but certified output. [3] [5]

Failure categories Failures in an airborne system can be categorized in five different types according to the DO-178B document:

Catastrophic A failure that will prevent a continuous safe flight and landing. Results of a catastrophic failure are multiple fatalities among the occupants and probably loss of the aircraft.

Hazardous / Severe-Major A failure that would reduce the capabilities of the aircraft or the ability of the crew to handle more difficult operating conditions to the extent of:

Large reduction of safety margins or functional capabilities. • Physical distress or higher workload such as the crew could not be relied • upon to perform their tasks accurately or completely.

Increased effects on occupants including seriously or potentially fatal in- • juries to a small number of the occupants.

Major A failure that would reduce the capabilities of the aircraft and the ability of the crew to do their work to any extent of:

Reduction of safety margins or functional capabilities. • Significant increased workload of the crew. • Possible discomfort of the occupants including injuries. • Minor A failure that would not significantly reduce the aircraft safety and the crew’s workload are still within their capabilities. Minor failures may include slight reduction of safety margins and functional capabilities, a slight increase in workload or some inconvenience for the occupants.

No Effect A failure of this type would not affect the operational capabilities of the aircraft or increase crew workload. [3] [4]

Software safety levels Software in airplanes has different safety levels depending on what kind of fail- ures they can cause. These are according to the DO-178B document:

Level A Software of level A that doesn’t work as intended may cause a failure of catastrophic type.

Level B Software of level B that doesn’t work as intended may cause a failure of Hazardous/Severe-Major type.

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

Federated System Integrated Modular Avionics (IMA)

Flight Mission Air Data Air Data FMS Mission computer Management Computer computer computer

MMU-partitioning Operating System

Bus

Figure 2.1: A federated architecture and an Integrated Modular Avionics architec- ture. [6]

2.2.1 Federated architecture Federated architecture is the traditional approach of implementing avionics sys- tems. This approach uses distributed standalone systems which run on their own separate hardware. This is a well known approach that has been used for a long time. One advantage of a federated architecture is that many experienced develop- ers are available. These people have worked with this kind of architecture for a long time and they know where the pitfalls are. Another advantage is that since each system is separate both hardware and software wise, this leads to easy verification and validation processes for these systems. This saves the company a lot of time and money since aircraft certification is extremely expensive. The disadvantage of this type of architecture is that each standalone system has a specific function. This requires that each system must be specifically developed in aspects of hardware and software. Reuse of software and hardware components are very rare. Federated architectures also require more power control mechanisms due to the fact that each separate system must have its own power system. This leads to more electronics leading to a higher power consumption, and that the weight is increased. In today’s airplanes weight and space is extremely limited. They are so full of electronics that it is hard to upgrade with new functionality. This together

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

13 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 im- portant core functionality of real-time operating systems should work to comply with the specification. The system functionality is divided into six categories:

Partition management •

14 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 times- lots, called minor frames or minor cycles. No priorities are set to the partitions as the specified scheduling order cannot change during runtime. It is the system integrators job to set the order, frequency and length of each partition’s frame. As frequency implies, a partition can be assigned to more than one frame in each major cycle. The configuration is loaded during system initialization and cannot change during runtime.

Partition Partition Partition Partition #1 #2 #3 #4

Minor Frame #1 Minor Frame #2 Minor Frame #3 Minor Frame #4 200 ms 150 ms 250 ms 200 ms

Major Frame repeat

Time

Figure 2.2: One cycle using the round robin partition scheduling. [6]

Modes A partition can be in four different modes: Idle, normal, coldstart and warmstart. IDLE When in this mode, the partition is not initialized and it is not executing any processes. However, the partition’s assigned timeslots are unchanged.

15 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 WARM- START is used when some things in the initialization phase do not need to be done. E.g. if the RAM memory is still intact after some kind of failure, the partition will start in WARMSTART mode. [1]

Process management Inside a partition an application resides which consists of one or more processes. A process has its own stack, priority, and deadline. The processes in a partition run concurrently and can be scheduled in both a periodic and an aperiodic way. It is the partition OS that is responsible for controlling the processes inside its partition.

States A process can be in four different states: Dormant, Ready, Running and Waiting.

Dormant Cannot receive resources. Processes are in this state before they are started and after they have been terminated.

Ready Ready to be executed.

Running The process is assigned to a processor. Only one process can be in running state at the same time.

Waiting Not allowed to use resources because the process is waiting for an event. E.g. waiting on a delay.

Scheduling Process scheduling is controlled by the partition operating sys- tem and is using a priority preemptive scheduling method. Priority preemptive scheduling means that the controlling OS can at anytime stop the execution of the current process in favor for a higher prioritized process which is in ready mode. If two processes have the same priority during a rescheduling event the scheduler chooses the oldest process in ready mode to be executed.

Time management Time management is extremely important in ARINC 653 systems. One of the main points of ARINC 653 is that systems can be constructed so applications will be able to run before their deadlines. This is possible since partition schedul- ing is, as already mentioned, time deterministic. A time deterministic scheduling means that the time each partition will be assigned to a CPU is already known. This knowledge can be used to predict the system’s behavior and thereby create systems that will fulfill their deadline requirements. [1]

16 CHAPTER 2. BACKGROUND

Memory allocation An application can only use memory in its own partition. This memory alloca- tion is defined during configuration and initialized during start up. There is no memory routines specified in the core OS that can be called during runtime. [1]

Interpartition communication The interpartition communication category contains definitions for how to com- municate between different partitions in the same core module. Communication between different core modules and to external devices is also covered. Interpartition communication is performed by message passing, a message of finite length is sent from a single source to one or more destinations. This is done through ports and channels.

Ports and Channels A channel is a logical link between a source and one or more destinations. The channel also defines the transfer mode of the messages. To access a channel, partitions need to use ports which work as access points. Ports can be of source or destination type and they allow partitions to send or receive messages to/from another partition through the channel. A source port can be connected to one or more destination ports. Each port has its own buffer and a message queue which both are of predefined sizes. Data which is larger then this buffer size must be fragmented before sending and then merged when receiving. All channels and all ports must be configured by the system integrator before execution. It is not possible to change these during runtime.

Transfer modes There are two transfer modes available to chose from when configuring a channel. They are sampling mode and queuing mode.

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

Queuing mode In queuing mode, messages are stored in a queue at the port. The size of this queue and its element sizes are configured before execution. A message sent from the source partition is buffered in the port’s message queue while waiting to be transmitted by the channel. At the receiving end, incoming messages are stored in the destination port’s message queue until its partition receives the message. Message queues in the queuing mode are following the First In First Out, FIFO, protocol. This allow ports to indicate overflow occurrences. However, it is the application’s job to manage the overflow situations and make sure no messages are lost. [1]

17 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 syn- chronization. Semaphores control access to shared resources while events coor- dinate the control flow between processes. Semaphores in ARINC 653 are counting semaphores and they are used to control partition resources. The count represents the number of resources avail- able. A process accessing a resource has to wait on a semaphore before accessing it and when finished the semaphore must be released. If multiple processes wait for the same semaphore, they will be queued in FIFO or priority order depending on the configuration. Events are used to notify other processes of special occurrences and they consist of a bi-valued state variable and a set of waiting processes. The state variable can be either ”up” or ”down”. A process calling the event ”up” will put all processes in the waiting processes set into the ready mode. A process calling the event ”down” will be put into the waiting processes set.[1]

Health Monitor Fault handling in ARINC 653 is performed by an OS function called Health Monitor(HM). The health monitor is responsible for finding and reporting faults and failures. Errors that are found have different levels depending on where they occurred. The levels are process level, partition level and OS level. Responses and actions taken are different depending on which error level the failure has and what has been set in the configuration. [1] [10]

2.3.2 Part 2 and 3 - Extended Services and Test Compli- ance Part 2, extended services, contains specifications for: File Systems • Sampling Port Data Structures • Multiple Module Schedules •

18 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. De- tails below are described in VxWorks 653 Configuration and Build Guide 2.2 [11].

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

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

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

19 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 applica- • tions must be created. This is done as a part of the shared library build.

2.4.4 Memory The memory configuration is made up of two parts; the physical memory con- figuration and the virtual memory configuration. An example of the memory organization can be seen in figure 2.3.

Physical memory Virtual memory

App-1 App-2 App-2 Blackboard Blackboard App-1 POS-2 POS-1 App-2 Blackboard App-1 POS-1 POS-1 POS-2 POS-2 ConfigRecord ConfigRecord ConfigRecord ConfigRecord COS COS COS COS Rom Ram App-1 App-2

Figure 2.3: VxWorks memory allocation example. [11]

Physical memory The physical memory is made up of the read-only memory, ROM, and the random-access memory, RAM.

20 CHAPTER 2. BACKGROUND

As figure 2.3 illustrates, applications and the core OS consumes more mem- ory in RAM than in ROM. This is because each application requires additional memory for the stack and the heap. This also applies to the core OS. Each application has its own stack and heap, since there is no memory sharing al- lowed between applications. If an application is using any shared libraries, it also needs to set aside memory for the libraries’ stacks and heaps. How much memory each application gets allocated is specified in the configuration record. Partition OSes, POS, and shared libraries, SL, require no additional space in RAM. This is because the application that is using the POS/SL is responsible for the stack and the heap space. SDR-Blackboard is a shared data region (SDR). It is a memory area set aside for two or more applications as a place to exchange data. App-1 and App-2, seen in figure 2.3 are loaded in to separate RAM areas. They share no memory excepts for the SDR areas.

Virtual memory Every component, except for the applications, has a fixed, unique address in the virtual memory. All applications have the same address. This makes it possible to configure an application as if it is the only application in the system. Each application exists in a partition, which is a virtual container. The partition configuration controls which resources that are available to the application.

2.4.5 Partitions and partition OSes A module consists of a RTOS and partitions. Each partition contains an ap- plication and a partition OS, POS, in which the application runs. When the application accesses a shared library or any I/O region, it is done via the POS which regulates the access. The partition provides the stack and heap space that is required by the application. It also supplies any shared library code that the application uses. There can be multiple POS instances in a module; one instance per partition. The instances are completely unaware of each other. Partition OSes are stored in system shared libraries. This is to conserve resources. If two partitions are running the same POS, they reference the same system shared library, but must provide their own copy of the read/write parts of the library to maintain the isolation between partitions. They must also provide the required stack and heap size for the library to run. A partition can only access one system shared library. A system shared library can only contain one POS. When the POS is built, stub files are created. The stub files are needed when building applications since they contain routine stubs that the applications link to. To map the stubs to the POS routines, an entry-point table is created as a part of the POS. VxWorks resolves the stub calls to the POS routines when the application is initializing. vThreads VxWorks 653 comes with a partition OS called vThreads. vThreads is based on VxWorks 5.5, and is a multithreading technology. It consists of a kernel and

21 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 draw- back is that partitions get coupled to each other, meaning that one application may block all the others. The other protocol, receiver discard, will drop messages when a destination port is full. This will avoid one application with a full destination buffer to block all the others. If all destination ports are full, an overflow flag will be set to notify the application that the message was lost.

2.4.7 Simulator VxWorks comes with a simulator. It makes it possible to run VxWorks 653 applications on a host computer. Since it’s a simulator, not an emulator, there are some limitations compared to the target environment. The simulator’s per- formance is affected by the host hardware and other software running on it. The only clock available in the simulator is the host system clock. The simu- lator’s internal tick counter is updated with either 60 Hz or 100 Hz, which gives very low resolution measures. 60 Hz implies that partitions can’t be scheduled with a timeslot shorter than 16 ms. With 100 Hz it’s possible to schedule as short as 10 ms. One feature that isn’t available in the simulator is the performance monitor, which is used for monitoring CPU usage.

2.5 Databases

Today Saab is using their own custom storage solutions in their avionics soft- ware. They are often specialized for a particular application and not that gen-

22 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 evalu- ated for implementation in the system. It also contains some general information that may be good to know for better understanding of the system implementa- tion.

2.5.1 ODBC Open Database Connectivity, ODBC, is an interface specification for accessing data in databases. It was created by Microsoft to make it easier for companies to develop Database Management System, DBMS, independent applications. Applications call functions in the ODBC interface, which are implemented in DBMS-specific modules called drivers. ODBC is designed to expose the database capabilities, not supplement them. This does not mean that just because one is using an ODBC interface to access a simple database, the database will transform into a fully featured relational database engine. If the driver is made for a DBMS that does not use SQL, the developer of the driver must implement at least some minimal SQL functionality. [17]

2.5.2 MySQL MySQL is one of the worlds most popular open source databases. It is a high performance, reliable relational database with a powerful transactional sup- port. It includes complete ACID (atomicity, consistency, isolation, durability) transaction support, unlimited row-level locking, and multi-version transaction support. The latter means that readers never block writers and vice-versa. The embedded version of MySQL has a small footprint with preserved func- tionality. It supports stored procedures, triggers, functions, ANSI-standard SQL and more. Even though MySQL is open-source, the embedded version is released under a commercial license. [16]

2.5.3 SQLite SQLite is an open source embedded database that is reliable, small and fast. These three factors come as a result of the main goal with SQLite - to be a simple database. One could look at SQLite as a replacement to fopen() and other filesystem functions, almost like an abstraction of the file system. There is no need for any configuration or any server to start or stop. SQLite is serverless. This means that it does not need any communication between processes. Every process that needs to read or write to the database opens the database file and reads/writes directly from/to it. One disadvantage with a serverless database is that it does not allow more complicated and finer grained locking methods. SQLite supports in-memory databases. However, it’s not possible to open a memory database more than once since a new database is created at every opening. This means that it’s not possible to have two separate sessions to one memory database.

23 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 man- ual reorganization of the database is ever needed. In Mimer, a transaction is an atomic operation. Since Mimer uses optimistic concurrency control, OCC, deadlocks never occur in the database. Change requests are stored in a write-set during the build-up phase of the transaction. The build-up phase is when all database operations are requested. During this phase the changes in the write-set is hidden from other users of the system. The changes will be visible to the other users after a successful commit. Besides the

24 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 in- memory and on-disk storage. It also has native support for VxWorks, and should therefore needs less effort to get up and running in VxWorks 653. It is widely used, among others is the aircraft vendor Boeing. Raima has both an SQL API and a native C API. The SQL API conforms to a subset of ODBC 3.5. Raima uses a data definition language, DDL, to specify the database design. Each database needs its own DDL file. The DDL file is parsed with a command line tool that generates a database file and a C header file. The header file contains C struct definitions for the database records defined in the DDL and constants for the field names. These structs and constants are used with Raima’s C API. The DDL parsing tool also generates index files for keys. Each index file must be specified in the DDL. There are two types of DDL in Raima. One which has a C like syntax, DDL, and one with a SQL like syntax, SDDL. Both types must be parsed by a special tool. Its not possible to create databases or tables during runtime with SQL queries. Fortunately, its possible to link Raima’s DDL/SDDL parsers into applications. This allows creation of DDL/SDDL files during runtime, that could be parsed by the linked code. Raima is storing data in fixed length records. This is not per table basis, but file basis. If there are multiple tables in the same file, the record size will be the size of the biggest record needed by any of the tables. This means that there may be a lot of space wasted, but it should result in better performance. [15]

25 Chapter 3

System design and implementation

In this chapter an experimental system is described, whose purposes are to ab- stract ARINC 653 and make a database available for applications. The database can easily be replaced by another database without modifications to the rest of the system. This system is later benchmarked to find different thresholds, see chapter 4.

3.1 Architecture overview

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

Layer 3 - Applications executing routines, database adapter providing • functionality to lower layer.

Layer 2 - Database API, Query/Result transport protocol. • Layer 1 - Interpartition communication. • ”Layer 0” - RTOS, handled by VxWorks. • Clients and Servers A partition containing a transmission module, database client module and an application is called a client. A partition containing a transmission module, database server module, database adapter and a database is called a server. This implementation is able to handle multiple clients which use one or more servers. However, the main configuration is for one server partition and multiple client partitions.

26 CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION

Partition scheduling Both client and server partitions are scheduled with a cyclic schedule that resembles round robin, i.e. all timeslots are of the same length and each partition has only one timeslot per major cycle. See Partition Management in section 2.3.1 for more information about partition scheduling in ARINC 653.

Database partition Application partition

Adapter

Application Database

Database module (server) Database module (client)

Transmission module Transmission module

RTOS (ARINC 653)

Figure 3.1: System design.

27 CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION

3.1.1 Interpartition communication design Partitions communicate with each other through ports and channels. This sec- tion describes the channel design for this implementation. In this design, each client partition has one outgoing and one ingoing channel connected to the database partition. This means that between a database and a client application, the ingoing / outgoing pair of channels are exclusively used for just this connection. See figure 3.2.

Figure 3.2: Channel design used in this system.

The benefit with this design is the application independence. E.g. if one port buffer is overflowed, only this port’s connection will be affected. The other connections can still continue to function. Another benefit is that the server will know which client sent a message. This is because all channels are configured before the system is run. The drawback with this approach is that it requires many ports and channels to be configured which requires a lot of memory.

28 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 rou- tines specified in the ODBC interface are implemented, only a subset of the ODBC routines that provide enough functionality to get the system to work. The names and short descriptions of the implemented routines are listed in table 3.1.

SQLAllocHandle Allocate handle of type: environment, connection or statement. SQLFreeHandle Free specified handle. SQLConnect Connect to specified database. SQLDisconnect Disconnect from database. SQLExecDirect Execute a query in connected database. SQLFetch Move results from queries into bound columns. SQLBindCol Bind buffers to database columns. SQLNumResultCols Get the number of columns in result data set. SQLRowCount Get the number of rows in result data set. SQLEndTran End transaction. A new transaction begins automatically.

Table 3.1: Database API

Design ODBC specifies three different datatypes. They are as follows:

Statements Contains a query and when returned, the result of the query. Connections Every connection contains handles to the ports asso- ciated with this connection. It also holds all state- ment handles used by this connection. Environments Contains port names and all connections operating on these ports.

See figure 3.3 for information about how these data types relate to each other. Before a query could be sent, an environment must be created. Inside this environment multiple connections can be created. And inside every connection,

29 CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION

* 1 * 1 «datatype» «datatype» «datatype» Statement Connection Environment

1 1 1 1

Figure 3.3: Statement, connection and environment relations. multiple statements can be created. A statement will contain the query and, when the response comes from the server, a rowset.

Send queries When a statement has been created, it can be loaded with a query and then sent by calling function SQLExecDirect with the specific state- ment as a parameter. Efficiency would be greatly diminished if the execute/send routine would be of a ”blocking” type, i.e. the execution would halt while waiting for a response to return. If this was the case, every client would only be able to execute one query per timeslot. This is due to the fact that a query answer cannot be returned to the sender application before the query has been executed in the database. The database partition must therefore be assigned to the CPU and process the query before a response can be sent back. Since the partitions are scheduled with a round robin scheduling with only one timeslot per partition, the sender application will get the response at earliest at its next scheduled timeslot. Our design does not use a ”blocking” execute. Instead it works as ODBC describes and passes a handle to the execute routine which sends the query and then continue its execution. The handle is later needed by the fetch/receive routine for knowing which answer should be fetched. This approach supports multiple sent queries during one timeslot. However, the fetch routine gets a bit more complicated.

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

30 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

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

YES

Move the result into the specified Statement and then move the result to the bound columns

Exit SQLFetch

Figure 3.4: Flowchart describing the SQLFetch routine.

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

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

31 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, syn- chronizing access to the database and sending back the results to the client applications.

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

Synchronization The access to the database is synchronized to prevent mul- tithreading issues within the database. This means that only one thread at a time can be executing a query in the database. The processing of this query must be completed before the lock is lifted and another thread can access the database.

32 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 possi- bility to release the CPU earlier at its own command. This scheduling doesn’t force the task to occupy its entire timeslot. Instead it will automatically relin- quish the processor at send and receive timeouts. Timeslot lengths are deter- mined by the number of ticks set by the KernelTimeSlice routine. Since all tasks have the same priority, all tasks will enjoy about the same execution time. If the partition timeslot is large enough and the KernelTimeSlice is small enough, all clients will get some responses every cycle. Another available scheduling is Yield only. This scheduling lets a task run until itself relinquishes the CPU. The tasks do not have a maximum continuous execution time. When used in this system, the CPU is released only at send and receive timeouts.

3.2.3 Server and Client interaction - Protocol The server and client interact with each other using a protocol. A package transmitted using this protocol always starts with a fixed sized header before the actual data follows. The data can be of any size since queries and result sizes can vary. This variable data is unknown for the receiver and can therefore not be received directly. The receive routine wants to know how many bytes it should read from the inport. Also, the receiver needs the data size to be able to allocate a buffer of an appropriate size. A fixed maximum data size is the alternative, but will generate a huge over- head because of the large size difference between the smallest result set and the largest result set. However, this approach is the only choice if the system should be certified. See section 6.4 for more information. Since this system uses a variable data size, the receive routine only knows about the header size. Therefore only the header is read from the inport at first, leaving the data behind. Then the receiver checks the header for the data size value, see table 3.2, and allocates a buffer of the correct size. As the data size now is known, the receiver can read the data from the port and put the data in the newly allocated buffer.

Header The header contains an id, a statement pointer, a data size and a command type as showed in table 3.2. The statement pointer is used to distinguish to which statement a query belongs. This is to make sure that database responses are moved into the correct statements. An id is required because there are some special occurrences where the statement pointer isn’t enough to determine which statement is the correct one. The id is a sequence number that is increased and added to the header at every send called by SQLExecDirect in the client application.

33 CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION

Id Unique id of a sent query. Statement pointer Pointer to the statement holding the query in the client application. Data size Size of the data following the header. Command type Type of the following data.

Table 3.2: Header and data

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

NONE is set when nothing should be sent, i.e. the module will skip sending messages of this type.

QUERY indicates that the package contains a SQL query. Messages of this type will always generate a response.

END TRAN is a command type for messages containing an end transaction. No response will be generated.

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

34 CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION

Command type Data NONE No package will be sent QUERY < char >Query as a string ∗ END TRAN < int >Commit or Rollback < int > Nr rows, < int > Nr cols < int > length colname(1), < char > col- name(1) ∗ RESPONSE ROWSET ... < int > length colname(nr cols), colname(Nr Cols), ∗ < int > size cell(row1, col1) , 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 [QUERY] Type of data database adapter [OTHER] Print error mesage

[END TRAN]

Adapter has Response type = [NO] result NONE

[YES]

Get result from adapter Send header and Free allocated and set Resonse type = data of response memory ROWSET_RESPONSE to client

Figure 3.5: Flowchart of a task in the database server module.

36 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 rea- son for this is that no messages are allowed to be lost, as might be the case when using sampling type ports. The transmission module shall also be able to transfer data of large sizes. This also requires the usage of queuing ports since large data must be fragmented to fit inside port buffers. This is impossible with sampling ports.

Fragmentation Buffer size and queue length are two important settings for a queuing port. Total size required by a port is the buffer size times the queue length, P ortsize = buffer size queue length. Large data∗ streams that cannot fit inside one port buffer must be split into several smaller parts. There are three different cases that can occur during the fragmentation: Case 1 Message fits in one buffer. It occupies one queue spot.

Case 2 Message doesn’t fit in one buffer but it fits in several buffers. This message occupies several queue spots but the queue is not full.

Case 3 Message is too large and fills all queue buffers. This means that the queue is full and the port is overflowed. The port’s behavior in this case depends on which port protocol that is used. Note that several large messages can be fragmented into the queue at the same time which increases the risk of port overflow occurrences.

Port protocols As mention before in section 2.4.6 VxWorks supports two different port proto- cols: Sender Block and Receiver Discard. The transmission module uses the Sender Block port protocol. The reason for this is that it removes the issue of retransmissions entirely for our test sys- tem. Another reason is that if the Receiver Discard port protocol were to be used, some kind of block functionality would still be necessary. This is because

37 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 pro- cess when it is trying to send data to a full port buffer queue. If both a client application and its corresponding server thread have full inport queues and both are in send mode, a deadlock will occur since both are blocked by the port protocol.

Deadlocks Deadlocks that regard the entire server’s uptime has been taken care of by special design and configuration at another level. A multithreaded server and the channel design will prevent one client to block the entire server because only a single thread becomes locked. See section 3.1.1 and section 3.2.2 for more information. However, deadlocks inside a single database thread might still occur. This kind of deadlock prevents the specific database thread and its corresponding application to execute successfully. This deadlock type occurs when the client application executes a lot of queries and thereby overflowing the server thread’s port buffer. This causes the client application to block itself waiting for the occupied spots in the database port queue to diminish. Then the server partition is switched in and it will re- ceive and execute a few of the queries in the database and send back the results to the client application. If the database responses are large enough to over- flow the client application’s port buffer the server will be blocked too. Now the client application is switched back in and since the database did some receives before getting blocked, the client is no longer blocked. The client application therefore resumes its execution at the same place where it was stopped before, i.e. it continues sending a lot of queries. This causes the client application to be blocked again soon. At this point both the client application and the server thread are blocked since both of their inbound ports are overflowed. See figure 3.6. To handle single thread deadlocks as described above, there are three options: prevent, avoid, or detect and recover. In this system deadlock prevention has been used.

Deadlock prevention Single thread deadlocks can be prevented by always making sure that the ports will always be large enough to hold all data, i.e. port overflows won’t happen. This approach is possible because of the predictability of the system. All systems must be carefully analyzed and configured not to send

38 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 avoid- ance that does not affect the application design. An application developer would have to make a check after each query executed, to see if it was executed suc- cessfully or not. If unsuccessful due to a full destination port, the application must call fetch with a valid statement handle to empty its own inport queue. This will avoid deadlock. This application dependency is unwanted and therefore this approach is rejected.

39 CHAPTER 3. SYSTEM DESIGN AND IMPLEMENTATION

Free space Occupied space Server inport Client inport

Client is switched in

Client sends queries but Queries gets blocked when the server inport is full

Server is switched in

The server processes some of the incoming queries and sends back responses. 7KHFOLHQW¶V Responses inport gets full and the server thread is blocked

Client is switched in

$VWKHVHUYHU¶VLQSRUW queue is not full anymore, the client can resume its Queries execution where it halted, i.e. continue sending queries

Both inports are full - Deadlock!

Figure 3.6: A connection deadlock caused by Sender Block port protocol.

40 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 applica- tion there ware many linking errors because of missing libraries in VxWorks 653. MySQL fell off since the embedded version only exists under a commercial license.

3.4.1 Filesystem The ARINC 653 specification part 2 specifies a filesystem. This is not im- plemented in VxWorks 653. However, there is a filesystem implemented in VxWorks. This filesystem is not used in this project. One reason for this is to avoid too much coupling to VxWorks 653-specific implementations. Another reason is the VxWorks simulator. Since it’s a simulator, not an emulator, the benchmarking may be even more inaccurate if disk read and write accesses are done via the host operating system. The filesystem that is used is an in-ram filesystem. It has been implemented by overloading filesystem related functions like open() and close(). The over- loading can be made since VxWorks lets you specify which functions that should be linked from shared libraries and which shouldn’t.

Filesystem usage Before using the filesystem it must be initialized. The initialization needs an array with pointers to memory regions, one region per file, and the size of the region. These memory regions can be of arbitrary sizes and are configured by the application developer. When creating a file, using open() or creat(), the first unused memory region that was given during the initialization is used. This means that one must open the files in the correct order to make sure that a file gets the wanted memory region. E.g. if one needs two files in an application, 1MB.txt and 1kB.txt, the filesystem needs to be initialized with two pointers in the initialization array. If the first pointer points to a 1MB memory region and the second pointer points to a 1kB memory region, the 1MB.txt file must be created first since the 1MB memory region is the first element of the pointer array.

Filesystem structure To keep track of open files two different structs are used, as seen in figure 3.7. The first one, file t, is the actual file struct. It has a pointer to where in the memory the file data is located. This struct also holds all locks, the filename, and the capacity and the size of the file. The second struct is ofile t. The o is for open. This struct keeps track of access mode flags and the current file pointer position. The last struct, fd t, is the file descriptor struct. It holds information about operation mode flags. The file descriptor struct and the open file struct could be merged to one, but then it would be impossible to implement file descriptor duplication func- tionality.

41 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 mod- ule requires. Except for executing pure queries the adapter interface provides functionality for transactions and for fetching a select’s resulting rowset. If the query results in one or more rows, the has result flag must be set. The adapter should also provide how many rows that were affected by the last query, i.e. how many rows got updated, deleted, inserted or selected.

3.5.1 Interface The interface for the adapters is very simple. It basically provides support for running queries and fetching results. dba init() Initializes the adapter. dba connect() Connects to the database. dba disconnect() Disconnects from the database. dba query() Executes a query. dba fetch() Fetches resulting rowset. dba has result() Records whether last query resulted in a rowset. dba affected rows() Records how many rows that were affected by last query. dba begin transaction() Begins transaction. dba commit() Commits transaction. dba rollback() Rolls back transaction.

3.5.2 SQLite adapter SQLite’s API provides two ways of executing a SQL query; via direct execution and via prepared statements. The former method is an wrapper around the latter method. This leads to less control of the execution flow. Therefore all queries are executed as prepared statements. After a query has been prepared, the statement is passed to a step function. The first thing this function does is to execute the statement, if it hasn’t been executed. It will then return a status code about the execution. If this status code is SQLITE ROW, there is a row

43 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 trans- action, this transaction will lock the entire database with an exclusive lock until it’s committed. This means that all other transactions have to wait for the lock to be released before they can execute any more queries. If there is one transaction per task in the database module and one of these transactions holds an exclusive lock, and the task suddenly is switched out, the other tasks won’t be able to perform any database queries. This will decrease the database module’s performance. A solution could be to use mutex locks and semaphores in the database module or disabling task switching to prevent nested transactions.

Result handling When a select query has been executed the result should be stored in a rowset. To build the rowset the result from the database is iterated. For each iteration a row is created and added to the rowset. To be able to add data to the rowset, the size of the data must be known. This is done by checking the data type for each column in the database.

3.5.3 Raima adapter The Raima adapter uses Raima’s ODBC interface. It runs queries via prepared statements. It’s not possible to create tables this way. This is done using Raima’s SQL Data Definition Language, SDDL, in a specialized initialization routine.

Initialization Since Raima is unable to create tables via normal SQL queries, a specialized initialization function must be used. This initialization function takes a pointer to a pointer to a string containing Raima SDDL statements. The SDDL cannot parsed right away. It has be written to a file first. Normally, this file would be parsed with Raima’s command-line SDDL tool, which is not possible in VxWorks since you cant use exec() to execute other applications. However, it is possible to link Raima’s binaries with your own and make a call to the SDDL tool’s main function sddl main().

44 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 sin- gle rows, get how many rows there are, get how many columns there are and get how much memory the stored data are using. Rowsets are created with sql rowset create(), which in turn is using malloc. This means that a rowset must be freed. This is done with the sql rowset free() function. A row is a collection of data. It doesn’t know what type of data it holds. It’s up to the user to know how to treat and transform the data. The row interface provides functionality to get column data, add column data, get number of columns and get the size of memory the data uses. A row is created with sql row create(), which in turn is using malloc. To free a row sql row free() is used. When freeing a rowset all rows in that rowset is also freed, and when a row is freed all data in that row is freed. To keep down the usage of dynamic memory a rowset can only have up to a fixed number of rows and a row can only have up to a fixed number of columns/values. However, memory for the column values are still allocated dynamically.

45 Chapter 4

Benchmarking

Benchmarking is performed to find the implemented system’s thresholds ac- cording to throughput, number of simultaneously clients and scheduling. This is required to be able to evaluate the usage of databases in an ARINC 653 environment. In the following sections, the benchmarking environment and results are described and analyzed. Comparisons between SQLite and Raima can be found in the next chapter.

4.1 Environment

The benchmarking is performed in a VxWorks 653 simulator on Windows desk- top computer. This section describes how measurements are performed and what default values are used for the benchmarking variables.

4.1.1 Simulator The simulator simulates the VxWorks 653 real-time operating system, i.e. par- titions, scheduling and the interpartition communication. The low resolution of the simulator’s tick counter forces us to mostly use long timeslots. We use 50 ms, 100 ms and 150 ms as our standard lengths but in a real system these intervals are very long. A real system often uses partition timeslots of length 5 ms or shorter. These short timeslots cannot be simulated, but have to be run on a target hardware.

4.1.2 Variables Table 4.1 shows the default values for the variables used during benchmarking. If nothing else is mentioned in each test case, these were the values that were used. Number of client partitions describes how many client partitions are sched- uled by the round robin partition scheduling in the core OS. Timeslot length is the length in milliseconds of each partition window in the above scheduling. Task scheduling describes the process scheduling inside a partition. Primary key is if the query is using the primary column for selecting single rows. Port buffer size and Port queue length are port attributes needed for communication

46 CHAPTER 4. BENCHMARKING between partitions. Table size is the initialization size of the table used in the benchmarks. Query response size is the size of the resulting rowset that will be sent back to the client. Sort result is if the resulting rowset is sorted. Client send quota is the number of queries each client will send.

Variable Value Number of client partitions 1 .. 8. Timeslot length 50,100,150 ms. Task scheduling Round robin. Primary key Yes. Port buffer size 1024 bytes. Port queue length 512. Table size 1000 rows, 16 columns Query response size 1 Row(16 cols). Sort result No Client send quota 1024

Table 4.1: Variables - default values

4.1.3 Measurement The benchmarks are created by setting different numbers of clients sending a predefined number of queries to the server. The server will then process these queries as fast as it can and measure its average and maximum number of processed queries for each of its timeslots. The minimum value was skipped since it will almost always show the value from the last timeslot where the final remaining queries are processed. The number of queries sent by each client is 1024. This value is large enough to cause full load on the database, but low enough to not need too much memory. Benchmarks in this thesis measure the server’s throughput, that is the num- ber of queries fully processed in the server during one timeslot. A fully pro- cessed query is a query that has been received from the in port, executed in the database and its result has been sent to the out port. A query that is processed in the database when a context switch occur, will be recorded in the next times- lot. The average number of the processed queries are calculated at the end of a test run by dividing the total number of queries sent to the server by the total number of timeslots the server required to finish, see equation (4.1). This measurement approach was chosen because of the simulator’s inaccurate time measurement and that queries processed is an easily understandable unit.

No. sent queries per client No. clients Average no. processed queries = ∗ P artition switches required (4.1) Every benchmark configuration has been run five times. A mean value has then been calculated from these five runs. For example, a mean value of ”parti- tion switches required” is used in equation 4.1 to calculate the average number of processed queries during one timeslot. For both databases the same benchmark configurations and the same queries have been used. The only thing different between the database benchmarks is

47 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 bench- marks. They summarize general and abnormal appearances found in the bench- marks. All benchmarks can be found in appendix A. In all graphs below the x axis shows the number of client partitions in the experiment, and the y axis shows the average number of queries as given in equation 4.1 earlier.

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

SQLite: Average insert performance 1100 50 ms 100 ms 1000 150 ms

900

800

700

600

Queries 500

400

300

200

100

0 1 2 3 4 5 6 7 8 Clients

Figure 4.1: Average inserts processed during one timeslot for different number of client partitions.

48 CHAPTER 4. BENCHMARKING

SQLite: Average insert performance 1100

1000

900

800

700 Queries

600 1 Client 2 Clients 3 Clients 4 Clients 500 5 Clients 6 Cleints 7 Clients 400 8 Clients

300 50 100 150 Timeslot [ms]

Figure 4.2: Average number of inserts processed during one timeslot of various length.

49 CHAPTER 4. BENCHMARKING

4.2.2 SQLite task scheduling This benchmark shows the select performance when using a different task schedul- ing. Yield only task scheduling is used in this benchmark, while Round robin and yield is used in the other benchmarks. See figure 4.3 for this benchmark’s result. As can be seen in the figure, the 150 ms curve is a straight horizontal line. This has to do with how the average value is calculated and is further explained in 4.3.2.

SQLite: Average select perfomance − different task scheduling 1100

1000 50 ms 900 100 ms 150 ms 800

700

600

Queries 500

400

300

200

100

0 1 2 3 4 5 6 7 8 Clients

Figure 4.3: Average selects processed during one timeslot for different numbers of client partitions and timeslot lengths. Task scheduling used is Yield only.

50 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 ap- pearance as in the insert benchmark graph. For the other two curves a small maximum can be seen at five clients. This top reoccurs in almost all graphs; both for Raima and SQLite. This is discussed in section 4.3.3.

SQLite: Average select performance 1100 50 ms 100 ms 1000 150 ms

900

800

700

600

Queries 500

400

300

200

100

0 1 2 3 4 5 6 7 8 Clients

Figure 4.4: Average selects processed during one timeslot for different numbers of client partitions.

51 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 differ- ence from SQLite, Raima does not have the 150 ms curve with the dip in the beginning. Raima is also slower than SQLite. A more in depth comparison can be found in the next chapter.

Raima: average select performance

600

500

400

50 ms 100 ms 300 Queries 150 ms

200

100

0 1 2 3 4 5 6 7 8 Clients

Figure 4.5: Average selects processed during one timeslot for different number of client partitions. The lines represent the average processed queries using different timeslot lengths.

52 CHAPTER 4. BENCHMARKING

4.3 Benchmark graphs analysis

This section explains some significant outcomes of the benchmarking experi- ments.

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

4.3.2 Average calculation issues All 150 ms curves seems to be quite strange when compared to the 50 ms and 100 ms curves. There are two different 150 ms curve appearances that are more frequent than others: ”dip at beginning” and ”always max”.

Dip at beginning The ”dip at beginning” appearance occurs in the SQLite insert, update and select graphs (See figures A.1, A.5 and A.9). This strange curve is explained by the average calculation method, see equation (4.1) on page 47. Since this method uses the number of sent queries, divided by the number of required timeslots, the calculation is very dependent on the timeslot length. A longer timeslot length leads to more queries getting processed per timeslot and thereby fewer partition switches are needed. With few clients, a small change in the number of required partition switches will have huge affect on the calculation result. If the average number of processed queries is less than a client’s total send quota, in the benchmarks set to 1024, the server will need more than one timeslot per client to finish. This means that the denominator in the average calculation increases and thereby the average performance will be reduced. With only one client running, the server manages to perform all of the client’s 1024 queries in one timeslot. When the number of clients is more than one, context switches will occur in the server that adds some overhead. This overhead makes, in the case of two clients, the server unable to perform all 2 1024 queries in two timeslots. This means that an extra timeslot is needed, and∗ the average performance is therefore heavily decreased. The calculations for the two cases are 1024/1 and (2 1024)/3. See figure 4.6 and figure 4.7. For every additionally∗ added client, the affect of the extra required partition switch will be less and less.

53 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

Database minor frame Idling

Figure 4.7: With two clients, the server cannot process 2*1024 in two timeslots due to context switches. An extra time frame is required.

Always max The average calculation can also explain some other 150 ms curves. For exam- ple figure 4.3 shows select with Yield only scheduling. Its 150 ms curve is a horizontal straight line which always has the value 1024. In this case, the average value is in reality slightly above the calculated average value of 1024. This leads to that the server will finish its processing faster. However it is not fast enough to gain an entire timeslot and skip the last partition switch. The number of partition switches are therefore the same and leads to an erroneous calculated average value. See figure 4.8.

1024 queries To slow to earn one frame

Database minor frame

Figure 4.8: The average processing speed is faster than 1024 queries per timeslot, but it is not fast enought to earn an entire timeslot.

4.3.3 Five clients top As can bee seen in most of the average graphs, the 50 ms and the 100 ms curves often show a local maximum when five clients are used. The curves increase slightly up to four clients, then a larger hop up to the maximum value at five clients and then a hop down to six clients. This local maximum might be related

54 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 times- lots SQLite is processing approximately 150 queries more than Raima. This indicates that SQLite is performing better for insert queries independent of timeslot length.

56 CHAPTER 5. COMPARISONS BETWEEN SQLITE AND RAIMA

Insert comparison

600

500

400

300 Queries

200

Raima 50 ms 100 Raima 100 ms SQLite 50 ms SQLite 100 ms 0 1 2 3 4 5 6 7 8 Clients

Figure 5.1: Comparison between average insert values in SQLite and Raima. Times- lots used in the graphs are 50 ms and 100ms.

57 CHAPTER 5. COMPARISONS BETWEEN SQLITE AND RAIMA

5.2 Update performance

A comparison between SQLite’s and Raima’s update performance can be seen in figure 5.2. The four curves describe the average queries processed for 50 ms and 100 ms timeslots. SQLite and Raima perform about the same, Raima even outperforms SQLite in 100 ms timeslot. Raima was clearly behind SQLite in the insert performance benchmark, but they are now almost equal. One possible reason for this is that Raima stores rows with fixed sized columns while SQLite stores rows with variable sized columns. This forces SQLite to fetch a row in order to be able do an update, since it does not know where in the row the column is, or if the new data fits in the current allocated space. SQLite may be forced to reorganize the database. Raima on the other hand, already knows exactly where in the row the column is. This means that Raima don’t have to fetch the row to find out where the column is. Since the column size is fixed, Raima can be sure that the new data fits and thereby perform the update without any reorganization of the database.

Update comparison

700

600

500

400 Queries 300

200

Raima 50 ms 100 Raima 100 ms SQLite 50 ms SQLite 100 ms 0 1 2 3 4 5 6 7 8 Clients

Figure 5.2: Comparison between average update values in SQLite and Raima. Times- lot 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

500

400

300 Queries

200

Raima 50 ms 100 Raima 100 ms SQLite 50 ms SQLite 100 ms 0 1 2 3 4 5 6 7 8 Clients

Figure 5.3: Comparison between average select values in SQLite and Raima. Times- lot lengths are 50 ms and 100 ms.

59 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

250

200

Queries Raima with primary key 150 Raima without primary key SQLite without primary key SQLite with primary key 100

50

0 1 2 3 4 5 6 7 8 Clients

Figure 5.4: Comparison between average select values in SQLite and Raima with and without primary key. Timeslot length is 50 ms.

60 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 400 SQLite − Yield only

350

300 Queries

250

200

150 1 2 3 4 5 6 7 8 Client

Figure 5.5: Comparison between average select queries using different task schedules in SQLite and Raima. Timeslot length is 50 ms.

61 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 10 SQLite − sort Raima − no sort 9 Raima − sort

8

7

6

Queries 5

4

3

2

1

0 1 2 3 4 5 6 7 8 Clients

Figure 5.6: Comparison between average selects with and without sorting in SQLite and Raima. The resulting rowsets are of size 128 rows and timeslot length is 50 ms.

Figure 5.7 compares the number of rows fetched from the database for single row queries and 128 rows queries. As expected, both databases can fetch many more rows during one timeslot when requesting larger rowsets as results. The database will fetch rows faster and the interpartition communication will be more effective. Fewer sends decreases the overhead.

Large responses comparison 1500 SQLite − 1 row per query Raima − 1 row per query SQLite − 128 rows per query Raima − 128 rows per query

1000 Rows

500

0 1 2 3 4 5 6 7 8 Clients

Figure 5.7: Comparison between single row select and 128 rows select queries in SQLite and Raima. Average values are showed in the graph with timeslot length of 50 ms.

62 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 con- tains to make sure we treat it correctly. If one wants to use the C interface in a server-client like environment, the database interface used in the applica- tions can’t be SQL based like ODBC. It would probably need to be a system dependent solution. The curves in Raima’s graphs show less fluctuations compared to SQLite’s graphs. This indicates that Raima’s performance is more deterministic.

6.1.2 Scalability Most benchmarking graphs are quite linear which is good since then it is possible to estimate results. If we use extrapolation on the curves we notice that curves in insert and update graphs won’t cross origo. This implies that the linearity won’t hold for low timeslot values. If the linearity did hold, it would be possible

64 CHAPTER 6. DISCUSSION AND CONCLUSION to use timeslots of zero length and still be able to process queries. This is obviously impossible. Raima does not have this behavior at all which further strengthens our conclusion that Raima’s performance is easier to estimate. It should be noted that there are few different timeslot lengths measured which makes the above discussion a bit uncertain. To validate these results, more timeslots must be tested. The three timeslot lengths used in the bench- mark were chosen because they are large enough to work with the simulator’s low resolution, while they are low enough to avoid inappropriate large port buffers. The timeslot lengths are also multiples of 50 which makes it easy to see scalability issues. As seen in most of the graphs, there is a peak at five clients. Even though it’s not verified, this peak might be due to the combination of timeslot lengths in the task and partition schedulings, and the VxWorks simulator. To make things clear about this, new benchmarks in a target environment are needed to get more trustworthy values.

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

6.2 Design and implementation

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

65 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 in- RAM filesystem by overloading system calls like open() and close().

Improvements It is probably possible to speed up the system by using pre- pared statements in a smarter way. One could have the applications send all their queries to the database. The database prepares the queries to statements, which are stored in a list. When the application then wants to perform a query, it just has to send an id for that query together with necessary parameters. In this way, the database server only needs to parse each SQL query once.

6.3 Usage and Certification

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

66 CHAPTER 6. DISCUSSION AND CONCLUSION

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

6.4 Future work

To make it possible to use our system as a safety-critical system, there are a couple of tasks that must be done. Target environment To validate the results the benchmarks must be run in a real hardware environment. The VxWorks simulator is not reliable enough. Certification If the system should be certified our implementation must be changed to use a static memory management and use certain C libraries. This should not be too hard. However, the database must also use a secure memory management, otherwise the certification would fail. This issue is harder to fix as it may require changes to the database source code if it doesn’t already comply with the certification standard.

6.5 Final words

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

67 Bibliography

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

68 BIBLIOGRAPHY

Paul, Minnesota, USA. [Available at: http://air.di.fc.ul. pt/air-ii/downloads/27th-DASC-Paper.pdf][viewed at 2009- 09-25]. [11] Wind River Systems Inc. 2007. VxWorks 653 Configuration and Build Guide 2.2.

[12] Alan Burnes, Andy Welling. 2001. Real-Time Systems and Pro- gramming Languages. Third edition. Pages 486 - 488. [13] SQLite Documentation. [Available at http://www.sqlite.org/ docs.html][viewed 2010-01-15].

[14] Mimer Information Technology. Mimer SQL homepage. [Avail- able at: http://www.mimer.com][viewed at 2009-11-16]. [15] Birdstep Technology. Raima Embedded 9.1 documentation. [Available at: http://www.raima.com/docs/rdme/9 1/][viewed 2010-01-18].

[16] Sun Microsystems. MySQL’s official website. [Available at: http://www.mysql.com][viewed 2009-11-20].

[17] Microsoft. MSDN: What is ODBC?. [Available at: http://msdn.microsoft.com/en-us/library/ms714591(VS. 85).aspx][viewed 2010-01-20].

69 Glossary

ACID Atomicity, consistency , isolation, durability. Set of properties that guaranties transaction are processed reliably API Application programming interface ARINC 653 A specification for time- and space partitioning in safety-critical real-time operating systems

Core OS Core operating system for a VxWorks 653 mod- ule. Provides OS services and schedules parti- tions COTS Commercial of The Shelf

DDL Data Definition Language, Used in Raima to specify databases DO 178B Software Considerations in Airborne Systems and Equipment certification. The avionics soft- ware developed by RTCA.

Federated architecture Software run on a single hardware FIFO Queuing protocol: First In, First out

MOS Module Operation System

OCC Optimistic concurrency control ODBC Open Database Connectivity, Standard inter- face for using databases

POS Partition Operation System POSIX Portable Operation System Interface for Unix

RAM Random Access Memory ROM Read-Only Memory RTCA Private company called Radio Technical Com- mission for Aeronautics. Developed DO-178B RTOS Real-Time Operating System

SAAB Multinational aircraft vendor SDDL SQL Data Definition Language. See DDL

70 BIBLIOGRAPHY

SDR Shared Data Region SQL Structured Query Language, language used in databases

vThreads Partition OS shipped with VxWorks VxWorks RTOS which complies to ARINC 653 part 1

71 Appendix A

Benchmark graphs

A.1 Variables

Table A.1 the default values for the variables used during benchmarking. If nothing else is mentioned in each test case, these were the values that were used.

Variable Value Number of client partitions 1 .. 8. Timeslot length 50,100,150 ms. Task scheduling Round robin. Primary key Yes. Port buffer size 1024 bytes. Port queue length 512. Table size 1000 rows, 16 columns Query response size 1 Row(16 cols). Sort result No Client send quota 1024

Table A.1: Variables - default values

A.2 SQLite

This section shows benchmarks concerning SQLite. They are divided into six categories: Insert, Update, Select, No primary key, Alternate task scheduling and Large response sizes.

A.2.1 Insert Insert query benchmarks are discussed here. Table A.2 shows non-default vari- able values for these benchmarks.

72 APPENDIX A. BENCHMARK GRAPHS

Variable Value Query type Insert Query response size 0

Table A.2: Variables that differ from the default values

Average performance This benchmark shows the average performance regarding inserts. In figure A.1 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 1000 150 ms

900

800

700

600

Queries 500

400

300

200

100

0 1 2 3 4 5 6 7 8 Clients

Figure A.1: Average inserts processed during one timeslot for different number of client partitions.

73 APPENDIX A. BENCHMARK GRAPHS

SQLite: Average insert performance 1100

1000

900

800

700 Queries

600 1 Client 2 Clients 3 Clients 4 Clients 500 5 Clients 6 Cleints 7 Clients 400 8 Clients

300 50 100 150 Timeslot [ms]

Figure A.2: Average no. inserts processed during one timeslot of various length.

74 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 800 150 ms

700

600

Queries 500

400

300

200

100

0 1 2 3 4 5 6 7 8 Clients

Figure A.3: Maximum inserts processed during one timeslot for different number of client partitions.

SQLite: Maximum insert performance 1200

1000

800

600

Queries 1 Client 2 Clients 3 Clients 400 4 Clients 5 Clients 6 Clients 7 Clients 8 Clients 200

0 50 100 150 Timeslot [ms]

Figure A.4: Maximum inserts processed for various timeslot lengths.

75 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 Value Query type Update Query response size 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 1000 100 ms 150 ms 900

800

700

600

Queries 500

400

300

200

100

0 1 2 3 4 5 6 7 8 Clients

Figure A.5: Average updates processed during one timeslot for different number of client partitions.

76 APPENDIX A. BENCHMARK GRAPHS

SQLite: Average update performance 1100

1000

900

800

700 Queries

600 1 Client 2 Clients 3 Clients 500 4 Clients 5 Clients 6 Clients 400 7 Clients 8 Clients 300 50 100 150 Timeslot [ms]

Figure A.6: Average no. updates processed during one timeslot of various length.

77 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

700

600

Queries 500

400

300 50 ms 200 100 ms 150 ms 100

0 1 2 3 4 5 6 7 8 Clients

Figure A.7: Maximum updates processed during one timeslot for different number of client partitions.

SQLite: Maximum update performance 1100

1000

900

800

700 1 Client

Queries 2 Clients 600 3 Clients 4 Clients 5 Clients 500 6 Clients 7 Clients 8 Clients 400

300 50 100 150 Timeslot length [ms]

Figure A.8: Maximum updates processed for various timeslot lengths.

78 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 Value Query type 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 1000 150 ms

900

800

700

600

Queries 500

400

300

200

100

0 1 2 3 4 5 6 7 8 Clients

Figure A.9: Average selects processed during one timeslot for different numbers of client partitions.

79 APPENDIX A. BENCHMARK GRAPHS

SQLite: Average select performance 1100

1000

900

800

700

600

Queries 500 1 Client 2 Clients 400 3 Clients 4 Clients 300 5 Clients 200 6 Clients 7 Clients 100 8 Clients

0 50 100 150 Timeslot [ms]

Figure A.10: Average no. selects processed during one timeslot of various length.

80 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

700

600

Queries 500

400

300

200 50 ms 100 100 ms 150 ms 0 1 2 3 4 5 6 7 8 Client

Figure A.11: Maximum selects processed during one timeslot for different numbers of client partitions.

SQLite: Maximum select performance 1100

1000

900

800

700

600

Queries 500 1 Client 400 2 Clients 3 Clients 300 4 Clients 5 Clients 200 6 Clients 7 Clients 100 8 Clients

0 50 100 150 Timeslot [ms]

Figure A.12: Maximum no. selects processed during one timeslot of various length.

81 APPENDIX A. BENCHMARK GRAPHS

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

Variable Value Query type Select Task scheduling Yield only

Table A.5: Variables that differ from the default values.

SQLite: Average select perfomance − different task scheduling 1100

1000 50 ms 900 100 ms 150 ms 800

700

600

Queries 500

400

300

200

100

0 1 2 3 4 5 6 7 8 Clients

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

900 50 ms 100 ms 800 150 ms

700

600

Queries 500

400

300

200

100

0 1 2 3 4 5 6 7 8 Clients

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 Value Query type Select Primary key 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

120

100

80 Queries

60

40

50 ms 20 100 ms 150 ms 0 1 2 3 4 5 6 7 8 Clients

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

120

100 Queries 1 Client 2 Clients 80 3 Clients 4 Clients 5 Clients 60 6 Clients 7 Clients 8 Clients

40 50 100 150 Timeslot [ms]

Figure A.16: Average no. selects processed during one timeslot of various length.

85 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 120 150 ms

100

Queries 80

60

40

20

0 1 2 3 4 5 6 7 8 Clients

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

140

120 Queries 100 1 Client 2 Clients 3 Clients 80 4 Clients 5 Clients 6 Clients 60 7 Clients 8 Clients

40 50 60 70 80 90 100 110 120 130 140 150 Timeslot [ms]

Figure A.18: Maximum no. selects processed during one timeslot of various length.

86 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 re- sponse sizes. No sorting is applied in the database on the results. See table A.7 for non default variable values and figure A.19 for benchmark result.

Variable Value Query type Select QUery response size 128 rows

Table A.7: Variables that differ from the default values.

SQLite: Average and maximum select performance − 128 rows response 14

12

10

8

Queries 6

4

2 Average 50 ms Maximum 50 ms 0 1 2 3 4 5 6 7 8 Client

Figure A.19: Average and maximum processed select queries. These selects ask for128 rows. No sorting is applied.

87 APPENDIX A. BENCHMARK GRAPHS

With sort This benchmark shows average and maximum performance regarding large re- sponse sizes when sorting is applied, see table A.8 for non default variable values. Resulting rows are sorted ascending order by an unindexed column. See figure A.20 for the benchmark result.

Variable Value Query type Select Query response size 128 rows Sort result Yes

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

7

6

5 Queries

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 di- vided into six categories: Insert, Update, Select, No primary key, Alternate task scheduling and Large response sizes.

A.3.1 Insert The benchmarks in this section shows Raima’s performance with respect to insert queries. Table A.9 shows the non-default values for variables used during the insert benchmarks.

Variable Value Query type Insert Query response size 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

600

500

Queries 400

300

200

50 ms 100 100 ms 150 ms 0 1 2 3 4 5 6 7 8 Clients

Figure A.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 800 2 clients 3 clients 4 clients 700 5 clients 6 clients 7 clients 600 8 clients

Queries 500

400

300

200 50 100 150 Timeslot [ms]

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

500

400 Queries

300

200

50 ms 100 100 ms 150 ms 0 1 2 3 4 5 6 7 8 Clients

Figure A.23: Maximum inserts processed during one timeslot for different number of client partitions.

Raima: maximum insert performance 800

700

600

500 Queries 1 clients 2 clients 400 3 clients 4 clients 5 clients 300 6 clients 7 clients 8 clients

200 50 100 150 Timeslot [ms]

Figure A.24: Maximum inserts processed for various timeslot lengths.

91 APPENDIX A. BENCHMARK GRAPHS

A.3.2 Update In this section update queries has been benchmarked. Table A.10 shows non- default values for variables used during the update benchmarks.

Variable Value Query type Update Query response size 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

700

600 50 ms 100 ms

Queries 500 150 ms

400

300

200

100

0 1 2 3 4 5 6 7 8 Clients

Figure A.25: Average number of updates processed during one timeslot for different number of client partitions.

92 APPENDIX A. BENCHMARK GRAPHS

Raima: average update performance 1100

1000

900

800

700 Queries

600

1 clients 500 2 clients 3 clients 4 clients 5 clients 400 6 clients 7 clients 8 clients 300 50 100 150 Timeslot [ms]

Figure A.26: Average number of updates processed for various timeslot lengths.

93 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 us- ing different timeslot lengths. In figure A.28 the lines represent the maximum number of queries processed during one timeslot for a specific number of clients

Raima: maximum update performance 1200

1000

800

50 ms 600 100 ms

Queries 150 ms

400

200

0 1 2 3 4 5 6 7 8 Clients

Figure A.27: Maximum updates processed during one timeslot for different number of client partitions.

94 APPENDIX A. BENCHMARK GRAPHS

Raima: maximum update performance 1200

1100

1000

900 1 clients 2 clients 800 3 clients 4 clients 5 clients Queries 700 6 clients 7 clients 8 clients 600

500

400

300 50 100 150 Timeslot [ms]

Figure A.28: Maximum updates processed for various timeslot lengths.

95 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 Value Query type 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

500

400

50 ms 100 ms 300 Queries 150 ms

200

100

0 1 2 3 4 5 6 7 8 Clients

Figure A.29: Average selects processed during one timeslot for different number of client partitions.

96 APPENDIX A. BENCHMARK GRAPHS

Raima: average select performance 650

600

550

500

450

400

Queries 1 clients 350 2 clients 3 clients 300 4 clients 5 clients 250 6 clients 7 clients 200 8 clients 150 50 100 150 Timeslot [ms]

Figure A.30: Average selects for various timeslot lengths.

97 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 us- ing different timeslot lengths. In figure A.32 the lines represent the maximum processed queries for one timeslot using different number of clients.

Raima: maximum select performance 700

600

500

400 Queries 300

200

100 50 ms 100 ms 150 ms 0 1 2 3 4 5 6 7 8 Clients

Figure A.31: Maximum selects processed during one timeslot for different number of client partitions.

Raima: maximum select performance 700

600

500

400

Queries 1 clients 2 clients 300 3 clients 4 clients 5 clients 200 6 clients 7 clients 8 clients

100 50 100 150 Timeslot [ms]

Figure A.32: Maximum selects processed for various timeslot lengths.

98 APPENDIX A. BENCHMARK GRAPHS

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

Variable Value Query type Select Task scheduling Yield only

Table A.12: Variables that differ from the default values.

Raima: average select performance, with yield

600

500

400 50 ms 100 ms 300 Queries 150 ms

200

100

0 1 2 3 4 5 6 7 8 Clients

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

400

Queries 300

200

100 50 ms 100 ms 150 ms 0 1 2 3 4 5 6 7 8 Clients

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 Value Query type Select Primary key 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 30 100 ms 150 ms

25

20 Queries 15

10

5

0 1 2 3 4 5 6 7 8 Clients

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

30

25

Queries 1 clients 20 2 clients 3 clients 4 clients 5 clients 15 6 clients 7 clients 8 clients

10 50 100 150 Timeslot [ms]

Figure A.36: Average selects processed for various timeslot lengths. No primary key is used.

102 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

30

25

20 Queries

15

10

50 ms 5 100 ms 150 ms 0 1 2 3 4 5 6 7 8 Clients

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

30

25 Queries 1 clients 2 clients 20 3 clients 4 clients 5 clients 15 6 clients 7 clients 8 clients

10 50 100 150 Timeslot [ms]

Figure A.38: Maximum select processed for various timeslot lengths. No primary key is used.

103 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 re- sponse sizes when sorting is applied, see figure A.39. Table A.14 shows non- default variables used in this benchmark.

Variable Value Query type Select Query response size 128 Rows (16 cols)

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

5

4 Queries

3

2

1

0 1 2 3 4 5 6 7 8 Clients

Figure A.39: Average and maximum processed selects are displayed. Each query asks for 128 rows.

With sort This benchmark shows average and maximum performance regarding large re- sponse sizes when sorting is applied, see table A.15 for non default variable values. Resulting rows are sorted in ascending order by an non indexed column. See figure A.40 for the benchmark result.

104 APPENDIX A. BENCHMARK GRAPHS

Variable Value Query type Select Query response size 128 Rows (16 cols) Sort result Yes

Table A.15: Variables that differ from the default values.

Raima: Average and maximum select performance, 128 sorted rows response 8

7

6

5

4 Queries

3

2 Average 50 ms Maximum 50 ms 1

0 1 2 3 4 5 6 7 8 Clients

Figure A.40: Average and maximum processed selects are displayed. Each query asks for 128. Results are sorted in an ascending order by an non-indexed column.

105

På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra- ordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/

© Martin Fri & Jon Börjesson Presentationsdatum Institution och avdelning 2010-02-26 IDA, Publiceringsdatum (elektronisk version) Dept. Of Computer and Information Science 2010-06-20 58183 LINKÖPING

Språk Typ av publikation ISBN (licentiatavhandling)

Svenska Licentiatavhandling ISRN LIU-IDA/LITH-EX-A--10/010--SE X Annat (ange nedan) X Examensarbete C-uppsats Serietitel (licentiatavhandling) D-uppsats Engelska/English Rapport Antal sidor Annat (ange nedan) Serienummer/ISSN (licentiatavhandling) 105

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

Antal sidor: 105

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