STRIDE Runtime - Revision history

Marku at 15:13, 4 July 2015

2015-07-04T15:13:08Z

← Older revision		Revision as of 15:13, 4 July 2015
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.

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

	~~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''' - fields client requests to a target and provides connection management, loopback and diagnostic features.

	*The '''~~Runtime APIs~~''' - a ~~public API~~ set, defined in the ''sr.h'' header file,~~ available for programmers~~ to ~~integrate into their target application code. These APIs support test unit logging~~ and ~~services, messaging, remote function calls, and tracing between~~ the ~~target application and host operating system. Additionally, a set of software development kits are available for creating target applications~~.		* 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.

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

	~~Each is briefly described here, with links provided for more detail.~~

	Refer to [[Runtime ~~Integration~~]] ~~on how to integrate the STRIDE Runtime in your environment~~.		Refer to the [[Media:s2sRuntime.pdf\|STRIDE Runtime Developer's Guide]] for more details.

	~~== The Platform Abstraction Layer ==~~		= Runtime Configuration =

	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.

	~~Refer to the [[Platform Abstraction Layer\|Platform Abstraction Layer]] page for a more detailed description of the PAL and its interfaces.~~

	~~== The Runtime Developer's Guide ==~~

	~~Click [[Media:s2sRuntime.pdf\|here]] to view the STRIDE Runtime Developer's Guide PDF document.~~

	=== 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:		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 STRIDE Transaction Identifiers (STIDs) that may be active simultaneously
Line 48:		Line 32:
	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 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) ===		= 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.		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 '''[[~~Test_API\|this page~~]]''' for more information on these APIs.		Please refer to the '''''srtest.h''''' header file and '''[[Runtime Test Services]]''' article for more information on these APIs.

	=== Logging Services ===		= 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 74:		Line 58:


	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.~~		These services are defined in '''''sr.h''''' header file.

	~~== 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.~~

	~~== Other Runtime components ==~~
	*[[Platform_Abstraction_Layer\|Platform Abstraction Layer (PAL)]]

	~~[[Category: Reference]]~~

Ivailop: /* Other Runtime components */

2014-06-05T20:02:33Z

Other Runtime components

← Older revision		Revision as of 20:02, 5 June 2014
Line 84:		Line 84:
	== Other Runtime components ==		== Other Runtime components ==
	*[[Platform_Abstraction_Layer\|Platform Abstraction Layer (PAL)]]		*[[Platform_Abstraction_Layer\|Platform Abstraction Layer (PAL)]]
	*[[SLAP\|Simplified Link Application Protocol (SLAP)]]

	[[Category: Reference]]		[[Category: Reference]]

Ivailop: /* Other Runtime components */

2013-09-24T21:32:07Z

Other Runtime components

← Older revision		Revision as of 21:32, 24 September 2013
Line 85:		Line 85:
	*[[Platform_Abstraction_Layer\|Platform Abstraction Layer (PAL)]]		*[[Platform_Abstraction_Layer\|Platform Abstraction Layer (PAL)]]
	*[[SLAP\|Simplified Link Application Protocol (SLAP)]]		*[[SLAP\|Simplified Link Application Protocol (SLAP)]]
	*[[GRS\|Generic RTOS Services (GRS)]]

	[[Category: Reference]]		[[Category: Reference]]

Ivailop: /* Runtime Test Services (RTS) */

2010-06-14T17:46:34Z

Runtime Test Services (RTS)

← Older revision		Revision as of 17:46, 14 June 2010
Line 52:		Line 52:
	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.		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 '''[[~~Test_Units~~\|~~Test Units~~ page]]''' for more information on these APIs.		Please refer to the '''''srtest.h''''' header file and '''[[Test_API\|this page]]''' for more information on these APIs.

	=== Logging Services ===		=== Logging Services ===

Ivailop: /* Other Runtime components */

2010-06-07T21:26:42Z

Other Runtime components

← Older revision		Revision as of 21:26, 7 June 2010
Line 83:		Line 83:

	== Other Runtime components ==		== Other Runtime components ==
			*[[Platform_Abstraction_Layer\|Platform Abstraction Layer (PAL)]]
			*[[SLAP\|Simplified Link Application Protocol (SLAP)]]
	*[[GRS\|Generic RTOS Services (GRS)]]		*[[GRS\|Generic RTOS Services (GRS)]]
	*[[SLAP\|Simplified Link Application Protocol (SLAP)]]

	[[Category: Reference]]		[[Category: Reference]]

Ivailop: /* The Platform Abstraction Layer */

2010-06-07T21:24:34Z

The Platform Abstraction Layer

← Older revision		Revision as of 21:24, 7 June 2010
Line 25:		Line 25:
	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.		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.

	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.		Refer to the [[Platform Abstraction Layer\|Platform Abstraction Layer]] page for a more detailed description of the PAL and its interfaces.

	== The Runtime Developer's Guide ==		== The Runtime Developer's Guide ==

Marku: moved Runtime Reference to STRIDE Runtime

2010-06-07T16:08:37Z

moved Runtime Reference to STRIDE Runtime

← Older revision	Revision as of 16:08, 7 June 2010
(No difference)

Ivailop: /* The Runtime Developer's Guide */

2009-06-11T22:57:43Z

The Runtime Developer's Guide

← Older revision		Revision as of 22:57, 11 June 2009
Line 30:		Line 30:

	Click [[Media:s2sRuntime.pdf\|here]] to view the STRIDE Runtime Developer's Guide PDF document.		Click [[Media:s2sRuntime.pdf\|here]] to view the STRIDE Runtime Developer's Guide PDF document.

			=== 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) ===		=== Runtime Test Services (RTS) ===

Ivailop: /* The Platform Abstraction Layer */

2009-06-11T22:57:19Z

The Platform Abstraction Layer

← Older revision		Revision as of 22:57, 11 June 2009
Line 26:		Line 26:

	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.		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.



	== The Runtime Developer's Guide ==		== The Runtime Developer's Guide ==

Ivailop: /* Runtime Configuration */

2009-06-11T22:57:07Z

Runtime Configuration

← Older revision		Revision as of 22:57, 11 June 2009
Line 27:		Line 27:
	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.		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

	~~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 Runtime Developer's Guide ==		== The Runtime Developer's Guide ==