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.