1 Problem Statement and related work 1.1 Solar Orbiter Mission
Solar Orbiter  is a planned Sun-observing satellite, under development by ESA and is scheduled to be launched in January 2017 as baseline. At its closest point, the spacecraft will be closer to the Sun than any previous spacecraft, almost one-third of the Earth’s distance from the Sun. Because of the proximity of the Sun, the spacecraft must withstand powerful bursts of atomic particles coming from the solar atmosphere. From an on-board software designer perspective, it is essential to look out for permanent soft errors resulting from latch-up failures in SDRAM/EEPROM memories. The Space Research Group (SRG) of the University ...view middle of the document...
The classic approach for developing this kind of software has been to design the hardware, make a physical prototype, write the code, and then integrate the hardware and software. This methodology is nowadays too slow and calls for an alternative to the traditional software-after-hardware design flow in order to get started with software development and testing before the hardware is ready. To shortcut these issues the SRG has developed Leon2ViP, a LEON2 virtual platform with fault-injection capabilities, which has been built around SystemC/TLM2 interfaces given previous experiences with LEON3 systems . The overall ICU hardware/software co-design is described in .
A key point of the proposed framework is that it enables the work of the design and verification teams to be decoupled. As a design principle, TLM2 code that implements system components like Instruction Set Simulators, memory modules or SpaceWire network interfaces should contain just functional code in order to emulate the behaviour of the component. All fault injection code employed to emulate memory stuck-at faults must be applied in TLM2 transaction interfaces and not embedded in the models code. This leads to the necessity of intercept TLM2 calls to the memory modules in order corrupt data read or written from/to memory or peripherals.
The interception library presented in this work is not intended to validate the Leon2ViP virtual platform itself. In fact, the library is part of the virtual platform and has been developed to help in the ICU boot software development and testing of the basic recovery mechanisms in those cases when nominal boot sequence is not possible. It has been also used in the co-design of the SpaceWire core used for communications from/to the spacecraft.
Although the interception library has been developed specifically for the Leon2ViP virtual platform, it can used as a separate instrument in order to insert wrappers in TLM2 designs. What these wrappers are used for is up to the library user. In section 4, shows an example of how the wrapping library has been used to insert a fault injection wrapper in order to simulate stuck-at zero faults in memory access. The goal is to verify the correctness, according to the specifications of the software that runs on the virtual platform.
1.2 Paper contribution
This paper presents the results of attempting to provide a generic framework that provides dynamic binary instrumentation to TLM2 models. The approach is based on the mechanism used by C++ to implement late binding in virtual method calls. Our targeted application is the Leon2ViP virtual platform.
To our knowledge, this is the first library using C++ virtual table hooking as dynamic binary instru- mentation technique in order to intercept TLM2 socket primitives. The basic idea was introduced in  and in order to to validate the approach a few code snippets specifically tailored for Microsoft VisualC++ compiler was given. This work presents a...