Studio:Deploying STRIDE on the Target

Components on the Target

In order for STRIDE Studio to interoperate with your target system, some STRIDE code artifacts must be part of the binary running on your target.

The first is the combination of STRIDE Runtime and PAL, which together provide standard STRIDE runtime services customized for the target hardware and operating system.

The second is the Intercept Module (IM) which is dynamically created from your SCL-instrumented source code and additional specification through either the IM Wizard or scripting of the studio object model.

The runtime + PAL combination is typically created as part of a STRIDE platform integration. This code is static in nature; once produced, it is usually packaged as a linkable library for use with follow-on test code.

The IM, however, is often a dynamically-changing module, especially as source code is incrementally SCL-instrumented as tests are being developed. It is not always known what the ultimate IM setup will be when starting to create tests for a platform, but it's important to consider your needs up front, since the STRIDE deployment model you choose will affect project workflow.

Target Deployment Models

The TestAgent Configuration

By default, we recommend that you consider the light-weight "TestAgent" configuration. This deployment model imposes several limitations, but this model minimizes the impact on your target system and workflow, and in many testing scenarios, the limitations are not ***.

Requirements:

• IM can contain only stubs
• No target c/cpp files may be used to build the executable image
  • For target-based testing, test class implementations are in header file(s)