Quickstart guides
Geeglee Engineering Pattern (GEP) guide
Geeglee Intelligence Pattern (GEI) guide
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:
GEI Quickstart guide
How to exploit data generated with Geeglee Engineering Pattern?
Geeglee Engineering Pattern is useful to explore the field of possibilities and find all available trade-offs (based on both your engineering know-how and on your catalogue of technical solutions, which can be existing solutions, new potential ideas, or Components Off The Shelf).
As the goal of Geeglee is not to replace humans, Geeglee is NOT deciding for you.
Geeglee Engineering Intelligence is the tool, from the Geeglee suite, to “play” with the data and decide which solution(s) is the right one for your goals (be it a solution to a specific need or a platform (product line)).
This part will let you understand how to use GEI in order to find the “right path”.
1. Structuration of your project
The organization of your work is free in Geeglee Engineering Intelligence, so you can create whichever datapage you want and as many as you need (For example: problem setting pages, problem solving pages, detailed study pages).
TIPS
The next paragraph shows you an easy, quick and efficient way to structure your analysis in Geeglee Engineering Intelligence.
Example of a 4-section structure of your project
-
“Home” will let you have a welcome page after having opened the project (it may take a few seconds depending on how large your exploration is (ambition in your project).
-
“Problem setting” in which you will describe the needs your SOI has to satisfy (an extract of the black-box view of GEP)
-
“Problem solving” in which you will define scenarios of analysis for your problem setting (those datapages will let you capitalize on the best way to analyze it). Once again, in Geeglee we keep separate the way-to-think from the data.
-
“Detailed studies” in which any discipline can create its viewpoints (it can be more than one datapage per discipline).
Example of structuration from Geeglee Engineering Intelligence
Home: Welcoming and explicit first contact
We recommend integrating a homepage in the “Home” section to enable a quick understanding of the project and its objectives. The homepage is all the more important if you are planning to present or share your Geeglee Engineering Intelligence project with colleagues, experts from other sectors or even clients.
It should therefore make it possible to understand what the topic is and what the issues are at a glance.
Problem setting: Synthetic presentation of studied system(s)
The purpose of this section is to present the key elements for understanding your project, its context, objectives and expected performance criteria. It can therefore include structural parts such as the definition of the need (black-box approach).
Problem solving: Investigating data according to different modes and objectives of analysis
This section is dedicated to the definition of the modeled system and its subsystems (white-box approach), and to the construction of analysis scenarios that will facilitate system(s) exploration.
These analysis scenarios can have different objectives and approaches. For example, you can create analysis scenarios that respond to:
-the issues you regularly investigate (What is the cheapest architecture for the required performance? What are the main cost drivers? etc.),
-your customers' expectations (What cost for which architecture? What is the footprint if I choose the cheapest architecture? etc.),
-your colleagues' modes of investigation or problems (What is the potential financial profitability of developing such an architecture? Which human resources should be associated with the development of this project? etc.).
Tips: Creating analysis scenarios, should be a team effort to integrate the expertise and know-how of the participants.
Detailed studies: Components and parameters breakdown of the studied system(s)
This section presents in details the components and parameters of the studied system(s) and its subsystems, among others:
-
Architecture breakdown,
-
Discipline’s viewpoint,
-
Performance criteria breakdown,
-
Technology breakdown,
The pages created in this part will be particularly important and useful for experts who will be able to work and interpret the results in more details.
2. Enrich and detail each section
Below is an example of a detailed structuring of your project.
Example of a detailed structure of the first level of a project
Example of structuration from Geeglee Engineering Intelligence
3. Focus on the key pages and elements
In this section, we will show you how to design the key pages of your project file in Geeglee Engineering Intelligence based on one of our customer's projects. This example is the design of a drone to be sent to Mars to carry out observation and/or cargo missions.
Example of detailed structuration from Geeglee Engineering Intelligence
3.1. Create your “Home” - How do you get your project goal across quickly?
A good home page often includes a few key elements such as:
-A title,
-A short presentation paragraph,
-A good quality image explicitly presenting the context, the objectives or the concept,
-The logos of the stakeholders,
This page is the first contact, so it must be welcoming and explicit to facilitate understanding and also to make people want to know more about your project.
Example of a Homepage extract from the "Martian Drone" project for the CNES in Geeglee Engineering Intelligence
3.2. Structuring the “Problem setting” section - What information is needed to properly contextualize your project?
In order to contextualise your project and its objectives, we recommend that you summarize:
-the context of operations (What is the situation in which your system is to be deployed?),
-the need(s) (What objective(s) should your system meet? What is it required to do?)
-the expected performance criteria (What is the basis for evaluating the satisfaction of the objective(s)?),
Example of a Problem setting page describing the context of the project, from the "Martian Drone" project for the CNES in Geeglee Engineering Intelligence
Example of a Problem setting page specifying the performance criteria of the system from the "Martian Drone" project for the CNES in Geeglee Engineering Intelligence
3.3. Structuring the “Problem solving” section - How to design an analysis scenario?
You have modeled your system and its subsystems in Geeglee Engineering Pattern, now is the time to explore it!
Data mining is an exciting activity, however, one can get lost quickly, so we recommend that you build analysis scenarios. This is an example of a scenario, however, many others could be created such as :
-What is the cost of landing on Mars?
-What type of mission(s) can be achieved with the lightest drone architecture?
-What is the most robust architecture to cover the different types of missions?
To design an analysis scenario, you first need to define what you want to know, which question(s) you want to answer.
In the case of the example project, we want to know the most reliable drone architecture, so it is necessary to define several elements of context and needs to perform this analysis.
Example of a Problem solving page integrating an analysis scenario to view the most reliable architecture, from the "Martian Drone" project for the CNES in Geeglee Engineering Intelligence
Firstly, it is important to choose for which type of mission we want the drone architecture to be the most reliable, as certain mission characteristics can increase the risk of reliability failure (need to be able to load, mission duration).
Example of a Problem solving page integrating an analysis scenario to view the most reliable architecture, from the "Martian Drone" project for the CNES in Geeglee Engineering Intelligence
Example of first step analysis scenario: Choose the mission to view the most reliable architecture,
from the "Martian Drone" project for the CNES in Geeglee Engineering Intelligence
We will then push the system to its limits by specifying the maximum payload mass. As the maximum payload mass can be an important factor in reliability failure, we will choose the highest mass available.
Example of second step analysis scenario: Specify the max payload mass to view the most reliable architecture,
from the "Martian Drone" project for the CNES in Geeglee Engineering Intelligence
After having chosen the mission type and selected the maximum payload mass, we will finish by setting the expected reliability under different circumstances (dust, radiation and before launch).
NB: You can see that at this stage, not all reliability levels are available. Indeed, the choices we made previously have already discarded some reliability levels, which means that if we want a higher level of reliability for certain circumstances, we will have to revise the previous choices (mission duration, maximum payload mass).
Example of third step analysis scenario: Setting the reliability level to view the most reliable architecture, from the "Marsian Drone" project for the CNES in Geeglee Engineering Intelligence
We have chosen the type of mission, specified the maximum payload mass and set the highest level of reliability available, we can now find out which architecture to favour!
Example of view results of the most reliable architecture,
from the "Martian Drone" project for the CNES in Geeglee Engineering Intelligence
3.4. Structuring the “Detailed studies” section - What is a “detailed study”?
A modeling and exploration of system(s) requires detailed analyses of certain parameters such as
-The architecture breakdown to study it more precisely,
-The discipline’s viewpoint so that the experts participating in the project can find their references for review,
-The performance criteria breakdowns to understand how they are obtained,
-The technology breakdown to distinguish certain results and thus arbitrate final orientations,
NB: We draw your attention to the need to prioritize the pages created in this section as you can quickly be overwhelmed by a large number of technical analysis and have difficulties in using them. We therefore recommend that you create only thematic technical pages (“Detailed studies”) and do not hesitate to create analysis scenarios (“Problem solving”) as soon as you conduct a study by navigating between several technical pages.
To have more details about good way to exploit data thanks to Geeglee Engineering Intelligence, have a look at: