365289299.

xlsx
COMPILED DRRs v.1 - 24 June 2016 Draft in Review (DIR): ECSS-Q-ST-30C-Rev.1-DIR1(6April2016)
CNES 19 DRRs DRR-01 to 19 Start of Public Review: Thursday, April 07, 2016
DLR 3 DRRs DRR-20 to 22 End of Public Review: Friday, June 03, 2016
Eurospace 23 DRRs DRR-23 to 45 Compiled DRRs distributed to WG convenor: Friday, June 24, 2016
ESA 10 DRRs DRR-46 to 55 DRRs dispositioned by WG:
Total 55 DRRs
NOTE: DLR also provided a CR during the Public Review (see CR-Q-ST-30C_11)
To be entered by WG To be entered by WG
DRR number Clause number Page number Review deficiency and justification Proposed change Disposition of DRR by DRR implementation by
(preferred approach: change "From - To") WG WG
1 1 7 To help in the tailoring of this standard, "per product To help in the tailoring of this standard, "a table proposing a
types and project phases" pre tailoring per product types and a table of dependability
Project phases not done documents delivery per project review" and project
phases
2 1 7 As pretailoring per project phase has been Change from "a table proposing a pre-tailoring per Product
abandonned by the TA , remove "Project phase" in "a types and Project phases into "a table proposing a pre-
table proposing a pre-tailoring per Product types and tailoring per Product types
Project phases"
3 2 8 ECSS-Q-ST-40 and ECSS-Q-ST-80 are missing add ECSS-Q-ST-40 and ECSS-Q-ST-80 as normative
reference in chapter 2 and in the core text
4 3.2.5 10 Definition of criticality is not in line with ECSS-Q-ST-30- use only one definition for Q-40 and Q-30 /30-02 standards
02 where probability of occurrence is always
considered
5 5.2 15 Editorial: In ECSS-M-ST-10C and in ECSS-E-ST-10.06, Change from "techical specification into "technical
"Technical specification" is defined and named as requirements specification" in all the clause.
"technical requirements specification"
6 Table 5-1 18 The sentence "(for lower than system analysis)" (outside level under study. Refer to requirement 5.3.2.c)
could be improved by "(outside level under study)",
because failure propagation could affect other
"systems".
7 table 5.2 20 Does table 5-2 applicable also to software or only table Specify if table 5-2 also applicable to software
5-3 ? Specify if there is a link between table 5-2 and 5-3
What is the link between table 5-2 and 5-3 for "function table 5-3 : add the word 'software' in 'function criticality'
criticality" ? There are 2 identical levels called 'I, II' with
different criterias.

8 5.4.2.d. 21 Why the software contained in compensation provision If software contained in compensation provision is
shall have the highest severity of the failure independant of the main function protected, without failure
consequences that they prevent or mitigate? propagation between them, its criticality category could be one
level lower.
9 5.4.2 22 Table 5-2 criticality of function and table 5-3 function Add definition of 'criticality of function' and 'function criticality'
criticality : differences between 'criticality of function' or use only one term
and 'function criticality' not clear, where are they
defined ?

10 Table 5.3 22 In function criticality I criticality category A if the Define categories A, B and C
software product is the sole means to implement the
function, same definition in II with category B : not
understood
11 table 5-3 22 What is the link with the severity ? According to Add a link/column with severity
defintion 3.2.5

365289299.xlsx page 1 of 8
 365289299.xlsx
12 Table 5-3 22 The table 5-3 considers compensating provisions Be more precise in the table 5-3 considering various
implemented by software but, in case of software architectures as it is done for example of SAE ARP4754
backup or redundancy, does not make the distinction
between asymmetrical software developed
independently and multiple copies of the same
software products. Yet, the criticality allocation should
be different considering these different cases.

13 Table 5-3 22 In case of N-Version software architecture, the

criticality allocation rules given in table 5.3 are not easy
to apply. In this case it is more over difficult to identify
the compensating provision with regard to the software
implemented.

14 Where is the classification for 'criticality of product' ? Add classification for product
(following definition given in 3.2.5)
15 6.4.2.2 note 26 In note : product FMECA/FMECA Correct with product FMEA/FMECA

16 6.4.2.2 26 b. all potential failure modes shall be identified and b. all potential failure modes shall be identified and classified
classified according to the severity or criticality according to the severity or criticality
Following def 3.2.6 classification of faliture mode or change the def 3.2.6
according to a combination of severity and its
likehood
Thus not the severity

17 8 33 Typo correction: "six project phase..." (add S at the "six project phases..."
end of phase)
18 8 33 Project phases is not part of the table Delete 'project phases' in title
19 Table 8-1 35 and 36 Please clarify comment A# if complete system view is
unknown.
20 6.4.2.2 26 Requirement 6.4.2.2.a refers in a note to a process Please refer to a process FMEA instead of a process FMECA.
FMECA.
Change from
Manufacturing processes should be capable and "NOTE FMEA/FMECA are performed on the functional and
controlled. To reach this failures during manufacturing physical design (Functional FMEA/FMECA and Product
have to be identified as early as possible in the FMECA/FMECA respectively) and, if required by the contract,
processes. In addition to severity and occurence the the processes used to realize the final product (Process
detection of failures in the manufacturing process FMECA). "
should be rated to for this purpose.Therefor a process to
FMEA is the more suitable tool. "NOTE FMEA/FMECA are performed on the functional and
physical design (Functional FMEA/FMECA and Product
FMECA/FMECA respectively) and, if required by the contract,
the processes used to realize the final product (Process
FMEA). "

Please also consider this change within the pre-tailoring

matrix.

21 Annex D 50 D.2.1.a.3: There is an editorial: Please change from:

A details of the failure detection method,
"3. A details of the failure detection method,"
to
"3. details of the failure detection method,"
or
"3. A description of the failure detection method,".

365289299.xlsx page 2 of 8
 365289299.xlsx
22 8 33 Currently a pre-tailoring approach is implemented Q-ST-40 and Q-ST-80 follow a different pre-tailoring approach,
within the ECSS-Standards. For this purpose an compared to the generic pretailoring by product type in other
additional chapter will be added to the correpsonding ECSS standards.
standards.
These chpaters start with an introduction. This difference, its meaning and necessity, should be
highlighted and explained in the introduction of these sections.
The introduction to the pre-tailoring is phrased in This shall help the user to understand the concept and not not
different manners within the standards. to be confused with the other pre-tailoring concept throughout
the ECSS system.
ECSS-Q-ST-30C, chapter 8:
"The matrix in Table 8 1 proposes a pre-tailoring of Introductory wording of these sections in Q-ST-40 and Q-ST-
ECSS-Q-ST-30C Rev 1, which may be tailored for the 80 should be harmonized, e.g. talking about "a proposed pre-
specific characteristics and constraints of a space tailoring", "an applicable tailoring" or "an applicable pre-
project in conformance with ECSS-S-ST-00. For each tailoring".
of the nine product types (as defined in ECSS-S-ST-
00-01) and six project phase (as defined in ECSS-M-
ST-10), the possible values are:
A or NA when the proposed pre-tailoring is
Applicable or Not Applicable respectively,
A# or X# when the proposed pre-tailoring is
Applicable and (A#) calls for supplementary
information or (X#) may depend on specific cases, both
being explained in the Comment column,
NOTE 1 Clauses are proposed as applicable to a given
decomposition level but not to the level below when
they address an element and its constituents at that
level, but not what is inside the constituents (at the
level below). In particular, no clause is proposed in the
pre-tailoring as applicable to the product type
software understood here as the applicability to the
development of software when not installed in
hardware.
NOTE 2 Clauses applicability to the product type
launch segment element and sub-system is proposed
in the pre-tailoring on the basis of launcher and
launcher element, covered by this product type, and
not of the other elements and sub-systems that this
23 Clarify differences between severity and criticality (function,
It is confusing to denote two different concepts under the product) . Avoid the usage of word criticality for two different
3.2 9 name criticality. Criticality (function, product) seems to be a concepts. When possible, use function criticality (or severity) and
synonymous of severity failure criticality

24 Add software criticality definition, and relation to function criticality

3.2 9 software criticality is not defined. and failure criticality concepts.
25 It is not describe where to collect the dependability lessons learnt.
4.7 14 Dependability lessons learnt shall be collected, but where? There is not a lessons learnt document. In the documents in Table B-
1, there is no reference to this issue.
26 Different levels shall be described or referred to the corresponding
5.3.2 17 Definition of levels standard. For example, a Payload system is a system itself but a
subsystem of the Ground Segment.
27
It is not clear when each severity classification should be
Table 5.1, 5.3.2 18 used. In case a failure has both dependability and safety To add clarification
consequences. Should the worst category be used?

365289299.xlsx page 3 of 8
 365289299.xlsx
28
FROM:
NOTE The severity categories are common to dependability and
safety. The Table 5 1 is common to ECSS-Q-ST-30 and ECSS-Q-ST-40
(as Table 6-1), which address respectively the dependability and
safety types of consequences
5.3.2 a NOTE 18 Errata: missing -es TO:
NOTE The severity categories are common to dependability and
safety. The Table 5 1 is common to ECSS-Q-ST-30 and ECSS-Q-ST-40
(as Table 6-1), which addresses respectively the dependability and
safety types of consequences

29
I cannot see the difference between dependability catastrophic
between system and lower levels. At system level is "failure
Table 5-1 18 Dependability catastrophic propagation", for lower level it refers to 5.3.2.c that says: "the
severity due to possible failure propagation shall be identified as
level 1".

30 The categorisation for environmental effects is subjective, the

Table 5-1 18 Detrimental environmental effects difference between severe and major detrimental environmental
effect is not obvious.
31 Although it looks like obvious, the mean of "function" shall be
5.4.1.a 20 Define "function" explained as an element in the "functional design".
32 Table 5-2 20 Feared event not defined in Q-30 It shall be included in the acronyms list.
33 The definition of software criticality categories is included in Q-80
5.4.2a 21 Refer to identification of SW criticality Table D-1. A reference shall be added.
34 The criticality category is assigned to a software product to tailor the
development standards (mainly the verification and software PA
Table 5-3 22 What is the classification of function criticality used for? activities), but the function criticality (I, II, III, IV) is not used in this
standards or any other.

35
Question : FMEA applies for random failures and their
26 impacts in-orbit, P_FMEA applies for manufacturing defects. to address D_FMEA or as a minimum to mention D_FMEA with a
6.4.2.2 Why D_FMEA considering design errors is not specified as defintion and to exclude D_FMEA formally from the document
well ?

36 critical items criteria: ".. Shal include:" meeans that the list I suggest to add a sub-clause stating that apart the criterai speciifed
is not exhaustive (depending on the systems some specific the subcontrcator shall identify any other criticality categories as
6.5 30 points may be also identified as critical in the frame of the relevant to the project specificity and shall list all the critical items
project) criteria (RAMS plan ?) used for the project.

37 Typo in the 4th line of the first paragraph, missing final "s"
8 33 in "six project phase" From "six project phase" to "six project phases"

365289299.xlsx page 4 of 8
 365289299.xlsx
38

Remplace
a. HSIA shall be performed to ensure that the software reacts in an
acceptable way to hardware failure.
b. HSIA shall be performed at the level of the technical specification
of the software.
NOTE HSIA can be included in the FMEA/FMECA (refer to ECSS-Q-ST-
30-02).
6.4.2.3 a. 27/66 Modifications to moderate the use of a HSIA analysis.
by
a. HSIA shall be performed to ensure that the category A or B
software reacts in an acceptable way to hardware failure.
b. HSIA shall be performed at the level of the technical specification
of the category A or B software.
NOTE HSIA can be included in the FMEA/FMECA (refer to ECSS-Q-ST-
30-02).

39

The criteria are too specific compared to the expectations of

the safety and dependability requirements.
For instance, if the requirement is to be FO/FO or FO/FS, A critical item, for safety and dependability, is identified in case of
that means that it is required to be tolerant of 2 failures: the no fulfilment of a safety and dependability requirement.
that means that the criteria related to the single point of For the internal company use, it should be interesting to define the
failure is not sufficient to trace all the related critical items
6.5 30 / 66 concept of "potential critical item" when the uncertainities can lead
that do not match with the FO/FO or the FO/FS requirement to the non fulfiment of a safety and dependability requirement
when it exists: it should be identified where the system will (uncertainities may be at different levels: uncertainities about the
not be tolerant to 2 failures. numerical values or uncertainities about the proofs).
This example shows that the critical item criteria are too
specific. The right defintion shall be built in relation with the
safety and dependability requirements.

40
The title of the clause and the text in the first paragraph of
clause 8 mention a pre-tailoring per product types and
project phases, but the table provides only the ore-tailoring
8 33-39 per product type (though the WG prepared the table with Please complete the table with the pre-tailoring per phase.
also the pre-tailoring per phase, as required by the NWIP
and by ECSS-D-00-01C ECSS Drafting rules).

41
The usefulness of the pre-tailoring could be significantly
improved by making a distinction between clauses that are
not "technically" applicable to a given product type or
33-39 phase, from those which are only proposed as "not Please consider improving the pre-tailoring with this clarification of
8 applicable" in the pre-tailoring but could be applied if so two cases of "non applicability"
desired in some project. Note that the possibility of leaving
a cell empty (in addition to the other 4 possibilities A, A#, X#
and NA) could be exploited for that purpose.

365289299.xlsx page 5 of 8
 365289299.xlsx
42
About "Documents listed in Table B-1 are either ECSS-Q-ST-
30 DRDs, or DRDs to other ECSS-Q-30-XX standards, or
defined within the referenced DRDs.":

"ECSS-Q-30-XX" should be changed to "ECSS-Q-XX", or even

Annex B 43 better "ECSS-Q-*" (as written by the WG) because not all Please change from "ECSS-Q-30-XX" to "ECSS-Q-*"
documents listed in the table are in the Q-ST-30 series
(there are also at least 40-12 and 10-04). Please note also
that literally speaking, ECSS-Q-30-XX does not refer to any
existing ECSS document, missing something between the Q
and the 30).

43
The DRD included in Annex C for the Dependability Plan is not
detailed. For example, the expected response is not detailed as the
Annex C 48 Dependability Plan sections not described. PAP in Q-10 Annex A.
Also, it would be very useful to include the requirements to be
fulfilled in each section as Q-80 Table B-1.

44
It is not clear why the title of some of these clauses is
"Scope and content" (in annexes C, D, E, F, I) whereas it is
"Content" in the other three annexes G, H and J).
Annexes C to J, clauses 48, 50, 53, 54, 56, Please change title of clauses C.2.1, D.2.1, E.2.1, F.2.1 and I.2.1 from
X.2.1 57; 59, 60 Note that in the draft produced by the WG, all these titles "Scope and content" to "Content"
were the same "Content", in application of ECSS-D-00-01C,
ECSS Drafting rules (letting apart a small typo, indeed the
draftint rules say "Contents").

45
The newly issued ECSS-Q-HB-30-03A handbook on human
dependability provides useful material and should be Please add ECSS-Q-HB-30-03 Space product assurance - Human
referred to in Q-ST-30.
Bibliography 66 dependability handbook in bibliography, and notes calling it in one
It may or should be called from one or more of clauses 5.2, or more of clauses 5.2, 5.6, 6.4.1, 7.1 and annex A.4.
5.6, 6.4.1, 7.1 and annex A.4.

46 6.44 29 the 'availability' of a performance/ duty is very much
depending of functional robustness against 'undesired
software function' (e.g. SW contributes at the moment
with app. >40% to the number of events which effect
the availability of the services of the Galileo
constellation; the current version does not give this fact
the adequate attention.
please add under 6.4.4 that the Availability is also effected
remarkable by the robustness of software/ hardware against
'undesired software function'; a reference has to/ contribution
be given to ECSS-Q-ST-80 make the importance of Software
assurance for the 'availability' clear, e.g.:
f.) the contribution of 'undesired software function to the
availability of the duty has to be mitigated as much as
reasonable by implementing of an adequate 'software product
assurance'(ECSS-Q-ST-80..)

47 5.2/ d./ bullet no. 6
14 the use/ understanding of the term 'software please replace the term: 'software malfunction' by 'undesired
malfunction' is not fully specified; software function' and an adequate definition has to be given
the term 'malfunction' is not defined neither in ECSS-Q- in an update of ECSS-S-ST-00-01C at least for 'undesired
ST-80C nor in Rev.1 DIR1 nor in ECSS-S-ST-00-01C; (event)' (see also 2.3.3./2.3.184 where the term 'undesired
event' is already used)
the software is functioning in the way as it is
programmed; the only thing what software is doing is: this recommendation applies as well to ECSS-Q-ST-80C Rev.1
software work/ acts in an unexpected way DIR1 page

365289299.xlsx page 6 of 8
 365289299.xlsx
48 5.3.2 18 in table 5-1 The severity for 'dependability' based on
the term 'mission';
'mission' is defined acc. ECSS-S-ST-00-01C/ 2.3.139:
'set of tasks, duties or functions to be accomplished by
an element', whereby 'element' (2.3.72) is a
'combination of integrated equipment, components and
parts' - I guess a satellite is here meant;
the loss of a mission(a satellite) is not 'critical' when the might be extended to 'combination of integrated equipment,
mission(a satellite) is part of a constellation, e.g.
Galileo or future (mega)constellation of micro/nano-
satellites;
the used reference for dependability 'mission' or
'mission degradation' is not suitable for ongoing and
future space activities where more than one 'satellite/ hence 'performance' is according ECSS-S-ST-00-01C/ 2.3.152
integrated equipment, components and parts 'is
involved, like in space born (mega)constellations and specified a new term 'services' or a definition for 'duty' as:
space campaigns
49 3.2.5 / 3.2.6 10 It is not understood the inconsistency introduced for
the criticality definition for function and failure. The
criticality of an HW participating to a function can be
reduced thanks to the likelihood but the function will
remain with higher criticality.
50 5.3.2 / 5.4.2 17 / 21 "Severity categories shall be assigned without
consideration of existing compensating provisions"
But for SW criticality category, anything which exist can
be used: inhibits, monitors, back-up, operational
procedures
51 5.4.2 g 21 It is written: "Any common resources shared by
software products of different criticality shall be
identified." But what happens once identified
52 Table 5-3 22 An HW or operational procedure can be a
compensating provision to reduce SW criticality
category. But what assurance level is expected for
these provisions?
53 6.4.2.2 26 A note should be added to clarify that Functional To add a note
FMECA is expected during early phase (PDR) whereas
a Physical FMECA is expected at later phase (CDR)
365289299.xlsx
a) The definition of 'mission' which based on 'elements' does
not really reflect the possible impact of 'software' or 'undesired
software functions' to the criticality categories via availability
degradation; therefore it is recommended to indicate this
aspect on a higher level of the document, e.g. in the chap. for
the 'Availability analysis' (see DW-30-01- > 6.4.4) - even when
it is not part of the Availability Analysis!
Or the definition of 'elements' in ECSS-S-ST-00-01C/ 2.3.72
components and parts, including its software'
b) to make the severity definition more practical and ready for
ongoing and future space activities it is recommended to
replace 'mission' by another term, e.g. 'performance';
limited to 'a function' and the term 'duties' is not further
quantifiable characteristics of a product .. is recommended;
e.g. the product 'Galileo constellation' will offer different
service(s)/ duty(s), e.g. global navigation for public (OS) or
PRS or SAR; e.g. this services/ duties are first lost (critical
consequence) when several satellites/ missions of the
constellation get lost at the same time - not one mission!
the use of 'quantifiable characteristics' of the expected
services/ duties would support a more practice oriented
definition of the severity categories from dependability
viewpoint and will avoid an overdesign of space activities
which are part of a (mega)constellation or a space campaign
Remark:
please take notice of the attached picture (right hand) which
were developed and is in use as a generic definition of severity
categories for CDF studies for very different kinds of space
activities in the domains of science, business and human
exploration with are basing on single satellites,
To align criticality definition for function and failure.
To align the philosophy when assigning severity categories.
To clarify how to handle common shared sw resources
To clarify
page 7 of 8
 365289299.xlsx
54 Annex D 50 Contingency analysis is not a task done by To change Contingency analysis by Dependability inputs to
Dependability. In best case, dependability analysis Contingency analysis
provide input to Contigency analysis.
55 Annex F 54 Same as above To change FDIR by Dependability inputs to FDIR

365289299.xlsx page 8 of 8