ELEC-E4240 Satellite systems. Systems Engineering

Transcription

1 ELEC-E4240 Satellite systems Systems Engineering

2 Making a satellite mission

3 Space Mission Elements Data Center Launcher Orbit Mission Operation Space mission Payload Spacecraft Subject (science)

4 Payload Payload selection is based on mission science Payload selection should be justified by requirements. Payload is the most important part of the S/C. Payload defines your S/C bus.

5 Mission Design Process

6

7 Orbit Consider: Measurement coverage, revisit time Launcher and cost Radiation environment Communication solution and data budget Power budget Thermal solution

8 Launcher A lot of energy has to be used to reach the orbit. The rocket has to carry also all the needed energy. Handling the amount of energy and acceleration is difficult. The spacecraft has to be as light as possible. The spacecraft has to be as strong as possible.

9

10 Environment Space environment Launch environment Transportation environment Storage environment

11 Mission operation and ground segment Consider Mission duration Data processing Data redistribution Autonomous operation Problems Available power Signal attenuation Dopler shift Ionospheric effectst

12 Effects of increased/decreased drag Solar storms deposit energy into the upper atmosphere/ionosphere atmosphere expands drag increases orbits are lowered, some pieces return to the atmosphere Low-orbit spacecraft (including) ISS must be pushed up regularly De-orbiting of large structures must be made carefully e.g. the de-orbiting of the MIR station was delayed a couple of weeks due to too good space weather Page 12

13 ISS orbit after Bastille day solar event

14

15 Space Mission Elements Data Center Launcher Orbit Mission Operation Space mission Payload Spacecraft Subject (science)

16 Anatomy of an unmanned spacecraft 3/7/

17 Voyager

18 Magellan

19 Hubble

20 MetOp

21 SESAT

22

23 Space mission product tree Space segment Ground Segment Telemetry tracking and command Thermal Control Structures Payload(s) Attitude Control System Propulsion system Electric Power Mission Operation Antennas Multi Layer Insulation Housing Camera Attitude sensors Thrusters Solar panels Ground station or GS network Radios Heat pipes Booms Magnetometer Mag torq. Tanks Batteries Data storage and delivery Health sensors Louvres Chassis Radar Reaction wheels Lines, valves Regulators Science team/ Sales team On Board Data Handling Radiometer Power distribution harness Launcher

24 S/C functional diagram

25 Problems to solve when designing a spacecraft

26 Available technology Evaluate, how much technology development needs to be done before launch.

27 Power budget considerations Your power system will degrade! Therefore you should calculate your budgets with EOL values (and add the margins!) EOL End of libe BOL Beginning of life Solar Cells have ~30% efficiency Radiation damages the cells Battery has finite lifetime and degradation Charging efficiency is always less than 100%

28 Solar array performance issues

29 Communications Antenna gain vs pointing accuracy Antenna placement Thermal properties Link budget

30

31 Thermal Design Thermal environment sets strong constrains for the mission Active / Passive Spacecraft Attitude and Subsystem locations

32 Harness (Electrical Distribution System EDS) Harness has mass Harness has volume Cables have bending radius Harness is prone to functional interference

33 Mars-96 Lander s main computer and power system EM In 1996, the Russian mission to Mars with two small stations and two penetrators was launched using a Proton rocket. The second fourthstage burn failed and the probe re-entered the Earth s atmosphere. The spacecraft is believed to have landed to Chile but no debris has been found. Page 33 Photo: Finnish Meteorological Institute

34 Mars-96 connector saver Photo: Finnish Meteorological Institute Page 34

35 Mars Express

36

37 Mass (g) SIXS SU mass development Allocation in the S/C mass budget STM EQM FM Measurements of the actual models! Time

38 Reaction control 1. Thrusters and reaction wheels 2. Spacecraft mass distribution 3. Thrusting directions 4. Redundancy 5. Main engine

39 Pointing budget and pointing errors ESA Pointing error handbook Issue1(19July2011).pdf

40 Kepler

41 Spacecraft structure Dominant elements and Antennas Booms Thrusters RTG Thermal radiators Stabilization solution

42

43

44 Rocket fairing Planck and Herschel

45 System Summary Budgets: Mass, Power, Telemetry Mission description and lifetime Launcher, launch mass, fairing Total system margin

46 Systems Engineering An art of how to build complex systems

47 Systems engineering A logical process of activities that transforms a set of requirements arising from a specific mission objective into a full description of a system which fulfils the objective in an optimum way. It ensures that all aspects of a project have been considered and integrated into a consistent whole. Chambers Science and Technology Dictionary Systems engineering is a robust approach to the design, creation, and operation of systems. In simple terms, the approach consists of identification and quantification of system goals, creation of alternative system design concepts, performance of design trades, selection and implementation of the best design, verification that the design is properly built and integrated, and post-implementation assessment of how well the system meets (or met) the goals. NASA System engineering handbook The interdisciplinary approach governing the total technical effort required to transform a requirement into a system solution. European Cooperation for Space Standardization (ECSS-E-10 Part 1B) Page 47

48 The need for system engineering Hardware cost factors Software cost factors Requirements 1 1 Design Build Test Operations Stecklein et al., Error cost escalation through the project life cycle, NASA Johnson Space, Center,

49 Requirement driven approach 3/7/

50 Objectives Requirements -Solutions WHY? High level objective drives the mission. WHAT? Requirements define the goals quantitatively (numbers, units). HOW? There might be several solutions for reaching the goal.

51 Top-level system requirements The spacecraft design shall guarantee the operational lifetime in the environment dictated by the orbit parameters established in chapter Photo: ESA/BepiColombo & EADS Astrium Near-Earth Commissioning Phase

52 System requirement specification Page 52

53 Requirements Requirements are formal statements what is needed to fulfil to achieve mission objectives. Well laid out requirements are prerequisites for a successful mission! Requirements communicate, what needs to be done. help to make decisions. keep focus on mission goal. resolve conflicts. find optimal solutions. provide specifications for low level engineering.

54 Good Requirements Requirements are hierarchical (can be tracked) Requirements are product related, not process related. Requirements shall be verified! Requirements specify numbers. Requirements specify units. Requirements provide verification method.

55

56 Mission Design Process

57 Mission Name Orbit Mission description Mission objective Mission requirements S/C Configuration Payload Instrument(s) Ground segment Spacecraft design Product tree Cost Telemetry budget Power budget S/C Drawing Schedule Mass budget

58

59 Tools for an systems engineer Jaan Praks

60 Systematic Design Flow

61 System engineer controls information flow

62 Documentation A number of documents are used to coordinate the design effort in ESA/NASA projects, there are requirements for documentation, too! The single most important topic that needs proper documentation is how the parts of the system will interface with each other In ESA projects, there are two major documents for system engineering: Experiment Interface Document - Part A (EID-A) requirements for the payload including scientific instruments mass, power, telemetry budgets for the payload prepared by the ESA project team and the prime contractor the spacecraft side of the interface to the payload Experiment Interface Document - Part B (EID-B) specifications of the payload i.e. payload side of the interface prepared by the payload team and approved by the prime contractor and ESA commonly introduces requirements to the spacecraft design!

63 Interfaces Specify interfaces in early stage. Leave room for corrections Use flexible archidecture where possible Use standards

64 Budgets Three most important budgets are: Mass budget Power budget Telemetry budget Budgets are the main tools for the system engineer Budgets should be ALWAYS up to date USE ALWAYS PROPER MARGINS (CONTINGENCY)!

65 Margins - Contingencies Equipment level margins according to development maturity 5% for off-the-shelf items 10% for off-the-shelf items with small modifications 20% for new designs and major modifications System level margin (at least 20%) Additional to equipment margins! Propellant margins (wet mass, dry mass).

66 Mass budget example Limit for subsystem enginer Limit for system enginer Subsystem Mass (g) Margin (g) Total (g) El. Power System Communication system On Board Data Handling Structure Payload System margin 220 TOTAL 1340

67 Trade-off Trade-off evaluates alternative solutions System performance Trade-off should have clear evaluation criterias (see your requirements) Typical criterias Mass Cost Time Performance mass cost

68 Hardware model philosophy Decide in early stage of the project model philosophy Mock-up Breadboard models Prototypes Engineering model Qualification model Protoflight model Flight Model Flight Spare

69 Part lists

70 FMECA Failure Modes, Effects and Criticality Analysis Severity Number X Probability Number = Criticality Number

71 Examples

72 Aalto-1 The Finnish Student Satellite

73 Aalto-1 The Finnish Student Satellite

74 Aalto-1 The Finnish Student Satellite

75 Aalto-1 The Finnish Student Satellite

76

77 Aalto-1 The interfaces need to be defined unambiguously

78 Adonis satellite concept 78 3/7/2017

79 Lisa Pathfinder

80 Adonis S/C product tree

81 Adonis mission ground segment 81 3/7/2017

82

83

84

85 Subsystem trade-off tree

86 Summary on Systems Engineer toolbox Form Descriptions Reports Tables Drawings Diagrams Lists Prototypes and models Tools Requirements Budgets Contingencies and tolerances Trade-offs FMECA Interfaces Designs

87 Program matics Cost Schedule Risk

88 Project Planning 1.Purpose and objectives of the project Key questions to be answered Key technical performance parameters Technical and programmatic constraints 2.Technology availability and development needs Potential cost and schedule drivers 3.Cost (cost class S, M, L, XL) 4.Ability and need to reuse existing equipment/products 5.Availability and need for human resources, skills, technical facilities 6.Risk assessment Risk management and mitigation actions 7.Development approach: Result from above considerations Project deliverables Customer requirements and constraints Project requirements documents Project management plan

89 Duration of mission phases

90 Reviews Idea MDR mission definition review PRR preliminary requirements review SRR system requirements review PDR preliminary design review Satellite Launch Operation Disposal CDR critical design review QR qualification review AR acceptance review ORR operational readiness review FRR flight readiness review LRR launch readiness review CRR commissioning result review ELR end of life review MCR mission close out review

91 Configuration management process Configuration management is the process for establishing and maintaining a consistent record of a product s functional and physical characteristics compared to its design and operational requirements. Configuration and information/documentation management are interrelated processes for managing projects. The main activities of these processes, depicted in Figure 4 1, are: management and planning; implementation of CM activities, i.e. configuration identification, control, status accounting, and verification and audit; implementation of IDM activities, i.e. creation, collection, review, delivery, storage and retrieval, and archiving. 91 3/7/2017

92

93 Configuration control

94 Preliminary system design plan with subsystems and interfaces Part availability? Manufacturing difficulty? Mass? Cost and other resources? Schedule? Page 94

95 Work breakdown structure

96 Schedules

97 Organization Quality organization has to be independent Determine who is customer, who supplier

98 Risk Analysis Space missions are large investments Understanding and analysis of risk is important to avoid catastrophic events as much as possible Identification of risk followed by risk mitigation is the approach Make a risk Register with main risks Rated with likelihood (A-E) and severity (1-5)

99 Tips and tricks Jaan Praks

100 Build prototypes, a lot of prototypes In educational project, nothing teaches better than making mistakes. Make mistakes, make prototypes.

101 Testing and developing Functional testing in early proto phase Make environmental tests already for components Testing takes time!

102 Connectors and harness Cables are always trouble Draw harness to your CAD Draw all connectors WITH counterparts Make integration tests

103 Documentation Importance of the documentation grows with the size of the project. Documentation is communication. Document at least the most important parts, such as interfaces. Use version control. Documentation does not need to be on paper or organized as paper like documentation.

104 Procurement Establish procurement chain in earli stage of the project Establish storage system Document your orders Procurement takes time

105 Make reviews Review is a convenient milestone Get things done Document your reviews Use external experts

106 ECSS European Coopration for Space Standardization Handbooks Standards

107 Systems Engineering troublemakers Mikko Syrjäsuo

108 System engineering troublemakers SOFTWARE (this is #1!!) Modern systems are increasingly software-driven The division of what should be done in hardware and software is a central question in modern system engineering (not only space!) The effort needed in (space) software design is typically underestimated!!! The interface to (non-existing) hardware needs to be defined It may not even be known how the hardware should be operated! The true behaviour of hardware can (read: will) differ from the specification We can fix it later with software -mentality Missing requirements for software design!! (see Troublemaker #2) The correct operation of the software needs to be verified by testing These tests may fail due to problems in hardware, too!

109 System engineering troublemakers Defining and deriving the requirements (this is #2!!) Collecting a complete set of system requirements is a major effort It is also more or less impossible to know what requirements are needed in advance there will always be missing requirements For each requirement, you need a verification method test plans/procedures are also needed A system is a collection of subsystems Adding new requirements may invalidate existing designs (subsystems) The requirement ambiguities affect the subsystem requirement specification (e.g. schedule impact) Deriving lower level requirements can be far from trivial yet they are essential for proper design Documentation Anything that can be misunderstood will be misunderstood Use TBD (To Be Defined/Determined), TBC (To Be Confirmed) etc. to construct the big picture Measure the temperature every TBD seconds The link speed is 5Mbps (TBC)

110 System engineering troublemakers Emergent properties i.e. how the subsystems behave as a whole Not known before the complete system is fully integrated and being tested All grounding and EMC related problems will not be found in subsystem tests There will always be undocumented features in subsystems At this point in the project when subsystems are being integrated together, all schedule contingencies are often used by previous delays Part procurement Long lead (time) items order now, receive after 24 weeks or 16 months ITAR (International Traffic in Arms Regulations), non-us alternatives may or may not exist E.g. field programmable gate arrays (FPGA) E.g. US manufactured thermal white paint paint itself can be exported but painted parts cannot!

111 System engineering troublemakers Human resources and other soft matters Scope-schedule-cost-triangle pick any two and they will define the third! Organisational differences Many organisations are typically involved Resource availability Mission objectives (science output / technology development / education / profit) Communication Documentation, language Societal differences (culture, industry/university, work hours, time zones) Human personalities, experience, preferences and commitment Finding a good compromise that balances mass/performance/cost etc. can be difficult especially when the deadline is approaching Humans are optimistic in estimating how long it will take and how easy it will be