U.S. patent application number 11/869288 was filed with the patent office on 2008-10-09 for systems, methods, and apparatus of a space communication file transfer system.
This patent application is currently assigned to United States of America as represented by the Administrator of NASA. Invention is credited to Timothy J. Ray.
Application Number | 20080250118 11/869288 |
Document ID | / |
Family ID | 39827931 |
Filed Date | 2008-10-09 |
United States Patent
Application |
20080250118 |
Kind Code |
A1 |
Ray; Timothy J. |
October 9, 2008 |
SYSTEMS, METHODS, AND APPARATUS OF A SPACE COMMUNICATION FILE
TRANSFER SYSTEM
Abstract
Systems, methods and apparatus are provided through which in
some embodiments a CFDP protocol state machine and state table is
implemented on each of a number of entities in a space
communication system. Some embodiments of the state table specify
at least one action to specific events for each of a plurality of
possible states and each state table implements a core CFDP
protocol. In some embodiments a method to transfer data into and
out of space flight systems and/or ground systems includes
receiving a user request into a memory of a CFDP-compliant library
apparatus. The method also includes starting a state machine in the
memory of the CFDP-compliant library apparatus that prompts a core
protocol to transfer a specified file to and/or from a specified
destination and initiating transfer of data blocks from the memory
of the library apparatus.
Inventors: |
Ray; Timothy J.; (Columbia,
MD) |
Correspondence
Address: |
NASA GODDARD SPACE FLIGHT CENTER
8800 GREENBELT ROAD, MAIL CODE 140.1
GREENBELT
MD
20771
US
|
Assignee: |
United States of America as
represented by the Administrator of NASA
Washington
DC
|
Family ID: |
39827931 |
Appl. No.: |
11/869288 |
Filed: |
October 9, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60891846 |
Feb 27, 2007 |
|
|
|
Current U.S.
Class: |
709/219 |
Current CPC
Class: |
H04B 7/18582 20130101;
H04L 67/06 20130101; Y10T 428/24331 20150115; H04L 67/322 20130101;
H04L 67/12 20130101 |
Class at
Publication: |
709/219 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A method to transfer data to and from a space flight system, the
method comprising: receiving a user request into a memory of a
CFDP-compliant library apparatus; routing the user request withinto
the CFDP-compliant library apparatus by a shell; starting a state
machine in the memory of the CFDP-compliant library apparatus that
prompts a core protocol to transfer a specified file to a specified
destination; and initiating transfer of data blocks from the memory
of the CFDP-compliant library apparatus.
2. The method of claim 1, wherein the user request further
comprises: a user request represented by a character string.
3. The method of claim 2, wherein the character string further
comprises: a character string having a predefined syntax.
4. The method of claim 1, wherein the transfer of data blocks is
one of two service classes further comprising: a service class of
which the CFDP-compliant library does not guarantee delivery of the
data block.
5. The method of claim 1, wherein the transfer of data blocks is
one of two service classes further comprising: a service class of
which the CFDP-compliant library guarantees delivery of the data
block.
6. The method of claim 1, further comprising: receiving a plurality
of user requests into the memory; and starting a state machine in
the memory of the CFDP-compliant library that prompts a core
protocol to transfer a specified file to a specified destination,
one state machine for each file transfer transaction.
7. The method of claim 1, further comprising: receiving at least
one protocol data unit into the memory; receiving at least one
request into the memory to set a MIB in the memory; and receiving
at least one cycle transaction.
8. A file-transfer routine library comprising: at least one state
machine in a memory, wherein each of the at least one state machine
is operable to instruct a core protocol to transfer a specified
file to a specified destination and operable to store a status of
data at a given time and operable to change the status and/or cause
an action or output to take place for any given change; and four
state tables in the memory, each state table specifying at least
one action in response to specific events for each of a plurality
of possible states, each state table implementing a core CFDP
protocol.
9. The file-transfer routine library of claim 8, further
comprising: a shell in the memory, the shell being operable to
manage creation and operation of the at least one state
machine.
10. The file-transfer routine library of claim 8, wherein the at
least one state machine in the memory further comprises: a
plurality of state machines in the memory each of which are
operable to concurrently transfer a specified file between a
specified destination.
11. The file-transfer routine library of claim 8, further
comprising: a virtual filestore file buffer not in the memory that
is operable to store each of a plurality of portions of a file
until the file is accepted.
12. The file-transfer routine library of claim 9, wherein the file
is accepted when either the entire file is received into the memory
and validated, or a library user has configured the library to save
incomplete files.
13. The file-transfer routine library of claim 8, wherein each of
the at least one state machine in the memory is operable to process
a user request, the user request being one of two service classes,
a first service class of which the CFDP-compliant library of which
the CFDP-compliant library does not guarantee delivery of the data
block and a second service class of which the CFDP-compliant
library guarantees delivery of the data block.
14. A space communication system comprising: a first entity having
a first memory, the first entity operable to communicate in a CFDP
communication protocol and including a shell in the first memory
that is operable to manage concurrent file transfers into and out
of the first memory with at least one other entity in the CFDP
protocol; and a second entity having a second memory operable to
communicate in the CFDP communication protocol and including a
shell in the second memory that is operable to manage concurrent
file transfers into and out of the second memory with at least one
other entity in the CFDP protocol.
15. The space communication system of claim 14, wherein each of the
entities is at least one of: an orbiter, a spacecraft, a
groundstation, a lander, and a mission operation center.
16. The space communication system of claim 14, wherein each of the
entities further comprises: at least one state machine, wherein
each of the at least one state machine is operable to instruct a
core protocol to transfer a specified file between a specified
destination and operable to store a status of data at a given time
and operable to change the status and/or cause an action or output
to take place for any given change; and four state tables, each
state table corresponding to at least one state machine, each state
table specifying at least one action in response to specific events
for each of a plurality of possible states, each state table
implementing a core CFDP protocol.
17. The space communication system of claim 16, wherein the core
protocol further comprises: a subset of the CFDP protocol that
includes the subset of CFDP protocol that is required to transfer
files between two points.
18. The space communication system of claim 16, wherein each of the
entities further comprises: a shell operable to manage creation and
operation of the at least one state machine.
19. The space communication system of claim 16, wherein each of the
at least one state machine further comprises: a plurality of state
machines each of which are operable to concurrently transfer a
specified file between a specified destination
20. The space communication system of claim 16, wherein each of the
entities further operable to communicated with a virtual filestore
file buffer to store each block, portion or chunk of a file until
the file is accepted, wherein the file is accepted when either the
entire file is received and validated, or a library user has
configured the library to save incomplete files.
21. The space communication system of claim 20, wherein each of the
at least one state machines is operable to process a user request,
the file transfer user request being one of a two plurality service
classes, a first service class of which the CFDP-compliant library
does not guarantee delivery of the data block and a second service
class of which the CFDP-compliant library guarantees delivery of
the data block.
Description
RELATED APPLICATION
[0001] This application claims the benefit of U.S. Provisional
Application Ser. No. 60/891,846, filed Feb. 27, 2007 under 35
U.S.C. 119(e).
ORIGIN OF THE INVENTION
[0002] The invention described herein was made by an employee of
the United States Government and may be manufactured and used by or
for the Government of the United States of America for governmental
purposes without the payment of any royalties thereon or
therefore.
FIELD OF THE INVENTION
[0003] This invention relates generally to communications systems,
and more particularly to space communication systems.
BACKGROUND
[0004] Space missions transfer blocks of data to spacecraft. The
data transfer blocks are called "loads." For example, a mission may
load a new version of onboard software, or a new version of a table
to be used by onboard software. Space missions transfer large data
blocks from spacecraft. Data block transfers from the spacecraft
are called "dumps." For example, a mission may dump images captured
by an onboard detector.
[0005] Loads and dumps use fundamental communication capabilities
provided by a space link. Most missions use the Consultative
Committee for Space Data Systems (CCSDS) space link protocols, but
not all use the CCSDS. Some space links are based on Internet
protocols, and there is some support for migrating in that
direction. To be widely reusable, a solution must be flexible with
regard to the space link.
[0006] Space links are typically intermittent. For example, the
link may be present for 15 minutes out of every 90 minutes of an
orbit around the earth, with no communication during the other 75
minutes of the 90 minutes. Any practical solution must provide a
way to suspend communication between contacts.
[0007] Loads and dumps interface with the on-board data storage
system. Some missions have onboard file systems, while others do
not--in which large data blocks are stored, but not in files. To be
widely reusable, a solution must be flexible with regard to the
data storage system.
[0008] Generally, each mission uses its own unique mechanisms to
accomplish loads and dumps. The load mechanism is usually different
than the dump mechanism. Reliable dumps typically require manual
inputs in which no automatic feedback loop ensures retransmission
of data.
[0009] One problem with conventional systems is that customized
software development is required. Another problem with conventional
systems is that manual inputs are not compatible with lights-out
operations.
[0010] For at least the reasons stated above, and for other reasons
stated below which will become apparent to those skilled in the art
upon reading and understanding the present specification, there is
a need in the art for a systems, methods and apparatus that can
accomplish both loads and dumps, that further is suitable for both
flight and ground environments, and is reusable from mission to
mission.
SUMMARY
[0011] The above-mentioned shortcomings, disadvantages and problems
are addressed herein, which will be understood by reading and
studying the following specification.
[0012] In one aspect, a method to transfer outgoing-data in a space
flight system includes receiving a user request into memory at a
library that is compliant with the consultative committee for space
data systems file delivery protocol (CFDP). The method also
includes routing the user request withto the CFDP-compliant library
apparatus by a shell. The method also includes starting a state
machine in the memory of the CFDP-compliant library apparatus that
prompts a core protocol to transfer a specified file to a specified
destination. The method also includes initiating transfer of data
blocks from the memory of the CFDP-compliant library. In some
embodiments, the user request is one of two service classes, a
first service class of which the CFDP-compliant library of which
the CFDP-compliant library does not guarantee delivery of data
blocks and a second service class of which the CFDP-compliant
library guarantees delivery of the data blocks.
[0013] In another aspect, a file-transfer routine library includes
one or more state machine(s) in a memory. Each of the one or more
state machine(s) is operable to instruct a core protocol to
transfer a specified file to a specified destination. Each of the
one or more state machine(s) is operable to store a status of data
at a given time. Each of the one or more state machine(s) is
operable to change the status and/or cause an action or output to
take place for any given change and one or more state table(s) in
the memory. Each state table corresponds to one and not more than
one of the one or more state machine(s). Each state table specifies
one or more action(s) in response to specific events for each of a
plurality of possible states, each state table implementing a core
CFDP protocol.
[0014] In yet another aspect, a space communication system
including a first entity having memory. The first entity and a
second entity include memory. Each entity is operable to
communicate in a CFDP communication protocol. Each entity includes
a shell in the first memory that is operable to manage concurrent
file transfers into and out of memory with one or more other
entitie(s) in the CFDP protocol.
[0015] Apparatus, systems, and methods of varying scope are
described herein. In addition to the aspects and advantages
described in this summary, further aspects and advantages will
become apparent by reference to the drawings and by reading the
detailed description that follows.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] FIG. 1 is a block diagram of an overview of a space
communication system to transfer blocks of data between entities in
the system, according to an embodiment;
[0017] FIG. 2 is a block diagram of an apparatus to transfer blocks
of data between entities in a space-based communication system,
according to an embodiment;
[0018] FIG. 3 is a block diagram of a library apparatus that is
compliant with the consultative committee for space data systems
file delivery protocol (CFDP) to transfer blocks of data in a space
communication system, according to an embodiment;
[0019] FIG. 4 is a flowchart of a method to transfer outgoing-data
in a space flight system, according to an embodiment;
[0020] FIG. 5 is a flowchart of a method to transfer incoming-data
in a space flight system, according to an embodiment; and
[0021] FIG. 6 is a block diagram of a hardware and operating
environment in which different embodiments can be practiced,
according to an embodiment.
DETAILED DESCRIPTION
[0022] In the following detailed description, reference is made to
the accompanying drawings that form a part hereof, and in which is
shown by way of illustration specific embodiments which may be
practiced. These embodiments are described in sufficient detail to
enable those skilled in the art to practice the embodiments, and it
is to be understood that other embodiments may be utilized and that
logical, mechanical, electrical and other changes may be made
without departing from the scope of the embodiments. The following
detailed description is, therefore, not to be taken in a limiting
sense.
[0023] The detailed description is divided into five sections. In
the first section, a system level overview is described. In the
second section, apparatus of embodiments are described. In the
third section, methods of embodiments are described. In the fourth
section, a hardware and operating environment in which different
embodiments can be practiced is described. Finally, in the fifth
section, a conclusion of the detailed description is provided.
System Level Overview
[0024] FIG. 1 is a block diagram of an overview of a space
communication system 100 to transfer blocks of data between
entities in the system, according to an embodiment.
[0025] System 100 includes space links 102 that interconnect a
spacecraft with its ground support system or with another
spacecraft. Agencies' new generations of space missions require
telecommand and telemetry capabilities beyond current technologies.
These new needs are for higher data rates, better link
performances, more performing ranging systems, together with lower
cost, mass and power and higher security.
[0026] More specifically, the space links 102 implement layers 1
& 2 of open system interconnection (OSI) protocol stack,
namely, RF & modulation, channel coding and data link layer,
for both long-haul (e.g., spacecraft 104 to ground station 106) and
proximity links (e.g., an orbiter 108 to a lander 110). In some
embodiments, two additional functions are also included in the
space links 102 data compression for end to end data transfer
optimization, and ranging for accurate orbit determination. The
area is composed of specialized working group whose objective is to
develop specific recommendations. One recommendation will typically
cover one OSI layer or sub-layer. This layering of recommendations
maximizes flexibility and interoperability with other commercial
protocols (e.g., TCP/IP). System 100 also includes a ground link
112 that is an electronic communication path between one or more
the ground station(s) 106 and one or more mission operation
center(s) 114. OSI is published by the International Organization
for Standardization located at 1, ch. de la Voie-Creuse, CP 56,
1211 Geneve 20, Switzerland.
[0027] The space links 102 and the ground links 112 are compliant
with the consultative committee for space data systems (CCSDS) file
delivery protocol (CFDP). The CFDP protocol provides reliable
transfer of files from one entity to another. For example, a
typical space mission might have two entities that communicate in
accordance with the CFDP protocol--one CFDP-compliant entity being
the spacecraft 104 and the other CFDP-compliant entity being the
mission operation center 114. CFDP is designed to work well over
space links 102.
[0028] The CFDP protocol is published is Consultative Committee for
Space Data Systems (CCSDS) file delivery protocol (CFDP). The CFDP
is published by the CCSDS located at 2801 Alexander Bell Drive,
Suite 500, Reston, Va. 20191-4344. The CFDP library 206 makes
outgoing subroutine calls for aspects of CFDP that are
implementation-dependent. One example or embodiment of the CFDP
library 206 is shown in the CFDP library apparatus 300 in FIG. 3
below.
[0029] Each entity (spacecraft 104, ground station 106, orbiter
108, lander 110 and/or mission operation center 114) is associated
with or includes a particular virtual filestore. A virtual
filestore acts like a collection of files (e.g., each `file` can be
opened, read from, closed, etc.) The CFDP protocol leaves the
implementation of the virtual filestore up to the user (for
example, a user is free to make a solid-state recorder look like a
file). A user is not necessarily a human, but rather can be a
CFDP-compliant entity.
[0030] Some embodiments of the CFDP protocol provide only a
single-hop, i.e., a source entity communicating directly with a
destination entity. Some embodiments of the CFDP protocol support
multiple-hop scenarios (e.g., a CFDP entity on a lander 110 sends a
file back to a CFDP entity on earth, such as mission operation
center(s) 114, via a CFDP entity on an orbiter 108). Each file
transfer is an independent transaction--the CFDP protocol allows an
unlimited number of concurrent transactions, including concurrent
file transfers in both directions.
[0031] More specifically, the CFDP protocol provides multiple
service classes, including the following two service classes:
Service Class 1 sends each file in which the receiver provides no
replies, nor is there any guarantee of reliable delivery. Service
class 2 ensures reliable file delivery; any required
retransmissions are requested and performed by a CFDP-compliant
entity.
[0032] The CFDP protocol defines a discrete set of requests that
allow a user or CFDP-compliant entity to control the protocol. For
example, a `Put Request` is used to initiate a file transfer. The
execution of each request is specified within the CFDP protocol.
However, generation of requests is implementation-dependent. For
example, requests may be generated by keyboard input or via an
interface to some automated program.
[0033] The CFDP protocol defines a discrete set of indications that
allow progress reporting on a request to an initiating user or
CFDP-compliant entity. For example, a `Transaction-Finished`
indication occurs whenever a transaction completes. Actions taken
by the user or CFDP-compliant entity in response to indications are
implementation-dependent. For example, in response to a
`Transaction-Finished` indication, the user or CFDP-compliant
entity could add an entry to a log file.
[0034] The CFDP protocol defines a discrete set of messages that
are used for communication between the sender and receiver. These
messages are called protocol data units (PDUs). The CFDP protocol
specifies use of the PDUs to accomplish file transfers.
[0035] The CFDP protocol does not specify how the PDUs are
delivered--CFDP can be run on top of any protocol that delivers
most of the PDUs. Nor does the CFDP protocol specify how
CFDP-compliant PDUs are provided to the underlying protocol. How
the CFDP PDUs are provided to the underlying protocol is
implementation-dependent. For example, the CFDP protocol can run
over UDP, TCP, or CCSDS command/telemetry in which a CFDP-compliant
message is encapsulated in a message that is compliant with another
protocol.
[0036] In system 100, callback routines provide access to the space
link 102 and data storage system to provide flexibility for
widespread reuse. Matching callback routine interfaces to Portable
Operating System Interface (POSIX) standard routines reduces
software development by library users, for example, to implement
the data storage system as a file system. No software development
is required because the POSIX standard routines are used by
default. However, a user could develop a unique interface. POSIX is
the collective name of a family of related standards specified by
the Institute of Electrical and Electronics Engineers, Inc. (IEEE)
standard 1003 to define the application programming interface (API)
for software compatible with variants of the Unix operating system.
POSIX is administered by The Open Group at 44 Montgomery St., Suite
960, San Francisco, Calif.
Apparatus of an Embodiment
[0037] In the previous section, a system level overview of the
operation of an embodiment was described. In this section, an
exemplary apparatus of such an embodiment are described by
reference to a series of diagrams.
[0038] FIG. 2 is a block diagram of an apparatus 200 to transfer
blocks of data between entities in the system, according to an
embodiment. System 200 includes incoming subroutine calls 202. The
incoming subroutine calls 202 include calls that are initiated by a
user application. A call is the process of invoking the
instructions in a subroutine.
[0039] In addition to the incoming subroutine calls 202, system 200
includes utility routines (not shown). System 200 also includes
outgoing subroutine calls 204. The outgoing subroutine calls 204
are calls that are initiated by a library 206 that is compliant
with Consultative Committee for Space Data Systems (CCSDS) file
delivery protocol (CFDP). The CFDP library 206 makes outgoing
subroutine calls for aspects of CFDP that are
implementation-dependent.
[0040] The CFDP library 206 accomplishes both loads and dumps with
an international standard protocol, and provides the automatic
retransmissions needed for reliable transfers. The CFDP library 206
implements the core CFDP protocol and provides unlimited concurrent
file transfers in both directions simultaneously. The core CFDP
protocol is a subset of the CFDP protocol that includes the subset
of CFDP protocol that is required to transfer files between two
points. In some embodiments, the core CFDP protocol includes
service classes 1 and 2 and excludes certain unnecessary options.
One example of an unnecessary option is "Filestore Directives" that
allow the user to create a directory. The CFDP library 206 is
single-tasking, single-threaded, and requires a small amount of
memory. The CFDP library 206 implements a generic interface to the
space links 102 and generic interfaces to the data storage system
interfaces. The CFDP library 206 is delivered with sample user code
for a complete sample application. The CFDP library 206 is
delivered with an automated test facility that validates the sample
application. The CFDP library 206 is reusable, from mission to
mission, for both flight and ground software. The CFDP library 206
is suitable for both flight and ground software.
[0041] A callback routine mechanism (not shown) is used for some
outgoing subroutine calls 204, such as subroutine call to output of
PDU and subroutine call to print messages. The purpose of using a
call back routine is to provide flexibility to the library user.
The call back mechanism also provides a mechanism to the library
user to accept the default callback routine (if there is one) or
register a callback routine.
[0042] The formal source code interface to the CFDP library 206 is
contained in the following five definition components: First, a
configuration component that includes settings for protocol
options. In some embodiments the configuration component can be
modified. Second, a data structures component that includes
datatype declarations. Third, a provided subroutine component that
includes subroutines provided by the library. Fourth, a required
callback routine component that includes subroutines required by
the library (e.g., callback routines). Fifth, a character string
component that includes character-string syntax for user requests
and management information base (MIB) parameters. A MIB is an
OSI/ISO Network management model and is a type of database used to
manage the devices in a communications network. MIB comprises a
collection of objects in a (virtual) database used to manage
entities (such as routers and switches) in a network.
[0043] Some embodiments of system 200 set the MIB. Each MIB
contains CFDP configuration parameters. In some embodiments, for
performance reasons, the MIB is stored within the CFDP library 206.
The library user can set MIB parameter values at both compile-time
and run time. MIB parameters can be set at compile-time by
modifying a header or in included source code file. MIB parameters
can also be set at run-time by calling a subroutine 208 that uses
character strings to represent the MIB parameters and values.
[0044] Some embodiments of system 200 also include one or more user
request(s) that are passed to the library by calling a subroutine
210. In some embodiments the subroutine uses a character string to
represent user requests. In some embodiments, the syntax of the
character string is defined in a header or in included source code
file.
[0045] Some embodiments of system 200 include one or more protocol
data unit(s) (PDU). A PDU 212 is a message between a sender and a
receiver. The library user provides PDUs to the CFDP library 206
from CFDP partners. Each PDU is passed to the CFDP library 206 by
calling a subroutine 212.
[0046] Some embodiments of system 200 include one or more cycle
transaction(s) 214. The CFDP library 206 uses a polling mechanism
to meter outgoing PDUs 214. The CFDP library 206 performs one
polling cycle each time the library user calls a subroutine. Note
that system performance will suffer, if the library user does not
call this subroutine frequently.
[0047] Some embodiments of system 200 include one or more outgoing
PDU(s). The CFDP library 206 generates outgoing PDUs and uses three
callback routines 216 described to output outgoing PDUs. The CFDP
library 206 does not provide default implementations for these
callback routines so the library user implements the callback
routines. In order to improve system performance, the subroutines
complete promptly.
[0048] Callback routine "open" can be called once at the start of
each transaction. The CFDP library 206 supplies an identification
of a local CFDP node and an identification of a CFDP partner when
calling this routine. The "open" callback routine establishes a
connection with the specified CFDP partner.
[0049] Callback routine "ready" controls outgoing PDUs. This
callback is called at least once prior to the output of each PDU.
The CFDP library 206 supplies an identification of a CFDP partner
when calling this routine.
[0050] Callback routine "send" sends a given PDU to a specified
CFDP entity. The CFDP library 206 calls this routine once for each
PDU generated by the CFDP library 206. The CFDP library 206
supplies an identification of a CFDP partner and a PDU when calling
this routine.
[0051] Some embodiments of system 200 include one or more virtual
filestore(s) 218. The CFDP library 206 calls a set of callback
routines for filestore access (to read and write from "files" in
the virtual filestore). In some embodiments, the prototypes for
almost all of these callback routines are Posix compliant (for
example, the prototype for reading from a file). In some cases, a
default callback is a Posix routine (for example, the default
callback for reading from a file is fread). If the library user has
a true filesystem, the default callbacks are probably acceptable
(i.e., the library user does not need to implement any filestore
access routines).
[0052] Some embodiments of system 200 include one or more
indication(s) 220. The CFDP protocol defines one or more
indication(s) 220 (e.g., "End-Of.File sent") that the protocol
provides to the user. The CFDP protocol does not specify the User's
response. The CFDP library 206 allows the user to enable/disable
certain Indications (by modifying a header or in included source
code file). The CFDP library 206 also implements a default response
to each indication 220 (a text message is output), and allows the
user to enable/disable the default response (by modifying a header
or in included source code file). The CFDP library 206 also defines
a callback routine to be called each time an indication 220 occurs
by default, the callback routine is null (meaning that no routine
is called). If desired, the library user may implement an
indication 220 callback routine and register the indication
220.
[0053] Some embodiments of system 200 include one or more text
message(s) 222. The CFDP library 206 outputs text messages 222 via
a callback routine whose prototype matches a print function. The
default callback is the print function. If desired, the library
user may override the default by registering another callback
routine. For example, a flight software application may each text
message into spacecraft telemetry, while a graphical user interface
application may put the text messages into a text box.
[0054] While the apparatus 200 is not limited to any particular
incoming subroutine calls 202, outgoing subroutine calls 204, CFDP
library 206, MIB set subroutine 208, user request subroutine 210,
PDU subroutine 212, cycle transaction subroutine 214, outgoing PDU
subroutine 216, one or more virtual filestore(s) 218, one or more
indication(s) 220, text message(s) 222, for sake of clarity general
incoming subroutine call(s) 202, outgoing subroutine call(s) 204,
CFDP library 206, MIB set subroutine 208, user request subroutine
210, PDU subroutine 212, cycle transaction subroutine 214, outgoing
PDU subroutine 216, one or more virtual filestore(s) 218, one or
more indication(s) 220, text message(s) 222 have been
described.
[0055] FIG. 3 is a block diagram of a CFDP library apparatus 300 to
transfer blocks of data in a space communication system, according
to an embodiment. CFDP library apparatus 300 is one example or
embodiment of the CFDP library apparatus 206 in FIG. 2 above.
[0056] The CFDP library apparatus 300 implements a subset of the
CFDP protocol required to transfer files from one point to another,
known as the core CFDP protocol. The CFDP library apparatus 300
includes state machines and/or callback routines, allowing a user
of the CFDP library apparatus 300 to easily create a CFDP
application that is a single program with a single execution
thread. The core CFDP protocol does not include service Class 3
(Proxy Operations wherein entity A requests that entity B send a
file to entity C), type-length-values (TLVs) such as a file
transfer that includes a request to create a new directory, and
segmented files whose segmented nature must he maintained at the
receiving end.
[0057] The CFDP library apparatus 300 minimizes the processing
required by a library user, while preserving much of the
flexibility of CFDP. Fixed aspects of CFDP are implemented within
the library, for example, the protocol state table logic. To the
maximum extent possible, all implementation-dependent aspects of
the CFDP protocol are kept outside the library. In some
embodiments, the CFDP library apparatus 300 provides a default
implementation of each implementation--dependent aspect of CFDP
protocol. The library user can accept these default subroutine
implementations or provide an alternative implementation. In
addition, the CFDP library apparatus 300 includes sample source
code for a complete CFDP application program.
[0058] Some implementation-dependent aspects of the CFDP library
apparatus 300 have a default predetermined implementation. The
implementation-dependent aspects that can be overridden by a
designation from the user include a response to indications and
filestore access (reading and writing from files).
[0059] Implementation-dependent aspects of the CFDP library
apparatus 300 that must be specified/designated/supplied by the
user include input of requests from the user, input of PDUs from
CFDP partners, output of PDUs to CFDP partners, and a main
routine.
[0060] The CFDP library apparatus 300 includes one or more state
table(s) 302 that implements a core CFDP protocol. Each state table
302 specifies actions to take in response to specific events (e.g.,
an incoming PDU) for each of the possible states (e.g. `sending the
whole file once,` `retransmitting missing data`). A shell 304
around the state table(s) 302 manages creation and operation of one
or more state machine(s) 306 that support an unlimited number of
concurrent simultaneous bidirectional file transfers. The state
machine(s) 306 store the status of data at a given time and operate
on input to change the status and/or cause an action or output to
take place for any given change. One state machine is required for
each current file transfer operation. So, the operation of multiple
state machine(s) 306 provides concurrent file transfers.
[0061] The state table(s) 302 implement logic of the CFDP protocol.
CFDP library apparatus 300 show four state tables, Service Class 1
sender 308, Service Class 1 receiver 310, Service Class 2 sender
312 and Service Class 2 receiver 314. For example, if
CFDP-compliant entity is using Service Class 2 to send a file to
another CFDP-compliant entity, then the Service Class 2 sender
state table 314 logic will be used.
[0062] In regards to the state machines 306, every transaction that
sends a file using Service Class 2 uses the corresponding state
table logic. However, each transaction has status information that
is independent of all the others (e.g., status information
describing how much of the file has been sent). The combination of
state table logic plus transaction status is referred to as a state
machine 306. At any given time, the library maintains a separate
state machine 306 for each active transaction.
[0063] The shell 304 manages the state machine(s) 306. The shell
304 receives incoming user request(s) 210 and incoming PDU(s) 212,
and the shell 304 routes incoming user request(s) 210 and incoming
PDU(s) 212 to the appropriate state machine 306. One example of an
appropriate state machine is a state machine that is assigned to a
particular file transfer transaction. A new state machine 306 is
created when a shell receives a PDU for a new transaction.
[0064] The CFDP library apparatus 300 stores the value of each MIB
parameter internally. The MIB value is stored in a utility module
outside of the shell. The user selects default parameter values for
each MIB at compile by modifying a header or in included source
code file, and/or during execution by calling a subroutine that
uses character strings to represent the MIB parameters and
values.
[0065] The CFDP library apparatus 300 uses a virtual filestore as a
file buffer. So, for example, an outgoing file is not copied into
memory. Instead, each block, portion or chunk of the file is read
directly from the virtual filestore. Incoming filedata 318 is
stored in a temporary file 320 outside the CFDP library apparatus
300 in the user's domain until the file is accepted. Acceptance
occurs if either the entire file is received and validated, or the
library user has configured the library to save incomplete files.
Upon acceptance, the temporary file is renamed to its "real"
destination. For example, if a CFDP partner sends the file
"science.one," the incoming filedata 316 is stored in a temporary
file. If accepted, the temporary file is renamed to "science.one,"
this process having has two benefits. First, this process avoids
overwriting an existing file until the new version is validated.
Second, this process allows the CFDP library apparatus 300 to
handle the situation in which a metadata PDU is dropped, in which
case, the CFDP library apparatus 300 stores the incoming file data
without knowing the file name. The file name is in the Metadata PDU
that was dropped.
[0066] The CFDP library apparatus 300 leaves the input of user
requests 210 and incoming PDUs 212 to the library user. The library
user passes each incoming user request 210 and PDU 212 on to the
library, by calling the appropriate subroutine.
[0067] The library calls a user-supplied callback routine to output
each PDU 216, which allows the library user to output the PDU 216
according to the specifications of the user. When the CFDP library
apparatus 300 has a PDU 212 to send, the CFDP library apparatus 300
buffers the PDU 212 until given a "green light" by the library user
(i.e., a polling mechanism is used to meter out one PDU at a time).
This polling is accomplished by calling another user-supplied
callback routine. The polling mechanism is activated each time the
CFDP library apparatus 300 user calls the subroutine for each
transaction. Each call to this subroutine is a cycle. For each
cycle, each transaction has an opportunity to output a PDU. Control
PDUs (e.g., acknowledgment signal "ack" and non-acknowledgment
signal "nak") get a higher priority than file data PDUs. In some
embodiments, the CFDP library apparatus 300 assumes that the user
of the CFDP library apparatus 300 will call this subroutine
frequently enough to utilize the available output bandwidth.
[0068] The CFDP library apparatus 300 uses internal timers for each
transaction, as specified by the CFDP protocol. These timers are
checked for expiration each time the subroutine cycle each
transaction is called.
Methods of an Embodiment
[0069] In the previous section, apparatus of the operation of an
embodiment was described. In this section, the particular processes
of such an embodiment are described by reference to a series of
flowcharts.
[0070] FIG. 4 is a flowchart of a method 400 to transfer
outgoing-data in a space flight system, according to an
embodiment.
[0071] Method 400 includes initiating transfer of data blocks
("files") from the CFDP library, at block 402 in FIG. 4. Outgoing
file transfers 402 are initiated or performed after receiving a
user request provided/sent a user to the CFDP library, at block
404. Initiation 402 of the file transfer starts a state machine, at
block 406, that prompts the core CFDP protocol to transfer the
specified file to the specified destination. One example of the
state machine is the state machine(s) 306 in FIG. 3.
[0072] FIG. 5 is a flowchart of a method 500 to transfer
incoming-data in a space flight system, according to an
embodiment.
[0073] Incoming file transfers that are initiated by incoming CFDP
messages that are generated by another CFDP-compliant node and
received by the CFDP library at block 502. The CFDP library creates
a new state machine, at block 504, to handle each incoming file
transfer. Multiple concurrent file transfers are handled by
multiple concurrent state machines. Each state machine runs
independently of all the other state machines.
[0074] For intermittent links, the CFDP library can suspend state
machines at the end of each pass by issuing a "freeze" request to
the library. A pass is a satellite contact while the satellite is
above the horizon from the perspective of a ground station. At the
beginning of each pass, the library user can issue a "thaw" request
to resume the suspended state machines.
[0075] In some embodiments, methods 400-500 are implemented as a
computer data signal embodied in a carrier wave, that represents a
sequence of instructions which, when executed by a processor, such
as processor 604 in FIG. 6, cause the processor to perform the
respective method. In other embodiments, methods 400-500 are
implemented as a computer-accessible medium having executable
instructions capable of directing a processor, such as processor
604 in FIG. 6, to perform the respective method. In varying
embodiments, the medium, for example, is a magnetic medium, an
electronic medium, or an optical medium.
[0076] More specifically, in the computer-readable program
embodiment, the programs can be structured in an object-orientation
using an object-oriented language such as Java, Smalltalk or C++,
and the programs can be structured in a procedural-orientation
using a procedural language such as COBOL or C. The software
components communicate in any of a number of means that are
well-known to those skilled in the art, such as application program
interfaces (API) or interprocess communication techniques, such as
remote procedure call (RPC), common object request broker
architecture (CORBA), Component Object Model (COM), Distributed
Component Object Model (DCOM), Distributed System Object Model
(DSOM) and Remote Method Invocation (RMI). The components execute
on as few as one computer as in computer 602 in FIG. 6, or on at
least as many computers as there are components.
Hardware and Operating Environment
[0077] FIG. 6 is a block diagram of a hardware and operating
environment 600 in which different embodiments can be practiced.
The description of FIG. 6 provides an overview of computer hardware
and a suitable computing environment in conjunction with which some
embodiments can be implemented. Embodiments are described in terms
of a computer executing computer-executable instructions. However,
some embodiments can be implemented entirely in computer hardware
in which the computer-executable instructions are implemented in
read-only memory. Some embodiments can also be implemented in
client/server computing environments where remote devices that
perform tasks are linked through a communications network. Program
modules can be located in both local and remote memory storage
devices in a distributed computing environment.
[0078] Computer 602 includes a processor 604, commercially
available from Intel, Motorola, Cyrix and others. Computer 602 also
includes random-access memory (RAM) 606, read-only memory (ROM)
608, and one or more mass storage device(s) 610, and a system bus
612, that operatively couples various system components to the
processing unit 604. The memory 606, 608, and mass storage devices,
610, are types of computer-accessible media. Mass storage devices
610 are more specifically types of nonvolatile computer-accessible
media and can include one or more hard disk drives, floppy disk
drives, optical disk drives, and tape cartridge drives. The
processor 604 executes computer programs stored on the
computer-accessible media.
[0079] Computer 602 can be communicatively connected to the
Internet 614 via a communication device 616. Internet 614
connectivity is well known within the art. In one embodiment, a
communication device 616 is a modem that responds to communication
drivers to connect to the Internet via what is known in the art as
a "dial-up connection." In another embodiment, a communication
device 616 is an Ethernet.RTM. or similar hardware network card
connected to a local-area network (LAN) that itself is connected to
the Internet via what is known in the art as a "direct connection"
(e.g., T1 line, etc.).
[0080] A user enters commands and information into the computer 602
through input devices such as a keyboard 618 or a pointing device
620. The keyboard 618 permits entry of textual information into
computer 602, as known within the art, and embodiments are not
limited to any particular type of keyboard. Pointing device 620
permits the control of the screen pointer provided by a graphical
user interface (GUI) of operating systems, such as versions of
Microsoft Windows.RTM.. Embodiments are not limited to any
particular pointing device 620. Such pointing devices include mice,
touch pads, trackballs, remote controls, and point sticks. Other
input devices (not shown) can include a microphone, joystick, game
pad, satellite dish, scanner, or the like.
[0081] In some embodiments, computer 602 is operatively coupled to
a display device 622. Display device 622 is connected to the system
bus 612. Display device 622 permits the display of information,
including computer, video and other information, for viewing by a
user of the computer. Embodiments are not limited to any particular
display device 622. Such display devices include cathode ray tube
(CRT) displays (monitors), as well as flat panel displays such as
liquid crystal displays (LCD's). In addition to a monitor,
computers typically include other peripheral input/output devices,
such as printers (not shown). Speakers 624 and 626 provide audio
output of signals. Speakers 624 and 626 are also connected to the
system bus 612.
[0082] Computer 602 also includes an operating system (not shown)
that is stored on the computer-accessible media RAM 606, ROM 608,
and mass storage device 610, and is executed by the processor 604.
Examples of operating systems include Microsoft Windows.RTM., Apple
MacOS.RTM., Linux.RTM., and UNIX.RTM.. Examples are not limited to
any particular operating system, however, and the construction and
use of such operating systems are well known within the art.
[0083] Embodiments of computer 602 are not limited to any type of
computer 602. In varying embodiments, computer 602 comprises a
PC-compatible computer, a MacOS.RTM.-compatible computer, a
Linux.RTM.-compatible computer, or a UNIX.RTM.-compatible computer.
The construction and operation of such computers are well known
within the art.
[0084] Computer 602 can be operated using at least one operating
system to provide a graphical user interface (GUI) including a
user-controllable pointer. Computer 602 can have at least one web
browser application program executing within at least one operating
system, to permit users of computer 602 to access an intranet,
extranet, or Internet world-wide-web pages as addressed by
Universal Resource Locator (URL) addresses. Examples of browser
application programs include Netscape Navigator.RTM. and Microsoft
Internet Explorer.RTM..
[0085] The computer 602 can operate in a networked environment
using logical connections to one or more remote computer(s), such
as remote computer 628. These logical connections are achieved by a
communication device coupled to, or a part of, the computer 602.
Embodiments are not limited to a particular type of communications
device. The remote computer 628 can be another computer, a server,
a router, a network PC, a client, a peer device or other common
network node. The logical connections depicted in FIG. 6 include a
local-area network (LAN) 630 and a network (WAN) 632. Such
networking environments are commonplace in offices, enterprise-wide
computer networks, intranets, extranets and the Internet.
[0086] When used in a LAN-networking environment, the computer 602
and remote computer 628 are connected to the local network 630
through network interfaces or adapters 634, which is one type of
communications device 616. Remote computer 628 also includes a
network device 636. When used in a conventional WAN-networking
environment, the computer 602 and remote computer 628 communicate
with a WAN 632 through modems (not shown). The modem, which can be
internal or external, is connected to the system bus 612. In a
networked environment, program modules depicted relative to the
computer 602, or portions thereof, can be stored in the remote
computer 628.
[0087] Computer 602 also includes power supply 638. Each power
supply, for example, can be a battery. Internal and external power
supplies are well-known in the art.
CONCLUSION
[0088] Systems, method and apparatus of a file transfer protocol
have been described. Although specific embodiments have been
illustrated and described herein, it will be appreciated by those
of ordinary skill in the art that any arrangement which is
calculated to achieve the same purpose may be substituted for the
specific embodiments shown. This application is intended to cover
any adaptations or variations.
[0089] In particular, one of skill in the art will readily
appreciate that the names of the methods and apparatus are not
intended to limit embodiments. Furthermore, additional methods and
apparatus can be added to the components, functions can be
rearranged among the components, and new components to correspond
to future enhancements and physical devices used in embodiments can
be introduced without departing from the scope of embodiments. One
of skill in the art will readily recognize that embodiments are
applicable to future data files and different space-based
communication systems.
[0090] The terminology used in this application with respect to
file systems, protocols and space-based communication systems is
meant to include all environments and alternate technologies which
provide the same functionality as described herein.
* * * * *