¶ Concurrent Engineering
If you are part of the eSpace team and new to this wiki, you need an account to log in and have full access to content of the wiki. Contact David and your account will be set up right away.
¶ Definition
There are many definitions of the meaning of “Concurrent Engineering” (CE) the following one is used at European Space Research and Technology Centre (ESTEC):
"Concurrent Engineering is a systematic approach to integrated product development that emphasizes the response to customer expectations. It embodies team values of co-operation, trust and sharing in such a manner that decision making is by consensus, involving all perspectives in parallel, from the beginning of the product life-cycle."
There are also many other simpler definitions like this one:
“Concurrent engineering, also known as simultaneous engineering, is a method of designing and developing products, in which the different stages run simultaneously, rather than consecutively. It decreases product development time and also the time to market, leading to improved productivity and reduced costs.”
Essentially, CE provides a collaborative, co-operative, collective and simultaneous engineering working environment.
More about history of Concurrent Engineering here.
ESA wiki about COMET documentation and concurrent engineering.
¶ Concurrent design
Concurrent design is a system engineering technique for design, development and technical management of a “product” based on:
- Real-time/simultaneous, co-located interactions of several specialists/disciplines
- Complete sharing of “product” data
- Team work and decision by consensus
- Active participation of the customer/user
For space systems the “product” is the space mission design or the spacecraft or any of its components (incl. payload)
The concurrent design approach is based on five key elements:
-
a process: Processes are the mechanisms used to run design sessions, such as the system development processes being considered and their specific implementation in facility operations. Projects may follow spiral development processes, waterfall development processes, combinations of these two, and any other development process of choice.
-
an infrastructure: is the physical embodiment of the facility, in terms of rooms and space used to facilitate the succession of interaction, concurrency, design work, and discussion, with processes running in parallel and oftentimes distributed in space and time – with study participants that are potentially also spread through the globe (Concurrent Design Facility (CDF)). Here is an article about establishing a Concurrent Design Facility. Below is an image showing the layout of the CDF at ESA/ESTEC (M. Bandecchi et alli, "The ESA/ESTEC Concurrent Design Facility", In: Proceeding of EuSEC (2000).). See our adaptations for the eSpace CDF.
-
a multidisciplinary team: is a core subsystem of a concurrent facility and represents one of the elements of major value and major source of complexity at the same time. The team includes experts leading design sessions, whom are educated in operating a CE environment as systems engineers, and experts that work in design teams and bring in disciplinary knowledge from their departments of origin. The figure above shows the types of experts that are expected during the desing of a space mission.
-
Software/hardware infrastructure: includes hardware and software installed in a CE facility. These include infrastructure for data storage, data processing, data sharing, visualization tools, specialist design software, collaboration tools, videoconferencing, and other means.
-
A Concurrent Design Tool - a software program that enables engineering teams in the concurrent design facility to efficiently exchange data and conduct research.
More information about using Concurrent Engineering approach at ESA/ESTEC can be found here.
¶ CE Workflow
Below you will find details as to what to do before, during, and after a new concurrent design study.
¶ Before
Studies are mandated as a service by external partners or within EPFL, by labs, for projects or for education purposes (see ENG-411 course). The person or entity ordering (maybe paying) for a CE study is called the customer.
¶ Step 0: Roles
The very first thing to do in preparation for an upcoming concurrent design study is to clarify the roles of the staff members overseeing it. These roles tend to include: study coordinators, session facilitators, system engineers, and technical or logistical support.
At times, multiple roles will be given to the same person. For example, session facilitators may act as systems engineers if their expertise lie within the scope of the mission or system to be designed. The list below defines the main responsibilities for each of these roles. Other roles beyond the ones listed can be defined based on the specific needs of the study.
- Study coordinators: top-level managers of a concurrent design study; in charge of identifying the need for a study, assigning staff roles, and defining expected outcomes and constraints, while controlling budget and time allocation. The study coordinator(s)' role is to be in contact with the customer, at least at the beginning of a partnership, before systems engieners and study facilitators can be directly in contact.
- Session facilitators: in charge of overseeing the development of each session with the objective of maintaining an effective and efficient flow of information between subsystems.
- System engineers: in charge of the technical coordination of a study from its preparation to its close-out and reporting. Often cumulate the tasks of a session facilitator because they are dicussing with all subsystems.
- Technical support experts: in charge of providing specific ad hoc expertise based on the needs and requirements of the mission or system to be designed. Not to be confused with study participants (see below and the CDF layout the subsystem experts).
- Logistical support team: assisting with the logistics of a study (booking of rooms, external communications, admin matters, infrastructure, etc.)
Another important contribution to the studies will come from subsystem experts.
- Subsystem experts are participants to the CE study. Some may be eSpace staff although this would probably be for specific competences regarding sustainable space or lunar research hubs, if such work station is included in the layout. Due to limited resources at eSpace and staff already assigned to other roles described above, the subsystem experts might come from consortium members or students could take the position to carry a CE study.
Already mentioned, the cutomers have a decisive role at the beginning of the study, to explain their needs, to validate the study preparation made by the systems engineers, and if needed, to refine / precise uncertainties. A specificity of the CE process is that customers are also present during the study. They must stay available (at least at intermediate milestones and final presentation) to answer any request for clarification, and to validate at the end that the proposed solution does indeed fulfill their needs.
¶ Step 1: Preparation
Before starting the design cycle, system engineers (SEs) and session facilitators (SFs) shall prepare and perform a preliminary analysis on their own, based on a request by a study coordinator (SC), maybe discussing with a customer. The goal of this step is to define a starting point or a baseline for the study.
This analysis includes defining the main top-level requirements and constraints for the mission and/or system to be designed. It is also necessary as part of defining a starting point to declare a set of assumptions that will be provided to the team and that will act as a baseline for the design (e.g., some subsystems or mission components may be considered out of scope and therefore treated as black boxes or dummy objects, designed by another party).
In essence, a good starting point should define the mission or system architecture.
Architecture drivers (often): trajectory and propulsion. But can also be the main goals of the mission (scientific, commercial, others).
Whenever possible it is good practice to refer to previous missions with similar characteristics or initial requirements! Check the list of previous CE studies.
Also, before the session starts, you need to create a mission/system model in the Concurrent Design Tool.
The SC must make sure that the relevant experts and subsystem specialists will attend the concurrent engineering sessions. The list of relevant experts/specialist is defined with inputs from the SFs/SEs about which roles are required for the study.
To contact potential participants or external experts, email templates are available.
In addition, SEs/SFs should define a timeframe for the study: when it will take place and how many session they deem the study requires.
Providing a timeframe for the study is critical. Defining how long a study should be is always a bit random. At ESA, concurrent design studies often end after 8 sessions (each session being 4 hours long). You can avoid falling into the trap of the never-ending refinement cycle by always defining a hard end-date for your study.
All the information gathered and details defined as part of this step shall be put together in a slide deck to be used during the kick-off of the study. A proposition for the content of the slides is given below:
- Mission overview
- ConOps (high level), to be refined during study
- Mission objectives
- Requirements (at system and subsystems’ levels)
- Scope for the study
- Design elements for the subsystems
¶ Step 2: Setup
To set up the infrastructure for the CE sessions, SF/SEs, together with logistical support if needed, shall follow the preparation checklist for how to setup the CDF. Beware that some actions are required several days/weeks prior to the start of the study.
The previous checklist includes material and equipment, as well as additional furniture (table, etc.), software installation, and logistics recommendations.
It is advised to have an empty report page ready on the wiki, and allow participants to fill it along the study, so not everything has to be done after the study (see point 8). The report can also guide the sessions by showing which content is expected at the end of the study. Report creation is included in the preparation checklist.
¶ During
¶ Step 3: Kick-off
A kick-off meeting is held in which SEs/SFs and often the customer presents to the rest of the team the rationale for the study; i.e., they describe why the mission/system is relevant, provide context and scope about mission goals, requirements and constraints, and introduce the results of a potential first system analysis conducted during the preparation, using the afermentioned kickoff slides.
¶ Step 4: Start the design
Definition of ConOps, timeline, modes of operations and changes in mission analysis.
Spend enough time identifying the inter-dependencies between subsystems: which values are needed by whom, and who will be responsible to create those parameters on COMET and compute them.
¶ Step 5: First iteration
Calculation of first budgets based on starting points.
Overall System synthesis is based on the following budgets:
• Mass budget
• Delta-V and Propellant budget
• Power and Energy budget
• Data budget
• Link budget
• Pointing error budget
• Cost
Mass budget is managed by System Engineers.
It is necessary to implement contingencies to cover the uncertainties. The contingency will depend on the confidence in the (sub)system you are designing and the readiness level of the technology used.
Experts will have to connect to COMET and to login to the COMET Excel plug-in (see the COMET action checklist).
¶ Step 6: Further iterations and refinement
After the first iteration, the engineers responsible for each of the subsystems make improved calculations on their own subsystem design based on the new values received from other subsystems (e.g., subssytem masses, power, volume, new lower-level requirements, new constrainsts, etc).
This process becomes an iterative loop.
Depending on the study, sometimes the customer may require to study multiple options.
This is the moment when Concurrent Engineering magic happens.
Specialists exchange data. They push data to Central Repository (Concurrent Design Tool). This data becomes available for the other specialists after system engineers review it and publish it for everyone. Each specialist can then pull this data to perform calculations and share their results.
The looping process can happen at the request of the specialists or the systems engineers, when new data is available in all subsystems, and they have reached a new step of design refinement. A loop shall happen at the end of each session, to make sure the changes are saved on the CE software and all subsystems can start with the most up-to-date values at the beginning of the next session. The end of a session is also a good milestone to take a moment for a post-session debriefing with the team (see below).
Iterations may lead to the changes in the mission/system architecture.
The number of iterations required is determined by system engineers. You can finish the process when the difference between the values obtained during the last iterations is covered by margin.
6.1 Post-session debriefing
A CE session generally last half a day or a full day. A lot of progress can be achieved by a team in this amount of time. Also the gap in between two sessions can vary from one night, to several days or weeks. It is thus important to alocate time for a post-session debriefing (PSD) with all participants involved to disseminate information about the design decisions made during the previous session. It is recommended to allow each subsystem to present their progress in a few minutes. Having every participants prepare one slide with visuals to support their talk can also be beneficial.
The PSD keeps everyone up-to-date with the current status of the study and can trigger questions to be tackled during the next session. It can also help in building up the final report by keeping track of the work, the assumptions taken, and the trade-offs made during the study.
¶ Step 7: Final Presentation/ Final check
At the end of the study, once the end-date for the study is reached, asking every subsystems to compile and present their final designs to the rest of the team is a good way to close the project. It also allows systems engineers to present a final mass budget with data from the subsystems (with relevant contingencies added). This is all useful information for the final report.
The final check shall include a screening of the requirements to verify that the designed mission fulfills them. The customer(s), having commissioned the study, shall then validate that the design indeed answer their needs.
¶ After
¶ Step 8: Post-study activities
The last step of a study is the report writing. A report template is available to eSpace staff to create a new page on the wiki. The report helps structure the outcomes of the study, provides lessons learned, assumptions, and data for future studies, and might be a required deliverable under a project contract.
It is the responsibility of the study facilitator(s) and the systems engineer(s) to ask every experts for the content of their subsystem to fill the report. They will then finish it before submitting it to the study coordinator and the customers. The report shall be defined as an expected deliverable in contracts for external studies.
Creating a clean and understandable report is worth it ! For yourselves and for future studies.
Make sure to block some time also with the participants at during and at the end of the study to synthetize their results and include them in the report.
¶ CE Software
-
Many others can be available.