An Introduction to the ECSS Software Standards

1
An Introduction to the ECSS SoftwareStandards
2
Abstract
This introduces the background, context, and
rationale for the creation of the ECSS standards
system presented in this course. Addresses the
concept that the software is just one element in
the overall engineering system, the E40-C
standard for space software is one standard
within the overall engineering branch of
standards. This module explains the relationship
between E-40 and the E-10 standard for space
system engineering.
3
What is ECSS?

• In June 1994, the ESA Council adopted a
  resolution to confirm the Agencys commitment to
  the transfer of the PSS system of ESA space
  standards to the new set of standards prepared by
  the European Cooperation for Space Standardisation

ECSS
European Cooperation for Space Standardization
4
Why ECSS?

• There were standards before
• In particular, the software area had a
  well-developed set of standards, the PSS series
• But the standards were not coordinated with each
  other
• Different concepts and approaches
• Different terminology
• A standard was needed for the total system
• software is pervasive in the system, an integral
  part of the whole
• Seeking compliance with ISO standards (e.g.
  ISO/IEC 12207)
• Pursuing homogenity across Space Organisations
  (Agencies, Industry)

The System
S/W
S/W
Software is pervasive!
5
Three types of document
Example

• The ECSS system is organised into three types
  Standards, Technical Memorandum, Handbooks
• Standard ECSS-E-ST-40C
• General requirements in the domain
• Space engineering software
• Handbook ECSS-E-HB-40
• Guidelines to interpreting the requirements for
  specific applications
• Engineering guide for software
• Technical memorandum ECSS-E-TM-40-07
• Candidate standard
• Software simulator interface

ST
E-ST-40
HB
E-HB-40
TM
6
How is the ECSS System Organised?

• The ECSS system has three major branches
• The management standards
• These provide a uniform approach to a number of
  common management issues
• The engineering standards
• Addressing a broad range of key Space engineering
  disciplines
• The product assurance standards
• Providing both general coverage, and specific
  coverage for specific disciplines

management
engineering
product assurance
7
The M-Series
A uniform set of standards for general Space
project management
8
The Q-Series
General standards

• General standards covering key topics critical to
  all Space projects
• Quality assurance in general
• Safety
• Dependability (RAM)
• Plus standards for specialised parts of the
  system
• Software
• Materials
• ASIC

standards in specific areas
Both the general and specific standards are
applicable to projects
9
The E-Series

• A series of standards covering all of the
  essential areas of engineering within Space
  projects
• The Systems Engineering standard covers the total
  system engineering process
• Specialised standards for engineering disciplines
• Software
• Electric and electronic
• Mechanical
• Ground segment E70

Systems engineering for the overall system

more specialised standards
software
10
Software in the ECSS System
11
Software configuration management,E40 and M40
12
Software Configuration Management
13
Software and system,E40 and E10
14
Software and Space System Engineering

• The software components of a space system play a
  role alongside the other engineering components
  such as mechanical and electrical
• All of these various engineering components
  (including software) are governed by the overall
  discipline known as space system engineering

Software components are part of the overall
mission system, together with other engineering
components
15
The E-10 Standard for System Engineering

• The ECSS-E-10 standard is special in that it is
  relevant to all the engineering disciplines,
  including software
• It is intended to guide the development of
  systems including H/W, S/W, man-in-the-loop,
  facilities services) for space applications
• It specifies implementation requirements for the
  responsible system engineering organization

16
System software THE projects' critical issue

• System requirements related to software are
  normally done by the system entity (customer)
• Software requirements are normally done by the
  software entity (supplier)
• However, system requirements related to software
  may be
• Delegated by the customer to the supplier.
• The customer may have initiated a software RB and
  ask for consolidation.
• The system requirements may be distributed in
  many (hardware) subsystem requirements.
• Merged with the software requirements
• The system is software intensive, no value
  added in 2 documents, however incremental
  approach.
• System software requirements weaknesses are the
  root of a lot of project troubles integration
  issues, late change, delays, etc

17
Overview of the System Engineering
A simplified view in which the five main system
engineering functions are identified
18
The Five System Engineering Functions

• Requirements engineering - Translates customer
  needs to consistent justified requirements
• Analysis - functional physical analysis,
  performance, trade-off
• Design and configuration - creates the physical
  architecture, budget
• Verification - Checks compliance with
  requirements, functional product verification,
  validation with user.
• Integration and control - define, plan manage

It is important to be aware how the overall
system engineering process is organised
Although the E40 standard defines its own
processes, they echo this overall organisation
and terminology
19
The Link Between E-10 and E-40
Sub System
Space System Engineering
Space Software Engineering

• Requirements engineering -
• Analysis -
• Design and configuration -
• Verification
• Integration and control

Software related system requirement process(E-40
Section 5.2)

• Software related
• Requirements analysis-
• Verification
• Integration and control

This clause (5.2) of E-40 complements ECSS-E-10
for the specific software activities to be
performed at system level by the customer
20
E10 and E40 Relationship
ECSS-E-40 5.2.2 5.8.3.1
ECSS-E-10
(software) Requirement Baseline
Specification of system requirements allocated to
software
Evaluation of system baseline
(system)
(system) Functional Specification for Software
(software)
SRR
Establishment of the software Technical
Specification TS
PDR
21
On the E-10 Side
ECSS-E-10
(software) Requirement Baseline
Specification of system requirements allocated to
software
Here the system engineer takes into account the
subsystem views to consolidate the system
baseline and formalize it between the system SRR
and the system PDR.
Evaluation of system baseline
(system) Functional Specification for Software
SRR
This provides the (system level) functional
specification for the software, i. e. the
Requirements Baseline.
Establishment of the software Technical
Specification TS
PDR
22
On the E-40 Side
ECSS-E-40 5.2.2 5.8.3.1
This activity verifies that the specific software
activities at system level described in E-40
Clause 5.2 are actually taken into consideration.
(software) Requirement Baseline
Specification of system requirements allocated to
software
Evaluation of system baseline
(system) Functional Specification for Software
SRR
Establishment of the software Technical
Specification TS
This is formalized at the software SRR, and now
the software is viewed as a (lower-level) system.
PDR
23
What is Verification for System and Software?

• The software verification activities confirm that
  adequate specifications and inputs exist for any
  activity and that the outputs of the activities
  are correct and consistent with the
  specifications and inputs
• Are we doing the thing right?

correct consistent?
input
activity
output

• The system verification activities are more
  concerned with ensuring that the requested
  functionality has been implemented

24
What is Verification for System and Software?

• The software validation activities ensure that
  the functionality of the developed system really
  corresponds to what was specified in the
  Requirements Baseline and further detailed in the
  Technical Specification
• Are we doing the right thing?
• Does the running system actually implement the
  promised functionality?

?

• The system validation activities are more
  concerned with the way the system is used.

25
Software and ground system,E40 and E70
26
Organisation of E70
5 Operations engineering..........................
..................................................
..............................23 5.1
General...........................................
..................................................
...........................................23
5.2 Requirements analysis and concept
development.......................................
..............................25 5.3 Mission
operations data preparation.......................
..................................................
..................29 5.4 Mission operations data
validation........................................
..................................................
.....31 5.5 Operations teams buildup and
training..........................................
...........................................32
5.6 Operational validation.......................
..................................................
........................................33 5.7
Operations execution..............................
..................................................
...................................35 5.8 Space
segment disposal..................................
..................................................
.........................38 6 Ground segment
engineering.......................................
..................................................
.......41 6.1 General............................
..................................................
..................................................
........41 6.2 Ground segment definition.........
..................................................
...............................................43
6.3 Ground segment production....................
..................................................
.................................46 6.4 Ground
segment AIT and verification......................
..................................................
...................47 6.5 Ground segment
maintenance.......................................
..................................................
..........51 6.6 Ground segment
disposal..........................................
..................................................
................52 7 Ground segment and
operations lifecycle..............................
...............................................55
7.1 General.......................................
..................................................
...............................................55
7.2 Phase A Mission and operational analysis,
feasibility studies and conceptual
design................57 7.3 Phase B
Preliminary design................................
..................................................
........................58 7.4 Phase C Detailed
design............................................
..................................................
..............59 7.5 Phase D Production, AIT
and verification..................................
..................................................
.60 7.6 Phase E Mission operations..............
..................................................
.........................................62 7.7
Phase F Disposal.................................
..................................................
......................................64 7.8
Summary of key documents and reviews..............
..................................................
....................64
27
E40 5.2
Special ESOC tailoring exists
28
The Engineering standards generating software
functional requirements
29
The Engineering standards generating software
functional requirements
Control
Control
Operability, FDIR
Operability, FDIR
Operability, FDIR
Operability, FDIR
Communication
Bus Interface
Bus Interface
Bus Interface
Bus Interface
HMI
30
Summary

• Space software engineering is part of the
  engineering branch of the ECSS standards
• The E-10 standard specifies implementation
  requirements for the responsible system
  engineering organization
• E-40 complements E-10 for the specific software
  activities to be performed at system level
• The link is reflected in E-40 Clause 5.2,
  Software related system requirement process
• These specific activities are performed early in
  the project phases (B)
• Note that they can be delegated by the customer
  to the supplier
• Software related system requirements are
  important
• E70 is the ground segment and operability
  standard.
• Several technical standards (not process models)
  generate software functional requirements.