46th International Conference on Environmental Systems ICES-2016-394 10-14 July 2016, Vienna, Austria

STAMP: data acquisition system for large-scale thermal

tests

Johannes N. Guijt1, Alize E.H. Pistidda

2, and Pierre-Arnaud Ansel

3

TERMA B.V., Leiden, 2316XG, the Netherlands

In this paper we present STAMP, a software system to conduct large-scale thermal tests. Thermal testing

requires coordination of numerous instruments, data sources, control circuits, and outputs over long periods

of time. Software to do this must meet high requirements:

• Reliability: a failure in the software infrastructure may have costly consequences and must be avoided.

• Capacity: the software must be able to

o control hundreds of instruments,

o acquire tens of thousands of channels, and

o display data on dozens of monitoring screens.

• Flexibility: the software must be able to adapt to customer requirements.

• User friendliness: (parts of) the software will be used by facility customers, who typically cannot spare

much time for training during the hectic period of test preparation.

• Partitioning: user access to specific functions and data must be controlled.

STAMP meets all these requirements.

Nomenclature

CPC = Common Presentation Client

DCL = Device Command Language

DMZ = Demilitarized Zone

GPU = Graphics Processing Unit

OLE = Object Linking and Embedding

OPC = OLE for Process Control

PSU = Sower Supply Unit

QCM = Quartz Crystal Microbalance

STAMP = System for Thermal Analysis, Measurement, and Power supply control

VISA = Virtual Instrument Software Architecture

I. History

STAMP1 was originally designed as the new Data Handling system at the ESA Test Centre in ESTEC in the

Netherlands. Development started in 1998 and production usage began in 2000. Since then it has been successfully

used to test dozens of spacecraft, such as METOP, Integral, SMOS. GOCE, Rosetta, ATV, Galileo, and

BepiColumbo. Its 18 years of development have resulted in it being a powerful toolset for thermal testing.

Despite its age, STAMP is kept up to date with modern technology, supporting the Unicode character set, IPv6

networking, anti-aliased and GPU-accelerated rendering, touch screens, and smartcard login. It is available in 32-bit

and 64-bit versions and runs on Windows (any version newer than Windows XP with Service Pack 2) and Linux.

II. Design

STAMP is designed as a series of separate applications, each with a specific purpose and organized in a client-

server configuration. In a typical STAMP system, there are two servers, configured in a hot failover configuration,

and dozens of clients, each with a specific task (such as data acquisition, PSU control, or monitoring). Normally

there will be at least three roles: administrators (who have full access to the system), operators (who have access

only to operational parameters), and customers (who usually only have the ability to monitor data). Other roles can

1 Senior Software Engineer, Space Division, hg@terma.com.

2 Software Engineer, Space Division, alpi@terma.com.

3 Department Manager, Space Division, par@terma.com.

International Conference on Environmental Systems

2

be defined as needed. For example, one could easily define an advanced customer role for customers who may set

alarm limits on customer sensors, or directly control specific power supplies.

A single STAMP server may contain multiple test campaigns, which can be in different stages: under

preparation, being executed, or completed. Multiple test campaigns can be executed simultaneously.

The design of STAMP is guided by the following philosophies:

A. Recoverability

Thermal tests may have a duration of many weeks. During this time problems may occur (networks break, cables

get dislodged, instruments fail, etc.). A major development goal is to be able to recover from such situations,

preferably automatically, or if that is not possible, to at least provide enough information to the operator to allow

him to quickly detect, assess, and correct the situation.

Individual STAMP applications run independently from each other, so if one application experiences a failure of

some kind (due to hardware problems, software bugs, etc.) it will not disrupt other running applications. All

applications communicate with the server, which is normally configured as a cluster in hot failover configuration, so

even if one machine fails, the other takes over immediately.

STAMP applications can run for any amount of time without a server. In this situation data acquisition continues

normally, and acquired data will be stored and processed once server access is restored.

B. Flexibility

STAMP is highly configurable in order to meet a wide range of test requirements. No element of the test

configuration is fixed: the instruments that are used, the number of sensors, selected scan rates, the number of scan

cycles, etc. are all operator-defined. A test configuration can be changed at any time before or during the test. All

configuration changes are logged, and can be queried to provide traceability.

A powerful formula system is available that allows almost any kind of calculation to be expressed. All data is

stored as it was acquired; all calculations take place in the monitoring subsystem. Formulas, like other

configurations, can be changed during the course of a test as needed.

New applications can be added to STAMP on the fly (even while a test is ongoing), allowing support for new

instruments to be integrated without changing the existing system.

C. Scalability

STAMP was designed to work (and works best) on a large network containing dozens of machines and

controlling hundreds of devices, but it will run on a single computer acting as server, data acquisition station, and

monitoring station all in one. This allows it to be used for smaller tests as well.

D. Soft limits

The software is limited only by available memory and CPU speed. There are no hard limits on the number of

configuration items (such as sensors or scan cycles), the length of text fields, acquisition speed, the number of

curves displayed in a graph, the number of graphs on screen, etc. Of course this does not mean it is practical to have

millions of sensors, or thousand-character sensor names; the choice of what configuration is acceptable is left to the

operator configuring the test.

III. Data acquisition

The data acquisition subsystem is responsible for acquiring data from a host of devices. For each device a driver

program must be written; such programs can be added to existing programs on the fly, without changing existing

software or even interrupting a running system.

Acquisition programs currently exist for numerous digital voltmeters, cryostats, spectrometers, quartz-crystal

microbalances (QCM), home-grown instruments (TempDAS and NgDCU), and for other software systems (such as

OPC). STAMP can also exchange data with other software systems through a network socket. This ability is bi-

directional, and allows for both historical and real-time data to be shared. For more detail, see Ref. 2.

Some acquisition modules have an optional user interface component that allows additional control over the

instrument from the control room. This is necessary for certain classes of instruments, like cryostats (which offer

control over pump settings, output setpoint, temperature profiles, etc.).

Data can be acquired from a new source in one of three ways:

International Conference on Environmental Systems

3

1. By writing a new scanner driver in DCL, an XML-based scripting language for VISA communication. This

approach allows any VISA-compatible instrument to be connected to STAMP using a simple scripting

interface.

2. By writing a new acquisition program in C++. This method is appropriate for instruments or systems that are

not VISA-compatible.

3. By importing the data through a socket. This approach may be used when the remote system can be modified

to send data to STAMP on its own terms, without STAMP scheduling scan cycles.

STAMP supports per-channel timing and scanner configuration. In addition, multiple independent scan cycles

are supported. If two (or more) scan cycles clash, STAMP will automatically choose a solution that satisfies all

constraints as much as possible.

All data is stored as it was acquired. Data manipulation (such as unit conversion or calculation of virtual sensors)

occurs in the monitoring subsystem, therefore the raw measured data can be retrieved at any time.

IV. Monitoring & analysis

The presentation subsystem is responsible for monitoring and analysis. Numerous types of presentation are

available; most of these are part of a single application called the Common Presentation Client (CPC).

The Remote Client is mostly identical to the CPC, but can be used from outside the test facility.

E. The Common Presentation Client

Data is presented to the user by the Common Presentation Client (CPC). The CPC contains numerous types of

presentations, including powerful graph presentations, table presentations, alarm generation, and 2D and 3D

synoptics. Presentations are fully interactive, and can be set up on an ad-hoc basis, or predefined and stored for later

use and sharing with other users. Most presentations support display of both real-time and historical data.

The CPC is the main interface used by facility customers; special care has been taken to make its basic

functionality straightforward to discover and use.

Figure 1: CPC showing two graphs, a table display, and an alarm display

The rest of this section briefly describes the available presentation in the CPC.

International Conference on Environmental Systems

4

1. Graph presentations

The main workhorse for presenting data in the CPC is the graph presentation. It supports multiple vertical scales,

linear and logarithmic display, user-defined markers, display of test phases and the logbook (showing test events on

the timeline of the graph), and user-defined colors and line styles for the curves. Built-in tools are provided to

determine trends, and for easy measurement of time ranges, value ranges, and slopes. To accommodate the high

volume of data frequently displayed in graph displays, GPU-acceleration is available for improved rendering

performance4.

The comparison graph allows comparison of measured data to a predefined set of values. These values are

themselves curves, that are overlaid on the normal data. The prediction curves can be moved in time with respect to

the measured data to allow easy comparison.

Other available types of graph presentations include the data distribution graph (which shows how data is

distributed over a range), the scatter graph (showing correlation between channels), and the waterfall graph

(showing the evolution of many channels over time).

The logbook contains a list of events deemed interesting by the users. Events can either be a single timestamp, or

a time range, and willbe displayed as additional information in graphs, making it easy to see correlations between

test events and the effect they had on the measured data. There is a separate logbook for each user group.

2. Table presentations

Two types of table presentation are available: one that shows many sensors at the same timestamp, and another

that shows the values of one or more sensors over a time range.

3. Alarm generation

The alarm presentation generates an alarm when an alarm condition is met. Alarms can be set for low and high

warning levels, low and high alarm levels, low and high slopes, and on extrapolated data. When an alarm occurs,

audible and visible warnings are provided, and a message may be logged to a file or line printer.

The throughput monitor generates an alarm when a sensor has not received an update for a certain amount of

time. This allows end-to-end monitoring of the entire system and provides a basic but useful real-time system health

check.

4. Synoptic presentations

There are two synoptic presentations: one that shows sensor values on a flat drawing, and one that shows a 3D

model of the spacecraft and facility, with correct orientation and associated sensors.

Figure 2: 3D synoptic, showing the SMOS spacecraft in the Large Space Simulator at ESTEC

4 This requires a CUDA-capable GPU (CUDA is a standard for non-3D computing using a GPU).

International Conference on Environmental Systems

5

The 3D renderer is highly efficient and can deal with large models consisting of millions of polygons. Our

largest model today has over 4 million polygons and is displayed at a steady 60fps using a recent GPU.

Data is imported using a 3rd

-party library called “assimp”, which offers support for a great number of import

formats, including fbx, 3ds, and dxf. Typical CAD formats can be converted using Polytrans (a commercial 3rd

-party

tool for converting 3D formats). Polytrans has modules for numerous CAD formats including CATIA. Regrettably,

importing 3D models remains a tough problem: many of the file formats are not well-documented, and as a result

the tool chain is not always able to properly convert or import a model.

5. Interfaces to other software

Historical data can be extracted from STAMP using the Excel presentation. This presentation stores data in a

comma-separated value file that can be directly imported into Excel and other applications.

The Connector presentation transmits data (both historical and real-time) over a socket to any compatible

application. While this is not a presentation intended for human users, its presence in the CPC means it is also

available in the Remote Client (see below), allowing it to be used to securely stream data in real-time to systems

running in off-site locations.

6. Other presentations

The Equilibrium presentation determines whether thermal equilibrium has been achieved by applying one of

several stability criteria to a set of sensors.

The QCM presentation determines a value for chamber contamination by interpreting the output of a quartz-

crystal microbalance in a specific way.

F. The Remote Client

The Remote Client offers the same features as the CPC, but can be used from outside the test facility. It supports

both online operation (where measurement data and configuration updates from the Test Center are received as they

occur) and offline operation (where only data and configuration that was received earlier is available for analysis).

To support offline operation, the Remote Client maintains a local copy of the system database. The Remote Client

can be switched between online and offline mode as needed. When switching to online mode, the local database will

automatically be synchronized with the database on the server.

To use the Remote Client, an intermediate server must be set up that can be reached from both the outside world

and the test facility itself. Data from the test is pushed to this server (this connection is strictly one-way), and from

there distributed to connected Remote Clients. The following image shows this setup, with security for the test

facility guaranteed by two firewalls and strict access rules:

Figure 3: Remote access setup

The Remote Client uses an encrypted connection secured with a password and a client certificate to connect to

the intermediate server (a client certificate demonstrates to the server that the client has the right to connect, and can

be revoked on the server if it is compromised).

A fully offline mode is also possible. In this mode the local database is created internally by the Test Center and

transmitted to the user using some other medium. The test campaign itself is never copied to the Teletest Server, and

thus never exposed to the world.

International Conference on Environmental Systems

6

G. Formula system

Acquired raw data can be manipulated using a comprehensive formula system, which allows for unit conversion,

calibration correction, data reduction, and other desired operations. The formula system supports almost a hundred

functions and operators (including standard conversions for thermocouples and PT100 platinum resistor

thermometers, and functions for table lookups and polynomial evaluation).

To display a single value on screen, up to four conversions may optionally be used:

1. The raw value of a compensation sensor is converted to a useable unit for further calculation (for example,

the resistance of a PT100 may be converted from Ω to °C).

2. The raw value of a (non-compensation) sensor is converted to a useful unit for monitoring (for example, the

value of a thermocouple may be converted from mV to °C, taking into account the PT100 temperature from

the previous step).

3. The value from the previous step is converted to a different engineering unit in the same class (for example:

from °C to K).

4. The internal binary value from the previous step is translated into a human-readable value. The output can

be a number with a certain number of digits in natural or scientific format, or it can be interpreted as a set of

bit fields that represent specific states such as “open” or “closed”. Additional formatting codes can be added

to the final human-readable text to add text effects (such as bold or italic) and colors.

The following diagram shows the full conversion pipeline as described above. Note that each step in the pipeline

is optional.

Figure 4: Conversion pipeline

The formula system can also be used to define virtual sensors. Virtual sensors do not have an underlying

acquisition channel, but are calculated from other (real or virtual) sensors. Example uses of virtual sensors include

summary values (for example, to display the average of a group of sensors), as filters (filtering out peaks in other

sensors), to calculate trends, or to calculate values over a time range.

Virtual sensors can be used in all places where normal (“real”) sensors are used: in presentations, as

compensation sensor, in other formulas, etc.

A formula wizard is available to help quickly define common types of virtual sensors.

H. Multi-user

After logging in, the user is shown only those sensors, test events, 3D models, etc. to which he has been granted

access rights. As many users (each with a unique set of access rights) can be defined as necessary.

Users can log in in three different ways: a workstation can be configured to be automatically logged in as a

specific STAMP user, the STAMP user can be derived from the Operating System user (thus ‘borrowing’ the user

from the Operating System), or a smart card system can be used.

V. Power supply control

The power supply (PSU) control subsystem of STAMP controls any number of PSUs in one of six control

modes. Control has been logically split over two components: a command program that provides all necessary

International Conference on Environmental Systems

7

information to the operator, and allows him to enter high-level control parameters, and an interface program that

implements the operator commands into low-level PSU commands. Usually, the command programs are running in

the control room and the interface programs run on separate computers next to their PSUs which are spread over the

facility.

A. Power supply command program

The command program provides a high-level overview of all controlled PSUs. This overview can be rearranged

using the mouse, allowing the operator to group PSUs with the same general behavior together in the display.

Double-clicking a PSU brings up a window containing detailed information regarding that PSU: its control mode,

setpoint, measured output level, etc. as well as a graph showing its recent behavior.

Figure 5: Command Process showing overview window (left) and detail window (right)

Multiple command programs can be configured, each responsible for a specific subset of PSUs. This allows

control to be spread over multiple screens, or shared between multiple users, each with clearly delineated

responsibilities.

PSUs can be controlled in one of six control modes. These are:

• fixed setpoint,

• thermostatic mode (the setpoint is chosen from a group of four, based on the value of a reference sensor),

• PID mode (the setpoint is calculated based on the value of a reference sensors),

• profile mode (the setpoint is determined by a predefined profile),

• K-mode (an entire group of PSUs is commanded using a single value), and

• Formula mode (the setpoint is defined by a formula).

The formulas used in formula mode may contain references to sensors. Since STAMP can acquire data from

other software systems, this allows (for example) EGSE systems to transmit setpoints to STAMP, with STAMP

supplying only the actual PSU interfaces. Logging and range checking still apply to such setpoints, providing a high

degree of safety and traceability.

International Conference on Environmental Systems

8

I. Power supply interface programs

Interface programs translate operator commands into actual PSU commands. While intended to run without

operator interaction, each interface program also has a local command console that allows control over the

connected PSUs in case of network failure. This local control only supports fixed setpoints; other control modes rely

on receiving regular input from the server and are therefore unavailable.

Interface programs for 13 different types of PSUs are currently available, and new ones can be added to the

system without having to change existing code.

VI. System monitoring

System operation is monitored using a pair of separate applications: the System Alarm Monitor and the System

Process Monitor. The Alarm Monitor shows all warnings generated by STAMP in a central location. The Process

Monitor tracks the current status of all STAMP applications, generating an alarm when an application terminates

prematurely or gets disconnected from the network.

VII. Current users

STAMP is currently in use at ESA’s ESTEC facility in Noordwijk, The Netherlands, and at IABG in Ottobrunn,

Germany.

European Test Services (ETS) B.V. operates the Test Centre of the "European Space Agency" (ESA) based in

the Netherlands. ETS is active in the domains of Mechanical testing, EMC testing, Thermal testing, Altitude

simulation and more. Established in the year 2000 as a common subsidiary company of IABG mbH (Ottobrunn,

Germany) and Intespace SA (Toulouse, France), ETS has become one of the major providers of test services for the

European aerospace industry.

The IABG Space Centre is one of the test centres coordinated by the European Space Agency, ESA. As a leading

European technology, IABG provides science service, engineering tests and analyses using state-of-the-art

technology to simulate real operational conditions such as the mechanical and thermal loading at lift-off and in orbit,

operation in vacuum and stressing during re-entry into earth’s atmosphere.

The versions of STAMP at IABG and ESTEC are identical, with one exception: IABG wants to have the ability

to have multiple power supply windows open in the Power Supply Command Process, while ESTEC specifically

does not permit this (citing possible operator confusion). The desired behaviour is selected using a field in the

database that is not accessible to normal users.

J. Lessons learned

As developers, we learned a few important lessons over the years:

• Being able to trace the steps taken by a user, and the results of those steps, is vitally important when

tracking down problems (and far more so when the user happens to be in another country).

• Warning messages must contain enough information to allow the user to respond correctly.

• Providing the right warnings is important and difficult. Many operations in STAMP occur on a cyclical

basis; it is important to avoid flooding the users with unavoidable recurring warnings.

• Being able to (automatically) recover from a problem is actually more important than avoiding the problem

altogether.

K. New features in STAMP v3

For people familiar with earlier versions of STAMP, we present a list of new features in STAMP v3 (which is

the current version):

• IPv6: as the number of IPv4 addresses has dwindled to almost zero, the world will have to switch to IPv6

soon. STAMP fully supports IPv4 and IPv6.

• Unicode: customers from non-ASCII parts of the world may desire to use text in their own language.

STAMP supports this by using unicode text throughout.

• Internationalization: numbers and dates are now displayed in the format defined by the operating system.

• 64-bit: STAMP is available in 32-bit and 64-bit versions. Installations with a mix of 32-bit and 64-bit

applications are supported.

• Touch screens: as touch screens become more ubiquitous, STAMP has added support for controlling the

software using touch.

International Conference on Environmental Systems

9

• GPU-accelerated rendering: rendering a graph with millions of data points is time consuming. STAMP can

use GPU-acceleration to improve rendering performance.

There are also improvements in the formula system, performance, and overall user friendliness.

L. Future directions

While development on a day to day basis is driven by customer requests, a tentative list of future goals might be

the following:

• Mac OSX support, at least for the Remote Client (allowing customers to work on any machine of their

choice).

• Additional driver support for Linux. Any STAMP application using either GPIB, RS232, or MIL1553

drivers, is not currently available on Linux (this means almost all scanner and power supply drivers); we

would like to change this.

• Improved comparison tools. The current comparison graph lets us compare predefined data to measurement

data. We would also like to be able to compare measurement data to measurement data from a different

time.

• Combined tests. This would allow us to show data from multiple tests in one presentation. In combination

with the previous feature, it would be possible to compare data from a previous test with the current test.

• Scripting. We would like for STAMP to be fully scriptable; that is, that any action that can be taken by a

user can also be performed automatically. This, however, is an extensiveamout of work that needs to be

properly discussed and designed on paper to avoid introducing new safety issues.

VIII. Conclusion

STAMP is a mature solution for large scale thermal testing that has been refined and improved over a period of

almost two decades. Its powerful formula language and high degree of configurability allow for a flexible approach

to test configuration, and its modular architecture allows for new capabilities (in particular, in the areas of

acquisition, PSU control, and monitoring) to be added without changing existing (and previously validated)

components.

IX. Acknowledgments

Many people have contributed ideas for improvement over the years, and it is thanks to their efforts that STAMP

has become the powerful tool that it is today. In particular, we would like to thank Mr. K. Debeule (ESA), Mr. A.

Popovitch (ESA), Mr. J. van der Meulen (ETS / Intespace), Mr. K. Buczek (IABG), and Mr. D. Füß (IABG) for

their input and support.

References 1 STAMP, System for Thermal, Analysis, Measurement, and Power supply control, software package v3.1.6,

Terma BV, Schuttersveld 9, 2316 XG, Leiden, the Netherlands, 2015. 2 Pistidda, A.E.H., Ansel, P.-A., and Guijt, J.N., “Integration of STAMP thermal testing software with spacecraft

checkout (EGSE) systems,” ICES2016, paper ICES2016-409.