Guides de démarrage rapide
Guide du modèle d'ingénierie Geeglee (GEP)
Guide du modèle d'intelligence Geeglee (GEI)
Guide de démarrage rapide GEP
Comment utiliser Geeglee Engineering Pattern
pour répondre à vos attentes ?
-
Introduction à l'étude de cas principale : la conception technique d'un drone martien
-
Paramétrage de la vue Black-Box
-
Paramétrage de la vue White-Box
Cette partie vise à partager les meilleures pratiques en matière de modélisation afin de maximiser la valeur obtenue en utilisant l'intelligence humaine augmentée. Pour atteindre cet objectif, le paragraphe suivant se concentrera sur une étude de cas principale (la conception d'un drone martien) mais d'autres seront accessibles, tout au long de cette partie, à des fins spécifiques.
1. Introduction à l'étude de cas principale : la conception technique d'un drone martien
Aujourd'hui, Mars est au cœur des programmes spatiaux. Pour préparer l'exploration humaine, plusieurs rovers ont été, et seront encore, envoyés à sa surface pour la cartographier et recueillir des données géologiques.
Pour accélérer cette étape vers l'objectif "d'envoyer un homme sur Mars et de le ramener", les agences spatiales cherchent des moyens plus rapides d'explorer la planète (les rovers sont lents). Voler dans l'atmosphère de Mars pourrait être LA solution. En effet, la technologie des drones volants ayant explosé sur Terre au cours de la dernière décennie, elle pourrait être utilisée sur Mars.
Ainsi, deux types de "profils de mission" ont été imaginés :
-
Cartographier la surface de Mars : " la mission d'observation ",
-
Prélever des échantillons géologiques dans des régions éloignées : "la mission cargo",
Ceci étant dit, il est assez facile d'initier l'approche de Geeglee et de passer à la première étape : "la vue de la boîte noire".
CONSEILS
Pour maximiser le retour sur investissement, l'intelligence humaine augmentée doit capitaliser à la fois sur la "manière de définir le besoin" (phase de définition du problème, également appelée, en ingénierie des systèmes, la vue de la boîte noire) et sur la "manière de penser la solution" (phase de résolution du problème également appelée, en ingénierie des systèmes, la vue de la boîte blanche). Même si, dans la première étape, la description de la vue de la boîte noire peut être facultative, il est fortement recommandé de le faire (vous comprendrez plus loin pourquoi il est plus rapide de travailler avec une approche descendante).
2. Paramétrage de la vue de la boîte noire
Au cours de cette étape, le système d'intérêt (SOI) doit être considéré comme une boîte noire. En d'autres termes, le SOI sera considéré pour la valeur qu'il apporte à son environnement (centre d'opérations spatiales, rover et planète Mars dans notre exemple).
Vous vous demandez comment créer un SOI ? Jetez un coup d'œil à notre page web de vidéos tutorielles (dans la section GEP) !
Les pages "Exigences de haut niveau" et "Systèmes d'environnement" vous guideront dans la configuration de la vue "boîte noire".
HLR Inputs (entrées des exigences de haut niveau) :
Dans cet onglet, définissez les attentes : ce qui est utile pour dimensionner le SOI.
Dans notre exemple de Mars, l'attente est de pouvoir effectuer des missions d'observation ou de cargaison. Pour suivre la méthode de Geeglee, il est nécessaire de demander aux experts ce qui décrit un profil de mission. Leur réponse :
-
Pour les missions d'observation :
-
La capacité de transporter une caméra (environ 300g) ou un lidar (environ 500g).
-
Une durée de fonctionnement (min)
-
Un nombre de vols par jour
-
Un temps de recharge entre deux vols
-
-
Pour les missions cargo :
-
La capacité d'emporter une pierre
-
Un temps de fonctionnement à vide (lorsque le SOI se déplace vers un lieu éloigné)
-
Un temps de fonctionnement à charge utile maximale (lorsque le SOI revient en transportant une roche)
-
Un nombre de vols par jour
-
Un temps de charge entre deux vols
-
En tant qu'ingénieur système, nous rendons compte à Geeglee (la caméra ou le lidar feront partie de notre SOI, ils ne sont donc pas définis comme des entrées HLR) :
-
Temps de fonctionnement requis avec une charge utile maximale (min)
-
Temps de fonctionnement requis sans charge utile (min)
-
Nombre minimum de vols par jour (#)
-
Poids de la charge utile (kg)
-
Temps de charge cible entre les vols (h)
CONSEILS
Il est fortement recommandé d'ajouter des unités partout.
Ces valeurs sont issues de l'analyse de la diversité des profils de mission. Par exemple : le SOI se déplacera vers un endroit éloigné à environ 5 minutes de vol du rover et ramènera 1kg de charge utile tout au long des 12 minutes de vol retour. L'opération sera répétée 3 fois par jour avec 3 heures d'intervalle.
CONSEILS
Dans la formulation des entrées du HLR, notez que Geeglee testera toutes les configurations possibles du HLR : toutes les valeurs possibles du poids de la charge utile seront associées à toutes les valeurs possibles du temps de charge entre les vols, etc. Si vous voulez éviter ce mélange, vous devez définir un ensemble spécifique de valeurs en utilisant les systèmes d'environnement.
Grâce au principe d'exploration, vous êtes en mesure de tester les effets de seuil en ajoutant une incertitude sur les paramètres des besoins. Par exemple, si vous prévoyez une masse de charge utile de 1 kg, vous pouvez tester avec Geeglee des solutions pour 0,9 kg et pour 1,1 kg afin de voir s'il est plus facile ou moins facile d'atteindre ces valeurs (l'analyse des effets de seuil est un scénario d'analyse fourni dans la section GEI de cette formation).
Variables d'environnement :
Dans cet onglet, définissez les contraintes provenant des environnements : définissez les contraintes auxquelles la DI doit se conformer.
CONSEILS
Comme pour les entrées HLR, la liste, et leurs valeurs, fournie sera explorée comme une carte combinatoire par Geeglee. Si vous souhaitez éviter cela, vous devez utiliser des systèmes d'environnement.
Dans notre exemple Mars, les contraintes environnementales ont été définies avec les contraintes Mars :
Nous avons choisi de le faire parce que le SOI que nous concevons est uniquement destiné à voler sur Mars. Nous pourrions imaginer trouver une plate-forme capable de voler à la fois sur Mars et Vénus, par exemple. Dans ce cas, nous déciderions d'ajouter les caractéristiques de la planète dans les systèmes d'environnement pour éviter l'exploration combinatoire des variables (cela n'a aucun sens de mélanger des caractéristiques de Mars avec quelques caractéristiques de Vénus !).
Sorties (sorties des exigences de haut niveau) :
Dans cet onglet, définissez ce qui est utilisé pour mesurer que le SOI répond aux attentes. Autrement dit, il faut définir les indicateurs clés de performance (ICP) qui permettent de sélectionner la solution la mieux adaptée à la mission.
Dans notre exemple de Mars, l'objectif est de pouvoir effectuer des missions d'observation ou de transport de marchandises. Pour suivre la méthode de Geeglee, il est nécessaire de demander aux experts ce qui est nécessaire pour garantir le succès d'un profil de mission. Leur réponse (reformulée par l'ingénieur système) :
CONSEILS
Fixer un objectif pour chaque sortie permet à Geeglee d'explorer le front de Pareto (le front de Pareto est expliqué plus loin dans la section sur l'analyse).
Contraintes des exigences :
Cet onglet peut rester vide pendant la majeure partie du projet ! Il est utilisé pour tuer les solutions automatiquement mais attention, il doit être utilisé avec précaution :
-
Nous vous recommandons de l'utiliser UNIQUEMENT au niveau système, car Geeglee fournit des capacités d'exploration, il peut explorer ce qui semble être des solutions pauvres au niveau sous-système mais qui peuvent être d'excellentes solutions au niveau système. Ne l'utilisez pas dans un autre but que celui d'éliminer les solutions vraiment insatisfaisantes.
-
Cet onglet peut être rempli au cours du projet, sur la base d'un savoir-faire immatériel.
Dans notre exemple Mars, des contraintes d'exigences ont été définies au cours du projet. La plus intéressante concerne la capacité à voler : "Peut-il voler ?" ou davantage "Peut-il soulever son propre poids ?".
La conception technique met en évidence une boucle de conception : la fonction " Convertir le mouvement de rotation en déplacement d'air ", qui sera attribuée au sous-système " rotor ", a besoin d'une puissance induite pour tourner (la puissance induite est calculée en fonction de la densité de l'air sur Mars et de la masse du SOI). Cette puissance induite est fournie par la fonction "Convertir la puissance électrique en couple", attribuée au sous-système "moteur". La puissance électrique est fournie par le pack batterie qui sera dimensionné (en termes de nombre d'éléments de batterie) en fonction de la puissance induite nécessaire (et donc de la masse du SOI). Cependant, on peut remarquer que le dimensionnement du pack batterie aura un impact sur la masse du SOI, ce qui entraîne une boucle. Grâce à l'exploration fournie par Geeglee, cette boucle peut être facilement résolue (nous verrons comment, dans la partie sur les règles). Mais pour éviter de créer un aspirateur martien, nous avons introduit une contrainte au niveau du système pour tuer les solutions fournissant suffisamment de puissance induite pour faire fonctionner le rotor mais pas pour permettre au SOI de voler : "puissance induite au poids à vide (W)"<"puissance induite (W)". Regardez la deuxième contrainte dans la figure ci-dessous.
3. Paramétrage de la vue de la boîte blanche
Au cours de cette étape, le système d'intérêt est considéré comme une boîte blanche. En d'autres termes, le SOI est considéré comme une agrégation de sous-systèmes permettant de répondre aux attentes.
Architectures & Configurations :
Geeglee est capable de gérer plusieurs architectures en même temps (pas seulement des configurations).
Définition :
Dans notre approche, l'architecture est considérée au sens de Crawley : l'allocation de fonctions en sous-systèmes constitue une architecture. Les configurations sont définies à l'intérieur d'une architecture par la combinaison d'alternatives pour chaque sous-système de notre SOI.
Comme vous le découvrirez en pratiquant avec Geeglee, la façon de penser est entièrement corrélée à l'architecture.
Jusqu'à présent, Geeglee ne capitalise que sur les fonctions feuilles et le dernier niveau de la PBS (Product Breakdown Structure).
Les pages "Product Breakdown Structure" et "Engineering Patterns" vous guideront dans la mise en place de la vue White-box.
La page "Product Breakdown Structure" est composée de cinq onglets :
-
"Modules" utilisés pour détailler les deux sous-systèmes composant le SOI et l alternative technique disponible pour chaque sous-système,
-
"Caractéristiques" contenant les caractéristiques techniques nécessaires pour décrire le compromis entre les alternatives des modules,
-
"Valeurs" utilisé pour spécifier les valeurs de chaque caractéristique technique par alternative,
-
"Incompatibilités internes" utilisé pour décrire les interfaces du SOI (dans Geeglee, les incompatibilités sont un type d'interfaces),
-
"Toutes les incompatibilités" définissant les interfaces entre la ventilation du SOI et le système environnemental.
Modules :
Dans cet onglet, on peut désigner :
Tous les modules composant le SOI (cela doit être fait par l'administration : se référer à la page web du tutoriel vidéo pour découvrir comment).
CONSEILS : faites attention lors de la Ventilation Fonctionnelle, la liste des modules doit couvrir l'ensemble du SOI sans chevauchement entre eux. De même, nommez les modules sans ambiguïté. Les noms doivent avoir un sens pour chaque personne impliquée dans le projet, puisqu'ils seront utilisés dans la page des schémas d'ingénierie...
Si vous avez défini plusieurs architectures, n'oubliez pas de préciser quel module contribue à quelle architecture. Dans l'exemple suivant, le module "Battery cell" est affecté à la fois aux architectures "Rover" et "Solar".
CONSEILS
L'attribution aux architectures peut se faire à deux niveaux. D'abord au niveau du module, c'est-à-dire qu'un sous-système est affecté ou non à chaque architecture. On peut aussi, pour un module donné, affecter des alternatives aux architectures. (voir paragraphe suivant). Il sera géré par Geeglee.
Pour chaque module, précisez les alternatives qui peuvent répondre aux attentes du module.
CONSEILS
-
Dans cet onglet, vous pouvez attribuer une ou plusieurs alternatives à une ou plusieurs architectures dédiées.
-
Quelle est la meilleure pratique entre créer un module dédié pour une architecture ou une alternative dédiée ? Notre recommandation est la suivante :
-
Si la fonction est la même entre les deux modules des architectures, gardez un module et préférez allouer des alternatives à l'architecture (cela simplifiera le travail en Engineering Patterns). C'est la solution que nous avons retenue pour le "Power charging system" du drone martien : la fonction est la même (fournir de l'énergie) donc nous avons attribué des alternatives aux architectures concernées (la prise à celle du rover et le panneau solaire à l'architecture solaire.
-
Si la fonction n'est pas la même entre les modules des architectures, préférez créer deux modules distincts, un pour chaque architecture.
-
CONSEILS
Vous pouvez activer ou désactiver les alternatives. En désactivant les alternatives, Geeglee les ignore pendant l'exploration (ceci est utile pour accélérer les calculs lors de la convergence vers un sous-ensemble de solutions, mais aussi pour se rappeler quelles alternatives ont été explorées avant la convergence).
Vue finale de l'onglet "Modules". "7/14" alternatives pour "cellule de batterie" signifie que 7 alternatives ont déjà été éliminées (désactivées) au stade du développement.
Caractéristiques :
Dans cet onglet, on peut spécifier la liste des caractéristiques techniques utilisées pour décrire les alternatives de chaque module (Une fois encore, veillez à leur donner des noms non ambigus). Notez qu'une caractéristique technique peut être utilisée pour plusieurs alternatives de plusieurs modules (comme par exemple, le coût unitaire).
CONSEILS
-
Comment choisir entre définir une caractéristique technique pour plusieurs alternatives ou une pour chacune d'entre elles ? Si possible, le fait d'avoir des caractéristiques techniques communes entre les modules vous permettra de créer le modèle plus rapidement et de créer des modèles d'ingénierie plus génériques.
-
Quel niveau de détail doit être saisi ? Deux éléments doivent être pris en compte :
-
Toute caractéristique technique que les experts considèrent comme importante pour évaluer le HLR (High Level Requirements set in Black-box view),
-
Toute caractéristique technique qui nous permet de comprendre le compromis entre deux alternatives (une bonne pratique consiste à éviter d'avoir deux alternatives avec les mêmes valeurs - aucun choix ne sera alors possible).
-
Valeurs :
Dans cet onglet, saisissez les valeurs de chaque caractéristique technique de chaque alternative de chaque module (remplissez le catalogue des alternatives techniques).
CONSEILS
Remplissez les données un module à la fois. La cohérence entre les variantes doit être suffisante pour obtenir des analyses pertinentes du SOI.
Vous aurez une vue dégagée :
Déplacement vers la page "Modèles d'ingénierie".
Par défaut, la page s'ouvre sur l'onglet "Patterns" mais un autre est disponible : "Variables de conception".
Patterns :
Dans cet onglet, listez toutes les règles que vous avez en tête (ou que vous pourrez mettre sur la table en interrogeant votre système n°1).
CONSEILS
-
Geeglee récupère automatiquement les sorties HLR. Commencez donc par les règles nécessaires pour les obtenir, car il s'agit de la portée minimale requise pour évaluer l'espace de conception (espace commercial) de votre DI.
-
Décomposez les étapes de l'analyse autant que possible.
Par exemple :
Coût total de possession (k€) = CAPEX (k€) + OPEX (k€), alors
CAPEX (k€) = Investissement (k€)/Nbre d'années de vie utile (#)
OPEX (k€) = nombre d'employés (#) * salaire moyen (k€)
-
Si vous avez besoin de convertir des k€ en M€ par exemple, créez une règle pour effectuer cette conversion :
Convertir k€ en M€ = 1/1000, et ensuite l'utiliser :
Coût (M€) = Coût (k€) * Convertir k€ en M€
-
La définition des règles est un processus itératif, ce qui signifie qu'un premier modèle peut être atteint facilement en utilisant des règles "simples" ou "approximatives". Ces règles peuvent être affinées ultérieurement si nécessaire. Par exemple, dans l'exemple ci-dessus : OPEX (k€) = nombre d'employés (#) * salaire moyen (k€) peut être frustrant car il considère que chaque employé a le même salaire. Ainsi, les règles peuvent être affinées comme suit plus tard dans le projet :
OPEX (k€) = nbre d'ingénieurs (#) * salaire moyen des ingénieurs (k€) + nbre d'opérateurs (#) * salaire moyen des opérateurs (k€).
Cette approche peut être poursuivie autant que vous le souhaitez.
-
Factorisez autant que possible ! Pour avoir un modèle facile à maintenir, factorisez autant que possible, ce qui signifie que vous devez éviter d'avoir des parties communes dans deux règles.
-
Remarquez comment définir des règles pour toutes les architectures ou pour une architecture spécifique. Les règles peuvent aussi ne concerner qu'une seule architecture.
Pour avoir plus de détails sur la bonne façon de concevoir des modèles, jetez un coup d'oeil à :
Guide de démarrage rapide GEI
Comment exploiter les données générées avec
Geeglee Engineering Pattern ?
-
Structuration de votre projet
-
Enrichissement et détail de chaque section
-
Focus sur les pages et éléments clés
Le logiciel Geeglee Engineering Pattern est utile pour explorer le champ des possibilités et trouver tous les compromis possibles (en se basant à la fois sur votre savoir-faire en matière d'ingénierie et sur votre catalogue de solutions techniques, qui peuvent être des solutions existantes, de nouvelles idées potentielles ou des composants prêts à l'emploi).
Comme le but de Geeglee n'est pas de remplacer les humains, Geeglee ne décide PAS pour vous.
Geeglee Intelligence est l'outil, issu de la suite Geeglee, qui permet de "jouer" avec les données et de décider quelle(s) solution(s) est la bonne pour vos objectifs (que ce soit une solution à un besoin spécifique ou une plateforme (ligne de produits)).
Cette partie vous permettra de comprendre comment utiliser le GEI afin de trouver le "bon chemin".
1. Structuration de votre projet
L'organisation de votre travail est libre dans Geeglee Intelligence, vous pouvez donc créer n'importe quelle page de données et autant que vous le souhaitez (par exemple : pages de définition de problèmes, pages de résolution de problèmes, pages d'étude détaillée).
CONSEILS
Le paragraphe suivant vous montre une façon simple, rapide et efficace de structurer votre analyse dans Geeglee Engineering Intelligence.
Exemple d'une structure de projet en 4 sections
-
"Home" vous permettra d'avoir une page d'accueil après avoir ouvert le projet (cela peut prendre quelques secondes selon l'ampleur de votre exploration et de l'ambition de votre projet).
-
"Problem setting" est la partie dans laquelle vous décrivez les besoins que votre SOI doit satisfaire (un extrait de la vue boîte noire de Geeglee Engineering Pattern).
-
"Problem solving" est la partie dans laquelle vous définirez des scénarios d'analyse pour étudier votre problème (ces pages de données vous permettront de capitaliser sur la meilleure façon de l'analyser). Encore une fois, dans Geeglee, nous séparons la façon de penser de l'exploitation des données.
-
"Detailed studies" est la partie dans laquelle toute discipline peut créer ses points de vue (il peut y avoir plus d'une page de données par discipline).
Exemple de structuration dans Geeglee Intelligence
"Home" : Premier contact accueillant et explicite
Nous recommandons d'intégrer une page d'accueil dans la section "Home" pour permettre une compréhension rapide du projet et de ses objectifs. La page d'accueil est d'autant plus importante si vous envisagez de présenter ou de partager votre projet de Geeglee Engineering Intelligence avec des collègues, des experts d'autres secteurs ou même des clients.
Elle doit donc permettre de comprendre en un coup d'œil le sujet et les enjeux.
"Problem setting" : Présentation synthétique du ou des système(s) étudié(s)
Cette partie a pour but de présenter les éléments clés permettant de comprendre votre projet, son contexte, ses objectifs et les critères de performance attendus. Elle peut donc inclure des parties structurelles telles que la définition du besoin (approche boîte noire).
"Problem solving" : Investigation des données selon différents modes et objectifs d'analyse
Cette section est consacrée à la définition du système modélisé et de ses sous-systèmes (approche boîte blanche), et à la construction de scénarios d'analyse qui faciliteront l'exploration du ou des systèmes.
Ces scénarios d'analyse peuvent avoir différents objectifs et approches. Par exemple, vous pouvez créer des scénarios d'analyse qui répondent à :
-les questions que vous étudiez régulièrement (Quelle est l'architecture la moins chère pour les performances requises ? Quels sont les principaux facteurs de coût ? etc,)
-les attentes de vos clients (Quel coût pour quelle architecture ? Quel est l'encombrement si je choisis l'architecture la moins chère ? etc,)
-les modes d'investigation ou les problématiques de vos collègues (Quelle est la rentabilité financière potentielle du développement d'une telle architecture ? Quelles sont les ressources humaines à associer au développement de ce projet ? etc.)
Conseils : La création de scénarios d'analyse, doit être un travail d'équipe pour intégrer l'expertise et le savoir-faire des participants.
"Detailed studies" : Ventilation des composants et des paramètres du ou des système(s) étudié(s)
Cette section présente en détail les composants et les paramètres du ou des système(s) étudié(s) et de ses sous-systèmes, entre autres :
-
Découpage de l'architecture,
-
Point de vue de la discipline,
-
Répartition des critères de performance,
-
Découpage de la technologie,
Les pages créées dans cette partie seront particulièrement importantes et utiles pour les experts qui pourront travailler et interpréter les résultats de manière plus détaillée.
2. Enrichissement et détail de chaque section
Vous trouverez ci-dessous un exemple de structuration détaillée de projet.
Exemple de structure détaillée du premier niveau d'un projet
Exemple de structuration de Geeglee Engineering Intelligence
3. Focus sur les pages et éléments clés
Dans cette section, nous allons vous montrer comment concevoir les pages clés de votre fichier de projet dans Geeglee Engineering Intelligence en nous basant sur un des projets de nos clients. Cet exemple est la conception d'un drone destiné à être envoyé sur Mars pour effectuer des missions d'observation et/ou de transport de marchandises.
Exemple de structuration détaillée de Geeglee Engineering Intelligence
3.1. Créez votre "Home" (Page d'accueil) - Comment faire passer rapidement l'objectif de votre projet ?
Une bonne page d'accueil comprend souvent quelques éléments clés tels que :
-Un titre,
-Un court paragraphe de présentation,
-Une image de bonne qualité présentant explicitement le contexte, les objectifs ou le concept,
-Les logos des parties prenantes,
Cette page est le premier contact, elle doit donc être accueillante et explicite pour faciliter la compréhension et aussi donner envie d'en savoir plus sur votre projet.
Exemple d'un extrait de page d'accueil du projet "Drone martien" pour le CNES en Geeglee Engineering Intelligence
3.2. Structuration de la section "Problem setting" - Quelles informations sont nécessaires pour bien contextualiser votre projet ?
Afin de contextualiser votre projet et ses objectifs, nous vous recommandons de résumer :
-le contexte des opérations (Dans quelle situation votre système doit-il être déployé ?),
-le(s) besoin(s) (À quel(s) objectif(s) votre système doit-il répondre ? Que doit-il faire ?)
-les critères de performance attendus (Sur quoi se fonde l'évaluation de la satisfaction du ou des objectif(s) ?),
Exemple de page de définition du problème décrivant le contexte du projet, tiré du projet "Drone martien" pour le CNES dans Geeglee Engineering Intelligence
Exemple de page "Problem setting" précisant les critères de performance du système du projet "Drone martien" pour le CNES dans Geeglee Engineering Intelligence
3.3. Structuration de la rubrique "Problem solving" - Comment concevoir un scénario d'analyse ?
Vous avez modélisé votre système et ses sous-systèmes dans Geeglee Engineering Pattern, il est maintenant temps de l'explorer !
L'exploration de données est une activité passionnante, cependant, on peut s'y perdre rapidement, nous vous recommandons donc de construire des scénarios d'analyse. Ceci est un exemple de scénario, néanmoins, de nombreux autres scénarios pourraient être créés tels que :
-Quel est le coût de l'atterrissage sur Mars ?
-Quel type de mission(s) peut-on réaliser avec l'architecture de drone la plus légère ?
-Quelle est l'architecture la plus robuste pour couvrir les différents types de missions ?
Pour concevoir un scénario d'analyse, vous devez d'abord définir ce que vous voulez savoir, à quelle(s) question(s) vous voulez répondre.
Dans le cas du projet pris pour exemple, on souhaite connaître l'architecture de drone la plus fiable, il est donc nécessaire de définir plusieurs éléments de contexte et de besoins pour effectuer cette analyse.
Exemple de page "Problem solving" intégrant un scénario d'analyse pour visualiser l'architecture la plus fiable, du projet "Drone martien" pour le CNES dans Geeglee Engineering Intelligence
Premièrement, il est important de choisir pour quel type de mission on veut que l'architecture du drone soit la plus fiable, car certaines caractéristiques de la mission peuvent augmenter le risque de panne de fiabilité (besoin de pouvoir charger, durée de la mission).
Exemple de page "Problem solving" intégrant un scénario d'analyse pour visualiser l'architecture la plus fiable, du projet "Drone martien" pour le CNES dans Geeglee Engineering Intelligence
Exemple de première étape d'un scénario d'analyse : Choisir le type de mission pour visualiser l'architecture la plus fiable,
du projet "Drone martien" pour le CNES dans Geeglee Engineering Intelligence
Nous pousserons ensuite le système dans ses retranchements en précisant la masse maximale de la charge utile. Comme la masse maximale de la charge utile peut être un facteur important de défaillance de la fiabilité, nous choisirons la masse la plus élevée disponible.
Exemple de seconde étape d'un scénario d'analyse : Spécifiez la masse de charge utile maximale pour afficher l'architecture la plus fiable, du projet "Drone martien" pour le CNES dans Geeglee Engineering Intelligence
Après avoir choisi le type de mission et sélectionné la masse maximale de la charge utile, nous terminerons en fixant la fiabilité attendue dans différentes circonstances (poussière, rayonnement et avant lancement).
NB : Vous pouvez constater qu'à ce stade, tous les niveaux de fiabilité ne sont pas disponibles. En effet, les choix que nous avons faits précédemment ont déjà écarté certains niveaux de fiabilité, ce qui signifie que si nous voulons un niveau de fiabilité plus élevé pour certaines circonstances, nous devrons revoir les choix précédents (durée de la mission, masse maximale de la charge utile).
Exemple de seconde étape d'un scénario d'analyse : Définition du niveau de fiabilité pour visualiser l'architecture la plus fiable, du projet "Drone martien" pour le CNES dans Geeglee Engineering Intelligence
Nous avons choisi le type de mission, spécifié la masse maximale de la charge utile et fixé le plus haut niveau de fiabilité disponible, nous pouvons maintenant savoir quelle architecture privilégier !
Exemple de résultats d'affichage de l'architecture la plus fiable du projet "Drone martien" pour le CNES dans Geeglee Engineering Intelligence
3.4. Structuration de la rubrique "Detailed studies" - Qu'est-ce qu'une « étude détaillée » ?
Une modélisation et une exploration de système(s) nécessitent des analyses détaillées de certains paramètres tels que :
-Le découpage de l'architecture pour l'étudier plus précisément,
-Le point de vue de la discipline pour que les experts participant au projet puissent trouver leurs références à revoir,
-Les ventilations des critères de performance pour comprendre comment ils sont obtenus,
-Le découpage technologique pour distinguer certains résultats et ainsi arbitrer les orientations finales,
NB : Nous attirons votre attention sur la nécessité de prioriser les pages créées dans cette rubrique car vous pouvez rapidement être submergé par un grand nombre d'analyses techniques et avoir des difficultés à les utiliser. Nous vous recommandons donc de ne créer que des pages techniques thématiques ("Detailed studies") et de ne pas hésiter à créer des scénarios d'analyse ("Problem solving") dès que vous réalisez une étude en naviguant entre plusieurs pages techniques.
Pour avoir plus de détails sur la bonne façon d'exploiter les données grâce à Geeglee Engineering Intelligence, jetez un œil à :