Development of a TCP/IP stack in a real time …...Development of a TCP/IP stack in a real time embedded system Stefan Jakobsson & Erik Dahlberg August 21, 2007 Master’s Thesis in

Development of a TCP/IPstack in a real time embedded

system

Stefan Jakobsson & Erik Dahlberg

August 21, 2007Master’s Thesis in Computing Science, 2*20 credits

Supervisor at CS-UmU: Jan Erik MostromExaminer: Per Lindstrom

Umea University

Department of Computing Science

SE-901 87 UMEA

SWEDEN

Abstract

A communication protocol is a description of the rules computers must follow tocommunicate with each other. The TCP/IP protocol suite refers to several separateprotocols that computers use to transfer data across networks. It is named after thetwo most important protocols in its suite, Transmission Control Protocol (TCP) andInternet Protocol (IP). TCP/IP is widely used because its ability to switch packets fromall shapes and sizes and varieties of networks.

The aim of this Master Thesis was to implement a TCP/IP stack in an embeddedsystem. The intended embedded system demanded some requirements on the TCP/IPstack. Only the most important protocols, and features in these protocols, should beimplemented. Memory usage should be kept low, and MISRA-C coding rules should beemployed.

This report presents how the TCP/IP stack is implemented as well as informationabout involved hardware and software. The report also gives an introduction to somebasic concepts regarding a TCP/IP stack and also information about the system inwhich the stack resides.

ii

Contents

1 Introduction 1

1.1 Outline of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Problem Description 3

2.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 VCS 5

3.1 VCS System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 VCS Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Rubus OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3.1 The Red Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3.2 The Blue Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.3 The Green Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.4 Rubus Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Software Development For Safety Critical Systems 15

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 System safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Software failuers: What can go wrong? . . . . . . . . . . . . . . . . . . . 16

4.3.1 Therac-25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3.2 Ariane 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4 What is the problem? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.5 Language Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.5.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.5.2 Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.5.3 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.7 Development of safety critical software . . . . . . . . . . . . . . . . . . . 22

4.7.1 Correctness of software based systems . . . . . . . . . . . . . . . 23

4.7.2 When is Software Ready for Production? . . . . . . . . . . . . . 25

iii

iv CONTENTS

5 TCP/IP 27

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3.1 Application layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3.2 Transport layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3.3 Network layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3.4 Network interface layer . . . . . . . . . . . . . . . . . . . . . . . 28

5.4 Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.5 Network Layer Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5.1 Internet Protocol (IP) . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5.3 Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.5.4 Header format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.5.5 Address Resolution Protocol (ARP) . . . . . . . . . . . . . . . . 33

5.5.6 Internet Control Message Protocol (ICMP) . . . . . . . . . . . . 34

5.6 Transport Layer Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.6.1 Transmission Control Protocol (TCP) . . . . . . . . . . . . . . . 35

5.6.2 User Datagram Protocol (UDP) . . . . . . . . . . . . . . . . . . 39

5.7 Application Layer Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.7.1 File Transfer Protocol (FTP) . . . . . . . . . . . . . . . . . . . . 40

6 Hardware 41

6.1 Phytec phyCore-XC167 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2 Microcontroller Infenion XC167CI . . . . . . . . . . . . . . . . . . . . . 43

6.3 Ethernet Controller Cirrus Logic CS8900A . . . . . . . . . . . . . . . . . 45

7 System description 47

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.2 Telnet Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.2.1 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.2.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.3 FTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.3.1 Supported Commands . . . . . . . . . . . . . . . . . . . . . . . . 50

7.4 Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.5 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.5.1 Data structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.5.2 Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.5.3 State machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.5.4 Establishing a connection . . . . . . . . . . . . . . . . . . . . . . 55

7.5.5 Sending data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.5.6 Receiving data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

CONTENTS v

7.5.7 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.5.8 Congestion control . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.6 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.7 IP layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.7.1 Upper level interface . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.7.2 Lower level interface . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.8 QueueLayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.8.1 ARP-module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.9 HAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8 Conclusions 71

8.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

9 Acknowledgments 73

References 75

A Abbreviations 77

B Socket Application Programming Interface (API) 79

B.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

B.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

B.2.1 Creating a socket . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

B.2.2 Accepting a connection . . . . . . . . . . . . . . . . . . . . . . . 80

B.2.3 Connect to a peer socket . . . . . . . . . . . . . . . . . . . . . . . 81

B.2.4 Send and receive data . . . . . . . . . . . . . . . . . . . . . . . . 81

B.2.5 Close a socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

B.3 Code example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

C Ethernet Hardware Abstraction Layer 85

C.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

C.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

C.2.1 Intialize Ethernet Controller . . . . . . . . . . . . . . . . . . . . . 85

C.2.2 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

C.2.3 Identifying The Ethernet Controller . . . . . . . . . . . . . . . . 86

C.2.4 Link Status of Ethernet Controller . . . . . . . . . . . . . . . . . 86

C.2.5 Send a Ethernet Frame . . . . . . . . . . . . . . . . . . . . . . . 86

vi CONTENTS

List of Figures

3.1 Example of a VCS System . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Inside a VCS node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4 Rubus overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.5 Clock scheduler in the red kernel . . . . . . . . . . . . . . . . . . . . . . 10

3.6 Legal state transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.7 Blue thread scheduling in Rubus . . . . . . . . . . . . . . . . . . . . . . 12

3.8 Rubus Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.1 An example of a network . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 IP header format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3 A small Local Area Network example . . . . . . . . . . . . . . . . . . . . 33

5.4 TCP header format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.5 Example of sequence and acknowledgment numbers . . . . . . . . . . . . 36

5.6 Example of how a TCP connection is established. . . . . . . . . . . . . . 37

5.7 UDP header format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1 Block diagram of phyCore-XC167 . . . . . . . . . . . . . . . . . . . . . . 42

6.2 Modification of phyCore-XC167 . . . . . . . . . . . . . . . . . . . . . . . 42

6.3 XC167CI Memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.4 Overview of XC167CI’s on-chip components . . . . . . . . . . . . . . . . 45

7.1 The TCP/IP-stack is built in a layered structure . . . . . . . . . . . . . 47

7.2 Data buffer organization for a TCP packet with N bytes of data . . . . 54

7.3 Overview of the send-algorithm . . . . . . . . . . . . . . . . . . . . . . . 56

7.4 Receive procedure for the Application-Thread . . . . . . . . . . . . . . . 59

7.5 Receive procedure for the Receive-Thread . . . . . . . . . . . . . . . . . 60

7.6 Packet queues buffer organization . . . . . . . . . . . . . . . . . . . . . . 65

7.7 Application-Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.8 Work process for the Receive-Thread . . . . . . . . . . . . . . . . . . . . 67

B.1 System structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

vii

viii LIST OF FIGURES

C.1 System structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

List of Tables

4.1 Definitions of controllability levels . . . . . . . . . . . . . . . . . . . . . 24

5.1 Address classes in IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 A possible ARP table in node 192.168.0.17 . . . . . . . . . . . . . . . . 33

5.3 ICMP message types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.1 Memory organization in CS8900A . . . . . . . . . . . . . . . . . . . . . 45

6.2 CS8900A I/O port mapping . . . . . . . . . . . . . . . . . . . . . . . . . 46

ix

x LIST OF TABLES

Chapter 1

Introduction

The use of embedded systems are common in many areas today. These systems varyin size, scope of use and complexity and resides in everything from toasters to spaceshuttles. An embedded system is a combination of computer hardware and softwarethat is manufactured to handle a specific task. Although an embedded system is usuallya single-purpose application, it is often integrated with other embedded systems whichtogether performs advanced functions.

Ordinary personal computers are designed to satisfy a variety of users and to runmany different kinds of applications. Embedded systems can be specialized in terms ofhardware and software for its specific task. This limited scope of use makes it possibleto design these systems to perform as efficiently as desired, and thereby keeping thecosts down. One domain using embedded systems is the vehicle industry. A moderncar contains many embedded systems which handles functionality like Anti-lock BrakingSystems (ABS) and Cruise Control.

Another vehicle industry using embedded systems in their products is the defenceindustry. One leading manufacturer of combat vehicles are BAE Systems Hagglundsin Ornskoldsvik (Sweden) with over 1200 employees. This master thesis was proposedby Hagglunds and involved an embedded system in a combat vehicle. The task was toextend this system with a TCP/IP stack, which is used to transmit data over a network.

1.1 Outline of this report

This thesis report describes the project made for BAE Systems Hagglunds. Chapter 7will explain how the work was done, thus describing the actual implementation detailsof the project. Preceding chapters are meant to give an insight of the overall system,which involves both hardware and software. There is also an in-depth study, in chapter4, discussing topics concerning development of safety critical software.

This project is an extension of an existing system in a combat vehicle. The system iscalled VCS (Vehicle Control System) and chapter 3 will explain what components VCSconsists of and how they interact. After the in-depth study, chapter 5 will explain theresponsibilities of a TCP/IP stack, which is a suite of transport protocols. A subset ofthese protocols will be explained in terms of how they work and cooperate. Readers

1

2 Chapter 1. Introduction

familiar with TCP/IP and its protocols might skip this chapter. The hardware used forthis project is presented in chapter 6.

After the description of the implementation in chapter 7, future work and limitationsof the solution is discussed. The list below gives a short description of the differentchapters, provided to give a quick overview of this report.

– Chapter 3

Describes VCS and VCS Core.

– Chapter 4

Introduction to software development in safety critical systems.

– Chapter 5

Information about TCP/IP.

– Chapter 6

Describes the hardware used for this project.

– Chapter 7

Presents and describes the result of our implementation.

– Chapter 8

Presents limitations of the current implementation and suggestions for future work.

Chapter 2

Problem Description

2.1 Problem Statement

When Hagglunds developed their new combat vehicle CV9030CH, a new distributedcomputer based system called Vehicle Control System (VCS) was born. This electricalsystem replaced the old systems built upon cables and relays. VCS consists of severalmicrocontrollers which uses CAN (Controller Area Network) to communicate with eachother. CAN is based on a shared serial bus developed for connecting electronic controlunits. VCS is responsible for controlling and monitoring vehicle functions such as fans,engines etc. Each microcontroller is configured to perform a specific task. To ease de-velopment of software for each microcontroller, all common functions were gathered andforms a framework under the name VCS Core. This framework can be viewed as anOperating System though it is built upon a small Real-Time Operating System calledRubus OS.

The assignment of this master thesis was to extend VCS Core with a TCP/IP stack.In addition to implementing the stack, the project also included implementing drivers tothe ethernet-controller. Applications that use the network communication tools providedby the TCP/IP stack, like FTP and Telnet, should also be implemented if time allowed.Certain aspects concerning the project had to be considered. First, the TCP/IP stackshould use as little memory as possible, because VCS is running on small microcontrollerswith limited resources. Further, the implementation should follow a number of codingguidelines. One guideline which had a big impact of the systems design was that nodynamic memory allocation was allowed.

2.2 Goals

The main purpose of this thesis was to investigate the possibility of a TCP/IP-stack inthe VCS system. Is it realistic to have a TCP/IP-stack in VCS core or will it consumeto much memory and CPU-time? The goal was therefore to implement a TCP/IP-stackinto the VCS Core framework that meets the systems demands. VCS had no supportfor TCP/IP whatsoever, so everything had to be done from scratch. This made it hardto estimate how much work and time that was needed for this project. Therefore thegoal was divided into the following sub-goals:

3

4 Chapter 2. Problem Description

– To Construct a driver for the Ethernet controller CS8900 adapted for VCS Core.

– To be able to send and receive Ethernet frames.

– To be able to ping a VCS node.

– To be able to set up a TCP-connection.

– A working Telnet-server that allows remote login.

– A working FTP-server to download log-files.

Many opportunities arise if communication with a VCS-node through Ethernet waspossible. Diagnostic information could be downloaded via FTP, or possibilities of remotelogin with Telnet. Also many 3:rd part components communicates through TCP/IP andintegration of such components could easily be done with a TCP/IP-stack in VCS.

Chapter 3

VCS

3.1 VCS System

VCS (Vehicle Control System) is the result of a new distributed computer based elec-trical system that was developed for the combat vehicle CV9030CH. Together withVCS another system called VIS (Vehicle Information System) was also developed asa complement to VCS. The system is based on different microcontrollers with CAN-communication, also called nodes. Each node runs VCS Core software and has oneor several different CAN interfaces. Normally a node is connected to a single CAN-network but it can be configured to act as a gateway between different CAN-networks.An example of a VCS System installed in a vehicle is seen in Figure 3.1.

Figure 3.1: Example of a VCS System

There are several advantages of using software and buses instead of cables and relaysin a electrical system. Software makes it more flexible and configurable. It makes it easyto build vehicle simulators, test-benches, virtual vehicles and also to discover and reacton errors that can arise in components. Software will also make it possible to use BuiltIn Tests (BIT) for error detection, which Hagglunds describes as a requirement fromcustomers. Another benefit with a software system is that it simplifies communicationswith 3:rd part systems like a GPS etc.

The electrical system inside Hagglunds combat vehicles can be divided into differentfunction domains, where each domain has special requirements. An overview of a typical

5

6 Chapter 3. VCS

computer based distributed electrical system and how it can be divided in differentdomains is shown in Figure 3.2.

Figure 3.2: System overview

As seen in the picture above the system has been divided in three function domains.To meet the function requirements of each domain Hagglunds has, besides VCS, devel-oped three other core platforms named Vehicle Information System (VIS), ExtendedControl System (ECS) and Diagnostic Information System (DIS). DIS is an externalsystem that is plugged into the CAN-network when diagnostics is needed.

– Information domainMan Machine Interface (MMI) manages and presents information to the userthrough displays, alarms, diagnoses, videos etc. All of these functions are han-dled by the VIS. Typical information that are presented here is:

• Operation data (instrumentation, meters etc).

• Ongoing errors (symbols + information texts).

• Manuals.

• Performing system test and diagnosis.

• Maps.

3.1. VCS System 7

Occasional disturbances that can arise in this domain will not effect the vehicle be-cause it contains no functions that controls the vehicle. VIS runs on PC machineswith Linux and communicates with each other through TCP/IP via Ethernet. Tobe able to communicate with nodes in the utility domain, one VIS-node must actas a gateway.

– Utility domainThe functions here provide the normal vehicle functionality such as:

• Controlling of motors, valves, wipers, lighting etc.

• Reading of important signals like safety loops, emergency stop etc.

• Detection of errors, so called build in tests (BIT).

• Logging of operational data.

These functions are managed by VCS. Communication within the domain here isexclusively done through CAN-buses.

– Real-Time domainAlthough VCS can be used in this domain, the primary choice is ECS. ECS is a bigbrother to VCS, and is based on VxWorks OS. The functions in this domain hashigher real time demands than in the utility domain. The functions here includeballistic calculations which require more computational power than the 40 Mhzmicrocontrollers can offer. Therefore ECS is running on Power PC machines at266 Mhz.

A fourth, safety-Critical, domain could also be added in the system view. The domainwould contain safety-critical operations like drive-by-wire systems for electrical steeringor braking. These operations are today traditionally done mechanically or hydrauli-cally but it will probably change in the future. Then VCS could be an alternative tocommercial solutions.

8 Chapter 3. VCS

3.2 VCS Core

Inside a VCS node the software can be divided into layers according to Figure 3.3. Atthe bottom there are Electronic Hardware, like signals, clocks, communication portsetc. Then comes the Hardware Abstraction Layer (HAL) that provides standardizedmethods to access different hardware. Above the HAL comes the VCS Core whichcontains a small Real-Time Operating System (RTOS) and a configuration part. Themain task of VCS Core is to provide common services and functions like I/O, monitoring,logging and CAN-protocols. With the configuration part it makes it easy to configurenodes for different applications. VCS Core is written in a subset1 of ANSI C and designedto be platform and compiler independent. This can be done because all hardware-specificsoftware is located in the HAL. It is also possible to simulate one or more VCS nodeson a ordinary PC, then the real CAN-drivers is replaced by drivers that communicatesthrough a shared memory.

Figure 3.3: Inside a VCS node

3.3 Rubus OS

The most inner part of the VCS Core is the Real-Time operating system Rubus OS,made by Arcticus Systems AB. Like all Real-Time operating systems time plays anessential role in Rubus. Typically a Real-Time operating system must react on externaldevices in a very constrained time period. Application operations running in Real-Time systems can be divided into two groups; hard Real-Time and soft Real-Time. Inhard Real-Time it is critical for the application operation to meet its deadline. In soft

1A subset specially developed for using C in safety critical systems called MISRA C

3.3. Rubus OS 9

Real-Time it is not critical if a deadline is missed but it is still not desirable. Becauseof different demands of application operations, Rubus OS provides three categories ofrun-time services:

– Green Run-Time ServicesExternal event triggered execution (interrupts).

– Red Run-Time ServicesTime triggered execution, used by applications which deadlines are critical to theoperation (Hard Real-Time).

– Blue Run Time ServicesInternal event triggered execution, for applications which deadlines are not criticalto the operation (Soft Real-Time).

Figure 3.4: Rubus overview

As seen in the Figure 3.4 Rubus OS contains three kernels:

– Red Kernel

– Green Kernel

– Blue Kernel

Each kernel is responsible for its the corresponding run-time service. The Red Kernelmanages the execution of time triggered red threads. Red threads are statically sched-uled before run-time. The Blue Kernel handles execution of internal event triggered bluethreads. Scheduling of blue threads is done during run-time. The green kernel managesthe execution of interrupt triggered green threads.

10 Chapter 3. VCS

3.3.1 The Red Kernel

The red kernel contains services related to time driven execution. Its main task is todispatch threads according to the current schedule and the current time. The scheduledefines when threads are to be executed. When the dispatcher reaches the end of theschedule it starts over from the beginning. This schedule can be illustrated as a clock.In Figure 3.5 Thread A will execute in slot 0. Thread B and C in slot 4 and 5. Whenthe clock has completed one rotation it will start over. Several schedules can co-exist inthe system and the Red Kernel contains functionality for switching between them. Theschedules are statically defined before run time.

Figure 3.5: Clock scheduler in the red kernel

3.3. Rubus OS 11

3.3.2 The Blue Kernel

The Blue Kernel contains management of blue threads and services for communicationbetween threads such as synchronization and message passing. Synchronization is doneby message queues, signals and mutexes according to the POSIX standard. The BlueKernel is a traditional event triggered kernel with a preemptive scheduling algorithm,which means that each thread will run for a maximum amount of some fixed time. If thethread is still running at the end of its given time it will be suspended and the schedulerwill select another thread to run [19]. The Blue kernel provides different priorities forblue threads and guarantees that the thread with highest priority, among the readythreads, will be executed first. Like everything else in Rubus the stack is allocatedstatically and the size of the stack can not be altered at run-time. Therefore the size ofthe stack must be dimensioned to the maximum stack usage. A blue thread can be inone of the following states:

– DormantThe thread is terminated or not initialized.

– ReadyThe thread is ready to execute.

– BlockedThe thread is blocked waiting for a signal.

– RunningThe thread is running.

Legal state transitions can be seen in figure 3.6.

Figure 3.6: Legal state transitions

12 Chapter 3. VCS

There are 16 thread priority levels, from 0 to 15, where 15 is reserved for the BlueKernel Thread and 0 is used (but not reserved) by the Blue idle thread. Each prioritylevel has an internal thread FIFO list which is scheduled in a Round-Robin manner.Within this list the threads are ordered by the time they arrived.

Figure 3.7: Blue thread scheduling in Rubus

Blue threads are scheduled during run-time and are executed when no red threadsare running. Either when no red threads are scheduled or when the red threads do notutilize all time that was given to them. When it is time for a blue thread to execute,the thread with highest priority among all blue threads that are ready will be selected.If a blue thread is executing and a higher priority thread becomes ready, the runningthread will be preempted and moved to the Ready-state.

3.3.3 The Green Kernel

The Green Kernel handles interrupt processing using Green Threads. The dispatch unitin the Green Kernel is the target processors interrupt logic. Therefore the behavior istarget dependent. If an interrupt occurs, a Green Thread will preempt the execution ofboth Red and Blue Threads.

3.3. Rubus OS 13

3.3.4 Rubus Visual Studio

Arcticus Systems has developed a configuration tool, to ease the development of de-pendable Real-Time system, based on Rubus OS. All threads in VCS Core are createdbefore run-time, and Rubus Visual Studio provides a interface which makes it easy toadd and remove such threads.

Figure 3.8: Rubus Visual Studio

14 Chapter 3. VCS

Chapter 4

Software Development ForSafety Critical Systems

4.1 Introduction

Failures are not desirable in any systems. But the consequence of something going wrongis not equal for all systems. If the software in a desktop computer crashes a couple ofworking hours may be lost, while a software failure inside an aircraft’s fly-by-wire systemcould lead to lost lives. In other words, there are systems where software failures areacceptable at some level and there are systems where failures are unacceptable[10].Safety-critical systems are those systems where failures are unacceptable, a failure insuch system could result in loss of life, significant property damage or damage to theenvironment. Traditional areas where these systems can be found include:

– Military, e.g. weapon systems.

– Space programs.

– Industry, e.g.manufacturing control where toxic substances are involved, and robots.

– Transport, e.g. fly-by-wire systems in aircraft, aircraft control. Interlocking sys-tems for trains.

– Medical devices.

– Nuclear power plant control.

A failure in these areas can directly lead to that human lives are put in danger. Manysafety critical systems are embedded systems, many do also have Real-Time demands. Ina Real-Time system a correct, but delayed, response can have equal serious consequences.Imagine a system controlling the air-bag in a car, if the air-bag is triggered too late itwill do more harm then good. This chapter will focus on the software aspect of safety,and discuss desirable properties of a programming language. Safety critical systemsare not necessarily (but often) embedded systems or Real-Time systems. Therefore theaspects of both embedded and Real-Time systems will be considered.

15

16 Chapter 4. Software Development For Safety Critical Systems

4.2 System safety

It is important to realize that computers are not unsafe by themselves. They rarelyexplode, catch fire or cause any physical harm. Computers can only indirect causeaccidents and therefore must safety be evaluated in the context of the whole system.System safety is often described in terms of hazards and risks. Leveson[12] defineshazard and risk as:

A hazard is a state that can lead to an accident given certain environmentalconditions.

A risk is defined as a function of:

1. The likelihood of a hazard occurring.

2. The likelihood that the hazard will lead to an accident.

3. The worst possible potential loss associated with such an accident.

An example of a hazard would be brakes failing in a motor vehicle. It will not nec-essarily cause an accident but it is certainly a state that can lead to an accident. Ifsystem safety was defined by accidents or catastrophic failures instead of hazards andrisks, most systems could be considered safe.

In this definition, software itself can not directly cause accidents but rather onlycontribute to hazards. However, because of software can contribute to system hazards,minimizing software flaws will therefore reduce or prevent accidents.

It is also important to separate safety from reliability. Reliability is often measuredin up-time or availability of a system. A safe system can fail frequently provided thatit fails in a safe way. While a reliable system may not fail often, it makes no guaranteeswhat happens when it fails. Systems can be safe but not reliable. A rail-road signalingsystem may be very unreliable but still safe if every time it fails ends up with showing’stop’. Similar a system can be reliable but unsafe. Reliability can also be achieved bythe cost of safety when errors are ignored, and systems are allowed to continue for thecause of availability. Place and Kang [17] points out that safety software requires notto be perfect. The code may contain errors as long the consequence of the errors do notlead to hazards.

4.3 Software failuers: What can go wrong?

Today, flaws in software products are common. Software patches and updates are con-stantly released to correct previous problems. People have come to accept that softwarefails once in a while. However, in safety critical systems there is no acceptance for failure.Unfortunately, safety critical systems are not completely spared from software failures.In this section a few examples will be presented, all where the failure was caused bysoftware errors.

4.4. What is the problem? 17

4.3.1 Therac-25

One of the most known software-related safety failure occurred in a radiation therapytreatment device called Therac-25. It was developed by the Atomic Energy of CanadianLimited (AECL)in the late 70th, and in 1982 the cancer treatment machine was ready.Therac-25 was like its predecessor Therac-6 and Therac-20 controlled by a DEC PDP-11 computer. In Threac-6 and Therac-20, which relied on hardware safety featuresand interlocks, the software played a minor part. However, the software in Therac-25had more responsibility for maintaining system safety [11]. Due to some software flawsin Therac-25, six patients received an overdose of radiation. The accidents occurredbetween 1985 and 1987 when Therac-25 was recalled. Three of the accidents had alethal outcome.

4.3.2 Ariane 5

Ariane 5 is an European launch system designed to deliver satellites and other payloadinto space. In June 4 1996, after 10 years of development and a cost of e7 billion, Ariane5 was finally ready for its first test flight (flight 501). The launch went well and Ariane5 followed a normal trajectory for 37 seconds. But shortly after, it suddenly veered offits flight path, broke up, and exploded. A data conversion from 64-bit floating pointto 16-bit integer had caused a software exception. The floating point number had avalue greater than what could be represented by a 16-bit signed integer. This led to anOperand Error -exception. Due to efficiency considerations the software handler (in Adacode) for this trap was disabled, although other conversions of comparable variables inthe same place in the code were protected. This software flaw was located in the InertialReference System (SRI) which provides flight data to the On-Board-Computer (OBC).The OBC is responsible for executing the flight program and controlling the nozzles ofthe solid boosters. Because of the software exception, the SRI transmitted erroneousflight data to the OBC. The flight data resulted in full nozzle deflection of the boosterand the self destruction mechanism was eventually triggered when the aerodynamicloads became too high. More details about the Ariane 501 flight failure can be found in[4].

4.4 What is the problem?

Despite that accidents have occurred due to software failures, software controlling safetycritical systems are here to stay. The use of software provides a number of advantagesover hardware. Software is flexible and easy to modify and can also provide a betterinterface for users. With software, it is easier to simulate and test the whole or partsof a systems. So called Built-In-Tests (BIT), where software examines the system sta-tus, is also feasible with software. It is cheaper to reproduce software than hardware,although maintaining the software can be the opposite. As systems are responsible formore and more complicated tasks, the software controlling the systems are getting morecomplex. Because of the software complexity, the human design-errors has increaseddramatically and it is hard, if not impossible, to ensure the correctness of the soft-ware. Before software was used in safety-critical systems, they were often controlledby non-programmable electronic and mechanical devices. Parnas[15] argues that analogsystems, such as mechanical- and hydraulic systems, are made from components that,within a broad operating range, have an infinite number of stable states and whose


behavior can be adequately described by continuous functions. When systems are de-scribed by continuous function it means that small changes in inputs will always causecorrespondingly small changes in output. This is not the case in a discrete system wherea single bit change can have a huge impact. The mathematics of continuous functions iswell understood and this combined with testing to ensure that components are withintheir operating range, leads to reliable systems.

4.5 Language Selection

There are plenty of programming languages to choose from today, each have its own ben-efits and is suitable for different tasks. Java, with its byte code, is platform independentwhile C is more suitable for low level programming etc.

A programming language itself can of course not guarantee the correctness of thesoftware. However, it can help the programmer in the right direction. The philosophyof C is to trust the programmer while other languages are more restrictive. A quotefrom Powell [6] describes this very well:

C treats you like a consenting adult. Pascal treats you like a naughty child.Ada treats you like a criminal.

Especially when developing safety critical systems the choice of programming lan-guage should be carefully considered. Some characteristics that generally improves thesafety of a programming language are:

– Strong compile-time checking

– Strong run-time checking

– Support for encapsulation and abstraction

– Exception handling

At compile-time checking the code is evaluated according to the grammatical rulesof the language. A more comprehensive check will increase the reliability of a languagewhen many common programming mistakes are discovered early. Consider the Pascal -code below:

Program Test;

var

x : integer;

y : real;

myArray : array[1..10] of integer;

begin

y := 3.14;

x := y; /* Syntax Error, Incompatible types */

myArray[11] := 4; /* Syntax Error, Range check error */

end.

The code will not pass a Pascal -compiler since two rules are broken. However, thecorresponding C -code would compile. Many strongly typed language as Java, Ada,Pascal etc. offers a better compile time checking and they are therefore considered as”safer” than a language like C. Another good feature with compile-time checking is thatno extra overhead is generated in the execution.

4.5. Language Selection 19

As mentioned earlier, many errors can be prevented with a better compile-timechecking, but all errors cannot be discovered before run-time. The next step is to providerun-time checking. A typical example of run-time checking is array range checking.Consider following statement:

array[i] = 11;

In C with no run-time checking, the value 11 will be stuffed into the memory locationpointed out by the array and index i. No implicit checking of the index i will be done.If the corresponding code was written in Ada, Pascal or Java, the variable i would bechecked during run-time. This will, of course, force the compiler to generate some extracode and therefore effect both code size and execution time. Because of the performanceloss, some developers dislike run-time checking although it provides increased safety.

The ability to handle run-time errors as well as other unusual states that can arisein software is important to achieve safety. An exemplary way for a programming lan-guage to handle this, is to provide exception handling. Exceptions are preferred overerror codes for several reasons. Checking return codes from functions, as the normal wayin C, tends to mess up the code and makes it harder to follow. Consider the codes below:

retValue = function1( x , y);

if ( retValue < 0 )

{

switch (retValue)

{

case ...

case ...

}

}

retValue = function2( z , v );

if ( retValue < 0 )

{

switch (retValue)

{

case ...

case ...

}

}

try {

retValue = function1( x , y);

retValue = function2( z , v );

} catch ( ... )

{

/* Handle exceptions */

}

With exception handling the error handling code can be separated from the rest ofthe code and prevent to obscuring the actual program logic. Checking return codes isa manual process, the programmer needs to remember to check every time the functionis used. It is all too easy to circumvent the error handling system with return codes1.With exception handling, the exceptions has to be handled, or ignored explicitly by theprogrammer. This makes it harder to forget (or skip) error handling.

1When did you lately check the return value of the printf()-function in C


Properties that make a programming language safer can also be more subtile thanthose which has been described so far. Depending on how the grammatical rules of alanguage is formed, ordinary typing errors can more or less easily slip into the code andcause unexpected behavior. For example, in C ’=’ is used for assignment and ’==’ forcomparison, this notation can easily result in the typing mistake shown in statement(1):

if ( a = b ) ( 1 )

if ( a == b ) ( 2 )

In C the statement (1) will always be true as long b 6= 0 and (2) will be true onlyif a = b. In java statement (1) would not pass the compiler since a boolean type isexcepted.

If a language has features that are not completely or ambiguously defined, the pro-grammer can assume that the compiler interprets the code differently than expected.This is mainly an issue when using different compilers, but one compiler can also behavedifferently depending on context.

4.5.1 Java

The Java programming language was initially designed to be used in embedded systems[18]. Sun Microsystems were not satisfied with Cand C++ for developing software forelectronical devices. C lacked the support of object-oriented programming, and C++was far too complex. They also believed that neither of them could provide enoughreliability. Sun’s guidelines when designing Java were therefore that it should be morereliable and simpler than C++. Although Java was designed for embedded systems,no electronic products using Java reached the market in the beginning. Instead, Javawas found to be a useful tool when the Word Wide Web became widely used. Today,Java has matured and is widely used in different systems, not to mention in embeddeddevices such as mobile phones where Java has grown strong. Java has several featuresthat are suitable for safety software development:

– Strong typing.

– Exception handling

– Run time checking of Null pointers and array ranges etc.

Although Java is used in many embedded systems, it has not been used for the sameextension in Real-Time systems. Many safety critical systems belong to the Real-Timedomain where predictability of execution is important. The automatic memory man-agement in Java leads to unpredictable latencies in execution. There is also some un-predictability in synchronization[2]. Beyond requirements for Real-Time systems thereare also features needed for embedded systems, such as low level programming, writinginterrupt procedures. This is a weak area (with purpose) of Java since it both com-promise portability and safety. To address the problems with Java, Sun Microsystemscreated a Real-Time Specification for Java (RTSJ).

4.6. Conclusion 21

4.5.2 Ada

Not surprisingly Ada is considered as the most suitable language for safety-critical-systems. Ada is the result of the most extensive and most expensive language designeffort that has ever been made[18]. It was standardized by the American NationalStandards Institute in 1983 but the first truly usable Ada compilers did not appearuntil two years later. Ada was developed to meet the high demands of a Department ofDefense (DoD) and to be used in their safety critical systems. Although Ada receivedsome criticism in the beginning, especially from Hoare in[7] that he thought it was toocomplex, it became the primary choice for programming safety critical systems.

4.5.3 C

C is not known as a reliable programming language. The language is suitable forlow-level programming and is therefore popular for programming embedded systems.There are C -compilers available for most architectures, therefore C -programs are veryportable. Some safety flaws in C have already been discussed, but there are also a num-ber of drawbacks when using C in Real-Time systems. C has no language support forconcurrency (multithreading), a serious drawback for Real-Time systems. The program-mer needs to use an external application programming interface or Real-Time operatingsystem (RTOS) which compromises portability.

4.6 Conclusion

Writing software for safety critical systems is not an easy task. Whatever programminglanguage, reliable or not, it is still up to the programmer to implement the software cor-rectly. Implementation is only one part of the software development process. To achievesoftware safety, each step from design to testing must be rigorouly defined. It is alsoimportant to remember to use trusted developing tools when developing the software,the compiler itself can be considered as safety critical.

Computer systems are already widely used in our society today and more and moreapplications will rely on computers in the future. Software systems will also be trustedin a higher extent. Modern cars are already filled with small computers, but still nocar contains drive-by-wire technology (replacement of mechanical operation devices byelectrical signals). The car industry is a bit behind the flight industry where manymodern planes today are controlled by fly-by-wire systems. It just a matter of timebefore such systems also will be introduced in the cars.


4.7 Development of safety critical software

In many areas the use of embedded systems increase rapidly. The software in thesesystems handles more and more advanced tasks, and thus becomes bigger and morecomplex. In some areas, including the motor vehicle industry, these systems handlestasks that are more or less safety critical. An example of a relatively complex safetycritical system, used in cars, is Adaptive Cruise Control (ACC). This system is similarto conventional cruise control, which holds a preset speed without participation of thedriver. The extra feature this system provides is the ability to adjust speed automaticallyto maintain a distance to the vehicle ahead. This is achieved through a radar headwaysensor, digital signal processor and a longitudinal controller. If the lead vehicle slowsdown, or if another object is detected, the system sends a signal to the engine or brakingsystem to decelerate. Then, when the road is clear, the system will re-accelerate thevehicle back to the preset speed. This kind of system involves interaction between manyvehicle control systems and is also a relatively new technique. A software system ofthis complexity has a potential for problems. Interesting questions about safety criticalsystems are:

1. How can confidence in software based systems be increased?

2. When is software ready for production, and how shall this be determined?

One organization dealing with these issues is MISRA, short for The Motor IndustrySoftware Reliability Association. MISRA is a collaboration between vehicle manufac-turers, component suppliers and engineering consultancies which seeks to promote bestpractice in developing safety-related electronic systems in road vehicles. In 1994 MISRApublished guidelines for the development of software for vehicle-based systems, theseguidelines are meant to ”provide important advice to the automotive industry for thecreation and application of safe, reliable software within vehicles”[3]. The list belowshows what these guidelines include.

– guidance for creating contracts and specifications for software procurement.

– an introduction to issues of automotive software reliability.

– a basis for training requirements within the automotive industry.

– guidance for company quality procedures.

– guidance for management on resource requirements.

– a basis for assessment.

– a foundation for a standard.

The vehicle manufacturer is responsible for the safety of its product, so which de-velopment process to use is decided by the manufacturer. The techniques described insection 4.7.1 are proposed approaches from MISRA, which will give examples of tech-niques for question 1 above. Then in section 4.7.2, the second question will be discussed.

4.7. Development of safety critical software 23

4.7.1 Correctness of software based systems

MISRA guidelines gives recommendations covering the whole software development pro-cess. One important aspect of the development process is the systems involved hazards.These must both be understood and taken into consideration at an early stage. Doingthis makes it possible to take design actions that can reduce these risks. It is also impor-tant to have documents of the reasoning behind the design actions taken. Therefore thefirst step in the process is to make a hazard analysis. For this analysis to be accuratea model, or approximation, of the system must be produced. Often the system can beassociated with many potential hazards which can lead to human injury, but most ofthese hazards are limited to specific physical situations. The model should thereforehave a well defined boundary between the system itself and the potential situations thatcan lead to hazards. Also the boundaries between components within the system itselfas well as boundaries between the system and other subsystems shall be defined. Amodel shall consist of:

– Components.

– The interconnections between the components.

– The boundaries.

The level of detail chosen for defining a component depends on what type of systemthe model shall describe. Each component has some sort of interface to other compo-nents in the system, which shall be included in the model. The interface shall describehow components communicate with each other, and the format of this interface dependson what type of component is being described. For a system in a car, most hazardswill be related to the movement of the whole vehicle. Therefore an important boundaryto include is the one between the vehicle and its environment. Examples of environ-ment can be driver, passenger, road, and other vehicles. Possible interactions with theenvironment are:

– Inputs - All devices that a driver can use to control signals to the system.

– Outputs - All displays and warning systems for the driver.

– Physical properties - Physical materials used etc.

When the model is complete, a Preliminary Hazard Analysis (PHA) can be per-formed. One technique used for the analysis is Failure Mode & Effects Analysis (FMEA),which is often called a ’what if?’ analysis. This analysis begins by identifying possiblehazards. Each boundary is considered in turn and the hazards related to its environmentare considered systematically. FMEA both considers hazards related to some systemfailure and when the system is working as desired. In complex systems, there can be achain of events that finally lead to a hazard. This means that other systems, whom canbe affected by a fault of the system being developed, also must be considered. Thereis no easy task finding all possible hazards, but a well performed hazard analysis willultimately lead to a safer system.

Once the hazard analysis is complete, the systems Safety Integrity Level (SIL) mustbe determined. This value between 0 and 4 classifies the hazards according to theirseverity, and is needed to determine the development process. A system with a low SIL


does not have to be designed, documented and built as thoroughly as a system witha high SIL. There are many techniques to determine the Safety Integrity Level for asystem, but most of them consider systems in static environments. The non-static envi-ronment for vehicle systems is practically infinite. Aspects like the skill of the driver andweather conditions must be considered. Therefore the MISRA Guidelines have adoptedthe concept of controllability as a means of determining safety integrity levels for sys-tems which do not have a static environment[13].

Controllability measures what degree of loss of control a fault causes. The greaterthe loss of control the more serious the failure. Table 4.1 shows how the different levelsof controllability are defined.

Uncontrollable This relates to failures whose effects are notcontrollable by the vehicle occupants, and whichare most likely to lead to extremely severeoutcomes. The outcome cannot be influenced by ahuman response.

Difficult to control This relates to failures whose effects are notnormally controllable by the vehicle occupants butcould, under favorable circumstances, beinfluenced by a mature human response. They arelikely to lead to very severe outcomes.

Debilitating This relates to failures whose effects are usuallycontrollable by a sensible human response and,whilst there is a reduction in safety margin, canusually be expected to lead to outcomes whichare at worst severe.

Distracting This relates to failures which produce operationallimitations, but a normal human response willlimit the outcome to no worse than minor.

Nuisance only This relates to failures where safety is notnormally considered to be affected, and wherecustomer satisfaction is the main consideration.

Table 4.1: Definitions of controllability levels

After these steps are completed and the design phase begins, the Detailed SafetyAnalysis (DSA) are performed. The objectives of the DSA are to [9]:

1. Confirm the findings of the PSA (Preliminary Safety Analysis) or PHA (Prelimi-nary Hazard Analysis).

2. Identify any additional hazards that may have been introduced as a result of thedesign used.

3. Identify the possible causes of each hazard.

4. Confirm the allocation of SILs (Controllability).

5. Predict the frequency with which a particular failure may occur.

6. Identify the degree to which the system can accommodate any fault.

4.7. Development of safety critical software 25

Two techniques are commonly used for the DSA: Design Failure Mode & EffectsAnalysis and Fault Tree Analysis (FTA). Design FMEA is a bottom-up technique start-ing at a fault and ends up at its resultant effect. Each fault is classified using threedifferent parameters: severity, occurrence and detection. Each of these parameters aregiven a score between 1 and 10 (not critical - extremely critical). The severity is thesame as controllability, with the exception that a different scale is used. Occurrence ispretty hard to estimate for systematic software faults, because there is no reliable dataavailable as there is for random faults in hardware. One option is to use measured MeanTime Between Failure for software from similar systems. The detection parameter de-scribes the systems ability to detect a fault and of what degree the risk associated withthat error can be reduced by the system.

Fault Tree Analysis is a top-down approach. This is done via a hierarchy whichgradually refines the hazard through a series of sub-system down to the failures ofindividual components. It can be useful to use both techniques to get an independentcheck, and provide confidence that nothing has been missed. This technique is also usefulfor design engineers to communicate to those writing service repair documentation.

4.7.2 When is Software Ready for Production?

The vehicle manufacturers are constantly trying to improve their products to get anedge on their competition. This leads to creation of new applications in vehicles, withincreasing complexity. Most features in modern vehicles are controlled with some soft-ware based system, and in the future these systems will most certainly control moreareas and be much more complex. And as the complexity of control systems increases,so does the complexity of interactions between the systems. To determine that the finalproduct meets the demands and safety analysis, there must be some guidelines thesemanufacturers can follow.

In 1995 a joint venture of Ford, General Motors and Chrysler published the QS9000[5] document set. The documents are an interpretation of ISO9001, which is an in-ternational standard that gives requirements for an organizations Quality ManagementSystem. QS9000 extends these requirements to be more specific about how they shouldbe met. It consists of a suite of documents and two of them, Advanced Product QualityPlanning (APQP) and Production Part Approval Process (PPAP), will be discussedhere. Another document for developing safety critical software are MISRA-C:2004.These coding guidelines, published by MISRA, will also be mentioned in this section.

The Advanced Product Quality Planning document provides a structured approachfor the implementation of a Product Quality Plan, which will support the developmentof the product, to satisfy customers. It is based on a vehicle design lifecycle. It defineswhat has to be completed at the end of each phase of the development, to ensure qualityof the product. It is impossible to directly measure the quality of the code, thereforeconfidence in a product is achieved through examining how well the APQP is followed.It is very important to have a well described criteria of when a stage is complete. Thesecriteria may include requirements documents, functional specifications, design docu-ments, checklist, the final code and so on. A company can evolve the APQP process foreach new project, and strive for improvement in their products. When the quality planis complete, the PPAP process can be applied.


The PPAP document defines an approach to determine if all customers, engineering,design records and specification requirements are properly understood by the supplier[14].A product must be approved by the PPAP process in order to be complete. The processmust prove that the product can be produced with all requirements stated within APQP.

MISRA has recently (march 2006) published a document with the title: Softwarereadiness for production(SRfP). This document describes metrics that can be used fortracking the progress for software projects towards the goal of production readiness. Themethod is inspired by the ideas in Advanced Product Quality Planning and AdvancedProduct Quality Planning mentioned above. The purpose of the SRfP process is tomake these approaches more suitable within a software context.

The C programming language are widely used in embedded systems, and the reasonis features of the language like easy access to hardware, low memory requirements, andefficient run-time performance. But the language also has its drawbacks such as highlylimited run-time checking, a syntax that is prone to mistakes that are technically legaletc. In 1998 MISRA published MISRA C to support the language requirements of the1994 MISRA Guidelines. The document became widely used and in year 2004, MISRApublished a new version: Guidelines for the Use of the C Language in Critical Systems,also called MISRA-C:2004. These set of rules, or guidelines, helps developers to writesafer and more portable code.

Chapter 5

TCP/IP

5.1 Overview

The TCP/IP protocol suite has become the standard for com-puter communications in today’s networked world, mainly becauseof its simplicity and power. TCP/IP stands for: ’The Transmis-sion Control Protocol(TCP)/Internet Protocol(IP)’, which are thenames of the two most important protocols in this suite. Theprotocol suite was constructed to enable communication betweenhosts on different networks. Therefore one important aspect isthe creation of an abstraction for the communication mechanismsprovided by each type of network. TCP/IP hides the architec-ture of the physical network from the developer of the network-application. TCP/IP is modeled in layers as many other networking software. Thisarchitecture has many advantages such as ease of implementation and testing, ability toalternative layer implementations etc. Each layer communicates with those above andbelow through a well defined interface, and each layer has its own well defined tasks.This section will explain each layer in this protocol suite, starting at the top and workingits way down.

5.2 Protocol

A protocol defines the format and the order of message exchanged betweentwo or more communicating entities, as well as the actions taken on thetransmission and/or receipt of a message or other event.

[Kurose & Ross Computer Networking]

5.3 Requirements

In this section each layer is explained briefly, to get an overview of what the individuallayers contains.

27

28 Chapter 5. TCP/IP

5.3.1 Application layer

The application layer is provided by the program that uses TCP/IP for communication.Examples of applications are Telnet and the File Transfer Protocol (FTP). The interfacebetween the application and transport layers is defined by something called socket, whichwill be explained in section 5.4.

5.3.2 Transport layer

The transport layer is responsible for transferring data from one application to its remotepeer. There is support for multiple applications to use the layer simultaneously. Themost used transport protocol are Transmission Control Protocol (TCP) which providesreliable data delivery. Another commonly used protocol are User Datagram Protocol(UDP) which provides unreliable data delivery.

5.3.3 Network layer

This layer works as an abstraction of the physical network architecture below it. InternetProtocol (IP) is the most important protocol in this layer. IP does not provide reliabilityor error recovery, this is up to higher layers to handle. Other network layer protocolsare ICMP, IGMP, ARP and RARP.

5.3.4 Network interface layer

The Network interface layer works as the interface to the actual network hardware.TCP/IP does not specify any protocol here, but can use almost any network interfaceavailable, which illustrates the flexibility of the Network layer.

5.4 Socket

As the network layer provides a host-to-host delivery ser-vice, there must be possible to direct data to a certainprocess running on its host. This process-to-process ser-vice is accomplished with ports and sockets. A socket canbe seen as a door to the process. When data is to bereceived or to be sent, a socket has to be used. Asstated earlier, the socket is within the transport layer andprovides an interface to the application layer. This sec-tion will explain how this process-to-process service is accom-plished.

A socket is compound of a port and an IP-address. In programming, a port is a”logical connection place”, and is simply a 16 bit integer. On an ordinary computer,there are usually 65.535 available ports. The port number is used for identifying thecorrect application process. Port are usually divided into two types: well-known portsand ephemeral ports. The well-known range from 1 to 1023, and are used for certainserver applications. For example Telnet uses port 23 and File Transfer Protocol(FTP)uses port 21. The reason for well-known ports is to allow clients to be able to findservers without configuration information. Ephemeral port numbers are of range 1024

5.4. Socket 29

to 65.535. These port are free to use by any application as long as the combination of[transport protocol, IP address, port number] is unique. The IP-address is used for thehost-to-host delivery service.

When a segment (a packet of data) arrives, the header is examined. The headerprovides information about what protocol the packet belongs to as well as destinationport number. With this information the correct socket can be found, and thereby thecorrect process. The job of examining the header and deliver the segment to the correctsocket is called demultiplexing. The job of gathering data from a socket, encapsulatingit into a segment with header information and sent it to the network layer is calledmultiplexing.


5.5 Network Layer Protocols

5.5.1 Internet Protocol (IP)

The Internet Protocol (IP) was designed 1981 to be used in interconnected systems ofpacket-switched computer communication networks. IP provides a format for trans-mitting blocks of data (datagram) from sources to destinations. These sources anddestinations are called hosts and are identified with an IP address. A network consistsusually of a number of hosts connected to each other through a router. A host sends apacket over a link, this link can be physical like cable but also wireless. The boundarybetween the link and the host is called an interface. A host is normally connected to asingle link while a router is connected to several. A router´s job is to receive datagramfrom one link and pass it on to another link. An IP address is bound to a interfacewhich means that a router needs multiple IP addresses, one for each interface. Figure5.1 shows an example of a IP network.

Figure 5.1: An example of a network

Unlike many other host-to-host protocols, IP has no mechanisms for reliability [RFC791], flow control, sequencing etc. All such functionality is left for higher level protocolto implement. The only error detection mechanism is a checksum control for the IPheader. If the checksum procedure fails the datagram will be discarded and will notbe delivered to a higher level protocol. The main functions of the IP is addressing andpacket fragmentation.

5.5.2 Addressing

Today there are two standards of IP addressing, version 4 (IPv4) and newer version 6(IPv6). IPv6 is meant to replace the IPv4 in the future but today most of IP traffic isstill done with IPv4 addressing. In IPv4, each address is 32 bits long which means thereare 232 unique addresses. That is about 4 billions. It may seem alot but in a world with6 billion people the addresses are soon used up. The addresses are typically writtenin dotted-decimal notation like 192.168.0.3, the same address in binary notationwould be:

11000000 10101000 00000000 00000011

5.5. Network Layer Protocols 31

Class Prefix Range Networks HostsA 0 1.0.0.0 - 127.255.255.255 27 224

B 10 128.0.0.0 - 191.255.255.255 214 216

C 110 192.0.0.0 - 223.255.255.255 221 28

Table 5.1: Address classes in IPv4

Four classes of addresses were defined in the original IPv4, also an additional fifthclass was reserved for future use. The fourth class, dedicated for so called multicastaddressing, is no longer considered a formal part of IPv4 addressing. The first bitsof the IP address determines which class it belongs to, see 5.1. Address 192.168.0.3

begins with 110 in binary notation and therefore belongs to class C.This partitioning of classes with even byte length of network and host portion turned

out to be problematic. Consider an organization with 2000 hosts. A class C networkwould not sufficient, instead a class B network with support of 65634 hosts could be used.This not only led to poor utilization of the given address space but also to depletion ofclass B addresses. The solution to this problem was Classless Interdomain Rout-ing (CIDR) and was standardized 1993 by the Internet Engineering Task Force(IETF). Instead of using the 8, 16 or 24 first bits of the address for network portion,any number could be used. For the example above the organization could use the first21 bits for the network address, and the remaining 11 bits for hosts. This would lead to2048 (211) possible host addresses within the organization´s network. Another benefitwith CIDR is that it makes subnetting possible. By dividing the the 11 rightmost bitsthe organization above could create own subnetworks within its network.

In the beginning of the 1990s people realized that the 32 bit address space in IPv4would not be enough. Therefore began the Internet Engineering Task Force to developa successor to the IPv4 protocol. In the new standard IPv6, the 32 bit address space hasbeen increased to 128 bit. With such address space every grain of sand on the planetcould have a unique IP address.

5.5.3 Fragmentation

Fragmentation and defragmentation is the other main task of IPv4. It is necessarybecause not all link-layer protocols can carry packets of same size. Ethernet packets cannot carry more than 1500 bytes [8] of data, while many wide-area links has a packetlimit of 576 bytes. The maximum packet size a link can carry is called MaximumTransfer Unit (MTU). A router can have different link interfaces, and that is whyfragmentation of packets is primarily done in routers. To spare routers the burden of alsoreassembling packets the designers of IPv4 decided to let the hosts take care of that. Stillfragmentation reduces performance in a router and it is desirable to keep fragmentationto a minimum. Because of all link layer protocols supported by IPv4 should have aMTU of at least 576 bytes, fragmentation can be entirely eliminated if all IP packetsare less than 576 bytes in size. This can be controlled by setting Maximum SegmentSize (MSS) of 536 bytes (removing 20 bytes of IP header and 20 bytes of TCP header)in the TCP connection. This technique often used in TCP data transfers, for exampleHTTP packets are often 512 - 536 bytes long. In IPv6 fragmentation is completelyremoved. If a router in IPv6 receives a packet that is too large to be forwarded over theoutgoing link, the router simply discards the packet and notifies the sender through a


5.5.4 Header format

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Version| IHL |Type of Service| Total Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identification |Flags| Fragment Offset |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Time to Live | Protocol | Header Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Destination Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Options | Padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5.2: IP header format

ICMP packet. The sender can then reduce the packet size and retransmit.

5.5. Network Layer Protocols 33

5.5.5 Address Resolution Protocol (ARP)

Nodes in a LAN transmit their frames over a broadcast channel. This means thatevery node connected to the LAN will receive the frame. But most of the times a nodejust wants to communicate with one particular node in the LAN. To manage this, everynode must have a unique LAN address. This address is also known as Medium AccessControl (MAC) address or physical address. These MAC addresses are bound to aspecific adapter when it is manufactured and no adapter has the same MAC address.Most of the networks, including the Ethernet networks, have 6 byte MAC addresses. Totransmit a frame from one host to another host in a LAN, a LAN address is needed.Because every host has two sorts of addresses, one network address and one physicaladdress, there is a need to translate between them. This task is solved by the AddressResolution Protocol (ARP).

Figure 5.3: A small Local Area Network example

If a host wants send a packet to a computer on the LAN, it must know the MACaddress of that computer. Figure 5.3 shows a network of three computers connectedthrough a hub. Imagine that the computer with address 192.168.0.17 wants to senda packet to node 192.168.0.11, it will then check its ARP table.

IP Address MAC Address TTL192.168.0.11 ED-66-AB-90-75-B1 227

Table 5.2: A possible ARP table in node 192.168.0.17

Table 5.2 contains the translation of IP addresses to MAC addresses. This time theaddress 192.168.0.11 has a valid translation in the table and Ethernet packet can besent to MAC address ED-66-AB-90-75-B1. But what happens if node 192.168.0.17

wants to send a packet to 192.168.0.3. The host will check its ARP-table, but willnot find a valid translation. At this moment an ARP-request packet must be sent. Thispacket is sent to the LAN broadcast address FF-FF-FF-FF-FF-FF and contains the IPaddress of the target machine which in this case is 192.168.03. All computers in LANwill receive this ARP-Request, and each of them compare its local IP address with thetarget IP address in the ARP-packet. The node with a match will respond with anARP-Reply packet, containing the desired address mapping, back to the sender. Thequerying node (192.168.0.17) will then update its ARP-table and send the IP datagram.


5.5.6 Internet Control Message Protocol (ICMP)

The Internet Control Message Protocol (ICMP) is often considered as a part of theIP although it lies above IP, as ICMP packets are carried inside IP packets, just likeTCP and UDP packets. The purpose of ICMP is provide feedback about problems in thenetwork communication. A typical example is the Destination network unreachable

which is sent by a IP router if it was unable to find a path to the destination host.There are a numerous different types of messages that can be sent by ICMP, see 5.3.The program ping may be familiar to the reader, it sends a ICMP message with of type8 with code 0.

ICMP Type Code Description0 0 Echo reply (pong)3 0 Destination network unreachable3 1 Destination host unreachable3 2 Destination protocol unreachable3 3 Destination port unreachable3 6 Destination network unknown3 7 Destination host unknown4 0 Source quench (congesting control)8 0 Echo request (ping)9 0 Router advertisement10 0 Router discovery11 0 TTL expired12 0 IP header bad

Table 5.3: ICMP message types

5.6. Transport Layer Protocols 35

5.6 Transport Layer Protocols

5.6.1 Transmission Control Protocol (TCP)

TCP is a connection-oriented protocol which provides features like flow-control, con-gestion control and reliability. It relies on many principles including error detection,retransmissions, timers and header fields for sequence and acknowledgment numbers.A TCP connection provides full-duplex data transfer, which means that two connectedprocesses can send data to each other simultaneously. Multicasting is not possible withTCP, the connection is always point-to-point. Before data can be sent between two TCPconnections, an initial ”handshake” must be completed. How this is accomplished willbe explained later in this section. When the connection is established the two processescan start transferring data to each other. TCP guaranties that all data is delivered inorder, without gaps and without errors. TCP also makes sure that router buffers alongthe way does not get congested. Yet another feature that TCP supports is flow control,which protects against overflowing the remote hosts internal buffers. This section willexplain the most important features of this transport protocol. Figure 5.4 illustrateshow the TCP header is composed.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Port | Destination Port |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Sequence Number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Acknowledgment Number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Data | |U|A|P|R|S|F| |

| Offset| Reserved |R|C|S|S|Y|I| Window |

| | |G|K|H|T|N|N| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Checksum | Urgent Pointer |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Options | Padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| data |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5.4: TCP header format


Sequence and acknowledgment numbers

Two of the most important fields of the TCP header are the sequence- and acknowledgment-number fields. They are used to provide TCP’s reliable data transfer service. To un-derstand how this works, the meaning of these fields will first be explained. TCP viewsdata as an ordered stream of bytes. Each byte of the data-stream is assigned a se-quence number. When a segment is received, the sequence-number field displays thebyte-stream number of the first byte in the segment. The acknowledgment-number fieldindicate what sequence number is expected from the peer process. How these numbersare used to provide reliable data transfers is illustrated in figure 5.5.

Figure 5.5: Example of sequence and acknowledgment numbers

Figure 5.5 shows a simplified data transmission. The arrows represent how segmentsare sent between the two processes. The sequence-number field of the segment is labeledSeq and the acknowledgment-number field is labeled Ack. The label length indicates howmany bytes of data the segment contains.

1. Process A sends a segment with three bytes of data. The sequence number forthe first byte of this segment is zero (Seq 0). The acknowledgment field is alsozero, indicating that process A expects a segment with sequence number zero fromprocess B.

2. Process B answers with an acknowledgment field set to three, which states thatnext expected sequence number from process A is three. This also means that allbytes up to sequence number two are received.

3. Process A sends a second data segment containing seven bytes, starting at sequencenumber three. The received segment from process B did not contain any data, thusnext expected sequence number from process B is still zero (Ack 0).

4. Process B acknowledges the received segment which informs process A that nextsequence number to send is ten.


Connection establishment

TCP requires an initial connection process before data can be sent or received. Thisconnection process is often called a ”three way handshake”, because the connectionestablishment demands three segments to be passed between the two TCP sockets.During the connection-process the necessary state-variables are initiated. Both sidesneed to know what Initial Sequence Number (ISN) the remote hosts data stream startsat. Figure 5.6 illustrates what segments are sent to establish the connection.

Figure 5.6: Example of how a TCP connection is established.

In this example a client shall connect to a server. The client first sends somethingcalled a SYN segment to the server. This segment is a connection-request and is calledSYN segment because the SYN flag in the header is set to one. The sequence numberfield is set to the clients ISN, which is randomly selected by the client. If the server ac-cepts the connection request, a reply is sent called a SYN-ACK segment. This segmentcontains the servers ISN placed in the sequence number field, and has its SYN flag setto 1. It also acknowledges the clients connection-request with acknowledgment numberfield set to client isn + 1. A SYN-segment does not contain any data but counts asa segment of length 1, and this is the reason for setting the acknowledgment field toclient isn + 1. The final step of the three way handshake is for the client to acknowledgethe servers ISN.

In addition to initialization of ISN, some other options can be agreed upon. Theseoptions resides in the header-field of the same name, and can only be present in theinitial SYN segment. The most important and most used option is Maximum SegmentSize (MSS), which informs the remote TCP socket how much data a segment is allowedto contain. For an embedded system with limited memory resources the MSS option


makes it possible to limit the size of the receive-buffer used by TCP. MSS is also used toavoid fragmentation within routers along the path between sender and receiver. Whenthis handshake is complete, the two processes can start sending data to each other.

Congestion Control

To avoid network congestion TCP uses Congestion Control. When many sources aresending data at high rate, router buffers are sometimes overflowed and begins to dropsegments. Congestion Control is used to throttle the send-rate when network congestionis discovered.

Flow Control

TCP also uses a mechanism to avoid overflowing receive-buffers. A TCP socket keepstrack of how much available buffer-space the remote host has for receiving data. Thewindow field in the TCP header announces this information.


5.6.2 User Datagram Protocol (UDP)

UDP is defined in RFC 768, and is a very thin transport protocol. It does not providefeatures like flow-control, congestion control or error recovery. It is basically an applica-tion interface to IP, and just handles multiplexing/demultiplexing (explained in section5.4) and some light error checking. There is no initial handshaking procedure, as thereis with TCP, and therefore UDP is said to be connectionless.

There are however some benefits with the UDP protocol, which are explained below:

– It has very little packet overhead, only eight bytes compared to twenty bytes forTCP.

– No connection establishment delay.

– No connection state variables to keep updated.

– Finer application-level control over when data is send, and when.

Some applications do not need reliable data transfer, since they tolerate some data-loss. Many multimedia applications use UDP because they do not work well with TCP’scongestion control due to the delays it causes. Figure 5.7 illustrates the format of theUDP header. Source and destination port are used for multiplexing/demultiplexing.The length field specifies the length of the UDP segment including the header, in bytes.For UDP to calculate the checksum, a few fields in the IP header is used in addition tothe UDP segment.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Port | Destination Port |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Length | Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5.7: UDP header format


5.7 Application Layer Protocols

5.7.1 File Transfer Protocol (FTP)

The FTP (File Transfer Protocol) is a commonly used protocol of exchanging files overany network that supports the TCP/IP protocol. The protocol relies upon TCP, with aserver on one side and a client on the other. Two TCP-connections are used in a normalFTP-session:

– Control ConnectionUsed for sending control information between the server and the client, informationsuch as user identification, password and commands like change remote directory,get file, put file, etc.

– Data ConnectionUsed for file transferring and file lists of the remote directory.

A user starts an FTP session by initiating a TCP connection to port 21 (standardport) at a server. The client then sends user identification and password and the FTPcontrol connection is established. When a server receives a file transfer request over thecontrol connection, it initiates a TCP data connection to the client side. The file will betransferred, either from server to client or from client to server, over the data connection.The data connection will be closed as soon the file transmission i completed. Thus, thecontrol connection remains open throughout the duration of the FTP session while thedata connection is created and closed for each file transfer. Commands and replies, thatare sent over the control connection, are text coded in seven-bit ASCII-format. Eachcommand consists of four uppercase ASCI characters, some with optional arguments.Some common commands are given below:

– USER username Sends the user identification to server.

– PASS password Sends the user password to server.

– PORT address and port Informs the server to where it should initiate next dataconnection.

– LIST Request the file list of current remote directory.

– RETR filename Initiate a file transfer from server to client.

– STOR filename Initiate a file transfer from client to server.

Each command issued at client side is followed by a reply from the server. The replymessages consists of a three-digit number followed by an optional message. More detailsabout the File Transfer Protocol can be found in RFC 959.

Chapter 6

Hardware

6.1 Phytec phyCore-XC167

The hardware used in this project was a rapid development kit from Phytec. It consistedof a Single Board Computer (SBC) phyCore-XC167 together with a development board.An SBC can be seen as a small computer and the size of phyCore-XC167 is just 60 x53 mm. The most central part of phyCore-XC167 is the microcontroller XC167CI fromInfenion but it also has many other features like:

– 16-bit, multiplexed bus mode.

– 256 KB - 2 MB external Flash on-board.

– 256 KB - 1 MB external RAM on-board.

– 512 KB fast SRAM on-board.

– 20-40 MHz clock frequency.

– 16 MB address space.

– 2 CAN interfaces.

– RS232 transceiver for two serial interfaces.

– CS8900A 10Base-T Ethernet Controller.

These and other features are presented in [16].

As seen in 6.1 the Ethernet controller is connected through a common bus with theexternal Flash, RAM and SRAM. The access to these components is easy because theyare mapped into the microcontrollers address space. A memory access to the externalmemory areas (see Figure 6.3) of the microcontroller will therefore use the external busand access a device there.

41

42 Chapter 6. Hardware

Figure 6.1: Block diagram of phyCore-XC167

The use of interrupts is preferable when constructing a driver for the Ethernet con-troller. It is clearly a better and more elegant way to let the Ethernet controller interruptthe host CPU than have some kind of polling solution. To make it possible for the Eth-ernet controller to interrupt a jumper needs to be closed. This jumper connects theIRQ output from the Ethernet controller to the pin P2.13 of the microcontroller. Thisjumper is marked in Figure 6.2 and is the only modification of the hardware that mustbe done.

Figure 6.2: Modification of phyCore-XC167

6.2. Microcontroller Infenion XC167CI 43

6.2 Microcontroller Infenion XC167CI

XC167CI is a full featured single-chip microcontroller. The list below presents a shortsummary of XC167CI’s features.

– High Performance 16-bit CPU with 5-Stage Pipeline.

– 40 MHz CPU Clock.

– 16 Mbytes Total Linear Address Space for Code and Data.

– 2 Kbytes On-Chip Dual-Port RAM (DPRAM).

– 4 Kbytes On-Chip Data SRAM (DSRAM).

– 2 Kbytes On-Chip Program/Data SRAM (PSRAM).

– 128 Kbytes On-Chip Program Memory (Flash Memory).

– Up to 12 Mbytes External Address Space for Code and Data.

– On-Chip Bootstrap Loader.

The memory space of the XC167 is configured in a Von Neumann architecture, whichmeans that all internal and external resources, such as code memory, data memory, reg-isters, and I/O ports are organized within the same linear address space. This commonmemory space includes 16 Mbytes and is arranged as 256 segments of 64 Kbytes each,where each segment consists of four data pages of 16 Kbytes each. How the memoryspace is organized is presented in figure 6.3.


Figure 6.3: XC167CI Memory map

The microcontroller has several on-chip memory modules. These are Dual-Port RAM(DPRAM), Data SRAM (DSRAM), Program/Data SRAM (PSRAM) and ProgramMemory (Flash Memory). The PSRAM is provided to store user code or data andis accessed via the Program Management Unit (PMU), as figure 6.4 illustrates. PMUis responsible for all code fetching and therefore also accesses the Flash Memory whichstores code or constant data. The DSRAM are provided as a storage for general userdata and is accessed via the Data Management Unit (DMU). DPRAM is provided as astorage for user defined variables, the system stack, and general purpose register banks.If more memory is required than the memory provided on the chip, up to 12 Mbytes ofexternal RAM and/or ROM can be connected to the microcontroller.

6.3. Ethernet Controller Cirrus Logic CS8900A 45

Figure 6.4: Overview of XC167CI’s on-chip components

6.3 Ethernet Controller Cirrus Logic CS8900A

Phytec phyCore-XC167 is equipped with the Ethernet controller CS8900A from Cirruslogic. The controller has a direct ISA-bus interface, an 802.3 MAC engine, 4 KB inte-grated RAM and a serial EEPROM interface. Its architecture is based on an efficientmethod of accessing internal registers and buffer memory known as Packet Page. The4 KB RAM, known as the Packet Page memory, is used for internal registers and tem-porary storage of Ethernet frames. Table 6.1 shows the organization of the accessableportion of Packet Page memory.

Packet Page Address Contents0000h - 0045h Bus Interface Registers0100h - 013Fh Status and Control Registers0140h - 014Fh Initiate Transmit Registers0150h - 015Dh Address Filter Registers0400h Receive Frame Location0A00h Transmit Frame Location

Table 6.1: Memory organization in CS8900A

The access to this memory is either done in Direct Memory Access (DMA) or throughI/O space operations. Access via DMA is slightly faster but the manufacturer recom-


mends to use I/O mode in order to get a cleaner driver design. In I/O mode the PacketPage memory is accessed through eight 16-bit I/O ports that are mapped into sixteencontiguous I/O locations in the host system’s I/O space. The default value of the I/Obase address for CS8900A is set to 300h (300h is typically assigned to LAN peripherals).Table 6.2 shows the mapping.

Offset Type Description0000h Read/Write Receive/Transmit Data0002h Read/Write Receive/Transmit Data0004h Read/Write TxCMD (Transmit Command)0006h Read/Write TxLength (Transmit Length)0008h Read/Write Interrupt Status Queue000Ah Read/Write Packet Page Pointer000Ch Read/Write Packet Page Data000Eh Read/Write packet Page Data

Table 6.2: CS8900A I/O port mapping

To read a register in CS8900A, the Page Page address of the register must first bewritten to Packet page Pointer port (000Ah). The content of the register can then beread from the Packet Page data port (000Ch). The interested reader can find moredetails about CS8900A and how it is accessed in the CS8900A product data sheet [1].

Chapter 7

System description

7.1 Overview

In this section an overview of the implementation will be presented. The system is builtin a layered structure, also called a stack, with a well defined interface between eachlayer. This way all protocol specific tasks are isolated in each layer. It also makes iteasy to add additional functions or to replace a layer. The layered structure and itsdifferent layers are illustrated in Figure 7.1. The description will be done in a top-downapproach and start with applications above the stack. First the Telnet- and FTP-server implementation will be described, then each layer down to the HAL. Conceptsand terms in this section have been explained, or at least brought up, in the previousTCP/IP chapter 5.

Figure 7.1: The TCP/IP-stack is built in a layered structure

7.2 Telnet Server

The Telnet-server implemented allows remote login from a Telnet-Client to a VCS-node.There is no support for handling multiple clients at the same time. To understandhow the Telnet-server works, the function of the Monitor-module in VCS Core must

47

48 Chapter 7. System description

be explained shortly. The Monitor-module inside VCS Core handles all standard in-put/output. It also parses commands directly from a user via command line and thenexecutes them. In fact, the monitor also acts as a shell where it can execute built incommands. The monitor can use different interfaces to the user depending what is suit-able. If the VCS-Node is simulated on a Windows machine it uses the standard I/O callsfrom C (printf, putchar etc.) When VCS is running on a microcontroller, a Serial-or a CAN-interface provides the standard I/O for the user. The Telnet-server providesan additional way of interacting with the VCS-Node. The whole process of managinginput data and forward outgoing data to the correct interface is pretty simple. At firstthere is a Red Thread periodically checking for new input data of each interface. If thereis data at some interface, a Blue Thread will be signaled to handle the data. The BlueThread will check which interface that has new input data and chooses that interface tobe active. Then the Blue thread will process each incoming character one-by-one andpresent the result to the active interface. This is roughly how the Monitor inside VCSCore works.

7.2.1 Negotiation

Directly after the TCP-Connection between the Telnet-client and the Telnet-server hasbeen established, a negotiation must take place. In the negotiation, different settingsfor the Telnet-session is determined. Since the Monitor inside VCS Core had supportfor VT100 it became straight forward to let the Telnet-server offer the VT100 standardas virtual terminal. The Telnet-server is also responsible for echoing characters fromthe user. In other words, the input character from the client will first be sent to serverand then back to client. The alternative would be to have local echo at the client, andfirst when the user hits Enter the whole line would be sent (linemode). By letting theserver echo it is possible to respond to single keystrokes from the user, like presentingcommand history when pressing Up Arrow.

The telnet server starts the negotiation with:

– DO TERMINAL TYPE (Wants the client to send its preferable virtual terminal)

– WILL SUPPRESS GO AHEAD

– WILL ECHO (The server will handle the echo)

– DONT ECHO (The server do not want local echo at the client)

After the negotiation phase is finished the telnet session can start. All outgoingcharacters from the Monitor are buffered until the buffer is full or when the flush routineis called. By buffering outgoing characters it will be more efficient and faster to sendwhole lines, instead of always sending one character at a time over the network. Whenechoing characters from the client, a consecutive flush call must be done to force theserver to send the character.

7.2.2 Interface

The Telnet-server provides an interface for the Monitor-module in VCS Core to be ableto work as an I/O-interface.

void Telnet_Init( void )

7.2. Telnet Server 49

Initiates the Telnet Server. Must be called before using it.

u16 Telnet_CharsInReceiveBuffer( void )

Returns the number of characters in the receive buffer that have not been read.

TEXT Telnet_ReadChar( void )

Returns next character from buffer.

u16 Telnet_SendChar( TEXT character )

The character will be buffered and not sent over the connection until the buffer is fullor until the Telnet Flush routine is called.

u16 Telnet_Flush( void )

Forces the Telnet-server to send all data in the send buffer.


7.3 FTP Server

The implemented FTP-server will, as the Telnet-server, not allow multiple clients to beconnected at the same time. In difference to Telnet, FTP uses two different connections.One control connection and one data connection. The control connection is where theFTP-commands are sent, and the data connection is opened for example when a filetransfer is initiated or when a directory list command has been received.

7.3.1 Supported Commands

Only a subset of the FTP-commands are supported. The supported commands are:

– USER - Send user name.

– PASS - Send password.

– TYPE - Transfer type.

– PORT - Open data port.

– PWD - Print working directory.

– CWD - Change Working directory.

– CDUP - CWD to the parent of the current directory.

– LIST - List remote files.

– RETR - Retrieve a remote file.

– QUIT - Terminate connection.

7.4. Socket 51

7.4 Socket

The implemented VCS socket-API supports the transport-protocols TCP (Transmission Control Protocol) and UDP (UserDatagram Protocol). When an application shall use UDP or TCPto send data to a remote host, a socket is used. The figure to theright shows how the socket-layer is at the very top of the TCP/IPstack and can be seen as an interface between the applicationand the TCP/IP-stack. A socket can be compared to a pipe infunctional aspects where, for example, the local application putdata into one end of the pipe and the remote application extractdata on the other end. The most important responsibilities forthe socket-layer are multiplexing/demultiplexing and translatinggeneric socket-layer functions to specific protocol functions. Mul-tiplexing and demultiplexing provides a process-to-process service.This means that the socket layer is responsible for directing an incoming segment to thecorrect application, as well as providing header information for outgoing segments. Asocket has a data-structure called str socket which holds information needed to man-age a connection. This structure keeps track of several state variables needed by itsunderlying transport-protocol. Most variables only concern TCP, because it is far morecomplex than UDP and therefore needs more connection-status information. Some ofthe most important components of the str socket structure are explained below.

– flags

The flags holds information about a connection, such as if the connection is cur-rently sending data or a timeout occurred etc.

– prot state

This is used by the TCP protocol to manage the TCP state machine, which isexplained further in section 7.5.

– inet opt

The inet opt structure holds local and remote address information (IP addressand port number).

– state

This holds the sockets connection-state (connected, connecting etc.)

– ops

A structure with function pointers used to map socket layer functions to specificprotocol functions.

When a socket is created the socket-structure is initialized to support the protocolthat shall be used. The most important member of the socket-structure is the ops

structure, which maps the socket API function-calls to protocol specific functions. Theops structure also maps protocol specific initialization and destroy functions, which areneeded to initiate and destroy the protocols control-block.

The socket API is implemented to resemble C-sockets. There are however some dif-ferences in how some functions behave. The most important difference is that vcs socketsonly support blocking send- and receive-functions. Some API functionality is only usedfor TCP sockets. UDP is said to be connectionless which means that an UDP socketdoes not have to establish a connection before sending or receiving data. API functions


vcs listen, vcs accept and vcs connect are therefore of no use for UDP sockets, andwill always return -1. The VCS socket API is listed below. More information aboutusing the socket API can be found in Appendix B.

– vcs socket

Creates a socket of type SOCK STREAM(TCP) or SOCK DGRAM(UDP).

– vcs bind

Binds the socket to a local port.

– vcs listen

Informs the socket to listen for connection requests.

– vcs accept

Accepts incoming connection-requests from remote sockets.

– vcs connect

Connects to a remote socket.

– vcs send

Sends data on a connected socket.

– vcs sendto

Sends data to a specified socket.

– vcs recv

Receives data.

– vcs recvfrom

Receives data from a specified socket.

– vcs close

Closes a connection.

7.5. TCP 53

7.5 TCP

The Transmission Control Protocol (TCP) provides reliable datatransfer. It relies on many principles including error detec-tion, retransmissions, timers and header fields for sequence- andacknowledgment-numbers. TCP is connection-oriented whichmeans that before two processes can send data to each other, aninitial handshake between them must be performed. This meansthat the two processes must exchange messages to setup and ini-tialize several TCP state variables to handle the connection. Thissection will explain how these state variables are updated, howbuffers are handled and other areas regarding the TCP implemen-tation of this project. The principle behind TCP is more thor-oughly explained in section 5.6.1, this section is suited for readersfamiliar with TCP.

7.5.1 Data structures

A TCP connection must keep a lot of state variables updated. Some TCP control vari-ables are kept in its corresponding socket-structure. The rest of the connection statusvariables are stored in a TCP Control Block. Because dynamic memory was not allowedin this project, the control-block structures must be allocated at compile time. If thereis N available sockets in the TCP/IP stack, there must be N TCP Control Blocks al-located. Even if some sockets are meant to use UDP as transport-protocol, it must bepossible to use all sockets as TCP sockets.

There is also another structure used by TCP that stores information about the lastreceived packet. This information is parsed and calculated from an incoming segment’sheader. There is only one instance of this structure because the TCP/IP stack onlyhandles one segment at the time.

7.5.2 Buffers

The TCP layer has two buffers allocated which are used when constructing outgoingpackets. One is used for storing control-packets, and the other for storing packets con-taining data. To save memory these buffers are available for all TCP sockets. Whenseveral TCP connections are sending and receiving data at the same time, they willneed to use these buffers simultaneously. Therefore the buffers are locked with a spin-lock to prevent disturbances. It would be possible using only one of the buffers tostore both data and control packets but the size of the control buffer is only 56 bytesand a lot of performance can be gained if many TCP sockets are active at the same time.

Space is reserved at the beginning of a buffer when constructing a packet. This spaceis for storing the IP- and Ethernet-header, which is filled in by the IP- and Queue-layerlater on. Figure 7.2 shows the structure of the data-packet buffer. The shaded fieldindicates where header field and data are copied into the buffer. The data field is oflength Maximum Segment Size (MSS) meaning the maximum number of bytes of dataa TCP packet can contain. This MSS value can be configured at compile time and


regulates how big buffer TCP shall use for data packets. If Maximum segment size issmall the performance will suffer because it requires sending more packets, but it is abalance between memory demands and performance.

Figure 7.2: Data buffer organization for a TCP packet with N bytes of data

7.5.3 State machine

A TCP connection can be seen as a state machine which progresses through a series ofstates during its lifetime. The states are:

– LISTEN

Represents socket created to accept connection requests.

– SYN-SENT

Represents waiting for a matching connection request after having sent a connec-tion request.

– SYN-RECEIVED

Represents waiting for a confirming connection request acknowledgment after hav-ing both received and sent a connection request.

– ESTABLISHED

Represents an open connection, data received can be delivered to the user. Thenormal state for the data transfer phase of the connection.

– FIN-WAIT-1

Represents waiting for a connection termination request from the remote TCP, oran acknowledgment of the connection termination request previously sent.

– FIN-WAIT-2

Represents waiting for a connection termination request from the remote TCP.

– CLOSE-WAIT

Represents waiting for a connection termination request from the local application.

– CLOSING

Represents waiting for a connection termination request acknowledgment from theremote TCP.

– LAST-ACK

Represents waiting for an acknowledgment of the connection termination requestpreviously sent to the remote TCP.

– TIME-WAIT

Represents waiting for enough time to pass to be sure the remote TCP receivedthe acknowledgment of its connection termination request.

– CLOSED

Represents no connection state at all.

7.5. TCP 55

A connection progresses from one state to another in response to events. The eventsare the user calls, the incoming segments and timeouts. The states and what eventscauses the connection to progress is defined in RFC 793.

7.5.4 Establishing a connection

If an application shall send or receive data on a TCP socket, the socket must first havean established connection with the remote socket. This can be accomplished in twoways, either connect to a listening socket or accept a connection-request. If the localsocket shall connect to a listening socket, a local port must be associated with the cre-ated socket. If the socket is not bound to a port by its application, it will automaticallybe bound to a randomly selected port before the handshaking procedure begins. Thisbehavior is useful when implementing socket applications.

The behavior when a socket shall accept a connection can be a bit confusing. Tosave memory and keep the TCP implementation simple there is no queue for incom-ing connection-requests. This results in rejection of all incoming connection-requestseven though the socket is ”listening” for connections. Not until the application callsvcs accept a connection-request can be handled. The reason for having a listeningstate at all is mainly for easing further development and to follow the standard.

7.5.5 Sending data

There are three threads involved when sending data, the application-thread (who callsthe send function), the receive-thread and the timer-thread. The application-threaddivides the data into packets, adds the TCP header-field and sends the data. Thereceive-thread handles acknowledgments for sent packets and the timer-thread handlesretransmissions of lost segments. The application-thread is used during the whole sendprocess which causes the send function to block until all data is sent. Figure 7.3 illus-trates how the send algorithm, which is performed by the application-thread, is working.


Figure 7.3: Overview of the send-algorithm

7.5. TCP 57

The application-thread and the receive-thread needs to alter the same state-variablesand therefore needs to be synchronized. When the receive-thread is processing an ac-knowledgment it can not change involved state-variables directly, because it may disturbthe application-thread. These changes can only be performed in a certain stage of thesend-algorithm. As a solution the receive-thread saves these changes in temporal vari-ables and sets a flag that indicates which variable has been changed. When the variablesare safe to change, the application-thread checks for these changes and performs them.

One other issue that complicates sending data is congestion control. The TCP socketcan only send a certain amount of unacknowledged data on the link before waiting to getthe data acknowledged. How much unacknowledged data the socket is allowed to sendis decided by the congestion control algorithm. When the limit of unacknowledged datais sent, the application thread has to wait before the send procedure con continue. If apacket is acknowledged, the receive-thread signals the application-thread who continuesto send data. If a timeout on a packet occur, the timer-thread signals the application-thread so the packet can be sent again.

The list below will explain each step in figure 7.3 for a better understanding of thesend-algorithm. Decision x is marked Dx in figure 7.3.

– Decision 1

For the socket to be allowed to send data it has to have an established connectionwith a remote socket. One other demand is that the socket is not already sendingdata via another application-thread.

– Decision 2

As stated earlier the receive-thread and the application-thread needs to be syn-chronized. At this stage of the algorithm the application-thread checks to see ifthere has been any changes of the state variables. Possible changes are receivedacknowledgments for sent packets, triple duplicate acknowledgments for the samepacket or a timeout.

– Decision 3

At this step the algorithm checks if all data has been sent.

– Decision 4

Even if all data is sent, the send procedure is not finished. The last sent segmentneeds to be acknowledged before the function terminates.

– Decision 5

Because of TCP’s congestion control, the amount of sent unacknowledged datamust be checked before sending a packet. If there is too much data out, theapplication-thread must sleep until there is a timeout or a packet is acknowledged.

– Decision 6

This last decision checks if the peer socket has memory reserved for receivingmore data. If the peer socket does not accept any data the algorithm sleeps for 5seconds. Then one byte of data is sent. In the acknowledgment for this one bytedata-packet the send-algorithm can see if the send-window increased. If the peersocket has a window larger than zero, a packet is send.

Blocking send functions combined with delayed acknowledgments can cause sendperformance to suffer in certain situations. Delayed acknowledgments are used to de-crease network-traffic, and most TCP implementations supports this technique. As data


is received by TCP on a particular connection, it sends an acknowledgment back onlyif one of the following conditions is true:

– No acknowledgment was sent for the previous segment received.

– A segment is received, but no other segment arrives before delayed-acknowledgment-timer expires.

The problem arises when small amounts of data shall be sent. If the entire send-procedure only requires to send one segment, the send-function will block until that seg-ment is acknowledged. The acknowledgment will not arrive until the delayed-acknowledgment-timer expires, which is typically 200 ms. This implementation solves the problem bysplitting the segment in half, and thereby receiving an acknowledgment on the secondsegment without any delay. This feature is active if the SPLIT-flag is present whencalling vcs send.

7.5. TCP 59

7.5.6 Receiving data

The receive procedure is mainly performed by the receive-thread and the timer-thread.The application-thread only performs a few tasks before sleeping until receive completes.Figure 7.4 illustrated how the application-thread works.

Figure 7.4: Receive procedure for the Application-Thread

In the first decision, D1 in figure 7.4, a few requirements on the socket is checkedbefore state variables can be initiated. First a socket has to have an established connec-tion. Second the socket can not be currently receiving data.

At decision 2 the advertised window is checked. This value shall indicate how muchavailable buffer space for incoming segments there are. Most implementations has atemporal buffer to store incoming segments. When receive is called the received datais copied from this temporal buffer into the buffer allocated by the application. To savememory there is no temporal buffer in this implementation thus the receive-window is setto zero. Received segments are copied directly to the buffer provided by the application.Buffer-space is therefore only available when vcs recv is called. To avoid delays, an ac-


knowledgment is sent when there is buffer-space to advertise the new window size. Whenthese tasks are done the application-thread goes to sleep, waiting for receive to complete.

Figure 7.5 illustrates how the receive-thread is processing a data-packet when it ispassed to the TCP-layer from the IP-layer. This flow chart is a bit simplified to geta better overview. But if a data packet arrives without any additional flags and thesocket is not currently sending data, this figure basically illustrates how the receive-thread works. Decision x is marked Dx in figure 7.5.

Figure 7.5: Receive procedure for the Receive-Thread

7.5. TCP 61

– Decision 1

The correct socket is found via destination- and source-address, where addressinvolves both ip-address and port.

– Decision 2

The checksum is calculated to detect errors. The checksum calculation requiresa pseudo-header-field to verify a packet correctly. If the checksum is correct thestructure containing information about the last received segment is built via in-formation from the segments header.

– Decision 3

A packet must be within the receive window with an expected sequence numberto be accepted. If the packet pass this test the data is copied into the application-buffer and state variables are updated accordingly. A packet received out-of-orderis discarded.

– Decision 4

The receive procedure can be completed in two ways, if errors and presence ofthe reset-flag are excluded. The first is simply that all data, required by theapplication, is received. The other way is that the push flag is set. This alsoterminates the receive procedure and all data received up to this point is deliveredto the application. In both cases the application-thread is signaled which causesthe receive function to terminate.

– Decision 5

This implementation supports delayed acknowledgments, but it can be disabled atcompile-time. If delayed ack is inactive, an acknowledgment is sent immediately.

– Decision 6

To save network traffic data-packets are not acknowledged directly. If an ac-knowledgment is delayed there are three scenarios to send it later. The first is ifdelayed-acknowledgment-timer expires which causes the timer-thread to send anacknowledgment. Second is if the socket is sending data at the same time andpiggybacks the acknowledgment on a data-packet. The last scenario is that adata-packet arrives when an acknowledgment already is delayed, which causes thealgorithm to send a segment that acknowledges both received packets.

7.5.7 Timers

For TCP to recover from lost segments, a retransmit timer is used. If a sent segmentis not acknowledged within a certain amount of time, the lost segment is sent again.Those packets sent after the lost segment, are re-sent as well. This behavior is calledGo-Back-N, where N stands for amount of unacknowledged data the send-algorithm isallowed to send. An alternative would be trying to fill the gap by just sending the lostsegment, but Go-Back-N was chosen to keep the send algorithm as simple and straightforward as possible. The length of the timeout interval is calculated according to thealgorithm described in [8].

7.5.8 Congestion control

To avoid overflowing of router-buffers, the send-algorithm needs a mechanism to regulateits send-rate. The congestion-algorithm calculates a congestion window which controls


how much unacknowledged data the send-algorithm is allowed to send, that is:

LastByteSent− LastByteAcked ≤ Congestion window

A small state-machine, with three states, is used to manage the algorithm. The statesare:

– SLOWSTART INIT

– CONGESTION AVOID

– SLOWSTART

When a TCP connection begins in SLOWSTART INIT state, the value of congestionwindow is initialized one MSS (Maximum Segment Size), resulting in an initial sendingrate of roughly MSS/RTT (Round Trip Time). Because the available bandwidth prob-ably is much larger than MSS/RTT it would not be a good idea to increase the sendingrate linearly. Instead the rate is increased exponentially until a packet loss occur. TheTCP connection discovers a packet loss in one of two ways. Either a sent segment gets atimeout or triple duplicate acknowledgments are received. A duplicate acknowledgmentis an ack that reacknowledges a segment for which the sender already received an earlieracknowledgment. When a segment loss occur, the congestion window is cut in half.

After this initial phase the state changes to CONGESTION AVOID. In this statethe congestion window increases by one MSS every time a segment is acknowledged,that is every RTT. If triple duplicate acknowledgments are received, the congestion win-dow is cut in half and the new value of congestion window is saved in a variable calledthreshold. This variable determines the window size at which slow start will end, andcongestion avoidance will begin. The variable threshold is initially set to a large valueso that it has no initial effect. When the threshold is saved the algorithm stays in thesame state.

If a timeout occur the following happens: threshold gets the value of congestion window2

,the size of the congestion window is set to one MSS and the state changes to SLOW-START. In state SLOWSTART, the size of the congestion window increases exponen-tially. If either a timeout occur or triple duplicate acknowledgments is received, the sizeof the congestion window is set to one MSS. But if the congestion window size reachesthe threshold, the state changes to CONGESTION AVOIDANCE.

7.6. UDP 63

7.6 UDP

UDP does just about as little as a transport layer can do. Thereis no flow- or congestion-control thus as soon as an applicationpasses data to UDP, the data will be packaged into a segment andimmediately passed to the IP-layer. There is no initial handshake,as with TCP, thus UDP does not introduce any delay to establisha connection. UDP is not a reliable transport-protocol so thereis no guarantee for sent data to be delivered. There is very littleoverhead, only 8 byte header compared to 20 bytes for TCP. Oneproblem arise when data shall be received. There is no way, asit is with TCP, to control how large segments the remote UDPsocket sends. This means that the queue-layer must have buffer-space available for receiving potentially large segments, which isnot preferred in an embedded system like this.


7.7 IP layer

The IP layer is central to the TCP/IP stack. Although it is centralit can be designed to be simplistic. First of all the IP layer wasdesigned to only support IPv4. This because IPv4 is undoubtedlyused more then IPv6 today and will be in near future. And ifsupport for IPv6 is needed further on, it can easily be added intothe TCP/IP stack because of the layered design. Fragmentationis described as one of the most important task for IP layer, butwith support of fragmentation some problems immediately arise.Fragmented packets needs to be stored somewhere, and in an em-bedded system with limited memory resources it is not desirableto allocate big memory areas. Other problems with fragmentationis to determine how long a host should keep a fragmented packetwhile waiting to receive the complete packet, if for example somepacket fragments were lost in the network. Fragmentation is an issue and it is no coinci-dence that fragmentation was removed in IPv6. By setting the Maximum Segment Size(MSS) in a TCP connection to less or equal than 536 bytes, the need for fragmentationcan be avoided. And small packets also suits the memory consumption for an embeddedsystem better.

No CIDR network addresses are supported in the implementation, only class C ad-dresses of IPv4 standard are allowed. This means that the first 24 bit of the addressidentifies the network and the remaining 8 bit identifies the host. Neither is there aforward table that allows packets to be sent to another network. The reason for whythese features not are included in the solutions is that the systems running the stackwill not be a part of a bigger network, and definitely not the Internet. The network willprobably be limited to two hosts connected through a cross wired network cable or acouple of hosts connected through hub/switch.

The only types of ICMP-messages that are implemented are ECHO-Request andECHO-Reply. In other words, it is possible to ping a running VCS-node and also possiblefor a VCS-node to ping another machine.

7.7.1 Upper level interface

void Send_IP_Packet( u16_ptr ipAddr[], u08 protocol, u16_ptr packet, u16 packet_size)

Adding IP-Header parameters in packet and calculates checksum before sending thepacket further down in the stack.

void Send_ICMP_Packet( u16_ptr ipAddr[], u08 type)

Sends an ICMP-packet to ipAddr if type type.

7.7.2 Lower level interface

void Process_IP_Packet( u16_ptr packet)

Processes an incoming IP-packet, will either send it further to TCP, UDP, ICMP ordrop the packet.

7.8. QueueLayer 65

7.8 QueueLayer

Below the IP layer and above the Hardware Abstraction Layer aQueueLayer has been inserted. The main task for the QueueLayeris to buffer incoming and outgoing packet. The QueueLayer alsocontains an ARP module, which is responsible for address transla-tions between IP addresses and physical (MAC) addresses. Thereare three queues that are central to this layer:

– ReceiveQueue

Incoming packets from the driver is placed here.

– SendQueue

Outgoing packets from the IP layer is placed here.

– WaitQueue

Packets, destined for a destination with no valid addresstranslation, are placed here.

Because no dynamic memory allocation is allowed in VCS Core each packet queueis constructed of a 16 bits array and allocated statically at compile time. To make thepacket queues memory efficient and to support arbitrary1 number of packets, all packetsand its sizes are stored in one single array. This way the packet queue can hold onebig or many small packets in an efficient way. The size of a packet is stored as a 16bit integer, then the packet follows, see Figure 7.6. Different threads have access to thepacket queues, therefore there is a need for synchronization to prevent race conditions.This is primly done by using the mutexes that Rubus provides. Mutexes solves most ofthe synchronization problems, but not all. The green interrupt thread, which is invokedwhen the Ethernet controller has received a packet, can not use mutexes. Thereforesynchronization is sometimes also achieved by turning off all interrupts for a short timeperiod.

Figure 7.6: Packet queues buffer organization

The QueueLayer contains two blue threads for managing the queues. The purposeof the threads is to take over responsibility from the Ethernet interrupt thread and fromapplication threads. The two threads that belong to the QueueLayer are:

– SendThread

This thread is responsible for sending packets when they arrive to the sendQueue.

– ReceiveThread

This thread handles incoming packets which are placed in the ReceiveQueue.

1As long as there is free space in the array


When an outgoing packet arrives to the QueueLayer, the packet is either placed in theWaitQueue or in the SendQueue depending on if the address translation table contains avalid translation. If there is no valid translation for the IP-address, the packet is placedin the WaitQueue until there is a valid translation. When there is a valid translationthe packet is placed in the SendQueue and a signal is sent to the SendThread. TheSendThread will then pass the packet to the HAL. Figure 7.7 illustrates the sendingprocess.

Figure 7.7: Application-Thread

When an interrupt occurs, the Ethernet ISR is invoked and copies the packet fromthe Ethernet controller directly into the rear of the ReceiveQueue. Then it signalsthe ReceiveThread inside the QueueLayer. The ReceiveThread will then process thepacket when time is given. In this approach the interrupt thread will have a shortand specific task, which is desirable. How the ReceiveThread functions is described inFigure 7.8.

7.8. QueueLayer 67

Figure 7.8: Work process for the Receive-Thread

7.8.1 ARP-module

The ARP-module inside the QueueLayer is responsible for translating the IP-address to aphysical (MAC) Ethernet address. These translations are stored in the translation table.The table contains the IP-address, the physical address and a Time To Live (TTL).Each translation is valid about five minutes, than it must be renewed. This mechanismis desirable to have because the network may change. If there is no valid translationfor a wanted IP-address, an ARP-request will be broadcasted over the network. Theimplementation follows the standard described in RFC 828 but is restricted to onlysupport translation between IPv4 address and 6 bytes Ethernet addresses. The standardARP-protocol is designed to support translation between different network addresses and


hardware addresses, not only the Internet Protocol and Ethernet.

7.9. HAL 69

7.9 HAL

The last layer before the hardware is the Ethernet HAL. The HALlayer itself can be divided into two parts. One part consists of rou-tines controlling the Ethernet Controller, in this case CS8900Afrom Cirrus Logic. The other part, which is described in Ap-pendix C, a provides clean and simple access methods for higherlayers. Therefore if another Ethernet controller would be used inthe future it is only necessary to replace the HAL layer with a newHAL that implements the same access methods.


Chapter 8

Conclusions

8.1 Limitations

Transport protocol UDP is implemented, but has never been tested.The FTP-server does not support many commands, and it needs to be tested with

other clients than WRQ Reflection FTP and the inbuilt text based FTP-client in Win-dows XP. The implemented FTP-server works fine with previous mentioned clients butthere are some problems with other clients. Both the Telnet- and FTP-server are limitedto handle one client at a time.

The IP-layer in the system is very simple, functions as fragmentation and routingare completely removed. Support for fragmented packets will probably not be necessarybut maybe some kind of routing mechanism would be nice to have in the future. Thefunctions of the ICMP-module is also limited to only support ECHO commands.

In the Ethernet HAL there is no standardized way to receive a packet. The interruptthread now copies the packet into the ReceiveQueue. A better way would be to makeit possible to register a receive handler function in the HAL that the Ethernet ISR willcall when a packet arrives.

8.2 Future work

The TCP/IP stack itself is pretty solid but of course some improvements can be done.It is preferable to reduce as much data copying as possible. The HAL contains nobuffer so the packet is copied directly into the ReceiveQueue in the QueueLayer fromthe Ethernet controller. When a packet is received, the interrupt routine requests forbuffer space from the QueueLayer. A similar approach is considerable in the other direc-tion. Instead of having a transmit buffer in the TCP-layer, the TCP-layer could requestmemory space from the QueueLayer. With such approach the packets do not have tobe copied from the TCP-buffer into the SendQueue and some performance will be gained.

On top of the TCP/IP-stack numerous applications could be considered to imple-ment. (Dynamic Host Configuration Protocol) DHCP that allows IP-addresses to behanded out by a server instead of having them statically defined. A simple web-server,that allows user to surf in and see system status and maybe download log-files, is alsoa thought.

71

72 Chapter 8. Conclusions

Chapter 9

Acknowledgments

First of all, we would like to thank BAE Systems Hagglunds for a great time in Ornskoldsvikand for giving us the opportunity to do this project. The work has been very stimulatingand has given us a lot of enjoyment as well as allowing us to gain a lot of knowledge.

A special thanks to our supervisor at Hagglunds, Jimmy Westerlund, for his supportwhile doing the project. Lastly, we also want to thank Jan-Erik Mostrom at UmeaUniversity for his advice and comments when writing this report.

Thank you all!

73

74 Chapter 9. Acknowledgments

References

[1] Cirrus. http://www.cirrus.com/en/products/pro/detail/P46.html.

[2] Java SE Real-Time. http://java.sun.com/javase/technologies/realtime.

jsp.

[3] The Motor Industry Software Reliability Association. http://www.misra.org.uk/.

[4] Par Jdly Ariane. A.fian 501 Inquiry Board report.

[5] Ford Motor Company Chrysler Corporation and General Motors Corporation. QS9000: Quality System Requirements. 1995.

[6] Bruce Powel Douglass. Safety-Critical Systems Design. 1998.

[7] Charles Antony Richard Hoare. The emperor’s old clothes. Commun. ACM,24(2):75–83, 1981.

[8] Keith W. Ross James F. Kurose. Computer Networking: A Top-Down ApproachFeaturing the Internet. Addison Wesley, 2003.

[9] Peter H Jesty and Ian Kendall (Jaguar Cars Ltd) Keith M Hobley (University ofLeeds), Richard Evans (Rover Group Ltd). Safety Analysis of Vehicle-Based Sys-tems. 2000.

[10] John C. Knight. Safety critical systems: challenges and directions. In ICSE ’02:Proceedings of the 24th International Conference on Software Engineering, pages547–550, New York, NY, USA, 2002. ACM Press.

[11] Nancy Leveson. Medical Devices: The Therac-25. Technical report, University ofWashington.

[12] Nancy G. Leveson. Software safety in embedded computer systems. Commun.ACM, 34(2):34–46, 1991.

[13] Roger S. Rivett (Rover Group Ltd). Emerging Software Best Practice and how tobe Compliant. 1997.

[14] Keith M Hobley (The University of Leeds) Ian Kendall (Rolls-Royce & Bent-ley Motor Cars Limited) Michael Ellims (Pi Technology), Richard Evans (JaguarCars Limited). When is Software Ready for Production? Parallels with AutomotiveQS9000 Methods. 2000.

[15] David Lorge Parnas. Software aspects of strategic defense systems. SIGSOFTSoftw. Eng. Notes, 10(5):15–23, 1985.

75

76 REFERENCES

[16] Phytec. phyCore XC167CI Hardware Manual. Technical report, Phytec, 2003.

[17] P.R.H. Place and K.C. Kang. Safety-Critical Software: Status Report and Anno-tated Bibliography. Technical Report CMU/SEI-92-TR-5 & ESC-TR-93-182, Soft-ware Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania15213, USA, June 1993.

[18] Robert W. Sebesta. Concepts of Programming Languages. Addison-Wesley Long-man Publishing Co., Inc., Boston, MA, USA, 2001.

[19] Andrew S. Tanenbaum. Modern Operating Systems, Second Edition. Prentice Hall,2001.

Appendix A

Abbreviations

ARP Address Resolution ProtocolCIDR Classless InterDomain RoutingFIFO First In First OutFTP File Transfer ProtocolHAL Hardware Abstraction LayerICMP Internet Control Message ProtocolIETF Internet Engineering Task ForceIP Internet ProtocolISR Ethernet Interrupt RoutineMAC Medium Access ControlMTU Maximum Transfer UnitOS Operating SystemRTOS Real-Time Operating SystemTCP Transmission Control ProtocolUDP User Datagram ProtocolVCS Vehicle Control SystemVIS Vehicle Information System

77

78 Chapter A. Abbreviations

Appendix B

Socket ApplicationProgramming Interface (API)

B.1 General

This is a description of the API (Application Programming Interface) for sockets in VCSCore. This section is intended for writers of applications.

VCS Core have a layered architecture consisting of three major layers, the HardwareAbstraction Layer (HAL), the VCS Core layer and the application layer. The API isthe interface between the Application and VCS Core. The TCP/IP stack is integratedinto the VCS Core.

The TCP/IP module is responsible for sending and receiving data via the ethernet-card. Available protocols for this propose are TCP and UDP. TCP represents reliabledata transfer an UDP represents unreliable data transfer. Sockets provide a standardprotocol-independent interface between the application-layer programs and the TCP/IPstack. The only way to use the TCP/IP stack from the applications perspective isthrough the socket interface.

B.2 Usage

A connection between two sockets can be created in two ways, accepting a connection-request or connect to an accepting socket. In a client server model the client usually

Figure B.1: System structure

79

80 Chapter B. Socket Application Programming Interface (API)

connects and the server accepts connections. TCP is connection oriented and creates areliable byte stream channel through which data flows between two end systems. UDPprovides an unreliable connectionless service. Therefore only TCP sockets can connectto or accept connections. The complete socket API is listed below.

s16 vcs_socket( u16 type )

s16 vcs_listen( u16 sockfd )

s16 vcs_bind( u16 sockfd, u16 port )

s16 vcs_accept( u16 sockfd, sock_addr_t PTR *saddr )

s16 vcs_connect( u16 sockfd, sock_addr_t PTR *daddr )

s16 vcs_send( u16 sockfd, u08_ptr msg, u16 len, u16 flags )

s16 vcs_sendto( u16 sockfd, u08_ptr ip, u16 port, u08_ptr msg, u16 len, u16 flags )

s16 vcs_recv( u16 sockfd, u08_ptr buf, u16 len )

s16 vcs_recvfrom( u16 sockfd, u08_ptr ip, u16 port, u08_ptr buf, u16 len )

void vcs_close( u16 sockfd )

B.2.1 Creating a socket

When creating a socket the type must be specified, which indicates what protocol thesocket shall use. For a TCP socket the type is SOCK STREAM and for a UDP socket thetype is SOCK DGRAM. The syntax for creating a socket is shown below.

s16 vcs_socket( u16 type )

The function returns the created sockets descriptor, or -1 if the socket could not becreated.

B.2.2 Accepting a connection

When a created TCP socket shall accept connection-requests from remote sockets, thesocket must first be bound to a unused port. This is done with the bind function. Thesyntax is shown below.

s16 vcs_bind( u16 sockfd, u16 port )

The first argument, sockfd, is the descriptor of the socket to be bound and thesecond argument is the preferred port to bind the socket to. The socket can be boundto any unused port between 1 and 65535. This function returns the sockets descriptoror -1 if bind fails.

Next the socket must be told to listen for connection-requests which is accomplishedwith the following function.

s16 vcs_listen( u16 sockfd )

Argument sockfd is the socket descriptor. The function returns the sockets descrip-tor or -1 if listen fails.

When a socket is in listening-state, it discards all incoming connection-requests be-cause there is no queue for storing these. For a connection to be established the socketmust accept requests which is done with the following function.

s16 vcs_accept( u16 sockfd, sock_addr_t PTR *saddr )

The argument sockfd is the sockets descriptor. The second argument, saddr, is apointer to a address-structure. The sock addr t structure is constucted as follows.

B.2. Usage 81

struct sock_addr

{

u16 port;

u08 ip_addr[4];

};

The element ip addr will hold the IP address of the remote socket if accept wassuccessful, and the remote sockets port are stored in port.

The accept function creates a new socket for the established connection. This newsockets descriptor is returned or -1 if accept failed.

B.2.3 Connect to a peer socket

Establishing a connection between a local socket and a remote accepting socket is donewith the vcs connect function. It is possible to bind the local socket before connecting,but it is not required. If the socket is unbound, the port associated with the socket willbe chosen arbitrarily between 1024 and 65535. The syntax of connect is shown below.

s16 vcs_connect( u16 sockfd, sock_addr_t PTR *daddr )

The first argument sockfd is the descriptor of the local socket. The second argumentdaddr is a sock addr t structure constructed as follows.

struct sock_addr

{

u16 port;

u08 ip_addr[4];

};

The daddr structure shall hold the IP address and port of the remote socket.

B.2.4 Send and receive data

Sending and receiving data on TCP sockets require an established connection betweentwo sockets. TCP sockets support all below listed send and receive functions, but thefunctions vcs sendto and vcs recvfrom are more suited for UDP sockets.

The send functions will block the calling thread until len bytes has been sent andacknowledged1. The syntax of the send functions are shown below.

s16 vcs_send( u16 sockfd, u08_ptr msg, u16 len, u16 flags )

s16 vcs_sendto( u16 sockfd, u08_ptr ip, u16 port, u08_ptr msg, u16 len, u16 flags )

The argument msg is a pointer to the buffer holding the data to be sent. Numberof bytes to send is specified in len. Accepted flags are PUSH and SPLIT. The PUSH

flag tells the remote socket to deliver (push) data to its application when len bytes aretransferred. The flag SPLIT divides the first segment to send in half. This is used togain performance due to delayed acknowledgments, that most TCP implementationsuse. It is only useful when sending data that fits into one segment. The functions returnnumber of bytes sent.

The receive functions will block the calling thread until receive completes. If thesending socket is using the push function, receive completes when the remote socket isdone sending. Otherwise receive completes after len bytes are transferred. The syntaxof the receive functions are shown below.

1Only TCP require acknowledgments


s16 vcs_recv( u16 sockfd, u08_ptr buf, u16 len )

s16 vcs_recvfrom( u16 sockfd, u08_ptr ip, u16 port, u08_ptr buf, u16 len )

Argument buf is a pointer to the buffer to store the received data. Number of bytesto receive is specified in len. The functions returns number of bytes received.

B.2.5 Close a socket

To close a connection the following function is used.

void vcs_close( u16 sockfd )

B.3 Code example

#include <vcs/inc/vcs_types.h>

#include <vcs/inc/vcsutility.h>

#include <vcs/inc/net/socket.h>

s16 ClientExample( void )

{

SOCKET clientSocket;

sock_addr_t daddr;

u08 serverIP[4] = {172, 16, 2, 5};

u16 serverPort = 1234;

u08 snd_buffer[15] = {’E’, ’x’, ’a’, ’m’, ’p’, ’l’, ’e’, ’ ’, ’p’, ’r’, ’o’, ’g’, ’r’, ’a’, ’m’};

s16 sentBytes;

/* Creating socket */

if( (clientSocket = vcs_socket( SOCK_STREAM )) < 0)

{

/* creating socket failed */

return -1;

}

/* Building address structure */

MemCopy( daddr.ip_addr, serverIP, 4 );

daddr.port = serverPort;

/* Connecting to peer socket */

if( (vcs_connect( clientSocket, &daddr )) < 0)

{

/* Connection attemp failed */

return -1;

}

/* Sending data */

if( (sentBytes = vcs_send( clientSocket, snd_buffer, 15, (PUSH | SPLIT) )) <= 0)

{

/* Send failed */

return -1;

}

vcs_close( clientSocket );

return sentBytes;

}

B.3. Code example 83

s16 ServerExample( void )

{

u08 rcv_buffer[40];

SOCKET connectionSocket;

SOCKET listeningSocket;

sock_addr_t saddr;

u16 localPort = 1234;

s16 recvBytes;

/* Creating socket */

if( (listeningSocket = vcs_socket( SOCK_STREAM )) < 0)

{

/* creating socket failed */

return -1;

}

/* Bind socket */

if( vcs_bind( listeningSocket, 1234 ) < 0 )

{

/* bind failed */

}

/* Listen for connection requests */

if( vcs_listen(listeningSocket) < 0 )

{

/* Listen failed */

return -1;

}

if( (connectionSocket = vcs_accept( listeningSocket, &saddr )) < 0)

{

/* accept failed */

return -1;

}

/* Receive data */

if( (recvBytes = vcs_recv( connectionSocket, rcv_buffer, 40 )) <= 0)

{

/* receive failed */

return -1;

}

vcs_close( listeningSocket );

vcs_close( connectionSocket );

return recvBytes;

}


Appendix C

Ethernet HardwareAbstraction Layer

C.1 General

The purpose of a Hardware Abstraction Layer is do provide machine independent accessto different hardware. It make is easier to move software between different machinesand to use different hardware.

This is a description of the HAL for Ethernet controllers in VCS Core. This sectionis intended for developers in CS Core and for developers writing Ethernet Controllerdrivers. It describes a interface to Ethernet Controller devices that makes it possible toaccess different Ethernet Controllers in the same way.

VCS Core has a layered architecture consisting of three major layers, the HardwareAbstraction Layer (HAL), the VCS Core layer and the application layer. This describesthe interface between the VCS Core and Ethernet Controllers.

Figure C.1: System structure

C.2 Usage

C.2.1 Intialize Ethernet Controller

Before any kind of communication with the Ethernet controller can be done, it must meinitialized.

85

86 Chapter C. Ethernet Hardware Abstraction Layer

void HAL_Ethernet_Init( void );

This function will set up all necessary configuration registers at the Ethernet Con-troller.

C.2.2 Interrupts

The Ethernet controller can generate interupt the CPU when different event occurs, likepacket reception etc.

void HAL_EthernetEnableISR( void );

This function will enable interrupt generation. After a call to this function the CPUcan be interrupted by the ethernet controller. On interrupt the Interrupt Service Routineat the Ethernet controller is invoked.

void HAL_EthernetDisableISR( void );

This function disables interrupt. After a call to this function the CPU will no longerbe interrupted.

C.2.3 Identifying The Ethernet Controller

Different Ethernet controller can be used. To be able to identify which type of Ethernetcontroller that is connected to the hardware this functionality has been added.

TEXT_CONST_PTR HAL_EthernetDeviceName( void );

The function returns a string that identifies the Ethernet controller.

C.2.4 Link Status of Ethernet Controller

To find out whether or not the cable is connected to the Ethernet controller.

BOOL HAL_EthernetLinkStatus( void );

Returns TRUE if a cable is connected , else FALSE.

C.2.5 Send a Ethernet Frame

Sending a Ethernet frame can be done in to ways. Either using a interrupt triggeringmethod or a polling method. In the polling method the Ethernet controller is polleduntil it is not busy and then it sends the frame. In interrupt mode it tries to sendthe frame, but if the Ethernet controller is busy return and wait for an interrupt to begenerated.

void HAL_SendEthernetFrame( u16_const_ptr packet, u16 packet_size );

This function will send a packet in poll mode. The function will not return until thepacket is sent.

void HAL_TrySendEthernetFrame( u16_const_ptr packet, u16 packet_size );

This function will try to send a Ethernet frame but if the Ethernet controller is busythis function will return. An interrupt will be generated when the Ethernet controlleris ready to transmit.

Documents

Development of a TCP/IP stack in a real time …...Development of a TCP/IP stack in a real time embedded system Stefan Jakobsson & Erik Dahlberg August 21, 2007 Master’s Thesis in