STRIDE Runtime: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
No edit summary
 
(36 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Overview  ==
__NOTOC__
 
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 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 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. This flexibility allows 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.  
 
<br>


[[Image:Runtime Overview.jpg|600px|center|Overview of the STRIDE Runtime]]  
[[Image:Runtime Overview.jpg|600px|center|Overview of the STRIDE Runtime]]  


<br>The Runtime components consist of:  
Other related components:
 
*The '''PAL (Platform Abstraction Layer)''' - provides a consistent interface for the STRIDE Runtime regardless of the operating system or data transport used. It consists of a small set of functions that provide a virtual link between the target operating system and the STRIDE Runtime. The PAL functionality, defined in the ''pal.h'' header file, allows the STRIDE Runtime to transmit and receive packets of data (called I-blocks) using the platform’s transport mechanism.
 
*The '''Host Transport Layer and Object Model''' - a server process and set of APIs that connects the Transport DLL to the STRIDE Runtime, providing indirect access to the target from host-side scripts and STRIDE applications. The Host Transport Services are defined in the ''transport.h'' header file. The Transport Server process is is accessed through the set of interfaces defined for the ''STRIDE.transport'' COM server.
 
*The '''Runtime APIs''' - a public API set, defined in the ''sr.h'' header file,&nbsp;available for programmers to integrate into their target application code. These APIs support messaging, remote function calls, and tracing between the target application and host operating system.
 
*The '''Intercept Module''' - generated code that facilitates remote function calls between the host and target. The IM code links to the target application; it implements '''stubs '''to allow remote function calls from the host to target-resident functions, and '''proxies '''that&nbsp;intercept target function calls and remotes them to a host implementation of the function. The IM can contain logic to dynamically switch target-based function calls to either host-resident or target-resident implementations, and capture tracing information, through '''delegates'''.


Additionally, groups of Runtime APIs provide test unit logging and services, and a software development kit is available for creating windows-based target applications. Each is briefly described here, with links provided for more detail.  
* The [[Platform_Abstraction_Layer | '''PAL (Platform Abstraction Layer)''']] - provides a consistent interface for the STRIDE Runtime regardless of the operating system or data transport used. It consists of a small set of functions that provide a virtual link between the target operating system and the STRIDE Runtime. The PAL functionality, defined in the ''pal.h'' header file, allows the STRIDE Runtime to transmit and receive packets of data (called I-blocks) using the platform’s transport mechanism.


<br>
* The [[Intercept_Module | '''Intercept Module''']] - is auot-generated harnessing code that facilitates remote function calls between the host and target.


== The Platform Abstraction Layer<br>  ==


The&nbsp;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.<br>
Refer to the [[Media:s2sRuntime.pdf|STRIDE Runtime Developer's Guide]] for more details.  


Refer to the [[Platform Abstraction Layer|Platform Abstraction Layer]] page and the [[Media:s2sPAL.pdf|PAL Specification]] document for a more detailed description of the PAL and its interfaces.
= Runtime Configuration =
You can configure the STRIDE Runtime by editing '''srcfg.h''' to achieve specific real-time performance objectives. By tailoring the RAM requirements, real-time performance, and traffic across the host-target transport, you can meet your own unique needs. Use the following STRIDE Runtime configuration parameters:
* Total number of STRIDE Transaction Identifiers (STIDs) that may be active simultaneously
* Total number of simultaneous broadcast message subscribers
* Total number of embedded pointers in your interfaces
* Total number of unique interfaces
* Total memory allocated for tracing
* Size of an individual trace buffer
* Frequency that trace buffers are transmitted from target to host
* Remote Function Call settings
* Enabling and configuring Memory Management settings
* Enabling Multi-Process Target settings
* Enabling Variable Arguments
* Timestamp unit


<br>
The default configuration is generally adequate for most uses, however the configuration may need to be adjusted as more sophisticated tests are developed with more numerous or complex interfaces.


== The Host Transport Services ==
= Runtime Test Services (RTS) =


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 Runtime Test Services (RTS) are a set of APIs implemented using the STRIDE Runtime that facilitate the writing of target based test code. These APIs are considered an optional extension on top of the STRIDE Runtime and can be used to communicate additional information about tests to the host based reporting mechanism. They also allow target test code to create additional test suites and test cases dynamically at runtime.  


[[Image:Transport diagram.gif|center|Host Transport Services Diagram]]  
Please refer to the '''''srtest.h''''' header file and '''[[Runtime Test Services]]''' article for more information on these APIs.


The Host Transport Services are defined in "transport.h" and each Transport DLL must implement the interfaces derived from the IStrideTransport class.
= Logging Services =
 
Refer to the [[Media:s2sTransport.pdf|STRIDE Host Runtime Transport Specification]] document for a more detailed description of the Host Transport Services.
 
<br>
 
== The Intercept Module  ==
 
The [[Intercept Module]] page provides details of the Intercept Module concept.<br>
 
The [[Name Mangling]] page provides more background on the use of name mangling when implementing delegates within an Intercept Module.
 
<br>
 
== The Runtime Developer's Guide  ==
 
Click [[Media:s2sRuntime.pdf|here]] to view the STRIDE Runtime Developer's Guide PDF document.
 
<br>
 
== Public Services<br>  ==
 
<br>
 
=== Runtime Test Services (RTS)<br>  ===
 
<br>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.<br>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.<br>
 
<br>
 
==== 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_test_flist or scl_test_cclass pragmas, and executed from the host. C-based [[Test_Units#Runtime_Test_Services|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.<br>
 
These services use the '''''srtest.h''''' header file. Please refer to the '''[[Test_Units#Runtime_Test_Services|Test Units page]]''', or Chapter 4 of the [[Media:s2sRuntime.pdf|STRIDE Runtime Developer's Guide]] for more information on these APIs.
<br>
 
=== Logging Services ===


The following are the categories available in the Runtime API for logging, that is, collecting and/or displaying, information at the host runtime environment:  
The following are the categories available in the Runtime API for logging, that is, collecting and/or displaying, information at the host runtime environment:  
Line 93: Line 53:
**'''srPrintInfo()''': used to output a formatted string with variable arguments to be displayed at information level filtering.  
**'''srPrintInfo()''': used to output a formatted string with variable arguments to be displayed at information level filtering.  
**'''srPrintError()''': used to output a formatted string with variable arguments to be displayed at error level filtering.
**'''srPrintError()''': used to output a formatted string with variable arguments to be displayed at error level filtering.
*'''Messaging''' - These routines can be used to send and receive messages for logging or any other debugging purposes.
**'''srBroadcast()''': used to “broadcast” information to one or more subscribers. Each subscriber receives its own copy of the message or pointer, depending on the attributes of the payload. If there are multiple subscribers on a remote platform only one copy of the response is transmitted across the link. If there are no subscribers then the routine simply returns.
**'''srSubscribe()''': used to subscribe to a Broadcast message sent using srBroadcast. There has to be at least one subscriber for a broadcast message to be sent.


These services use the '''''sr.h''''' header file. Please refer to Chapter 3 of the [[Media:s2sRuntime.pdf|STRIDE Runtime Developer's Guide]] for more information on these APIs.<br>
<br>
== The Windows Off-Target SDK  ==
The STRIDE development environment provides a way for you to build and execute your application and test code off-target, on a Windows host platform. This provides a faster way to test and validate your code since it does not require you to build your target application and re-image the device.
The Windows Off-Target SDK consists of:<br>
*The Target Runtime, PAL and [[GRS|GRS]] packaged in the s2srwin.lib and s2srwin.dll files, installed in the STRIDE\lib and STRIDE\bin directories.
*The public APIs for these components, available through header files installed in the STRIDE\inc directory. These include:
**sr.h
**srwin.h
**grs.h
**pal.h
*Utility script components that facilitate building and executing off-target applications on Windows hosts:
**[[STRIDE.vsbuild|STRIDE.vsbuild]]
**[[STRIDE.windowsprocess|STRIDE.windowsprocess]]
These components are written in the Perl scripting language and therefore require that Perl be installed. See [[Host_Installation#Third Party Requirements|Perl requirements]] for more information.<br>
Development of off-target applications using the SDK resources is discussed in more detail in the [[Windows Off-Target Apps|Windows Off-Target Apps]] page.
== 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 STRIDE.transport Program ID. The Transport Server API is defined in the [[Transport Server Component|Transport Server Object Model]] page.


[[Category: Reference]]
These services are defined in '''''sr.h''''' header file.

Latest revision as of 15:13, 4 July 2015

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. This flexibility allows 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.

Overview of the STRIDE Runtime

Other related components:

  • The PAL (Platform Abstraction Layer) - provides a consistent interface for the STRIDE Runtime regardless of the operating system or data transport used. It consists of a small set of functions that provide a virtual link between the target operating system and the STRIDE Runtime. The PAL functionality, defined in the pal.h header file, allows the STRIDE Runtime to transmit and receive packets of data (called I-blocks) using the platform’s transport mechanism.
  • The Intercept Module - is auot-generated harnessing code that facilitates remote function calls between the host and target.


Refer to the STRIDE Runtime Developer's Guide for more details.

Runtime Configuration

You can configure the STRIDE Runtime by editing srcfg.h to achieve specific real-time performance objectives. By tailoring the RAM requirements, real-time performance, and traffic across the host-target transport, you can meet your own unique needs. Use the following STRIDE Runtime configuration parameters:

  • Total number of STRIDE Transaction Identifiers (STIDs) that may be active simultaneously
  • Total number of simultaneous broadcast message subscribers
  • Total number of embedded pointers in your interfaces
  • Total number of unique interfaces
  • Total memory allocated for tracing
  • Size of an individual trace buffer
  • Frequency that trace buffers are transmitted from target to host
  • Remote Function Call settings
  • Enabling and configuring Memory Management settings
  • Enabling Multi-Process Target settings
  • Enabling Variable Arguments
  • Timestamp unit

The default configuration is generally adequate for most uses, however the configuration may need to be adjusted as more sophisticated tests are developed with more numerous or complex interfaces.

Runtime Test Services (RTS)

The Runtime Test Services (RTS) are a set of APIs implemented using the STRIDE Runtime that facilitate the writing of target based test code. These APIs are considered an optional extension on top of the STRIDE Runtime and can be used to communicate additional information about tests to the host based reporting mechanism. They also allow target test code to create additional test suites and test cases dynamically at runtime.

Please refer to the srtest.h header file and Runtime Test Services article for more information on these APIs.

Logging Services

The following are the categories available in the Runtime API for logging, that is, collecting and/or displaying, information at the host runtime environment:

  • Setup and Shutdown
    • srCreateSTID(): used to allocate resources required to send and receive trace and print messages that implement the following APIs.
    • srDeleteSTID(): used to free STRIDE Runtime resources previously allocated for an STID.
  • Tracing - Tracing routines are used by target applications for information collection and display by the host runtime environment.
    • srTracePoint(): used to output a data structure to the tracing window on the host.
    • srTraceStr(): used to output a string to the tracing window.
  • Printing - These routines are used by applications to log or display messages on Trace Views on the host.
    • srPrintInfo(): used to output a formatted string with variable arguments to be displayed at information level filtering.
    • srPrintError(): used to output a formatted string with variable arguments to be displayed at error level filtering.
  • Messaging - These routines can be used to send and receive messages for logging or any other debugging purposes.
    • srBroadcast(): used to “broadcast” information to one or more subscribers. Each subscriber receives its own copy of the message or pointer, depending on the attributes of the payload. If there are multiple subscribers on a remote platform only one copy of the response is transmitted across the link. If there are no subscribers then the routine simply returns.
    • srSubscribe(): used to subscribe to a Broadcast message sent using srBroadcast. There has to be at least one subscriber for a broadcast message to be sent.


These services are defined in sr.h header file.

Retrieved from "https://www.stridewiki.com/index.php?title=STRIDE_Runtime&oldid=14345"