Based on NASA Standard NASA-STD-4009A Draft
Table of Contents
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.
- Using a script or WFCCN is a type of inspection that is computer-aided.
- Using a compliance tool implies a script or WFCCN.
- 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:
|
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:
|
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:
|
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 |
|
||||||||||||||||||||||||||||||||
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:
|
||||||||||||||||
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 |
|
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:
|
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||||||||||||||||
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:
|
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||||
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 |
|
||||||||||||
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 |
|
|||||||||||||||
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.