Responsive Space System Engineering: methodologies and tools prototype

Transcription

1 Responsive Space System Engineering: methodologies and tools prototype DOC-TAS-EN-001 Technical University of Lisbon, Lisbon,

2 Summary This paper reports the activities performed by Thales Alenia Space (F) and Daysha Consulting (IRL) to assess system engineering methods and tools to be developed for usage in responsive space programs for ESA. 2 Responsive Space concepts are available in the US, developed primarily for military purposes. Responsive missions are categorized in terms of rapidity from kick-off to operational phase as Tier 1 (one week), Tier 2 (one month) or Tier 3 (one year). The interest in RSSE methodology for ESA is to minimize the duration of the spacecraft development life cycle and to open new mission capabilities. Responsive Space Concepts are emerging especially in US ESA interest is to minimize S/C development cycle and open new mission capabilities

3 State of the Art methods and tools. Activity started with analysis of the State of the Art methods and tools Responsive Space Systems Engineering Activities were identified ongoing worldwide, the majority occurring in the USA. Responsive Space is at the point of operational use, and that Responsive Spacecraft development is possible, even in a timeframe as short as seven days. No single method or tool is employed to achieve Responsive satellite development, in achieved Responsive Space development M&T are used in combination, Through Brainstorming Sessions with senior engineers, 140 new ideas of tools and methodologies to minimize development duration were found. These could be condensed in 35 of particular interest for the study. These 18 SE Activities and the 35 ideas could then be regrouped in a list of 10 Methods and Tools Categories. The first activity was a Survey of State of the Art M&T. Outcome is the definition of a list of 10 Methods and Tools Categories including 53 identified M&T

4 Methods and tools categories Parallelisation of tasks: behind this concept there is the idea that tasks should be parallelised at the maximum extent 4 Building Block Modular Approach: behind this concept there are two ideas, the definition of modular spacecraft and stocks or databases of these modules Standardisation of Interfaces: behind this concept there is the idea that the building blocks interfaces are completely defined and validated for each crosscoupling Standardisation of Requirements: behind this concept there is the idea that no requirement have to be written a second time, everything is included in the definition of the constituting blocks Accept Higher Risk and possibly of Lower Quality: behind this concept there is the idea that validations could be avoided accepting higher risks and diminishing the quality of the Spacecraft design

5 Methods and tools categories Integrated Design Tool: behind this concept there is the idea that the design part could be completely automated 5 Test by Simulator: behind this concept there is the idea that many tests could be made on virtual entities Fast AIT: behind this concept there is the idea that many tests could be made on virtual entities Avoidance of Just in time procurement: behind this concept there is the idea that the procurement have to run outside the project lifecycle, every block should be already manufactured prior the start Responsive Procurement Method: behind this concept there is the idea that the procurement have to be managed differently than for standard projects, These M&T are cross-coupled

6 Applicability to ESA Each of the tools / methods identified is analysed in terms of applicability to the ESA environment. 6 Every tool has at least some applicability to the ESA environmental context Many touch critical aspects of both the ESA Systems Engineering process, as well as the overall ESA Development Cycle. The applicability of the identified M&T to ESA environment is analysed. M&T are applicable, but touching critical aspects

7 Applicability to ESA Mission needs Requirements Standardization 2 NECESSARY STEP * Applicable to ESA * Mandatory for rapid procurement * Large expected «R.O.I.» TOP LEVEL NEED * Highly applicable to ESA * Pre-requisite for RSSE 2 Interface Standardization Building Block Catalog 1 HIGH IMPORTANCE ASPECT * Applicable to ESA * Mandatory for rapid BB connections * Possible share benefit with usual prog. Complete BB virtual models Depends on Mission type Anticipated h/w production 1? 2 HIGH IMPORTANCE ASPECT * Mandatory for Tier2 * Necessary for many BB in Tier3 case * If h/w not OTS at Service call-up complete virtual models shall be available in advance 7 1 RS S/C procurement Design origin? ESA or Industry? Integrated Design Tools 2 Fast AIT 3 CONCEPT TO BE INVESTIGATED * Applicable to ESA, TBC * New concept * TBD way of implementation HIGH LEVEL NEED * Highly applicable to ESA * ESA current process very long * Necessary big change in ESA procurement philosophy LARGE NEED OF TOOL DEVT * Highly applicable to ESA * Tools shall cover all aspects, not only Design * Ultimate goal: Global tool connecting all the RS aspects (Spec, design, AIT, h/w, s/w, processes, ) 2 Test by Simulation 3 NOT A NEW CONCEPT * Applicable to ESA * TBD way of implementation Acceptance of Higher Risks and possibly Lower Quality Parallelization of tasks 3 Legend: Preliminary priority level NOT A NEW CONCEPT * Applicable to ESA * Will improve the responsiveness but not as major contributor BROAD CONCEPT * Highly applicable to ESA * Request a cultural step in ESA * TBD way of implementation Methods and Tools are analysed in term of compatibility with ESA environment, ranked in term of priority and interconnected in the design development flow

8 Spacecraft Development Cycle Analysis The study decided to focus on two LEO S/C categories to correctly estimate the impact that every M&T identified has on the development cycle: a mini satellite compliant with Tier 3 case, a micro satellite compliant with Tier 2 case. Tier 1 was considered out of scope of the analysis. 8 The study examined the defined M&T combined with the industrial practices and lessons learned from past projects to determine a first estimate of the S/C development cycle duration for both cases, the best tools implementing the methodologies, the requirements of these tools in a top down approach, the costs and development planning of these tools the applicability these tools have to CDF environment When analysing current Thales Alenia Space products it is possible to note that various methodologies identified are already in place up to a certain level. Ex: Proteus and Prima Standard Mini Satellite class Platforms are already part of the NASA RSDO (Rapid Spacecraft Development Office) catalogue. Methods and Tools are analysed in term of compatibility with ESA environment, ranked in term of priority and interconnected in the design / development flow

9 Responsive Spacecraft Development Cycles 9 Tier 2 (left) and Tier 3 (right) development flow as retained possible adopting all the identified M&T

10 Tools supporting RS Development Cycles 10 The Tools identified as necessary to achieve RS capabilities are: MDT: Mission Design Tool To generate a mission design rapidly considering all the RS context through dynamic links with all RS databases SPT: Satellite Procurement Tool To rapidly elaborate the procurement package following a specific responsive format BBMT: Building Block Management Tool To exploit the RS various databases (satellites components, launcher capacities, RS facilities, etc ) and link them to the other RS tools (MDT, SVM, DMT, ) SVM: Satellite Virtual Model Complete model of the satellite used as the reference for the whole spacecraft development sequences (design, performances assessment, manufacturing, testing) DMT: Development Management Tool To simulate accurately all the times aspects related to the satellite development (as well for anticipation as for activities follow-up or tracking or reporting) TOG: Teams Organization & Geo-location To optimize and organize all the RS resources and facilities SPAT: Staff Performance Assessment Tool To manage and optimize the work efficiency of the shared activities (especially when several teams are working in parallel), to optimize the information exchange between the team members and 7 tools are identified as necessary to support Responsive Space Development Cycles

11 Responsive Space Tools Trade-Offs 11 The consortium performed a complete analysis of the gains expected coming from the use of the tools in the various phases. The tools used in the development phase showed good planning benefits, they play an important role in matching the planning of an RS project. This is consistent with the fact that those tools are applicable to the development and production phases phases that have the longest timeframes and largest resource consumption. Two tools show similar planning benefits and are expected to play a major role in the matching of RS projects planning for both TIER categories The Satellite Virtual Model The Development Management Tool with the TOG and SPAT plug-ins A complete trade-off among tools is performed to determine the most efficient. The winners are the Satellite Virtual Model and the Development Management Tool

12 Responsive Space Tools Trade-Offs 12 The trade is based on multiple criteria, covering costs, development duration and effort, applicability to Industry, ESA in general and to CDF in particular

13 Responsive Space Tools Development Plan 13 The road map for RS capabilities implementation in ESA requires successive tools and methodologies development. Activities should be made in cooperation with interested industries helping to support the road map. Activities should be held with a specific mission in the road map to stimulate industry to concur to the solution proposing innovation. In principle a tight planning can provide a first RS prototype application in 5 years, a time scale equivalent with standard satellites. In fact most of the program duration would be taken to define the supporting tools and methodologies. Advantages will be seen only as from the second application. Complete development plan is estimated on the basis of the development duration of the various tools and their interdependencies. The time scale is equivalent with std satellites, advantages will arrive since the 2 nd satellite

14 Responsive Space Tools Development Plan 14 ID Task Start End Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q Q Q1 Q2 Q3 Q Q1 Q2 Q3 Q4 1 Call for Interested Industries 01/01/ /09/ Standard IF definition 01/05/ /05/ Definition of Responsive Procurement normative framework 28/03/ /09/ Definition of acceptable quality and complexity for RS missions 01/04/ /04/ Definition of Virtual Models and frame for testing and validation through simulators 04/10/ /04/ Standard requirements definition 01/06/ /06/ Building Block Catalogue 03/10/ /12/2018 Standard equipments and procedures 8 07/04/ /01/2018 for automatic AIT/AIV 9 MDT 09/06/ /12/ BBMT 21/11/ /12/ SVM 24/04/ /12/ SPT 01/12/ /12/ DMT 23/05/ /12/ TOG 23/03/ /12/ SPAT 05/06/ /12/ First RS mission 05/01/ /01/ years is a good time scale to develop RS capabilities. Shorter time frame could be possible when starting with smaller satellites.

15 Tool prototype definition 15 To finalize the study the team developed a prototype edition of the RS environment. To limit development duration only a subset of the identified tools, and a mock up edition of the remaining was achieved. One tool in particular, the programmatics domain specific tool was the central focus of the effort as it deemed the most interesting from CDF perspective. Due similarities the tool development went in parallel: one dedicated to RSSE a version applicable to Concurrent Engineering and CDF Sessions. Thales Alenia Space and Daysha Developed a mock-up of an entire RS framework, prototyping only few fonctionalities. The focus was the Development Management tool interesting also for CDF

16 Tool prototype schema 16 RSSE Environment Intelligence Standard High Level Requiements Design Algo s Planning Algo s Risk Algo s DST Visualiser Staff performance assessment Agenda (TOG) RS BB DB Virtual Models DST Environment/s CATIA Simulators Planning Others DBs Functions completely prototype are encircled Supporting functions, partially prototyped are dotted Other parts are only mocked-up

17 Planning Algorithm To develop a version of the tool for usage in standard project in CDF a specific planning for standard project was also included on the basis of past projects planning. 17 The same set of projects was used to derive statistical data and define a planning algorithm as core of the tool. Proteus Jason 1 + 5PF (Calypso, Corot, SMOS, Jason 2, Jason 3) Myriade Picard (CNES) Herschel and Plank The first two classes are applicable for RSSE area of interest, but they benefit from the product line effect. The various Proteus Platforms are derived from the first model (Jason 1), with lessons learned helping to decrease the development duration for each subsequent mission. H/P is introduced to provide good single-model prototype base. CDF studies, with ESA s science department often the customer, are more related to single-model prototypes than product lines. Planning Algorithm is introduced to support programmatics discipline to determine the planning for CDF studies using TAS planning database

18 Building Block Database 18 To support the prototype demonstration the Building Blocks database is filled with two existing spacecraft functional chains compatible Tier 2 and Tier 3: The ELiTe P/F TheTAS Myriade P/F Myriade and Elite P/Fs data are used to support prototype demonstration

19 Mission Design Tool 19

20 Building Block Database 20

21 Development Management Tool 21

22 Development Management Tool Algorithm 22

23 Development Management Tool Algorithm settings 23

24 Development Management Tool Algorithm settings 24

25 Development Management Tool Probability Chart 25

26 Building Block Database Timeline view 26

27 Development Management Tool Export 27

28 Conclusions The analyses performed on the study gave a better insight on a complex matter that is how to diminish program duration to its lower level. 28 It is challenging, but possible to develop a complete Spacecraft in time as short as one month. Multiple methodologies exist and many are already partially implemented in spacecraft lifecycle especially on commercial products. All the methodologies found are applicable to ESA environment, but requiring critical changes in the current process. Responsive Space System Office should be possibly created with ad hoc policies in order to bypass current limitations that can remain for standard project. Many of the methodologies are applicable to standard project helping in minimizing the duration, but also allowing a better reuse of products, reducing delta-developments and delta-qualifications. The software layer is important to implement the methodologies. Many tools could play an important role to diminish the duration of studies or to better assess duration of standard projects since the beginning. It is possible to perform Responsive Space Program in timeline as short as 7 days also in ESA environemnt. Methodologies and Tools exists and could be possibly help reducind duration also of standard programs

29 Conclusions An extensive analysis of each tool, allowed to determine the best suited tool to be prototyped in the frame of the study a consistent road map for Responsive Space Capabilities implementation in ESA. 29 RS capabilities can be implemented for ESA in a timeframe comparable with short standard programs, roughly five years. It may be possible to shorten this timeframe implementing RS capabilities for nano-satellites first. While the RS framework had to be only mocked-up for study limitations, the focus of the development was ported to the Development Management Tool. This tool was determined to be the most valuable for the study and to achieve RS capabilities. It was possible to make it applicable to the CDF for standard studies. A complete analysis of the tools is performed allowing to determine the best tool suite to be prototyped and a consistent development plan