In general we use a SIL Test Harness to develop and test C or C++ code on a PC.  The code might be generated, hand crafted, or a combination.  It is also possible to build a SIL Test Harness which executes the test cases on the target microcontroller.  Note that for testing on a PC, although we are using C++ compiler, we compile and build ANSI C code. It is advisable to use a Static Analysis tool for many reasons, here are a couple that apply in the PC-based testing of embedded C code:

To ensure that you do not include any C++ constructs (if your target compiler is a C compiler)

To ensure that your code is portable (See our C Portability Guidelines.)

hmtoggle_plus1Step 1. Create the Basic Harness
hmtoggle_plus1Step 2. Customize the MSVC Project
hmtoggle_plus1Step 3. Stub Partitioning
hmtoggle_plus1Step 4. Define the Interface (Ports) in an AppIF.c File
hmtoggle_plus1Step 5. Compiling and Linking
hmtoggle_plus1Step 6. Export and Connect Your Signals
hmtoggle_plus1Step 7. Create and Execute TestCases and Scenarios

Linking an Existing C Project for SIL Testing

To Harness a project is to set up the Virtual Micro Controller environment for your source code set.  You need to follow all the steps above for harnessing a new project, but before you start you should read the notes below.

Harnessing addresses Scheduling and the I/O interface.


For harnessing we can classify the scheduling strategy for a controller into Simple Scheduler, OSEK, and Other.

Simple Scheduler - Many real-time control systems have a Simple Scheduler.  By simple Scheduler we mean that there is no concept of Tasks, and the scheduler therefore is not responsible for switching from one task to another in a preemptive way.  There may be interrupt handlers, but the Scheduler does not handle the interrupts.

OSEK - Many ECUs employ an OSEK operating system.  MxVDev has an OSEK that runs on the PC.  When testing in this environment you use the MxVDev OSEK.

Other - For other scheduling approaches, such as a preemptive OS, we essentially adapt/extend what we described above.  It may be necessary to port the OS to run in a PC environment.

I/O Interface

Identify the I/O interface to which you plan to connect.  The choices are usually MicroController Abstraction Interface, or Application Component Interface. For an existing code set, the MicroController abstraction is best.

There are five steps to building your harness.  This may take half a day or so to complete.

1.Add Source Code to project - Check out a complete copy of the Source Code, including all included header files. Based on the I/O interface chosen, add the appropriate files to the MSVC project.

2.Compile - Pick one of the simple C files and click the compile button. You will probably get some errors which you will have to address. Once you get one file compiling, the second one is easier, and the third is easier still. See the Tips on Portability to help you get the compilations working.

3.Link - During the linking phase we identify all the unresolved variables and functions. This list usually corresponds closely to the Input and Outputs to the SUT. In general, each unresolved symbol results in a definition in the AppIF.c file. See the Tips on Stubbing for help resolving problems with linking.

4.Init Function - Identify the functions that should be called to Initialize the SUT code. Cause them to be invoked from an initialization test case.

5.Tick Function - Identify the Step or Tick Function(s). Cause them to be invoked at the appropriate periodic rate from Execution Model test cases.


Generated Code - Code that has been generated is usually easy to harness.  It is generally very portable.

Execution Issues - There are sometimes while() loops in device driver code which can cause the software to hang in a SIL environment. If the execution hangs, break using MSVC and look for an infinite loop. Use conditional compilation as needed to prevent the software from staying in the loop.

Related Topics:

Using VMCs

Debugging SUT Applications Using MxVDev and Visual C++

Harnessing Application Code for Testing

Tips on Stubbing

Tips on Porting

Execution Model

C Portability Guidelines

Visual Studio and MxVDev