STRS software architecture. POSIX, Portable Operating System Interface; RTOS, real-time operating system; HAL, Hardware Abstraction Layer; API, application programming interface; FPGA, field-programmable gate array. (See http://www.uml.org for a detailed explanation of the notation in this figure.)
Long description of figure 1.
This year, the Space Telecommunications Radio System (STRS) project investigated various software-defined radio architectures suitable for NASAs missions subject to the constraints of the space environment. The STRS architecture was developed at the NASA Glenn Research Center and includes both use cases and Unified Modeling Language (UML; see http://www.uml.org) diagrams. The STRS architecture (see the preceding UML figure) separates the STRS operating environment (OE) from its various waveform applications and abstracts any specialized hardware to limit its effect on the operating environment. The STRS OE enables the startup, operation, and teardown of the waveform applications. The waveform applications are implemented in firmware and software to transform information to or from signals that are transmitted over the air. Separating functionality within the radio promotes waveform portability and reuse.
The processing capability of the software-defined radio enables the radio to implement functionality previously limited to the flight computer. The command and control subsystem validates commands from the flight computer and translates them to appropriate method calls.
When a waveform function becomes a required part of the radio, the waveform is transitioned to a service by being configured as part of the infrastructure. Examples of functions likely to become part of the STRS infrastructure are the Global Positioning System (GPS) or ranging, navigation, and dynamic discovery service.
Use cases capture the requirements of a system by describing how the system should interact with the users or other systems (the actors) to achieve a specific goal. The following diagram shows groupings of the use cases and how the actors are involved. Use cases are textual and contain a description, information about the external actors, related use cases, preconditions, a triggering event, a resulting event, postconditions, and a sequential list of the steps necessary to accomplish the desired result and alternatives.
Top-level use case diagram.
Long description of figure 2.
The users are shown as stick figures both inside and outside of the spacecraft system boundary. The over-the-air users communicate with or control the radio by means of a communication channel realized by the STRS radio itself. The STRS command-and-control users communicate with the radio via an onboard interface. The ground station can configure a waveform over the air directly or can configure a waveform indirectly by sending the command to the onboard flight computer by means of another radio. This is why the ground station is shown twice. The interaction of the ground station and the flight computer shown on the right indicates that the ground station uses the flight computer to command the STRS radio.
Use cases identified for the STRS architecture follow:
Last updated: September 6, 2007
Responsible NASA Official:
Gynelle.C.Steele@nasa.gov
216-433-8258
Point of contact for NASA Glenn's Research & Technology reports:
Cynthia.L.Dreibelbis@nasa.gov
216-433-2912
SGT, Inc.
Web page curator:
Nancy.L.Obryan@nasa.gov
216-433-5793
Wyle Information Systems, LLC
