STRIDE Runtime

Overview

The STRIDE Runtime routes messages both within and between platform boundaries and manages the conversion of interface data as it crosses from one platform to another. This "transparent messaging" model means that your test cases can be located on one platform (e.g., as a script running off-target) and your code on another (on-target).

The STRIDE Runtime is a combination of processes and libraries that provide services for messaging, remote function calls, and tracing while providing seamless connectivity between the target application and the host operating system. The STRIDE Runtime standardizes how threads and applications communicate with each other, independent of the platform on which they are executing, which eliminates the need to integrate new software on the target hardware. Developers can then incrementally integrate embedded software on a combination of the desktop environment and the target hardware, providing more control over integration and testing. New software functionality under development can be simulated on the desktop environment while the software using this new functionality can run on the target hardware. The tremendous flexibility gained by allowing developers to choose how to integrate different software components and target platforms allows developers to detect integration and testing issues and correct defects much earlier in the development process.

The Runtime components consist of the Runtime APIs, the Runtime Thread, the PAL, the Transport Layer, and the Intercept Module. Each is briefly described here, with links provided for more detail.

The Runtime Developer's Guide

Click [here] to view the STRIDE Runtime Developer's Guide PDF document.

The Platform Abstraction Layer

The Platform Abstraction Layer, or PAL, defines the set of OS functionality required by the platform to support the STRIDE Runtime. The “pal.h” header file provided with the STRIDE installation defines the PAL functionality. The PAL also defines functionality required by the STRIDE Runtime to transmit and receive packets of data (called I-blocks) using the platform’s transport mechanism. These PAL routines enable the STRIDE Runtime to be installed on diverse environments without changing its internal design.

Click [here] to view the STRIDE Platform Abstraction Layer (PAL) Specification PDF document.

The Host Transport Services

The Host Transport Services define an interface that enables the STRIDE Runtime on your target to send data to and receive data from the target. The STRIDE Transport Server connects the Transport DLL to the STRIDE Runtime running on the host platform, thus providing indirect access to the target from STRIDE Studio, Autoscript, and other STRIDE applications. Several common transports are already supported within the STRIDE Transport Server, including serial and TCP/IP.

The Host Transport Services are defined in "transport.h" and each Transport DLL must implement the interfaces derived from the IStrideTransport class.

Click [here] to view the STRIDE Host Runtime Transport Specification PDF document.

The Transport Server Object Model

The Transport Server is an out-of-process COM server that provides connection management, loopback and diagnostic features. It can be accessed by clients through the API defined in the Transport Server Object Model .

The Intercept Module

Follow this link for an overview of the Intercept Module concept.

This link provides more background on the use of name mangling when implementing delegates within an Intercept Module.

Public Services

Runtime Test Services (RTS)

The Runtime Test Services (RTS) are a set of C-based APIs in the STRIDE Runtime that facilitate the writing of target based test code. These APIs make up an optional portion of the STRIDE Runtime and can be used to communicate additional information about tests to the host based reporting mechanism. These APIs also allow target test code to create additional test suites and test cases dynamically at runtime.
These C-based APIs work equally well from C Test Functions and C++ Test Classes. If, however, you choose to derive your C++ test classes from the STRIDE Runtime Base Class (srTest), then you will have access to member objects in the srTest class and its methods that provide the same functionality as the C APIs.

C Test Functions

C test functions enable testing of C code similarily to xUnit-style testing. Test functions can be written by users, captured using the scl_function pragma, and executed from the host. C-based Runtime Test Services APIs are available for use in test functions.

C++ Test Classes

C++ test classes enable testing of C++ code similarily to xUnit-style testing. Test classes can be written by users, captured using scl_test_class, scl_test_setup and scl_test_teardown pragmas, and executed from the host. C-based Runtime Test Services APIs as well as C++ Runtime Base Class are available for use in test classes.

C-based Runtime Test Services APIs provided:

• srTestSuiteAddSuite: creates an additional sub-suite at runtime.
• srTestSuiteSetName: sets the name of the specified suite.
• srTestSuiteSetDescription: sets the description of the specified suite.
• srTestSuiteAddTest: creates an additional test case at runtime.
• srTestCaseSetName: sets the name of the specified test case.
• srTestCaseSetDescription: sets the description of the specified test case.
• srTestCaseAddComment: adds a comment to the specified test case.
• srTestCaseSetStatus: explicitly sets the status for the specified test case.
• srTestCaseSetStatusEx: explicitly sets the status for the specified test case and allows specification of an extended failure code.

Member objects of srTest base class, via which you can access the same
functionality:
• testSuite member object provides following methods:
156
o AddSuite
o SetName
o SetDescription
o AddTest
• testCase member object provides following methods:
o SetName
o SetDescription
o AddComment
o SetStatus
These services use the srtest.h header file.