NASA

National Aeronautics and Space Administration

Glenn Research Center

Space Telecommunications Radio System (STRS)

Space Telecommunications Radio System (STRS) > What is STRS? > STRS Requirements and Examples

STRS Requirements and Examples

Based on NASA Standard NASA-STD-4009A Draft

Table of Contents

(Skip to contents.)

Section Requirement Name Table
7.1 STRS-1 Power Up –
7.2 STRS-2 Provide Platform Diagnostics –
7.3 STRS-3 Use Platform Diagnostics (Deleted) –
7.4 STRS-4 Document Resources –
7.5 STRS-5 Document Capability –
7.6 STRS-6 Document Radio Frequency (RF) Behavior –
7.7 STRS-7 Document Module Interfaces –
7.8 STRS-8 Document Module Control –
7.9 STRS-9 Document Power –
7.10 STRS-10 STRS Application Uses OE –
7.11 STRS-11 OE Uses HAL –
7.12 STRS-12 STRS Application Repository –
7.13 STRS-13 OE Controls Signal-Processing Module (SPM) –
7.14 STRS-14 Provide Platform-Specific Wrapper –
7.15 STRS-15 Document Platform-Specific Wrapper –
7.16 STRS-16 Use C/C++ Waveform (WF) Interface –
7.17 STRS-17 OE Uses STRS Application Control API –
7.18 STRS-18 Use C/C++ Compile-Time –
7.19 STRS-19 Use C/C++Run-Time –
7.20 STRS-20 Include STRS_ApplicationControl.h –
7.21 STRS-21 Provide STRS_ApplicationControl.h –
7.22 STRS-22 STRS_ApplicationControl Base Class –
7.23 STRS-23 Include STRS_Sink.h –
7.24 STRS-24 Provide STRS_Sink.h –
7.25 STRS-25 STRS_Sink Base Class –
7.26 STRS-26 Include STRS_Source.h –
7.27 STRS-27 Provide STRS_Source.h –
7.28 STRS-28 STRS_Source Base Class –
7.29 STRS-29 APP_Configure Table 5
7.30 STRS-30 APP_GroundTest Table 9
7.31 STRS-31 APP_Initialize Table 10
7.32 STRS-32 APP_Instance Table 11
7.33 STRS-33 APP_Query Table 12
7.34 STRS-34 APP_Read Table 13
7.35 STRS-35 App_ReleaseObject Table 14
7.36 STRS-36 APP_RunTest Table 15
7.37 STRS-37 APP_Start Table 16
7.38 STRS-38 APP_Stop Table 17
7.39 STRS-39 APP_Write Table 18
7.40 STRS-40 STRS_Configure Table 19
7.41 STRS-41 STRS_GroundTest Table 20
7.42 STRS-42 STRS_Initialize Table 21
7.43 STRS-43 STRS_Query Table 22
7.44 STRS-44 STRS_ReleaseObject Table 23
7.45 STRS-45 STRS_RunTest Table 24
7.46 STRS-46 STRS_Start Table 25
7.47 STRS-47 STRS_Stop Table 26
7.48 STRS-48 STRS_AbortApp Table 27
7.49 STRS-49 STRS_GetErrorQueue Table 28
7.50 STRS-50 STRS_HandleRequest Table 30
7.51 STRS-51 STRS_InstantiateApp Table 31
7.52 STRS-52 STRS_IsOK Table 32
7.53 STRS-53 STRS_Log Table 33
7.54 STRS-54 STRS_Log Error –
7.55 STRS-55 STRS_Log Fatal –
7.56 STRS-56 STRS_Log Warning –
7.57 STRS-57 STRS_Log Telemetry –
7.58 STRS-58 STRS_Write Table 36
7.59 STRS-59 STRS_Read Table 37
7.60 STRS-60 Device Control (Deleted) –
7.61 STRS-61 STRS_DeviceClose Table 38
7.62 STRS-62 STRS_DeviceFlush Table 39
7.63 STRS-63 STRS_DeviceLoad Table 40
7.64 STRS-64 STRS_DeviceOpen Table 41
7.65 STRS-65 STRS_DeviceReset Table 42
7.66 STRS-66 STRS_DeviceStart (Deleted) –
7.67 STRS-67 STRS_DeviceStop (Deleted) –
7.68 STRS-68 STRS_DeviceUnload Table 43
7.69 STRS-69 STRS_SetISR Table 44
7.70 STRS-70 STRS_FileClose Table 51
7.71 STRS-71 STRS_FileGetFreeSpace Table 52
7.72 STRS-72 STRS_FileGetSize Table 53
7.73 STRS-73 STRS_FileGetStreamPointer Table 54
7.74 STRS-74 STRS_FileOpen Table 55
7.75 STRS-75 STRS_FileRemove Table 56
7.76 STRS-76 STRS_FileRename Table 57
7.77 STRS-77 Use Messaging API –
7.78 STRS-78 STRS_QueueCreate (Deleted) –
7.79 STRS-79 STRS_QueueDelete (Deleted) –
7.80 STRS-80 STRS_Register Table 62
7.81 STRS-81 STRS_Unregister Table 63
7.82 STRS-82 Use Time Control API –
7.83 STRS-83 STRS_GetNanoseconds Table 65
7.84 STRS-84 STRS_GetSeconds Table 66
7.85 STRS-85 STRS_GetTime Table 67
7.86 STRS-86 STRS_GetTimeWarp Table 69
7.87 STRS-87 STRS_SetTime Table 70
7.88 STRS-88 STRS_TimeSynch Table 73
7.89 STRS-89 Provide STRS.h Table 74
7.90 STRS-90 Provide POSIX® –
7.91 STRS-91 Use POSIX® Table 77
7.92 STRS-92 Document HAL –
7.93 STRS-93 OE Uses HAL (Deleted) –
7.94 STRS-94 External Commands –
7.95 STRS-95 Use STRS APIs –
7.96 STRS-96 Use STRS_Query –
7.97 STRS-97 Use STRS_Log (Deleted) –
7.98 STRS-98 Document Platform for XML (Project Option) –
7.99 STRS-99 Document WF for XML (Deleted) –
7.100 STRS-100 Provide XML File (Project Option) –
7.101 STRS-101 XML Content (Project Option) –
7.102 STRS-102 Provide XML Schema (Project Option) –
7.103 STRS-103 Provide XML Transformation Tool (Project Option) –
7.104 STRS-104 Provide XML Transformed (Project Option) –
7.105 STRS-105 OE Provides API in C –
7.106 STRS-106 Use STRS.h –
7.107 STRS-107 Document External Commands –
7.108 STRS-108 Document Thermal and Power Limits –
7.109 STRS-109 Provide General-Purpose Processing Module –
7.110 STRS-110 Provide STRS_APIs.h –
7.111 STRS-111 Include STRS_DeviceControl.h –
7.112 STRS-112 Provide STRS_DeviceControl.h –
7.113 STRS-113 STRS_DeviceControl Base Class –
7.114 STRS-114 APP_Destroy Table 6
7.115 STRS-115 APP_GetHandleID Table 7
7.116 STRS-116 APP_GetHandleName Table 8
7.117 STRS-117 STRS_GetHandleName Table 29
7.118 STRS-118 STRS_ValidateHandleID Table 34
7.119 STRS-119 STRS_ValidateSize Table 35
7.120 STRS-120 DEV_Close Table 45
7.121 STRS-121 DEV_Flush Table 46
7.122 STRS-122 DEV_Load Table 47
7.123 STRS-123 DEV_Open Table 48
7.124 STRS-124 DEV_Reset Table 49
7.125 STRS-125 DEV_Unload Table 50
7.126 STRS-126 STRS_MessageQueueCreate Table 58
7.127 STRS-127 STRS_MessageQueueDelete Table 59
7.128 STRS-128 STRS_PubSubCreate Table 60
7.129 STRS-129 STRS_PubSubDelete Table 61
7.130 STRS-130 Document STRS Clock/Timer Table 64
7.131 STRS-131 STRS_GetTimeAdjust Table 68
7.132 STRS-132 STRS_SetTimeAdjust Table 71
7.133 STRS-133 STRS_Sleep Table 72
7.134 STRS-134 STRS Platform Queryable Parameters Table 75
7.135 STRS-135 STRS Application Queryable Parameters Table 76


Go to top,
Skip to (next) STRS-1.

Note: Background color yellow indicates that hovering with the mouse should display additional information.



7. STRS REQUIREMENTS, RATIONALE, VERIFICATION METHOD, AND EXAMPLES

The following sections address each requirement in turn, displaying the rationale, the related higher-level requirements, verification method, and other pertinent information, which augment the general rationale given earlier in this document.

In each section, the title line contains the requirement number and the title of the requirement. That is followed by the text of the requirement. The rationale describes why the requirement is needed. The category contains one or more of the summary capabilities from NASA/TM-2007-215042. The categories are chosen from the following list: adaptability, availability, extensibility, flexibility, interoperability, portability, (implying reusability too), scalability, reliability, and reconfigurability. The traced-from specifies the section numbers in NASA/TM-2007-215042 that apply to this requirement. The use case specifies the names of the use case sections in
NASA/TP-2008-214813 that apply to this requirement. The related to specifies the part of the STRS radio that has to satisfy the requirement where platform indicates that the hardware and related documentation are tested, OE indicates that the OS and infrastructure and related documentation are tested, and application indicates that the application and related documentation are tested. The notes contain additional explanations for the requirement.

Verification methods are used to show that the requirement has been met. The verification method is chosen from the following list: Analysis, inspection, observation, similarity, or test. Tests are not used because tests are expected to be mission requirements rather than STRS requirements.

a. Analysis is the process of utilizing analytical techniques to verify that requirements have been satisfied. This method may be used when qualification by test is not possible, when a test would introduce significant risk into the software, or when analysis is an appropriate, cost-effective qualification method.

b. Inspection is a qualification method consisting of investigation without the use of special tests. Inspection is usually a visual examination, but it may be computer-aided. Using a script or WFCCN refers to the STRS compliance tools as described in the NASA/TM-2011-217266, STRS Compliance Testing document. A compliance certification testing facility is available at Glenn Research Center (GRC) to perform compliance testing and will test all STRS applications submitted to the STRS Application Repository. The users may use their own tools as an independent check of an OE or of an application prior to submitting the application to the STRS Application Repository.

  1. Using a script or WFCCN is a type of inspection that is computer-aided.
  2. Using a compliance tool implies a script or WFCCN.
  3. Using a program, such as XMLSpy, validates the XML schema and the predeployed configuration file against its schema.

c. Observation is a method of qualification that is limited to readily observable functional operation to determine compliance with requirements. This method of qualification does not require the use of special equipment or sophisticated instrumentation.

d. Similarity is the process of using analysis and/or “delta testing” to prove the design adequacy of an item by reference to the prior qualification of an identifiable item that has been qualified for a similar application.

e. Test is a qualification method that employs technical means including, but not limited to, the evaluation of functional characteristics by the use of special equipment or instrumentation, simulation techniques, and the application of established principles and procedures to determine compliance with requirements. The analysis of data derived from a test is an integral part of the method.

Note: The variables STRS_APP_INSTANTIATED, STRS_APP_STOPPED, and STRS_APP_RUNNING, shown in the examples, are variables for states, which would have to be defined locally.


Go to top,
Skip to (next) STRS-2.

7.1   STRS-1 Power Up
Requirement An STRS platform shall have a known state after completion of the power-up process.
Rationale To increase the reliability of the STRS platform after reboot or power cycle, the radio has to be able to return to full operation autonomously without the need for external equipment or procedures.
Category Availability, Reliability
Traced-from 4.3, 5.17
Use Case Power On
Applicable to OE developer: usually platform provider
Notes A known state is one that is predictable from documentation or from configuration file(s) or scripts or some combination thereof.
Verification Method Observation of radio operation.
See Also N/A


Go to top,
Skip to (prev) STRS-1, Skip to (next) STRS-3

7.2   STRS-2 Provide Platform Diagnostics
Requirement A module’s diagnostic information shall be available via the STRS APIs.
Rationale To increase the reliability and availability of the STRS platform, there has to be a means of providing data to identify configuration information as well as status and fault identification. Data for both BITs and recognition of operational degradation and malfunction have to be available.
Category Reliability, Availability
Traced-from 4.3, 5.15, 5.16
Use Case Fault Management, Built-In Test
Applicable to OE developer: usually platform provider
Notes None
Verification Method Observation of radio operation.
See Also N/A


Go to top,
Skip to (prev) STRS-2, Skip to (next) STRS-4

7.3   STRS-3 Use Platform Diagnostics (Deleted)
Rationale This requirement was deleted becauseSTRS-2 wording was made more robust, STRS-3 became redundant. STRS-3 previously stated: Self-diagnostic and fault-detection data shall be created for each module so that it is accessible to the STRS OE.


Go to top,
Skip to (prev) STRS-3, Skip to (next) STRS-5

7.4   STRS-4 Document Resources
Requirement The STRS platform provider shall describe, in the HID document, the behavior and capability of each major functional device or resource available for use by waveforms, services, or other applications (e.g., FPGA, GPP, DSP, or memory), noting any operational limitations.
Rationale Waveform developers need to know the features and limitations of the platform for their applications. Once the radio has been procured, NASA has the knowledge to procure or produce new or additional modules using HID information. Also, future module replacement or additions will be possible without designing a new platform.
Category Adaptability
Traced-from 4.7, 4.8, 5.2, 5.3
Use Case None
Applicable to Platform provider
Notes None
Verification Method Inspection of HID document.
See Also N/A


Go to top,
Skip to (prev) STRS-4, Skip to (next) STRS-6

7.5   STRS-5 Document Capability
Requirement The STRS platform provider shall describe, in the HID document, the reconfigurability behavior and capability of each reconfigurable component.
Rationale Waveform developers need to know the features and limitations of the platform for their applications. Once the radio has been procured, NASA has the knowledge to procure or produce new or additional modules using HID information. Also, future module replacement or additions will be possible without designing a new platform.
Category Adaptability
Traced-from 4.7, 4.8, 5.2, 5.3
Use Case None
Applicable to Platform provider
Notes None
Verification Method Inspection of HID document.
See Also N/A


Go to top,
Skip to (prev) STRS-5, Skip to (next) STRS-7

7.6   STRS-6 Document Radio Frequency (RF) Behavior
Requirement The STRS platform provider shall describe, in the HID document, the behavior and performance of the RF modular component(s).
Rationale Waveform developers need to know the features and limitations of the platform for their applications. Once the radio has been procured, NASA has the knowledge to procure or produce new or additional modules using HID information. Also, future module replacement or additions will be possible without designing a new platform.
Category Interoperability, Adaptability
Traced-from 4.6, 4.7, 4.8, 5.2, 5.3
Use Case None
Applicable to Platform provider
Notes None
Verification Method Inspection of HID document.
See Also N/A


Go to top,
Skip to (prev) STRS-6, Skip to (next) STRS-8

7.7   STRS-7 Document Module Interfaces
Requirement The STRS platform provider shall describe, in the HID document, the interfaces that are provided to and from each modular component of the STRS platform.
Rationale Waveform developers need to know the features and limitations of the platform for their applications. Once the radio has been procured, NASA has the knowledge to procure or produce new or additional modules using HID information. Also, future module replacement or additions will be possible without designing a new platform.
Category Interoperability, Adaptability
Traced-from 4.2, 4.7, 4.8, 5.2, 5.3
Use Case None
Applicable to Platform provider
Notes None
Verification Method Inspection of HID document.
See Also N/A


Go to top,
Skip to (prev) STRS-7, Skip to (next) STRS-9

7.8   STRS-8 Document Module Control
Requirement The STRS platform provider shall describe, in the HID document, the control, telemetry, and data mechanisms of each modular component (i.e., how to program or control each modular component of the platform, and how to use or access each device or software component, noting any proprietary and nonstandard aspects).
Rationale Waveform developers need to know the features and limitations of the platform for their applications. Once the radio has been procured, NASA has the knowledge to procure or produce new or additional modules using HID information. Also, future module replacement or additions will be possible without designing a new platform.
Category Interoperability, Adaptability
Traced-from 4.7, 4.8, 5.2, 5.3
Use Case None
Applicable to Platform provider
Notes None
Verification Method Inspection of HID document.
See Also N/A


Go to top,
Skip to (prev) STRS-8, Skip to (next) STRS-10

7.9   STRS-9 Document Power
Requirement The STRS platform provider shall describe, in the HID document, the behavior and performance of any power supply or power converter modular component(s).
Rationale Waveform developers need to know the features and limitations of the platform for their applications. Once the radio has been procured, NASA has the knowledge to procure or produce new or additional modules using HID information. Also, future module replacement or additions will be possible without designing a new platform.
Category Reliability, Adaptability
Traced-from 4.7, 4.8, 5.2, 5.3
Use Case None
Applicable to Platform provider
Notes None
Verification Method Inspection of HID document.
See Also STRS-108


Go to top,
Skip to (prev) STRS-9, Skip to (next) STRS-11

7.10   STRS-10 STRS Application Uses OE
Requirement An STRS application shall use the STRS infrastructure-provided APIs and POSIX® API for access to platform resources.
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. Rather than creating many more APIs in STRS, the currently available POSIX® standard was selected. Thus, POSIX® subsets were chosen to implement certain OS services missing from the list of STRS Application-provided methods. The POSIX® subsets are widely available, implemented by multiple OSs, and scalable. Layering of the architecture separates and encapsulates functionality so that the parts are less influenced by changes to the other. This separation of functionality promotes portability.
Category Portability
Traced-from 4.2, 4.7, 5.1
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A


Go to top,
Skip to (prev) STRS-10, Skip to (next) STRS-12

7.11   STRS-11 OE Uses HAL
Requirement The STRS infrastructure shall use the STRS platform HAL APIs to communicate with application components on the platform specialized hardware via the physical interface defined by the STRS platform provider.
Rationale

The HAL API is to be published so that specialized hardware made by one company may be integrated with the STRS infrastructure made by a different company.

The HAL API documentation is to include a description of each method or function used, including its calling sequence, return values, an explanation of its functionality, any preconditions before using the method or function, and the status after using the method or function.

The HAL API documentation is to also contain information about the underlying hardware such as address and data interfaces, interrupt input and output, power connections, and other control and data lines necessary to operate in the STRS platform environment.

Category Adaptability, Extensibility
Traced-from 4.4, 4.5, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection of HAL document.
See Also STRS-92


Go to top,
Skip to (prev) STRS-11, Skip to (next) STRS-13

7.12   STRS-12 STRS Application Repository
Requirement The following application or OE development artifacts shall be submitted to the NASA STRS Application Repository:

  1. Application (or OE) or system component software and configurable hardware design simulation model(s) and/or documentation). (Design Description Document)
  2. Documentation of external interfaces for STRS application, devices, or configurable hardware design (e.g., signal names, descriptions, polarity, format, data type, and timing constraints). (HID)
  3. Documentation of STRS application or OE behavior, initialization, and adaptability (e.g., configurable and queryable data items). (Design Description Document, User’s Guide)
  4. Application or OE function sources (e.g., C, C++, header files, VHSIC VHDL, and Verilog®). (Artifacts)
  5. Application or OE libraries, if applicable (e.g., electronic design interchange format (EDIF) and Dynamic Link Library (DLL)). (Artifacts)
  6. Documentation of application (or OE) development environment and/or tool suite as follows: (Design Description Document)
    1. Include the development environment and/or tool suite name, purpose, developer, version, and configuration specifics (e.g., ISE Design Suite System, Xilinx, 14.4, EDK and SDK; MATLAB® Simulink®, Model base design support automatic code generation, MathWorks, R2016a).
    2. Include a description of the hardware on which the development environment and/or tool suite is executed, its OS, OS developer, OS version, and OS configuration specifics (e.g., Microsoft® Windows 7, Service pack 2; Linux® Ubuntu, (Xenial Xerus) 16.04).
    3. Include a description of the output of the development environment and/or tool suite, its STRS infrastructure/OE description, developer, version, and unique implementation items (e.g., type of file, .mdl, .slx; GRC’s STRS Reference Implementation; Intellectual Property (IP) generated from Xilinx).
    4. Include a description of licensing agreements for development environment and/or tool suite.
  7. Test plans, procedures, and results documentation. (Verification and Validation (V&V) Plan, V&V Procedure, and V&V Results)
  8. Identification of software development standards used. (Version Description Document (VDD)/Metadata)
  9. Version of this NASA Technical Standard used. (VDD/Metadata)
  10. Information, along with supporting documentation, required to make the appropriate decisions regarding ownership, distribution rights, and release (technology transfer) of the application or OE and associated artifacts. (Transfer Rights/Agreements)
  11. Version Description Document, if available, or other document containing the version numbers of each separable artifact in the release, defined down to the lowest level components. (VDD)
  12. Documentation of the platform component hardware used by the application or OE, its function, and the interconnections. If the component executes an operating system, document the OS, OS developer, OS version, and OS configuration. (HID)
  13. Documentation when an OE is submitted to the STRS Application Repository, providing guidelines to aid a waveform/application developer and integrator in the task of developing an STRS compliant waveform/application. (OE-Specific Developer’s Guide)
Rationale To understand how to use the radio, information must be provided about its design and implementation. To have confidence that the design and implementation meet the NASA Procedural Requirements (NPR) 7150.2, NASA Software Engineering Requirements, additional information about standards, reviews, and tests must be provided.
Category Portability
Traced-from 4.2, 4.9, 5.2
Use Case None
Applicable to Application or OE developer
Notes None
Verification Method Inspection of deliverable items and documentation.
See Also STRS-92


Go to top,
Skip to (prev) STRS-12, Skip to (next) STRS-14

7.13   STRS-13 OE Controls Signal-Processing Module (SPM)
Requirement If the STRS application has a component resident outside the GPM (e.g., in configurable hardware design), then the component shall be controllable from the STRS OE.
Rationale The layering of the architecture introduces the need for the GPP to be able to control, configure, and monitor many aspects of the SPM. For portability, waveform applications use STRS APIs, which access the HAL or POSIX® API within the STRS OE as needed.
Category Portability, Reconfigurability, Adaptability
Traced-from 4.5, 4.9, 5.1, 5.4, 5.22
Use Case None
Applicable to Application developer
Notes None
Verification Method Observation of operation of radio.
See Also N/A


Go to top,
Skip to (prev) STRS-13, Skip to (next) STRS-15

7.14   STRS-14 Provide Platform-Specific Wrapper
Requirement The STRS SPM developer shall provide a platform-specific wrapper for each user-programmable FPGA, which performs the following functions:

  1. Provides an interface for command and data from the GPM to the waveform application.
  2. Provides the platform-specific pinout for the STRS application developer. This may be a complete abstraction of the actual FPGA pinouts with only waveform application signal names provided.
Rationale To aid in the portability of waveform applications within an FPGA, a platform-specific wrapper provides an additional layer separating the interface between the GPP and SPM/FPGA from the signal processing functionality within the FPGA.
Category Portability, Extensibility
Traced-from 4.2, 4.4, 4.9, 5.1, 5.8
Use Case None
Applicable to Platform provider
Notes None
Verification Method Inspection of document and code.
See Also N/A


Go to top,
Skip to (prev) STRS-14, Skip to (next) STRS-16

7.15   STRS-15 Document Platform-Specific Wrapper
Requirement The STRS SPM developer shall provide documentation on the configurable hardware design interfaces of the platform-specific wrapper for each user-programmable FPGA, which describes the following:

  1. Signal names and descriptions.
  2. Signal polarity, format, and data type.
  3. Signal direction.
  4. Signal-timing constraints.
  5. Clock generation and synchronization methods.
  6. Signal-registering methods.
  7. Identification of development tool set used.
  8. Any included noninterface functionality.
Rationale When functions, interfaces, components, and/or design rules are defined and published, the architecture is open. Open architecture facilitates interoperability among commercial and government developers and minimizes the operational impact of upgrading hardware and software components.
Category Portability, Adaptability
Traced-from 4.2, 4.4, 4.7, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Platform provider
Notes None
Verification Method Inspection of document.
See Also N/A


Go to top,
Skip to (prev) STRS-15, Skip to (next) STRS-17

7.16   STRS-16 Use C/C++ Waveform (WF) Interface
Requirement The STRS Application-provided Application Control API shall be implemented using ISO/IEC C or C++.
Rationale Because portability is a basic goal but middleware is not required, a totally language-independent solution was not available. The lowest common denominator turns out to be a C or C++ language interface. Using a standard ISO/IEC 9899 C or ISO/IEC 14882 C++ aids portability. The year is not included in the requirement, so that obsolete compilers are not mandated.
Category Portability, Scalability
Traced-from 4.1, 4.2, 4.7, 4.9, 5.1
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection of code.
See Also N/A


Go to top,
Skip to (prev) STRS-16, Skip to (next) STRS-18

7.17   STRS-17 OE Uses STRS Application Control API
Requirement The STRS infrastructure shall use the STRS Application-provided Application Control API to control STRS applications.
Rationale Layering of the architecture separates and encapsulates functionality so that the parts are less influenced by changes to the other. This separation of functionality promotes portability.
Category Portability
Traced-from 4.1, 4.2, 4.7, 4.9, 5.1
Use Case None
Applicable to OE developer: usually platform provider
Notes The STRS Application-provided Application Control API refers to the API defined in STRS-29 through STRS-39, STRS-114 through STRS-116, and the corresponding tables 5 through 18. The method names in the STRS Application-provided Application Control API begin with “APP_”.
Verification Method Inspection using OE script and using compliance tool.
See Also N/A


Go to top,
Skip to (prev) STRS-17, Skip to (next) STRS-19

7.18   STRS-18 Use C/C++ Compile-Time
Requirement The STRS OE shall support ISO/IEC C or C++, or both, language interfaces for the STRS Application-provided Application Control API at compile-time.
Rationale Because portability is a basic goal but middleware is not required, a totally language-independent solution was not available. The lowest common denominator turns out to be a C or C++, or both, language interface. Using a standard ISO/IEC 9899 C or ISO/IEC 14882 C++ aids portability. The year is not included in the requirement, so that obsolete compilers are not mandated.
Category Portability
Traced-from 4.1, 4.2, 4.7, 4.9, 5.1
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection
See Also N/A


Go to top,
Skip to (prev) STRS-18, Skip to (next) STRS-20

7.19   STRS-19 Use C/C++ Run-Time
Requirement The STRS OE shall support ISO/IEC C or C++, or both, language interfaces for the STRS Application-provided Application Control API at run-time.
Rationale Because portability is a basic goal but middleware is not required, a totally language-independent solution was not available. The lowest common denominator turns out to be a C or C++, or both, language interface. Using a standard ISO/IEC 9899 C or ISO/IEC 14882 C++ aids portability. The year is not included in the requirement, so that obsolete compilers are not mandated.
Category Portability
Traced-from 4.1, 4.2, 4.7, 4.9, 5.1
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A


Go to top,
Skip to (prev) STRS-19, Skip to (next) STRS-21

7.20   STRS-20 Include STRS_ApplicationControl.h
Requirement Each STRS application shall contain:
#include “STRS_ApplicationControl.h”.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A


Go to top,
Skip to (prev) STRS-20, Skip to (next) STRS-22

7.21   STRS-21 Provide STRS_ApplicationControl.h
Requirement The STRS platform provider shall provide an “STRS_ApplicationControl.h” that contains the method prototypes for each STRS application and, for C++, the class definition for the base class STRS_ApplicationControl.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection
See Also N/A


Go to top,
Skip to (prev) STRS-21, Skip to (next) STRS-23

7.22   STRS-22 STRS_ApplicationControl Base Class
Requirement If the STRS Application-provided Application Control API is implemented in C++, the STRS application class shall be derived from the STRS_ApplicationControl base class.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection
See Also N/A
Example 
In C++, a MyWaveform.h file should contain a class definition of the form: 
class MyWaveform: public STRS_ApplicationControl 
{...};


Go to top,
Skip to (prev) STRS-22, Skip to (next) STRS-24

7.23   STRS-23 Include STRS_Sink.h
Requirement If the STRS application provides the APP_Write method, the STRS application shall contain:
#include “STRS_Sink.h”.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A


Go to top,
Skip to (prev) STRS-23, Skip to (next) STRS-25

7.24   STRS-24 Provide STRS_Sink.h
Requirement The STRS platform provider shall provide an “STRS_Sink.h” that contains the method prototypes for APP_Write and, for C++, the class definition for the base class STRS_Sink.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection
See Also N/A


Go to top,
Skip to (prev) STRS-24, Skip to (next) STRS-26

7.25   STRS-25 STRS_Sink Base Class
Requirement If the STRS Application-provided Application Control API is implemented in C++ and the STRS application provides the APP_Write method, the STRS application class shall be derived from the STRS_Sink base class.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection
See Also N/A
Example 
In C++, a MyWaveform.h file should contain a class definition of the form:
class MyWaveform:  public STRS_ApplicationControl, 
   public STRS_Sink 
{...};


Go to top,
Skip to (prev) STRS-25, Skip to (next) STRS-27

7.26   STRS-26 Include STRS_Source.h
Requirement If the STRS application provides the APP_Read method, the STRS application shall contain:
#include “STRS_Source.h”.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A


Go to top,
Skip to (prev) STRS-26, Skip to (next) STRS-28

7.27   STRS-27 Provide STRS_Source.h
Requirement The STRS platform provider shall provide an “STRS_Source.h” that contains the method prototypes for APP_Read and, for C++, the class definition for the base class STRS_Source.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection
See Also N/A


Go to top,
Skip to (prev) STRS-27, Skip to (next) STRS-29

7.28   STRS-28 STRS_Source Base Class
Requirement If the STRS Application-provided Application Control API is implemented in C++ and the STRS application provides the APP_Read method, the STRS application class shall be derived from the STRS_Source base class.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection
See Also N/A
Example In C++, the MyWaveform.h file should contain a class definition of the form:

   class MyWaveform:   public STRS_ApplicationControl,
                       public STRS_Source 
   {...};

If both APP_Read and APP_Write are provided in the same waveform, the C++ class will be derived from all three base classes named in requirements (STRS-22, STRS-25, and STRS-28). For example, the MyWaveform.h file should contain a class definition of the form:

   class MyWaveform:   public STRS_ApplicationControl,
                    public STRS_Sink,
                    public STRS_Source
   {...};


Go to top,
Skip to (prev) STRS-28, Skip to (next) STRS-30

7.29   STRS-29 APP_Configure
Requirement Each STRS application shall contain a callable APP_Configure method as described in table 5, APP_Configure().
Table 5
APP_Configure
Description Set the value for one property in the target component (application, device). It is the responsibility of the target component to determine which properties can be changed in which internal states. The API is defined in STRS_PropertySet.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C.
  • name – (in STRS_Property_Name) name or other identification of data to be obtained
  • value – (in STRS_Property_Value *) location of data to process/store in application corresponding to name
  • lenValue – (in STRS_Buffer_Size) actual length of data in value
Return status (STRS_Result) actual size stored unless error
Precondition None
Postcondition The appropriately named value is configured. When an error is returned, see the logs for more information.
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. In addition, APP_Configure was patterned after the configure method in the PropertySet interface in JTRS/SCA and OMG/SWRADIO.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3
Use Case Set Waveform Parameter
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_Configure
Example 
STRS_Result APP_Configure(STRS_Property_Name name, STRS_Property_Value *value, STRS_Buffer_Size nb) {
   STRS_Result rtn = STRS_OK;
   if (strcmp("A", name)==0  &&  nb <=  maxLa){
      strncpy(a, value, nb);
   } else
      if (strcmp("B",.name)==0  &&  nb <= maxLb){
         if (myState == STRS_APP_RUNNING) {
            rtn = STRS_WARNING;
         } else {
            strncpy(b, value, nb);
            rtn = strlen(b);
         }
      } else {
         rtn = STRS_WARNING;
      }
   }
   return rtn;
}


Go to top,
Skip to (prev) STRS-29, Skip to (next) STRS-31

7.30   STRS-30 APP_GroundTest
Requirement Each STRS application shall contain a callable APP_GroundTest method as described in table 9, APP_GroundTest().
Table 9
APP_GroundTest()
Description Perform unit and system testing, which is usually done before deployment. The testing may include calibration. The tests aid in isolating faults within the target component. A responding component may be in any internal state, but certain tests may be restricted to specific states. If the application is not in the appropriate internal state, then nothing is done and an error is returned. Property values may be used, if needed. The API is defined in STRS_TestableObject. The method is similar to APP_RunTest except that it contains more extensive testing used especially before deployment to satisfy any additional project requirements. This method may be invalid upon deployment and if so, it may be eliminated.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
  • testID – (in STRS_TestID) number of the test to be performed
Return status (STRS_Result)
Precondition None
Postcondition The test is performed. The state is unchanged unless specifically required by mission.
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. In addition, APP_GroundTest was patterned after the runTest method in the TestableObject interface in JTRS/SCA and OMG/SWRADIO. It performs system and unit testing usually done before deployment.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3, 5.15
Use Case Built-In Test
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_GroundTest
Example 
STRS_Result APP_GroundTest(STRS_TestID testID) {
   STRS_HandleID fromWF = APP_GetHandleID();
   if (testID == 0) {
       ...
      return STRS_OK;
   } else {
      STRS_Buffer_Size nb = strlen(
         "Invalid APP_GroundTest argument."); 
      STRS_Log(fromWF, STRS_ERROR_QUEUE,
         "Invalid APP_GroundTest argument.", nb);
      return STRS_ERROR;
   }
}


Go to top,
Skip to (prev) STRS-30, Skip to (next) STRS-32

7.31   STRS-31 APP_Initialize
Requirement Each STRS application shall contain a callable APP_Initialize method as described in table 10, APP_Initialize().
Table 10
APP_Initialize()
Description Initialize the target component (application, device). The API is defined in STRS_LifeCycle. The purpose is to set or reset the component to a known initial state. If no fault is detected, this method changes the internal state as appropriate.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
Return status (STRS_Result)
Precondition None
Postcondition None
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. In addition, APP_Initialize was patterned after the initialize method in the LifeCycle interface in JTRS/SCA and OMG/SWRADIO.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3
Use Case Waveform Instantiation
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_Initialize
Example 
STRS_Result APP_Initialize() {
   STRS_HandleID fromWF = APP_GetHandleID();
   if (myState == STRS_APP_RUNNING) {
      STRS_Buffer_Size nb = strlen(
         "Can't Init when STRS_APP_RUNNING.");
      STRS_Log(fromWF,STRS_WARNING_QUEUE,
         "Can't Init when STRS_APP_RUNNING.", nb);
      return STRS_WARNING;
   } else {
      ...
      myState = STRS_APP_STOPPED;
   }
   return STRS_OK;
}


Go to top,
Skip to (prev) STRS-31, Skip to (next) STRS-33

7.32   STRS-32 APP_Instance
Requirement Each STRS application shall contain a callable APP_Instance method as described in table 11, APP_Instance().
Table 11
APP_Instance()
Description Store the two parameters passed in the calling sequence, so that they are available to the constructor. In C++, APP_Instance is a static method used to call the class constructor for C++. If no fault is detected, this method returns an instance pointer and initializes the internal state.
Parameters
  • id – (in STRS_HandleID) handle ID of this STRS application.
  • name – (in char *) handle name of this STRS application.
Return Pointer to STRS_Instance, instance of class, in C or C++.
Precondition None
Postcondition None
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3
Use Case Waveform Instantiation
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example for C++ 
STRS_Instance *ThisSTRSApplication::APP_Instance(
                             STRS_HandleID handleID, 
                             char *name) {
    return new ThisSTRSApplication(handleID,name);
}
Example for C 
char handleName[nMax]; 
STRS_Instance *APP_Instance( STRS_HandleID handleID, 
                             char *name) {
    myQ = handleID;
    strncpy(handleName, name, nMax);
    myState = STRS_APP_INSTANTIATED;
    OE_DEFINED_MACRO_TO_SET_INST();
    return inst;
}


Go to top,
Skip to (prev) STRS-32, Skip to (next) STRS-34

7.33   STRS-33 APP_Query
Requirement Each STRS application shall contain a callable APP_Query method as described in table 12, APP_Query().
Table 12
APP_Query()
Description Obtain the value for a specified property in the target component (application, device). It is the responsibility of the target component to determine which properties can be interrogated in which internal states. The API is defined in STRS_PropertySet.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
  • name – (in STRS_Property_Name) name or other identification of data to be obtained
  • value – (in STRS_Property_Value *) location to store data corresponding to name
  • lenValue – (in STRS_Buffer_Size) maximum length of data in to be stored in value
Return status (STRS_Result) actual size unless error
Precondition The value is to have space allotted for the maximum size of the property whose value is to be returned (not bigger than lenValue).
Postcondition Value is populated with data, as appropriate. When an error is returned, see the logs for more information.
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. In addition, APP_Query was patterned after the query method in the PropertySet interface in JTRS/SCA and OMG/SWRADIO.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3
Use Case Get Waveform Parameter
Applicable to Application developer
Notes None
See Also STRS_Query
Verification Method Inspection using STRS compliance tool.
Example 
STRS_Result APP_Query(STRS_Property_Name *name, STRS_Property_Value *value, STRS_Buffer_Size nb) {
   if (strcmp("A",name)==0)
   {
      /* Variable "a" is declared as a  
       * character string, and typically 
       * contains a value set by APP_Configure.
       */
      if (a == NULL || strlen(a) >= nb) {
         rtn = STRS_ERROR;
      } else {
         strncpy(value, a, nb);
         rtn = strlen(value);
      }
   }
   return rtn;
}


Go to top,
Skip to (prev) STRS-33, Skip to (next) STRS-35

7.34   STRS-34 APP_Read
Requirement If the STRS application provides data to the infrastructure, then the STRS application shall contain a callable APP_Read method as described in table 13, APP_Read().
Table 13
APP_Read()
Description Method used to obtain data from the target component (application, device). This is optional. The API is defined in STRS_Source. The caller manages the buffer area, preallocating the buffer before calling APP_Read and processing the returned data without any effects on the data source application. The character data type (STRS_Message) does not have to contain valid characters. If the application is not in the appropriate internal state, then nothing is done and an error is returned.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
  • buffer – (out STRS_Message) a pointer to an area in which the application stores the requested data
  • nb – (in STRS_Buffer_Size) number of bytes requested
Return Error status (negative) or actual number of bytes (non-negative) obtained (STRS_Result)
Precondition Storage for the buffer with space for nb bytes is allocated before calling APP_Read. If used for a C style character string, the size should include space for a final ‘\0’.
Postcondition The data from the application is stored in the buffer area.
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3
Use Case Transmit a Packet
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_Read
Example 
STRS_Result APP_Read(STRS_Message buffer, 
    STRS_Buffer_Size nb) { 
    if (nb <= 4) return STRS_ERROR; 
    strcpy (buffer,"ABCD"); 
    return strlen(buffer); 
}


Go to top,
Skip to (prev) STRS-34, Skip to (next) STRS-36

7.35   STRS-35 APP_ReleaseObject
Requirement Each STRS application shall contain a callable APP_ReleaseObject method as described in table 14, APP_ReleaseObject().
Table 14
APP_ReleaseObject()
Description Free any resources that the target component (application, device) has acquired. An example would be to allow the target component to close any open files or devices. It is the responsibility of the target component to determine whether any release is done in which internal states. The API is defined in STRS_LifeCycle. The purpose of APP_ReleaseObject is to prepare the target component for removal.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
Return status (STRS_Result)
Precondition None
Postcondition All resources acquired by the target component are released. The application may not be usable unless reinstantiated or reinitialized.
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. In addition, APP_ReleaseObject was patterned after the releaseObject method in the LifeCycle interface in JTRS/SCA and OMG/SWRADIO.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3
Use Case Waveform Deallocation
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_ReleaseObject
Example 
STRS_Result APP_ReleaseObject() {
   STRS_HandleID fromWF = APP_GetHandleID();
   if (myState == STRS_APP_RUNNING) {
      STRS_Buffer_Size nb = strlen(
         "Can't free resources when RUNNING.");
      STRS_Log(fromWF,STRS_WARNING_QUEUE,
         "Can't free resources when RUNNING.", nb);
      return STRS_WARNING;
   } else {
      ...
   }
   return STRS_OK;
}


Go to top,
Skip to (prev) STRS-35, Skip to (next) STRS-37

7.36   STRS-36 APP_RunTest
Requirement Each STRS application shall contain a callable APP_RunTest method as described in table 15, APP_RunTest().
Table 15
APP_RunTest()
Description Test specific functionality within the target component (application, device). The tests provide aid in isolating faults within the application. Application may be in any internal state, but certain tests may be restricted to specific states. If the application is not in the appropriate internal state, then nothing is done and an error is returned. Property values may be used, if needed. The API is defined in STRS_TestableObject.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
  • testID – (in STRS_TestID) number of the test to be performed. Values of testID are mission dependent.
Return status (STRS_Result)
Precondition None
Postcondition The test is performed.
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. In addition, APP_RunTest was patterned after the runTest method in the TestableObject interface in JTRS/SCA and OMG/SWRADIO. It performs system and unit testing usually done after deployment.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3, 5.15
Use Case Built-In Test
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_RunTest
Example 
STRS_Result APP_RunTest(STRS testID) {
    
    if (testID == 1 ) {
       ...
    } else {
       STRS_HandleID fromWF = APP_GetHandleID();
       STRS_Buffer_Size nb = strlen(
          "Invalid APP_RunTest argument testID.");
       STRS_Log(fromWF, STRS_ERROR_QUEUE,
          "Invalid APP_RunTest argument testID.",
          nb);
       return STRS_ERROR;
    }
    return STRS_OK;
}


Go to top,
Skip to (prev) STRS-36, Skip to (next) STRS-38

7.37   STRS-37 APP_Start
Requirement Each STRS application shall contain a callable APP_Start method as described in table 16, APP_Start().
Table 16
APP_Start()
Description Begin normal target component (application, device) processing. If the application is not in the appropriate internal state, then nothing is done and an error is returned. The API is defined in STRS_ControllableComponent.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
Return status (STRS_Result)
Precondition None
Postcondition None
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. In addition, APP_Start was patterned after the start method in the Resource interface in JTRS/SCA and ControllableComponent interface in OMG/SWRADIO.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3
Use Case Waveform Start
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_Start
Example 
STRS_Result APP_Start() {
   if (myState == STRS_APP_STOPPED) {
      ...
      myState = STRS_APP_RUNNING;
      ...
   } else {
      return STRS_ERROR;
   }
   return STRS_OK;
}


Go to top,
Skip to (prev) STRS-37, Skip to (next) STRS-39

7.38   STRS-38 APP_Stop
Requirement Each STRS application shall contain a callable APP_Stop method as described in table 17, APP_Stop().
Table 17
APP_Stop()
Description End normal target component (application, device) processing. If the application is not in the appropriate internal state, then nothing is done and an error is returned. The API is defined in STRS_ControllableComponent.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
Return status (STRS_Result)
Precondition None
Postcondition None
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. In addition, APP_Stop was patterned after the stop method in the Resource interface in JTRS/SCA and ControllableComponent interface in OMG/SWRADIO.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3
Use Case Waveform Stop
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_Stop
Example 
STRS_Result APP_Stop() {
   if (myState == STRS_APP_RUNNING) {
      ...
      myState = STRS_APP_STOPPED;
      ...
   } else {
      return STRS_ERROR;
   }
   return STRS_OK;
}


Go to top,
Skip to (prev) STRS-38, Skip to (next) STRS-40

7.39   STRS-39 APP_Write
Requirement If the STRS application receives data from the infrastructure, then the STRS application shall contain a callable APP_Write method as described in table 18, APP_Write().
Table 18
APP_Write()
Description Method used to send data to the target component (application, device). This is optional. The API is defined in STRS_Sink. The caller manages the buffer area, preallocating and filling the buffer before calling APP_Write. The character data type (STRS_Message) does not have to contain valid characters. If the application is not in the appropriate internal state, then nothing is done and an error is returned.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
  • buffer – (in STRS_Message) pointer to the data for the application to process
  • nb – (in STRS_Buffer_Size) number of bytes in buffer
Return Error status (negative) or number of bytes (non-negative) written (STRS_Result)
Precondition Storage for the buffer with space for nb bytes is allocated before calling APP_Write. If used for a C style character string, the size should include space for a final ‘\0’.
Postcondition The data has been captured by the application for its processing.
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3
Use Case Receive a Packet
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_Write
Example 
STRS_Result APP_Write(STRS_Message buffer, 
       STRS_Buffer_Size nb) { 
    /* Data in buffer is character data. */ 
    if (strlen(buffer) != nb -1) 
       return STRS_ERROR;
    int nco = fprintf(stdout,"%s\n",buffer); 
    return (STRS_Result) nco; 
}


Go to top,
Skip to (prev) STRS-39, Skip to (next) STRS-41

7.40   STRS-40 STRS_Configure
Requirement The STRS infrastructure shall contain a callable STRS_Configure method as described in table 19, STRS_Configure().
Table 19
STRS_Configure()
Description Set the value for one property in the target component (application, device). It is the responsibility of the target component to determine which properties can be changed in which internal states.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toWF – (in STRS_HandleID) handle ID of target component that should respond to the request.
  • name – (in STRS_Property_Name) name or other identification of data to be obtained
  • value – (in STRS_Property_Value *) location of data to process/store in application corresponding to name
  • lenValue – (in STRS_Buffer_Size) actual length of data in value
Return status (STRS_Result) actual size stored unless error
Precondition None
Postcondition The appropriate named value is configured. When an error is returned, see the logs for more information.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. The signature of the infrastructure method is different from the signature of the corresponding application method because there has to be a C language interface to the infrastructure method and it has to contain additional information that allows the infrastructure to determine whether the target component is C or C++ and call the corresponding application method appropriately.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2
Use Case Set Waveform Parameter
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also APP_Configure
Example 
/* Set A=5, B=27. */
STRS_Result rtn;
STRS_HandleID fromWF = APP_GetHandleID();
Do while (true) {
    rtn = STRS_Configure(fromWF,toWF, "A", "5", 1);
    if ( ! STRS_IsOK(rtn)) break;
    rtn = STRS_Configure(fromWF,toWF, "B", "27", 2);
    if ( ! STRS_IsOK(rtn)) break;
    break;
}
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "STRS_Configure fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "STRS_Configure fails.", nb);
}


Go to top,
Skip to (prev) STRS-40, Skip to (next) STRS-42

7.41   STRS-41 STRS_GroundTest
Requirement The STRS infrastructure shall contain a callable STRS_GroundTest method as described in table 20, STRS_GroundTest().
Table 20
STRS_GroundTest()
Description Perform unit and system testing-usually done before deployment. The testing may include calibration. The tests aid in isolating faults within the target component. This method provides more exhaustive testing to satisfy any additional project requirements. A responding component may be in any internal state, but certain tests may be restricted to specific states. If the application is not in the appropriate internal state, then nothing is done and an error is returned. Property values may be used, if needed. This method may be invalid upon deployment.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toWF – (in STRS_HandleID) handle ID of target component that should respond to the request.
  • testID – (in STRS_TestID) number of the test to be performed. Values are mission dependent.
Return status (STRS_Result)
Precondition None
Postcondition The test is performed.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. The signature of the infrastructure method is different from the signature of the corresponding application method because there has to be a C language interface to the infrastructure method and it has to contain additional information that allows the infrastructure to determine whether the target component is C or C++ and call the corresponding application method appropriately. It performs system and unit testing usually done before deployment.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.15
Use Case Built-In Test
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also APP_GroundTest
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = 
    STRS_GroundTest(fromWF,toWF,testID);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "GroundTest fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE, 
       "GroundTest fails.", nb);
}


Go to top,
Skip to (prev) STRS-41, Skip to (next) STRS-43

7.42   STRS-42 STRS_Initialize
Requirement The STRS infrastructure shall contain a callable STRS_Initialize method as described in table 21, STRS_Initialize().
Table 21
STRS_Initialize()
Description Initialize the target component (application, device). The purpose is to set or reset the component to a known initial state.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toWF – (in STRS_HandleID) handle ID of target component that should respond to the request.
Return status (STRS_Result)
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. The signature of the infrastructure method is different from the signature of the corresponding application method because there has to be a C language interface to the infrastructure method and it has to contain additional information that allows the infrastructure to determine whether the target component is C or C++ and call the corresponding application method appropriately.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2
Use Case Waveform Instantiation
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also APP_Initialize
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = STRS_Initialize(fromWF,toWF);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "STRS_Initialize fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE, 
       "STRS_Initialize fails.", nb);
}


Go to top,
Skip to (prev) STRS-42, Skip to (next) STRS-44

7.43   STRS-43 STRS_Query
Requirement The STRS infrastructure shall contain a callable STRS_Query method as described in table 22, STRS_Query().
Table 22
STRS_Query()
Description Obtain the value for a specified property in the target component (application, device).
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toWF – (in STRS_HandleID) handle ID of target component that should respond to the request.
  • name – (in STRS_Property_Name) name or other identification of data to be obtained
  • value – (in STRS_Property_Value *) location to store data corresponding to name
  • lenValue – (in STRS_Buffer_Size) maximum length of data in to be stored in value
Return status (STRS_Result) actual size unless error
Precondition The value is to have space allotted for the maximum size of the property whose value is to be returned (not bigger than lenValue).
Postcondition Value is populated with data as appropriate. When an error is returned, see the logs for more information.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. The signature of the infrastructure method is different from the signature of the corresponding application method because there has to be a C language interface to the infrastructure method and it has to contain additional information that allows the infrastructure to determine whether the target component is C or C++ and call the corresponding application method appropriately.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2
Use Case Get Waveform Parameter
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also APP_Query
Example 
STRS_Result rtn;
STRS_HandleID fromWF = APP_GetHandleID();
Do while (true) {
   rtn = STRS_Query(fromWF,toWF,"A", a, maxLa);
   if ( ! STRS_IsOK(rtn)) break;
   rtn = STRS_Query(fromWF,toWF,"B", b, maxLb);
   if ( ! STRS_IsOK(rtn)) break;
   break;
}
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "STRS_Query fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "STRS_Query fails.", nb);
}
cout << "A = " << a << std::endl;
cout << "B = " << b << std::endl;


Go to top,
Skip to (prev) STRS-43, Skip to (next) STRS-45

7.44   STRS-44 STRS_ReleaseObject
Requirement The STRS infrastructure shall contain a callable STRS_ReleaseObject method as described in table 23, STRS_ReleaseObject().
Table 23
STRS_ReleaseObject()
Description Free any resources that the target component (application, device) has acquired. An example would be to allow the target component to close any open files or devices. It is the responsibility of the target component to determine whether any release is done in which internal states. The purpose of STRS_ReleaseObject is to prepare the target component for removal.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toWF – (in STRS_HandleID) handle ID of target component that should respond to the request.
Return status (STRS_Result)
Precondition None
Postcondition All resources acquired by the target component are released. The target component may not be usable unless reinstantiated or reinitialized.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. The signature of the infrastructure method is different from the signature of the corresponding application method because there has to be a C language interface to the infrastructure method and it has to contain additional information that allows the infrastructure to determine whether the target component is C or C++ and call the corresponding application method appropriately.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2
Use Case Get Waveform Parameter
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also APP_ReleaseObject
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = 
    STRS_ReleaseObject(fromWF,toWF);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "STRS_ReleaseObject fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "STRS_ReleaseObject fails.", nb);
}


Go to top,
Skip to (prev) STRS-44, Skip to (next) STRS-46

7.45   STRS-45 STRS_RunTest
Requirement The STRS infrastructure shall contain a callable STRS_RunTest method as described in table 24, STRS_RunTest().
Table 24
STRS_RunTest()
Description Test specific functionality within the target component (application, device). The tests provide aid in isolating faults within the target component. A responding application may be in any internal state, but certain tests may be restricted to specific states. If the application is not in the appropriate internal state, then nothing is done and an error is returned. Property values may be used, if needed.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toWF – (in STRS_HandleID) handle ID of target component that should respond to the request.
  • testID – (in STRS_TestID) number of the test to be performed. Values of testID are mission-dependent.
Return status (STRS_Result)
Precondition None
Postcondition The test is performed.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. The signature of the infrastructure method is different from the signature of the corresponding application method because there has to be a C language interface to the infrastructure method and it has to contain additional information that allows the infrastructure to determine whether the target component is C or C++ and call the corresponding application method appropriately. It performs system and unit testing usually done after deployment.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2, 5.15
Use Case Built-In Test
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also APP_RunTest
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = 
    STRS_RunTest(fromWF,toWF,1);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "STRS_RunTest fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE, 
       "STRS_RunTest fails.", nb);
}


Go to top,
Skip to (prev) STRS-45, Skip to (next) STRS-47

7.46   STRS-46 STRS_Start
Requirement The STRS infrastructure shall contain a callable STRS_Start method as described in table 25, STRS_Start().
Table 25
STRS_Start()
Description Begin normal target component (application, device) processing. Nothing is done if the application (or device) is not in the appropriate internal state.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toWF – (in STRS_HandleID) handle ID of target component that should respond to the request.
Return status (STRS_Result)
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. The signature of the infrastructure method is different from the signature of the corresponding application method because there has to be a C language interface to the infrastructure method and it has to contain additional information that allows the infrastructure to determine whether the target component is C or C++ and call the corresponding application method appropriately.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2
Use Case Waveform Start
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also APP_Start
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = STRS_Start(fromWF,toWF);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "STRS_Start fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "STRS_Start fails.", nb);
}


Go to top,
Skip to (prev) STRS-46, Skip to (next) STRS-48

7.47   STRS-47 STRS_Stop
Requirement The STRS infrastructure shall contain a callable STRS_Stop method as described in table 26, STRS_Stop().
Table 26
STRS_Stop()
Description End target component (application, device) processing. Nothing is done unless the application (or device) is in the appropriate internal state.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toWF – (in STRS_HandleID) handle ID of target component that should respond to the request.
Return status (STRS_Result)
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms. The signature of the infrastructure method is different from the signature of the corresponding application method because there has to be a C language interface to the infrastructure method and it has to contain additional information that allows the infrastructure to determine whether the target component is C or C++ and call the corresponding application method appropriately.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2
Use Case Waveform Start
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also APP_Stop
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = STRS_Stop(fromWF,toWF);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "STRS_Stop fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "STRS_Stop fails.", nb);
}


Go to top,
Skip to (prev) STRS-47, Skip to (next) STRS-49

7.48   STRS-48 STRS_AbortApp
Requirement The STRS infrastructure shall contain a callable STRS_AbortApp method as described in table 27, STRS_AbortApp().
Table 27
STRS_AbortApp()
Description Abort an application or service.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toWF – (in STRS_HandleID) handle ID of target component that should respond to the request
Return Status (STRS_Result)
Precondition None
Postcondition The target component is aborted, and application is stopped, resources released, and unloaded, if allowed by OE.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to implement and use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2
Use Case Waveform Abort
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = STRS_AbortApp(fromWF,toWF);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "AbortApp fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE, 
       "AbortApp fails.", nb);
}


Go to top,
Skip to (prev) STRS-48, Skip to (next) STRS-50

7.49   STRS-49 STRS_GetErrorQueue
Requirement The STRS infrastructure shall contain a callable STRS_GetErrorQueue method as described in table 28, STRS_GetErrorQueue().
Table 28
STRS_GetErrorQueue()
Description Transform an error status into an error queue.
Parameters
  • result – (in STRS_Result) return value of previous call.
Return Handle ID (STRS_HandleID) corresponding to invalid STRS_Result; that is, return STRS_ERROR_QUEUE for STRS_ERROR, STRS_WARNING_QUEUE for STRS_WARNING, and STRS_FATAL_QUEUE for STRS_FATAL; otherwise, implementation defined.
Precondition None
Postcondition The corresponding error queue handle ID is returned.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_IsOK
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = STRS_AbortApp(fromWF,toWF);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "AbortApp fails.");
    STRS_Log(fromWF, STRS_GetErrorQueue(rtn), 
       "AbortApp fails.", nb);
}


Go to top,
Skip to (prev) STRS-49, Skip to (next) STRS-51

7.50   STRS-50 STRS_HandleRequest
Requirement The STRS infrastructure shall contain a callable STRS_HandleRequest method as described in table 30, STRS_HandleRequest().
Table 30
STRS_HandleRequest()
Description The handle ID is obtained for the given handle name. The handle ID of the current component (fromWF) is used for any error message. Using STRS_HandleRequest to determine the handle ID of the current component while it is being instantiated gives undefined results.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toResourceName – (in char *) name of desired resource (application, device, file, queue).
Return Handle ID of the entity or error status. ( STRS_HandleID)
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_ValidateHandleID, STRS_GetHandleName
Example 
STRS_HandleID fromWF = APP_GetHandleID();
char toResourceName[] = "WF1";
STRS_HandleID toID = STRS_HandleRequest(fromWF,
   toResourceName);
STRS_Result rtn = STRS_ValidateHandleID(toID);
If ( ! STRS_IsOK(rtn)) {
   STRS_HandleID errQ = STRS_GetErrorQueue(rtn);
   STRS_Buffer_Size nb = strlen(
      "Did not find handle ID.");
   STRS_Log(fromWF,errQ,
      "Did not find handle ID.", nb);
} else {
   std::cout << "Found Handle for " 
             << toResourceName << ": "
             << toID << std::endl;
}


Go to top,
Skip to (prev) STRS-50, Skip to (next) STRS-52

7.51   STRS-51 STRS_InstantiateApp
Requirement The STRS infrastructure shall contain a callable STRS_InstantiateApp method as described in table 31, STRS_InstantiateApp().
Table 31
STRS_InstantiateApp()
Description Instantiate an application, service, or device. The handle name specified for the application, service, or device is to be unique. The OE-specific name is used to identify the application for instantiation and may impose additional operations to be performed as documented by the platform provider. It is up to the OE to determine whether any resources are to be loaded to accomplish the instantiation.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • handleName – (in char *) unique handle name for the application (or device) that should be instantiated.
  • startName – (in char *) OE-specific name used to instantiate and configure the application (or device) into a known state.
Return handle ID (STRS_HandleID) of the application (or device) instantiated or the error status
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case Waveform Instantiation
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
char toWF[STRS_MAX_PATH_LENGTH];
char handleName[STRS_MAX_HANDLE_NAME_LENGTH];
STRS_HandleID fromWF = APP_GetHandleID();
// OE-specific string defines a configuration file.
strcpy(toWF,"/path/STRS_WFxxx.cfg");
strcpy(handleName,"WFxxx");
STRS_HandleID wfID = 
    STRS_InstantiateApp(fromWF,handleName,toWF);
STRS_Result rtn = STRS_ValidateHandleID(wfID);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "InstantiateApp fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE, 
       "InstantiateApp fails.", nb);
}


Go to top,
Skip to (prev) STRS-51, Skip to (next) STRS-53

7.52   STRS-52 STRS_IsOK
Requirement The STRS infrastructure shall contain a callable STRS_IsOK method as described in table 32, STRS_IsOK().
Table 32
STRS_IsOK()
Description Return true, if return value of argument obtained from previous call is not an error status.
Parameters
  • result – (in STRS_Result) return value of previous call.
Return true, if STRS_Result is not STRS_WARNING, STRS_ERROR, or STRS_FATAL: that is, non-negative (bool)
Precondition Previous call returns a status result.
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_GetErrorQueue
Example 
char toWF[MAX_PATH_LENGTH];
char handleName[STRS_MAX_HANDLE_NAME_LENGTH];
STRS_HandleID fromWF = APP_GetHandleID();
strcpy(toWF,"/path/STRS_WFxxx.cfg");
strcpy(handleName,"WFxxx");
STRS_HandleID wfID = 
    STRS_InstantiateApp(fromWF,handleName,toWF);
STRS_Result rtn = STRS_ValidateHandleID(wfID);
if ( ! STRS_IsOK(rtn) {
    STRS_Buffer_Size nb = strlen(
       "InstantiateApp fails.");
    STRS_Log(fromWF, STRS_GetErrorQueue(wfID), 
       "InstantiateApp fails.", nb);
}


Go to top,
Skip to (prev) STRS-52, Skip to (next) STRS-54

7.53   STRS-53 STRS_Log
Requirement The STRS infrastructure shall contain a callable STRS_Log method as described in table 33, STRS_Log().
Table 33
STRS_Log()
Description Send log message for distribution as appropriate. The time stamp and an indication of the from and target handles are added automatically. STRS_Log may be used to inform the infrastructure that the STRS component is in the FAULT state when a target handle ID of STRS_ERROR_QUEUE, STRS_WARNING_QUEUE, or STRS_FATAL_QUEUE is used. The character data type (STRS_Message) does not have to contain valid characters.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • logTarget – (in STRS_HandleID) handle ID of target (e.g., STRS_TELEMETRY_QUEUE, STRS_ERROR_QUEUE, STRS_WARNING_QUEUE, or STRS_FATAL_QUEUE). The last three special-purpose handle IDs may be used to log errors.
  • msg – (in STRS_Message) a pointer to the data to process
  • nb – (in STRS_Buffer_Size) number of bytes in buffer
Return status (STRS_Result)
Precondition None
Postcondition Log message is distributed.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case Fault Management
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also See STRS_RunTest or APP_RunTest for further examples.
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Buffer_Size nb = strlen("file does not exist.");
STRS_Log(fromWF,STRS_ERROR_QUEUE, 
    "file does not exist.", nb);
// This could produce a line something like: 
//   19700101000000;WF1,ERROR,file does not exist.


Go to top,
Skip to (prev) STRS-53, Skip to (next) STRS-55

7.54   STRS-54 STRS_Log Error
Requirement When an STRS application has a nonfatal error, the STRS application shall use the callable STRS_Log method as described in table 33, STRS_Log(), with a target handle ID of constant STRS_ERROR_QUEUE.
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case Fault Management
Applicable to Application developer
Notes None
Verification Method Inspection
See Also N/A
Example None


Go to top,
Skip to (prev) STRS-54, Skip to (next) STRS-56

7.55   STRS-55 STRS_Log Fatal
Requirement When an STRS application has a fatal error, the STRS application shall use the callable STRS_Log method as described in table 33, STRS_Log(), with a target handle ID of constant STRS_FATAL_QUEUE.
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Applicable to Application developer
Notes None
Verification Method Inspection
See Also N/A
Example None


Go to top,
Skip to (prev) STRS-55, Skip to (next) STRS-57

7.56   STRS-56 STRS_Log Warning
Requirement When an STRS application has a warning condition, the STRS application shall use the callable STRS_Log method as described in table 33, STRS_Log(), with a target handle ID of constant STRS_WARNING_QUEUE.
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case Fault Management
Applicable to Application developer
Notes None
Verification Method Inspection
See Also N/A
Example None


Go to top,
Skip to (prev) STRS-56, Skip to (next) STRS-58

7.57   STRS-57 STRS_Log Telemetry
Requirement When an STRS application needs to send telemetry, the STRS application shall use the callable STRS_Log method as described in table 33, STRS_Log(), with a target handle ID of constant STRS_TELEMETRY_QUEUE.
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection
See Also N/A
Example None


Go to top,
Skip to (prev) STRS-57, Skip to (next) STRS-59

7.58   STRS-58 STRS_Write
Requirement The STRS infrastructure shall contain a callable STRS_Write method as described in table 36, STRS_Write().
Table 36
STRS_Write()
Description Method used to send data to a target component (application, device, file, or queue) acting as a sink. The caller manages the buffer area, preallocating and filling the buffer before calling STRS_Write. The character data type (STRS_Message) does not have to contain valid characters.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toID – (in STRS_HandleID) handle ID of target component that should respond to the request and that implemented STRS_Sink.
  • buffer – (in STRS_Message) a pointer to the data to process
  • nb – (in STRS_Buffer_Size) number of bytes in buffer
Return Error status (negative) or number of bytes (non-negative) written (STRS_Result)
Precondition Storage for the buffer is allocated before calling STRS_Write having space for at least nb bytes. If used for a C style character string, the size should include space for a final ‘\0’.
Postcondition The data has been captured by the target component for its processing.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case Receive a Packet
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also APP_Write
Example 
STRS_HandleID fromWF = APP_GetHandleID();
char buffer[32];
strcpy(buffer,"ABCDE");
STRS_Buffer_Size nb = strlen(buffer);
STRS_Result rtn = 
    STRS_Write(fromWF,toID,buffer,nb);


Go to top,
Skip to (prev) STRS-58, Skip to (next) STRS-60

7.59   STRS-59 STRS_Read
Requirement The STRS infrastructure shall contain a callable STRS_Read method as described in table 37, STRS_Read().
Table 37
STRS_Read()
Description Method used to obtain data from a target component (application, device, file, or queue) acting as a source or supplier. The caller manages the buffer area, preallocating the buffer before calling STRS_Read and processing the returned data without any effects on the data source application. The character data type (STRS_Message) does not have to contain valid characters.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • pullID – (in STRS_HandleID) handle ID of target component that should respond to the request and that implemented STRS_Source.
  • buffer – (out STRS_Message) a pointer to an area in which to store the data requested
  • nb – (in STRS_Buffer_Size) number of bytes requested
Return Error status (negative) or actual number of bytes (non-negative) obtained (STRS_Result)
Precondition Storage for the buffer is allocated before calling STRS_Read, having space for at least nb bytes. If used for a C style character string, the size should include space for a final ‘\0’.
Postcondition The data from the target component is stored in the buffer area.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability, Extensibility
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case Transmit a Packet
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also APP_Read
Example 
STRS_HandleID fromWF = APP_GetHandleID();
char buffer[32];
STRS_Buffer_Size nb = 32;
STRS_Result rtn = 
    STRS_Read(fromWF,pullID,buffer,nb);


Go to top,
Skip to (prev) STRS-59, Skip to (next) STRS-61

7.60   STRS-60 Device Control (Deleted)
Rationale This requirement was deleted because whenSTRS-10 wording was made more robust, STRS-60 became superfluous. STRS-60 previously stated: The STRS applications shall use the methods in the STRS infrastructure Device Control API, STRS infrastructure-provided Application Control API, Infrastructure Data Source API (if appropriate), and Infrastructure Data Sink API (if appropriate) to control the STRS Devices.


Go to top,
Skip to (prev) STRS-60, Skip to (next) STRS-62

7.61   STRS-61 STRS_DeviceClose
Requirement The STRS infrastructure shall contain a callable STRS_DeviceClose method as described in table 38, STRS_DeviceClose().
Table 38
STRS_DeviceClose()
Description Close the open device.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toDev – (in STRS_HandleID) handle ID of device that should respond to the request.
Return status (STRS_Result)
Precondition None
Postcondition The device is closed.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = 
    STRS_DeviceClose(fromWF,toDev);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "DeviceClose fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "DeviceClose fails.", nb);
}


Go to top,
Skip to (prev) STRS-61, Skip to (next) STRS-63

7.62   STRS-62 STRS_DeviceFlush
Requirement The STRS infrastructure shall contain a callable STRS_DeviceFlush method as described in table 39, STRS_DeviceFlush().
Table 39
STRS_DeviceFlush()
Description Used the opened device to send any buffered data immediately to the underlying hardware and clear the buffers.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toDev – (in STRS_HandleID) handle ID of device that should respond to the request.
Return status (STRS_Result)
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = 
    STRS_DeviceFlush(fromWF,toDev);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "DeviceFlush fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "DeviceFlush fails.", nb);
}


Go to top,
Skip to (prev) STRS-62, Skip to (next) STRS-64

7.63   STRS-63 STRS_DeviceLoad
Requirement The STRS infrastructure shall contain a callable STRS_DeviceLoad method as described in table 40, STRS_DeviceLoad().
Table 40
STRS_DeviceLoad()
Description Load a binary image to the open device.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toDev – (in STRS_HandleID) handle ID of device that should respond to the request.
  • filename – (in char *) storage area name or fully qualified file name of the binary image to load onto the hardware device.
Return status (STRS_Result)
Precondition None
Postcondition The binary image is stored in the target device.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = 
    STRS_DeviceLoad(fromWF,toDev,
    "/path/WF1.FPGA.bit");
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "DeviceLoad fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "DeviceLoad fails.", nb);
}


Go to top,
Skip to (prev) STRS-63, Skip to (next) STRS-65

7.64   STRS-64 STRS_DeviceOpen
Requirement The STRS infrastructure shall contain a callable STRS_DeviceOpen method as described in table 41, STRS_DeviceOpen().
Table 41
STRS_DeviceOpen()
Description Open the device.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toDev – (in STRS_HandleID) handle ID of device that should respond to the request.
Return status (STRS_Result)
Precondition None
Postcondition The device is opened.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = 
    STRS_DeviceOpen(fromWF,toDev);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "DeviceOpen fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "DeviceOpen fails.", nb);
}


Go to top,
Skip to (prev) STRS-64, Skip to (next) STRS-66

7.65   STRS-65 STRS_DeviceReset
Requirement The STRS infrastructure shall contain a callable STRS_DeviceReset method as described in table 42, STRS_DeviceReset().
Table 42
STRS_DeviceReset()
Description Reinitialize the device, if possible. Reset is normally used after the corresponding device has been started and stopped, and before the device is started again to bring the hardware device to its power-on state.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toDev – (in STRS_HandleID) handle ID of device that should respond to the request.
Return status (STRS_Result)
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = 
    STRS_DeviceReset(fromWF,toDev);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "DeviceReset fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "DeviceReset fails.", nb);
}


Go to top,
Skip to (prev) STRS-65, Skip to (next) STRS-67

7.66   STRS-66 STRS_DeviceStart (Deleted)
Rationale This requirement was deleted because it is redundant; STRS_Start is used instead. STRS-66 previously stated: The STRS infrastructure shall contain a callable STRS_DeviceStart method.


Go to top,
Skip to (prev) STRS-66, Skip to (next) STRS-68

7.67   STRS-67 STRS_DeviceStop (Deleted)
Rationale This requirement was deleted because it is redundant; STRS_Stop is used instead. STRS-67 previously stated: The STRS infrastructure shall contain a callable STRS_DeviceStop method.


Go to top,
Skip to (prev) STRS-67, Skip to (next) STRS-69

7.68   STRS-68 STRS_DeviceUnload
Requirement The STRS infrastructure shall contain a callable STRS_DeviceUnload method as described in table 43, STRS_DeviceUnload().
Table 43
STRS_DeviceUnload()
Description Unload the open device.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toDev – (in STRS_HandleID) handle ID of device that should respond to the request.
Return status (STRS_Result)
Precondition None
Postcondition The device is unloaded.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case Waveform Deallocation
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = 
    STRS_DeviceUnload(fromWF,toDev);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "DeviceUnload fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "DeviceUnload fails.", nb);
}


Go to top,
Skip to (prev) STRS-68, Skip to (next) STRS-70

7.69   STRS-69 STRS_SetISR
Requirement The STRS infrastructure shall contain a callable STRS_SetISR method as described in table 44, STRS_SetISR().
Table 44
STRS_SetISR()
Description Set the Interrupt Service Routine for the device.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of the current component making the request.
  • toDev – (in STRS_HandleID) handle ID of the device that should respond to the request.
  • pfun – (in STRS_ISR_Function) function pointer to a static or non-class function to be called to service the interrupt
Return status (STRS_Result)
Precondition None
Postcondition ISR function is activated.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes The callback function whose address is passed to the STRS_SetISR method may be different for different OE’s. The OE-specific documentation tells whether there are any arguments and if so, what they are. The most likely argument would be an instance variable obtained from the handle ID with which the function may obtain and/or set instance data.
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID myQ = APP_GetHandleID();
qnew=myQ;
fp = (STRS_ISR_Function) Test_ISR_Method;
fprintf(stdout,
   "Pointer to function Test_ISR_ Method: %p\n",fp);
rtn = STRS_SetISR(myQ,qnew,(STRS_ISR_Function) fp);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "STRS_SetISR fails for Test_ISR_Method.");
    STRS_Log(myQ, STRS_ERROR_QUEUE, 
       "STRS_SetISR fails for Test_ISR_Method.", nb);
}


Go to top,
Skip to (prev) STRS-69, Skip to (next) STRS-71

7.70   STRS-70 STRS_FileClose
Requirement The STRS infrastructure shall contain a callable STRS_FileClose method as described in table 51, STRS_FileClose().
Table 51
STRS_FileClose()
Description Close the open file. STRS_FileClose is used to close a file that has been opened by STRS_FileOpen.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toFile – (in STRS_HandleID) handle ID of file to be closed.
Return status (STRS_Result)
Precondition None
Postcondition The file is closed and the handle ID is released.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_FileOpen
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = STRS_FileClose(fromWF,toFile);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "FileClose fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "FileClose fails.", nb);
}


Go to top,
Skip to (prev) STRS-70, Skip to (next) STRS-72

7.71   STRS-71 STRS_FileGetFreeSpace
Requirement The STRS infrastructure shall contain a callable STRS_FileGetFreeSpace method as described in table 52, STRS_FileGetFreeSpace().
Table 52
STRS_FileGetFreeSpace()
Description Get total size of free space available for file storage.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • fileSystem – (in char *) used when more than one file system exists.
Return Total size in bytes (STRS_File_Size).
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_File_Size size = 
    STRS_FileGetFreeSpace(fromWF,NULL);
if (size < 0) {
    STRS_Buffer_Size nb = strlen(
       "FileGetFreeSpace fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "FileGetFreeSpace fails.", nb);
}


Go to top,
Skip to (prev) STRS-71, Skip to (next) STRS-73

7.72   STRS-72 STRS_FileGetSize
Requirement The STRS infrastructure shall contain a callable STRS_FileGetSize method as described in table 53, STRS_FileGetSize().
Table 53
STRS_FileGetSize()
Description Get the size of the specified file.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • filename – (in char *) storage area name or fully qualified file name of the file for which the size is obtained.
Return File size in bytes (STRS_File_Size).
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_File_Size size = 
    STRS_FileGetSize(fromWF,"/path/WF1.FPGA.bit");
if (size < 0) {
    STRS_Buffer_Size nb = strlen(
       "FileGetSize fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "FileGetSize fails.", nb);
}


Go to top,
Skip to (prev) STRS-72, Skip to (next) STRS-74

7.73   STRS-73 STRS_FileGetStreamPointer
Requirement The STRS infrastructure shall contain a callable STRS_FileGetStreamPointer method as described in table 54, STRS_FileGetStreamPointer().
Table 54
STRS_FileGetStreamPointer()
Description Get the file stream pointer for the open file associated with the STRS handle ID. This is normally not used because either the common functions are built into the STRS architecture or the entire file manipulation is local to one application or device. This method may be needed for certain file operations not built into the STRS architecture and distributed over more than one application or device or the STRS infrastructure. For example, the file stream pointer may be used when multiple applications write to the same file using a queue or need features not found in STRS_Write. Having a file system is optional; if no file system is present, NULL will be returned. A NULL will also be returned if another error condition is detected.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toFile – (in STRS_HandleID) file handle ID.
Return File stream pointer (FILE *) or NULL for error condition.
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale STRS-73 solves the potential problem of I/O methods missing from NASA-STD-4009A. Since not all SDRs will have a file system, this method should be used sparingly with comments describing its purpose.
Category Extensibility
Traced-from 4.4, 4.5
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_FileOpen
Example 
STRS_HandleID fromWF = APP_GetHandleID();
FILE *fsp = 
    STRS_FileGetStreamPointer(fromWF,toFile);
if (fsp == NULL) {
    STRS_Buffer_Size nb = strlen( 
       "FileGetStreamPointer fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "FileGetStreamPointer fails.", nb);
} else {
    rewind(fsp);
}


Go to top,
Skip to (prev) STRS-73, Skip to (next) STRS-75

7.74   STRS-74 STRS_FileOpen
Requirement The STRS infrastructure shall contain a callable STRS_FileOpen method as described in table 55, STRS_FileOpen().
Table 55
STRS_FileOpen()
Description Open the file. This method is used to obtain an STRS handle ID when the file manipulation is either built into the STRS architecture or distributed over more than one application or device or the STRS infrastructure.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • filename – (in char *) file name of the file to be opened.
  • file access – (in STRS_Access) indicates if file is to be opened for reading, writing, both, or appending.
  • file type – (in STRS_Type) indicator whether file is text or binary.
Return a handle ID used to read or write data from or to the file (STRS_HandleID). Handle ID should be validated with STRS_ValidateHandleID to deteremine if successful.
Precondition None
Postcondition The file is open unless an error occurs. On error, the return value should contain an error indication that can be tested by STRS_ValidateHandleID.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_HandleID frd = 
    STRS_FileOpen(fromWF,filename,
STRS_ACCESS_READ,
STRS_TYPE_TEXT);
STRS_Result rtn = STRS_ValidateHandleID(frd);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "FileOpen fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "FileOpen fails.", nb);
}


Go to top,
Skip to (prev) STRS-74, Skip to (next) STRS-76

7.75   STRS-75 STRS_FileRemove
Requirement The STRS infrastructure shall contain a callable STRS_FileRemove method as described in table 56, STRS_FileRemove().
Table 56
STRS_FileRemove()
Description Remove the closed file.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • oldName – (in char *) name of file to be removed.
Return status (STRS_Result)
Precondition None
Postcondition The file is no longer available, and the space where it was stored becomes available.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case Waveform Remove
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = 
    STRS_FileRemove(fromWF,oldName);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "FileRemove fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "FileRemove fails.", nb);
}


Go to top,
Skip to (prev) STRS-75, Skip to (next) STRS-77

7.76   STRS-76 STRS_FileRename
Requirement The STRS infrastructure shall contain a callable STRS_FileRename method as described in table 57, STRS_FileRename().
Table 57
STRS_FileRename()
Description Rename the closed file where the new file name does not exist prior to the call.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • oldName – (in char *) current name of file.
  • newName – (in char *) new name of file after rename.
Return status (STRS_Result)
Precondition None
Postcondition The contents of the old file are now associated with the new file name.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = 
    STRS_FileRename(fromWF,oldName,newName);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "FileRename fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE,
       "FileRename fails.", nb);
}


Go to top,
Skip to (prev) STRS-76, Skip to (next) STRS-78

7.77   STRS-77 Use Messaging API
Requirement The STRS applications shall use the STRS Infrastructure Messaging, STRS Infrastructure Data Source, and STRS Infrastructure Data Sink methods to establish queues to send messages between components.
Rationale In an SDR executing multiple threads or processes, messages have to be processed using message passing methods so that they do not interfere with each other. One example might be a receive application queuing its data for a subsequent transmit application. Another example might be the queuing of error messages from STRS_Log.
Category Portability, Adaptability
Traced-from 4.5, 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes The STRS Infrastructure Messaging methods refer to the API defined in STRS-77, STRS-80, STRS-81 and STRS-126 through STRS-129 as well as corresponding tables 58 through 63.
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example None


Go to top,
Skip to (prev) STRS-77, Skip to (next) STRS-79

7.78   STRS-78 STRS_QueueCreate (Deleted)
Rationale This requirement was replaced by two: STRS-128, STRS_PubSubCreate and STRS-126, STRS_MessageQueueCreate, with similar functionality but having different calling sequences to avoid confusion.


Go to top,
Skip to (prev) STRS-78, Skip to (next) STRS-80

7.79   STRS-79 STRS_QueueDelete (Deleted)
Rationale This requirement was replaced by two: STRS-129, STRS_PubSubDelete and STRS-119, STRS_MessageQueueDelete, with similar functionality but having different calling sequences to avoid confusion.


Go to top,
Skip to (prev) STRS-79, Skip to (next) STRS-81

7.80   STRS-80 STRS_Register
Requirement The STRS infrastructure shall contain a callable STRS_Register method as described in table 62, STRS_Register().
Table 62
STRS_Register()
Description Register an association between a publisher and subscriber where both exist. Disallow duplicates between the same publisher and subscriber.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • useQID – (in STRS_HandleID) handle ID of Pub/Sub that will be used as a sink; the publisher.
  • actQID – (in STRS_HandleID) handle ID of Pub/Sub, file, device, or target component that should respond to the request as a sink; the subscriber.
Return status (STRS_Result)
Precondition None
Postcondition Association between publisher and subscriber is registered, if allowed.
Applicable to OE developer: usually platform provider
Rationale The publish-subscribe design pattern provided a way for the publisher of a message to send the message to all subscribers without knowing the details. For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = STRS_Register(fromWF,psX,qFC);
if (! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "Can't register subscriber.");
    STRS_Log(fromWF,STRS_ERROR_QUEUE,
       "Can't register subscriber.", nb);
}


Go to top,
Skip to (prev) STRS-80, Skip to (next) STRS-82

7.81   STRS-81 STRS_Unregister
Requirement The STRS infrastructure shall contain a callable STRS_Unregister method as described in table 63, STRS_Unregister().
Table 63
STRS_Unregister()
Description Remove an association between a publisher and subscriber, if the association exists.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • useQID – (in STRS_HandleID) handle ID of Pub/Sub that was used as a sink; the publisher.
  • actQID – (in STRS_HandleID) handle ID of Pub/Sub, file, device, or target component that should no longer respond to the request as a sink; usually the subscriber.
Return status (STRS_Result)
Precondition None
Postcondition Association between publisher and subscriber is removed.
Applicable to OE developer: usually platform provider
Rationale The publish-subscribe design pattern provides a way for the publisher of a message to send the message to all subscribers without knowing the details. For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
// After unregistering, upon STRS_Write to psX, 
// the message does not get sent to qFC.
STRS_Result rtn = STRS_Unregister(fromWF,psX,qFC);
if (! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "Can't unregister subscriber.");
    STRS_Log(fromWF,STRS_ERROR_QUEUE,
       "Can't unregister subscriber.", nb);
}


Go to top,
Skip to (prev) STRS-81, Skip to (next) STRS-83

7.82   STRS-82 Use Time Control API
Requirement Any portion of the STRS Applications on the GPP needing time control shall use the STRS Infrastructure Time Control methods to access the hardware and software timers.
Rationale For portability of waveform applications, a standard API for using timers in the GPP was necessary. The timers are expected to be used for relatively low accuracy timing such as time stamps, timed events, and time constraints. As the speed of new GPPs increases over time, the timers are expected to be used for signal processing.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes The STRS Infrastructure Time Control methods refer to the API defined in STRS-82 through STRS-88, STRS-130 through STRS-133 and corresponding tables 64 through 73 in NASA-STD-4009A.
Verification Method Inspection
See Also N/A
Example None


Go to top,
Skip to (prev) STRS-82, Skip to (next) STRS-84

7.83   STRS-83 STRS_GetNanoseconds
Requirement The STRS infrastructure shall contain a callable STRS_GetNanoseconds method as described in table 65, STRS_GetNanoseconds().
Table 65
STRS_GetNanoseconds()
Description Get the number of nanoseconds from the STRS_TimeWarp object.
Parameters
  • twObj – (in STRS_TimeWarp) the STRS_TimeWarp object from which the nanoseconds portion of the time increment is extracted.
Return Integer number of nanoseconds in the STRS_TimeWarp object representing a time interval. (STRS_Nanoseconds)
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_GetSeconds, STRS_GetTime, STRS_GetTimeWarp
Example 
STRS_TimeWarp base, timx;
STRS_Nanoseconds nsec;
STRS_Result rtn;
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Clock_Kind kx = 1;
rtn = STRS_GetTime(fromWF,toDev,*base,kx,*timx);
nsec = STRS_GetNanoseconds(base);


Go to top,
Skip to (prev) STRS-83, Skip to (next) STRS-85

7.84   STRS-84 STRS_GetSeconds
Requirement The STRS infrastructure shall contain a callable STRS_GetSeconds method as described in table 66, STRS_GetSeconds().
Table 66
STRS_GetSeconds()
Description Get the number of seconds from the STRS_TimeWarp object.
Parameters
  • twObj – (in STRS_TimeWarp) the STRS_TimeWarp object from which the nanoseconds portion of the time increment is extracted.
Return integer number of seconds in the STRS_TimeWarp object representing a time interval. (STRS_Seconds)
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_GetNanoseconds, STRS_GetTime, STRS_GetTimeWarp
Example 
STRS_TimeWarp base,timx;
STRS_Seconds isec;
STRS_Result rtn;
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Clock_Kind kx = 1;
rtn = STRS_GetTime(fromWF,toDev,*base,kx,*timx);
isec = STRS_GetSeconds(base);


Go to top,
Skip to (prev) STRS-84, Skip to (next) STRS-86

7.85   STRS-85 STRS_GetTime
Requirement The STRS infrastructure shall contain a callable STRS_GetTime method as described in table 67, STRS_GetTime().
Table 67
STRS_GetTime()
Description Get the current base time and the corresponding time of a specified type (kind). The base clock/timer is usually a hardware timer. The variable kind is used to obtain a nonbase time at a specified offset from the base time. An offset is usually specified to ensure that the clock is monotonically increasing after a power reset or synchronized with another clock/timer. To compute the time interval between two nonbase times of different kinds, the function is called twice and the interval is modified by the difference between the two base times.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toDev – (in STRS_HandleID) handle ID of device that should respond to the request.
  • baseTime – (inout STRS_TimeWarp) current time of the base timer.
  • kind – (in STRS_Clock_Kind) type of clock/timer.
  • kindTime – (inout STRS_TimeWarp) current time of the specified timer.
Return status (STRS_Result)
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_SetTime
Example 
STRS_Result rtn;
STRS_HandleID fromWF = APP_GetHandleID();
STRS_HandleID refDev = STRS_HandleRequest(fromWF,
  "Name of Reference clock");
STRS_HandleID tgtDev = STRS_HandleRequest(fromWF,
  "Name of drifting clock");
STRS_HandleID defDev = STRS_HandleRequest(fromWF,
  STRS_DEFAULT_CLOCK_NAME);
STRS_Clock_Kind kRef = 1;
STRS_Clock_Kind kTgt = 1;
STRS_TimeWarp refbase, refkind, tgtbase, tgtkind;

rtn = STRS_GetTime(fromWF,refDev, refbase, kRef, refkind); 
rtn = STRS_GetTime(fromWF,tgtDev, tgtbase, kTgt, tgtkind); 
STRS_TimeWarp initial_difference = refkind - tgtkind;

while(TRUE)
{
    STRS_Sleep(fromWF, defDev, STRS_DEFAULT_CLOCK_KIND, POLL_INTERVAL, false);

    rtn = STRS_GetTime(fromWF, refDev, refbase, kRef, refkind);
    rtn = STRS_GetTime(fromWF, tgtDev, tgtbase, kTgt, tgtkind);
    STRS__TimeWarp drift = (refkind - tgtkind) -
      initial_difference;
    STRS_TimeAdjust tRate = drift * FEEDBACK_COEFFICIENT;

    rtn = STRS_SetTimeAdjust(fromWF, tgtDev, tRate);
}


Go to top,
Skip to (prev) STRS-85, Skip to (next) STRS-87

7.86   STRS-86 STRS_GetTimeWarp
Requirement The STRS infrastructure shall contain a callable STRS_GetTimeWarp method as described in table 69, STRS_GetTimeWarp().
Table 69
STRS_GetTimeWarp()
Description Get the STRS_TimeWarp object containing the number of seconds and nanoseconds in the time interval.
Parameters
  • isec – (in STRS_Seconds) number of seconds in the time interval
  • nsec – (in STRS_Nanoseconds) number of nanoseconds in the fractional portion of the time interval
Return STRS_TimeWarp object representing the time interval.
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_GetNanoseconds,STRS_GetSeconds, STRS_SetTime
Example 
STRS_TimeWarp delta;
STRS_Seconds     isec = 1; /* Leap second. */
STRS_Nanoseconds nsec = 0;
delta = STRS_GetTimeWarp(isec,nsec);


Go to top,
Skip to (prev) STRS-86, Skip to (next) STRS-88

7.87   STRS-87 STRS_SetTime
Requirement The STRS infrastructure shall contain a callable STRS_SetTime method as described in table 70, STRS_SetTime().
Table 70
STRS_SetTime()
Description Set the current time in the specified clock/timer by adjusting the time offset.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toDev – (in STRS_HandleID) handle ID of device that should respond to the request.
  • kind – (in STRS_Clock_Kind) type of clock/timer.
  • delta – (in STRS_TimeWarp) increment to add to specified clock/timer.
Return status (STRS_Result)
Precondition None
Postcondition Time is adjusted.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_GetTime, STRS_GetTimeWarp
Example 
STRS_TimeWarp delta;
STRS_Seconds isec = 1; /* Leap second */
STRS_Nanoseconds nsec = 0;
STRS_Result rtn;
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Clock_Kind k1 = 1;
delta = STRS_GetTimeWarp(isec,nsec);
rtn = STRS_SetTime(fromWF,toDev,k1,delta);


Go to top,
Skip to (prev) STRS-87, Skip to (next) STRS-89

7.88   STRS-88 STRS_TimeSynch
Requirement The STRS infrastructure shall contain a callable STRS_TimeSynch method as described in table 73, STRS_TimeSynch().
Table 73
STRS_TimeSynch()
Description Synchronize clocks. The action depends on whether the clocks to be synchronized are internal or external, or whether the clocks differ by amounts that exceed the maximum step size allowed.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • refDev – (in STRS_HandleID) handle ID of reference device containing the reference clock/timer.
  • ref – (in STRS_Clock_Kind) type of reference clock/timer.
  • targetDev – (in STRS_HandleID) handle ID of target device to synchronize.
  • target – (in STRS_Clock_Kind) type of clock/timer to synchronize with reference clock/timer.
  • stepMax – (in STRS_TimeWarp) maximum step size to allow at a time, which can be used for gradual time adjustment. Zero implies no limit in step size.
Return status (STRS_Result) where a positive value indicates the number of steps left to adjust at the maximum step size.
Precondition None
Postcondition Clocks are more synchronized.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
qref = STRS_HandleRequest(fromWF,"ReferenceClock");
iref = 0;
qtgt = STRS_HandleRequest(fromWF,"TargetClock");
itgt = 0;
// To use previous technique, step max is 
// defined as jump = 0.
STRS_TimeWarp jump = STRS_GetTimeWarp(0,0);
rtn = STRS_TimeSynch(fromWF,qref,iref,qtgt,itgt, jump);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
         "STRS_ Synch fails.");
    STRS_Log(fromWF, STRS_ERROR_QUEUE, 
         "STRS_ Synch fails.", nb);
}


Go to top,
Skip to (prev) STRS-88, Skip to (next) STRS-90

7.89   STRS-89 Provide STRS.h
Requirement The STRS platform provider shall provide an STRS.h file containing the STRS predefined data shown in table 74, STRS Predefined Data.
Table 74

STRS Predefined Data (Skip to Next)

Typedefs
Name Type Description
STRS_Access A number Used to indicate how reading and/or writing of a file or queue is done. See also constants STRS_ACCESS_APPEND, STRS_ACCESS_BOTH, STRS_ACCESS_READ, and STRS_ACCESS_WRITE.
STRS_Buffer_Size A number Used to represent a buffer size in bytes. The type of the number is to be long enough to contain the aximum number of bytes to reserve or to transfer with a read or write.
STRS_Clock_Kind A number Used to represent a kind of clock or timer. The type of the number is to be long enough to contain the maximum number of kinds of clocks and timers.
STRS_File_Size A number Used to represent a size in bytes. The type of the number is to be long enough to contain the number of bytes in GPP storage. Specific negative error values returned indicate an error.
STRS_HandleID A number Used to represent an STRS application, device, file, or queue. Specific error value(s) returned indicate an error.
STRS_int8

 A number Used for an 8-bit signed integer
STRS_int16

 A number Used for a 16-bit signed integer
STRS_int32

 A number Used for a 32-bit signed integer
STRS_int64

 A number Used for a 64-bit signed integer
STRS_ISR_Function A static C-style function pointer Used to define static C-style function pointers passed to the STRS_SetISR() method. The function passed to the STRS_SetISR() method is defined with any arguments needed by the OE for its underlying system calls. The OE-specific documentation contains the description of any arguments.
STRS_Message A char array pointer Used for messages.
STRS_Nanoseconds A number Used to hold the number of nanoseconds in the STRS_TimeWarp object, at least 32 bits for a signed integer. Using 32 bits would allow a maximum of 2,147,483,647 nanoseconds = 2.147483647 seconds that would allow the sum/difference of the nanosecond counter in 2 normalized STRS_TimeWarp objects. Each additional bit multiplies the 2.1475 seconds in the nanosecond counter by 2.
STRS_Property_Name   Used to hold a property name, usually a set of characters (int or char*).
STRS_Property_Value   Used to hold a property value, usually a set of characters (char).
STRS_Queue_Max_Messages A number Used to represent the maximum number of messages allowed in the queue.
STRS_Result A number Used to represent a return value, where there are specific values that indicate an error.
STRS_Seconds A number Used to hold the number of seconds in the STRS_TimeWarp object, at least 32 bit signed integer. Using 32 bits would allow a maximum of 2,147,483,647 seconds = 68.05 years. For an epoch of 1970, the 32-bit second counter runs out in 2038. Each additional bit multiplies the 68.05 years in the second counter by 2.
STRS_TestID A number Used to represent the built-in test or ground test to be performed by APP_RunTest or APP_GroundTest, respectively.
STRS_TimeWarp A representation of a time delay The representation of a time delay able to hold the number of seconds and nanoseconds in the time delay so that the corresponding macros can extract them. The time delay is meant to be used for recurrent processes such as in health management. The implementation is mission and/or platform specific and is most likely a struct. The maximum number of seconds in a time delay cannot be greater than 2(no. of bits in STRS_Seconds – 1) seconds. Divide the maximum number of seconds by 31557600 (60*60*24*365.25) to get the approximate number of years.
STRS_TimeRate A number Integer indicating time rate factor used to adjust time relative to clock accuracy defined by STRS_TIME_RATE_PPS.
STRS_Type A number Used to indicate whether a file is text or binary. See also constants STRS_TYPE_BINARY and STRS_TYPE_TEXT.
STRS_uint8

A number Used for an 8-bit unsigned integer
STRS_uint16

 A number Used for a 16-bit unsigned integer
STRS_uint32

 A number Used for a 32-bit unsigned integer
STRS_uint64

 A number Used for a 64-bit unsigned integer
Constants
Name Type Description
STRS_ACCESS_APPEND STRS_Access Indicates that writing is allowed such that previous data written are preserved and new data are written following any previous data. Corresponds to ISO C fopen mode “a”.
STRS_ACCESS_BOTH STRS_Access Indicates that both reading and writing are allowed. Corresponds to ISO C fopen mode “r+” used for update.
STRS_ACCESS_READ STRS_Access Indicates that reading is allowed. Corresponds to ISO C fopen mode “r”.
STRS_ACCESS_WRITE STRS_Access Indicates that writing is allowed. Corresponds to ISO C fopen mode “w”.
STRS_OK STRS_Result Indicates that the STRS_Result is valid. See also STRS_IsOK().
STRS_ERROR STRS_Result Indicates that the STRS_Result is invalid. Specific value indicating an error such that the application or other component is still usable. See also STRS_IsOK() and STRS_GetErrorQueue().
STRS_ERROR_QUEUE STRS_HandleID Indicates that the log queue is for error messages. See also STRS_GetErrorQueue().
STRS_FATAL STRS_Result Indicates that the STRS_Result is invalid. Specific value indicating a serious error such that the application or other component is not usable. See also STRS_IsOK() and STRS_GetErrorQueue().
STRS_FATAL_QUEUE STRS_HandleID Indicates that the log queue is for fatal messages. The fatal queue is used for messages that the fault monitoring and recovery functions are to deal with immediately. The messages are sent to the Flight Computer for further handling. See also STRS_GetErrorQueue().
STRS_TELEMETRY_QUEUE STRS_HandleID Indicates that the log queue is for telemetry data.
STRS_TYPE_BINARY STRS_Type Indicates that a file is a binary file.
STRS_TYPE_TEXT STRS_Type Indicates that a file is a text file.
STRS_WARNING STRS_Result Indicates that the STRS_Result is invalid. Specific value indicating an error such that there may be little or no effect on the operation of the application or other component. See also STRS_IsOK() and STRS_GetErrorQueue().
STRS_WARNING_QUEUE STRS_HandleID Indicates that the log queue is for warning messages. See also STRS_GetErrorQueue().
STRS_OE_HANDLE_NAME char * A handle name used to find handle ID that may be used to query the OE.
STRS_DEFAULT_CLOCK_NAME char * The handle name used to find handle ID that may be used to access time using STRS_GetTime used in a timestamp.
STRS_DEFAULT_CLOCK_KIND STRS_Clock_Kind The number used to indicate the type of clock/timer used in a timestamp.
STRS_TIME_RATE_PPS STRS_TimeRate Integer accuracy of time rate in number of parts per second.
STRS_MAX_PROPERTY_NAME_SIZE #define The maximum number of characters in the name in a Property object, not including the final ‘\0’. Any use of this as a dimension should be increased by one.
STRS_MAX_PROPERTY_VALUE_SIZE #define The maximum number of characters in the value in a Property object, not including the final ‘\0’. Any use of this as a dimension should be increased by one.
STRS_MAX_PATH_NAME_SIZE #define The maximum number of characters in a path name for the OE, not including the final ‘\0’. Any use of this as a dimension should be increased by one.
STRS_MAX_HANDLE_NAME_SIZE #define The maximum number of characters in a handle name for the OE, not including the final ‘\0’. Any use of this as a dimension should be increased by one.
STRS_MAX_LOG_MESSAGE_SIZE #define The maximum number of characters in each message submitted to the log, not including the final ‘\0’. Any use of this as a dimension should be increased by one.
STRS_MAX_QUEUE_MESSAGES STRS_Queue_Max_Messages The maximum number of messages that can be stored in a queue. Not normally used except for testing.
Rationale For portability, standard names are defined for various constants and data types.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using OE script and using STRS compliance tool.
See Also N/A


Go to top,
Skip to (prev) STRS-89, Skip to (next) STRS-91

7.90   STRS-90 Provide POSIX®
Requirement The STRS OE shall provide the interfaces described in POSIX® IEEE Standard 1003.13 profile PSE51.
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. Rather than creating many more APIs in STRS, the currently available POSIX® standard was selected. Thus POSIX® subsets were chosen to implement certain OS services missing from the list of STRS Application-provided methods. The POSIX® subsets are widely available, are implemented by multiple OSs, and are scalable. Layering of the architecture separates and encapsulates functionality so that the parts are less influenced by changes to the other. This separation of functionality promotes portability.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection
See Also N/A


Go to top,
Skip to (prev) STRS-90, Skip to (next) STRS-92

7.91   STRS-91 Use POSIX®
Requirement STRS applications shall use POSIX® methods except for the unsafe functions listed in Table 77, Replacements for Unsafe Functions.
Table 77
Replacements for Unsafe Functions
Unsafe Function Reentrant Counterpart
Do Not Use! OK to Use
abort STRS_AbortApp
asctime asctime_r
atexit –
ctermid ctermid_r
ctime ctime_r
exit STRS_AbortApp
getlogin getlogin_r
gmtime gmtime_r
localtime localtime_r
rand rand_r
readdir readdir_r
strtok strtok_r
tmpnam tmpnam_r
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. Rather than creating many more APIs in STRS, the currently available POSIX® standard was selected. Thus POSIX® subsets were chosen to implement certain OS services missing from the list of STRS Application-provided methods. The POSIX® subsets are widely available, are implemented by multiple OSs, and are scalable. Layering of the architecture separates and encapsulates functionality so that the parts are less influenced by changes to the other. This separation of functionality promotes portability.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.7, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A


Go to top,
Skip to (prev) STRS-91, Skip to (next) STRS-93

7.92   STRS-92 Document HAL
Requirement The STRS platform provider shall provide STRS platform HAL documentation that includes the following:

  1. For each method or function, its calling sequence, return values, an explanation of its functionality, any preconditions for using the method or function, and the postconditions after using the method or function.
  2. Information required to address the underlying hardware, including interrupt input and output, memory mapping, and the configuration data necessary to operate in the STRS platform environment.
Rationale

The HAL API is to be published so that specialized hardware made by one company may be integrated with the STRS infrastructure made by a different company.

The HAL API documentation is to include a description of each method or function used, including its calling sequence, return values, an explanation of its functionality, any preconditions before using the method/function, and the status after using the method or function.

The HAL API documentation is to also contain information about the underlying hardware such as address and data interfaces, interrupt input and output, power connections, plus other control and data lines necessary to operate in the STRS platform environment.

Category Reconfigurability, Adaptability, Extensibility
Traced-from 4.4, 4.5, 4.7, 4.8, 5.1, 5.2
Use Case None
Applicable to Platform
Notes None
Verification Method Inspection of HAL document.
See Also STRS-11
Example
HAL API RESULT OPEN(HANDLE* resourceHandle, RESOURCE_NAME resourceName)
Description Open a resource by name. If no errors are encountered, use the resourceHandle to access the resource.
Parameters
  • resourceHandle – [out] A pointer to place the opened handle into
  • resourceName – [in] The name of the resource to open
Return A 32-bit signed integer used to determine whether an error has occurred. Use TEST_ERROR to obtain a printable message.

  • Zero – No errors or warnings.
  • Positive – Warning.
  • Negative – Error.
Precondition Resource is not open before executing this command.
Postcondition Resource will be open and ready for further access if no error was encountered.
See Also READ, WRITE, CLOSE, TEST_ERROR
Example 
#include <HALResources.h>
 ...
RESULT result;
HANDLE resourceHandle;
RESOURCE_NAME resourceName = "FPGA";
result = OPEN(&resourceHandle, resourceName)
if (result < 0) {
   cout << "Error: " << TEST_ERROR(result) << endl;
} else if (result > 0) {
   cout << "Warning: " << TEST_ERROR(result) << endl;
}


Go to top,
Skip to (prev) STRS-92, Skip to (next) STRS-94

7.93   STRS-93 OE Uses HAL (Deleted)
Rationale This requirement was deleted because it was the same as STRS-11. STRS-11 stated the same thing, with only a few words different, so STRS-93 was redundant. STRS-93 previously stated: The STRS infrastructure shall use the HAL APIs to communicate with the specialized hardware via the physical interface defined by the STRS platform provider.


Go to top,
Skip to (prev) STRS-93, Skip to (next) STRS-95

7.94   STRS-94 External Commands
Requirement An STRS platform shall accept, validate, and respond to external commands.
Rationale To adapt to changing circumstances, an STRS radio has to accept external commands from a ground station, another satellite, or another system on the same satellite. The external commands have to be validated as required by the mission. There has to be a way to determine whether or not the command worked and, for some commands, the resulting values.
Category Adaptability
Traced-from 4.5, 5.4, 5.15
Use Case Waveform Upload, STRS OE Upload, Waveform Instantiation, Waveform Start, Processor Resource Sharing with Flight Computer, Set Waveform Parameter, Get Waveform Parameter, Transmit a Packet, Receive a Packet, Waveform Stop, Waveform Deallocation, Waveform Abort, Waveform Remove, Built-In-Test
Applicable to OE developer: usually platform provider
Notes None
Verification Method Observation of radio operation.
See Also N/A


Go to top,
Skip to (prev) STRS-94, Skip to (next) STRS-96

7.95   STRS-95 Use STRS APIs
Requirement An STRS platform shall execute external application control commands using the standardized STRS APIs.
Rationale To promote portability and adaptability, the use of the standard STRS APIs is required. One waveform should be able to control another waveform or device in a portable manner.
Category Portability, Adaptability
Traced-from 4.1, 4.2, 4.3, 4.5, 4.9, 5.1, 5.2, 5.4, 5.6, 5.7
Use Case Waveform Upload, STRS OE Upload, Waveform Instantiation, Waveform Start, Processor Resource Sharing with Flight Computer, Set Waveform Parameter, Get Waveform Parameter, Transmit a Packet, Receive a Packet, Waveform Stop, Waveform Deallocation, Waveform Abort, Waveform Remove, Built-In Test
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A


Go to top,
Skip to (prev) STRS-95, Skip to (next) STRS-97

7.96   STRS-96 Use STRS_Query
Requirement The STRS infrastructure shall use the STRS_Query method to service external system requests for information from an STRS application.
Rationale The only way to request information from an application is by means of data values returned when an application method is invoked. The STRS_Query/APP_Query methods are designed for this purpose. Although STRS_RunTest/APP_RunTest could be used to request data values, they are designed for testing.
Category Adaptability, Extensibility
Traced-from 4.4, 4.5, 5.1, 5.2
Use Case Get Waveform Parameter
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection
See Also N/A


Go to top,
Skip to (prev) STRS-96, Skip to (next) STRS-98

7.97   STRS-97 Use STRS_Log (Deleted)
Rationale This requirement was deleted because it was the same as STRS-57. STRS-97 previously stated: An STRS application shall use the STRS_Log and STRS_Write methods to send STRS telemetry set information to the external system. STRS-97 was less clear than STRS-57 because STRS-97 involved the external interface, not just the application to infrastructure call. Also, in some implementations, the application telemetry may not be sent directly to the external interface but may be sent to a file from which the telemetry may be downloaded as necessary.


Go to top,
Skip to (prev) STRS-97, Skip to (next) STRS-99

7.98   STRS-98 Document Platform for XML (Project Option)
Requirement (Optional, OE-specific) The STRS platform provider shall document the necessary platform information (including a sample file) to develop a predeployed application configuration file in XML 1.0.
Rationale When functions, interfaces, components, and/or design rules are defined and published, the architecture is open. Open architectures facilitate interoperability among commercial and government developers and minimize the operational impact of upgrading hardware and software components. Leveraging the existing XML standard may reduce NASA’s costs and risks by increasing reliability.
Category Reconfigurability, Adaptability, Extensibility
Traced-from 4.2, 4.4, 4.5, 4.7, 5.2, 5.4
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection of document and sample file.
See Also N/A


Go to top,
Skip to (prev) STRS-98, Skip to (next) STRS-100

7.99   STRS-99 Document WF for XML (Deleted)
Rationale This requirement was deleted because it is redundant. This requirement is replaced by STRS-12 (3). STRS-99 previously stated: The STRS application developer shall document the necessary application information to develop a predeployed application configuration file in XML 1.0.


Go to top,
Skip to (prev) STRS-99, Skip to (next) STRS-101

7.100   STRS-100 Provide XML File (Project Option)
Requirement (Optional, OE-specific) The STRS integrator shall provide a predeployed application configuration file in XML 1.0.
Rationale A waveform (STRS application) configuration file contains specific information that (1) allows STRS to instantiate the application; (2) provides default configuration values; and (3) provides connection references to ports and services needed by the application. The format of the configuration files has to be defined in XML using an XML schema. The XML should be preprocessed to optimize space in the STRS radio memory while keeping the equivalent content. Examples include platform configuration files, STRS infrastructure configuration files as a XML schema, and waveform configuration files that contain specific information that allows STRS to instantiate the application, provide default configuration values, and provide connection references to ports and services needed by the application. Leveraging the existing XML standard may reduce NASA’s costs and risks by increasing reliability.
Category Reconfigurability
Traced-from 4.7, 5.3, 5.4
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using XMLSpy.
See Also N/A


Go to top,
Skip to (prev) STRS-100, Skip to (next) STRS-102

7.101   STRS-101 XML Content (Project Option)
Requirement (Optional, OE-specific) The predeployed STRS application configuration file shall identify the following application attributes and default values:

  1. Identification.
    1. Class name.
  2. State after processing the configuration file or equivalent.
  3. Any resources to be loaded separately.
    1. Filename of loadable image.
    2. Target on which to put loadable image file.
    3. Target memory in bytes, number of gates, or logic elements.
  4. Initial or default values for all distinct operationally configurable parameters.
Rationale A waveform (STRS application) configuration file contains specific information that (1) allows STRS to instantiate the application; (2) provides default configuration values; and (3) provides connection references to ports and services needed by the application. The format of the configuration files has to be defined in XML using an XML schema. The XML should be preprocessed to optimize space in the STRS radio memory while keeping the equivalent content. Examples include platform configuration files, STRS infrastructure configuration files as a XML schema, and waveform configuration files that contain specific information that allows STRS to instantiate the application, provide default configuration values, and provide connection references to ports and services needed by the application.
Category Reconfigurability
Traced-from 5.4
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection of delivered files and documentation.
See Also N/A


Go to top,
Skip to (prev) STRS-101, Skip to (next) STRS-103

7.102   STRS-102 Provide XML Schema (Project Option)
Requirement (Optional, OE-specific) The STRS platform provider shall provide an XML 1.0 schema definition (XSD) file to validate the format and data for predeployed STRS application configuration files, including the order of the tags, the number of occurrences of each tag, and the values or attributes.
Rationale A waveform (STRS application) configuration file contains specific information that (1) allows STRS to instantiate the application; (2) provides default configuration values; and (3) provides connection references to ports and services needed by the application. The format of the configuration files has to be defined in XML using an XML schema. Since the term XML schema was variously interpreted to mean either a description or a file, the requirement was clarified to specify that an XML schema definition (XSD) file is required. The XML should be preprocessed to optimize space in the STRS radio memory while keeping the equivalent content. Examples include platform configuration files, STRS infrastructure configuration files as a XML schema, and waveform configuration files that contain specific information that allows STRS to instantiate the application, provide default configuration values, and provide connection references to ports and services needed by the application. Leveraging the existing XML standard may reduce NASA’s costs and risks by increasing reliability.
Category Reliability
Traced-from 4.3, 4.7, 5.3, 5.4
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using XMLSpy.
See Also N/A


Go to top,
Skip to (prev) STRS-102, Skip to (next) STRS-104

7.103   STRS-103 Provide XML Transformation Tool (Project Option)
Requirement (Optional, OE-specific) The STRS platform provider shall document the transformation (if any) from a predeployed application configuration file in XML into a deployed application configuration file and provide the tools to perform such transformation.
Rationale A waveform (STRS application) configuration file contains specific information that (1) allows STRS to instantiate the application; (2) provides default configuration values; and (3) provides connection references to ports and services needed by the application. The format of the configuration files has to be defined in XML using an XML schema. The XML should be preprocessed to optimize space in the STRS radio memory while keeping the equivalent content. Examples include platform configuration files, STRS infrastructure configuration files as an XML schema, and waveform configuration files that contain specific information that allows STRS to instantiate the application, provide default configuration values, and provide connection references to ports and services needed by the application.
Category Reconfigurability, Adaptability, Extensibility
Traced-from 4.4, 4.5, 5.2, 5.3, 5.4
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection of document and tools.
See Also N/A


Go to top,
Skip to (prev) STRS-103, Skip to (next) STRS-105

7.104   STRS-104 Provide XML Transformed (Project Option)
Requirement (Optional, OE-specific) The STRS integrator shall provide a deployed STRS application configuration file for the STRS infrastructure to place the STRS application in the specified state.
Rationale A waveform (STRS application) configuration file contains specific information that (1) allows STRS to instantiate the application; (2) provides default configuration values; and (3) provides connection references to ports and services needed by the application. The format of the configuration files has to be defined in XML using an XML schema. The XML should be preprocessed to optimize space in the STRS radio memory while keeping the equivalent content. Examples include platform configuration files, STRS infrastructure configuration files as an XML schema, and waveform configuration files that contain specific information that allows STRS to instantiate the application, provide default configuration values, and provide connection references to ports and services needed by the application.
Category Reconfigurability
Traced-from 5.4
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection of delivered files and documentation.
See Also N/A


Go to top,
Skip to (prev) STRS-104, Skip to (next) STRS-106

7.105   STRS-105 OE Provides API in C
Requirement The STRS infrastructure APIs shall have an ISO/IEC C language compatible interface.
Rationale Because portability is a basic goal but middleware is not required, a totally language-independent solution was not available. The lowest common denominator turns out to be a C language interface. Using a standard ISO/IEC 9899 C or ISO/IEC 14882 C++ aids portability. The year is not included in the requirement, so that obsolete compilers are not mandated.
Category Portability
Traced-from 4.1, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A


Go to top,
Skip to (prev) STRS-105, Skip to (next) STRS-107

7.106   STRS-106 Use STRS.h
Requirement An STRS application shall use the appropriate constant, typedef, or struct defined in Table 74, STRS Predefined Data, when the data are used to interact with the STRS APIs.
Rationale For portability, standard names are defined for various constants and data types.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection
See Also N/A


Go to top,
Skip to (prev) STRS-106, Skip to (next) STRS-108

7.107   STRS-107 Document External Commands
Requirement An STRS platform provider shall document the external commands describing their format, function, and any STRS methods invoked.
Rationale To adapt to changing circumstances, an STRS radio has to accept external commands from a ground station, another satellite, or another system on the same satellite. The external commands have to be validated as required by the mission. There has to be a way to determine whether the command worked and, for some commands, the resulting values. To promote portability and adaptability, the use of the standard STRS APIs is required.
Category Adaptability
Traced-from 4.5, 5.1, 5.4, 5.5, 5.6, 5.7, 5.15
Use Case Waveform Upload, STRS OE Upload, Waveform Instantiation, Waveform Start, Processor Resource Sharing with Flight Computer, Set Waveform Parameter, Get Waveform Parameter, Transmit a Packet, Receive a Packet, Waveform Stop, Waveform Deallocation, Waveform Abort, Waveform Remove, Built-In-Test
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection of documentation.
See Also N/A


Go to top,
Skip to (prev) STRS-107, Skip to (next) STRS-109

7.108   STRS-108 Document Thermal and Power Limits
Requirement The STRS platform provider shall describe, in the HID document, the thermal and power limits of the hardware at the smallest modular level to which power is controlled.
Rationale The power consumption and resulting heat generation of a reprogrammable FPGA will vary according to the amount of logic used and the clock frequency(s). The power consumption may not be constant for each possible waveform that can be loaded on the platform. The STRS platform provider should document the maximum allowable power available and thermal dissipation of the FPGA(s) on the basis of the maximum allowable thermal constraints of FPGA(s) of the platform. For human spaceflight environments, touch temperature requirements may limit dissipation further; therefore, these reductions are to be factored into the given dissipation limits.
Category Reliability, Adaptability
Traced-from 4.3, 4.7, 5.9, 5.10, 5.15, 5.16
Use Case None
Applicable to Platform provider
Notes None
Verification Method Inspection of HID document.
See Also STRS-9


Go to top,
Skip to (prev) STRS-108, Skip to (next) STRS-110

7.109   STRS-109 Provide General-Purpose Processing Module
Requirement An STRS platform shall have a GPM that contains and executes the STRS OE and the control portions of the STRS applications and services software.
Rationale The GPM contains and executes the STRS OE, including POSIX®, STRS interface code, and configuration file parsing, to support the corresponding requirements. A layered hardware architecture augments the layered software architecture by providing the ability to change portions without affecting other portions to support extensibility, adaptability, and portability.
Category Portability, Adaptability
Traced-from 4.3, 4.4, 4.5, 4.6, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Platform provider
Notes None
Verification Method Inspection
See Also N/A


Go to top,
Skip to (prev) STRS-109, Skip to (next) STRS-111

7.110   STRS-110 Provide STRS_APIs.h
Requirement The STRS platform provider shall provide an “STRS_APIs.h” that contains the method prototypes for the infrastructure APIs.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection
See Also N/A


Go to top,
Skip to (prev) STRS-110, Skip to (next) STRS-112

7.111   STRS-111 Include STRS_DeviceControl.h
Requirement Each STRS Device shall contain:
#include “STRS_DeviceControl.h”.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A


Go to top,
Skip to (prev) STRS-111, Skip to (next) STRS-113

7.112   STRS-112 Provide STRS_DeviceControl.h
Requirement The STRS platform provider shall provide an “STRS_DeviceControl.h” that contains the method prototypes for each STRS Device and, for C++, the class definition for the base class STRS_DeviceControl, which inherits from the base class STRS_ApplicationControl.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection
See Also N/A
Example None


Go to top,
Skip to (prev) STRS-112, Skip to (next) STRS-114

7.113   STRS-113 STRS_DeviceControl Base Class
Requirement If the STRS Device-provided Device Control API is implemented in C++, the STRS Device class shall be derived from the STRS_DeviceControl base class.
Rationale For portability, standard names are defined for various constants, data types, and method prototypes in the API.
Category Portability
Traced-from 4.9, 5.1, 5.2
Use Case None
Applicable to Device
Notes None
Verification Method Inspection
See Also N/A
Example 
For example, the MyDevice.h file should contain a class definition of the form:
class MyDevice: public STRS_DeviceControl
             [, public STRS_Source]
             [, public STRS_Sink]
   {...};
   Note: [] indicates optional.


Go to top,
Skip to (prev) STRS-113, Skip to (next) STRS-115

7.114   STRS-114 APP_Destroy
Requirement Each STRS application shall contain a callable APP_Destroy method as described in table 6, APP_Destroy().
Table 6
APP_Destroy()
Description Call the destructor for the specified target component. APP_Destroy is not a class method.
Parameters
  • pApp – (in STRS_Instance *) pointer to application instance.
Return None
Precondition Application must be stopped and resources released.
Postcondition STRS instance object is no longer valid.
Applicable to Application developer
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection using STRS compliance tool.
See Also APP_Instance
Example (C) 
// Not a class method
// Called in OE as:
ClassName_APP_Destroy(thisPtr);

// Implemented in application as:
void ClassName_APP_Destroy(
         STRS_Instance *thisPtr) 
{   
   free thisPtr;  // Non-standard
}
Example (C++) 
// Not a class method
void ClassName::APP_ Destroy (
STRS_Instance *Obj)
{
    delete static_cast<ClassName *>(Obj);
}


Go to top,
Skip to (prev) STRS-114, Skip to (next) STRS-116

7.115   STRS-115 APP_GetHandleID
Requirement The STRS infrastructure shall define a callable APP_GetHandleID method in each application as described in table 7, APP_GetHandleID().
Table 7
APP_GetHandleID()
Description Obtain the handle ID for the application, stored by the OE.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
Return handle ID of the current application (STRS_HandleID)
Precondition Application is instantiated.
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
if ( ! STRS_IsOK(rtn)) {
    int nb = sprint(buffer, 
            "I found the error in %s at %s:%d\0",
            APP_GetHandleName(), __FILE__, __LINE__ );
    STRS_Log(APP_GetHandleID(), STRS_GetErrorQueue(rtn), buffer, nb);
    return rtn;
}


Go to top,
Skip to (prev) STRS-115, Skip to (next) STRS-117

7.116   STRS-116 APP_GetHandleName
Requirement The STRS infrastructure shall define a callable APP_GetHandleName method in each application as described in table 8, APP_GetHandleName().
Table 8
APP_GetHandleName()
Description Obtain the handle name for the application, stored by the OE.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
Return handle name of the current application (char *)
Precondition Application is instantiated.
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
if ( ! STRS_IsOK(rtn)) _
    int nb = sprint(buffer, 
            "I found the error in %s at %s:%d\0",
            APP_GetHandleName(), __FILE__, __LINE__ );
    STRS_Log(APP_GetHandleID(), STRS_GetErrorQueue(rtn), buffer, nb);
    return rtn;
}


Go to top,
Skip to (prev) STRS-116, Skip to (next) STRS-118

7.117   STRS-117 STRS_GetHandleName
Requirement The STRS infrastructure shall contain a callable STRS_GetHandleName method as described in table 29, STRS_GetHandleName().
Table 29
STRS_GetHandleName()
Description The handle name is obtained for the given handle ID. The handle ID of the current component (fromWF) is used for any error message. Using STRS_GetHandleName to determine the handle name of the current component while it is being instantiated gives undefined results.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toID – (in STRS_HandleID) handle ID of the resource (application, device, file, queue) for which the handle name is to be obtained.
  • toResourceName – (out char *) handle name of the desired resource.
Return status (STRS_Result)
Precondition Space must be allocated for handle name.
Postcondition Handle name is filled in. On error, the first character of the handle name is filled with a zero unless the toResourceName variable is NULL.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_HandleRequest
Example 
char toResourceName[STRS_HANDLE_NAME_MAX_LENGTH+1];
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = STRS_GetHandleName(fromWF,
   toID,
   toResourceName);
If ( ! STRS_IsOK(rtn)) {
   STRS_HandleID errQ = 
      STRS_GetErrorQueue(rtn);
   STRS_Buffer_Size nb = strlen(
      "Did not find handle name.");
   STRS_Log(fromWF,errQ,
      "Did not find handle name.", nb);
} else {
   std::cout << "Found Handle name " 
             << toResourceName << " for ID "
             << toID << std::endl;
}


Go to top,
Skip to (prev) STRS-117, Skip to (next) STRS-119

7.118   STRS-118 STRS_ValidateHandleID
Requirement The STRS infrastructure shall contain a callable STRS_ValidateHandleID method as described in table 34, STRS_ValidateHandleID ().
Table 34
STRS_ValidateHandleID()
Description Determines if a handle ID is STRS_OK or in error. After calling any STRS method that returns a handle ID, it is recommended that STRS_ValidateHandleID be called before any other STRS method.
Parameters
  • tstID – (in STRS_HandleID) the STRS_HandleID object from which the handle ID is extracted.
Return (STRS_Result) STRS_OK when successful; otherwise, for error, STRS_WARNING, STRS_ERROR, or STRS_FATAL.
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_HandleRequest, STRS_FileOpen, STRS_InstantiateApp, STRS_MessageQueueCreate, STRS_IsOK
Example 
STRS_HandleID tstID = 
   STRS_HandleRequest(fromID, otherWF);
STRS_Result  rtn = STRS_ValidateHandleID(tstID); 
If ( ! STRS_IsOK( rtn )) { 
   STRS_Message msg = "Handle ID error."; 
   STRS_HandleID errQ = STRS_GetErrorQueue(rtn); 
   STRS_Log (fromID, errQ, msg, (STRS_Buffer_Size) sizeof(msg)); 
} else {
   cout << "OK." << endl;
}


Go to top,
Skip to (prev) STRS-118, Skip to (next) STRS-120

7.119   STRS-119 STRS_ValidateSize
Requirement The STRS infrastructure shall contain a callable STRS_ValidateSize method as described in table 35, STRS_ValidateSize ().
Table 35
STRS_ValidateSize()
Description Determines if a STRS_File_Size is STRS_OK or in error. STRS_FileGetFreeSpace and STRS_FileGetSize return a type STRS_File_Size number. After calling any STRS method that returns an STRS_File_Size, it is recommended that STRS_ValidateSize be called before calling any other STRS method.
Parameters
  • tstSize – (in STRS_File_Size) the file size object from which the file size is extracted.
Return (STRS_Result) STRS_OK when successful; otherwise, for error, STRS_WARNING, STRS_ERROR, or STRS_FATAL.
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_FileGetFreeSpace, STRS_FileGetSize, STRS_IsOK
Example 
STRS_File_Size tstSize = 
   STRS_FileGetFreeSpace(fromID, NULL);
STRS_Result  rtn = STRS_ValidateSize(tstSize); 
If ( ! STRS_IsOK( rtn )) { 
   STRS_Message msg = "File size error."; 
   STRS_HandleID errQ = STRS_GetErrorQueue(rtn); 
   STRS_Log (fromID, errQ, msg, (STRS_Buffer_Size) sizeof(msg)); 
} else {
   cout << "OK." << endl;
}


Go to top,
Skip to (prev) STRS-119, Skip to (next) STRS-121

7.120   STRS-120 DEV_Close
Requirement If the hardware is to be loaded by the STRS Device, the STRS Device shall contain a callable DEV_Close method as described in table 45, DEV_Close().
Table 45
DEV_Close()
Description Close the open device.
Parameters inst – (in STRS_Instance *) instance pointer, only for C implementation.
Return status (STRS_Result)
Precondition None
Postcondition The device is closed.
Applicable to Device developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Device
Notes None
Verification Method Inspection using compliance tool.
See Also STRS_DeviceClose
Example 
STRS_Result DEV_Close() {
   STRS_Result rtn = STRS_OK;
   int ok = HAL_Close(myDev);
   if ( ! HAL_Successful(ok)) {
      STRS_HandleID fromWF = APP_GetHandleID();
      STRS_Buffer_Size nb = strlen(
         "DEV_Close fails.");
      STRS_Log(fromWF, STRS_ERROR_QUEUE,
         "DEV_Close fails.", nb);
      rtn = STRS_ERROR;
   }
   return rtn;
}


Go to top,
Skip to (prev) STRS-120, Skip to (next) STRS-122

7.121   STRS-121 DEV_Flush
Requirement If the hardware is to be flushed by the STRS Device, the STRS Device shall contain a callable DEV_Flush method as described in table 46, DEV_Flush().
Table 46
DEV_Flush()
Description Use the opened device to send any buffered data immediately to the underlying hardware and clear the buffers.
Parameters inst – (in STRS_Instance *) instance pointer, only for C implementation.
Return status (STRS_Result)
Precondition None
Postcondition The device’s buffered data is flushed.
Applicable to Device developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Device
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_DeviceFlush
Example 
STRS_Result DEV_Flush() {
   STRS_Result rtn = STRS_OK;
   int ok = HAL_Flush(myDev);
   if ( ! Hal_Successful(ok)){
      STRS_HandleID fromWF = APP_GetHandleID();
      STRS_Buffer_Size nb = strlen(
         "DEV_Flush fails.");
      STRS_Log(fromWF, STRS_ERROR_QUEUE,
         "DEV_Flush fails.", nb);
      rtn = STRS_ERROR;
   }
   return rtn;
}


Go to top,
Skip to (prev) STRS-121, Skip to (next) STRS-123

7.122   STRS-122 DEV_Load
Requirement If the hardware is to be loaded by the STRS Device, the STRS Device shall contain a callable DEV_Load method as described in table 47, DEV_Load().
Table 47
DEV_Load()
Description Load a binary image to the open device.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
  • filename – (in char *) storage area name or fully qualified file name of the binary image to load onto the hardware device.
Return status (STRS_Result)
Precondition None
Postcondition The binary image is stored in the target device.
Applicable to Device developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Device
Notes None
Verification Method Inspection using compliance tool.
See Also STRS_DeviceLoad
Example 
STRS_Result DEV_Load(char *filename ) {
   STRS_Result rtn = STRS_OK;
   int ok = HAL_Load(myDev,filename);
   if ( ! Hal_Successful(ok)){
      STRS_HandleID fromWF = APP_GetHandleID();
      STRS_Buffer_Size nb = strlen(
         "DEV_Load fails.");
      STRS_Log(fromWF, STRS_ERROR_QUEUE,
         "DEV_Load fails.", nb);
      rtn = STRS_ERROR;
   }
   return rtn;
}


Go to top,
Skip to (prev) STRS-122, Skip to (next) STRS-124

7.123   STRS-123 DEV_Open
Requirement If the hardware is to be loaded by the STRS Device, the STRS Device shall contain a callable DEV_Open method as described in table 48, DEV_Open().
Table 48
DEV_Open()
Description Open the device.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
Return status (STRS_Result)
Precondition None
Postcondition The device is opened.
Applicable to Device developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Device
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_DeviceOpen
Example 
STRS_Result DEV_Open() {
   STRS_Result rtn = STRS_OK;
   myDev = HAL_Open("/dev/fpga1", O_RDWR);
   if (myDev != NULL) {
      STRS_HandleID fromWF = APP_GetHandleID();
      STRS_Buffer_Size nb = strlen(
         "DEV_Open fails.");
      STRS_Log(fromWF, STRS_ERROR_QUEUE,
         "DEV_Open fails.", nb);
      rtn = STRS_ERROR;
   }
   return rtn;
}


Go to top,
Skip to (prev) STRS-123, Skip to (next) STRS-125

7.124   STRS-124 DEV_Reset
Requirement If the hardware is to be reset by the STRS Device, the STRS Device shall contain a callable DEV_Reset method as described in table 49, DEV_Reset().
Table 49
DEV_Reset()
Description Reinitialize the device, if possible. Reset is normally used after the corresponding device has been started and stopped, and before the device is started again to bring the hardware device to its power-on state.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
Return status (STRS_Result)
Precondition None
Postcondition The device is reset to an initial state.
Applicable to Device developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Device
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_DeviceReset
Example 
STRS_Result DEV_Reset() {
   STRS_Result rtn = STRS_OK;
   int ok = HAL_Reset(myDev);
   if ( ! Hal_Successful(ok)){
      STRS_HandleID fromWF =APP_GetHandleID();
      STRS_Buffer_Size nb = strlen(
         "DEV_Reset fails.");
      STRS_Log(fromWF, STRS_ERROR_QUEUE,
         "DEV_Reset fails.", nb);
      rtn = STRS_ERROR;
   }
Return rtn;
}


Go to top,
Skip to (prev) STRS-124, Skip to (next) STRS-126

7.125   STRS-125 DEV_Unload
Requirement If the hardware is to be loaded by the STRS Device, the STRS Device shall contain a callable DEV_Unload method as described in table 50, DEV_Unload().
Table 50
DEV_Unload()
Description Unload the open device.
Parameters
  • inst – (in STRS_Instance *) instance pointer, only for C implementation.
Return status (STRS_Result)
Precondition None
Postcondition The device is unloaded.
Applicable to Device developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case Waveform Deallocation
Applicable to Device
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_DeviceUnload
Example 
STRS_Result DEV_Unload() {
   STRS_Result rtn = STRS_OK;
   int ok = HAL_Unload(myDev);
   if ( ! Hal_Successful(ok)){
      STRS_HandleID fromWF =APP_GetHandleID();
      STRS_Buffer_Size nb = strlen(
         "DEV_Unload fails.");
      STRS_Log(fromWF, STRS_ERROR_QUEUE,
         "DEV_Unload fails.", nb);
      rtn = STRS_ERROR;
   }
   return rtn;
}


Go to top,
Skip to (prev) STRS-125, Skip to (next) STRS-127

7.126   STRS-126 STRS_MessageQueueCreate
Requirement The STRS infrastructure shall contain a callable STRS_MessageQueueCreate method as described in table 58, STRS_ MessageQueueCreate().
Table 58
STRS_MessageQueueCreate()
Description Create a FIFO message queue if a handle does not already exist having the given name
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • queueName – (in char *) unique name of the queue.
  • nb – (in STRS_Buffer_Size) maximum size of buffer containing messages.
  • nmax – (in STRS_Queue_Max_Messages) maximum number of messages in queue.
Return handle ID of queue or error status (STRS_HandleID)
Precondition None
Postcondition Queue is created unless an error occurs.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Buffer_Size nbmax = STRS_MAX_LOG_MESSAGE_SIZE+1;
STRS_Queue_Max_Messages nmsgmax = 20;
if (nmsgmax > STRS_MAX_QUEUE_MESSAGES)
    nmsgmax = STRS_MAX_QUEUE_MESSAGES;
STRS_HandleID qX = STRS_MessageQueueCreate(fromWF,
    "QX", nbmax, nmsgmax);
STRS_Result rtn = STRS_ValidateHandleID(qX);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "Can't create queue.");
    STRS_Log(fromWF,STRS_ERROR_QUEUE,
       "Can't create queue.", nb).
    return STRS_ERROR;
}


Go to top,
Skip to (prev) STRS-126, Skip to (next) STRS-128

7.127   STRS-127 STRS_MessageQueueDelete
Requirement The STRS infrastructure shall contain a callable STRS_MessageQueueDelete method as described in table 59, STRS_ MessageQueueDelete().
Table 59
STRS_MessageQueueDelete()
Description Delete a queue if it exists.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toQueue – (in STRS_HandleID) handle ID of queue to delete.
Return status (STRS_Result)
Precondition None
Postcondition Queue is deleted.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = STRS_QueueDelete(fromWF,qX);
if (! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "Can't delete queue.");
    STRS_Log(fromWF,STRS_ERROR_QUEUE,
       "Can't delete queue.", nb);
   return STRS_ERROR;
}


Go to top,
Skip to (prev) STRS-127, Skip to (next) STRS-129

7.128   STRS-128 STRS_PubSubCreate
Requirement The STRS infrastructure shall contain a callable STRS_PubSubCreate method as described in table 60, STRS_PubSubCreate().
Table 60
STRS_PubSubCreate()
Description Create a Pub/Sub handle ID that is a proxy used to receive and redistribute messages using STRS_Write unless the handle name already is used somewhere else.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • pubsubName – (in char *) unique name of the Pub/Sub.
Return handle ID of Pub/Sub or error status (STRS_HandleID)
Precondition None
Postcondition Pub/Sub is created unless an error occurs.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_Register
Example 
STRS_HandleID psX;
STRS_HandleID fromWF = APP_GetHandleID();
psX = STRS_PubSubCreate(fromWF, "PSX");
STRS_Result rtn = STRS_ValidateHandleID(psX);
if ( ! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "Can't create Pub/Sub.");
    STRS_Log(fromWF,STRS_ERROR_QUEUE,
       "Can't create Pub/Sub.", nb).
    return STRS_ERROR;
}


Go to top,
Skip to (prev) STRS-128, Skip to (next) STRS-130

7.129   STRS-129 STRS_PubSubDelete
Requirement The STRS infrastructure shall contain a callable STRS_PubSubDelete method as described in table 61, STRS_PubSubDelete().
Table 61
STRS_PubSubDelete()
Description Delete a Pub/Sub if it exists. Any association between a publisher and subscriber that references the Pub/Sub is removed.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toPubSub – (in STRS_HandleID) handle ID of Pub/Sub to delete.
Return status (STRS_Result)
Precondition None
Postcondition Specified Pub/Sub is deleted and any associations are removed.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also N/A
Example 
STRS_HandleID fromWF = APP_GetHandleID();
STRS_Result rtn = STRS_PubSubDelete(fromWF,psX);
if (! STRS_IsOK(rtn)) {
    STRS_Buffer_Size nb = strlen(
       "Can't delete Pub/Sub.");
    STRS_Log(fromWF,STRS_ERROR_QUEUE,
       "Can't delete Pub/Sub.", nb);
}


Go to top,
Skip to (prev) STRS-129, Skip to (next) STRS-131

7.130   STRS-130 Document STRS Clock/Timer
Requirement The implementer of an STRS clock/timer software component for use with STRS_GetTime shall document it to include handle name, kind, epoch, resolution, use of leap seconds, and whether it should match a time somewhere else, as further described in table 64, Document STRS Clock/Timer.
Table 64
Document STRS Clock/Timer
Applicable to STRS clock/timer developer, which may be platform provider or application developer.
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to STRS clock/timer developer, which may be platform provider or application developer.
Notes None
Verification Method Inspection
See Also N/A
Example Sample documentation:

Clock/timer Name Monotonic from Power On
Clock/timer Handle name sysTime
Clock/timer Base Same as kind = 0
Purpose Be synch-able to flight computer.
Epoch Power On
Resolution 100 microseconds
Leap Seconds None
Matches None
Clock/timer kind 1
Purpose Keep up with other computers in the system. Timestamp.
Epoch 1/1/1970 GMT
Resolution Same
Leap Seconds None
Matches System time


Go to top,
Skip to (prev) STRS-130, Skip to (next) STRS-132

7.131   STRS-131 STRS_GetTimeAdjust
Requirement The STRS infrastructure shall contain a callable STRS_GetTimeAdjust method as described in table 68, STRS_GetTimeAdjust().
Table 68
STRS_GetTimeAdjust()
Description Get the current time rate for the specified clock/timer which, when applied to the clock specified by its handle ID, will more closely synchronize it with another.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toDev – (in STRS_HandleID) handle ID of device that should respond to the request.
Return iRate (STRS_TimeRate) an integer time rate. Units are specific to the clock/timer.
Precondition None
Postcondition Time rate is obtained or computed.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_SetTimeAdjust
Example 
STRS_Result rtn;
STRS_HandleID fromWF = APP_GetHandleID();
STRS_HandleID clDev = STRS_HandleRequest(fromWF,
  "Name of clock observed");
STRS_TimeWarp tBase, tKind;
STRS_TimeAdjust tRate;

tRate = STRS_GetTimeAdjust(fromWF, clDev);
if (!STRS_IsOK(rtn)) {
  STRS_Message msg =
        "STRS_GetTimeAdjust error.";
  STRS_Log(fromWF,STRS_ERROR_QUEUE,msg,
         strlen(msg));
  return rtn;
}


Go to top,
Skip to (prev) STRS-131, Skip to (next) STRS-133

7.132   STRS-132 STRS_SetTimeAdjust
Requirement The STRS infrastructure shall contain a callable STRS_SetTimeAdjust method as described in table 71, STRS_SetTimeAdjust().
Table 71
STRS_SetTimeAdjust()
Description Set the current time rate in the specified clock/timer.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • toDev – (in STRS_HandleID) handle ID of device that should respond to the request.
  • iRate – (in STRS_TimeRate) a rate applied to the specified clock/timer to set the clock/timer relative time. Units are specific to the clock/timer.
Return status (STRS_Result)
Precondition None
Postcondition Time rate is adjusted.
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Applicable to OE developer: usually platform provider
Use Case None
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_GetTimeAdjust
Example 
STRS_Result rtn;
STRS_HandleID fromWF = APP_GetHandleID();
STRS_HandleID refDev = STRS_HandleRequest(fromWF,
  "Name of Reference clock");
STRS_HandleID tgtDev = STRS_HandleRequest(fromWF,
  "Name of drifting clock");
STRS_HandleID defDev = STRS_HandleRequest(fromWF,
  STRS_DEFAULT_CLOCK_NAME);
STRS_Clock_Kind kRef = 1;
STRS_Clock_Kind kTgt = 1;
STRS_TimeWarp refbase, refkind, tgtbase, tgtkind; 

rtn = STRS_GetTime(fromWF, refDev, refbase, kRef, 
                   refKind);
rtn = STRS_GetTime(fromWF, tgtDev, tgtbase, kTgt,
                   tgtkind);
STRS_TimeWarp initial_difference = refkind - tgtkind;

while(TRUE)
{
    STRS_Sleep(fromWF, defDev, STRS_DEFAULT_CLOCK_KIND, POLL_INTERVAL, false);

    rtn = STRS_GetTime(fromWF, refDev, refbase, kRef,
                   refkind);
    rtn = STRS_GetTime(fromWF, tgtDev, tgtbase, kTgt,
                   tgtkind);
    STRS_TimeWarp drift = (refkind - tgtkind) -
                   initial_difference;  
    STRS_TimeAdjust tRate = drift * FEEDBACK_COEFFICIENT;

    rtn = STRS_SetTimeAdjust(fromWF, tgtDev, tRate);
}


Go to top,
Skip to (prev) STRS-132, Skip to (next) STRS-134

7.133   STRS-133 STRS_Sleep
Requirement The STRS infrastructure shall contain a callable STRS_Sleep method as described in table 72, STRS_Sleep().
Table 72
STRS_Sleep()
Description Delays the execution of the application for at least the time specified in the STRS_TimeWarp argument that contains the number of seconds and nanoseconds in the time interval. The time interval may still not be accurate depending on the underlying timer resolution and thread interaction.
Parameters
  • fromWF – (in STRS_HandleID) handle ID of current component making the request.
  • clockID – (in STRS_HandleID) the handle ID of the timer/clock.
  • kind – (in STRS_Clock_Kind) type of clock/timer.
  • twObj – (in STRS_TimeWarp) the STRS_TimeWarp object from which the time is extracted.
  • absOrRel- (in Boolean) true, if absolute time is specified; false, if relative time is specified.
Return (STRS_Result) STRS_OK when successful. STRS_ERROR for error. STRS_WARNING if interrupted.
Precondition None
Postcondition None
Applicable to OE developer: usually platform provider
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE developer: usually platform provider
Notes None
Verification Method Inspection using STRS compliance tool.
See Also STRS_GetTimeWarp
Example 
STRS_TimeWarp delta;
STRS_Seconds isec = 1; 
STRS_Nanoseconds nsec = 0;
delta = STRS_GetTimeWarp(isec,nsec);
STRS_Result ret = STRS_ERROR;
ret = STRS_Sleep(fromID, clockID, 0, delta, false);
// Let's try again with absolute time.
STRS_TimeWarp nowT, nowK;
ret = STRS_GetTime(fromID,clockID,nowt,0,nowK);
isec += STRS_GetSeconds(nowT);
nsec += STRS_GetNanoseconds(nowT);
nowK = STRS_GetTimeWarp(isec,nsec);
ret = STRS_Sleep(fromID, clockID, o, nowK, true);


Go to top,
Skip to (prev) STRS-133, Skip to (next) STRS-135

7.134   STRS-134 STRS Platform Queryable Parameters
Requirement The STRS infrastructure shall have the queryable parameter names,of type STRS_Property_Name, in table 75 for which values may be obtained using STRS_Query with the handle ID corresponding to the handle name STRS_OE_HANDLE_NAME.
Table 75
Queryable Platform Parameter Names
Parameter Name Description Notes
STRS_PLATFORM_PROVIDER Unique name of STRS platform provider This is usually a company name or university, followed by a subsidiary, division, or department name.
STRS_OE_VERSION Unique version number for platform STRS infrastructure software
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to OE
Notes None
Verification Method Inspection and Test
See Also N/A
Example 
STRS_Result rtn;
STRS_HandleID fromWF = APP_GetHandleID();
char name1[] = "STRS_OE_VERSION";
char value1[STRS_MAX_PROPERTY_VALUE_SIZE+1];
char name2[] = "STRS_PLATFORM_PROVIDER";
char value2[STRS_MAX_PROPERTY_VALUE_SIZE+1];
STRS_HandleID oeID =
    STRS_HandleRequest(fromWF,STRS_OE_HANDLE_NAME);
rtn = STRS_ValidateHandleID(oeID);
if (STRS_IsOK(rtn)) {
   rtn = STRS_Query(fromWF, oeID, name1, value1,
                    STRS_MAX_PROPERTY_VALUE_SIZE);
   if ( STRS_IsOK(rtn)) {
      print ("%s = %s\n", name1,value1);
   } else {
      print("STRS_Query OE error: %s\n",
             name1);
   }
   rtn = STRS_Query(fromWF, oeID, name2, value2,
                    STRS_MAX_PROPERTY_VALUE_SIZE);
   if ( STRS_IsOK(rtn)) {
      print ("OK: %s = %s\n", name2, value2);
   } else {
      print("STRS_Query OE error: %s\n",
             name2);
   }
} else {
   // ERROR
   print(
       "STRS_HandleRequest did not work for %s.\n",
     STRS_OE_HANDLE_NAME);
   return STRS_ERROR;
}


Go to top,
Skip to (prev) STRS-134,

7.135   STRS-135 STRS Application Queryable Parameters
Requirement An STRS application shall have the queryable parameter names, of type STRS_Property_Name, in table 76 for which values may be obtained using APP_Query and STRS_Query with the handle ID of the application.
Table 76
Queryable Application Parameter Names
Parameter Name Description Notes
STRS_APP_DEVELOPER Unique name of application developer This is usually a company name or university, followed by a subsidiary, division, or department name.
STRS_APP_VERSION Unique version number for STRS application software
STRS_APP_STATE Current application state Documented per STRS-12(3)
Rationale For an open architecture to support portability, the architecture has to be standardized across platforms and implementations. In particular, waveform applications and services have to use standard interfaces across all platforms.
Category Portability
Traced-from 4.1, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9, 5.1, 5.2
Use Case None
Applicable to Application developer
Notes None
Verification Method Inspection and Test
See Also N/A
Example 
STRS_Result rtn;
STRS_HandleID fromWF = APP_GetHandleID();
char name1[] = "STRS_APP_VERSION";
char value1[STRS_MAX_PROPERTY_VALUE_SIZE+1];
char name2[] = " STRS_APP_DEVELOPER";
char value2[STRS_MAX_PROPERTY_VALUE_SIZE+1];
char name3[] = "STRS_APP_STATE";
char value3[STRS_MAX_PROPERTY_VALUE_SIZE+1];
STRS_HandleID wfID = STRS_HandleRequest(fromWF,"WF1");
rtn = STRS_ValidateHandleID(wfID);
if (STRS_IsOK(rtn)) {
   rtn = STRS_Query(fromWF, wfID, name1, value1,
                    STRS_MAX_PROPERTY_VALUE_SIZE);
   if ( STRS_IsOK(rtn)) {
      print ("OK: %s = %s\n", name1,value1);
   } else {
      print("STRS_Query WF error: %s\n",
             name1);
   }
   rtn = STRS_Query(fromWF, wfID, name2, value2,
                    STRS_MAX_PROPERTY_VALUE_SIZE);
   if ( STRS_IsOK(rtn)) {
      print (OK: "%s = %s\n", name2, value2);
   } else {
      print("STRS_Query WF error: %s\n",
             name2);
   }
   rtn = STRS_Query(fromWF, wfID, name3, value3,
                    STRS_MAX_PROPERTY_VALUE_SIZE);
   if ( STRS_IsOK(rtn)) {
      print ("OK: %s = %s\n", name3, value3);
   } else {
      print("STRS_Query WF error: %s\n",
             name3);
   }

} else {
   // ERROR
   print("STRS_HandleRequest did not work for %s.\n",
        "WF1");
   return STRS_ERROR;
}

Go to top,
Skip to (prev) STRS-135.

List of Tables

Table 5 APP_Configure
Table 6 APP_Destroy
Table 7 APP_GetHandleID
Table 8 APP_GetHandleName
Table 9 APP_GroundTest
Table 10 APP_Initialize
Table 11 APP_Instance
Table 12 APP_Query
Table 13 APP_Read
Table 14 App_ReleaseObject
Table 15 APP_RunTest
Table 16 APP_Start
Table 17 APP_Stop
Table 18 APP_Write
Table 19 STRS_Configure
Table 20 STRS_GroundTest
Table 21 STRS_Initialize
Table 22 STRS_Query
Table 23 STRS_ReleaseObject
Table 24 STRS_RunTest
Table 25 STRS_Start
Table 26 STRS_Stop
Table 27 STRS_AbortApp
Table 28 STRS_GetErrorQueue
Table 29 STRS_GetHandleName
Table 30 STRS_HandleRequest
Table 31 STRS_InstantiateApp
Table 32 STRS_IsOK
Table 33 STRS_Log
Table 34 STRS_ValidateHandleID
Table 35 STRS_ValidateSize
Table 36 STRS_Write
Table 37 STRS_Read
Table 38 STRS_DeviceClose
Table 39 STRS_DeviceFlush
Table 40 STRS_DeviceLoad
Table 41 STRS_DeviceOpen
Table 42 STRS_DeviceReset
Table 43 STRS_DeviceUnload
Table 44 STRS_SetISR
Table 45 DEV_Close
Table 46 DEV_Flush
Table 47 DEV_Load
Table 48 DEV_Open
Table 49 DEV_Reset
Table 50 DEV_Unload
Table 51 STRS_FileClose
Table 52 STRS_FileGetFreeSpace
Table 53 STRS_FileGetSize
Table 54 STRS_FileGetStreamPointer
Table 55 STRS_FileOpen
Table 56 STRS_FileRemove
Table 57 STRS_FileRename
Table 58 STRS_MessageQueueCreate
Table 59 STRS_MessageQueueDelete
Table 60 STRS_PubSubCreate
Table 61 STRS_PubSubDelete
Table 62 STRS_Register
Table 63 STRS_Unregister
Table 64 Document STRS Clock/Timer
Table 65 STRS_GetNanoseconds
Table 66 STRS_GetSeconds
Table 67 STRS_GetTime
Table 68 STRS_GetTimeAdjust
Table 69 STRS_GetTimeWarp
Table 70 STRS_SetTime
Table 71 STRS_SetTimeAdjust
Table 72 STRS_Sleep
Table 73 STRS_TimeSynch
Table 74 Provide STRS.h
Table 75 STRS Platform Queryable Parameters
Table 76 STRS Application Queryable Parameters
Table 77 Use POSIX®

Go to top.