National Aeronautics and Space Administration

Glenn Research Center


Frequently Asked Questions

Table of Contents

(Skip to contents.)

4.1 Operational Requirements
4.2 Operating Environment (OE) Requirements
4.3 Documentation Requirements
4.4 Source Code Requirements
4.5 Configuration File or Script File Recommendation
4.6 Roles and Responsibilities
5.1 How to Associate an FPGA with an STRS Application
5.2 How to Load an FPGA
5.3 How to Set Attributes
5.4 How to Get Attributes
5.5 How to Push Packets
5.6 How to Pull Packets
5.7 How to Process Errors
5.8 How to Make Multiple Instances of an Application
5.9 How to Map Memory Locations
5.10 When to Use STRS_Log and STRS_Write
5.11 Difference Between Run Test and Ground Test
5.12 When to Use Start/Stop, Load/Unload, and Open/Close
5.13 How to Read and Write Data
5.14 How to Add Asynchronous Publisher/Subscriber Functionality
6.1 Fault State and Use of the ERROR, WARNING, and FATAL Queues
6.2 Pub/Sub Messaging and Queues Need Clarification
6.3 What is an STRS Device?
6.4 How to Configure and Control SDR Hardware
6.5 STRS Infrastructure Methods Do Not Belong to Any Class
6.6 Explain Clocks and Timers
6.7 FPGA Partial Reconfiguration
6.8 Compliance Testing
6.9 Configuration Files Examples
6.10 C Language Naming Duplication
6.11 Sequence Diagrams Depicting STRS API Calls
6.12 Why are APP_Instance and APP_Initialize Separate?
6.13 Why Start with SCA?
6.14 Security for STRS
6.15 What is Configurable Hardware Design?
6.16 Why is there STRS_InstantiateAPP and no STRS_Instance method?
6.17 Uniqueness of Handle Names and IDs
6.18 Are there any exception-safety rules?
6.19 What does it mean that an STRS Device or STRS Service may be part of the OE?
6.20 How does the application know how to put the data (address, command, data) into the buffer in the specialized hardware?
6.21 Can STRS applications run in multiple address spaces?
6.22 Does an STRS application require a main entry point?
6.23 How is STRS_TimeSynch used to adjust time?
6.24 How is Clock Rate Adjustment Used?
6.25 What is OE-Specified String for the Application to be Instantiated?
6.26 STRS Radio Startup Process, Platform Diagnostics, and Built-in Test?
6.27 Cognitive, Navigation, and Other Services
6.28 C and C++ Compatibility?
A Example Configuration Files
A.1 STRS Platform Configuration File Hardware Example
A.2 STRS Platform Configuration File Software Example
A.3 STRS Application Configuration File Example

Go to top.

4.1 Operational Requirements

Many Level 1 requirements describe what the architecture has to allow in the way of operations. However, any mission determines which of these are to be implemented in its specific radios to support the mission’s needs. In NASA-STD-4009A, requirements were written in a layered way so as to describe many architectural requirements in terms of applications, devices, services, other artifacts, and how they are used to perform the necessary functions.

The Level 1 requirements include responding to commands sent from an external source for remote reconfiguration, remote reprogrammability, processor sharing, and commanded Built-In-Test (BIT) and status reporting. These Level 1 requirements become part of the rationale for those requirements in NASA-STD-4009A pertaining to the startup and configuration of the radio as well as commanding the radio and obtaining information back about the configuration and command success.

Go to top.

4.2 Operating Environment (OE) Requirements

The STRS OE, as used in NASA-STD-4009A, is the software environment in which the STRS applications are executed. Because an STRS radio is really a computer, it has an operating system (OS) usually created separately from the STRS infrastructure. Using an OS promotes the STRS goals and objectives for flexibility, decreasing development time and cost, and increasing the reliability of SDRs, by leveraging existing standards, resources, and experience. A real-time operating system (RTOS) is likely to be used to meet timing deadlines and to support other operations, even though most of the real-time capability currently resides in field programmable gate arrays (FPGAs). Furthermore, an OS will need real-time capability if the general purpose processors (GPPs) are faster and assume more of the telecommunication functions or if the mission’s telemetry requirements are stringent enough to warrant using an RTOS to be able to achieve processing constraints.

The Portable Operating System Interface (POSIX®) is a standard that is used by many OSs. Therefore, POSIX® was chosen to implement certain functions missing from the list of STRS Application-provided methods to minimize duplication of methods between STRS and POSIX®.

Go to top.

4.3 Documentation Requirements

NASA-STD-4009A requires specific information to be delivered with an STRS-compliant platform and application. This information is requested to support the goals and objectives for extensibility, adaptability, portability, reusability, and vendor independence. The specific mission procuring the platform and/or application will require additional documentation to integrate and operate the platform and/or application with the rest of the system for the mission.

The hardware abstraction layer (HAL) documentation is required by STRS to allow, for example, the independence of the providers of the infrastructure and the FPGA. The basic goals and objectives include accommodating advances in technology with minimal rework (extensibility) and maintaining vendor independence. The STRS infrastructure has access to the HAL, and the HAL is specific to a platform. Since STRS is designed for the applications to be as portable as possible, STRS hides the HAL from the STRS application using a bridge pattern so that an STRS application can use a standardized application program interface (API) to interact with any specialized hardware.

Go to top.

4.4 Source Code Requirements

Because of size, weight, and power (SWaP) restrictions for space, many of the requirements in the Department of Defense’s Software Communications Architecture (SCA) version 2.2 were eliminated for STRS. These include eliminating the requirement for Common Object Request Broker Architecture (CORBA) and the onboard parsing of the Extensible Markup Language (XML). Although object-oriented Unified Modeling Language (UML) diagrams were used for parts of the description to clarify relationships, they did not become part of the requirements. As described in the Case Study, STRS was able to use almost the same PIM as the OMG’s SWRADIO to come up with a very different implementation.

Because the STRS architecture needed to support a C language interface to minimize SWaP, a pure object-oriented approach was unsatisfactory. To encapsulate functionality in a consistent manner, APIs were defined and the corresponding #include files were required to constrain the method signatures appropriately. A subset of the infrastructure APIs was required to call the appropriate application API. Because of the C language interface, the methods were differentiated so that the STRS infrastructure APIs had a different naming convention and two additional arguments:

  1. The fromWF argument in many of the STRS infrastructure APIs is the handle identification (ID) used to indicate who the caller or source is.
  2. The toWF argument in many of the STRS infrastructures APIs is the handle ID used to indicate who the responder or destination is. The STRS infrastructure uses the toWF to determine which application, device, file, or queue is to be used to perform any further processing. Then the infrastructure-provided method usually calls the corresponding Application-provided method.

A handle ID is used to control access to applications, devices, and so forth. The fromWF and toWF may be used by the infrastructure to validate whether the method is allowed to be called and to keep track of the history of the method call for error processing. They are used by the infrastructure when creating log messages to indicate the source of an error.

It is up to the infrastructure provider whether the handle ID is an index into a table, or an address of a structure, or a hash value used to look up the information that the infrastructure uses to access the application, device, file, or queue. The only restriction imposed by STRS is that a negative value indicates an error. It is the responsibility of the infrastructure to keep any additional information needed to intelligently populate the error logs. Each application is informed of its own handle ID and handle name using APP_Instance. The application uses its own handle ID as the fromWF argument to most STRS infrastructure-provided methods. There should be a handle ID for the infrastructure (or portions thereof) to indicate when the infrastructure is the source for error messages.

After considering the functionality required by the use cases and OMG SWRADIO profile, there needed to be APIs to standardize additional portions of the software. Therefore, APIs were created for devices, message queues, files, and timing. Some others were left to POSIX® to implement.

Go to top.

4.5 Configuration File or Script File Recommendation

Configuration files or script files are recommended as a self-documenting way for the STRS infrastructure to start STRS applications into a known state to support the Level 1 requirements for remote partial configuration, reconfigurability, adaptability, automated system recovery and initialization, and multiple waveform support. The basic requirement derives from the need for each component to start in a known state. Requirement STRS-1 produces a known state for the platform. Using application configuration files or script files produces a known state for the applications. The infrastructure configuration files are suggested to allow for evolution of the hardware and software in a standard way.

Using an application configuration file addresses the variability regarding what resources may be needed by the application, what variables need to be defined, and what state changes need to be made. There is not necessarily a one-to-one correspondence between an application and a loadable file. A loadable file can contain parts of multiple applications; likewise, an application can span multiple loadable images. In a common case, a single application has both a GPP part and an FPGA part. Another case occurs for the OS-like Real-Time Executive for Multiprocessor Systems (RTEMS), a free open-source RTOS designed for embedded systems, which does not support dynamic loading. In that case, there is no need to include separate information on the GPP part of an application, since the build process does not make a loadable image for the application alone, separate from the infrastructure.
The application configuration files allow for the same application to be configured for different situations. For example, the environment may vary over the life of the radio and parameters may need to be adjusted accordingly. Another example might be allowing the original frequencies defined in a configuration file to be updated to avoid interference. It is less risky to send a short data file to the radio than to send a full software load. A current example for one of the SCaN Testbed SDRs is that the software and/or configurable hardware design has to remain stable at a certain point in the development process so that code review and test can be completed. However, there are parameters that are environmentally sensitive and can only be determined by testing under environmental conditions that simulate the conditions of space. These parameters are determined and entered into the application configuration file. A new application configuration file is then added to the SDR, but the software and configurable hardware design used for the code review and test remain unchanged.

When the waveform application is started, the state, resources, and the configurable parameters can be specified in a configuration file or script so that any reinitialization is predictable. For example, if the radio needs to cycle power to correct some glitch, it should be able to do so and restart the application without intervention. The project manager may require the inclusion of “initial or default values for all distinct operationally configurable parameters.” The “operationally configurable parameters” were those that could be configured using the STRS_Configure/APP_Configure commands instead of using subordinate parameters that do not have to be configured separately or using merely queryable parameters. For example, if a data item can be initialized in multiple ways such as having parameters for both frequency and wavelength, only one would need to be configured. Also, a parameter could be queryable but not configurable (e.g., temperature, location, and power consumption).

When the project manager specifies a requirement for a configuration file, XML is recommended as a good starting point. The reasons for using XML for the predeployed application configuration files are as follows:

  1. Using XML allows the data to have a standardized format that is easily created, read, and used by multiple entities.
  2. XML is easy to learn, does not require much overhead, and is a World Wide Web Consortium (W3C) free and open standard.
  3. Using XML saves time and money since tools already exist for displaying, editing, validating, parsing, and other functions.
  4. Using XML allows the data to be self-documenting.
  5. An exact format for the predeployed configuration files is not specified because the infrastructure for each vendor may need different information to start an application. The data in the application configuration files may not always be just name/value pairs.
  6. Using XML allows for hierarchical as well as sequential data. Using hierarchical data allows for greater complexity. Using XML does not hinder the data from being used sequentially or in a specific order.
  7. XML is easily transformed to more compact forms such that only the relevant subset appears in the deployed configuration file. The minimum data could be identification, any resources loaded, any parameters configured, and ending state information.
  8. Using XML allows the STRS integrators to be able to verify that the data they enter meet some specified criteria so that the creation of the deployed configuration file will work properly.
  9. STRS began as an approach to adapt SCA for NASA space applications. A waveform application was implemented using SCA and from that, it was apparent that having CORBA and an XML parser in the radio added quite a lot to the complexity, size, and weight. STRS eliminated the need for CORBA, dynamic features, and an XML parser in the OE. So, the best resolution was having XML to start with and a processed file to deploy on the radio.
  10. The SCA’s properties files in XML could be used for STRS with minimal changes. An Extensible Stylesheet Language Transformation (XSLT) could be written to transform an SCA properties file into any deployed format.
  11. Using XML allows validation of input values. Part of the compliance testing is to verify that the configuration file follows the format specified in the schema. Using an XML schema saves NASA from having to keep a different validation tool for each vendor.
  12. Using XML allows data to be labeled with tags and attribute names so that the data are more easily validated and changed. The minimum was specified for the format of the application configuration files so that each vendor could use the format appropriate to that vendor’s implementation. For example, here are some alternatives for a “wait” command in XML:
    1. <command>wait 100</command>
    2. <wait>100</wait>
    3. <wait delay=”100″/>
    4. <wait delay=”100″ units=”microseconds”/>
    5. <wait> <delay>100</delay> <units>microseconds</units> </wait>

    Validation is difficult for alternative (1) using a schema. When the data “100” is separately identified, as in alternatives (2)-(5), it is easier to validate using a schema. When “100” is labeled as a delay, it is easier for multiple entities to identify and modify. Alternative (3) is not really better than (2) because the word delay does not add to the definition of the number significantly but adding the units does. When the “100” is labeled as a delay in microseconds, as in alternatives (4)-(5), it is even easier for multiple entities to identify and modify. Both (4) and (5) contain the same explanatory information and may be clearly checked by a schema. Which one may be considered optimal depends on the ability to transform the data into a deployed format.

XML 1.0 is recommended because the standards state that even though XML 1.1 is the current version, “You are encouraged to create or generate XML 1.0 documents if you do not need the new features in XML 1.1.” Furthermore, an error was obtained when using XMLSpy, a commercial-off-the-shelf (COTS) software product for testing with XML 1.1.

To avoid the drawback of requiring an XML parser to be part of the radio, the STRS allows the configuration files to be preprocessed into a simpler form. Although XSLT is suggested in NASA-STD-4009A as a simple mechanism for this transformation, it is not required. Alternatively, the preprocessing could be handled by a program or script. Although a manual process using a text editor is not impossible, an automated process is preferred.

The following state diagram, figure 1, STRS Application Recommended State Diagram, shows that an STRS application can have various states during execution. The files for the STRS application are to be accessible before execution can begin.

  • STRS_InstantiateApp causes the deployed configuration file to be parsed and APP_Instance or the constructor to be called such that the STRS application starts in the INSTANTIATED state, but it may be transitioned to another state if specified in the STRS application configuration file.
  • STRS_Initialize calls APP_Initialize on the appropriate STRS application.
  • APP_Initialize transitions the STRS application to the STOPPED state upon successful completion.
  • STRS_Start calls APP_Start on the appropriate STRS application.
  • APP_Start transitions the STRS application from the STOPPED state to the RUNNING state upon successful completion.
  • STRS_Stop calls APP_Stop on the appropriate STRS application.
  • APP_Stop transitions the STRS application from the RUNNING state to the STOPPED state upon successful completion.
  • When either APP_RunTest or APP_GroundTest is called, the application may be transitioned from the STOPPED state to a TESTING state, if necessary.
  • STRS_ReleaseObject calls APP_ReleaseObject on the appropriate STRS application.
  • The FAULT state may be set by the STRS application or detected by the fault monitoring and recovery functions, but any recovery is managed by the STRS infrastructure or by an external system.

The STRS application internal states shown in figure 1 are suggested. The STRS application developer may define and use any additional internal states that the STRS application developer sees fit. The infrastructure may use any additional states that are deemed necessary.

STRS Application Recommended State Diagram
Figure 1 – STRS Application Recommended State Diagram (D)

Go to top.

4.6 Roles and Responsibilities

For STRS, roles are specified as abstractions for the responsible organizations. The roles and corresponding organizations are expected to change at different stages of the radio’s life cycle. For example, a developer or provider of some component may act as an STRS integrator for that component and other components at a subsequent stage of production. Then, that STRS integrator may act as a provider for the next stage. NASA’s goals are to promote vendor independence, scalability, flexibility, and extensibility while specifying the smallest number of clearly defined roles possible.

The basic roles that NASA-STD-4009A defines are the STRS platform provider, who delivers a platform upon which STRS applications can be executed, an STRS application developer who provides the desired functionality in the form of an STRS application, and an STRS integrator who is responsible for integrating the parts to work together. The STRS platform provider could subcontract for hardware and software, but the responsibility for coordination, integration, and delivery of the infrastructure and related artifacts would reside in one STRS platform provider organization.
The STRS platform provider would usually act as STRS application developer and STRS integrator for at least a sample application. The roles and associated products are depicted in figure 2, Roles and Products.

The roles could have been broken down differently, allowing for various combinations of providers and integrators that could be very complex. Some suggested roles were as follows:

  1. Application developer or provider.
  2. Application integrator (OE + applications).
  3. Configurable hardware design provider.
  4. HAL/board support package (BSP)/drivers provider.
  5. Hardware integrator.
  6. Hardware parts supplier.
  7. Infrastructure provider.
  8. Kernel integrator (OS + POSIX® + HAL).
  9. OE integrator (OS + POSIX® + HAL + infrastructure).
  10. OE provider (OS + POSIX® + HAL + infrastructure).
  11. Operator.
  12. OS provider.
  13. Platform integrator.
  14. Platform provider.
  15. POSIX® provider.
  16. Radio integrator (OE + applications).
  17. Radio operator (concerned with the mechanics of commanding the radio).
  18. Spacecraft operator (concerned with the functionality of the radio in the larger sense of including ground operations, experimenters, i.e., consumers of the data flowing through the radio).
  19. System integrator (the entity that puts the radio into a system).

Some of these roles are duplicates or overlap one another. There were multiple interpretations for some of the roles, causing confusion. Therefore, the roles were simplified. Although a few operator roles were suggested, the operator roles have no STRS requirements, so these roles were not included. The operator roles are required for specific missions or projects rather than for the STRS architecture. There are no STRS requirements for specific external commands and how the commands and data get to the STRS radio. There are no STRS requirements for a specific process for an operator to turn the radio on and off, send configuration commands, consume and source data, deal with configuration management of software uploads, and other functions. There are no STRS requirements for the radio link parameters and for the actions of the experimenters and consumers of the data flowing through the radio. These types of requirements are mission-specific and have to be included in the requirements for the particular mission or project, which are in addition to NASA-STD-4009A requirements.

Document preparer roles and reviewer roles are not included, because STRS has no requirements concerning the process by which the documents are generated. There will be mission or project requirements for additional roles (including stakeholders) not mentioned here, for which STRS has no requirements.

Roles and Products
Figure 2 – Roles and Products (D)

Go to top.

5.1 How to Associate an FPGA with an STRS Application

For an FPGA, there should be a corresponding STRS Device (GPP code) to control the FPGA and transfer data. The handle name of the STRS Device for each FPGA may be named differently, especially on different platforms. To make it easy for the STRS application to access the appropriate FPGA with maximum portability, the handle name of the STRS Device that corresponds to the appropriate FPGA should be a configurable attribute for the STRS application. The STRS application would use the attribute supplying the handle name to obtain the handle ID using STRS_HandleRequest. The application would use the resulting handle ID of the STRS Device to invoke the STRS Infrastructure-Provided Application Control API methods (NASA-STD-4009A, section 7.3.2) and STRS Infrastructure-Provided Device Control API methods (NASA-STD-4009A, section 7.3.6) to interact with the FPGA. A likely implementation would have any methods in the STRS Infrastructure-Provided Device Control API invoke the corresponding method in an STRS Device-Provided Device Control API. A sample of an STRS Device-provided Device Control API is shown in Figure 5, STRS Application/Device Structure, as the Device API.

For example, there might be FPGA1 and FPGA2 available. If WF1 uses FPGA2, a configuration file for WF1 could contain a name/value pair to associate the name useFPGA with FPGA2. Let the function getValue obtain the value corresponding to the given name. Then, the STRS application could access the correct FPGA, as follows:

  STRS_HandleID fromID = APP_GetHandleID();
  char* fpgaName = getValue("useFPGA");
  STRS_HandleID fpgaID = STRS_HandleRequest(fromID, fpgaName);
  STRS_Result rtn = STRS_ValidateHandleID(fpgaID);
  if ( ! STRS_IsOK( rtn )) { 
     STRS_Message msg = "Handle ID error for useFPGA."; 
     STRS_HandleID errQ = STRS_GetErrorQueue(rtn); 
     STRS_Log (fromID, errQ, msg, (STRS_Buffer_Size) sizeof(msg)); 

Go to top.

5.2 How to Load an FPGA

An FPGA may be loaded directly by the infrastructure when it parses the configuration file, if supported, or may be loaded by an STRS_DeviceLoad call from the application GPP code. If the latter method is used, the name of the bitstream file should also be a configurable attribute set with the APP_Configure method. The STRS_HandleRequest method should be called to obtain the handle ID for the FPGA Device, and then the STRS_DeviceLoad method should be called for the FPGA to load the bitstream file. These STRS infrastructure calls may be performed in the APP_Configure directly or in the APP_Start method, as appropriate.

Go to top.

5.3 How to Set Attributes

An FPGA may be configured directly by the infrastructure when it parses the configuration file or by an STRS_Configure call to the STRS Device for the FPGA call from the application GPP code. If the latter method is used, the handle name of the FPGA Device should also be a configurable attribute set with the APP_Configure method. The STRS_HandleRequest method should be called to obtain the handle ID for the FPGA Device, and then the STRS_Configure method should be called for the FPGA Device to configure the FPGA. These STRS infrastructure calls may be performed in the APP_Configure directly or in the APP_Start method, as appropriate.

Go to top.

5.4 How to Get Attributes

Not all specialized hardware can be interrogated for its configuration; however, the infrastructure or the application may maintain any configuration data needed. The application has to implement APP_Query and, if appropriate, it should call the STRS_HandleRequest to obtain the handle ID for the FPGA followed by an STRS_Query call to the STRS FPGA Device to obtain the configuration data from the FPGA.

Go to top.

5.5 How to Push Packets

To push packets from an application, to a device, queue, file, or another application, STRS_Write is used. For generating packets in the same application used to send the packets,
APP_Write may be used directly. If an application acts as a sink of packets pushed, it has to implement APP_Write, #include “STRS_Sink.h”; and if C++, the class has to implement STRS_Sink.

Go to top.

5.6 How to Pull Packets

To pull packets from a device, queue, file, or another application, STRS_Read is used. To pull packets from another module in the same application, APP_Read may be used directly. If an application acts as a source of packets pulled, it has to implement APP_Read, #include “STRS_Source.h”, and, if C++, the class has to implement STRS_Source.

Go to top.

5.7 How to Process Errors

When a call to an STRS method is made, a variable of type STRS_Result is usually returned. To ensure consistent testing for errors, where an error is usually a negative value, STRS_IsOK tests that variable of type STRS_Result for errors, and returns a true or false boolean variable. The value returned from STRS_IsOK is true when there is no error and false when there is an error so that appropriate action may be taken.

When an error is detected in the operation of the application, STRS_Log should be invoked using an error queue handle ID (STRS_FATAL_QUEUE, STRS_ERROR_QUEUE, or STRS_WARNING_QUEUE), and a descriptive message. The error queue handle ID can be determined using STRS_GetErrorQueue with the error return value as an argument. The error queues are monitored and passed to the infrastructure for further action.

The STRS methods use the error returns rather than using variable errno to indicate an error. STRS policy on errno is that it is undefined outside of the application methods. You cannot rely on it to indicate the particular error because it is not reset before system calls and may be reset to a different error later, before it is tested. It reduces portability by allowing different values on different operating systems with different compilers.

Go to top.

5.8 How to Make Multiple Instances of an Application

To create multiple instances of an application, be sure that the application is reentrant and that all pertinent data are configurable. Two configuration or script files may have to be created, if any of the initial data is different. A different handle name is specified for each instance. When using C language applications, there may be method name duplication, which is discussed further in section 6.10, C Language Naming Duplication.

Go to top.

5.9 How to Map Memory Locations

STRS Devices are allowed to use memory mapped locations in which storing/retrieving an item in shared memory automatically pushes/pulls the item to/from the specialized hardware. STRS Devices do not have to be portable, so non-standard methods may be encapsulated within an STRS Device. The STRS applications should not use the shared memory locations directly to communicate with the specialized hardware because that is not portable and violates the spirit of STRS. The addresses for the specialized hardware should not be defined in the application or its configuration file. Hard-coding of memory locations in an STRS application or STRS Device is strongly discouraged because hard-coding would limit the independence of the software and configurable hardware design and may cause problems with verification and validation if any FPGA code is changed that would affect that location.

There is no requirement that an STRS Device use configuration or script files containing location information, but it is strongly encouraged to be configured rather than hard-coded. Configuration data are usually specified in a configuration file where the OE parses the configuration file to call STRS_Configure and that calls APP_Configure in the STRS Device to accept the configuration data. However, there is nothing in the standard that restricts the OE from calling other method(s) such as DEV_SetMemoryMap(map) to specify more complicated configuration data. Similarly, a script file may be executed to call STRS_Configure and related commands.

The shared memory locations should be specified in the configuration or script files for the appropriate STRS Device. In the example of a configuration file shown in Appendix A for MEMORYMAP and MAPVALUE, there is a base name, associated relative location, offset, size, and access. These are illustrated in figure 3, Memory Map. The location for an individual item is specified relative to the base name in addressable storage units. The location may also have a bit offset and bit length. Then, when the configurable item is modified, the mapped location is used. In the example of an STRS Device shown in Figure 5, the OE can use the DEV_SetMemoryMap(map) method to configure the mapping in the STRS Device.

Memory Map
Figure 3 – Memory Map (D)

Go to top.

5.10 When to Use STRS_Log and STRS_Write

The two STRS infrastructure methods, STRS_Log and STRS_Write, have similar functionality except that STRS_Log adds a time stamp and possibly other identifying information. These methods should never be mixed for a given target. An STRS application developer should only write to the error queues using STRS_Log because the errors need to be identified further (STRS-54, STRS-55, STRS-56) and never with STRS_Write. Similarly, an STRS application developer should only write to the telemetry queues using STRS_Log because the telemetry data need to be identified further (STRS-57) and never using STRS_Write. Furthermore, the error queues are monitored for faults. An STRS application developer should only use STRS_Write to write buffered data to another application, service, device, file, or queue that does not require additional information added.

Go to top.

5.11 Difference Between Run Test and Ground Test

A run test is invoked using STRS_RunTest and implemented by APP_RunTest. A ground test is invoked using STRS_GroundTest and implemented by APP_GroundTest. A run test is invoked before or after deployment to determine whether the component is performing correctly. A ground test is generally invoked before deployment to perform unit testing and calibration. The ground tests help to automate and evaluate those tests. The term ground test was originally used to indicate testing for a satellite system, which is performed on the ground before launch.

Ground test may be invalid after deployment and indicates that such tests are normally completed before deployment and are not repeated thereafter. If allowed by the project and the ground tests will not be repeated after deployment, then the ground test code may be removed prior to deployment. The run tests and ground tests were separated because NASA generally requires significant testing prior to deployment; for example, vibration testing, environmental testing, radiation testing, etc.

Go to top.

5.12 When to Use Start/Stop, Load/Unload, and Open/Close

The commands STRS_Start, STRS_DeviceLoad, STRS_DeviceOpen are specified in NASA-STD-4009A along with the reverse commands, STRS_Stop, STRS_DeviceUnload, and STRS_DeviceClose. The following describes the interaction of these commands under various common circumstances.

Initialize (STRS_Initialize) is used while the application is in the STOPPED mode to set the application to a known initial condition. The application may be configured before and/or after initialize. Start (STRS_Start) is used to begin normal processing and change the state to RUNNING. If any part of the application is in specialized hardware, that portion needs to be loaded before starting. To load (STRS_Load) an STRS Device, the Device has to be opened (STRS_Open) first. It is suggested that any part executing in specialized hardware not begin execution upon being loaded but rather during the start process. Similarly, it is suggested that stopping execution (STRS_Stop) does not require any specialized hardware to be unloaded. Therefore, greater control is given to the application software for processing commands to start and stop waveform application operation in order to take advantage of windows of opportunity for execution as well as to promote consistency in control of the radio. Only certain allowed items may be configured after starting.

It is suggested that the STRS OE use configuration file(s) to start-up an application to a known initial state. STRS encourages that changeable data be specified in configuration files, rather than coding the data as constants within the application or device, so that greater portability and ease of modification is achieved. The STRS OE may process a configuration file to instantiate, open and load the device, initialize, configure, and start the application, or use any subset of these as determined by the project/mission and STRS platform provider.

As an example, the following use case is written for a waveform application using specialized hardware to send signals over the air to another radio assuming that the specialized hardware device has already been instantiated and initialized by the OE:

  1. Radio receives a command that a new waveform application is needed. This may be multiple commands received or one command that invokes a series of operations. In either case, those operations follow.
  2. OE checks for availability of the application and memory to instantiate it.
  3. OE instantiates application (STRS_InstantiateApp).
  4. OE initializes application (STRS_Initialize).
  5. OE opens specialized hardware device (STRS_DeviceOpen).
  6. OE loads specialized hardware device (STRS_DeviceLoad).
  7. OE configures application (STRS_Configure).
  8. OE starts application (STRS_Start).

The use case for the reverse process is as follows:

  1. The radio receives a signal to stop and remove the application. This may be multiple commands received or one command that invokes a series of operations. In either case, those operations follow.
  2. OE stops the application (STRS_Stop).
  3. OE unloads the specialized hardware device (STRS_DeviceUnload).
  4. OE closes the specialized hardware device (STRS_DeviceClose).
  5. OE releases resources for application (STRS_ReleaseResources).

If there is no specialized hardware device, the steps pertaining to such a device may be eliminated. If the application merely performs calculation, start may mean perform the calculation and, before each calculation, the data is reconfigured. Alternately, start may mean ready to perform the calculation and start invokes a thread that loops waiting for new data so that each time new data is obtained, the computation is performed. Similarly, for a waveform application, start may mean to tell the specialized hardware device to begin processing signals or alternately, start may invoke a thread to perform the communication functions. A separate thread is used so that other commands may be processed independently.

Go to top.

5.13 How to Read and Write Data

An application may read data using STRS_Read and write data using STRS_Write. A description of content, format, and usage of buffers is provided as part of the user documentation. As Consultative Committee for Space Data Systems (CCSDS) Electronic Data Sheets mature, these should be considered as precise machine-readable descriptions to facilitate reading and writing data. Currently, CCSDS Electronic Data Sheets are Red Book specifications 876.0 and 876.1.

It is suggested that CCSDS be used to document the format of buffers. CCSDS book 876.0 specifies “Electronic Data Sheets” (EDS), which is an XML schema for describing data exchange between system components. It provides a means to specify the exact format of the data, binary or otherwise, the types of interfaces provided by a component, as well as any handshaking or protocol-level requirements of an interface. The objective is to specify these details in a machine-readable language, and with sufficient detail such that it eliminates the need for a separate interface control document (ICD). The system components described can be physical hardware devices, where the device manufacturer would author the EDS, or software components where EDS can serve as a common interface description between the sender and receiver.

The STRS architecture does not dictate a specific data format for all APIs, leaving this decision up to application/waveform developers. By standardizing the description of the data format using EDS, flexibility is retained while still providing a compatibility point. Because the electronic data sheets are implemented in a machine-readable format, parts of the data exchange between components can be machine assisted, thereby easing the efforts required to port applications between different systems. Using the EDS, any other independently developed system or component that also implements the CCSDS electronic data sheet technology can exchange data with the component.

The core Flight System (cFS) is a platform independent reusable software framework and set of reusable software applications that is reused on NASA flight projects and/or embedded software systems at a significant cost savings. The cFS contains an implementation of the CCSDS electronic data sheets. The cFS-based STRS OE utilizes this technology to describe the sink and source interfaces as well as the various configurable properties of STRS applications, which aids portability to other cFS installations or other independently developed systems implementing EDS.
Go to top.

5.14 How to Add Asynchronous Publisher/Subscriber Functionality

A queue can be used to disassociate a publisher directly from a subscriber. The Pub/Sub implementation is synchronous. To get the asynchronous publisher/subscriber effect, the publisher writes to a queue and, in a different thread, a copy service reads from the queue and writes the data to a Pub/Sub to which the subscriber has registered. The copy service is to be configured knowing a queue source, a Pub/Sub sink, and the maximum number of bytes. Functionally, the copy service merely obtains the source and sink handle IDs and uses them to read from the source and write to the sink.

A copy service may be useful to copy other sources to other sinks. It may need additional options to do so, especially concerning initialization, finalization, and timing considerations. These will have to be handled on a case-by-case basis.

Go to top.

6.1 Fault State and Use of the ERROR, WARNING, and FATAL Queues

NASA-STD-4009A does not specify how the fault state is set or detected. The fault state may be determined in a number of ways as specified by the mission or project. When STRS_Log sends a message to the error queue or fatal queue, it is assumed that there is an error or fatal error in that component and that the fault state is set accordingly. The fault state could also be set when a Health Manager or Watchdog Timer detects a problem (neither of which is required). The fault state could also be detected when the telemetry returns improper values. The fault state as shown in the state diagram (figure 1) implies that the radio detects and possibly recovers; however, it could be designed so that the fault state is kept by the flight computer or equivalent.

The use of the ERROR, WARNING, and FATAL queues are expected to be defined more closely by the mission or project. The three relevant types of queues are as follows:

  1. The STRS_FATAL_QUEUE is the queue used when an STRS_FATAL error is encountered. STRS_FATAL_QUEUE denotes the queue for a unrecoverable error in an attempt to capture information about the situation in a logging trail used to reconstruct the original cause of the error. Furthermore, sending a message to the STRS_FATAL_QUEUE is one way of initiating an orderly shutdown and reboot of the radio to a known state. The processing for a fatal error could imply turning off the heartbeat; that is, rebooting the radio and, if that does not work, reloading the software and/or configurable hardware design. It could imply that additional diagnostic tests need to be run. It is up to the mission to define whether there are alternative ways of rebooting under different circumstances such as after trying three times. It may make a difference if the problem is overheating or if a bit has been changed in the radio so that it does not work properly.
  2. STRS_ERROR_QUEUE denotes the queue for a recoverable error. The most likely reason is an invalid set of configuration parameters. The recovery would be to get a valid set of configuration parameters.
  3. STRS_WARNING_QUEUE denotes the queue for a recoverable error that has little or no effect on the operation of the radio. The most likely reasons are trying to run a test in a state for which the test is not allowed, trying to configure or query a parameter when the value is not available in that state, or trying to run APP_Start when the application is already started.

Go to top.

6.2 Pub/Sub Messaging and Queues Need Clarification

In NASA-STD-4009A, a Pub/Sub is distinguished from a message queue. In a Pub/Sub, messages written to the message passing facility by one application are delivered to all subscribers of that publisher. The STRS does not require implementing Pub/Sub using the observer/publish-subscribe design pattern where the class inherits a notify method. The STRS is designed to work in C without inheritance, but the idea is that the publisher does not know the identity of the subscriber such that one or more applications or devices can funnel data to one or more different applications, devices, files, or queues. Figure 4, Sample Publisher-Subscriber Sequence Diagram, is just one possibility for a sequence diagram showing the creation and possible use of a messaging queue using one form of the publisher-subscriber paradigm.

Sample Publisher-Subscriber Sequence Diagram
Figure 4 – Sample Publisher-Subscriber Sequence Diagram (D)

Detecting circularity and duplication is difficult with just the sequence diagram shown without adding additional methods. Circularity is where the message published eventually ends up back at the original publisher and is sent again in an infinite loop. Duplication is where the message published ends up at the same destination twice.

There is a problem of notification when it is a message queue. STRS_Write will put the message on the queue, but there is no standard way of determining when there is something waiting on the queue; that is, when does STRS_Read obtain it from the queue and when does the message get deleted from the queue? Also, can the queue fill up so that further messages are rejected? The resolution to the message-queuing behavior is not included in the current version of NASA-STD-4009A but has to be covered by the specific design for the mission or project.

Go to top.

6.3 What is an STRS Device?

An STRS Device is software that responds to both STRS Infrastructure-provided Application Control methods and STRS Infrastructure Device Control methods. An STRS Device is used to separate an abstraction in the form of its interface from its underlying implementation. An STRS Device is a bridge between a waveform application and the specialized hardware, used to insulate the waveform application developer from knowing how the data gets to its final destination. This encourages encapsulation of non-portable functionality. STRS Devices do not have to be portable. However, it will be advantageous to follow the STRS Device-Provided Device Control API wherever possible to maximize consistency and portability. The functionality of the STRS Device will need to be ported to each successive radio while allowing an application to access the STRS Device methods in a consistent way that makes the STRS applications more portable and more understandable.

If a waveform application intends to transfer a data value from/to the specialized hardware, the waveform application would contain the data value and the corresponding STRS Device would be used to transfer the data value from/to the specific location in the specialized hardware. The STRS Device could use memory mapping or POSIX® or HAL, whichever is the documented way to get/set data in the specialized hardware while keeping the waveform application portable.

An STRS application is expected to use an STRS Device method to transfer data to and from the physical device. It was expected that the STRS Device configure/query methods could be used to get or set values, but there was a complaint that there were problems with performance, porting from legacy applications, and scheduling. Any exceptions to the standard are handled individually.

  1. An STRS Device can act as a sink by implementing APP_Write in the STRS Device. An STRS_Write/APP_Write is used to send data to a buffer in the specialized hardware. As an alternative, the STRS Device’s APP_Configure could be used.
  2. An STRS Device can act as a source by implementing APP_Read in the STRS Device. An STRS_Read/APP_Read is used to retrieve data from a buffer in the specialized hardware. As an alternative, the STRS Device’s APP_Query could be used.
  3. An STRS_Configure/APP_Configure is used to send the value of a name/value pair to the corresponding location in the specialized hardware.
  4. An STRS_Query/APP_Query is used to retrieve the value of a name/value pair from the corresponding location in the specialized hardware.

When an FPGA is implemented as an STRS Device, the FPGA may be loaded, configured, started, stopped, unloaded, and so forth, using the corresponding STRS Infrastructure Device Control API. There is no requirement that an STRS Device actually exists as separate software or hardware item. There is no requirement that the Device API is implemented as shown in figure 5. They are required when portability and reusability are desired as measured by their inclusion into the STRS Application Repository.

Many SDRs use memory mapped locations in which storing/retrieving an item in memory automatically pushes/pulls the item to/from the specialized hardware (see section 5.9). Other SDRs use special APIs that comprise the HAL to send/retrieve the item to/from a specific address in the specialized hardware. Still others use POSIX®. Having the STRS Device as a portable interface for data transfer allows the HAL methods, POSIX® methods, or memory mapping to be used as appropriate and easily changed. The STRS application can use the appropriate STRS Device methods when the STRS application just knows the handle name of the STRS Device, which gives more flexibility in configuring a data source or sink. For example, an application might be used to transmit data over the air obtained from a data source that might be configured as an application, device, queue, or file. Similarly, an application might be used to receive data over the air and send it to a data sink that might be configured as an application, device, queue, or file. Thus, an STRS Device may be used either to distribute functionality over multiple waveform applications or to abstract hardware functionality, further giving greater flexibility. This is analogous to redirection or pipes in UNIX®.

Since STRS Devices are only partially standardized by the STRS Device-provided Device Control API, extra methods may be implemented in an STRS Device to be used by the OE to establish the proper use of the HAL. A DEV_SetMemoryMap method is suggested in figure 5 to specify how a named value is associated with the appropriate location in the specialized hardware. This may be a non-portable construction but it does not violate the NASA Technical Standard. The idea is to have the STRS application code as portable as possible with the STRS Devices as lean as possible.

STRS Application/Device Structure
Figure 5 – STRS Application/Device Structure (D)

Go to top.

6.4 How to Configure and Control SDR Hardware

The configuration and control of the SDR hardware depends on where the intelligence exists; that is, which software component knows how to configure and control SDR hardware? A combination of software components (waveform application, STRS infrastructure, STRS Device, and HAL) knows how to configure and control SDR hardware.

  1. The application knows about data values, the STRS Device knows about mappings in the GPP, and the HAL knows about how to take values and transfer them to the hardware.
  2. The STRS application should be the target component for the parameters it controls and could pass to an STRS Device those parameters that need to be passed to the HAL.
  3. STRS Application.
    1. The STRS application would control what data are configured.
    2. The STRS application has limited intelligence on how and where to enable the application to be portable.
    3. The STRS application knows the handle ID of the STRS Device to use.
    4. For example, an STRS application processes FREQUENCY, converts from floating point to integer in a format that is recognized by the STRS Device, and calls the appropriate method to configure the STRS Device.
  4. STRS Device.
    1. The STRS Device controls how data get to the FPGA or other hardware.
    2. The STRS Device knows how to send data to the proper register in the FPGA using the HAL.
    3. The HAL may be external functions or inline functions that know the mappings from data addresses to registers in the FPGA.
  5. STRS Infrastructure.
    1. The STRS infrastructure reads the configuration files or receives an external command and calls the STRS_Configure method for the appropriate target component.
    2. The STRS_Configure in the infrastructure calls the corresponding APP_Configure within the target component.

6.5 STRS Infrastructure Methods Do Not Belong to Any Class

The STRS infrastructure-provided methods beginning with “STRS_” do not belong to any class, since they have to be the same when called from C language implementations. If one is coding in C++, these methods should be defined using extern “C” {…}.

In NASA-STD-4009A, the STRS infrastructure provides the STRS infrastructure-provided Application Control API that supports application operation using the STRS
Application-provided Application Control API in section 7.3.1. The STRS Infrastructure-provided Application Control API methods (section 7.3.2) that begin with “STRS_” correspond to the STRS Application-provided Application Control API methods (section 7.3.1) that begin with “APP_” and are used to access those methods. The STRS infrastructure implements these methods for use by any STRS application or by any part of the infrastructure that is desired to be implemented in a portable way.

Since the C language is optional for STRS applications (see STRS-16, 18, 19), the STRS Application-provided application control methods beginning with “APP_” may belong to a class.

Go to top.

6.6 Explain Clocks and Timers

The clocks/timers are used for determining when something happens, how long something takes, and coordinating internal and external events, including timestamps for messages. As computer speeds increase, more real-time functions for communication may be performed in the GPP. Some functions currently in the FPGA(s) may be transitioned to the GPP when the GPPs are fast enough and capable enough to handle the additional signal processing functionality. These GPP functions would need access to high speed clocks/timers.

NASA-STD-4009A is designed to allow a clock/timer to be an extension of an STRS Device so that the functionality can be embedded in specialized hardware, if necessary. Multiple timers are only defined when they are required by the mission. An offset is usually specified to ensure that the clock is monotonically increasing from a previous power reset or is synchronized with another clock/timer.

Normally, each clock/timer has a base time, usually measured from when it is turned on. An offset may be used to keep the time monotonically increasing with each power cycle. An offset may also be used to coordinate with external events. The timing of external events, such as another satellite coming over the horizon or the availability of experimenters, may be used to power parts of the radio off and on so that the radio optimizes its power consumption and availability.

It is recommended that one clock/timer match the required timestamp for STRS_Log so that an application, service, the OE, or even STRS_Log itself could obtain that time in a consistent way. It was suggested that the time for the timestamp be retrieved via STRS_GetTime using the handle ID corresponding to handle name “STRS_DEFAULT_CLOCK_NAME” and kind given by property “STRS_DEFAULT_CLOCK_KIND”. The use of this handle ID for STRS_SetTime may be restricted as necessary.

As specified by the mission, there should be at least one clock/timer with an epoch fixed to some Earth time zone, e.g., Coordinated Universal Time (UTC), so that the epoch could be adjusted to seconds from 1/1/1970 0:0:0, known adjustments for leap days and leap seconds applied, and the standard POSIX® time functions used. For example:

  1. From seconds to calendar time: Obtain the number of seconds from the TimeWarp object, apply any offset needed, and use gmtime_r to convert a given time since epoch (a time_t value) into calendar time, expressed in UTC in the struct tm format.
  2. From calendar time to seconds: Fill a struct tm with calendar time, convert to UNIX® time using mktime, apply any offset, and create a TimeWarp object.

Go to top.

6.7 FPGA Partial Reconfiguration

Partial reconfiguration is the process of configuring selected areas of an FPGA after its initial configuration. Xilinx indicates that a bitstream file can contain all the configuration commands and data necessary for partial reconfiguration. Therefore, STRS_DeviceLoad will work, and no new methods need to be defined. Whether the partial reconfiguration is fully transparent to the application(s) running on the FPGA or requires stopping and restarting or reconfiguring any other application(s) depends on the specifics of the partial reconfiguration.

Go to top.

6.8 Compliance Testing

STRS compliance of a vendor- or partner-provided SDR is assessed by source code inspection, document inspection, configuration file inspection, adding an application containing a reference to each STRS infrastructure method and testing that application. The name of that application is the STRS Command and Compliance, also known as WFCCN. WFCCN may be compiled with an STRS infrastructure to determine whether or not there are any missing constants, typedefs, or structs. These techniques are described in the STRS Compliance Testing document, which should be reviewed because of their complexity.

Since many of the STRS requirements are source code requirements, a standard test suite cannot test them fully. Since STRS is designed to allow multiple vendors to work together, certain source code artifacts have to be made available so that a subsequent STRS application developer or STRS integrator can use the methods, constants, typedefs, and structs required. The following is an example of a problem that WFCCN cannot be used to find: One vendor used noncompliant
method signatures with int instead of STRS_Buffer_Size, but on that platform, both integer items compiled as the same type. Using a type that happens to correspond to the vendor’s implementation of an STRS type is not necessarily portable to the next platform.

The STRS compliance could be evaluated at and by each vendor or partner and the results shared and discussed in one or more workshops at various points in the project life cycle. This alternative is to be decided by the mission or project. A full release and delivery of all STRS OE source code is not required in order to perform STRS compliance testing. Each vendor or partner should inspect his or her own software and documents before delivery. However, NASA found its own review to be invaluable to ensure greater compliance and promote understanding of differences among submitters.

Once the STRS radio artifacts are tested for STRS compliance, any noncompliances will be reported to the supplier and the mission or project, along with any suggestions. It is the responsibility of the mission or project to decide whether to grant deviations and waivers for any noncompliances that are not resolved.

Go to top.

6.9 Configuration Files Examples

To help the reader and implementer of the STRS architecture understand the development and use of the configuration files described in Appendix A, Example Configuration Files, an example of a configuration file based on that format was developed. This example of a configuration file, for a sample application WF1, is shown in this NASA Technical Handbook in figure 6, Example of Predeployed Configuration File for Appendix A.

Example of Predeployed Configuration File for Appendix A
Figure 6 – Example of Predeployed Configuration File for Appendix A (D)

Here is the explanation, line by line:

  1. XML declaration.
  2. Extensible Stylesheet Language (XSL) file declaration.
  3. Comment.
  4. Open tag STRS and corresponding XML schema declaration.
  5. Open tag CONFIGURATION.
  6. Open tag W_HANDLE.
  7. Tag HANDLENAME containing WF1 as the handle name.
  8. Tag WAVEFORM containing the OE-specific name used to instantiate WF1 as a path to additional items to process.
  9. Close tag W_HANDLE.
  10. Close tag CONFIGURATION.
  11. Close tag STRS.

The OE-specific name is a file name containing the additional items to process, which are specified with their own XML configuration file and transformation process. This example of an application configuration file, for a sample application WF1, is shown in this NASA Technical Handbook in figure 7, Example of Predeployed Configuration File for Application WF1 for Appendix A.

Example of Predeployed Configuration File for Application WF1 for Appendix A
Figure 7 – Example of Predeployed Configuration File for Application WF1 for Appendix A. (D)

Here is the explanation, line by line:

  1. XML declaration.
  2. Extensible Stylesheet Language (XSL) file declaration.
  3. Comment.
  4. Open tag WAVEFORM and corresponding XML schema declaration.
  5. Tag WFNAME containing WF1as the class name.
  6. Tag WFACCESS with WF1 having no READ/WRITE access; that is, neither APP_Read nor APP_Write are implemented.
  7. Tag WFSTATE with final state as INSTANTIATED.
  8. Comment.
  9. Open tag LOADFILE.
  10. Tag LOADFILENAME containing the path to load WF1.out.
  11. Tag LOADTARGET containing SELF to indicate that it is loaded on the current GPP.
  12. Open tag LOADMEMORY.
  13. Tag MEMORYSIZE indicating that the size is 134k bytes.
  14. Tag MEMORYUNITS indicating that the size is measured in bytes.
  15. Close tag LOADMEMORY.
  16. Close tag LOADFILE.
  17. Open tag LOADFILE.
  18. Tag LOADFILENAME containing the path to WF1.bit.
  19. Tag LOADTARGET containing FPGA to indicate that it is loaded on the FPGA.
  20. Open tag LOADMEMORY.
  21. Tag MEMORYSIZE indicating that the size is 2670K gates.
  22. Tag MEMORYUNITS indicating that the size is measured in gates.
  23. Close tag LOADMEMORY.
  24. Close tag LOADFILE.
  25. Open tag ATTRIBUTE.
  26. Tag NAME containing A.
  27. Tag VALUE containing 5 as the value for A.
  28. Close tag ATTRIBUTE.
  29. Open tag ATTRIBUTE.
  30. Tag NAME with B.
  31. Tag VALUE containing 27 as the value for B.
  32. Close tag ATTRIBUTE.
  33. Open tag ATTRIBUTE.
  34. Tag NAME with C.
  35. Tag VALUE containing “Non-numeric” as the value for C.
  36. Close tag ATTRIBUTE.
  37. Close tag WAVEFORM.

The example in Appendix A splits the formatting into three parts to group the information logically. The following explanations further clarify the necessity and intent of Appendix A:

  1. There is no necessity or requirement for splitting the platform configuration files into hardware and software parts as shown in Appendix A.1 and A.2. Splitting up the description this way was just a logical way to organize the description.
  2. The format of the platform configuration file should allow some applications, devices, and services to be instantiated at boot-up or restart. Therefore, to use STRS_InstantiateApp to instantiate applications in all cases, the platform configuration file would specify the arguments. For this example, the OE-specific name argument referenced is the application configuration file name whose predeployed format is shown in Appendix A.3. The application configuration file may be independent of the platform configuration file.

Go to top.

6.10 C Language Naming Duplication

There will most likely be more than one application in an STRS radio. In the C language, there is no namespace support as in C++ or other object-oriented (OO) languages that scope the member functions to the class. Thus, there will be multiple implementations of the same STRS Application-provided API method names, starting with “APP_”, one in each implementation of an application.

One technique to allow multiple “instances” of C language applications could use APP_Instance to return a pointer to a table of pointers to the methods. Then, the OE could use these method locations to call the methods. This technique and variations are described in NASA/TM-2011-216948, Symbol Tables and Branch Tables: Linking Applications Together. The techniques specify the creation of a branch table or indirect address table for each application. To suppress the common method names, compile and link each application separately. When the table is registered with the OE, the OE could use the table to call the appropriate method.

Another technique to allow multiple “instances” of C language applications with the same method names depends on loading new applications one at a time, sequentially, and capturing the new method locations instead of the old at the appropriate point in the process. The method locations are saved in a structure associated with the STRS application and the appropriate method is called as needed. The flow chart shown in figure 8, Obtain Array of Pointers to Methods, gives some highlights. Note that, besides the method illustrated in figure 8, there are other ways of creating an array of pointers to the C language methods. This array of pointers may be used to invoke those methods later.

Obtain Array of Pointers to Methods
Figure 8 – Obtain Array of Pointers to Methods (D)

The technique demonstrated in figure 8 might not be possible on a platform that needs everything to be compiled and linked together ahead of time. Another technique would be to use message queuing to communicate between independent applications, but this technique might be awkward to use in practice. Another technique is to prepend the method name with a C-language class name equivalent.

Go to top.

6.11 Sequence Diagrams Depicting STRS API Calls

The following sequence diagrams depict the relationship between the STRS infrastructure-provided Application Control API beginning with “STRS_” and the corresponding STRS Application-provided Application Control API beginning with “APP_.” The methods described for figure 1 are those that cause a change in state. In this NASA Technical Handbook, the methods depicted in figure 9, Simplified Sequence Diagram for STRS_InstantiateApp, figure 10, Simplified Sequence Diagram for STRS_AbortApp, and figure 11, Simplified Sequence Diagram for STRS_Configure, contain both those that cause a change in state as well as those that do not. In this NASA Technical Handbook, since an STRS Device inherits all the methods from an STRS application, as shown in figure 5, the methods in figures 9, 10, and 11 for STRS applications could apply to STRS Devices as well. In figures 9, 10, and 11, “Command Source” is used for the object, internal to the radio, either an STRS application or part of the OE, which calls the STRS infrastructure methods.

Simplified Sequence Diagram for STRS_InstantiateApp
Figure 9 – Simplified Sequence Diagram for STRS_InstantiateApp (D)

Simplified Sequence Diagram for STRS_AbortApp
Figure 10 – Simplified Sequence Diagram for STRS_AbortApp (D)

Simplified Sequence Diagram for STRS_Configure
Figure 11 – Simplified Sequence Diagram for STRS_Configure (D)

A sequence diagram for each row in table 1, Substitutions for Figure 11, can be made from the diagram in figure 11, by substituting the “COMMAND SOURCE TO OE” method in place of STRS_Configure and the corresponding “OE TO STRS APPLICATION” method in place of APP_Configure.

Table 1 – Substitutions for Figure 11
STRS_GroundTest APP_GroundTest
STRS_Initialize APP _Initialize
STRS_Query APP _Query
STRS_Read APP _Read
STRS_ReleaseObject APP _ReleaseObject
STRS_RunTest APP _RunTest
STRS_Start APP _Start
STRS_Stop APP _Stop
STRS_Write APP _Write

Go to top.

6.12 Why are APP_Instance and APP_Initialize Separate?

The APP_Instance and APP_Initialize methods are often used together successively but should not be combined because they have different functionality. The separation of APP_Instance and APP_Initialize supports encapsulation. It allows configuration to occur before APP_Initialize. In figure 9, STRS_InstantiateApp calls APP_Instance and then it may call APP_Configure and APP_Initialize, as specified by the configuration file. STRS_InitializeApp may do everything in one call or additional calls may be needed thereby giving the greatest flexibility. Also, note that APP_Instance is a convenience function containing a constructor and saving any application identifying information.

Go to top.

6.13 Why Start with SCA?

The Wireless Innovation Forum (formerly SDR Forum) and SWRADIO by the OMG put so mu