¶ Useful tips
All useful information for eSpace staff on how to prepare, conduct, facilitate a CE session.
¶ Purpose of this list
Lessons learnt are compiled by facilitators during each CE sessions. They are then sorted and uploaded to the wiki. This section contains general lessons learnt about concurrent engineering, sorted into five categories:
Technical lessons learnt specific to one session are compiled in the session's own mission log. Have a look at them under the list of previous CE sessions.
¶ Infrastructure lessons learnt
- The available wifi network can be pushed to its limit during a CE session. One needs a good internet connection, via an ethernet LAN router/switch if needed, to have enough bandwidth for the whole group.
- When hosting companies, one needs a more professional CDF setup, with better workstation with double screens, more display capabilities, and higher-quality connection to the internet. The configuration of the room has to allow for interactions between the participants.
The CDF at eSpace can host a maximum number of around 10 participants plus three facilitators. Using room MED 2 1124 might be an alternative to host more people.
- When connected to another CDF room (eg. for 2022 CEC) : One needs a good audio system in the room. , with easy ways to ask questions at each workstation. Ideally using equipment the participants are already familiar with (their own).
- Use work stations with engineering software already installed (for CAD, FEM, CFD, data handling and plotting, etc.). A list of open source programs that can be installed or used online is available here.
¶ Sessions' preparation
- Do not forget the preparation (systems engineers’ job), think about the product tree in advance, prepare a high level ConOps, make sure to understand the requirements and explain them well to the subsystems’ experts. Visual support is appreciated to convey the information.
- Speaking of visual support, it may be a good idea to have an example of how does the data flow during the CE session. Have every experts understand which parameters impact their subsystem (so they shall subscribe to them) and which ones from their subsystem impact others (so they know with whom to speak to if it is modified).
- Anticipate documents sharing capability (a folder on a server like google drive or similar) and a way to quickly share links and messages (a group on webex teams, a slack group or any other communication service that could do the job).
- Check that all the necessary parameters are on the CE software. Forgetting one means some subsystems could wait on values no one is trying to put online. Also make sure there are no double parameter. Subsystems that are subscribed may be confused and if one is not updated but the other is, it may result in conflicts. For information that is more difficult to model in the CE software (eg. connections between subsystems, position in the spacecraft, etc.), either create new parameters with clear names and units, or iterate directly with the subsystems involved. The latter is manageable only for small numbers of parameters.
Quick fix if a parameter was forgotten: add the parameter to the relevant subsystem(s)' element in the CE software and asked best estimates from the subsystem(s). The value will hopefully be already better than what would have been a 1st iteration estimate. Then follow the regular CE workflow.
¶ CE workflow
- Start with “top-down” estimations of mass (and power, and others) budgets and then build the first design iteration upon these values. One can use literature to find good first estimates.
- Make sure there are values for each and every parameters from the first iteration on ! Even very rough estimates: the process has to start somewhere. Values with zeros cannot be used for the design of subsystems. And check that all the necessary parameters are on the CE software (see Sessions' preparation).
- The iteration loop really starts with everyone sharing the same values (put estimates if needed, do not forget any or leave any at 0 (see above). Then every subsystem iterates and at the end everyone pushes their values and notify the SEs.
- Take the time needed for the publication and synchronization steps this loop is really a critical moment during which everyone needs to be focused. At the beginning of an iteration/of a day, experts shall “re-build” their local working file by pulling values from the CE software.
- Once subsystems have shared their values (push), SEs shall take the time needed for the publication step: checking the values, building the budgets, entering the values that are based on these budgets and owned by SEs, before publishing. Participants shall not iterate during this time, they shall wait for the publication to be done and only then they can synchronize by pulling the new values.
- For the dry mass budget margins, SEs gather the values from each subsystem and add a margin dependent on the confidence they have in the provided values (min 20% but can be as much as 100% margin). Then, add another 20% margin at system level for the total dry mass.
- For the wet mass budget margins: add a very little margin on the Delta v value (it is then used in an exponential formula to find the propellant mass). But one can easily add 20% margin on the propellant mass computed from those Delta v.
- Do not rush for a CAD. First do a quick functional diagram to understand location requirements and at the end have a CAD to assemble everything. A CAD is only useful for inertia calculation and payload fairing volume check (and for visual motivation of the team). Start with a very basic CAD or reuse an image from a similar mission at first.
- It could happen that iterating does not yield the desired convergence of the design in terms of mass, cost, power (all the budgets), but rather the design could start diverging. If this is the case, go back to your assumptions and key driver decisions, adjust them before starting again.
For example at CEC 2022, the choice of the launcher was a very important decision to make because it changed the trajectory of the spacecraft, which ultimately had a huge impact on the design. By the middle of the week, we changed from Ariane 6 to Vega C because of the performance required and converged to a solution.
For general CE Workflow see Here
¶ Lessons learnt from ESTEC CDF
ESA wiki about COMET documentation and concurrent engineering.
¶ ESA CDF visit
While visiting ESTEC during the ESA CleanSpace Industry Days 2022. eSpace staff had the chance to visit the CDF used by ESA on the ESTEC site in the Netherlands. During the tour, an ESA systems engineer shared his thoughts about the process as they experience it at ESA:
- It can be hard to find experts (because it's time consuming for them) and the directorates are hesitant to commit a lot of manpower to a CE study. Not many experts are trained to use the CDF because it's always the same people participating for the same subsystem.
- ESA usually conducts 8 sessions of 1/2 day over 1.5 month (~2 sessions per week).
- Experts get "homeworks" between the sessions (simulations, calculus, literature, etc.).
- ESTEC CDF has "splitting rooms" if a subset of subsystems have to be isolated to discuss a more detailed matter / topic / trade-off (could be PPH 335 at EPFL).
- Ideation support: ESA team identified that a pain point is sharing the same vision, sharing your ideas, so they use LEGOs, 3D printers and soon mixed augmented reality (!) to help this process.
- Another painpoint : the lack of interactions: they consider banning powerpoint presentations, to encourage the use of the whiteboard and push for more discussions.
Other opportunities to learn from ESA experts soon presented themselves, for instance the participation to the Human Inspirator Co-Engineering (HICE) study in early 2023. Lessons learnt are given below.
- Introduction / context: the systems team can present a (historical) review of past, present, and in development solutions that address the topic of the study (eg. history of cargo vehicles to LEO, or history of reentry vehicles for human). This can be used to set lower and upper boundaries on some of the sizing elements to define (mass, volume, etc.) to create a baseline.
- Preparation / initial brainstorm: functional analysis using Systems Modeling Language (sysML) for the system (and the subsystems). The functional analysis can be detailed per phase of the mission.
- It's important to keep track of all assumptions and trade-offs made before and during the study. In case of doubt, ask the customer to validate. In particular, flag the assumptions that are high level and have an impact on all (sub)systems.
- At the end of a session, wrap up with the actions (for the systems team and for the participants) to be done before the next one.
- Invited subsystem experts shall reflect the need of the mission objectives defined by the customers (so they shall be adapted per study: eg. if the mission includes human exploration, have an "environmental control and life support system" (ECLSS) expert.)
- Other subsystems idea: architecture, cost, electrical vs chemical propulsion, aero-thermodynamic (reentry), risk, safety, programmatic/AIV, visualisation, crew aspects, MGSE, EGSE, software, ...
NB it can be hard to find experts (it's time consuming for them) and the directorates (Ed. industries, labs, partners) are hesitant to commit a lot of manpower to a CE study. There is a risk that not many experts are trained to use the CDF because it's always the same people participating for the same subsystem.
- Each CE study is different ! Need to adapt to the “level” of the mission, the time-to-mission, the team, etc.
- Start sessions with a 1 pager summerizing the current status of the reference mission
- Assumptions by the customers or systems team shall be challenged by the experts, and can be presented to final "users" too (eg. astronauts) to avoid over-designing (over-engineering).
- Literature collection (review) can be complemented by subsystems' experts.
- Design can follow either a "capacity push" approach or a "needs pull" approach
- Some key performance indicators (KPIs) start to make sense with [.../year] or [.../trip] units if number of launches continues to increase
¶ Other ESA specifics
Other ESA specifics, of interest for any CE study, explained in the COMET basic tutorial (available on eSpace Google Drive) are shown below. See if they are applicable to your study:
- Margin policy:
| Mass margin | Maturity | ECSS-E-ST-10-02-C Product Category |
|---|---|---|
| 5% | for off-the-shelf equipment | A |
| 10% | for equipment with slight modifications | B or C |
| 20% | for new or heavily modified equipment | D |
Delta v margin: 5% (careful it's used in an exponential function to compute propellant mass). Add 3% of unusable, residual propellant. In geenral for consumables (AOCS propellant, batteries, food, etc.) size for mission lifetime + extension.
Data processing margins: 50% for mass memory, 100% for computing power.
Communication margin: 3dB in the link budget.
Temperatures: +/- 10 degrees.
Systems margins evelove wiht the mission phase: 20% at SSR, 15% at PDR, 10% at CDR, 5% or less at FAR.
-
When to publish (step of the three switch mechnanism to coordinate data sharing) ?:
- At the end of a session
- At the end of a Domain Expert’s presentation
- On request
-
When and how to wrap up a study ?:
- When iterations converge towards a solution (chnages below a certain threshold, eg. below the contingencies added to the mass, power, etc..., see margin table above.
- How: Ensure that report and model are in sync
¶ Other lessons
- During brainstorms, encourage people to stand up, use white board, discuss more, interact, and share their ideas. Avoid the case when only facilitators are talking, and make sure every expert can participate equally.
- Always be consistent with units and display them clearly.
- Anticipate food and drinks for the coffee breaks. Those are important for the morale and team's spirit.
- Know when to stop: to take breaks, have lunch, or end the day, otherwise there is always something to do. Breaks and end of days are good moments to finish an iteration and perform the synchronization process.
- Managing the morale of the team and the relationships between participants is crucial for the progress of the design. Avoid conlicts, tensions or bad behaviour, to create an efficient and pleasant working atmosphere.
- If some participants are joining remotely, anticipate the need for an online drawing tool (like MURAL), to ease the sharing of ideas.
Even between students, tensions can arise from simple cause like a delay in the synchronization, or two conflicting views on how to handle a problem. Also, during CE challenges, the team shall not compare itself to other teams, or other experts.
¶ ENG-411 lessons
¶ format and lectures
- Give more credits to attract more students
- Make 1 SE course mandatory for students to register (otherwise a lot of material to give during the lectures)
- make sure the logistics info are shared with the students: add wiki link to the EPFL website course description
- Invite other universities to join at the same time ?
- Buy computers with everything installed for CE instead of renting to Poseidon everytime
- Split dense CE lectures into smaller bits (2 moments at the beginning of the semester and keep the 8 days for design sessions later)
- move intense week earlier (this time was week 4-5, but week 3-4 would be better)
- ESA's wifi sucks, EPFL's too...
- Webex is shitty ! Why would it close on its own in the middle of the meeting... lesson is to use tools we are familiar with. Use MS Teams
- Don't write report on wiki because students can't write in parallel (directly in markdown .md format)
- Emphasize team work aspects (also for writing the report)
- create a short Youtube video as tutorial for COMET, put chapters to split the video by action explained, "much better than slides"
- We need at least 4 supervisors and 1/2 days every days for two weeks was much better for us (eSpace)
- Insist the guest lectures should follow our needs (from ESA: not the usual official speech but more a personal take / lessons learnt from someone who works at CDF). We have leverage because it must be useful for students
- make sure the focus of the evaluation is about concurrent engineering, not spacecraft design (but be careful because students feel a lot of emphasis on deliverables, report, presentation)
- grading categories and weights: more emphasis on COMET / model / concurrent aspects
¶ design sessions
- not all subsystems have the same workload at the same time: while prop, trajectory and conf. work since the start, power, thermal, and else will contribute more later
- simplify the way to get to destination (trajectory analysis) because that's what we need at the very beginning (could choose a study concept without trajectory (an instrument, a system (not the whole mission)) or assuming fixed values
- we don't understand the meaning of the colours for parameters in COMET (now yes, see COMET checklist if complete)
- add system level margin already when going top-down during mass budget allocation (eg. remove 20% of available mass) or add after creating the global budget (but not both)
- Prepare the customers' "knowledge" more or invent number where needed for information they should provide in a real study (eg. data rate of pathfinderss, dimensions, etc.) we can set values so it doesn't block the progress of the team --> add more constraints to the study
- for thermal: start with thermal balance (Q_int + Q_sun + Q_albedo + Q_IR = Q_tot), in each phase. Assume homegeneous temperature in the spacecraft and identify survivability and operatig T ranges for the elements. Then select coating and passive elements, then active where required (approximation)
- SUBSCRIPTION ! The last iteration was surprisingly easy to stop because it seemed like no one was depedant on the others' values... in fact, in many cases, the students decided to compute / model an element with the worse case only (eg. loads supported by the structure, they used as if the mass was 8.5 tons (the max capacity of A64) instead of subscribing to the "mass" parameter of the system on COMET
- Inter dependency of the systems through comet is low
- too many conservative assumptions instead of using comet
- too many computation done by hand
- Many subsystems were not changed during this last day
- Some parameters were not correclty entered, hence subscribed by the other subsystems
- For the final iteration, the idea is to freeze the design of the subsystems one after the other, in this proposed order: 1) trajectory and propulsion 2) comms 3) structure and configuration 4) aocs 5) power and thermal 6) SE budgets
In between each freeze, the subsystem to be frozen has to pull, update their values, and push the new ones. So the SEs can publish (at which point the parameters are considered frozen). This logic is needed to make sure the subsystems are using the most up-to-date values in the final computation
¶ Challenges
- Kick start the first iteration
- Have the student SE manage the class (only ok if they are confident and know about CE, SE, project management), and careful, it happened that some discussions were only between SEs and eSpace staff
- include everyone in the discussion
- Make sure everyone is aware of the decisions / ongoing discussions / assumptions
- push a bit some student to set "best guess" values at the beginning
- when to stop to be able to publish (there is always a calculation to do)
- some of the subsystems we are less comfortable with (thermal is always difficult, aocs and cdhs we were lucky to have students with background), be careful as it can drag iteration behind
- make students understand the "power" of COMET: subscribe to others' parameters, even if the tool is not easy to use --> enforce the use of COMET
¶ Ideas
- add a sustainability workstation (with eSpace tools ? SSR, ACT, TCAT, ... handbook)
- Course about tools available
- COMET video tutorial, use it with everyone to make a test
- more time and push more to identify the parameters that link the subsystems (make a diagram for exemple)
- lecture on critical thinking, system thinking, assumptions, rule of thumbs, systems decomposition, system dependency at system level