US20080250118A1 - Systems, methods, and apparatus of a space communication file transfer system - Google Patents
Systems, methods, and apparatus of a space communication file transfer system Download PDFInfo
- Publication number
- US20080250118A1 US20080250118A1 US11/869,288 US86928807A US2008250118A1 US 20080250118 A1 US20080250118 A1 US 20080250118A1 US 86928807 A US86928807 A US 86928807A US 2008250118 A1 US2008250118 A1 US 2008250118A1
- Authority
- US
- United States
- Prior art keywords
- cfdp
- file
- library
- memory
- transfer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/14—Relay systems
- H04B7/15—Active relay systems
- H04B7/185—Space-based or airborne stations; Stations for satellite systems
- H04B7/18578—Satellite systems for providing broadband data service to individual earth stations
- H04B7/18582—Arrangements for data linking, i.e. for data framing, for error recovery, for multiple access
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10T—TECHNICAL SUBJECTS COVERED BY FORMER US CLASSIFICATION
- Y10T428/00—Stock material or miscellaneous articles
- Y10T428/24—Structurally defined web or sheet [e.g., overall dimension, etc.]
- Y10T428/24273—Structurally defined web or sheet [e.g., overall dimension, etc.] including aperture
- Y10T428/24322—Composite web or sheet
- Y10T428/24331—Composite web or sheet including nonapertured component
Definitions
- This invention relates generally to communications systems, and more particularly to space communication systems.
- Space missions transfer blocks of data to spacecraft.
- the data transfer blocks are called “loads.”
- 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.”
- a mission may dump images captured by an onboard detector.
- Space links are typically intermittent.
- 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.
- 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.
- 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.
- CFDP space data systems file delivery protocol
- 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.
- 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.
- 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.
- 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
- CFDP space data systems file delivery protocol
- 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
- FIG. 6 is a block diagram of a hardware and operating environment in which different embodiments can be practiced, according to an embodiment.
- 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.
- 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 ).
- OSI open system interconnection
- 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).
- CCSDS consultative committee for space data systems
- CFDP file delivery protocol
- the CFDP protocol provides reliable transfer of files from one entity to another.
- 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).
- CCSDS Consultative Committee for Space Data Systems
- 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.
- 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).
- PDUs protocol data units
- 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.
- 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.
- API application programming interface
- POSIX is administered by The Open Group at 44 Montgomery St., Suite 960, San Francisco, Calif.
- 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.
- 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).
- CCSDS Consultative Committee for Space Data Systems
- CFDP file delivery protocol
- 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.
- the core CFDP protocol includes service classes 1 and 2 and excludes certain unnecessary options.
- 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.
- 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.
- system 200 set the MIB.
- Each MIB contains CFDP configuration parameters.
- 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.
- system 200 also include one or more user request(s) that are passed to the library by calling a subroutine 210 .
- the subroutine uses a character string to represent user requests.
- the syntax of the character string is defined in a header or in included source code file.
- system 200 include one or more protocol data unit(s) (PDU).
- 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 .
- 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.
- 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 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.
- 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).
- the prototypes for almost all of these callback routines are Posix compliant (for example, the prototype for reading from a file).
- 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 .
- 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.
- 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.
- 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 .
- Service Class 1 sender 308 Service Class 1 receiver 310
- Service Class 2 sender 312 Service Class 2 receiver 314
- Service Class 2 sender state table 314 logic will be used.
- 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 .
- 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.
- 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.
- this process avoids overwriting an existing file until the new version is validated.
- 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.
- 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.
- 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.
- 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.
- 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.
- the library user can issue a “thaw” request to resume the suspended state machines.
- 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.
- 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.
- the medium for example, is a magnetic medium, an electronic medium, or an optical medium.
- 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).
- API application program interfaces
- CORBA common object request broker architecture
- COM Component Object Model
- DCOM Distributed Component Object Model
- DSOM Distributed System Object Model
- RMI Remote Method Invocation
- 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.
- 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 .
- RAM random-access memory
- ROM read-only memory
- mass storage device(s) 610 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.
- 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.”
- 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., T 1 line, etc.).
- LAN local-area network
- 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 .
- GUI graphical user interface
- Such pointing devices include mice, touch pads, trackballs, remote controls, and point sticks.
- Other input devices can include a microphone, joystick, game pad, satellite dish, scanner, or the like.
- 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).
- 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 .
- 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 .
- 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 .
- LAN local-area network
- WAN network
- Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, extranets and the Internet.
- the computer 602 and remote computer 628 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 .
- the computer 602 and remote computer 628 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 .
- 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.
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
- 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).
- 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.
- 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.
- 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.
-
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. - 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.
-
FIG. 1 is a block diagram of an overview of aspace communication system 100 to transfer blocks of data between entities in the system, according to an embodiment. -
System 100 includesspace 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., anorbiter 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 aground 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 themission operation center 114. CFDP is designed to work well overspace 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. TheCFDP library 206 makes outgoing subroutine calls for aspects of CFDP that are implementation-dependent. One example or embodiment of theCFDP library 206 is shown in theCFDP library apparatus 300 inFIG. 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 thespace 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. - 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 anapparatus 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 alibrary 206 that is compliant with Consultative Committee for Space Data Systems (CCSDS) file delivery protocol (CFDP). TheCFDP 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. TheCFDP 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 includesservice classes CFDP library 206 is single-tasking, single-threaded, and requires a small amount of memory. TheCFDP library 206 implements a generic interface to the space links 102 and generic interfaces to the data storage system interfaces. TheCFDP library 206 is delivered with sample user code for a complete sample application. TheCFDP library 206 is delivered with an automated test facility that validates the sample application. TheCFDP library 206 is reusable, from mission to mission, for both flight and ground software. TheCFDP 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 theCFDP 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 asubroutine 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 asubroutine 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). APDU 212 is a message between a sender and a receiver. The library user provides PDUs to theCFDP library 206 from CFDP partners. Each PDU is passed to theCFDP library 206 by calling asubroutine 212. - Some embodiments of
system 200 include one or more cycle transaction(s) 214. TheCFDP library 206 uses a polling mechanism to meteroutgoing PDUs 214. TheCFDP 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). TheCFDP library 206 generates outgoing PDUs and uses threecallback routines 216 described to output outgoing PDUs. TheCFDP 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 theCFDP library 206. TheCFDP 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. TheCFDP 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. TheCFDP library 206 allows the user to enable/disable certain Indications (by modifying a header or in included source code file). TheCFDP 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). TheCFDP library 206 also defines a callback routine to be called each time anindication 220 occurs by default, the callback routine is null (meaning that no routine is called). If desired, the library user may implement anindication 220 callback routine and register theindication 220. - Some embodiments of
system 200 include one or more text message(s) 222. TheCFDP library 206outputs 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 setsubroutine 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 setsubroutine 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 aCFDP 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 theCFDP library apparatus 206 inFIG. 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. TheCFDP library apparatus 300 includes state machines and/or callback routines, allowing a user of theCFDP 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, theCFDP 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, theCFDP 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’). Ashell 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 1sender 308,Service Class 1receiver 310,Service Class 2sender 312 andService Class 2receiver 314. For example, if CFDP-compliant entity is usingService Class 2 to send a file to another CFDP-compliant entity, then theService Class 2 sender state table 314 logic will be used. - In regards to the
state machines 306, every transaction that sends a file usingService 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 astate machine 306. At any given time, the library maintains aseparate state machine 306 for each active transaction. - The
shell 304 manages the state machine(s) 306. Theshell 304 receives incoming user request(s) 210 and incoming PDU(s) 212, and theshell 304 routes incoming user request(s) 210 and incoming PDU(s) 212 to theappropriate state machine 306. One example of an appropriate state machine is a state machine that is assigned to a particular file transfer transaction. Anew 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 atemporary file 320 outside theCFDP 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,” theincoming 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 theCFDP library apparatus 300 to handle the situation in which a metadata PDU is dropped, in which case, theCFDP 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 ofuser requests 210 andincoming PDUs 212 to the library user. The library user passes eachincoming user request 210 andPDU 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 thePDU 216 according to the specifications of the user. When theCFDP library apparatus 300 has aPDU 212 to send, theCFDP library apparatus 300 buffers thePDU 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 theCFDP 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, theCFDP library apparatus 300 assumes that the user of theCFDP 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. - 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 amethod 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, atblock 402 inFIG. 4 .Outgoing file transfers 402 are initiated or performed after receiving a user request provided/sent a user to the CFDP library, atblock 404.Initiation 402 of the file transfer starts a state machine, atblock 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 inFIG. 3 . -
FIG. 5 is a flowchart of amethod 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, atblock 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 inFIG. 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 asprocessor 604 inFIG. 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 inFIG. 6 , or on at least as many computers as there are components. -
FIG. 6 is a block diagram of a hardware andoperating environment 600 in which different embodiments can be practiced. The description ofFIG. 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 aprocessor 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 asystem bus 612, that operatively couples various system components to theprocessing unit 604. Thememory 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. Theprocessor 604 executes computer programs stored on the computer-accessible media. -
Computer 602 can be communicatively connected to theInternet 614 via acommunication device 616.Internet 614 connectivity is well known within the art. In one embodiment, acommunication 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, acommunication 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 akeyboard 618 or apointing device 620. Thekeyboard 618 permits entry of textual information intocomputer 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 anyparticular 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 adisplay device 622.Display device 622 is connected to thesystem 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 anyparticular 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 Speakers system bus 612. -
Computer 602 also includes an operating system (not shown) that is stored on the computer-accessible media RAM 606,ROM 608, andmass storage device 610, and is executed by theprocessor 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 ofcomputer 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 ofcomputer 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 asremote computer 628. These logical connections are achieved by a communication device coupled to, or a part of, thecomputer 602. Embodiments are not limited to a particular type of communications device. Theremote 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 inFIG. 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 andremote computer 628 are connected to thelocal network 630 through network interfaces oradapters 634, which is one type ofcommunications device 616.Remote computer 628 also includes anetwork device 636. When used in a conventional WAN-networking environment, thecomputer 602 andremote computer 628 communicate with aWAN 632 through modems (not shown). The modem, which can be internal or external, is connected to thesystem bus 612. In a networked environment, program modules depicted relative to thecomputer 602, or portions thereof, can be stored in theremote computer 628. -
Computer 602 also includespower supply 638. Each power supply, for example, can be a battery. Internal and external power supplies are well-known in the art. - 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 (21)
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.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/869,288 US20080250118A1 (en) | 2007-02-27 | 2007-10-09 | Systems, methods, and apparatus of a space communication file transfer system |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US89184607P | 2007-02-27 | 2007-02-27 | |
US11/869,288 US20080250118A1 (en) | 2007-02-27 | 2007-10-09 | Systems, methods, and apparatus of a space communication file transfer system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20080250118A1 true US20080250118A1 (en) | 2008-10-09 |
Family
ID=39827931
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/862,550 Expired - Fee Related US7922920B2 (en) | 2007-02-27 | 2007-09-27 | Systems, methods, and apparatus of a low conductance silicon micro-leak for mass spectrometer inlet |
US11/869,288 Abandoned US20080250118A1 (en) | 2007-02-27 | 2007-10-09 | Systems, methods, and apparatus of a space communication file transfer system |
US12/889,014 Expired - Fee Related US8455926B2 (en) | 2007-02-27 | 2010-09-23 | Systems, methods, and apparatus of a low conductance silicon micro-leak for mass spectrometer inlet |
US12/888,973 Expired - Fee Related US8742468B2 (en) | 2007-02-27 | 2010-09-23 | Systems, methods and apparatus of a low conductance silicon micro-leak for mass spectrometer inlet |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/862,550 Expired - Fee Related US7922920B2 (en) | 2007-02-27 | 2007-09-27 | Systems, methods, and apparatus of a low conductance silicon micro-leak for mass spectrometer inlet |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/889,014 Expired - Fee Related US8455926B2 (en) | 2007-02-27 | 2010-09-23 | Systems, methods, and apparatus of a low conductance silicon micro-leak for mass spectrometer inlet |
US12/888,973 Expired - Fee Related US8742468B2 (en) | 2007-02-27 | 2010-09-23 | Systems, methods and apparatus of a low conductance silicon micro-leak for mass spectrometer inlet |
Country Status (1)
Country | Link |
---|---|
US (4) | US7922920B2 (en) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140047448A1 (en) * | 2012-08-10 | 2014-02-13 | Honeywell International Inc. | Systems and methods for limiting user customization of task workflow in a condition based health maintenance system |
CN103856304A (en) * | 2014-02-21 | 2014-06-11 | 北京神舟航天软件技术有限公司 | Reliable file transmission protocol with selectable safety levels |
US8832649B2 (en) | 2012-05-22 | 2014-09-09 | Honeywell International Inc. | Systems and methods for augmenting the functionality of a monitoring node without recompiling |
US8990770B2 (en) | 2011-05-25 | 2015-03-24 | Honeywell International Inc. | Systems and methods to configure condition based health maintenance systems |
US9037920B2 (en) | 2012-09-28 | 2015-05-19 | Honeywell International Inc. | Method for performing condition based data acquisition in a hierarchically distributed condition based maintenance system |
CN108075821A (en) * | 2017-11-22 | 2018-05-25 | 西南电子技术研究所(中国电子科技集团公司第十研究所) | Interrupted unicom deep space network data storage and transmission method |
CN108090514A (en) * | 2017-12-27 | 2018-05-29 | 西南石油大学 | Infrared image recognition based on two benches Density Clustering |
US10481943B2 (en) * | 2016-12-30 | 2019-11-19 | Winmore, Inc. | System and method for state machine management |
CN114185825A (en) * | 2021-10-25 | 2022-03-15 | 西安空间无线电技术研究所 | Architecture system based on multi-service working mode |
CN116232442A (en) * | 2023-05-08 | 2023-06-06 | 银河航天(北京)网络技术有限公司 | Communication method, device and storage medium based on TCP/IP protocol and CCSDS protocol |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7922920B2 (en) * | 2007-02-27 | 2011-04-12 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Systems, methods, and apparatus of a low conductance silicon micro-leak for mass spectrometer inlet |
WO2014191746A1 (en) * | 2013-05-31 | 2014-12-04 | Micromass Uk Limited | Compact mass spectrometer |
WO2014191747A1 (en) | 2013-05-31 | 2014-12-04 | Micromass Uk Limited | Compact mass spectrometer |
WO2014191750A1 (en) | 2013-05-31 | 2014-12-04 | Micromass Uk Limited | Compact mass spectrometer |
US10096458B2 (en) | 2013-05-31 | 2018-10-09 | Micromass Uk Limited | Compact mass spectrometer |
GB2541876B (en) | 2015-08-27 | 2019-05-29 | Microsaic Systems Plc | Microengineered skimmer cone for a miniature mass spectrometer |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6690934B1 (en) * | 1997-10-24 | 2004-02-10 | Universal Space Network, Inc. | Multiple access satellite communications network |
US20040043725A1 (en) * | 1998-10-27 | 2004-03-04 | Fujitsu Limited | Time synchronization system, satellite system applied to the time synchronization system, ground system applied in the time synchronization system, time synchronization method and a computer-readable recording medium with a program |
US20040252053A1 (en) * | 2003-06-13 | 2004-12-16 | Harvey A. Stephen | Security system including a method and system for acquiring GPS satellite position |
US20060209737A1 (en) * | 2005-03-18 | 2006-09-21 | Barnhart Randy C | Data handling in a distributed communication network |
US7400274B2 (en) * | 2000-10-03 | 2008-07-15 | Realtime Data Llc | System and method for data feed acceleration and encryption |
US20080294749A1 (en) * | 2007-05-21 | 2008-11-27 | Derenge Charles L | System and method for globally sharing fms data or other files from aerial platforms or other sources anywhere in the world |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4394998A (en) | 1981-05-18 | 1983-07-26 | Office National D'etudes Et De Recherche Aerospatiales (Onera) | Process and apparatus for exploring the atmosphere of a planet |
US4492110A (en) | 1983-06-01 | 1985-01-08 | Martin Marietta Corporation | Ultra sensitive noble gas leak detector |
US5010776A (en) | 1989-05-04 | 1991-04-30 | Iit Research Institute | Environmental contamination detection and analyzing system and method |
US5313061A (en) | 1989-06-06 | 1994-05-17 | Viking Instrument | Miniaturized mass spectrometer system |
US5164593A (en) | 1991-02-28 | 1992-11-17 | Kratos Analytical Limited | Mass spectrometer system including an ion source operable under high pressure conditions, and a two-stage pumping arrangement |
US5175431A (en) | 1991-03-22 | 1992-12-29 | Georgia Tech Research Corporation | High pressure selected ion chemical ionization interface for connecting a sample source to an analysis device |
US5566909A (en) | 1993-09-08 | 1996-10-22 | Hughes Aircraft Company | System and method for deploying multiple probes |
US6635163B1 (en) * | 1999-06-01 | 2003-10-21 | Cornell Research Foundation, Inc. | Entropic trapping and sieving of molecules |
US6613561B1 (en) * | 1999-11-26 | 2003-09-02 | Olympus Optical Co., Ltd. | High-density capillary array for reaction and detection of fluid |
JP3993372B2 (en) * | 2000-09-13 | 2007-10-17 | 独立行政法人理化学研究所 | Reactor manufacturing method |
JP2003117833A (en) * | 2001-10-15 | 2003-04-23 | Shin Etsu Chem Co Ltd | Polishing plate |
US6864487B1 (en) | 2002-01-21 | 2005-03-08 | Mcmurtry Gary M | Environmental sampler for mass spectrometer |
GB2391694B (en) * | 2002-08-01 | 2006-03-01 | Microsaic Systems Ltd | Monolithic micro-engineered mass spectrometer |
JP4556158B2 (en) * | 2002-10-22 | 2010-10-06 | 株式会社Sumco | Method for manufacturing bonded SOI substrate and semiconductor device |
US7147695B2 (en) * | 2002-12-13 | 2006-12-12 | New Jersey Institute Of Technology | Microfabricated microconcentrator for sensors and gas chromatography |
WO2005001879A2 (en) | 2003-02-14 | 2005-01-06 | Mds Sciex | Atmospheric pressure charged particle discriminator for mass spectrometry |
US6967326B2 (en) | 2004-02-27 | 2005-11-22 | Lucent Technologies Inc. | Mass spectrometers on wafer-substrates |
US7145136B2 (en) | 2004-12-17 | 2006-12-05 | Varian, Inc. | Atmospheric pressure ionization with optimized drying gas flow |
US7922920B2 (en) * | 2007-02-27 | 2011-04-12 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Systems, methods, and apparatus of a low conductance silicon micro-leak for mass spectrometer inlet |
-
2007
- 2007-09-27 US US11/862,550 patent/US7922920B2/en not_active Expired - Fee Related
- 2007-10-09 US US11/869,288 patent/US20080250118A1/en not_active Abandoned
-
2010
- 2010-09-23 US US12/889,014 patent/US8455926B2/en not_active Expired - Fee Related
- 2010-09-23 US US12/888,973 patent/US8742468B2/en not_active Expired - Fee Related
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6690934B1 (en) * | 1997-10-24 | 2004-02-10 | Universal Space Network, Inc. | Multiple access satellite communications network |
US20040043725A1 (en) * | 1998-10-27 | 2004-03-04 | Fujitsu Limited | Time synchronization system, satellite system applied to the time synchronization system, ground system applied in the time synchronization system, time synchronization method and a computer-readable recording medium with a program |
US7400274B2 (en) * | 2000-10-03 | 2008-07-15 | Realtime Data Llc | System and method for data feed acceleration and encryption |
US20040252053A1 (en) * | 2003-06-13 | 2004-12-16 | Harvey A. Stephen | Security system including a method and system for acquiring GPS satellite position |
US20060209737A1 (en) * | 2005-03-18 | 2006-09-21 | Barnhart Randy C | Data handling in a distributed communication network |
US20080294749A1 (en) * | 2007-05-21 | 2008-11-27 | Derenge Charles L | System and method for globally sharing fms data or other files from aerial platforms or other sources anywhere in the world |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8990770B2 (en) | 2011-05-25 | 2015-03-24 | Honeywell International Inc. | Systems and methods to configure condition based health maintenance systems |
US8832649B2 (en) | 2012-05-22 | 2014-09-09 | Honeywell International Inc. | Systems and methods for augmenting the functionality of a monitoring node without recompiling |
US20140047448A1 (en) * | 2012-08-10 | 2014-02-13 | Honeywell International Inc. | Systems and methods for limiting user customization of task workflow in a condition based health maintenance system |
US8832716B2 (en) * | 2012-08-10 | 2014-09-09 | Honeywell International Inc. | Systems and methods for limiting user customization of task workflow in a condition based health maintenance system |
US9037920B2 (en) | 2012-09-28 | 2015-05-19 | Honeywell International Inc. | Method for performing condition based data acquisition in a hierarchically distributed condition based maintenance system |
CN103856304A (en) * | 2014-02-21 | 2014-06-11 | 北京神舟航天软件技术有限公司 | Reliable file transmission protocol with selectable safety levels |
US10481943B2 (en) * | 2016-12-30 | 2019-11-19 | Winmore, Inc. | System and method for state machine management |
CN108075821A (en) * | 2017-11-22 | 2018-05-25 | 西南电子技术研究所(中国电子科技集团公司第十研究所) | Interrupted unicom deep space network data storage and transmission method |
CN108090514A (en) * | 2017-12-27 | 2018-05-29 | 西南石油大学 | Infrared image recognition based on two benches Density Clustering |
CN114185825A (en) * | 2021-10-25 | 2022-03-15 | 西安空间无线电技术研究所 | Architecture system based on multi-service working mode |
CN116232442A (en) * | 2023-05-08 | 2023-06-06 | 银河航天(北京)网络技术有限公司 | Communication method, device and storage medium based on TCP/IP protocol and CCSDS protocol |
Also Published As
Publication number | Publication date |
---|---|
US8742468B2 (en) | 2014-06-03 |
US20110097541A1 (en) | 2011-04-28 |
US7922920B2 (en) | 2011-04-12 |
US20090110880A1 (en) | 2009-04-30 |
US8455926B2 (en) | 2013-06-04 |
US20110095181A1 (en) | 2011-04-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20080250118A1 (en) | Systems, methods, and apparatus of a space communication file transfer system | |
US6115744A (en) | Client object API and gateway to enable OLTP via the internet | |
EP1308844B1 (en) | System and method for monitoring an application on a server | |
Huang et al. | LCM: Lightweight communications and marshalling | |
US6628965B1 (en) | Computer method and system for management and control of wireless devices | |
US7260623B2 (en) | Remote services system communication module | |
US20070047279A1 (en) | Middleware method and apparatus and program storage device adapted for linking data sources to software applications | |
US20020161903A1 (en) | System for secure access to information provided by a web application | |
US20020046301A1 (en) | System and method for integrating disparate networks for use in electronic communication and commerce | |
US20040117435A1 (en) | Common persistence layer | |
US20020002599A1 (en) | Real-time global positioning system application in two-way mobile wireless networks | |
US20030212738A1 (en) | Remote services system message system to support redundancy of data flow | |
US20060248145A1 (en) | System and method for providing various levels of reliable messaging between a client and a server | |
Kon et al. | 2k: A reflective component-based operating system for rapidly changing environments | |
EP1766824A2 (en) | System and method for extending business systems to a mobile workforce | |
Myerson | The complete book of middleware | |
WO2001009721A2 (en) | A system, method and article of manufacture for providing an interface between a first server and a second server. | |
US7529840B2 (en) | HTTP use for bidirectional communication | |
US20050060169A1 (en) | Frameworks for integrating information systems | |
US20020161828A1 (en) | System and method for communicating with a device | |
US7206977B2 (en) | Intelligent self-configurable adapter | |
Marszk et al. | MO services and CFDP in action on OPS-SAT | |
Shehory et al. | The RETSINA communicator | |
US7231437B2 (en) | Task submission systems and methods for a distributed test framework | |
Cutler et al. | A framework for robust and flexible ground station networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: UNITED STATES OF AMERICA AS REPRESENTED BY THE ADM Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:RAY, TIMOTHY J., MR.;REEL/FRAME:020118/0916 Effective date: 20071029 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |