|
From: | Eric NOULARD |
Subject: | [Tsp-devel] TSP whitepaper "first edition" |
Date: | Tue, 01 Feb 2005 22:15:07 +0100 |
Hi everybody, You will find hereafter the TSP whitepaper, first Ed. feel free to spread it all around the world. Eric
The Transport Sample Protocol (TSP) white paperEric NOULARDBT Consulting & Systems Integration Software Architect address@hidden Yves DUFRENNEEADS Astrium Expert in RealTime Test Benches address@hidden TSP the Transport Sample Protocol TSP is a data sampling protocol which aims at simplifying sampling and observation of evolutionary data. Since TSP is a protocol specification, it is very easy to write other implementations with other languages. Today two implementations in C and Java for different architectures exist. And TSP is an open source project.
1. HistoryTSP was born from the collaboration of BT C & SI (formerly Syntegra) and EADS Astrium in the domain of validation tests benches for satellite assembly, integration and validation or test (AIV or AIT). Both parties worked together for years, so they can both build on firm technical experience in the domain of realtime test beds. The TSP specificication cames from the need for a efficient and versatile sample protocols which may brings a better reusability among realtime testbeds projects (not only in the satellite domain). 2. A simple designTSP is a simple protocol whose design focused on simplicity and efficiency. TSP is easy to use and has low ressource needs (most notably CPU and network bandwith). 2.1. A provider/consumer modelTSP defines relationship between providers (TSP provider) and consumers (TSP consumer) of data. A TSP data provider is very simple, it is a process defining a list of named symbols (TSP symbols) with an associated value. The name of the symbol is a text string, the associated value is evolving (pseudo)-periodically. For example a TSP provider may provide 3 symbols: Table 1. A TSP provider example
The TSP consumer may ask to any TSP provider for the list of the symbols he provides and other kind of information like its base frequency. As soon as the consumer obtained a TSP session id from a provider, he may ask the provider for receiving sample values. When both consumer and provider are informed of a valid sample configuration, the consumer ask the provider for beginning sampling, then raw data value are sent from provider to consumer side at the specified pace. At this step only necessary raw data are sent on the link, no symbol, no meta-data. 2.2. TSP communication channelsCommunication between providers and consumers use two different paths: command channel and data channel . 2.2.1. Command channel: TSP requestThe TSP command channel is the mean for consumer and provider to negotiate the sample configuration. It's an asynchronous command link which is logically unconnected . In fact between 2 asynchronous command, called TSP request, the network link between both side may have been down without any impact. Each time a TSP consumer send a TSP request to a TSP provider, the consumer receive a TSP answer from the provider specifying how the request was processed by the provider. Table 2. The TSP request
A typical TSP request sequence is following:
Current TSP implementation use ONC RPC [4] as command link interface. In fact TSP is made open (by design and current C implementation) to different kind of request handler. A forseen TSP improvement in this area is to implement several request handler kind: 2.2.2. Data channel: TSP streamThe TSP data channel is used for efficient sample data flow as soon as the consumer ask for sampling process to start (TSP_request_sample_init). The TSP sampling data flow is optimal in the sense that only the necessary raw data will flow from provider to consumer side. For example, if a consumer ask for 5 double precision symbols produced at 16Hz, the data link will contains 5x8x16 = 640 bytes/second (double precision values are stored on 8 bytes). Since both provider and consumer know what was the content of the TSP_request_sample, there is no need to transport meta-data. The data sent by the data channel are XDR [5] encoded in order to avoid byte ordering trouble between povider and consumer. XDR is used by ONC RPC [4], we may well have used CDR which is used by CORBA-GIOP [12]. Note that using other encoding for the data channel may be added to TSP very easily since TSP_request_information and TSP_request_sample contains a "requested features" bitsets with unused place which may be used to negotiate forthcoming features. The sample request dialog phase enables the TSP provider to precisely specifies to the TSP consumer before to send any sample data the exact order of the raw data it will receive. The provider describes this data sequence in the TSP_answer_sample [2], so that when the consumer read the data flow he only have to pop the data in the specified order. This minimize the work of both sides during sampling. 3. A technical experimentation platformTSP is easy to use since building a provider and/or a consumer from the TSP software library (C or Java) is simple. A sample Java consumer has been written in no more than a hundred lines, comment included. TSP is simple but its technical content is rich since TSP is meant to be a technical development and experimentation framework. The technical objectives of TSP are described hereafter. 3.1. PortabilityFrom its specification through the different implementation TSP aims at a maximum source portability, in order to be usable on a wode range of hardware platform. The portability elements of TSP are:
3.2. RobustnessTSP is using simple concept which should be autotested in the TSP SDK itself. TSP should be robust, since it is meant to be used long term running simulation (from several hours to many weeks). 3.3. EfficiencyEfficiency was a primary goal since TSP first design. Ressource requirement during sampling, are minimized in terms of network bandwith and CPU cycle on both consumer and provider side. 3.4. MaintenanceA TSP implementation must be documented in order to fullfil the TSP specifications [2]. Code documentation should should be processed automatically using a documentation extraction tool. [2] Initial industrial partners did take the road to "Open Source" in order to make TSP cross the companies frontier. Free software is a source of motivation for TSP stakeholders (developpers and other contributors). TSP is hosted at the FSF project hosting solution: Savannah 4. TSP objectivesTSP is a multi-purpose project. 4.2. Wide range of application
5. Forseen development & evolutionTSP is usable now, but there is some place for improvement and evolution which would enable more widespread use. A non-exhaustive list of tasks is shown below, each task will be discussed and assigned by the TSP registered team at Savannah. External contribution are welcomed, but the preferred way is to join the TSP Savannah registered team in order to avoid redondant development. The forseen improvement are following:
A. Contributors and helpersMany people have contributed to TSP since its conception at different level.
Bibliography[1] The TSP project at Savannah: http://savannah.nongnu.org/projects/tsp . [4] RFC 1831, RPC: Remote Procedure Call Protocol Specification, Version 2 : http://www.rfc-editor.org/rfcsearch.html . [5] RFC 1832, XDR: External Data Representation Standard: http://www.rfc-editor.org/rfcsearch.html . [6] CCSDS 102.0-B-5, Packet Telemetry : http://www.ccsds.org/all_books.html#telemetry . [7] POSIX (1003.1-1990, 1003.1b-1993, 1003.1c-1994, …: http://www.opengroup.org/austin/ . [8] Single Unix Specification version 2 or version 3 : http://www.unix-systems.org/version3/ . [9] ESA PSS-04-107 Issue 2 (April 1992): http://esapub.esrin.esa.it/pss/pss-cat1.htm. [10] Simple Object Access Protocol (SOAP) 1.1: http://www.w3.org/TR/SOAP/ . [11] XML-RPC Specification: http://www.xmlrpc.org/spec . [12] Object Management Group: http://www.omg.org/. [13] The Apache ANT Project: http://ant.apache.org/ . Notes
|
tsp_whitepaper.pdf
Description: Adobe PDF document
[Prev in Thread] | Current Thread | [Next in Thread] |