Terma.com uses cookies and the like for the purposes of statistical analysis, improving the friendliness and usability of our website, tailoring content to your interests and engaging with social media. By visiting our website, you consent to our and third party use of cookies as described in our privacy policy.

Read about Cookies

Software Validation Facilities

Software Validation Facilities comprise facilities to examine software execution in its target processor environment. The activities include features to support debugging and analysis of software performance. Software Validation Facilities are especially developed to support independent validation of embedded software.


Introduction

The independent validation and certification process of software requires elaborate facilities to examine the software execution in its target processor environment. The aim is to ensure that software performance will not lead to unacceptable system behavior in terms of mission criticality.

Within Terma's Software Validation Facilities, it is possible to test the robustness of flight software in scenarios that would be costly or potentially dangerous as part of an exhaustive test program.

XMM (image courtesy: ESA)

For these purposes, Terma has developed and used Software Validation Facilities (SVFs) for a range of satellite projects.

Terma has provided SVFs to a variety of ESA missions, including:

  • Herschel/Planck
  • Mars Express
  • XMM
  • Integral
  • Rosetta
  • Metop
  • Envisat.

Benefits

MarsExpress (image courtesy: ESA-D.DUCROS

Software Validation Facility systems offer simulated real-time performance with one-clock-cycle time resolution. This feature ensures a fully correct timing relation between the on-board software under test and its environment. Thus, it is possible, functionally and timing-wise, to simulate accurately the behavior of any complex device.

Together with the prime contractor, Terma defines a number of scenarios that may potentially lead to mission failure. They may be derived top down from operational situations, or they may be defined bottom up from perceived software or subsystem failures.

In the SVF, the software is embedded in dynamic system simulations allowing the realistic reproduction of a flight scenario. The software is subsequently executed to substantiate that no failures occur that would be detrimental to an acceptable system performance. 


Functionality

An SVF configuration is highly flexible, consisting of a Sun Unix work station and a VME crate hosting one or more target emulator boards. The two are connected via a bus coupler kit, consisting of a special VME board mounted in the VME crate, an Sbus card mounted in the workstation, and a cable connecting the two. 

An SVF may be located conveniently and used in a normal office environment. With the Sun work station connected to a network, it may also be used remotely, utilizing normal Unix facilities such as remote login, remote X11 display, etc.

The basic part of the SVF host software consists of three Unix processes: the generic process "Target Emulator Server" which encapsulates and synchronizes all target emulator access, the main user control interface "User", and the environment simulation control interface "EnvSim".

Rosetta (image courtesy: ESA)

A main aspect of the SVF design is to establish a well-defined "point of control" from the user's perspective. This may be at: 

  • The Flight Software execution with the Target Emulator process
  • The User process command interface
  • The EnvSim process command interface. 

The Target Emulator process is at the core of the test. Together with logging of commands issued by the software validator, the overall SVF synchronization strategy supports subsequent and accurate "replaying" of test sessions at any given point in time.