TCPstack Embedded System

Development of a TCP/IP stack in a real time embedded system
Stefan Jakobsson & Erik Dahlberg
August 21, 2007 Masters Thesis in Computing Science, 2*20 credits Supervisor at CS-UmU: Jan Erik Mostrm o Examiner: Per Lindstrm o
Ume University a
Department of Computing Science SE-901 87 UME A SWEDEN
Abstract A communication protocol is a description of the rules computers must follow to communicate with each other. The TCP/IP protocol suite refers to several separate protocols that computers use to transfer data across networks. It is named after the two most important protocols in its suite, Transmission Control Protocol (TCP) and Internet Protocol (IP). TCP/IP is widely used because its ability to switch packets from all shapes and sizes and varieties of networks. The aim of this Master Thesis was to implement a TCP/IP stack in an embedded system. The intended embedded system demanded some requirements on the TCP/IP stack. Only the most important protocols, and features in these protocols, should be implemented. Memory usage should be kept low, and MISRA-C coding rules should be employed. This report presents how the TCP/IP stack is implemented as well as information about involved hardware and software. The report also gives an introduction to some basic concepts regarding a TCP/IP stack and also information about the system in which the stack resides.
ii
Contents
1 Introduction 1.1 Outline of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Problem Description 2.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 VCS 3.1 VCS System . . . . . . . . . 3.2 VCS Core . . . . . . . . . . 3.3 Rubus OS . . . . . . . . . . 3.3.1 The Red Kernel . . 3.3.2 The Blue Kernel . . 3.3.3 The Green Kernel . 3.3.4 Rubus Visual Studio 1 1 3 3 3 5 5 8 8 10 11 12 13 15 15 16 16 17 17 17 18 20 21 21 21 22 23 25
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
4 Software Development For Safety Critical Systems 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 4.2 System safety . . . . . . . . . . . . . . . . . . . . . . 4.3 Software failuers: What can go wrong? . . . . . . . . 4.3.1 Therac-25 . . . . . . . . . . . . . . . . . . . . 4.3.2 Ariane 5 . . . . . . . . . . . . . . . . . . . . . 4.4 What is the problem? . . . . . . . . . . . . . . . . . 4.5 Language Selection . . . . . . . . . . . . . . . . . . . 4.5.1 Java . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Ada . . . . . . . . . . . . . . . . . . . . . . . 4.5.3 C . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . 4.7 Development of safety critical software . . . . . . . . 4.7.1 Correctness of software based systems . . . . 4.7.2 When is Software Ready for Production? . . iii
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
iv
CONTENTS
5 TCP/IP 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 5.2 Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Requirements . . . . . . . . . . . . . . . . . . . . . 5.3.1 Application layer . . . . . . . . . . . . . . . 5.3.2 Transport layer . . . . . . . . . . . . . . . . 5.3.3 Network layer . . . . . . . . . . . . . . . . . 5.3.4 Network interface layer . . . . . . . . . . . 5.4 Socket . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Network Layer Protocols . . . . . . . . . . . . . . . 5.5.1 Internet Protocol (IP) . . . . . . . . . . . . 5.5.2 Addressing . . . . . . . . . . . . . . . . . . 5.5.3 Fragmentation . . . . . . . . . . . . . . . . 5.5.4 Header format . . . . . . . . . . . . . . . . 5.5.5 Address Resolution Protocol (ARP) . . . . 5.5.6 Internet Control Message Protocol (ICMP) 5.6 Transport Layer Protocols . . . . . . . . . . . . . . 5.6.1 Transmission Control Protocol (TCP) . . . 5.6.2 User Datagram Protocol (UDP) . . . . . . 5.7 Application Layer Protocols . . . . . . . . . . . . . 5.7.1 File Transfer Protocol (FTP) . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
27 27 27 27 28 28 28 28 28 30 30 30 31 32 33 34 35 35 39 40 40 41 41 43 45 47 47 47 48 48 50 50 51 53 53 53 54 55 55 59
6 Hardware 6.1 Phytec phyCore-XC167 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Microcontroller Infenion XC167CI . . . . . . . . . . . . . . . . . . . . . 6.3 Ethernet Controller Cirrus Logic CS8900A . . . . . . . . . . . . . . . . . 7 System description 7.1 Overview . . . . . . . . . . . . . 7.2 Telnet Server . . . . . . . . . . . 7.2.1 Negotiation . . . . . . . . 7.2.2 Interface . . . . . . . . . . 7.3 FTP Server . . . . . . . . . . . . 7.3.1 Supported Commands . . 7.4 Socket . . . . . . . . . . . . . . . 7.5 TCP . . . . . . . . . . . . . . . . 7.5.1 Data structures . . . . . . 7.5.2 Buers . . . . . . . . . . . 7.5.3 State machine . . . . . . . 7.5.4 Establishing a connection 7.5.5 Sending data . . . . . . . 7.5.6 Receiving data . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
CONTENTS
7.6 7.7
7.8 7.9
7.5.7 Timers . . . . . . . . 7.5.8 Congestion control . UDP . . . . . . . . . . . . . IP layer . . . . . . . . . . . 7.7.1 Upper level interface 7.7.2 Lower level interface QueueLayer . . . . . . . . . 7.8.1 ARP-module . . . . HAL . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
61 61 63 64 64 64 65 67 69 71 71 71 73 75 77
8 Conclusions 8.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgments References A Abbreviations B Socket Application Programming Interface B.1 General . . . . . . . . . . . . . . . . . . . . B.2 Usage . . . . . . . . . . . . . . . . . . . . . B.2.1 Creating a socket . . . . . . . . . . . B.2.2 Accepting a connection . . . . . . . B.2.3 Connect to a peer socket . . . . . . . B.2.4 Send and receive data . . . . . . . . B.2.5 Close a socket . . . . . . . . . . . . . B.3 Code example . . . . . . . . . . . . . . . . . C Ethernet Hardware Abstraction Layer C.1 General . . . . . . . . . . . . . . . . . . . . C.2 Usage . . . . . . . . . . . . . . . . . . . . . C.2.1 Intialize Ethernet Controller . . . . . C.2.2 Interrupts . . . . . . . . . . . . . . . C.2.3 Identifying The Ethernet Controller C.2.4 Link Status of Ethernet Controller . C.2.5 Send a Ethernet Frame . . . . . . . (API) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
79 79 79 80 80 81 81 82 82 85 85 85 85 86 86 86 86
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
vi
CONTENTS
List of Figures
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 5.1 5.2 5.3 5.4 5.5 5.6 5.7 6.1 6.2 6.3 6.4 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 Example of a VCS System . . . . System overview . . . . . . . . . Inside a VCS node . . . . . . . . Rubus overview . . . . . . . . . . Clock scheduler in the red kernel Legal state transitions . . . . . . Blue thread scheduling in Rubus Rubus Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6 8 9 10 11 12 13 30 32 33 35 36 37 39 42 42 44 45 47 54 56 59 60 65 66 67 79
An example of a network . . . . . . . . . . . . . . IP header format . . . . . . . . . . . . . . . . . . . A small Local Area Network example . . . . . . . . TCP header format . . . . . . . . . . . . . . . . . . Example of sequence and acknowledgment numbers Example of how a TCP connection is established. . UDP header format . . . . . . . . . . . . . . . . . Block diagram of phyCore-XC167 . . . . . . Modication of phyCore-XC167 . . . . . . . XC167CI Memory map . . . . . . . . . . . . Overview of XC167CIs on-chip components . . . . . . . . . . . . . . . .
The TCP/IP-stack is built in a layered structure . . . . Data buer organization for a TCP packet with N bytes Overview of the send-algorithm . . . . . . . . . . . . . . Receive procedure for the Application-Thread . . . . . . Receive procedure for the Receive-Thread . . . . . . . . Packet queues buer organization . . . . . . . . . . . . . Application-Thread . . . . . . . . . . . . . . . . . . . . . Work process for the Receive-Thread . . . . . . . . . . .
. . . . . of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1 System structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
viii
LIST OF FIGURES
C.1 System structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
List of Tables
4.1 5.1 5.2 5.3 6.1 6.2 Denitions of controllability levels . . . . . . . . . . . . . . . . . . . . . Address classes in IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . A possible ARP table in node 192.168.0.17 . . . . . . . . . . . . . . . . ICMP message types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Memory organization in CS8900A . . . . . . . . . . . . . . . . . . . . . CS8900A I/O port mapping . . . . . . . . . . . . . . . . . . . . . . . . . 24 31 33 34 45 46
ix
LIST OF TABLES
Chapter 1
Introduction
The use of embedded systems are common in many areas today. These systems vary in size, scope of use and complexity and resides in everything from toasters to space shuttles. An embedded system is a combination of computer hardware and software that is manufactured to handle a specic task. Although an embedded system is usually a single-purpose application, it is often integrated with other embedded systems which together performs advanced functions. Ordinary personal computers are designed to satisfy a variety of users and to run many dierent kinds of applications. Embedded systems can be specialized in terms of hardware and software for its specic task. This limited scope of use makes it possible to design these systems to perform as eciently as desired, and thereby keeping the costs down. One domain using embedded systems is the vehicle industry. A modern car contains many embedded systems which handles functionality like Anti-lock Braking Systems (ABS) and Cruise Control. Another vehicle industry using embedded systems in their products is the defence industry. One leading manufacturer of combat vehicles are BAE Systems Hgglunds a in Ornskldsvik (Sweden) with over 1200 employees. This master thesis was proposed o by Hgglunds and involved an embedded system in a combat vehicle. The task was to a extend 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 Hgglunds. Chapter 7 a will explain how the work was done, thus describing the actual implementation details of 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 chapter 4, discussing topics concerning development of safety critical software. This project is an extension of an existing system in a combat vehicle. The system is called VCS (Vehicle Control System) and chapter 3 will explain what components VCS consists of and how they interact. After the in-depth study, chapter 5 will explain the responsibilities of a TCP/IP stack, which is a suite of transport protocols. A subset of these protocols will be explained in terms of how they work and cooperate. Readers 1
Chapter 1. Introduction
familiar with TCP/IP and its protocols might skip this chapter. The hardware used for this project is presented in chapter 6. After the description of the implementation in chapter 7, future work and limitations of the solution is discussed. The list below gives a short description of the dierent chapters, 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 Hgglunds developed their new combat vehicle CV9030CH, a new distributed a computer based system called Vehicle Control System (VCS) was born. This electrical system replaced the old systems built upon cables and relays. VCS consists of several microcontrollers which uses CAN (Controller Area Network) to communicate with each other. CAN is based on a shared serial bus developed for connecting electronic control units. VCS is responsible for controlling and monitoring vehicle functions such as fans, engines etc. Each microcontroller is congured to perform a specic task. To ease development of software for each microcontroller, all common functions were gathered and forms a framework under the name VCS Core. This framework can be viewed as an Operating System though it is built upon a small Real-Time Operating System called Rubus 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 to the ethernet-controller. Applications that use the network communication tools provided by 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 stack should use as little memory as possible, because VCS is running on small microcontrollers with limited resources. Further, the implementation should follow a number of coding guidelines. One guideline which had a big impact of the systems design was that no dynamic memory allocation was allowed.
2.2
Goals
The main purpose of this thesis was to investigate the possibility of a TCP/IP-stack in the VCS system. Is it realistic to have a TCP/IP-stack in VCS core or will it consume to much memory and CPU-time? The goal was therefore to implement a TCP/IP-stack into the VCS Core framework that meets the systems demands. VCS had no support for TCP/IP whatsoever, so everything had to be done from scratch. This made it hard to estimate how much work and time that was needed for this project. Therefore the goal was divided into the following sub-goals: 3
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-les. Many opportunities arise if communication with a VCS-node through Ethernet was possible. Diagnostic information could be downloaded via FTP, or possibilities of remote login with Telnet. Also many 3:rd part components communicates through TCP/IP and integration 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 electrical system that was developed for the combat vehicle CV9030CH. Together with VCS another system called VIS (Vehicle Information System) was also developed as a complement to VCS. The system is based on dierent microcontrollers with CANcommunication, also called nodes. Each node runs VCS Core software and has one or several dierent CAN interfaces. Normally a node is connected to a single CANnetwork but it can be congured to act as a gateway between dierent 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 relays in a electrical system. Software makes it more exible and congurable. It makes it easy to build vehicle simulators, test-benches, virtual vehicles and also to discover and react on errors that can arise in components. Software will also make it possible to use Built In Tests (BIT) for error detection, which Hgglunds describes as a requirement from a customers. Another benet with a software system is that it simplies communications with 3:rd part systems like a GPS etc. The electrical system inside Hgglunds combat vehicles can be divided into dierent a function domains, where each domain has special requirements. An overview of a typical 5
Chapter 3. VCS
computer based distributed electrical system and how it can be divided in dierent domains 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 Hgglunds has, besides VCS, devela oped three other core platforms named Vehicle Information System (VIS), Extended Control System (ECS) and Diagnostic Information System (DIS). DIS is an external system that is plugged into the CAN-network when diagnostics is needed. Information domain Man Machine Interface (MMI) manages and presents information to the user through displays, alarms, diagnoses, videos etc. All of these functions are handled 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
Occasional disturbances that can arise in this domain will not eect the vehicle because it contains no functions that controls the vehicle. VIS runs on PC machines with Linux and communicates with each other through TCP/IP via Ethernet. To be able to communicate with nodes in the utility domain, one VIS-node must act as a gateway. Utility domain The 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 is exclusively done through CAN-buses. Real-Time domain Although VCS can be used in this domain, the primary choice is ECS. ECS is a big brother to VCS, and is based on VxWorks OS. The functions in this domain has higher real time demands than in the utility domain. The functions here include ballistic calculations which require more computational power than the 40 Mhz microcontrollers can oer. Therefore ECS is running on Power PC machines at 266 Mhz.
A fourth, safety-Critical, domain could also be added in the system view. The domain would contain safety-critical operations like drive-by-wire systems for electrical steering or braking. These operations are today traditionally done mechanically or hydraulically but it will probably change in the future. Then VCS could be an alternative to commercial solutions.
Chapter 3. VCS
3.2
VCS Core
Inside a VCS node the software can be divided into layers according to Figure 3.3. At the bottom there are Electronic Hardware, like signals, clocks, communication ports etc. Then comes the Hardware Abstraction Layer (HAL) that provides standardized methods to access dierent hardware. Above the HAL comes the VCS Core which contains a small Real-Time Operating System (RTOS) and a conguration part. The main task of VCS Core is to provide common services and functions like I/O, monitoring, logging and CAN-protocols. With the conguration part it makes it easy to congure nodes for dierent applications. VCS Core is written in a subset1 of ANSI C and designed to be platform and compiler independent. This can be done because all hardware-specic software is located in the HAL. It is also possible to simulate one or more VCS nodes on a ordinary PC, then the real CAN-drivers is replaced by drivers that communicates through 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 an essential role in Rubus. Typically a Real-Time operating system must react on external devices in a very constrained time period. Application operations running in RealTime systems can be divided into two groups; hard Real-Time and soft Real-Time. In hard 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
Real-Time it is not critical if a deadline is missed but it is still not desirable. Because of dierent demands of application operations, Rubus OS provides three categories of run-time services: Green Run-Time Services External event triggered execution (interrupts). Red Run-Time Services Time triggered execution, used by applications which deadlines are critical to the operation (Hard Real-Time). Blue Run Time Services Internal event triggered execution, for applications which deadlines are not critical to 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 Kernel manages the execution of time triggered red threads. Red threads are statically scheduled before run-time. The Blue Kernel handles execution of internal event triggered blue threads. Scheduling of blue threads is done during run-time. The green kernel manages the 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 to dispatch threads according to the current schedule and the current time. The schedule denes when threads are to be executed. When the dispatcher reaches the end of the schedule 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. When the clock has completed one rotation it will start over. Several schedules can co-exist in the system and the Red Kernel contains functionality for switching between them. The schedules are statically dened 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 communication between threads such as synchronization and message passing. Synchronization is done by message queues, signals and mutexes according to the POSIX standard. The Blue Kernel is a traditional event triggered kernel with a preemptive scheduling algorithm, which means that each thread will run for a maximum amount of some xed time. If the thread is still running at the end of its given time it will be suspended and the scheduler will select another thread to run [19]. The Blue kernel provides dierent priorities for blue threads and guarantees that the thread with highest priority, among the ready threads, will be executed rst. Like everything else in Rubus the stack is allocated statically and the size of the stack can not be altered at run-time. Therefore the size of the stack must be dimensioned to the maximum stack usage. A blue thread can be in one of the following states: Dormant The thread is terminated or not initialized. Ready The thread is ready to execute. Blocked The thread is blocked waiting for a signal. Running The thread is running. Legal state transitions can be seen in gure 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 Blue Kernel Thread and 0 is used (but not reserved) by the Blue idle thread. Each priority level 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 threads are running. Either when no red threads are scheduled or when the red threads do not utilize 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 running thread 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 unit in the Green Kernel is the target processors interrupt logic. Therefore the behavior is target dependent. If an interrupt occurs, a Green Thread will preempt the execution of both Red and Blue Threads.
3.3. Rubus OS
13
3.3.4
Rubus Visual Studio
Arcticus Systems has developed a conguration tool, to ease the development of dependable Real-Time system, based on Rubus OS. All threads in VCS Core are created before run-time, and Rubus Visual Studio provides a interface which makes it easy to add and remove such threads.
Figure 3.8: Rubus Visual Studio
14
Chapter 3. VCS
Chapter 4
Software Development For Safety Critical Systems

4.1 Introduction
Failures are not desirable in any systems. But the consequence of something going wrong is not equal for all systems. If the software in a desktop computer crashes a couple of working hours may be lost, while a software failure inside an aircrafts y-by-wire system could lead to lost lives. In other words, there are systems where software failures are acceptable at some level and there are systems where failures are unacceptable[10]. Safety-critical systems are those systems where failures are unacceptable, a failure in such system could result in loss of life, signicant property damage or damage to the environment. 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. y-by-wire systems in aircraft, aircraft control. Interlocking systems for trains. Medical devices. Nuclear power plant control. A failure in these areas can directly lead to that human lives are put in danger. Many safety critical systems are embedded systems, many do also have Real-Time demands. In a 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 it will 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 systems are not necessarily (but often) embedded systems or Real-Time systems. Therefore the aspects 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 rarely explode, catch re or cause any physical harm. Computers can only indirect cause accidents 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] denes hazard and risk as: A hazard is a state that can lead to an accident given certain environmental conditions.
A risk is dened 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 necessarily cause an accident but it is certainly a state that can lead to an accident. If system safety was dened by accidents or catastrophic failures instead of hazards and risks, most systems could be considered safe. In this denition, software itself can not directly cause accidents but rather only contribute to hazards. However, because of software can contribute to system hazards, minimizing software aws will therefore reduce or prevent accidents. It is also important to separate safety from reliability. Reliability is often measured in up-time or availability of a system. A safe system can fail frequently provided that it fails in a safe way. While a reliable system may not fail often, it makes no guarantees what happens when it fails. Systems can be safe but not reliable. A rail-road signaling system 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 by the cost of safety when errors are ignored, and systems are allowed to continue for the cause of availability. Place and Kang [17] points out that safety software requires not to be perfect. The code may contain errors as long the consequence of the errors do not lead to hazards.
4.3
Software failuers: What can go wrong?
Today, aws in software products are common. Software patches and updates are constantly released to correct previous problems. People have come to accept that software fails 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 by software 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 therapy treatment device called Therac-25. It was developed by the Atomic Energy of Canadian Limited (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 PDP11 computer. In Threac-6 and Therac-20, which relied on hardware safety features and interlocks, the software played a minor part. However, the software in Therac-25 had more responsibility for maintaining system safety [11]. Due to some software aws in Therac-25, six patients received an overdose of radiation. The accidents occurred between 1985 and 1987 when Therac-25 was recalled. Three of the accidents had a lethal outcome.
4.3.2
Ariane 5
Ariane 5 is an European launch system designed to deliver satellites and other payload into space. In June 4 1996, after 10 years of development and a cost of e7 billion, Ariane 5 was nally ready for its rst test ight (ight 501). The launch went well and Ariane 5 followed a normal trajectory for 37 seconds. But shortly after, it suddenly veered o its ight path, broke up, and exploded. A data conversion from 64-bit oating point to 16-bit integer had caused a software exception. The oating point number had a value greater than what could be represented by a 16-bit signed integer. This led to an Operand Error -exception. Due to eciency considerations the software handler (in Ada code) for this trap was disabled, although other conversions of comparable variables in the same place in the code were protected. This software aw was located in the Inertial Reference System (SRI) which provides ight data to the On-Board-Computer (OBC). The OBC is responsible for executing the ight program and controlling the nozzles of the solid boosters. Because of the software exception, the SRI transmitted erroneous ight data to the OBC. The ight data resulted in full nozzle deection of the booster and the self destruction mechanism was eventually triggered when the aerodynamic loads became too high. More details about the Ariane 501 ight failure can be found in [4].
4.4
What is the problem?
Despite that accidents have occurred due to software failures, software controlling safety critical systems are here to stay. The use of software provides a number of advantages over hardware. Software is exible and easy to modify and can also provide a better interface for users. With software, it is easier to simulate and test the whole or parts of a systems. So called Built-In-Tests (BIT), where software examines the system status, 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 for more and more complicated tasks, the software controlling the systems are getting more complex. Because of the software complexity, the human design-errors has increased dramatically and it is hard, if not impossible, to ensure the correctness of the software. Before software was used in safety-critical systems, they were often controlled by non-programmable electronic and mechanical devices. Parnas[15] argues that analog systems, such as mechanical- and hydraulic systems, are made from components that, within a broad operating range, have an innite number of stable states and whose
18
behavior can be adequately described by continuous functions. When systems are described by continuous function it means that small changes in inputs will always cause correspondingly small changes in output. This is not the case in a discrete system where a single bit change can have a huge impact. The mathematics of continuous functions is well understood and this combined with testing to ensure that components are within their operating range, leads to reliable systems.
4.5
Language Selection
There are plenty of programming languages to choose from today, each have its own benets and is suitable for dierent tasks. Java, with its byte code, is platform independent while C is more suitable for low level programming etc. A programming language itself can of course not guarantee the correctness of the software. However, it can help the programmer in the right direction. The philosophy of C is to trust the programmer while other languages are more restrictive. A quote from 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 language should be carefully considered. Some characteristics that generally improves the safety 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 rules of the language. A more comprehensive check will increase the reliability of a language when 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, the corresponding C -code would compile. Many strongly typed language as Java, Ada, Pascal etc. oers 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 that no extra overhead is generated in the execution.
4.5. Language Selection
19
As mentioned earlier, many errors can be prevented with a better compile-time checking, but all errors cannot be discovered before run-time. The next step is to provide run-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 stued into the memory location pointed 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 be checked during run-time. This will, of course, force the compiler to generate some extra code and therefore eect both code size and execution time. Because of the performance loss, 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 arise in software is important to achieve safety. An exemplary way for a programming language to handle this, is to provide exception handling. Exceptions are preferred over error codes for several reasons. Checking return codes from functions, as the normal way in 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 of the code and prevent to obscuring the actual program logic. Checking return codes is a manual process, the programmer needs to remember to check every time the function is 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 the programmer. This makes it harder to forget (or skip) error handling.
1 When
did you lately check the return value of the printf()-function in C
20
Properties that make a programming language safer can also be more subtile than those which has been described so far. Depending on how the grammatical rules of a language is formed, ordinary typing errors can more or less easily slip into the code and cause unexpected behavior. For example, in C = is used for assignment and == for comparison, this notation can easily result in the typing mistake shown in statement (1):
if ( a = b ) ( 1 ) ( 2 )
if ( a == b )
In C the statement (1) will always be true as long b = 0 and (2) will be true only if a = b. In java statement (1) would not pass the compiler since a boolean type is excepted. If a language has features that are not completely or ambiguously dened, the programmer can assume that the compiler interprets the code dierently than expected. This is mainly an issue when using dierent compilers, but one compiler can also behave dierently 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 satised with C and C++ for developing software for electronical devices. C lacked the support of object-oriented programming, and C++ was far too complex. They also believed that neither of them could provide enough reliability. Suns guidelines when designing Java were therefore that it should be more reliable and simpler than C++. Although Java was designed for embedded systems, no electronic products using Java reached the market in the beginning. Instead, Java was found to be a useful tool when the Word Wide Web became widely used. Today, Java has matured and is widely used in dierent systems, not to mention in embedded devices such as mobile phones where Java has grown strong. Java has several features that 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 same extension in Real-Time systems. Many safety critical systems belong to the Real-Time domain where predictability of execution is important. The automatic memory management in Java leads to unpredictable latencies in execution. There is also some unpredictability in synchronization[2]. Beyond requirements for Real-Time systems there are also features needed for embedded systems, such as low level programming, writing interrupt procedures. This is a weak area (with purpose) of Java since it both compromise portability and safety. To address the problems with Java, Sun Microsystems created a Real-Time Specication for Java (RTSJ).
4.6. Conclusion
21
4.5.2
Ada
Not surprisingly Ada is considered as the most suitable language for safety-criticalsystems. Ada is the result of the most extensive and most expensive language design eort that has ever been made[18]. It was standardized by the American National Standards Institute in 1983 but the rst truly usable Ada compilers did not appear until two years later. Ada was developed to meet the high demands of a Department of Defense (DoD) and to be used in their safety critical systems. Although Ada received some criticism in the beginning, especially from Hoare in[7] that he thought it was too complex, it became the primary choice for programming safety critical systems.
4.5.3
C is not known as a reliable programming language. The language is suitable for low-level programming and is therefore popular for programming embedded systems. There are C -compilers available for most architectures, therefore C -programs are very portable. Some safety aws in C have already been discussed, but there are also a number of drawbacks when using C in Real-Time systems. C has no language support for concurrency (multithreading), a serious drawback for Real-Time systems. The programmer needs to use an external application programming interface or Real-Time operating system (RTOS) which compromises portability.
4.6
Conclusion
Writing software for safety critical systems is not an easy task. Whatever programming language, reliable or not, it is still up to the programmer to implement the software correctly. Implementation is only one part of the software development process. To achieve software safety, each step from design to testing must be rigorouly dened. It is also important 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 more applications will rely on computers in the future. Software systems will also be trusted in a higher extent. Modern cars are already lled with small computers, but still no car contains drive-by-wire technology (replacement of mechanical operation devices by electrical signals). The car industry is a bit behind the ight industry where many modern planes today are controlled by y-by-wire systems. It just a matter of time before such systems also will be introduced in the cars.
22
4.7
Development of safety critical software
In many areas the use of embedded systems increase rapidly. The software in these systems handles more and more advanced tasks, and thus becomes bigger and more complex. In some areas, including the motor vehicle industry, these systems handles tasks that are more or less safety critical. An example of a relatively complex safety critical system, used in cars, is Adaptive Cruise Control (ACC). This system is similar to conventional cruise control, which holds a preset speed without participation of the driver. The extra feature this system provides is the ability to adjust speed automatically to maintain a distance to the vehicle ahead. This is achieved through a radar headway sensor, digital signal processor and a longitudinal controller. If the lead vehicle slows down, or if another object is detected, the system sends a signal to the engine or braking system to decelerate. Then, when the road is clear, the system will re-accelerate the vehicle back to the preset speed. This kind of system involves interaction between many vehicle control systems and is also a relatively new technique. A software system of this complexity has a potential for problems. Interesting questions about safety critical systems are: 1. How can condence 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 Industry Software Reliability Association. MISRA is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-related electronic systems in road vehicles. In 1994 MISRA published guidelines for the development of software for vehicle-based systems, these guidelines are meant to provide important advice to the automotive industry for the creation and application of safe, reliable software within vehicles[3]. The list below shows what these guidelines include. guidance for creating contracts and specications 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 development process to use is decided by the manufacturer. The techniques described in section 4.7.1 are proposed approaches from MISRA, which will give examples of techniques 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 process. 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. Doing this makes it possible to take design actions that can reduce these risks. It is also important to have documents of the reasoning behind the design actions taken. Therefore the rst step in the process is to make a hazard analysis. For this analysis to be accurate a model, or approximation, of the system must be produced. Often the system can be associated with many potential hazards which can lead to human injury, but most of these hazards are limited to specic physical situations. The model should therefore have a well dened boundary between the system itself and the potential situations that can lead to hazards. Also the boundaries between components within the system itself as well as boundaries between the system and other subsystems shall be dened. A model shall consist of: Components. The interconnections between the components. The boundaries. The level of detail chosen for dening a component depends on what type of system the model shall describe. Each component has some sort of interface to other components in the system, which shall be included in the model. The interface shall describe how components communicate with each other, and the format of this interface depends on what type of component is being described. For a system in a car, most hazards will be related to the movement of the whole vehicle. Therefore an important boundary to include is the one between the vehicle and its environment. Examples of environment can be driver, passenger, road, and other vehicles. Possible interactions with the environment 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 performed. One technique used for the analysis is Failure Mode & Eects Analysis (FMEA), which is often called a what if? analysis. This analysis begins by identifying possible hazards. Each boundary is considered in turn and the hazards related to its environment are considered systematically. FMEA both considers hazards related to some system failure and when the system is working as desired. In complex systems, there can be a chain of events that nally lead to a hazard. This means that other systems, whom can be aected by a fault of the system being developed, also must be considered. There is no easy task nding all possible hazards, but a well performed hazard analysis will ultimately lead to a safer system. Once the hazard analysis is complete, the systems Safety Integrity Level (SIL) must be determined. This value between 0 and 4 classies the hazards according to their severity, and is needed to determine the development process. A system with a low SIL
24
does not have to be designed, documented and built as thoroughly as a system with a high SIL. There are many techniques to determine the Safety Integrity Level for a system, but most of them consider systems in static environments. The non-static environment for vehicle systems is practically innite. Aspects like the skill of the driver and weather conditions must be considered. Therefore the MISRA Guidelines have adopted the concept of controllability as a means of determining safety integrity levels for systems which do not have a static environment[13]. Controllability measures what degree of loss of control a fault causes. The greater the loss of control the more serious the failure. Table 4.1 shows how the dierent levels of controllability are dened. Uncontrollable This relates to failures whose eects are not controllable by the vehicle occupants, and which are most likely to lead to extremely severe outcomes. The outcome cannot be inuenced by a human response. This relates to failures whose eects are not normally controllable by the vehicle occupants but could, under favorable circumstances, be inuenced by a mature human response. They are likely to lead to very severe outcomes. This relates to failures whose eects are usually controllable by a sensible human response and, whilst there is a reduction in safety margin, can usually be expected to lead to outcomes which are at worst severe. This relates to failures which produce operational limitations, but a normal human response will limit the outcome to no worse than minor. This relates to failures where safety is not normally considered to be aected, and where customer satisfaction is the main consideration.
Dicult to control
Debilitating
Distracting
Nuisance only
Table 4.1: Denitions of controllability levels After these steps are completed and the design phase begins, the Detailed Safety Analysis (DSA) are performed. The objectives of the DSA are to [9]: 1. Conrm the ndings of the PSA (Preliminary Safety Analysis) or PHA (Preliminary Hazard Analysis). 2. Identify any additional hazards that may have been introduced as a result of the design used. 3. Identify the possible causes of each hazard. 4. Conrm 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 & Eects Analysis and Fault Tree Analysis (FTA). Design FMEA is a bottom-up technique starting at a fault and ends up at its resultant eect. Each fault is classied using three dierent parameters: severity, occurrence and detection. Each of these parameters are given a score between 1 and 10 (not critical - extremely critical). The severity is the same as controllability, with the exception that a dierent scale is used. Occurrence is pretty hard to estimate for systematic software faults, because there is no reliable data available as there is for random faults in hardware. One option is to use measured Mean Time Between Failure for software from similar systems. The detection parameter describes the systems ability to detect a fault and of what degree the risk associated with that error can be reduced by the system. Fault Tree Analysis is a top-down approach. This is done via a hierarchy which gradually renes the hazard through a series of sub-system down to the failures of individual components. It can be useful to use both techniques to get an independent check, and provide condence that nothing has been missed. This technique is also useful for 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 an edge on their competition. This leads to creation of new applications in vehicles, with increasing complexity. Most features in modern vehicles are controlled with some software based system, and in the future these systems will most certainly control more areas 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 nal product meets the demands and safety analysis, there must be some guidelines these manufacturers 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 international standard that gives requirements for an organizations Quality Management System. QS9000 extends these requirements to be more specic about how they should be met. It consists of a suite of documents and two of them, Advanced Product Quality Planning (APQP) and Production Part Approval Process (PPAP), will be discussed here. 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 approach for the implementation of a Product Quality Plan, which will support the development of the product, to satisfy customers. It is based on a vehicle design lifecycle. It denes what has to be completed at the end of each phase of the development, to ensure quality of the product. It is impossible to directly measure the quality of the code, therefore condence 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. These criteria may include requirements documents, functional specications, design documents, checklist, the nal code and so on. A company can evolve the APQP process for each new project, and strive for improvement in their products. When the quality plan is complete, the PPAP process can be applied.
26
The PPAP document denes an approach to determine if all customers, engineering, design records and specication requirements are properly understood by the supplier[14]. A product must be approved by the PPAP process in order to be complete. The process must prove that the product can be produced with all requirements stated within APQP. MISRA has recently (march 2006) published a document with the title: Software readiness for production(SRfP). This document describes metrics that can be used for tracking the progress for software projects towards the goal of production readiness. The method is inspired by the ideas in Advanced Product Quality Planning and Advanced Product Quality Planning mentioned above. The purpose of the SRfP process is to make these approaches more suitable within a software context. The C programming language are widely used in embedded systems, and the reason is features of the language like easy access to hardware, low memory requirements, and ecient run-time performance. But the language also has its drawbacks such as highly limited run-time checking, a syntax that is prone to mistakes that are technically legal etc. In 1998 MISRA published MISRA C to support the language requirements of the 1994 MISRA Guidelines. The document became widely used and in year 2004, MISRA published 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 write safer and more portable code.
Chapter 5
TCP/IP
5.1 Overview
The TCP/IP protocol suite has become the standard for computer communications in todays networked world, mainly because of its simplicity and power. TCP/IP stands for: The Transmission Control Protocol(TCP)/Internet Protocol(IP), which are the names of the two most important protocols in this suite. The protocol suite was constructed to enable communication between hosts on dierent networks. Therefore one important aspect is the creation of an abstraction for the communication mechanisms provided by each type of network. TCP/IP hides the architecture of the physical network from the developer of the networkapplication. TCP/IP is modeled in layers as many other networking software. This architecture has many advantages such as ease of implementation and testing, ability to alternative layer implementations etc. Each layer communicates with those above and below through a well dened interface, and each layer has its own well dened tasks. This section will explain each layer in this protocol suite, starting at the top and working its way down.
5.2
Protocol
A protocol denes the format and the order of message exchanged between two or more communicating entities, as well as the actions taken on the transmission and/or receipt of a message or other event. [Kurose & Ross Computer Networking]
5.3
Requirements
In this section each layer is explained briey, to get an overview of what the individual layers 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 interface between the application and transport layers is dened by something called socket, which will be explained in section 5.4.
5.3.2
Transport layer
The transport layer is responsible for transferring data from one application to its remote peer. There is support for multiple applications to use the layer simultaneously. The most used transport protocol are Transmission Control Protocol (TCP) which provides reliable 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. Internet Protocol (IP) is the most important protocol in this layer. IP does not provide reliability or error recovery, this is up to higher layers to handle. Other network layer protocols are 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 interface available, which illustrates the exibility of the Network layer.
5.4
Socket
As the network layer provides a host-to-host delivery service, there must be possible to direct data to a certain process running on its host. This process-to-process service is accomplished with ports and sockets. A socket can be seen as a door to the process. When data is to be received or to be sent, a socket has to be used. As stated earlier, the socket is within the transport layer and provides an interface to the application layer. This section will explain how this process-to-process service is accomplished. 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 the correct application process. Port are usually divided into two types: well-known ports and ephemeral ports. The well-known range from 1 to 1023, and are used for certain server 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 nd servers without conguration 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 the host-to-host delivery service. When a segment (a packet of data) arrives, the header is examined. The header provides information about what protocol the packet belongs to as well as destination port number. With this information the correct socket can be found, and thereby the correct process. The job of examining the header and deliver the segment to the correct socket is called demultiplexing. The job of gathering data from a socket, encapsulating it into a segment with header information and sent it to the network layer is called multiplexing.
30
Chapter 5. TCP/IP
5.5
5.5.1
Network Layer Protocols

Internet Protocol (IP)
The Internet Protocol (IP) was designed 1981 to be used in interconnected systems of packet-switched computer communication networks. IP provides a format for transmitting blocks of data (datagram) from sources to destinations. These sources and destinations are called hosts and are identied with an IP address. A network consists usually of a number of hosts connected to each other through a router. A host sends a packet over a link, this link can be physical like cable but also wireless. The boundary between the link and the host is called an interface. A host is normally connected to a single link while a router is connected to several. A routers job is to receive datagram from one link and pass it on to another link. An IP address is bound to a interface which means that a router needs multiple IP addresses, one for each interface. Figure 5.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 [RFC 791], ow control, sequencing etc. All such functionality is left for higher level protocol to implement. The only error detection mechanism is a checksum control for the IP header. If the checksum procedure fails the datagram will be discarded and will not be delivered to a higher level protocol. The main functions of the IP is addressing and packet 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 trac is still done with IPv4 addressing. In IPv4, each address is 32 bits long which means there are 232 unique addresses. That is about 4 billions. It may seem alot but in a world with 6 billion people the addresses are soon used up. The addresses are typically written in dotted-decimal notation like 192.168.0.3, the same address in binary notation would be: 11000000 10101000 00000000 00000011
5.5. Network Layer Protocols
31
Class A B C
Prex 0 10 110
Range 1.0.0.0 - 127.255.255.255 128.0.0.0 - 191.255.255.255 192.0.0.0 - 223.255.255.255
Networks 27 214 221
Hosts 224 216 28
Table 5.1: Address classes in IPv4 Four classes of addresses were dened in the original IPv4, also an additional fth class was reserved for future use. The fourth class, dedicated for so called multicast addressing, is no longer considered a formal part of IPv4 addressing. The rst bits of 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 network would not sucient, 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 of class B addresses. The solution to this problem was Classless Interdomain Routing (CIDR) and was standardized 1993 by the Internet Engineering Task Force (IETF). Instead of using the 8, 16 or 24 rst bits of the address for network portion, any number could be used. For the example above the organization could use the rst 21 bits for the network address, and the remaining 11 bits for hosts. This would lead to 2048 (211 ) possible host addresses within the organizations network. Another benet with CIDR is that it makes subnetting possible. By dividing the the 11 rightmost bits the organization above could create own subnetworks within its network. In the beginning of the 1990s people realized that the 32 bit address space in IPv4 would not be enough. Therefore began the Internet Engineering Task Force to develop a successor to the IPv4 protocol. In the new standard IPv6, the 32 bit address space has been increased to 128 bit. With such address space every grain of sand on the planet could have a unique IP address.
5.5.3
Fragmentation
Fragmentation and defragmentation is the other main task of IPv4. It is necessary because not all link-layer protocols can carry packets of same size. Ethernet packets can not carry more than 1500 bytes [8] of data, while many wide-area links has a packet limit of 576 bytes. The maximum packet size a link can carry is called Maximum Transfer Unit (MTU). A router can have dierent link interfaces, and that is why fragmentation of packets is primarily done in routers. To spare routers the burden of also reassembling packets the designers of IPv4 decided to let the hosts take care of that. Still fragmentation reduces performance in a router and it is desirable to keep fragmentation to a minimum. Because of all link layer protocols supported by IPv4 should have a MTU of at least 576 bytes, fragmentation can be entirely eliminated if all IP packets are less than 576 bytes in size. This can be controlled by setting Maximum Segment Size (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 example HTTP packets are often 512 - 536 bytes long. In IPv6 fragmentation is completely removed. If a router in IPv6 receives a packet that is too large to be forwarded over the outgoing link, the router simply discards the packet and noties the sender through a
32
Chapter 5. TCP/IP
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 that every node connected to the LAN will receive the frame. But most of the times a node just wants to communicate with one particular node in the LAN. To manage this, every node must have a unique LAN address. This address is also known as Medium Access Control (MAC) address or physical address. These MAC addresses are bound to a specic 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. To transmit 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 physical address, there is a need to translate between them. This task is solved by the Address Resolution 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 MAC address of that computer. Figure 5.3 shows a network of three computers connected through a hub. Imagine that the computer with address 192.168.0.17 wants to send a packet to node 192.168.0.11, it will then check its ARP table. IP Address 192.168.0.11 MAC Address ED-66-AB-90-75-B1 TTL 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 the address 192.168.0.11 has a valid translation in the table and Ethernet packet can be sent 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 will not nd a valid translation. At this moment an ARP-request packet must be sent. This packet is sent to the LAN broadcast address FF-FF-FF-FF-FF-FF and contains the IP address of the target machine which in this case is 192.168.03. All computers in LAN will receive this ARP-Request, and each of them compare its local IP address with the target IP address in the ARP-packet. The node with a match will respond with an ARP-Reply packet, containing the desired address mapping, back to the sender. The querying node (192.168.0.17) will then update its ARP-table and send the IP datagram.
34
Chapter 5. TCP/IP
5.5.6
Internet Control Message Protocol (ICMP)
The Internet Control Message Protocol (ICMP) is often considered as a part of the IP although it lies above IP, as ICMP packets are carried inside IP packets, just like TCP and UDP packets. The purpose of ICMP is provide feedback about problems in the network communication. A typical example is the Destination network unreachable which is sent by a IP router if it was unable to nd a path to the destination host. There are a numerous dierent 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 type 8 with code 0. ICMP Type 0 3 3 3 3 3 3 4 8 9 10 11 12 Code 0 0 1 2 3 6 7 0 0 0 0 0 0 Description Echo reply (pong) Destination network unreachable Destination host unreachable Destination protocol unreachable Destination port unreachable Destination network unknown Destination host unknown Source quench (congesting control) Echo request (ping) Router advertisement Router discovery TTL expired IP header bad
Table 5.3: ICMP message types
5.6. Transport Layer Protocols
35
5.6
5.6.1
Transport Layer Protocols

Transmission Control Protocol (TCP)
TCP is a connection-oriented protocol which provides features like ow-control, congestion control and reliability. It relies on many principles including error detection, retransmissions, timers and header elds for sequence and acknowledgment numbers. A TCP connection provides full-duplex data transfer, which means that two connected processes can send data to each other simultaneously. Multicasting is not possible with TCP, the connection is always point-to-point. Before data can be sent between two TCP connections, an initial handshake must be completed. How this is accomplished will be explained later in this section. When the connection is established the two processes can start transferring data to each other. TCP guaranties that all data is delivered in order, without gaps and without errors. TCP also makes sure that router buers along the way does not get congested. Yet another feature that TCP supports is ow control, which protects against overowing the remote hosts internal buers. This section will explain the most important features of this transport protocol. Figure 5.4 illustrates how 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
36
Chapter 5. TCP/IP
Sequence and acknowledgment numbers Two of the most important elds of the TCP header are the sequence- and acknowledgmentnumber elds. They are used to provide TCPs reliable data transfer service. To understand how this works, the meaning of these elds will rst be explained. TCP views data as an ordered stream of bytes. Each byte of the data-stream is assigned a sequence number. When a segment is received, the sequence-number eld displays the byte-stream number of the rst byte in the segment. The acknowledgment-number eld indicate what sequence number is expected from the peer process. How these numbers are used to provide reliable data transfers is illustrated in gure 5.5.
Figure 5.5: Example of sequence and acknowledgment numbers
Figure 5.5 shows a simplied data transmission. The arrows represent how segments are sent between the two processes. The sequence-number eld of the segment is labeled Seq and the acknowledgment-number eld is labeled Ack. The label length indicates how many bytes of data the segment contains. 1. Process A sends a segment with three bytes of data. The sequence number for the rst byte of this segment is zero (Seq 0). The acknowledgment eld is also zero, indicating that process A expects a segment with sequence number zero from process B. 2. Process B answers with an acknowledgment eld set to three, which states that next expected sequence number from process A is three. This also means that all bytes up to sequence number two are received. 3. Process A sends a second data segment containing seven bytes, starting at sequence number three. The received segment from process B did not contain any data, thus next expected sequence number from process B is still zero (Ack 0). 4. Process B acknowledges the received segment which informs process A that next sequence number to send is ten.
37
Connection establishment TCP requires an initial connection process before data can be sent or received. This connection process is often called a three way handshake, because the connection establishment demands three segments to be passed between the two TCP sockets. During the connection-process the necessary state-variables are initiated. Both sides need to know what Initial Sequence Number (ISN) the remote hosts data stream starts at. 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 rst sends something called a SYN segment to the server. This segment is a connection-request and is called SYN segment because the SYN ag in the header is set to one. The sequence number eld is set to the clients ISN, which is randomly selected by the client. If the server accepts the connection request, a reply is sent called a SYN-ACK segment. This segment contains the servers ISN placed in the sequence number eld, and has its SYN ag set to 1. It also acknowledges the clients connection-request with acknowledgment number eld set to client isn + 1. A SYN-segment does not contain any data but counts as a segment of length 1, and this is the reason for setting the acknowledgment eld to client isn + 1. The nal step of the three way handshake is for the client to acknowledge the servers ISN.
In addition to initialization of ISN, some other options can be agreed upon. These options resides in the header-eld of the same name, and can only be present in the initial SYN segment. The most important and most used option is Maximum Segment Size (MSS), which informs the remote TCP socket how much data a segment is allowed to contain. For an embedded system with limited memory resources the MSS option
38
Chapter 5. TCP/IP
makes it possible to limit the size of the receive-buer used by TCP. MSS is also used to avoid fragmentation within routers along the path between sender and receiver. When this 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 are sending data at high rate, router buers are sometimes overowed and begins to drop segments. Congestion Control is used to throttle the send-rate when network congestion is discovered.
Flow Control TCP also uses a mechanism to avoid overowing receive-buers. A TCP socket keeps track of how much available buer-space the remote host has for receiving data. The window eld in the TCP header announces this information.
39
5.6.2
User Datagram Protocol (UDP)
UDP is dened in RFC 768, and is a very thin transport protocol. It does not provide features like ow-control, congestion control or error recovery. It is basically an application interface to IP, and just handles multiplexing/demultiplexing (explained in section 5.4) and some light error checking. There is no initial handshaking procedure, as there is with TCP, and therefore UDP is said to be connectionless. There are however some benets with the UDP protocol, which are explained below: It has very little packet overhead, only eight bytes compared to twenty bytes for TCP. 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 dataloss. Many multimedia applications use UDP because they do not work well with TCPs congestion control due to the delays it causes. Figure 5.7 illustrates the format of the UDP header. Source and destination port are used for multiplexing/demultiplexing. The length eld species the length of the UDP segment including the header, in bytes. For UDP to calculate the checksum, a few elds in the IP header is used in addition to the 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
40
Chapter 5. TCP/IP
5.7
5.7.1
Application Layer Protocols

File Transfer Protocol (FTP)
The FTP (File Transfer Protocol) is a commonly used protocol of exchanging les over any network that supports the TCP/IP protocol. The protocol relies upon TCP, with a server on one side and a client on the other. Two TCP-connections are used in a normal FTP-session: Control Connection Used for sending control information between the server and the client, information such as user identication, password and commands like change remote directory, get le, put le, etc. Data Connection Used for le transferring and le lists of the remote directory. A user starts an FTP session by initiating a TCP connection to port 21 (standard port) at a server. The client then sends user identication and password and the FTP control connection is established. When a server receives a le transfer request over the control connection, it initiates a TCP data connection to the client side. The le will be transferred, either from server to client or from client to server, over the data connection. The data connection will be closed as soon the le transmission i completed. Thus, the control connection remains open throughout the duration of the FTP session while the data connection is created and closed for each le transfer. Commands and replies, that are sent over the control connection, are text coded in seven-bit ASCII-format. Each command consists of four uppercase ASCI characters, some with optional arguments. Some common commands are given below: USER username Sends the user identication to server. PASS password Sends the user password to server. PORT address and port Informs the server to where it should initiate next data connection. LIST Request the le list of current remote directory. RETR filename Initiate a le transfer from server to client. STOR filename Initiate a le transfer from client to server. Each command issued at client side is followed by a reply from the server. The reply messages consists of a three-digit number followed by an optional message. More details about 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 consisted of 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 x 53 mm. The most central part of phyCore-XC167 is the microcontroller XC167CI from Infenion 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 the external Flash, RAM and SRAM. The access to these components is easy because they are mapped into the microcontrollers address space. A memory access to the external memory areas (see Figure 6.3) of the microcontroller will therefore use the external bus and 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 controller. It is clearly a better and more elegant way to let the Ethernet controller interrupt the host CPU than have some kind of polling solution. To make it possible for the Ethernet controller to interrupt a jumper needs to be closed. This jumper connects the IRQ output from the Ethernet controller to the pin P2.13 of the microcontroller. This jumper is marked in Figure 6.2 and is the only modication of the hardware that must be done.
Figure 6.2: Modication 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 short summary of XC167CIs 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 congured in a Von Neumann architecture, which means that all internal and external resources, such as code memory, data memory, registers, and I/O ports are organized within the same linear address space. This common memory 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 memory space is organized is presented in gure 6.3.
44
Chapter 6. Hardware
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 Program Memory (Flash Memory). The PSRAM is provided to store user code or data and is accessed via the Program Management Unit (PMU), as gure 6.4 illustrates. PMU is responsible for all code fetching and therefore also accesses the Flash Memory which stores code or constant data. The DSRAM are provided as a storage for general user data and is accessed via the Data Management Unit (DMU). DPRAM is provided as a storage for user dened 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 of external RAM and/or ROM can be connected to the microcontroller.
6.3. Ethernet Controller Cirrus Logic CS8900A
45
Figure 6.4: Overview of XC167CIs on-chip components
6.3
Ethernet Controller Cirrus Logic CS8900A
Phytec phyCore-XC167 is equipped with the Ethernet controller CS8900A from Cirrus logic. The controller has a direct ISA-bus interface, an 802.3 MAC engine, 4 KB integrated RAM and a serial EEPROM interface. Its architecture is based on an ecient method of accessing internal registers and buer memory known as Packet Page. The 4 KB RAM, known as the Packet Page memory, is used for internal registers and temporary storage of Ethernet frames. Table 6.1 shows the organization of the accessable portion of Packet Page memory. Packet Page Address 0000h - 0045h 0100h - 013Fh 0140h - 014Fh 0150h - 015Dh 0400h 0A00h Contents Bus Interface Registers Status and Control Registers Initiate Transmit Registers Address Filter Registers Receive Frame Location Transmit Frame Location
Table 6.1: Memory organization in CS8900A The access to this memory is either done in Direct Memory Access (DMA) or through I/O space operations. Access via DMA is slightly faster but the manufacturer recom-
46
Chapter 6. Hardware
mends to use I/O mode in order to get a cleaner driver design. In I/O mode the Packet Page memory is accessed through eight 16-bit I/O ports that are mapped into sixteen contiguous I/O locations in the host systems I/O space. The default value of the I/O base address for CS8900A is set to 300h (300h is typically assigned to LAN peripherals). Table 6.2 shows the mapping. Oset 0000h 0002h 0004h 0006h 0008h 000Ah 000Ch 000Eh Type Read/Write Read/Write Read/Write Read/Write Read/Write Read/Write Read/Write Read/Write Description Receive/Transmit Data Receive/Transmit Data TxCMD (Transmit Command) TxLength (Transmit Length) Interrupt Status Queue Packet Page Pointer Packet Page Data 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 rst be written to Packet page Pointer port (000Ah). The content of the register can then be read from the Packet Page data port (000Ch). The interested reader can nd more details 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 built in a layered structure, also called a stack, with a well dened interface between each layer. This way all protocol specic tasks are isolated in each layer. It also makes it easy to add additional functions or to replace a layer. The layered structure and its dierent layers are illustrated in Figure 7.1. The description will be done in a top-down approach and start with applications above the stack. First the Telnet- and FTPserver implementation will be described, then each layer down to the HAL. Concepts and terms in this section have been explained, or at least brought up, in the previous TCP/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 understand how 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 input/output. It also parses commands directly from a user via command line and then executes them. In fact, the monitor also acts as a shell where it can execute built in commands. The monitor can use dierent interfaces to the user depending what is suitable. If the VCS-Node is simulated on a Windows machine it uses the standard I/O calls from C (printf, putchar etc.) When VCS is running on a microcontroller, a Serialor a CAN-interface provides the standard I/O for the user. The Telnet-server provides an additional way of interacting with the VCS-Node. The whole process of managing input data and forward outgoing data to the correct interface is pretty simple. At rst there is a Red Thread periodically checking for new input data of each interface. If there is data at some interface, a Blue Thread will be signaled to handle the data. The Blue Thread will check which interface that has new input data and chooses that interface to be active. Then the Blue thread will process each incoming character one-by-one and present the result to the active interface. This is roughly how the Monitor inside VCS Core works.
7.2.1
Negotiation
Directly after the TCP-Connection between the Telnet-client and the Telnet-server has been established, a negotiation must take place. In the negotiation, dierent settings for the Telnet-session is determined. Since the Monitor inside VCS Core had support for VT100 it became straight forward to let the Telnet-server oer the VT100 standard as virtual terminal. The Telnet-server is also responsible for echoing characters from the user. In other words, the input character from the client will rst be sent to server and then back to client. The alternative would be to have local echo at the client, and rst when the user hits Enter the whole line would be sent (linemode). By letting the server echo it is possible to respond to single keystrokes from the user, like presenting command 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 nished the telnet session can start. All outgoing characters from the Monitor are buered until the buer is full or when the ush routine is called. By buering outgoing characters it will be more ecient and faster to send whole lines, instead of always sending one character at a time over the network. When echoing characters from the client, a consecutive ush call must be done to force the server to send the character.
7.2.2
Interface
The Telnet-server provides an interface for the Monitor-module in VCS Core to be able to 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 buer that have not been read.
TEXT Telnet_ReadChar( void )
Returns next character from buer.

u16 Telnet_SendChar( TEXT character )
The character will be buered and not sent over the connection until the buer is full or until the Telnet Flush routine is called.
u16 Telnet_Flush( void )
Forces the Telnet-server to send all data in the send buer.
50
7.3
FTP Server
The implemented FTP-server will, as the Telnet-server, not allow multiple clients to be connected at the same time. In dierence to Telnet, FTP uses two dierent connections. One control connection and one data connection. The control connection is where the FTP-commands are sent, and the data connection is opened for example when a le transfer 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 les. RETR - Retrieve a remote le. QUIT - Terminate connection.
7.4. Socket
51
7.4
Socket
The implemented VCS socket-API supports the transportprotocols TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). When an application shall use UDP or TCP to send data to a remote host, a socket is used. The gure to the right shows how the socket-layer is at the very top of the TCP/IP stack and can be seen as an interface between the application and the TCP/IP-stack. A socket can be compared to a pipe in functional aspects where, for example, the local application put data into one end of the pipe and the remote application extract data on the other end. The most important responsibilities for the socket-layer are multiplexing/demultiplexing and translating generic socket-layer functions to specic protocol functions. Multiplexing and demultiplexing provides a process-to-process service. This means that the socket layer is responsible for directing an incoming segment to the correct application, as well as providing header information for outgoing segments. A socket has a data-structure called str socket which holds information needed to manage a connection. This structure keeps track of several state variables needed by its underlying transport-protocol. Most variables only concern TCP, because it is far more complex than UDP and therefore needs more connection-status information. Some of the most important components of the str socket structure are explained below. flags The ags holds information about a connection, such as if the connection is currently sending data or a timeout occurred etc. prot state This is used by the TCP protocol to manage the TCP state machine, which is explained further in section 7.5. inet opt The inet opt structure holds local and remote address information (IP address and 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 specic protocol functions. When a socket is created the socket-structure is initialized to support the protocol that shall be used. The most important member of the socket-structure is the ops structure, which maps the socket API function-calls to protocol specic functions. The ops structure also maps protocol specic initialization and destroy functions, which are needed to initiate and destroy the protocols control-block. The socket API is implemented to resemble C-sockets. There are however some differences in how some functions behave. The most important dierence is that vcs sockets only support blocking send- and receive-functions. Some API functionality is only used for TCP sockets. UDP is said to be connectionless which means that an UDP socket does not have to establish a connection before sending or receiving data. API functions
52
vcs listen, vcs accept and vcs connect are therefore of no use for UDP sockets, and will always return -1. The VCS socket API is listed below. More information about using 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 specied socket. vcs recv Receives data. vcs recvfrom Receives data from a specied socket. vcs close Closes a connection.
7.5. TCP
53
7.5
TCP
The Transmission Control Protocol (TCP) provides reliable data transfer. It relies on many principles including error detection, retransmissions, timers and header elds for sequence- and acknowledgment-numbers. TCP is connection-oriented which means that before two processes can send data to each other, an initial handshake between them must be performed. This means that the two processes must exchange messages to setup and initialize several TCP state variables to handle the connection. This section will explain how these state variables are updated, how buers are handled and other areas regarding the TCP implementation of this project. The principle behind TCP is more thoroughly explained in section 5.6.1, this section is suited for readers familiar with TCP.
7.5.1
Data structures
A TCP connection must keep a lot of state variables updated. Some TCP control variables are kept in its corresponding socket-structure. The rest of the connection status variables are stored in a TCP Control Block. Because dynamic memory was not allowed in this project, the control-block structures must be allocated at compile time. If there is N available sockets in the TCP/IP stack, there must be N TCP Control Blocks allocated. Even if some sockets are meant to use UDP as transport-protocol, it must be possible to use all sockets as TCP sockets. There is also another structure used by TCP that stores information about the last received packet. This information is parsed and calculated from an incoming segments header. There is only one instance of this structure because the TCP/IP stack only handles one segment at the time.
7.5.2
Buers
The TCP layer has two buers allocated which are used when constructing outgoing packets. One is used for storing control-packets, and the other for storing packets containing data. To save memory these buers are available for all TCP sockets. When several TCP connections are sending and receiving data at the same time, they will need to use these buers simultaneously. Therefore the buers are locked with a spinlock to prevent disturbances. It would be possible using only one of the buers to store both data and control packets but the size of the control buer is only 56 bytes and 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 buer when constructing a packet. This space is for storing the IP- and Ethernet-header, which is lled in by the IP- and Queue-layer later on. Figure 7.2 shows the structure of the data-packet buer. The shaded eld indicates where header eld and data are copied into the buer. The data eld is of length Maximum Segment Size (MSS) meaning the maximum number of bytes of data a TCP packet can contain. This MSS value can be congured at compile time and
54
regulates how big buer TCP shall use for data packets. If Maximum segment size is small the performance will suer because it requires sending more packets, but it is a balance between memory demands and performance.
Figure 7.2: Data buer 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 of states 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 connection request. SYN-RECEIVED Represents waiting for a conrming connection request acknowledgment after having both received and sent a connection request. ESTABLISHED Represents an open connection, data received can be delivered to the user. The normal state for the data transfer phase of the connection. FIN-WAIT-1 Represents waiting for a connection termination request from the remote TCP, or an 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 the remote TCP. LAST-ACK Represents waiting for an acknowledgment of the connection termination request previously sent to the remote TCP. TIME-WAIT Represents waiting for enough time to pass to be sure the remote TCP received the 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 events are the user calls, the incoming segments and timeouts. The states and what events causes the connection to progress is dened in RFC 793.
7.5.4
Establishing a connection
If an application shall send or receive data on a TCP socket, the socket must rst have an established connection with the remote socket. This can be accomplished in two ways, either connect to a listening socket or accept a connection-request. If the local socket shall connect to a listening socket, a local port must be associated with the created socket. If the socket is not bound to a port by its application, it will automatically be bound to a randomly selected port before the handshaking procedure begins. This behavior is useful when implementing socket applications. The behavior when a socket shall accept a connection can be a bit confusing. To save memory and keep the TCP implementation simple there is no queue for incoming connection-requests. This results in rejection of all incoming connection-requests even though the socket is listening for connections. Not until the application calls vcs accept a connection-request can be handled. The reason for having a listening state 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 calls the send function), the receive-thread and the timer-thread. The application-thread divides the data into packets, adds the TCP header-eld and sends the data. The receive-thread handles acknowledgments for sent packets and the timer-thread handles retransmissions of lost segments. The application-thread is used during the whole send process which causes the send function to block until all data is sent. Figure 7.3 illustrates how the send algorithm, which is performed by the application-thread, is working.
56
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-variables and therefore needs to be synchronized. When the receive-thread is processing an acknowledgment it can not change involved state-variables directly, because it may disturb the application-thread. These changes can only be performed in a certain stage of the send-algorithm. As a solution the receive-thread saves these changes in temporal variables and sets a ag that indicates which variable has been changed. When the variables are 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 socket can only send a certain amount of unacknowledged data on the link before waiting to get the data acknowledged. How much unacknowledged data the socket is allowed to send is decided by the congestion control algorithm. When the limit of unacknowledged data is sent, the application thread has to wait before the send procedure con continue. If a packet is acknowledged, the receive-thread signals the application-thread who continues to send data. If a timeout on a packet occur, the timer-thread signals the applicationthread so the packet can be sent again. The list below will explain each step in gure 7.3 for a better understanding of the send-algorithm. Decision x is marked Dx in gure 7.3. Decision 1 For the socket to be allowed to send data it has to have an established connection with a remote socket. One other demand is that the socket is not already sending data via another application-thread. Decision 2 As stated earlier the receive-thread and the application-thread needs to be synchronized. At this stage of the algorithm the application-thread checks to see if there has been any changes of the state variables. Possible changes are received acknowledgments for sent packets, triple duplicate acknowledgments for the same packet 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 nished. The last sent segment needs to be acknowledged before the function terminates. Decision 5 Because of TCPs congestion control, the amount of sent unacknowledged data must be checked before sending a packet. If there is too much data out, the application-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 receiving more data. If the peer socket does not accept any data the algorithm sleeps for 5 seconds. Then one byte of data is sent. In the acknowledgment for this one byte data-packet the send-algorithm can see if the send-window increased. If the peer socket has a window larger than zero, a packet is send. Blocking send functions combined with delayed acknowledgments can cause send performance to suer in certain situations. Delayed acknowledgments are used to decrease network-trac, and most TCP implementations supports this technique. As data
58
is received by TCP on a particular connection, it sends an acknowledgment back only if 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-acknowledgmenttimer expires. The problem arises when small amounts of data shall be sent. If the entire sendprocedure only requires to send one segment, the send-function will block until that segment is acknowledged. The acknowledgment will not arrive until the delayed-acknowledgmenttimer expires, which is typically 200 ms. This implementation solves the problem by splitting the segment in half, and thereby receiving an acknowledgment on the second segment without any delay. This feature is active if the SPLIT-ag is present when calling 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 rst decision, D1 in gure 7.4, a few requirements on the socket is checked before state variables can be initiated. First a socket has to have an established connection. Second the socket can not be currently receiving data. At decision 2 the advertised window is checked. This value shall indicate how much available buer space for incoming segments there are. Most implementations has a temporal buer to store incoming segments. When receive is called the received data is copied from this temporal buer into the buer allocated by the application. To save memory there is no temporal buer in this implementation thus the receive-window is set to zero. Received segments are copied directly to the buer provided by the application. Buer-space is therefore only available when vcs recv is called. To avoid delays, an ac-
60
knowledgment is sent when there is buer-space to advertise the new window size. When these 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 is passed to the TCP-layer from the IP-layer. This ow chart is a bit simplied to get a better overview. But if a data packet arrives without any additional ags and the socket is not currently sending data, this gure basically illustrates how the receivethread works. Decision x is marked Dx in gure 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 address involves both ip-address and port. Decision 2 The checksum is calculated to detect errors. The checksum calculation requires a pseudo-header-eld to verify a packet correctly. If the checksum is correct the structure containing information about the last received segment is built via information from the segments header. Decision 3 A packet must be within the receive window with an expected sequence number to be accepted. If the packet pass this test the data is copied into the applicationbuer and state variables are updated accordingly. A packet received out-of-order is discarded. Decision 4 The receive procedure can be completed in two ways, if errors and presence of the reset-ag are excluded. The rst is simply that all data, required by the application, is received. The other way is that the push ag is set. This also terminates the receive procedure and all data received up to this point is delivered to the application. In both cases the application-thread is signaled which causes the receive function to terminate. Decision 5 This implementation supports delayed acknowledgments, but it can be disabled at compile-time. If delayed ack is inactive, an acknowledgment is sent immediately. Decision 6 To save network trac data-packets are not acknowledged directly. If an acknowledgment is delayed there are three scenarios to send it later. The rst is if delayed-acknowledgment-timer expires which causes the timer-thread to send an acknowledgment. Second is if the socket is sending data at the same time and piggybacks the acknowledgment on a data-packet. The last scenario is that a data-packet arrives when an acknowledgment already is delayed, which causes the algorithm 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 segment is 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 called Go-Back-N, where N stands for amount of unacknowledged data the send-algorithm is allowed to send. An alternative would be trying to ll the gap by just sending the lost segment, but Go-Back-N was chosen to keep the send algorithm as simple and straight forward as possible. The length of the timeout interval is calculated according to the algorithm described in [8].
7.5.8
Congestion control
To avoid overowing of router-buers, the send-algorithm needs a mechanism to regulate its send-rate. The congestion-algorithm calculates a congestion window which controls
62
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 states are: SLOWSTART INIT CONGESTION AVOID SLOWSTART When a TCP connection begins in SLOWSTART INIT state, the value of congestion window is initialized one MSS (Maximum Segment Size), resulting in an initial sending rate of roughly MSS/RTT (Round Trip Time). Because the available bandwidth probably is much larger than MSS/RTT it would not be a good idea to increase the sending rate linearly. Instead the rate is increased exponentially until a packet loss occur. The TCP connection discovers a packet loss in one of two ways. Either a sent segment gets a timeout or triple duplicate acknowledgments are received. A duplicate acknowledgment is an ack that reacknowledges a segment for which the sender already received an earlier acknowledgment. When a segment loss occur, the congestion window is cut in half. After this initial phase the state changes to CONGESTION AVOID. In this state the congestion window increases by one MSS every time a segment is acknowledged, that is every RTT. If triple duplicate acknowledgments are received, the congestion window is cut in half and the new value of congestion window is saved in a variable called threshold. This variable determines the window size at which slow start will end, and congestion avoidance will begin. The variable threshold is initially set to a large value so that it has no initial eect. When the threshold is saved the algorithm stays in the same state. If a timeout occur the following happens: threshold gets the value of congestion window , 2 the size of the congestion window is set to one MSS and the state changes to SLOWSTART. In state SLOWSTART, the size of the congestion window increases exponentially. If either a timeout occur or triple duplicate acknowledgments is received, the size of the congestion window is set to one MSS. But if the congestion window size reaches the 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. There is no ow- or congestion-control thus as soon as an application passes data to UDP, the data will be packaged into a segment and immediately passed to the IP-layer. There is no initial handshake, as with TCP, thus UDP does not introduce any delay to establish a connection. UDP is not a reliable transport-protocol so there is no guarantee for sent data to be delivered. There is very little overhead, only 8 byte header compared to 20 bytes for TCP. One problem arise when data shall be received. There is no way, as it is with TCP, to control how large segments the remote UDP socket sends. This means that the queue-layer must have buerspace available for receiving potentially large segments, which is not preferred in an embedded system like this.
64
7.7
IP layer
The IP layer is central to the TCP/IP stack. Although it is central it can be designed to be simplistic. First of all the IP layer was designed to only support IPv4. This because IPv4 is undoubtedly used more then IPv6 today and will be in near future. And if support for IPv6 is needed further on, it can easily be added into the TCP/IP stack because of the layered design. Fragmentation is described as one of the most important task for IP layer, but with support of fragmentation some problems immediately arise. Fragmented packets needs to be stored somewhere, and in an embedded system with limited memory resources it is not desirable to allocate big memory areas. Other problems with fragmentation is to determine how long a host should keep a fragmented packet while waiting to receive the complete packet, if for example some packet fragments were lost in the network. Fragmentation is an issue and it is no coincidence 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 fragmentation can be avoided. And small packets also suits the memory consumption for an embedded system better. No CIDR network addresses are supported in the implementation, only class C addresses of IPv4 standard are allowed. This means that the rst 24 bit of the address identies the network and the remaining 8 bit identies the host. Neither is there a forward table that allows packets to be sent to another network. The reason for why these features not are included in the solutions is that the systems running the stack will not be a part of a bigger network, and denitely not the Internet. The network will probably be limited to two hosts connected through a cross wired network cable or a couple of hosts connected through hub/switch. The only types of ICMP-messages that are implemented are ECHO-Request and ECHO-Reply. In other words, it is possible to ping a running VCS-node and also possible for 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 the packet 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 or drop the packet.
7.8. QueueLayer
65
7.8
QueueLayer
Below the IP layer and above the Hardware Abstraction Layer a QueueLayer has been inserted. The main task for the QueueLayer is to buer incoming and outgoing packet. The QueueLayer also contains an ARP module, which is responsible for address translations between IP addresses and physical (MAC) addresses. There are 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 address translation, are placed here. Because no dynamic memory allocation is allowed in VCS Core each packet queue is constructed of a 16 bits array and allocated statically at compile time. To make the packet queues memory ecient and to support arbitrary1 number of packets, all packets and its sizes are stored in one single array. This way the packet queue can hold one big or many small packets in an ecient way. The size of a packet is stored as a 16 bit integer, then the packet follows, see Figure 7.6. Dierent threads have access to the packet 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 of the synchronization problems, but not all. The green interrupt thread, which is invoked when the Ethernet controller has received a packet, can not use mutexes. Therefore synchronization is sometimes also achieved by turning o all interrupts for a short time period.
Figure 7.6: Packet queues buer organization The QueueLayer contains two blue threads for managing the queues. The purpose of the threads is to take over responsibility from the Ethernet interrupt thread and from application 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.
1 As
long as there is free space in the array
66
When an outgoing packet arrives to the QueueLayer, the packet is either placed in the WaitQueue or in the SendQueue depending on if the address translation table contains a valid translation. If there is no valid translation for the IP-address, the packet is placed in the WaitQueue until there is a valid translation. When there is a valid translation the packet is placed in the SendQueue and a signal is sent to the SendThread. The SendThread will then pass the packet to the HAL. Figure 7.7 illustrates the sending process.
Figure 7.7: Application-Thread When an interrupt occurs, the Ethernet ISR is invoked and copies the packet from the Ethernet controller directly into the rear of the ReceiveQueue. Then it signals the ReceiveThread inside the QueueLayer. The ReceiveThread will then process the packet when time is given. In this approach the interrupt thread will have a short and specic task, which is desirable. How the ReceiveThread functions is described in Figure 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 a physical (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 ve minutes, than it must be renewed. This mechanism is desirable to have because the network may change. If there is no valid translation for a wanted IP-address, an ARP-request will be broadcasted over the network. The implementation follows the standard described in RFC 828 but is restricted to only support translation between IPv4 address and 6 bytes Ethernet addresses. The standard ARP-protocol is designed to support translation between dierent network addresses and
68
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 HAL layer itself can be divided into two parts. One part consists of routines controlling the Ethernet Controller, in this case CS8900A from Cirrus Logic. The other part, which is described in Appendix C, a provides clean and simple access methods for higher layers. Therefore if another Ethernet controller would be used in the future it is only necessary to replace the HAL layer with a new HAL that implements the same access methods.
70
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 Reection FTP and the inbuilt text based FTP-client in Windows XP. The implemented FTP-server works ne with previous mentioned clients but there are some problems with other clients. Both the Telnet- and FTP-server are limited to handle one client at a time. The IP-layer in the system is very simple, functions as fragmentation and routing are completely removed. Support for fragmented packets will probably not be necessary but maybe some kind of routing mechanism would be nice to have in the future. The functions 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 interrupt thread now copies the packet into the ReceiveQueue. A better way would be to make it possible to register a receive handler function in the HAL that the Ethernet ISR will call 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 no buer so the packet is copied directly into the ReceiveQueue in the QueueLayer from the Ethernet controller. When a packet is received, the interrupt routine requests for buer space from the QueueLayer. A similar approach is considerable in the other direction. Instead of having a transmit buer in the TCP-layer, the TCP-layer could request memory space from the QueueLayer. With such approach the packets do not have to be copied from the TCP-buer into the SendQueue and some performance will be gained. On top of the TCP/IP-stack numerous applications could be considered to implement. (Dynamic Host Conguration Protocol) DHCP that allows IP-addresses to be handed out by a server instead of having them statically dened. A simple web-server, that allows user to surf in and see system status and maybe download log-les, is also a thought.
71
72
Chapter 8. Conclusions
Chapter 9
Acknowledgments
First of all, we would like to thank BAE Systems Hgglunds for a great time in Ornskldsvik a o and for giving us the opportunity to do this project. The work has been very stimulating and 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 Hgglunds, Jimmy Westerlund, for his support a while doing the project. Lastly, we also want to thank Jan-Erik Mostrm at Ume o a University 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. jsp. http://java.sun.com/javase/technologies/realtime.
[3] The Motor Industry Software Reliability Association. http://www.misra.org.uk/. [4] Par Jdly Ariane. A.an 501 Inquiry Board report. [5] Ford Motor Company Chrysler Corporation and General Motors Corporation. QS 9000: Quality System Requirements. 1995. [6] Bruce Powel Douglass. Safety-Critical Systems Design. 1998. [7] Charles Antony Richard Hoare. 24(2):7583, 1981. The emperors old clothes. Commun. ACM,
[8] Keith W. Ross James F. Kurose. Computer Networking: A Top-Down Approach Featuring the Internet. Addison Wesley, 2003. [9] Peter H Jesty and Ian Kendall (Jaguar Cars Ltd) Keith M Hobley (University of Leeds), Richard Evans (Rover Group Ltd). Safety Analysis of Vehicle-Based Systems. 2000. [10] John C. Knight. Safety critical systems: challenges and directions. In ICSE 02: Proceedings of the 24th International Conference on Software Engineering, pages 547550, New York, NY, USA, 2002. ACM Press. [11] Nancy Leveson. Medical Devices: The Therac-25. Technical report, University of Washington. [12] Nancy G. Leveson. Software safety in embedded computer systems. Commun. ACM, 34(2):3446, 1991. [13] Roger S. Rivett (Rover Group Ltd). Emerging Software Best Practice and how to be Compliant. 1997. [14] Keith M Hobley (The University of Leeds) Ian Kendall (Rolls-Royce & Bentley Motor Cars Limited) Michael Ellims (Pi Technology), Richard Evans (Jaguar Cars Limited). When is Software Ready for Production? Parallels with Automotive QS9000 Methods. 2000. [15] David Lorge Parnas. Software aspects of strategic defense systems. SIGSOFT Softw. Eng. Notes, 10(5):1523, 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 Annotated Bibliography. Technical Report CMU/SEI-92-TR-5 & ESC-TR-93-182, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213, USA, June 1993. [18] Robert W. Sebesta. Concepts of Programming Languages. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2001. [19] Andrew S. Tanenbaum. Modern Operating Systems, Second Edition. Prentice Hall, 2001.
Appendix A
Abbreviations
ARP CIDR FIFO FTP HAL ICMP IETF IP ISR MAC MTU OS RTOS TCP UDP VCS VIS Address Resolution Protocol Classless InterDomain Routing First In First Out File Transfer Protocol Hardware Abstraction Layer Internet Control Message Protocol Internet Engineering Task Force Internet Protocol Ethernet Interrupt Routine Medium Access Control Maximum Transfer Unit Operating System Real-Time Operating System Transmission Control Protocol User Datagram Protocol Vehicle Control System Vehicle Information System
77
78
Chapter A. Abbreviations
Appendix B
Socket Application Programming Interface (API)

B.1 General
This is a description of the API (Application Programming Interface) for sockets in VCS Core. This section is intended for writers of applications. VCS Core have a layered architecture consisting of three major layers, the Hardware Abstraction Layer (HAL), the VCS Core layer and the application layer. The API is the interface between the Application and VCS Core. The TCP/IP stack is integrated into the VCS Core. The TCP/IP module is responsible for sending and receiving data via the ethernetcard. Available protocols for this propose are TCP and UDP. TCP represents reliable data transfer an UDP represents unreliable data transfer. Sockets provide a standard protocol-independent interface between the application-layer programs and the TCP/IP stack. The only way to use the TCP/IP stack from the applications perspective is through the socket interface.
B.2
Usage
A connection between two sockets can be created in two ways, accepting a connectionrequest 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 a reliable byte stream channel through which data ows between two end systems. UDP provides an unreliable connectionless service. Therefore only TCP sockets can connect to 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 specied, which indicates what protocol the socket shall use. For a TCP socket the type is SOCK STREAM and for a UDP socket the type 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 be created.
B.2.2
Accepting a connection
When a created TCP socket shall accept connection-requests from remote sockets, the socket must rst be bound to a unused port. This is done with the bind function. The syntax is shown below.
s16 vcs_bind( u16 sockfd, u16 port )
The rst argument, sockfd, is the descriptor of the socket to be bound and the second argument is the preferred port to bind the socket to. The socket can be bound to any unused port between 1 and 65535. This function returns the sockets descriptor or -1 if bind fails. Next the socket must be told to listen for connection-requests which is accomplished with the following function.
s16 vcs_listen( u16 sockfd )
Argument sockfd is the socket descriptor. The function returns the sockets descriptor or -1 if listen fails. When a socket is in listening-state, it discards all incoming connection-requests because there is no queue for storing these. For a connection to be established the socket must 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 a pointer 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 was successful, and the remote sockets port are stored in port. The accept function creates a new socket for the established connection. This new sockets 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 done with 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 will be chosen arbitrarily between 1024 and 65535. The syntax of connect is shown below.
s16 vcs_connect( u16 sockfd, sock_addr_t PTR *daddr )
The rst argument sockfd is the descriptor of the local socket. The second argument daddr 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 between two sockets. TCP sockets support all below listed send and receive functions, but the functions 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 and acknowledged1. 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 buer holding the data to be sent. Number of bytes to send is specied in len. Accepted flags are PUSH and SPLIT. The PUSH ag tells the remote socket to deliver (push) data to its application when len bytes are transferred. The ag SPLIT divides the rst segment to send in half. This is used to gain performance due to delayed acknowledgments, that most TCP implementations use. It is only useful when sending data that ts into one segment. The functions return number of bytes sent. The receive functions will block the calling thread until receive completes. If the sending socket is using the push function, receive completes when the remote socket is done sending. Otherwise receive completes after len bytes are transferred. The syntax of the receive functions are shown below.
1 Only
TCP require acknowledgments
82
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 buer to store the received data. Number of bytes to receive is specied 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; }
84
Appendix C
Ethernet Hardware Abstraction Layer

C.1 General
The purpose of a Hardware Abstraction Layer is do provide machine independent access to dierent hardware. It make is easier to move software between dierent machines and to use dierent hardware. This is a description of the HAL for Ethernet controllers in VCS Core. This section is intended for developers in CS Core and for developers writing Ethernet Controller drivers. It describes a interface to Ethernet Controller devices that makes it possible to access dierent Ethernet Controllers in the same way. VCS Core has a layered architecture consisting of three major layers, the Hardware Abstraction Layer (HAL), the VCS Core layer and the application layer. This describes the interface between the VCS Core and Ethernet Controllers.
Figure C.1: System structure
C.2
C.2.1
Usage
Intialize Ethernet Controller
Before any kind of communication with the Ethernet controller can be done, it must me initialized. 85
86
Chapter C. Ethernet Hardware Abstraction Layer
void HAL_Ethernet_Init( void );
This function will set up all necessary conguration registers at the Ethernet Controller.
C.2.2
Interrupts
The Ethernet controller can generate interupt the CPU when dierent event occurs, like packet reception etc.
void HAL_EthernetEnableISR( void );
This function will enable interrupt generation. After a call to this function the CPU can be interrupted by the ethernet controller. On interrupt the Interrupt Service Routine at the Ethernet controller is invoked.
void HAL_EthernetDisableISR( void );
This function disables interrupt. After a call to this function the CPU will no longer be interrupted.
C.2.3
Identifying The Ethernet Controller
Dierent Ethernet controller can be used. To be able to identify which type of Ethernet controller that is connected to the hardware this functionality has been added.
TEXT_CONST_PTR HAL_EthernetDeviceName( void );
The function returns a string that identies the Ethernet controller.
C.2.4
Link Status of Ethernet Controller
To nd 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 triggering method or a polling method. In the polling method the Ethernet controller is polled until it is not busy and then it sends the frame. In interrupt mode it tries to send the frame, but if the Ethernet controller is busy return and wait for an interrupt to be generated.
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 the packet 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 busy this function will return. An interrupt will be generated when the Ethernet controller is ready to transmit.

TCPstack Embedded System

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCPstack Embedded System

Enviado por

Direitos autorais:

Formatos disponíveis

Development of a TCP/IP stack in a real time embedded system

Stefan Jakobsson & Erik Dahlberg

B.1 System structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

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

Outline of this report

Chapter 2. Problem Description

Figure 3.2: System overview

3.1. VCS System

Figure 3.3: Inside a VCS node

The Red Kernel

Figure 3.5: Clock scheduler in the red kernel

The Blue Kernel

Figure 3.6: Legal state transitions

The Green Kernel

Rubus Visual Studio

Figure 3.8: Rubus Visual Studio

Software Development For Safety Critical Systems

Chapter 4. Software Development For Safety Critical Systems

Software failuers: What can go wrong?

4.4. What is the problem?

What is the problem?

Chapter 4. Software Development For Safety Critical Systems

4.5. Language Selection

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

Chapter 4. Software Development For Safety Critical Systems

Chapter 4. Software Development For Safety Critical Systems

Development of safety critical software

4.7. Development of safety critical software

Correctness of software based systems

Chapter 4. Software Development For Safety Critical Systems

4.7. Development of safety critical software

When is Software Ready for Production?

Chapter 4. Software Development For Safety Critical Systems

Network interface layer

Network Layer Protocols

5.5. Network Layer Protocols

Range 1.0.0.0 - 127.255.255.255 128.0.0.0 - 191.255.255.255 192.0.0.0 - 223.255.255.255

Networks 27 214 221

Hosts 224 216 28

Figure 5.2: IP header format

5.5. Network Layer Protocols

Address Resolution Protocol (ARP)

Internet Control Message Protocol (ICMP)

Table 5.3: ICMP message types

5.6. Transport Layer Protocols

Transport Layer Protocols

Figure 5.4: TCP header format

Figure 5.5: Example of sequence and acknowledgment numbers

5.6. Transport Layer Protocols

5.6. Transport Layer Protocols

User Datagram Protocol (UDP)

Figure 5.7: UDP header format

Application Layer Protocols

Figure 6.2: Modication of phyCore-XC167

6.2. Microcontroller Infenion XC167CI

Microcontroller Infenion XC167CI

6.3. Ethernet Controller Cirrus Logic CS8900A

Figure 6.4: Overview of XC167CIs on-chip components

Ethernet Controller Cirrus Logic CS8900A

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

Chapter 7. System description

7.2. Telnet Server

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