ESA - Software engineering and standardisation

About us

Software Engineering and Standardisation

Software life cycle

Overview System-Software co-engineering Requirement engineering and modelling

Design

Automatic code and test generation Compiler environments Schedulability analysis

Software building blocks

Overview Generic architectures Operating Systems Middleware Fault detection, isolation and recovery Application Building Blocks Personal digital assistants in space

Software standardisation

Overview Board for Software Standardisation and Control (BSSC)European Cooperation for Space Standardisation (ECSS)

Archive

Historical activities

Services

Useful links Contact us

FOR SECURITY REASONS, ALL LINKS TO THE ftp.estec.esa.int SERVER ARE DISABLED. YOU MAY REQUEST RELATED DOCUMENTS TO bssc@esa.int

Design

Once proper requirements (at system/customer level [Requirement Baseline] and at software/supplier level [Technical Specification]) are available, the design can start. In a waterfall lifecycle, the design will start after approval of the software/supplier requirements, whereas in a spiral one, a prototype design will continuously follow each requirements step.

The design can be performed in two steps, an architectural design and a detailed design. The architectural design is part of the technical specification as a 'top-level architecture'. The detailed design is part of the development.

Design methods

The use of a design method is required by the software standards. It gives a more abstract view than the code itself and allows a proper hierarchical organisation. The design method selection may depend on a modellisation language used for the requirements.

The traditional space design methods are HOOD4 and HRT-HOOD3, where HOOD4 is used on ground and (HRT-)HOOD3 on board. HOOD4 is also largely used on-board Eurofighter and Airbus. Other design methods are also used:

UML and packages, generally after a UML requirement modellisation. In particular HRT-UML is an adaptation of UML aiming at keeping the design engineering qualities of HOOD. The method has been assessed against the AOCS Framework by an ESA trainee. HRT-UML is evolving towards a profile of UML 2.0
an HRT-UML tool is available
methods allowing for the expression of the variability of an application domain, and used for generic architectures: design patterns, features, aspects
the behavioural languages (SDL, Lustre, Esterel)

The design methods generally allow for automatic code generation, from the generation of templates (for example, UML) to the complete code generation (behavioural language) or code configuration (features and aspect weaver). (HRT-)HOOD allows for the generation of templates and, if the pseudo-code has been filled in the design, for full code generation.

Last update: 20 March 2007

Send this page to a friend

More information

Introduction to HRT-UML (pdf)HRT-UML Brochure (ppt)UML based notation for HRT (pdf)A UML2 profile for HRT (pdf)A case study for HRT-UML (pdf)HRT-UML assessment (pdf)HRT-UML assessment slides (ppt)

HOOD