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 (refer to the SCL Wizard section of the STRIDE Online Help for information.)

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.

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

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

• one-way responses are used by function owners to reply to one-way commands. An owner may reply with one or more one-way responses.

• two-way command-responses involve 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.

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

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.

See Also

• SCL Structure
• SCL Data Types
• SCL Design Requirements
• SCL Message Attributes
• SCL Pragmas
• For detailed instructions on working with SCL, including code samples and examples, refer to the SCL Reference Guide.