Studio:SCL Overview
Overview of The STRIDE Communication Language
The STRIDE Communication Model
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 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.
During integration and testing, it is often desirable but difficult to separate two components across platform boundaries, such as in the following examples:
- During unit testing, the SCM permits a host-based unit-under-test to transact with a target-based component that would otherwise be difficult to simulate.
- One component in a complex target build changes frequently. As long as the interfaces remain stable, the SCM allows the changing component to be moved to the host. The component can then be modified as frequently as you want, while the rest of the target build remains unchanged.
As defined by the SCM, an interface can be either an asynchronous message exchanged between two components, or a direct function call of one component invoked by another. The SCM defines how components can communicate with each other over interfaces using standard messaging services provided by the STRIDE Runtime.
In addition to enabling components to communicate with each other across platform boundaries using asynchronous messages and remote function calls, the SCM also defines a tracing model. An SCM-compliant runtime environment provides tracing capabilities, so that you can capture interface transactions between components without requiring instrumentation of the components on either side of the interface. An SCM-compliant runtime also supports trace points, which allows developers to leverage the runtime and the underlying SCM to extract additional, non-transactional information from the embedded application.
Owners and Users
The SCM assumes that there is an owner/user relationship between the components communicating across an interface. An owner provides services to others, while a user consumes services provided by the owner (click here for more information about owners and users).
Asynchronous Messaging
Inter-thread communications are generally asynchronous and are accomplished using messages. To afford developers maximum flexibility in designing messaging schemes, the SCM supports four different types of messages:
- one-way commands
- one-way responses
- two-way command-responses
- broadcast responses
Click here for more information about these types of messages. Each SCM-compliant asynchronous message type may consist of up to three elements:
- a 16-bit identifier to uniquely identify the message and type
- a set of attributes specific to each message type
- optional data, called the payload
Remote Function Calls
Remote function calls, or RFCs, allow synchronous communications such as direct function calls, regardless of the platform on which they are located. Like asynchronous messaging, the RFC model also identifies each transaction on an interface as having an owner and a user. In this case, however, the owner/user relationship is much more straightforward. Because it provides the service associated with a function, the owner is the function itself. A user, therefore, is the caller of the function.
To allow the owner and the user of a direct function call transaction to be located on different platforms, the function call must be intercepted, converted into an asynchronous two-way command-response message, and then converted back into a function call response. During this entire process, which is completely automated by STRIDE, the caller is blocked.
Each SCM-compliant runtime requires its own unique 16-bit identifier so it can route remote function calls correctly across platforms.
Tracing
The SCM tracing model is based on built-in messaging support provided by the STRIDE Runtime, and includes additional capability for software instrumentation. Tracing is enabled via filters.
The STRIDE Communication Language (SCL)
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. Interfaces are identified and annotated in order to expose enough information about them so that they can be marshaled across platform boundaries. SCL-compliant messages also define a contract between the communicating owner and user. The syntax and semantics of this contract are described below.
The SCL is a superset of the ANSI C language. SCL extensions to the C language are a set of pragmas that allow interface semantics to be more precisely prescribed than allowed by the C language.
- Message-based interfaces require unique identification of the message, definition of the sender/receiver relationship, and description of the data, if any, that is part of the message payload.
- Function-based interfaces require unique identification of the function and a description of the parameters and return values.
- Trace points require unique identification of the trace point, assignment of a name, and description of the optional associated data.
SCL is a superset of the ANSI C Standard (ISO/IEC 9899:1999). Primarily, the extensions consist of new pragma directives. For detailed information about SCL Pragmas, click here. The context for this description is the ANSI C Standard (ISO/IEC 9899:1999). Many terms used within this section have meaning as defined by the standard.
An SCL-compliant compiler automatically defines the symbol "_SCL".
Note: C++-style tag names for enumerations, structures, and unions are supported.
SCL Pragmas
Test Units
Capture
Qualification
Trace
See Also
- For detailed instructions on working with SCL, including code samples and examples, refer to the SCL Reference Guide.
- SCL Structure
- SCL Data Types
- SCL Design Requirements
- SCL Message Attributes
- SCL Pragmas