June 17, 2004 ? Massachusetts Institute of Technology, 2002 1 Software Engineering for Satellites Kathryn Anne Weiss Software Engineering Research Laboratory Department of Aeronautics and Astronautics Massachusetts Institute of Technology October 22, 2003 June 17, 2004 2? Massachusetts Institute of Technology, 2002 Topics of Discussion ? Background ?Why is Software Engineering Hard? ?Lifecycle ? Cost ? Requirements Specification ? Approaches to Design ? Implementation ? Testing ? Maintenance ? Why is Software Engineering Hard for Spacecraft? ? SERL Approach ? Component-Based Systems Engineering ?SPHERES ? Conclusions June 17, 2004 3? Massachusetts Institute of Technology, 2002 Background Ariane 5 Mars Climate Orbiter SOlar Heliospheric Observatory Courtesy of Arianespace / ESA / CSG. Used with permission. June 17, 2004 4? Massachusetts Institute of Technology, 2002 Background ? Why is Software Engineering Hard? ?“Curse of flexibility” ? ‘‘And they looked upon the software and saw that it was good. But they just had to add one other feature ...’’ ? No physical constraints ?Intangibility ?Lack of historical usage information ?Organized complexity ? Too complex for complete analysis ? Too organized for statistics ?Large discrete state spaces June 17, 2004 5? Massachusetts Institute of Technology, 2002 Background ? Software Lifecycle Feasibility Study V & V Requirements V & V Design V & V Implement ation V & V Testing V & V Maintenance V & V June 17, 2004 6? Massachusetts Institute of Technology, 2002 Background ? Software Cost Maintenance Testing Requirements Coding June 17, 2004 7? Massachusetts Institute of Technology, 2002 Requirements Specification ? Most critical portion of the software lifecycle ? Majority of errors in software can be traced back to flaws in the requirements ? Many methods and types of requirements including: ?Informal ?English ?UML ?Formal ?Zed ?State Machines ?Intent Specifications June 17, 2004 8? Massachusetts Institute of Technology, 2002 Approaches to Design ? Software design grew out of the structured programming movement beginning in the 1960s ? Many approaches to design including: ?Functional Decomposition ?Object-Orientation (OO) ?Event-based CBSE ?Agent Architectures ? What approach to Software Design is appropriate for Satellite Engineering? June 17, 2004 9? Massachusetts Institute of Technology, 2002 Implementation ? Only 10% of the software development effort!!! ?Other 90% made up of planning and testing ? Issues include: ?Programming Languages ?COTS and Reuse ?Interfaces June 17, 2004 10? Massachusetts Institute of Technology, 2002 Testing ? Examining a program to see if it does not do what it is supposed to do is only half the battle – the other half is seeing whether the program does what it is not supposed to do! June 17, 2004 11? Massachusetts Institute of Technology, 2002 Maintenance ? Comprises approximately 70% of the software lifecycle cost and time ? Issues include: ?Deployment and Training ?Code Changes ? Additional functionality ? Fixing bugs ?Diagnosis and Troubleshooting ?Job Turnover – understanding someone else’s code June 17, 2004 12? Massachusetts Institute of Technology, 2002 Why is Software Engineering Hard for Spacecraft? ? Spacecraft Software Structure and a Lack of Autonomy ? Loss of Domain Knowledge ? Miscommunication Among Multi-disciplinary Engineering Teams ?Proposed Solution: ?Component-Based Systems Engineering June 17, 2004 13? Massachusetts Institute of Technology, 2002 SERL Approach ? Intent Specifications ?Why? instead of merely What? and How? ?Design Rationale ? SpecTRM ?Specification Toolkit and Requirements Methodology ? SpecTRM-RL ?SpecTRM-Requirements Language June 17, 2004 15? Massachusetts Institute of Technology, 2002 SERL Approach (Cont.) ? Level 3 – SpecTRM-RL ?Easily Readable and Reviewable ?Unambiguous and uses simple semantics ? Complete ?Can specify everything need to specify ? Analyzable ?Executable ?Formal (mathematical) foundation ?Assists in finding incompleteness June 17, 2004 16? Massachusetts Institute of Technology, 2002 Component-Based System Engineering ? Functional Decomposition ?Spacecraft Level ? Command and Data Handling Computer ?Subsystem Level ? Attitude Determination and Control ? Power ? Thermal ? Communications ? Guidance and Navigation ? Propulsion June 17, 2004 17? Massachusetts Institute of Technology, 2002 Component-Based System Engineering (Cont.) ? Top-Down Decomposition ?Component Level ? Ex) NEAR’s Attitude Determination and Control Subsystem – Sun Sensors – Star Trackers – Inertial Measurement Units – Reaction Control Systems – Reaction Wheels June 17, 2004 18? Massachusetts Institute of Technology, 2002 Component-Based System Engineering (Cont.) ? Construct software and hardware intent specifications from the component level to the system level ? Specification Toolkit and Requirements Methodology – Generic Spacecraft Component (SpecTRM-GSC) ?Fully Encapsulated ?Well-defined Interfaces ?Generic ?Component-level Fault Protection June 17, 2004 19? Massachusetts Institute of Technology, 2002 Component-Based Systems Engineering (Cont.) ? Instead of performing CBSE, engineers can perform Component-Based Systems Engineering, in which the entire process of development (from the component- level to the system-level) is reused ? Benefits: ?Provides the benefits of Component-Based Software Engineering without the detrimental effects of improper implementation of reuse ?Supports the principles of systems engineering: ? Common means of communication ? Placing the component in context within the larger system June 17, 2004 20? Massachusetts Institute of Technology, 2002 Component-Based System Engineering (Cont.) ? The development is performed in a systems engineering development environment (SpecTRM) ? Benefits: ? Helps capture domain knowledge through recording rationale ? Abstracts away the details of design ? Provides various analyses ? Simulate design alternatives ? Nothing has been implemented at this point ? Easy to incorporate changes to the software ? Visualizations provide different perspectives on the same system June 17, 2004 21? Massachusetts Institute of Technology, 2002 SPHERES ? Synchronized Position Hold Engage Reorient Experimental Satellites Why SPHERES? 1. Autonomous 2. Highly modular 3. Test technique on a real system June 17, 2004 22? Massachusetts Institute of Technology, 2002 SPHERES (Cont.) June 17, 2004 23? Massachusetts Institute of Technology, 2002 SPHERES (Cont.) ? Two Guest Scientist Programs were modeled to illustrate: ?The feasibility/scalability of the technique ?The ease with which the components can be reused ?The process of building a new spacecraft configuration from already existing components June 17, 2004 24? Massachusetts Institute of Technology, 2002 SPHERES (Cont.) ? Rate Damper ?One Sphere Configuration ?Nullifies any angular rate experienced by the Sphere ? Leader/Follower (Rate Matcher) ?Two Sphere Configuration ?Follower Sphere matches the angular rate experienced by the Leader Sphere ? Demonstration June 17, 2004 25? Massachusetts Institute of Technology, 2002 June 17, 2004 26? Massachusetts Institute of Technology, 2002 June 17, 2004 27? Massachusetts Institute of Technology, 2002 June 17, 2004 28? Massachusetts Institute of Technology, 2002 Conclusions ? The research on and the test case application of Component-Based Systems Engineering show its potential for use in developing the next generation of spacecraft ? The benefits of using the technique span not only the engineering issues faced by today’s spacecraft development teams but also the difficulties inherent in the aerospace industry June 17, 2004 29? Massachusetts Institute of Technology, 2002 Questions and Comments