r bulletin 111 — august 2002

Introducing ECSS Software-Engineering

Standards within ESA
– Practical approaches for space- and ground-segment
software

M. Jones & E. Gomez

Ground Segment Engineering Department

A. Mantineo
Quality Office
ESA Directorate of Technical and Operational Support, ESOC, Darmstadt, Germany

U.K. Mortensen
Electrical Engineering Department
ESA Directorate of Technical and Operational Support, ESTEC, Noordwijk,
The Netherlands

Why a new software-engineering standard? engineering standard would become the one to
ESA has had a highly successful software- be used in ESA software projects. Shortly after
engineering standard, ESA PSS-05, since this decision, ISO published a new international
1984. PSS-05 was prepared by ESA’s Board software-engineering standard, ISO/IEC 12207
for Software Standardisation and Control (Information Technology, Software Lifecycle
(BSSC), which was established in 1977, when Processes, 1995), which is now the leading
the importance of software standards for the standard in this field. The ECSS software-
proper conduct of complex or critical space- engineering standard ECSS-E-40, which first
software projects was realised. PSS-05 appeared in 1999, is based on ISO 12207. In
fact, ECSS-E-40 tailors ISO12207 specifically
In June 1994, the ESA Council adopted a resolution that confirmed the for space projects.
Agency’s commitment to transferring the existing system of ESA
space standards to a new set of standards that were to be prepared The introduction of this new standard
by the European Cooperation for Space Standardization (ECSS). For represented a further step in the
software engineering, this has meant moving from the ESA PSS-05-0 ‘Europeanisation’ of the way of working in the
to new software standards: ECSS-E-40 for software engineering and Agency. In fact, an objective was to produce a
ECSS-Q-80 for software product assurance, both of which are based standard to be used throughout the European
on a new international standard, ISO/IEC 12207. In addition, to cover space business, i.e. by Industry and across the
the full scope of the old standard, it is also necessary to use the ECSS space agencies within Europe, superseding
management standards (the ECSS-M series). Adoption of a new agency-specific standards such as PSS-05. In
standard is a major change and one that has to be undertaken with this way, the problem of a given company or
care and so this article describes the measures that were taken to consortium having to follow different standards
ensure a smooth transition, both at ESTEC for space-segment depending on which agency it is contracted to
software and at ESOC for ground-segment software. for any given development is avoided: the
ECSS standards thus provide a common
backbone.
appeared in Issue 1 in 1984, followed by Issue
2 in 1991. The BSSC also wrote a set of guides This European approach also had consequences
to provide more detailed assistance in using for ESA’s BSSC: whereas formerly the BSSC
PSS-05. Both the standard and the set of established and maintained software-
guides were published as books. engineering standards, now this responsibility
is transferred to the ECSS. Of course, the
However, the Council decision in 1994 meant BSSC has in practice been involved in the
that no further issues of PSS-05 would be relevant ECSS Working Group and subgroups
published and the new ECSS software- – for example, one of the BSSC Co-Chairmen

132
 ecss software-engineering standards

is also convenor of the ECSS-E-40/ ECSS-Q- – ground segments comprised of all of the
80 Working Group. Within ESA, the BSSC still ground facilities needed to operate each
plays an important role, since it has to ensure mission.
that the new software-engineering standards
are introduced and applied properly and that Software is pervasive throughout the whole
tailoring methods and ESA implementations of ‘product tree’ of any space programme:
the ECSS standards are available as needed. It Figure 2 shows a typical space system
also deals with standardisation aspects such schematically, with emphasis on the software
as coding standards that will not be covered by elements. The space segment has onboard
ECSS. The rest of the BSSC’s responsibilities computers, data-handling systems, attitude
remain unchanged, ensuring in particular that and orbit control systems, all of which contain
the standards are applied in ESA contracts, software. The ground segment has mission-
and liasing with the ESA’s Legal and Contract control systems, simulators, flight-dynamics
Departments on matters affecting software systems, mission-analysis tools, communications
intellectual-property rights. networks and ground-station data systems
such as telemetry and telecommand
The structure of the ECSS standards is shown processors, as well as ‘downstream
in Figure 1, from which it can be seen that there processing’ systems for payload data. These all
are three main branches: ‘Management’, contain software, often of considerable
‘Product Assurance’ and ‘Engineering’. It is a complexity.
characteristic of software engineering that it
involves all three branches of the ECSS Developing and maintaining this software in a
standards. disciplined way is a key to the success of any
space mission. Failure to do this can result in
Software in ESA expensive delays, and in the worst case in
ESA’s core business is the execution of space catastrophic failure. Following proper software
programmes, including: standards is one of the ways of keeping
– space segments comprised of spacecraft, software development under control and
payloads and launchers ensuring adequate quality.

ECSS-P-00 ECSS System ECSS-P-001

Standardization policy Glossary of terms

Space project management Space product assurance Space engineering

ECSS-M-00 ECSS-Q-00 ECSS-E-00

Policy and principles Policy and principles Policy and principles

ECSS-M-10 ECSS-Q-20 ECSS-E-10

Project breakdown structure Quality assurance System engineering

ECSS-M-20 ECSS-Q-30 ECSS-E-20

Project organization Dependability Electric and electronic

ECSS-M-30 ECSS-Q-40 ECSS-E-40

Project phasing and planning Safety Software

ECSS-M-40 ECSS-Q-60
Configuration management EEE Components

ECSS-M-50 ECSS-Q-70
Information/Documentation Materials, mechanical parts
Management and processes

ECSS-M-70 ECSS-Q-80
Integrated logistic support Software product assurance

Level 3 Level 3 Level 3

management Standards product assurance engineering Standards Figure 1. Structure of the
standards ECSS standards

133
r bulletin 111 — august 2002

Figure 2. Schematic of a Overview of ECSS-E-40 ECSS-E-40 is based on the customer–supplier

typical space system, with
ISO 12207 and ECSS-E-40 are based on a concept. As shown in Figure 3, this concept
the emphasis on software
elements defined set of processes. They define: may be applied recursively, as would typically
be the case for space projects with ESA as the
– requirements on those processes broken customer at the top level, and then a chain of
down into component activities customer–supplier relationships extending
– their expected inputs and outputs. downwards to the prime contractor and then to
the lower levels of subcontractors. Reviews are
They are in effect ‘standards for making the main interaction points between the
standards’, the idea being that this permits customer and the supplier.
suppliers to use their own standards, provided
that they comply with the requirements of The accompanying coloured panel is a brief
ECSS-E-40 or some tailoring of it defined by review of ECSS-E-40, outlining the required
the customer. ECSS-E-40 is available at the processes, reviews and documentation. It gives
Figure 3. Customer–supplier ECSS Web site: http://www.estec.esa.nl/ecss/, the correspondence to PSS-05 where
relationship
where its partner quality standard ECSS-Q-80 appropriate, for the benefit of readers familiar
Figure 4. Processes of and the ECSS-M standards may also be with that standard. Figure 4 shows the
ECSS E-40 and ECSS Q-80 found. processes of ECSS-E-40 and ECSS-Q-80.

...

Customer

Level n

Supplier Supplier

Customer Customer

Level n+1

H/W Supplier S/W Supplier

Customer Customer

Level n+2

H/W S/W S/W

134
 ecss software-engineering standards

ECSS-E-40 Processes
System Engineering
This is carried out by the customer and involves such activities as:
– system requirements engineering
– system integration
– system validation.

This is somewhat analogous to the PSS-05 User Requirements (UR) phase, but is more general in that it sees the software
as part of a system that put requirements on it – the surrounding system could be onboard hardware and other software
systems, and need not necessarily include a human user. In PSS-05, the UR phase was generally understood as a specific
activity occurring after the system definition, preparing the software development, but separated from the system activities.
In ECSS, this process is the same as the ECSS-E-10 Space System Engineering process, ensuring a better transition of the
requirements from system to software.

Software Requirements Engineering

This is carried out by the supplier and in essence involves:
– software-requirements analysis (roughly equivalent to PSS-05 SR phase)
– software top-level architectural design (roughly equivalent to PSS-05 AD phase).

The related review is the Preliminary Design Review (PDR).

Software Design Engineering

This is also carried out by the supplier and involves:
– designing of software items
– coding and unit testing
– integration
– validation with respect to the technical specification (equivalent of PSS-05 System Testing).

The related review is the Critical Design Review (CDR).

Software Validation and Acceptance

This comprises:
(i) Validation with respect to the requirements baseline: the milestone is the Qualification Review (QR), which is carried out in
the supplier’s environment and is often referred to as the ‘Factory Acceptance Test’
(ii) Software delivery and installation
(iii)Software acceptance: the milestone is the Acceptance Review (AR) and is carried out in the operational environment (like
PSS-05 Acceptance Test, AT). This is also referred to as the Site Acceptance Test (SAT), and may be preceded by a
Preliminary SAT (PSAT). Acceptance is carried out by the customer.

Activities (ii) and (iii) are analogous to the PSS-05 Transfer Phase.

Software Operations Engineering

This comprises:
– preparation of software operations procedures
– preparation of plans for operational testing (i.e. of new releases coming from the maintenance process)
– software operations proper
– user support, including what is usually called ‘first-line support’, e.g. help desk.

Software Maintenance
This comprises:
– software problem analysis
– software problem correction (software modification)
– re-acceptance (i.e. validation of corrections)
– software migration (cf. PSS-05 ‘adaptive’ maintenance)
– software retirement.

ECSS software maintenance is similar to PSS-05 Operations and Maintenance (OM Phase), but ECSS-E-40 places more
emphasis on migration and retirement, and separates first-line maintenance from software operations.

135
r bulletin 111 — august 2002

Reviews document this choice in the Software

The following table summarises the reviews Development Management Plan.
required by ECSS-E-40:
Comparison of ECSS-E-40 and PSS-05
Name Acronym Associated process The BSSC carried out a detailed analysis of
ECSS-E-40 and PSS-05, comparing in
System Requirements Review SRR System engineering particular the ECSS-E-40 processes with the
Preliminary Design Review PDR Requirements engineering PSS-05 phases, including process/phase
Critical Design Review CDR Design engineering inputs and outputs, and reviews. The main
Qualification Review QR Validation and acceptance conclusions were that PSS-05 mandatory
Acceptance Review AR Validation and acceptance practices cover about 70% of the ECSS-E-40
Operational Readiness Review ORR Software operations requirements. The analysis also identified
engineering ECSS-E-40 requirements not covered by
PSS-05-0 practices.

Software documentation Figure 6 shows a mapping of PSS-05-0 phases

Figure 5 shows the main categories of ECSS- to the ECSS-E-40 processes, including related
E-40 documentation. It is arranged in ‘folders’, reviews, reflecting the fact that a process
into which the various output documents are model can always be projected into a set of
aggregated. The main folders are: phased activities. Figure 7 illustrates the
– Requirements Baseline (RB) contrasting features of the two standards, the
– Technical Specification (TS) main ones being:
– Design Definition File (DDF) – process-based (ECSS-E-40) versus practice-
– Design Justification File (DJF). based (PSS-05)
– ECSS-E-40 is based on the notion of customer
The contents of these folders are built up in and supplier, while PSS-05 has no such
the course of the project, as shown in Figure 5. concept
The folders may, of course, be logical, i.e. they – ECSS-E-40 and ECSS-Q-80 apply to ‘product
may in effect be directories pointing to the software’, i.e. software that is part of a
documents they ‘contain’ rather than being space-system product tree and developed
physical folders. as part of a space project. They are applicable
to all the elements of a space system: the
Software life cycles space segment, the launch-service segment
The software life cycle defines the sequencing and the ground segment. By contrast, PSS-
and dependencies of the processes. As with 05 is general (it could apply to any software)
PSS-05, no particular life-cycle model is and applies to a software project
Figure 5. Main categories of imposed, but its selection is an essential – ECSS-E-40 allows the customer to ‘tailor’
ECSS E-40 documentation management activity. The supplier must the standard, i.e. the deletion of non-
applicable processes, activities or
tasks. Tailoring is specified in the
customer’s request for proposal,
and may involve additional unique
or special processes, activities or
tasks.

Transition from PSS-05 to the

ECSS set of software standards
In 1996, the BSSC issued an
information note to all ESA staff
providing information about the
planned transition. It also laid down
one general principle: it was not
required to apply ECSS-E-40
retroactively to projects already
using ESA PSS-05, and this still
holds true.

Applying ECSS software

standards to space-segment
projects
Spacecraft onboard software has
several features unique for the

136
 ecss software-engineering standards

Figure 6. Mapping of the

UR PSS-05 phases to the ECSS
SR E-40 processes
AD
DD
TR
OM

UR/R SR/R AD/R DD/R PA FA

PSS-05 phases
ECSS-E-40 processes Software Maintenance

Software Operations Engineering

Validation
and Acceptance

Design
Engineering

Requirements
Engineering

System
Engineering

SRR SWR PDR CDR QR AR

domain. Not least, it has a high level of criticality

for the spacecraft, since failures can cause loss Processes versus practices
of the entire mission. Unlike aircraft systems, for E-40 is based on ISO 12207
cf. PSS-05 is based on IEEE
example, no prototype flights can be made and SW standards
the software has to work correctly as soon as Customer/supplier relationship
the satellite arrives in orbit. Therefore, testing
and qualifying the software to ensure it will work
correctly ‘first time’ is a major challenge. E-40 is to be used with other M and Q standards
Because of avionics, power and mass cf. PSS-05 is a “one-stop” shop

constraints, onboard software is designed with

severe limitations on processing power and Tailoring versus mandatory and
memory. However, it controls and handles most Integration within the
recommended practices
system life-cycle (reviews)
of the electrical systems and the interfaces to versus software only
the onboard avionics, and therefore it belongs projects
to the technically difficult class of ‘hard real- Process outputs “files” versus
documents with strict tables of contents
time software’, with many processes running in E-40 addresses space system
parallel and response requirements in the product tree: PSS-05 is a general
microsecond range. Moreover, since a large software standard
and ever-increasing proportion of mission and
spacecraft functional requirements are
implemented by onboard software, its conventions as any other space-system Figure 7. Comparison of the
specification and design is strongly coupled development (SRR, PDR, CDR, etc.). main features of PSS-05 and
ECSS E-40
with the overall system-engineering activities of
the mission. The first use of the ECSS Software Engineering
standards was made as early as 1996. Since
This major expansion in spacecraft onboard then, the combination of ECSS-E-40 and
software functionalities occurred after the ECSS-Q-80 has been successfully applied to
1980s, when PSS-05 was written. Hence, in several tens of space projects, ranging from
producing the ECSS Software Standards, it full-size satellite projects (in Space Science,
was a priority to introduce and modernise the Earth Observation, and Navigation) to smaller
standards to take into account this evolution. R&D activities in the areas of onboard software,
Introduction of system-engineering processes Electrical Ground Support Equipment (EGSE),
and interfacing software-engineering activities analysis tools and algorithm development. The
to the overall system-engineering process are transition to the new set of software-
good examples of this. Another example is the engineering standards has been successful,
adoption of life-cycle milestones such that with no major problems vis-a-vis the ongoing
software developments follow the same space-segment developments.

137
r bulletin 111 — august 2002

Key factors in the successful introduction and Implementation aspects include, for example,
application were: document templates and advice on how to
– A strong commitment from the participating perform the necessary work, in addition to the
ECSS partners in producing very high quality ECSS requirements. It is also an initial tailoring
standards and with internal commitments for of the ECSS requirements for ground-segment
the integration into their respective business software developments. The SEMG has
processes. removed some requirements that were not
– Training material and introduction courses applicable to ground-segment development
both for those with previous experience with and has also introduced some missing ones,
other standards and for those entering the particularly in the areas of configuration
space market for the first time. management and software project management.
– The ECSS tailoring possibility, allowing Another example of the tailoring is the addition
adaptation of the requirements to individual of the Software Requirements Review (SWRR)
projects or domains. between SRR and PDR to provide a separate
review of the software requirements and
Applying ECSS software standards to facilitate continuity with established practice.
ground-segment projects at ESOC
An important feature of the ECSS software
The ESA Ground-Segment Software standards is that they may be tailored in
Engineering and Management Guide (ESA accordance with customer needs and project
GS SEMG) or system characteristics. The GS SEMG can,
At ESOC, the bulk of ESA’s ground-segment therefore, be further tailored (corresponding in
software is procured via frame contracts. effect to a tailoring of the ECSS source
Typically, there are several frame contractors in standards). The Tailoring Template, also
each discipline area (e.g. mission control published by the BSSC, is a companion guide
systems, simulators, flight dynamics) and they to the GS SEMG that provides guidance when
compete for work as it arises. PSS-05 has introducing further tailoring. Specifically, it gives
been applied for all such software procurement advice on the processes to be considered
and was made applicable in the relevant frame applicable within a given software-development
contracts. This led to a uniform approach to project. It clarifies the principles upon which
reviews and documentation across the various the tailoring process is based, allowing for the
contracts in any given area. The desire was to selection or waiving of some of the practices
continue this practice and avoid a situation described in the Guide. It does not constitute
in which different suppliers use different a specific tailoring of the GS SEMG as such,
implementations of ECSS-E-40. This is and therefore should not be considered or
particularly important for long-lived and referred to as contractually binding. However, a
complex infrastructures or generic software, tailoring resulting from it could be made
where several different contractors may be contractually binding.
involved.
The GS SEMG could be applied to any
Transition to the ECSS standards involves: development of ground-segment software for
– using a process-based standard instead of a a space mission. However, it is primarily
practice-based standard intended for use in ground-segment software
– coping with the distribution of the ECSS development at ESOC, where the GS SEMG
standard over many documents (E40, Q-80, will be referenced (i.e. made applicable) in
ECSS-M-) instead of one (PSS-05). procurement contracts.

It was to ease these steps and provide a The SEMG has three volumes:
common implementation basis for the various – Part A: Software Engineering, covering
frame contracts that the ESA Ground Segment ECSS-E-40
Software Engineering and Management Guide – Part B: Software Management, covering the
(ESA GS SEMG) was written. This provides ECSS-Q-80 and ECSS-M- series
ECSS compliance in the form of a set of – Part C: Document Templates.
practices. It is written in a style similar to PSS-
05, with a clear correspondence to the ECSS Part A was the first one to be written and was
processes and requirements, and it covers all the result of work carried out by a Working
relevant ECSS standards in a single (multi- Group comprised of software engineers drawn
volume) document. from the ground-segment disciplines that
develop and maintain software (simulations,
The SEMG is an implementation guide, mission-control systems, flight dynamics,
applying the relevant ECSS standards to ground-station information systems and
software development for ground segments. spacecraft checkout).

138
 ecss software-engineering standards

The GS SEMG is based on new versions of QMS documents by the second quarter of
ECSS-E-40 and ECSS-Q0-80, the so-called 2002, with a view to using the standard for new
‘B’ versions, which are currently under formal projects from that time onwards. Management
review within the ECSS. These do not differ in approved this plan in May 2001.
any principle respects from the ones currently
on the ECSS Web site, but there are a large The April 2001 Workshop determined that
number of corrections and improvements. some 20 documents needed updating. In
some cases the updates required were
The ESOC Quality Management System (QMS) substantial, as with for example the procedure
In November 1999, ESOC was the first ESA on ‘Control of Software Procurement via
entity to be certified according to the ISO/IEC Contract’, where there were numerous
9001 Quality Standard, following an 18-month references to PSS-05 had to be replaced.
preparatory phase. The rationale for this was There were about half a dozen documents in
that ESOC was providing services both to this category. Other documents, such as all of
ESA projects and to external ‘third party’ the procedures relating to configuration control,
projects, the latter following an ESA Council needed only minor changes. A QMS
decision in 1998. ISO 9001 certification Consistency Workshop was held in January
therefore increases ESOC’s effectiveness and 2002 to review the whole body of updated
attractiveness as a supplier of services. QMS documents and ensure that they were
coherent.
To support ISO 9001 certification, ESOC
prepared a Quality Management System In fact, the schedule was successfully
(QMS), which is a set of internal procedures maintained, with the formal issue of QMS
and instructions defining implementation of documents taking place in early May 2002.
work processes at ESOC and the associated
responsibilities. It consists of: Training courses are planned, including a
technical one for data system managers and
– a Quality Manual describing top-level technical officers in charge of defining and
requirements on the management system procuring software systems.

– a set of procedures and work instructions Conclusions

describing all of ESOC’s business processes, This article has outlined the new ECSS
software-engineering standards and an intense
The procedures and work instructions are split set of activities within ESA to ensure their
up into different areas such as Ground Segment smooth introduction into the Agency’s
Management, Infrastructure, Configuration procurement of software for both the space
Management, and Procurement via Contracts. and ground segments. The ECSS standards
The QMS does not repeat the various technical have been applied for some time to space-
and procedural standards that are used in segment projects. The transition to ECSS
ESOC’s work, but rather refers to them as standards for ground-segment projects at
necessary. ESOC took place later, with the first projects
beginning to use them via an implementation
At the time that the QMS was first written, all guide (the GS SEMG) this year. Indications are
ESOC software projects were based on the that the careful preparation and support has
PSS-05 standards, and so this was referenced helped make the transition a smooth one.
in the QMS. r

The transition process at ESOC

The transition process at ESOC involved
reviewing the Quality Management System,
identifying the changes needed to adapt to the
new standard, making those changes, and
formally re-issuing the QMS. A QMS revision
team was defined, made up where possible of
the original authors of the various QMS
documents. A Workshop was held in April
2001 to introduce the team to the new
standards, agree on the subset of documents
that would require change, and make a plan for
the phase-in of the new standard. The resulting
plan foresaw a set of activities extending over
one year, with an approved updated set of

139