An Introduction to the ECSS Software Standards - PowerPoint PPT Presentation

Loading...

PPT – An Introduction to the ECSS Software Standards PowerPoint presentation | free to view - id: 1df596-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

An Introduction to the ECSS Software Standards

Description:

... components of a space system play a role alongside the other engineering ... All of these various engineering components (including software) are governed by ... – PowerPoint PPT presentation

Number of Views:147
Avg rating:3.0/5.0
Slides: 31
Provided by: intecs
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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.
About PowerShow.com