QP/C++ Framework component shall support Software Tracing.
Description
Support for Software Tracing means that the QP/C++ Framework component shall implement the QS target-resident component. This also means that the QP/C++ Framework component shall provide the Software Tracing API for initializing the QS target-resident component, setting up the filters, encoding QS trace records, accessing the QS trace buffers, etc.
Forward Traceability (truncated to 2 level(s))
QS target-resident component shall be inactive by default and activated only when explicitly enabled.
Description
The QS tracing API shall be inactive by default, meaning it should not produce any executable code. The QS instrumentation shall become active only when explicitly enabled. This requirement does NOT mean that the QS tracing instrumentation gets removed or changed in the QP/C++ Framework component or QP/C++ Application source code. Instead, this requirement means that the (inactive) QS instrumentation can be safely left in the source code (both QP/C++ Framework component and QP/C++ Application) to help in future development, testing, and maintenance.
Use Case
The QS API can be implemented as preprocessor macros (in C or C++), which are defined to nothing by default, resulting in no code generation by the compiler. Only when a special macro is defined (e.g., Q_SPY), the QS API can be defined such that it generates code. That way also avoids contaminating the source code with conditional compilation for every QS API, which could run the risk of inadvertently leaving some QS APIs active (should the developer forget to surround the QS API with conditional compilation).
Forward Traceability (truncated to 2 level(s))
QS target-resident component shall use the binary data protocol.
Description
The QS target-resident component shall produce tracing data into the RAM buffer encoded by means of a binary protocol. The main feature required from the applied protocol is maintaining delimited frames, each containing one trace record. The protocol "frames" shall contain the following elements:
Use Case
This requirement can be met, for example, by a High-Level Data Link Control (HDLC) protocol, which is characterized by establishing very easily identifiable frames in the serial data stream. Any receiver of such a protocol can instantaneously synchronize to the frame boundary by simply finding the Flag byte (typically 0x7E).
Forward Traceability (truncated to 2 level(s))
QS target-resident component shall allow flexible buffering schemes and decoupling trace generation from transmission to the host.
Description
The QS data protocol is the primary enabler for a flexible buffering policy. Specifically, the protocol inserts only complete trace records as delimited "frames" into the RAM buffer, which has two significant consequences:
Forward Traceability (truncated to 2 level(s))
QS target-resident component shall support Global-Filter.
Description
The QS Global-Filter is based on the record-id associated with each QS trace record (see SRS_QP_QS_10). The Global-Filter shall allow the QP/C++ Application to disable or enable each record-id or an arbitrary subset of record-ids. For example, QP/C++ Application might enable or disable only state-machine-entry records, or all state-machine groups of records. This filter works globally for all trace records in the entire system.
Forward Traceability (truncated to 2 level(s))
QS target-resident component shall support Local-Filter.
Description
The QS Local-Filter is based on the individual object-id associated with various objects in the target memory. The object-ids are small integer numbers in the range 0..127. The object-ids in the range 0..64 are reserved for the Active Objects, where object-id corresponds to the unique priority of the Active Object. QP/C++ Application can associate other remaining object-ids (65..127) with different objects. Then, the QP/C++ Application can set up the QS Local-Filter to enable only a specific object-id or any subset of object-ids.
Use Case
The main use case for the Local-Filter is an application where particular objects (e.g., Active Objects) are very "noisy" and would overwhelm the trace. The Local-Filter allows the QP/C++ Application to silence the "noisy" objects and let the others through. Please note that the Global-Filter cannot achieve such a selection and must be complemented by the Local-Filter.
Forward Traceability (truncated to 2 level(s))
QS target-resident component shall support predefined trace records.
Description
Predefined trace records are trace records with a fixed format known upfront by both the QS target-resident component and the QSPY host-resident component. Every predefined trace record is uniquely identified by its record-id (see SRS_QP_QS_10), and the record-id range 0..100 is reserved for the predefined records. This one-to-one mapping between record-ids and predefined records allows the QSPY host-resident component to easily recognize and correctly parse all the "pre-defined" records. Most predefined trace records have the timestamp data element (see SRS_QP_QS_10), but some (e.g., dictionary trace records) do not.
Use Case
Predefined trace records are used for tracing instrumentation embedded in the QP/C++ Framework component, such as state machine activity (dispatching events, entering/exiting a state, executing transitions, etc.), Active Object activity (allocating events, posting/publishing events, time events, etc.), and more.
Forward Traceability (truncated to 2 level(s))
QS target-resident component shall support application-specific trace records.
Description
Application-specific trace records have a flexible format not known in advance to the QSPY host-resident component. Instead, application-specific trace records carry the format information in them (which makes them somewhat less efficient than predefined trace records). The record-ids of application-specific trace records are in the range 101-127, and are used only for the Local-Filter (see SRS_QP_QS_20). However, the record-ids in this case do not determine any specific format of the application-specific record. In other words, many application-specific trace records can have the same record ID. All application-specific trace records have the timestamp data element (see SRS_QP_QS_10).
Use Case
Application-specific trace records are used for tracing instrumentation embedded in the QP/C++ Applications. Their flexible format allows the QP/C++ Application to add arbitrary information to the software trace.
Forward Traceability (truncated to 2 level(s))
QS target-resident component shall provide symbolic information in the trace using dictionary trace records.
Description
The QS target-resident component provides special predefined dictionary trace records designed expressly for providing the symbolic information about the target code in the trace itself. These dictionary records are similar to the symbolic information embedded in the object files for the traditional single-step debugger. QS supports five types of dictionary trace records:
Forward Traceability (truncated to 2 level(s))
QS target-resident component shall provide the receive channel to allow interaction between the host and the target.
Description
A QS-RX channel is required for interacting with the target system and implementing such features as testing, validation, verification, and monitoring of the target system. The QS-RX channel provides the following services:
Forward Traceability (truncated to 2 level(s))
