Search Results

The development process of space mission software has to go through numerous steps, from early dimensioning factors at system level (e.g. energy to be consumed by a system, weight of equipment) to the description of low-level software concerns (tasks period, etc.). Most of the time, mission components are taken or derived from existing projects and use well-known best practices: hardware and software concerns are designed from a set of existing components, and are usually well tested and documented. However, teams, with different technical backgrounds, and development approaches, achieve the design. This adds incidental complexity to the design of a common architecture and its verification. Consequently, even if design of new systems is close to existing ones, the recurring key challenge is to reconcile the different views built by these teams, and to ensure that all properties are preserved and validated.

An increasing number of spacecraft missions have very stringent requirements for thermal stability to avoid thermally driven noise from affecting the main observables. For example, it may be necessary to reduce temperature fluctuations in the neighbourhood of the instrument below micro-Kelvin (μK). Consequently, the influence of fluctuations in boundary temperature or internal power dissipation on temperature at the instrument detector must be precisely evaluated. Thermal stability requirements are usually expressed as an upper limit on the linear spectrum density (LSD) of temperature fluctuations. This indicates the strength of the response to a perturbation of a given frequency, and is usually stated in units of K/√Hz. The LSD can be estimated by running a succession of transient simulations and applying Fast Fourier Transforms techniques, but this method is time-consuming and has numerical limitations.

The Automated Transfer Vehicle (ATV) Thermal Control System (TCS) has the task to ensure the required internal environment at level of pressurized module and to thermally control the not pressurised modules and installed equipment, using passive and active control means, in response to the relevant applicable requirements. The ATV vehicle is assially subdivided into three main modules: the Integrated Cargo Carrier (ICC), the Equipped Avionics Bay (EAB) and the Equipped Propulsion Bay (EPB). Each of these modules present elaborated and specific thermal design solutions, to satisfy the different required operative tasks. The extensive thermal analysis campaign performed at ATV vehicle level and in progress for the next Qualification Review (QR) to justify and support the thermal control design solutions and verification status is described.

ESARAD is an integrated suite of analysis tools for thermal radiative analysis. The suite provides modules for: • Geometry Definition; • Calculation of view factor, radiative exchange factor and solar, albedo and planet flux results; •Visualization of models in orbit with pre- and post-processing of radiative and thermal results; • Reporting of all aspects of the model; and • Generation of Input Files for Thermal Analysis tools. ESARAD is driven by a fully developed GUI, providing the user with a simple, intuitive windows, menus, forms interface to all its features. A modern, block structured language can also be used to run ESARAD. This gives the advanced user great power and flexibility to perform the most complex analyses. ESARAD was designed and developed between 1988 and 1991 to replace the VWHEAT software used by ESA at that time.

The Columbus Orbital Facility is being developed as the European laboratory contribution to the United States' led International Space Station programme. The need to exchange thermal mathematical models frequently amongst the Space Station partners for thermal analyses in support of their individual programme milestone, integration and verification activities requires the development of a commonly agreed and effective approach to identify and validate mathematical models and environments. The approach needs to take into account the fact that the partners have different model and software tool requirements and the fact that the models need to be properly tailored to include all the relevant design features. It must also decouple both programmes from the unavoidable design changes they are still undergoing. This problem presents itself for both active and passive thermal interfaces.