1 / 17

Hideki Nomoto Elwin Ong Karen Marais Nancy Leveson

Hideki Nomoto Elwin Ong Karen Marais Nancy Leveson. Systems Engineering Research Lab MIT Aeronautics/Astronautics Japan Manned Space Systems. E. Ong P55. 1.

cwen
Télécharger la présentation

Hideki Nomoto Elwin Ong Karen Marais Nancy Leveson

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hideki Nomoto Elwin Ong Karen Marais Nancy Leveson Systems Engineering Research Lab MIT Aeronautics/Astronautics Japan Manned Space Systems E. Ong P55 1

  2. Component-Based Spacecraft Fault Protection With Non-Dimensionalized FDIR Design E. Ong P55 2

  3. Introduction • Component-based Spacecraft Architecture • Reusable spacecraft component library • Integrated fault protection • Intent specifications • Non-dimensional FDIR Design • Use component-based architecture to form generic framework for FDIR design • Non-dimensional FDIR design table • 2 Layer non-dimensional architecture E. Ong E. Ong P55 3

  4. Traditional Fault Protection • Labor intensive & expensive process • Spacecraft design is unique and iterative • Unique missions  Unique designs  Unique FP • Fault Protection SW is system-specific • Each spacecraft requires unique FP design • Designed at the end of spacecraft design phase • FP Software is separate from rest of S/C SW • Need for more cost effective solution E. Ong E. Ong P55 4

  5. Spacecraft Decomposition • Create a library of generic reusable spacecraft component specifications E. Ong E. Ong P55 5

  6. Component-Based Architecture • Create spacecraft specifications from set of generic component specifications • Built-in fault protection logic • Encapsulate fault protection logic in specifications • Basic fault protection is ensured • Fault protection is specified explicitly at the beginning of the design phase • As technology changes, add new knowledge to generic foundation • Library created & updated by spacecraft engineers E. Ong E. Ong P55 6

  7. Research Goals • Capture domain knowledge • Capture recurring design, store, & reuse • Integrate fault protection design with rest of spacecraft design • FP design considered from beginning of SC design • Other novelties of research • Implement reuse at specification level, not code • Domain-specific to spacecraft engineering • Use intent specifications E. Ong E. Ong P55 7

  8. Using Intent Specifications • Enforce good documentation practices • Capture design rationales and assumptions • Provides linking for traceability • Integrates hazard analysis • Design fault protection mechanisms for identified hazards • Formal model of system behavior • Allows analysis and simulation of specification • Easy to understand and use E. Ong E. Ong P55 8

  9. FDIR Design Issues • Complex FDIR Design Tables • Must account for spacecraft operating mode and status of multiple sensors/actuators • Can lead to three or four dimensional design tables • Complex design tables lead to incomplete or inconsistent design • Difficult for operators to understand fault protection design • May lead to safety issues during operation due to lack of situation awareness E. Ong E. Ong P55 9

  10. Current FDIR Design • Simple FDIR Systems • 2D Design Table • Most FDIR Systems • 3D or 4D Table • Much more complex E. Ong E. Ong P55 10

  11. Non-Dimensionalized FDIR • 2 Layer FDIR Design • Borrow from technique used in relational database design • FDIR Design Tables are non-dimensionalized into Primary Table and Secondary Table • Fits into component-based architecture • Generic tables can be initially populated using SpecTRM tool in plug and play environment • Can result in improved situational awareness for operators E. Ong E. Ong P55 11

  12. Primary Table • Defines Spacecraft Operating Modes & available Fault Responses • Fault Responses are prioritized • Typically involves 100 cells or less • Generic primary table is obtained automatically from plug and play tool when component models are pieced together to form subsystem • Designers must update primary table to fit system requirements • E.g. Certain fault responses should be deactivated during Standby Mode or Safety Mode E. Ong E. Ong P55 12

  13. Generic primary table customized to fit system requirements, certain fault responses are deactivated for Standby and Safety Modes E. Ong E. Ong P55 13

  14. Secondary Table • Defines severity levels based on multiple failures • Severity levels used to update primary table • Secondary table can be quite large • E.g. 30 components with 5 failure modes each involves table with 22,500 cells • Most cases are handled in primary table design • Few exceptions forces designers to think through design logic and possible failure scenarios • E.g. ESA failure prior to Earth Acquisition E. Ong E. Ong P55 14

  15. Example of a generic secondary table E. Ong E. Ong P55 15

  16. Using secondary table to update primary table, accounting for ESA failure prior to Earth acquisition E. Ong E. Ong P55 16

  17. Conclusions • Component Based Spacecraft Design • Store recurring design in reusable generic specifications • Decrease development cost by developing new spacecraft from generic component models • Non-Dimensionalized FDIR Design • 2-layer design tables using primary table for overall system architecture and secondary table to define severity of multiple failures • Increase situation awareness of operators and alleviate design incompleteness and inconsistencies E. Ong E. Ong P55 17

More Related