Product Assurance Requirements for SXC

1
Product Assurance Requirements for SXC
2
Product Assurance

• Product Assurance Requirements
• Based on CNES µ-sat guide line Specificiation
  Assurance Produit micro-satellitesRef
  µST-AQ-S-0-348-CNS (doc. in french)
• Main topics
• Traceability (Configuration / NCR RFW)
• Design verification
• Manufacturing integration test
• Safety
• EEE, material process selection
• SoftwareThis ppt focuses on requirements for
  early project phases

3
Traceability

• Does not concern early project phase standard
  approach.
• Configuration control consists in
• Defining a base line (CIDL)
• Specs (functional, perf., environment)
• i/f control,
• design files,
• test procedures
• Tracing any deviation from this base line through
  NCR, RFW
• Controling evolutions of any docs in CIDL
• Traceability system for each step supply,
  manufacturing, assembly, integration, test

4
Design, verification, manufacturing, test

• Verification process started in early design
  phase verification matrix showing how
  conformance to specs is established (analysis,
  test, inspection)
• Verification matrix is part of the specification
  document
• Margins (EEE deratings as per ECSS-Q-60-11)
• Model philosophy TBD (SXC development paln TBD?)
• Suppliers to be carefully chosen, CNES approval
  expected (suppliers are supposed to be known from
  CNES since they are usually french!)any
  information regarding NASA approval of suppliers
  welcome
• Contamination control SXC has to be compatible
  with a class 100.000 AIT environment (as per FED
  Std 209 E)

5
Safety Architecture risk analysis (1/2)

• Safety approach based on early risk analysis
• Risk analysis looks like a light FMECA based on
  architecture.
• Based on result of risk analysis, true FMECA or
  reliability analysis may be required for critical
  area / subsystems
• Estimate scenarios of failure
• Effects to be classified
• Propagation (propagation to other equipment)
• Critical (loss of a function)
• Major (degradation of performance)
• Minor (light degradation of performance, perf to
  minimum reqd)
• Result gathered in table (see next slide)
• Inputs to FDIR
• Actions in risk reduction

6
Safety Architecture risk analysis 2/2

• Exemple

7
Safety tolerance to radiative environment

• Rate of indisponibility due to radiations (SEU,
  latch-up) to be assessed for each function
• Delay to recover (if self recovery)
• If no self recovery detection and recovery mean
• To be gathered in a dedicated analysis

8
EEE components

• COTS EEE are welcome, with specific strategy and
  justification for critical parts (from safety
  analysis, tolerance to radiation, procurement
  risk, etc)
• Hi-Rel EEE may be costdelay effective depending
  on risk reduction actions
• See also QML-38535, ECSS-Q-60-01, GSFC PPL-21
• Preliminary list (DCL) to be provided (ref,
  function, manufacturer, temp. range, quality
  level, procurement spec. Ref., critical or not,
  justification file ref).
• Deratings as per ECSS-Q-60-11A

9
Materials and Processes

• Material and process selection
• Approved by space agencies
• Already used in same applications
• as per ECSS-Q-70-71A or NASA equivalent
• Preliminary lists to be provided (format as per
  ECSS-Q-70 B)

10
Open point / Conclusion

• Open point PA for software
• Convergence of PA , two possible approaches
• A spec from CNES/CEA to MIT (english or french
  doc?)
• A PA plan from MIT with evaluation of ? wrt to
  CNES PA specsby CEA major discrepancies to be
  solved by dedicated note.
• Welcome informations
• data package from previous deliveries (hete-2,
  chandra)
• PA plan