Concurrent Engineering in student course Practice Space Systems Engineering
- SECESA 2014 - 08-10 October 2014
Vaihingen Campus, University of Stuttgart Germany
Jian Guo (1), Arne Matthyssen (2), Martin Fijneman (2) (1)
Faculty of Aerospace Engineering, Delft University of Technology Kluyverweg 1, 2629 HS
Delft, The Netherlands Email: j.guo@tudelft.nl
(2) RHEA SYSTEM S.A.
Leiden Office, Schuttersveld 2, 2316 ZA Leiden, the Netherlands Email: m.fijneman@rheagroup.com
INTRODUCTION
Systems Engineering (SE) has long history of being a key element of the curriculum in the Faculty of Aerospace Engineering, the Delft University of Technology (TU Delft-AE). From the first year bachelor course to the final year master thesis project, SE is embedded into lectures, assignments, individual projects, and group projects. As part of this curriculum, the MSc track Space Flight provides two dedicated courses on SE: Space Systems Engineering AE4-S12 focuses more on theoretical side, and Practical Space Systems Engineering AE4S12P, a follow-up of AE4-S12, aims at providing students an opportunity to practise the methodologies and tools that were taught in AE4S12. More recently, Concurrent Design and Concurrent Engineering have been introduced in the Practical Space Systems Engineering course, in which the students are divided in several groups. These groups will go through the design steps of a Concurrent Design process, touching upon the phases and tasks. At the end of the project, the foreseen result is for each team to have formulated a set of high-level requirements and a high-level solution direction for the system.
This paper provides details of the design and implementation of the course Practical Space Systems Engineering course, with a special interest on the Concurrent Engineering element. The paper starts with a description of the setup of the course, its objectives and the approach taken. The course in general consists of several central contact hours, and hours that should be spent per group to work on the project assignment. In the beginning of the project, the course itself is introduced, and a description is given of the Concurrent Design approach, and the tools used. After this first introduction, the topic for the assignment is presented. Given the limited time and study effort that is available for the course, a suitable topic for the assignment is found in the FireSat example from the Space Mission Analysis and Design (SMAD) [1]. The objective is to apply the Systems Engineering methodology in a team of engineers and using collaborative tools, more than to come up with complete and comprehensive requirements and design itself.
The paper will then describe the process and the supporting tools that are used in the course. The students perform the project assignment in smaller groups, making a division of tasks between themselves. The course is supported with the Concurrent Design Platform, the CDP™. A short training is provided to train the students in using the concepts needed within the scope of the student project, taking a focus on the Requirement Manager. A Product Tree can be setup using generic building blocks, derived from a library that holds the most important parameters, according to a subset of the ECSS-E-TM-10-25 [2].
The last part of the paper will describe the results of the course, as well as present the experience, provided feedback and lessons learned. In general, the application of the Concurrent Design process and methodology was found very useful by most students. It was seen as beneficial, and applicability for other student projects and assignments was expressed. To take into account the limited time available, the process, training and the tools should be reviewed to highlight and present the required basic steps and functionalities, as the students do not have enough time available on the course to go in too much detail. The effort and time of the course may be extended as well, to provide the students with a better learning experience.
COURSE SETUP AND OBJECTIVES
In this chapter, the setup and objectives of the course AE4S12P Practical Space Systems Engineering are described, starting from an overview of SE relevant courses in TU Delft-AE.
Overview of SE Courses in TU Delft-AE
As aforementioned, the SE element has been embedded into the whole curriculum of the TU Delft-AE, from lectures, assignments, to individual projects and group projects. Table 1 is an overview of typical courses of TU Delft-AE that have strong SE content. From Table 1 it can be found that SE theory and practise have been provided at BSc level; however at MSc level two courses dedicated on SE are given, partially for in-depth understanding and practise, partially due to the fact that around 1/3 of TU Delft-AE MSc students had their BSc education in other institutes without SE background.
Table 1. Overview of SE courses in the curriculum of TU Delft-AE
Level of education Course with SE Remark
1st year of BSc AE1222-II: Aerospace Design & Systems
Engineering Elements I
Introduction on SE elements including functional analysis, requirement generation and concept trade-off
2nd year of BSc AE2111-II: Aerospace Design & Systems
Engineering Elements II
Follow-up of AE1222, using real world aircraft/spacecraft as show cases for SE
3rd year of BSc AE3211-I: Systems Engineering &
Aerospace Design
Further SE elements including design iterations, verification and validation, etc.
AE3200: Design Synthesis Exercises (DSE) 10-week 10-person full time group design project
with extensive usage of SE
1st year of MSc AE4S12: Space Systems Engineering In-depth theory of SE
AE4S12P: Practical Space Systems Engineering
Follow-up of AE4S12, focusing on practise SE methodologies and tools in a systematic way
This paper focuses on the MSc course AE4S12P Practical Space Systems Engineering. However, as a follow-up course of AE4S12 Space Systems Engineering, the latter is also briefly introduced here.
Precursor Course Space Systems Engineering
The course Space Systems Engineering (AE4S12) is required to have been taken by students before admission to the practical course. This MSc course introduces the main aspects of the Space Systems Engineering process in Spacecraft Conceptual Design, and in its setup covers:
• Introduction • Project management • Functional analysis • Requirement analysis
• Design option analysis and trade-off • Technical risk analysis
• System conceptual design • Verification and validation
The focus in course AE4S12 is the process for designing systems, covered by topics such as identifying stakeholder needs, generating, evaluating and selecting concepts, translating stakeholder expectations to technical system requirements, setting up logical decomposition and design solutions, estimating lifecycle costs, and managing technical risks. Furthermore it presents methods and tools to manage the Systems Engineering process, covering management of technical effort as well as managing interfaces and configuration in the design process.
An overview of the Systems Engineering processes as presented in course AE4S12 is given in Fig. 1.
Setup of the Practical Course
The main objective of the course (AE4S12P) as a follow-up is to implement the conceptual design of space systems using an end-to-end Systems Engineering approach.
Systems Engineering (SE) is more an experience-based discipline rather than theory-based. Since knowledge on SE processes and tools have already been taught in the precursor course AE4S12, the goal of the follow-up course AE4S12P Practical Space Systems Engineering is [3]:
The course shall provide students an opportunity for practicing their SE knowledge and gaining hands-on SE experience.
The top-level learning goal for students is:
Participants will be able to implement the conceptual design of space systems using an end-to-end Systems Engineering approach.
The following learning objectives are retrieved or modified from the course AE4S12, with an emphasis on practicing aspect:
1. Participants shall be able to design an end-to-end SE process for a space system demonstrating a credible feasibility of that process.
2. Participants shall be able to analyze and critically review a SE process in terms of its completeness and feasibility.
The above learning objectives are related to Bloom’s taxonomy [4], as shown in Table 2.
Table 2. Relation of learning objectives (LO) to Bloom’s level of learning LO # Bloom’s level
1 5 (synthesize) 2 6 (evaluate)
According to [5], there are seven typical instructional formats, each associated with one or more scopes. The learning objectives of the AE4S12P are at Bloom’s level 5 to 6, which indicates the most suitable instructional formats are
design and projects, both have scopes Application and Integration. Due to practical considerations such as study load
and the continuity with the course AE4S12, it is decided that the AE4S12P should utilize design projects as the core instructional format and lectures as the supplement.
One major challenge for this practical course is that it is required for the students to implement a DSE-like (see Table 1) project within 1 ECTS. The number of contact hours, as well as the overall time that students should spend on the course is therefore very limited. As a second challenge, students are usually lacking experience in the analysis and design of space missions which is a typical prerequisite of good Systems Engineers.
The course is opened with a lecture, providing introductions on the course and assignments. The SE principles and tools to be used are introduced, including a Concurrent Engineering tool training (2 hour).
The lecture is followed by a group assignment amounting to 22 hours. For this, a group report has to be delivered at the end of the course. The main aspect of the group assignment is to promote synthesizing and evaluating skills in a collaborative learning experience. An individual assignment of 4 hours is implemented, for which an individual report has to be provided. This assignment promotes evaluating skills in a reflective learning experience.
In this course, the students are divided in 2 main groups for the group assignment, with the following tasks: • Group A
o Act as customer o Interact with Group B • Group B
o Act as contractor o Implement SE o Write group report o Be assessed as a group
The individuals in Group A will have to evaluate the reports from Group B, next to writing an individual report. The participants in Group A are assessed individually..
In terms of planning and execution, the course is scheduled for a total duration of approximately 7 weeks. After the opening lecture, the students have to form groups and perform the assignment, taking the following steps:
• Step 1: Project management (assign roles and inform the lecturer) • Step 2: Investigate the FireSat example
• Step 3: Implement the SE process
• Step 4: Prepare for the CE session (can be parallel with Step 3) • Step 5: Implement the CE session
• Step 6: Documentation
Working on the group assignment is targeted at an average of 4 hours per week. For this group assignment, a lecture room was available for half a day each week.
The student teams started from project kickoff, and finish after System Conceptual Design with a requirement verification. Throughout this assignment, a SE process had to be implemented, incorporating the SE elements or tools that were taught in AE4S12. Additionally, the Concurrent Design Platform (CDP™) of RHEA was used as a Concurrent Engineering tool in support of the team effort to come up with a high-level design solution in the project work for the assignment.
The intention was to work with the FireSat project example in the SMAD book [1].Any information in the SMAD book could be used by the student teams with the appropriate justification. The project work that was performed should be well documented.
For the final result of the group assignment, a set of grading criteria was applied: • Assessment of using CE tool (30%)
• Usage of SE methods and tools (30%) • Design quality (30%)
• Completeness and style (10%)
For the individual assignment, 4 hours are available. Students are required to individually evaluate the group assignment submitted by other groups. The evaluation focuses on the SE aspect, not too much the design itself. This evaluation has to be well documented. The grading criteria for the individual report are the following:
• Quality of evaluation on technical contents (40%)
• Quality of evaluation on usage of CE tool, SE methods and tools (40%) • Completeness and style (20%)
For the final reporting, the students in group B should present a set of high-level requirements and a high-level solution direction for the system. As can be seen from the grading structure however, the report should also provide information on the Systems Engineering processes and methods that are used by the students to perform the assignment. The focus in performing the assignments by the groups should be to apply the Systems Engineering methodology in a team of engineers and using (collaborative) tools, more than to come up with a complete and comprehensive set of requirements and a complete design itself.
SYSTEMS ENGINEERING PROCESS AND SUPPORTING SE METHODS AND TOOLS
In the course Space Systems Engineering (AE4S12), several methods and tools are presented to support the Systems Engineering processes as given in Fig. 1.
Examples of methods and tools related to project management are Work Flow Diagrams (WFD), Work Breakdown Structures (WBS), usage of Gantt charts to schedule the tasks (as given in the WBS) and in the given sequence (according to the WFD).
A central aspect in the SE processes is managing requirements. Organising requirements in e.g. a Requirements Discovery Tree (RDT) will provide insight in what the system should do and how it should perform, followed by an elaboration and consolidation of the requirements. Identification of the main or “killer” requirements is used to focus attention in the design effort to make sure the system will be live up to the expectations of the customer, representing what the system should in any case be able to do to be considered a successful system.
For the technical processes, examples of methods and tools are performing a functional analysis, creating a Functional Flow Diagram (FFD) and a Functional Breakdown Structure (FBS), N2 Charts for functions or (physical) elements can be used to identify interfaces for the system design. Based on the (main or high level) requirements design options need to be derived, after which the most promising design options will need to be evaluated, first at a system level, followed by a detailing at the subsystem level.
For the options that are identified and investigated during the design process, a trade-off process will need to be applied to determine which option is the most promising to deliver a successful system. In these trade-offs, identification of the drivers on which to rate and compare the options is crucial, next to the task of providing traceability from the technical specifications back to the requirements of the customer.
Several parts of the, mostly technical, SE processes, are implemented in this course using the Concurrent Design (CD) approach and principles:
• A multidisciplinary team working together to exchange, share and discuss all aspects of a design • A structured and guided design process
• The presence of the customer providing feedback on the main design and trade-off decisions • Using one common reference model
• Turning multidisciplinary design sessions into concrete values supported by experts • Representing all perspectives of the product life cycle
The iterative design process of CD is performed by the student teams using the Concurrent Design Platform (CDP™) of RHEA, a Concurrent Engineering tool containing the principles of Concurrent Design as an integral part of the tool to reach these objectives, such as the notion of options, domains, decomposition levels, and the actual parametric setup of the design in the CDP™ Product Tree.
The CDP™ is thus used to support the team effort to come up with a high-level design solution in the project work for the assignment. The CDP™ can be used to create an integrated parametric design with supporting calculations, focused on allowing a multidisciplinary team to create and share up-to-date design information. Furthermore, it provides a clear audit trail in the design process, and the possibility to link the design to requirements through the integrated CDP™ Requirements Manager.
IMPLEMENTATION AND RESULTS OF THE COURSE
The course AE4S12P has been implemented for 4 years and received positive feedback from students. In this section, the implementation of the course in the 2013-2014 academic year is briefly introduced, followed by the results on performing Concurrent Engineering within the course since this is the focus on this paper.
Implementation
In the 2013-2014 academic year, there were in total 20 MSc students participated in the course from the beginning to the end. These students are divided into two groups, each consisting of 10. Since there were only two groups, each group has to take two roles: as customer to interact with the other group and assess their report and; as contractor to implement SE and write group report.
Both groups identified requirements with the customer for the FireSat example, used information from SMAD as a basis to avoid (re-)inventing too much for the full range of possible tasks within the Systems Engineering processes that the students were encouraged to implement. The project was geared towards the student teams performing a Concurrent Engineering sessions, taking a focus on performing design iterations with their team members, involving if possible the customers from the other group.
Approaches taken by teams include the definition or identification of: • mission statement
• requirements, with RDT
• function analysis, with FFD, N2 chart
• project tasks, with WBS, WFD and Gantt-charts • design options, with Design Option Tree (DOT)
• trade-off, with both numerical scoring scheme and Analytical Hierarchy Process (AHP) • risk analysis, with risk map
Due to time constraints of the course, the SE element of verification and validation was not implemented in the practice but was taken into account by the students. The correct and successful application of SE methodologies and tools by students indicate a good mastering of SE knowledge in practical (if not real) environment.
Results on Performing CE
For usage of the CDP, the student teams provided useful feedback and comments. One recurring point of comment was the choice of supported platforms, limited to specific Windows and Office versions. The CDP as a commercial tool is geared towards software and platforms mainly used in large companies and organisations. This is closely connected to the choice for Excel integration in the CDP. In academic environments in general, and for students in particular, these are usually frontrunners in developing and applying new technologies: pure from a software point of view, a wider variety of platforms and software, either commercially available or open source, is used by students that is not always compatible with the standard industry environment.
After the initial presentation and training, the CDP, the CDP is available to the student teams with a generic space model available in it. The student teams experienced the effort needed for setting up the CDP models and calculations as time-consuming with respect to the total time available for this part of the assignment. The possibility to use a template activity specifically adapted to the FireSat example could be explored, with more and better models and calculation sheets for the domain specific CDP Workbooks already available, to enable the teams to have a faster start. Some difficulties were reported by the student teams, both from a SE/CE process point of view, and from a technical point of view in using the CDP, that are mostly caused by having no team members with experience in a SE role, and inexperience in using the CDP. Having to learn, adapt and apply all this at the same time, while also working on the technical details of the assignment was found to be difficult. A suggestion made by some team members would be to include in the teams in the role of SE someone who is already knowledgeable in the design process, and has more experience with the program.
Most participants regard the CDP as a powerful, complex tool to support complex design projects. The feedback provided by the different team members indicates however that usage of the CDP will have more added value on larger student projects, such as the DSE, or larger Master projects, where more time is available to get experience with it and go through several design iterations to get a good result. For the scale of the project with the number of contact hours limited to 4-6 hours a week in a 5-week period, where only a part of this time is intended to use Concurrent Design and
the CDP and many other tasks need to be performed and tools and methods need to be used, the usage of the CDP needs to be better integrated within the scope of the assignment.
A better selection of functionality could be made to offer to the students, allowing the teams to have a better targeted usage of the CDP in their projects.
Possible adaptations and customisations in the functionality and representation of the CDP to better serve the needs of student teams in educational projects, or more generally for inexperienced users in smaller projects, are worthwhile to investigate, together with possible adaptations to the Concurrent Design process, to be able to have a better fit with the specific demands and objectives for the use within an educational environment, especially for smaller-scale group assignments. With a higher level of complexity, and especially more time available for students to spend on the project, the CD process and the CDP as they are now are expected to already provide a benefit with respect to the results that can be achieved for larger projects, such as the DSE itself, or larger Master-course projects.
CONCLUSIONS AND RECOMMENDATIONS
The course Practical Space Systems Engineering of TU Delft-AE is introduced with details in the paper. Its position in the curriculum, course setup, SE processes and tools used, and the implementation are described. A special interest is on the Concurrent Design and Concurrent Engineering aspect.
The CDP™ was provided by RHEA to TU Delft-AE as Concurrent Design and System Engineering tool. After an initial presentation and training, the CDP™ is made available to all student teams and a generic space model is provided as starting point.
Most participants regard Concurrent Engineering as a powerful methodology and tool to support complex design projects. The feedback provided by the different team members indicates that usage of the CDP™ will have even more added value on larger student projects, such as the DSE, or larger Master projects, where more time is available to get experience with it and go through several design iterations to get a good result.
For the scale of the smaller student projects with a limited number of contact hours , 4-6 hours a week in a 5-week period, with only a part of this time is intended to use Concurrent Design and the CDP™ and many other tasks need to be performed and tools and methods need to be used a CDPLite™ can be considered to better comply with the assignment scope.
Having to learn, adapt and apply all this at the same time, while also working on the technical details of the assignment was understandably found to be difficult. A suggestion made by some team members and RHEA would be to include in the teams in the role of SE someone who is already knowledgeable in the design process, and has more experience with the process and tools used.
As a result of the usage of Concurrent Engineering, especially the CDP™, TU Delft together with EPFL (CH) and Hoge School Zeeland (NL) and RHEA are preparing the creation of a CDLite™ and CDPLite™ for the usage of Concurrent Design in SME and academia and other educational organisations.
REFERENCES
[1] J. Larson and J.R. Wertz, Space Mission Analysis and Design, 3rd edition. Wiley. 1999. [2] System Engineering - Engineering Design Model Data Exchange (CDF). ECSS-E-TM-10-25.
[3] J.Guo, Educational Concept of the Course “Practical Space Systems Engineering”, Delft University of Technology, 2009
[4] Bloom's Taxonomy, http://en.wikipedia.org/wiki/Bloom's_taxonomy. Retrieved in March 2009.
[5] E.Gill, Educational and Thematic Concept of the Course “Space Systems Engineering”, Delft University of Technology, 2009
