VectorCAST/RSP
| VectorCAST/RSP is a Runtime Support Package add-on to the VectorCAST toolset that enables testing of real-time applications directly in an embedded target or simulator environment. VectorCAST/RSP is used in conjunction with VectorCAST/C++ or VectorCAST/Ada to provide automated module testing in a real-time embedded environment. VectorCAST/RSP has been ported to industry-leading compiler and run-time combinations. |
|
Key Features
- Cross-Compiler Specific test-harness generation for execution on a target or simulator.
- Automatic Download of test harnesses and test cases for execution on a target by way of the compiler interface or a user-specified download mechanism.
- Execution Controlled from GUI provides an ease-of-use not common to component target testing.
- Customized I/O Facilities are provided on both the host and target sides to allow communication between the host and target processors for test reporting.
The VectorCAST-Test Harness Architecture
The VectorCAST architecture is centered on the executable test harness that is constructed using the VectorCAST environment constructor utility. The source code for the harness is re-built each time a new version of your application is built. This test harness is built using the same language as the source code being tested (Ada, C/C++). The test harness code is then compiled and linked into an executable program using the same cross compiler and linker that you are using for your application code. This results in a complete executable program that can be downloaded to any target architecture your cross-compilation tools support. The harness is completely compatible with the processor and board the application is intended to run on.
The VectorCAST harness is data driven, which means that no changes are required to the harness source code in order to change how the harness stimulates the code under test. VectorCAST uses file-based test data sets to stimulate the test harness. All data produced by the harness during a test run is likewise saved to files.
Additionally, all I/O that the harness performs is funneled through the VectorCAST I/O facility.
This architecture allows the VectorCAST application to run on a host platform while the test harness executable runs on the same host processor, OR on a remote target platform. The architecture of the target is not important, all that matters to VectorCAST is that there is some mechanism to send ASCII test data into the harness and to retrieve ASCII test results back from the harness. With VectorCAST/RSP this mechanism is the I/O link that is used for downloading the target processor from the host platform.
VectorCAST/RSP-Customization Issues
The following sections address each of the components of the target architecture that affect the customization of VectorCAST/RSP. The term "target architecture" refers to all information about the target board, compiler, and host computer that affects the VectorCAST/RSP product. For each issue listed, a summary of the impact to VectorCAST/RSP is provided.
Target Download Capabilities
VectorCAST must integrate with whatever tool or mechanisms exist to allow for the download of executable programs to the target board. All commands are integrated within VectorCAST to provide as automated a solution as possible. In some cases there will be manual steps involved (e.g. resetting the card rack). Any manual steps are formalized in the VectorCAST/RSP documentation. Integrating VectorCAST/RSP with the download facilities allows tests to be run as easily on the target as they are on the host. The only additional step is the download of the target board.
I/O Facilities
This is the prime area in which customization is required. Depending on the run-time kernel (executive) that is being employed, there may be robust, simple, or no I/O facilities on the target board. "Robust I/O" means that there is the capability to do host-mapped file I/O for both reading and writing of file data. "Simple I/O" means that there is a simple character or string based input and output capability across the download link, including the capability to (at a minimum) capture uploaded ASCII data from the target on the host machine. "No I/O" means that there is absolutely no facility within the run-time kernel that the application program can use to perform I/O operations. Each of these scenarios requires a different solution.
Because all harness I/O takes place using the VectorCAST I/O facility, I/O related customization is modular in nature. Customization involves replacing the stock VectorCAST I/O facility with a board / kernel specific facility.
In the case where there is "robust I/O", the stock VectorCAST I/O facility can be used with minor adjustments. Reads from files and writes to files will be mapped back to the host file system architecture. In the case where there is "simple I/O", VectorCAST will buffer I/O on both sides of the link and send bursts of ASCII data across the link as required.
In this case the stock VectorCAST I/O facility will be replaced with a facility that utilizes the kernel primitive I/O facilities. In the "No I/O" case, the stock VectorCAST I/O facility is replaced with calls to assembly level routines to interface to the hardware I/O facilities of the board. The "no I/O" case also requires a host based process to handle the host side of the I/O link to the board.
Processor Chip
No impact. All harness components are high-level source code that are simply compiled and linked for the target processor.
Board Architecture
Minimal impact. The use of special purpose chips such as a math co-processor may make certain high-level language constructs available or not available. These issues are similar to the VectorCAST code generation issues described in the following paragraph.
VectorCAST Code Generation
Minimal impact. In cases where all of the language facilities are not available in the target run-time kernel, checks are made during VectorCAST code generation to ensure that non-supported features are not used in the VectorCAST test harness code.