GEP Quickstart guide
How to use Geeglee Pattern for your expectations?
-
Introduction to the main case study: the engineering design of a martian drone
-
Setting the Black-Box view
-
Setting the White-Box view
This part is aimed at sharing the best practice in modeling in order to maximize the value obtained by using Augmented Human Intelligence. To reach this goal, the following paragraph will focus on one main case study (the design of a martian drone) but others will be accessible, all along this part, for dedicated purposes.
1. Introduction to the main case study: the engineering design of a martian drone
Nowadays, Mars is at the heart of space programs. To prepare human exploration, several rovers have been, and more will be again, sent to its surface to map and to get geological data.
To accelerate this step towards the goal “to put a man on Mars and bring him back”, space agencies are looking for faster ways to explore the planet (rovers are slow). Flying in Mars' atmosphere could be THE solution. Indeed, since the flying drone technology soared on Earth in the past decade, it could be used on Mars.
Thus, two types of “mission profiles” have been imagined:
-
To map the surface of Mars: “the observation mission”
-
To get geological samplings from remote regions: “the cargo mission”
That being said, it’s quite easy to initiate Geeglee’s approach and to move to the first step: “the Black-box view”.
TIPS
To maximize the Return-on-Investment, Augmented Human Intelligence must capitalize on both the “way-to-set the need” (problem setting phase, also called, in systems engineering, the black-box view) and the “Way-to-think the solution” (problem solving phase also called, in systems engineering, the white-box view). Even though, in the first step, describing the black-box view can be optional, it is highly recommended to do it (you will understand below why it’s faster to work with a top-down approach).
2. Setting the Black-Box view
During this step, the System-of-Interest (SOI) must be considered as a black-box. In other words, the SOI will be considered for the value it provides to its environment (Space operations centre, rover and the Mars planet in our example).
Wondering how to create an SOI? Have a look at our tutorial video webpage (on GEP section)!
The pages “High level requirements” and “Environment systems” will guide you through the setting of the Black-box view.
HLR Inputs (High Level Requirements Inputs):
On this tab, set the expectations: what is helpful to size the SOI.
In our Mars example, the expectation is to be able to do observation or cargo missions. To follow Geeglee’s method, it’s necessary to ask experts about what describes a mission profile? Their answer:
-
For observation missions:
-
The ability to carry a camera (about 300g) or a lidar (about 500g)
-
An operating time (min)
-
A number of flights per day
-
A charging time between two flights
-
-
For cargo missions:
-
The ability to carry a rock
-
An operating time at empty weight (when the SOI move to a remote location)
-
An operating time at max payload (when the SOI is coming back carrying a rock)
-
A number of flight per day
-
A charging time between two flights
-
As a Systems Engineer, we report into Geeglee (Camera or lidar will be part of our SOI so their are not set as HLR inputs):
-
Required operating time at max payload (min)
-
Required operating time with no payload (min)
-
Minimum number of flights per day (#)
-
Payload weight (kg)
-
Target charging time between flight (h)
TIPS
It’s highly recommended to add units everywhere.
The values are coming from the analysis of the diversity of mission profiles. For instance: the SOI will move to a remote location about 5 minutes of flight time from the rover and bring back 1kg of payload all along the 12 minutes flight back. The operation will be repeated 3 times a day with 3 hours between each.
TIPS
-
Within the formulation of HLR inputs, note that Geeglee will test all possible configurations of HLR: all the possible values of Payload weight will be associated with all the possible values of charging time between flights, etc.. If you want to avoid this mix, you must define a specific set of values using Environment systems
-
Thanks to the exploration principle, you are able to test threshold effects by adding uncertainty onto needs settings. For example, if you expect a payload mass of 1 kg, you can test with Geeglee to find solutions for 0,9 kg and for 1,1 kg to see if it’s easier or worse to reach these values (threshold effects analysis is one scenario of analysis provided in the GEI section of this training).
Environment variables:
On this tab, set the constraints coming from the environments: set the constraints the SOI must be compliant with.
TIPS
As for HLR inputs, the list, and their values, provided will be explored as a combinatorial map by Geeglee. If you wish to avoid that, you must use Environment systems.
In our Mars example, environnement constraints have been set with Mars constraints:
We choose to do that because the SOI we are designing, is only meant to fly on Mars. We could imagine finding a platform able to fly on both Mars and Venus for instance. In that latter case, we would decide to add planet characteristics into environment systems to avoid the combinatorial exploration of variables (it makes no sense to mix characteristics from Mars with few characteristics from Venus!)
Outputs (High Level Requirements Outputs):
On this tab, set what is used to measure that the SOI is reaching the expectations. Stated differently, one has to define the key performance indicators (KPI) that help select the solution which has the best fit for the mission.
In our Mars example, the expectation is to be able to do observation or cargo missions. To follow Geeglee’s method, it is necessary to ask experts about what is needed to ensure that a mission profile is a success? Their answer (rephrased by Systems Engineer):
TIPS
Setting a target for each Output enables Geeglee to explore the Pareto Front (Pareto front is explained later in the analysis section).
Requirement constraints:
This tab can remain empty for most of the project! It is used to kill the solutions automatically but take care, it must be used with caution:
-
We recommend you to use it ONLY at system level, as Geeglee provides exploration capabilities, it can explore what looks like poor solutions at sub-system level but that can be excellent solutions at system level. Do not use it for another goal than to kill really unsatisfactory solutions
-
This tab can be filled during the project, based on intangible know-how
In our Mars example, requirement constraints have been set during the project. The most interesting one concerns the ability to fly: “Can it fly?” or rather “Can it lift its own weight?”
The engineering design highlights a design loop: the function “Convert rotation motion into air displacement”, that will be allocated to the “rotor” sub-system, needs induced power to rotate (the induced power is calculated based on air density on Mars and the SOI’s mass). This induced power is provided by the function “Convert electrical power into torque”, allocated to the “motor” sub-system. The electrical power is provided by the battery pack that will be sized (in terms of number of battery cells) following the induced power needed (and so the SOI’s mass). However, one can notice that sizing the battery pack will impact the SOI’s mass, resulting in a loop. Thanks to the exploration provided by Geeglee, this loop can be easily solved (we will see how, in the rules part). But to avoid creating a Martian vacuum cleaner, we introduced a system level constraint to kill solutions providing enough induced power to run the rotor but not to enable the SOI to fly: "induced power at empty weight (W)"<"induced power (W)". Have a look at the second constraints in the figure below.
3. Setting the White-Box view
During this step, the System-of-Interest is seen as a white-box. In other words, the SOI is considered as an aggregation of subsystem to fulfill the expectations.
Architectures & Configurations:
Geeglee is able to manage several architectures at the same time (not only configurations).
Definition:
In our approach, architecture is considered in the sense of Crawley: the allocation of functions into subsystems constitutes an architecture. Configurations are defined inside an architecture by the mix of alternatives for each subsystem of our SOI.
As you will discover while practicing with Geeglee, the way-of-thinking is fully correlated to the architecture.
Up to now , Geeglee only capitalizes on the leaf functions and the last level of the PBS (Product Breakdown Structure).
The pages “Product Breakdown Structure” and “Engineering Patterns” will guide you through the setting of the White-box view.
The page “Product Breakdown Structure” is composed of five tabs:
-
“Modules” used to detail both subsystems composing the SOI and technical alternative available for each subsystem,
-
“Characteristics” containing technical characteristics needed to describe the tradeoff between modules’ alternatives,
-
“Values” used to specify the values for each technical characteristic per alternatives,
-
“Internal incompatibilities” used to describe SOI’s interfaces (in Geeglee, incompatibility are one type of interfaces),
-
“All incompatibilities” setting interfaces between SOI’s breakdown and Environment system.
Modules:
In this tab, can one designate:
-
All modules composing the SOI (this must be done through administration: refer to the video tutorial webpage to discover how).
TIPS: be careful during the Functional Breakdown, the list of modules must cover the overall SOI without overlap between them. Also, name the modules without ambiguity. The names must make sense for every person involved in the project, since they will be used in the Engineering patterns page..
-
If you have set several architectures, do not forget to specify which module is contributing to which architecture. In the following example, the “Battery cell” module is assigned to both “Rover” and “Solar” architectures.
TIPS
The allocation to architectures can be done at two levels. First at module level, meaning that a subsystem is assigned or not to each architecture. One can also, for a given module, assign alternatives to architectures. (see next paragraph). It will be managed by Geeglee.
For each module, specify the alternatives that can fulfill the module’s expectations.
TIPS
-
On this tab, you can allocate alternative(s) to dedicated architecture(s).
-
What is the best practice between creating a dedicated module for an architecture or dedicated alternative? Our recommendation is:
-
If the function is the same between the two modules of the architectures, keep one module and prefer to allocate alternatives to architecture (this will simplify the work into Engineering Patterns). It is the solution we retained for the “Power charging system” of the martian drone: the function is the same (to provide energy) so we assigned alternatives to the relevant architectures (the plug to the rover one and the solar panel to the solar architecture.
-
If the function is not the same between the modules of the architectures, prefer to create two separate modules, one for each architecture.
-
TIPS
You can activate or inactivate alternatives. Deactivating alternatives makes Geeglee ignore them during the exploration (this is useful to accelerate computations when converging towards a subset of solution, but also to remember which alternatives were explored before convergence).
Final view of the “Modules” tab. “7/14” alternatives for “battery cell” means that 7 alternatives have already been eliminated (deactivated) at the development stage.
Characteristics:
In this tab, one can specify the list of technical characteristics used to describe the alternatives of each module (Once again, make sure to give them unambiguous names). Note that a technical characteristic can be used for several alternatives of several modules (as for instance, unit cost).
TIPS
-
How to choose between setting one technical characteristic for several alternatives or one for each of them? When possible, having common technical characteristics between modules will let you create the model quicker and let you create more generic engineering patterns.
-
Which level of details must be inputted? Two elements must be taken into account:
-
Any technical characteristics that experts consider important to assess the HLR (High Level Requirements set in Black-box view),
-
Any technical characteristic that enables us to understand the trade-off between two alternatives (it is good practice to avoid having two alternatives with the same values - no choice will be then possible).
-
Values:
In this tab, input the values for each technical characteristic of each alternative of each module (fill the catalogue of technical alternatives).
TIPS
Fill in the data one module at a time. The consistency between alternatives must be sufficient to obtain relevant analyses of the SOI.
You will get a cleared view:
Moving to the “Engineering Patterns” page.
By default, the page opens on the“Patterns” tab but another one is available: “Design Variables”.
Patterns:
In this tab, list all the rules you have in mind (or you will be able to put on the table by questioning your system #1).
TIPS
-
Geeglee automatically retrieves HLR outputs. So begin with the rules necessary to obtain them first since it is the minimum required scope to assess the design space (trade space) of your SOI.
-
Break down the steps of analysis as much as possible.
For instance:
Total Cost of Ownership (k€) = CAPEX (k€) + OPEX (k€), then
CAPEX (k€) = Investment (k€)/Nbre of years of useful life (#)
OPEX (k€) = nber of employees (#) * average salary (k€)
-
If you need to convert k€ to M€ for instance, create a rule to make to conversion:
Convert k€ in M€ = 1/1000, and then use it:
Cost (M€) = Cost (k€) * Convert k€ in M€
-
Defining rules is an iterative process, which means that a first model can be reached easily by using “simple” or “approximative” rules. These rules can be refined later if needed. For instance, in the above example: OPEX (k€) = nber of employees (#) * average salary (k€) can be frustrating because it considers every employee has the same salary. Thus, the rules can be refined as follows later in the project:
OPEX (k€) = nbre of engineers (#) * average engineer salary (k€) + nbre of operators (#) * average operator salary (k€)
The approach can be continued as much as you like.
-
Factor as much as possible! To have an easily maintainable model, factor as much as possible, meaning that you should avoid having common parts in two rules.
-
Remark how to set rules for all architectures or for specific one. Rules can be only for one architecture also.
To have more details about good way to model patterns, have a look at: "GEP Best practice in pattern edition".