US20080250118A1

US20080250118A1 - Systems, methods, and apparatus of a space communication file transfer system

Info

Publication number: US20080250118A1
Application number: US11/869,288
Authority: US
Inventors: Timothy J. Ray
Original assignee: National Aeronautics and Space Administration NASA
Current assignee: National Aeronautics and Space Administration NASA
Priority date: 2007-02-27
Filing date: 2007-10-09
Publication date: 2008-10-09
Also published as: US8742468B2; US20110097541A1; US20110095181A1; US8455926B2; US7922920B2; US20090110880A1

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.

Description

RELATED APPLICATION

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

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

This invention relates generally to communications systems, and more particularly to space communication systems. BACKGROUND
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.
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.
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.
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.
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.
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.
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

The above-mentioned shortcomings, disadvantages and problems are addressed herein, which will be understood by reading and studying the following specification.
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.
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.
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.
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

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;

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;

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;

FIG. 4 is a flowchart of a method to transfer outgoing-data in a space flight system, according to an embodiment;

FIG. 5 is a flowchart of a method to transfer incoming-data in a space flight system, according to an embodiment; and

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

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

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.
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.
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 Genève 20, Switzerland.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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

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

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.
FIG. 4 is a flowchart of a method 400 to transfer outgoing-data in a space flight system, according to an embodiment.
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.
FIG. 5 is a flowchart of a method 500 to transfer incoming-data in a space flight system, according to an embodiment.
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.
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.
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.
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

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.
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.
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® 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.).
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®. 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.
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.
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®, Apple MacOS®, Linux®, and UNIX®. 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.
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®-compatible computer, a Linux®-compatible computer, or a UNIX®-compatible computer. The construction and operation of such computers are well known within the art.
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® and Microsoft Internet Explorer®.
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.
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.
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

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

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.