Software Engineeringfor SatellitesTopics of DiscussionBackgroundBackgroundBackgroundBackgroundRequirements SpecificationApproaches to DesignImplementationTestingMaintenanceWhy is Software Engineering Hard for Spacecraft?SERL ApproachSERL Approach (Cont.)Component-Based System EngineeringComponent-Based System Engineering (Cont.)Component-Based System Engineering (Cont.)Component-Based Systems Engineering (Cont.)Component-Based System Engineering (Cont.)SPHERESSPHERES (Cont.)SPHERES (Cont.)SPHERES (Cont.)ConclusionsQuestions and CommentsJune 17, 2004 © Massachusetts Institute of Technology, 2002 1Software Engineeringfor SatellitesKathryn Anne WeissSoftware Engineering Research LaboratoryDepartment of Aeronautics and AstronauticsMassachusetts Institute of TechnologyOctober 22, 2003June 17, 2004 2June 17, 2004 © Massachusetts Institute of Technology, 2002Topics 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 ConclusionsJune 17, 2004 3June 17, 2004 © Massachusetts Institute of Technology, 2002BackgroundAriane 5Mars Climate OrbiterSOlar Heliospheric Observatory Courtesy of Arianespace / ESA / CSG. Used with permission.June 17, 2004 4June 17, 2004 © Massachusetts Institute of Technology, 2002Background 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 spacesJune 17, 2004 5June 17, 2004 © Massachusetts Institute of Technology, 2002Background Software LifecycleFeasibilityStudyV & VRequirementsV & VDesignV & VImplementationV & VTestingV & VMaintenanceV & VJune 17, 2004 6June 17, 2004 © Massachusetts Institute of Technology, 2002Background Software CostMaintenanceTestingRequirementsCodingJune 17, 2004 7June 17, 2004 © Massachusetts Institute of Technology, 2002Requirements 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 SpecificationsJune 17, 2004 8June 17, 2004 © Massachusetts Institute of Technology, 2002Approaches 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 9June 17, 2004 © Massachusetts Institute of Technology, 2002Implementation Only 10% of the software development effort!!! Other 90% made up of planning and testing Issues include: Programming Languages COTS and Reuse InterfacesJune 17, 2004 10June 17, 2004 © Massachusetts Institute of Technology, 2002Testing 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 11June 17, 2004 © Massachusetts Institute of Technology, 2002Maintenance 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 codeJune 17, 2004 12June 17, 2004 © Massachusetts Institute of Technology, 2002Why 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 EngineeringJune 17, 2004 13June 17, 2004 © Massachusetts Institute of Technology, 2002SERL Approach Intent Specifications Why? instead of merely What? and How? Design Rationale SpecTRM Specification Toolkit and Requirements Methodology SpecTRM-RL SpecTRM-Requirements LanguageJune 17, 2004 15June 17, 2004 © Massachusetts Institute of Technology, 2002SERL 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 incompletenessJune 17, 2004 16June 17, 2004 © Massachusetts Institute of Technology, 2002Component-Based System Engineering Functional Decomposition Spacecraft Level• Command and Data Handling Computer Subsystem Level• Attitude Determination and Control• Power• Thermal• Communications• Guidance and Navigation• PropulsionJune 17, 2004 17June 17, 2004 © Massachusetts Institute of Technology, 2002Component-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 WheelsJune 17, 2004 18June 17, 2004 © Massachusetts Institute of Technology, 2002Component-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 ProtectionJune 17, 2004 19June 17, 2004 © Massachusetts Institute of Technology, 2002Component-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