Studio:Reference Overview
STRIDE is an embedded software verification platform which integrates with the embedded software target to create a single virtual platform that accelerates continuous integration, testing, and verification.
Designed with unique remote interfacing and automation capabilities, STRIDE empowers development teams to:
Conduct interactive development during coding Deploy unit and integration tests on the target device Automate test execution with every software build Provide automatic reporting of defects and test results
By adopting these practices, development teams create portfolios of reusable test assets and exploit these assets to automatically and continuously verify the health of engineering builds, thereby detecting defects early in the development cycle and achieving continuous integration.
As a result, embedded software development teams optimize their productivity, costs, quality, and ability to meet business objectives. Optimizing Integration is essential to improving product quality and schedule predictability. STRIDE is the first and only product that has been designed from the ground up to optimize the integration of embedded software applications, substantially reducing software defects while simultaneously shifting defect detection and resolution to earlier stages of the development cycle.
STRIDE is agnostic to the RTOS, transport, and compiler, and thus supports virtually any target device. STRIDE also provides the following key features:
- Support for all ActiveScripting languages, such as Perl, JScript, etc.
- Built-in reporting and test automation capabilities
- Record-and-playback capability to automate the capture of complex test scenarios using tracing data.
STRIDE and the Host Platform
STRIDE provides a number of key features to interact with the host platform:
- The STRIDE Communication Model is a standard that defines how embedded software components, such as threads and functions, can communicate with each other within an embedded application, as well as with scripts, Windows applications, and other software applications, regardless of the platform on which they are hosted. The SCM also defines each platform's runtime environment requirements to support seamless messaging, remote function calls, and tracing across platform boundaries. The SCM itself is defined by the STRIDE Communication Language (SCL), which is a collection of compiler pragmas, standard C-based data types, and limited C++ extensions. Using the SCL, developers can define unambiguous interfaces between components that allow for communications, regardless of where the components are located. The SCL Wizard streamlines and simplifies working with the SCL by allowing you to quickly capture interfaces and accurately qualify payloads and types.
- STRIDE Studio provides a graphical environment allowing software engineers to interactively exercise and verify code during implementation.
- STRIDE AutoScript extends your device software’s interfaces with the objects, properties, and methods to make them accessible in a script. This facilitates automated testing and allows you to break dependencies by simulating missing software or hardware components.
- 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 platform leverages your host-target connection to support on-target verification. You can select from off-the-shelf host-target connections (media and protocol), or configure your own custom connection.
- STRIDE Build Tools, a set of command line utilities, allow performing the Stride compile/build process, which may be easily invoked through makefiles or similar build utilities (eg. ANT).
STRIDE and the Target Platform
- Intercept Modules Intercept modules allow remote function calls across hardware (e.g., processor or machine) or software (operating system) platform boundaries.
- 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 Platform Abstraction Layer (PAL) isolates STRIDE from the details of your target hardware/software platform, and therefore makes it both portable across target platforms and forward-compatible with future RTOS and/or hardware changes.
The STRIDE Communication Model (SCM)
The STRIDE Communication Model (SCM) is a standard that defines how embedded software components, such as threads and functions, can communicate with each other within an embedded application, as well as with scripts, Windows applications, and other software applications, regardless of the platform on which they are hosted. The SCM also defines each platform's runtime environment requirements to support seamless messaging, remote function calls, and tracing across platform boundaries.
The STRIDE Communication Language (SCL) is an Interface Definition Language, or IDL, used by the SCM to identify and define messages, remote function calls (RFCs), and trace points within an application. For detailed information on the SCM and SCL, click here.
Transparent Interfacing
In STRIDE, the host and target are "combined" in a seamless virtual platform. The caller/sender (user) and called/receiver (owner) functions are each unaware of where the other lives. Communication boundaries can be threads, separate hardware platforms, or even desktop applications written in different programming languages; the STRIDE Runtime "hides" these details from the communicating parties.
Tracing
STRIDE's built-in tracing mechanism allows you to trace interface transactions without instrumenting your code. You can define trace points, which augment built-in function and message tracing; turn tracing on and off dynamically without rebuilding or recompiling your application; filter and prioritize tracing information; and instrument your application to view and monitor any object (e.g., a global variable).
The Owner/User Model
For the purposes of identifying the participants in a transaction over an interface, STRIDE assumes that your embedded software is structured such that some components (functions, transactors, interrupt routines, etc.) provide services to others. This service-centric orientation allows us to define interface perspectives, also known as transactors, as follows:
An owner is the called function or message destination. It identifies where function calls or messages are routed, whether it be to the original on-target function or receiver, to a window in STRIDE Studio, or to a script running in Studio. Only one owner is allowed at any given time, with one exception: broadcast messages can originate with one or more owners (subscribers) and terminate (be subscribed to) by one or more users.
A user makes calls to a function or sends messages to an owner, which can be the original on-target function or receiver, a window in STRIDE Studio, or a script running in Studio. There can be as many users as necessary.
Interface Types: Functions and Messages
Your embedded application’s internal interfaces most likely belong in one of two interface classifications:
A function interface, or application programming interface (API), occurs when a component directly calls a function. The calling component (the user) passes zero or more parameters via a direct function call. The called function (the owner) then responds with zero or one return values, and optionally, other data is returned indirectly (e.g., via pointers). During the function call, the calling component is blocked.
A messaging interface exists when one component signals another indirectly via a runtime, operating system, queue, or other means. Messaging interfaces are asynchronous. Commands sent from users to owners and responses sent from owners to users may or may not contain a message payload. Unlike function interfaces, a messaging interface does not necessarily result in the message sender being blocked.
There are four types of messages, which are described in the following section: command, response, two-way command-response, and broadcast.
Message Types
Some transactions are open-loop and others are closed-loop. Some transactions originate with the owner, whereas others originate with the user. STRIDE uses the following conventions to distinguish between the different types of transactions that take place on a given interface.
- A one-way command is a messaging interface transaction that is always sent from a user to the owner. As a result of receiving a one-way command, the owner may reply with one or more one-way responses.
- A one-way response is a messaging interface transaction that always originates with the owner. A one-way response may or may not be generated as a result of the receipt of a one-way command.
- A two-way command-response message involves a command sent from a user to the owner and an optional response sent from the owner to a user. Of course, a two-way command-response can be approximated with a one-way command and a one-way response. However, two-way command-responses have additional properties not available when pairing one-way transactions.
- A broadcast message is a messaging interface transaction that originates with one or more owners and terminates with one or more users, who subscribe to the message. The differences between a response and a broadcast message are:
- Broadcast messages are sent by one or more owners and received by one or more users. Unlike one-way and two-way messages, broadcast messages may have multiple owners and are not based on a command from user to owner.
- Users subscribe to broadcast messages (e.g., users notify the STRIDE Runtime when they want to receive particular broadcast messages).
In contrast, a response is associated with only one owner at any given time, and users do not subscribe to responses.
Intercept Modules
Intercept modules allow remote function calls across hardware (e.g., processor or machine) or software (operating system) platform boundaries. The following integration and testing situations are examples of when one or more intercept modules would be used:
- To call a function on the target platform from the host, you must generate an intercept module containing a stub and include it in the target build.
- To call a function on the host platform from a function on the target, you must generate an intercept module containing a proxy and include it in the target build.
- To trace on that function resides wholly on the target (e.g., both the called and the calling functions are co-located on the target platform), you must generate an intercept module containing a tracing delegate and include it in the target build.
- To be able to dynamically "move" a function back and forth between host and target platforms during integration and testing without rebuilding the target application, you must generate an intercept module containing a dynamic delegate and include it in the target build.
For more detailed information on intercept modules, including how to generate them, click here.
Data Marshalling
Data marshalling, which is the preparation of data for processing or transport from the host to target or target to host via an intercept module, occurs under the following circumstances:
- An intercept module containing a stub is generated and included in the target build. This allows a function on the host to call a function on the target.
- An intercept module containing a proxy is generated and included in the target build. This allows a function on the target to call a function on the host.
- An intercept module containing a tracing delegate is generated and included in the target build. This allows tracing of function calls that reside solely on the target.
- An intercept module containing a dynamic delegate is generated and included in the target build. This allows a function to be dynamically "moved" back and forth between the host and target platforms without rebuilding the target application.