L’une des prochaines grosses étapes est de dégrossir le système global PHOENIX, on propose pour cela une réunion de travail basée sur la méthodologie MBSE, ce sera animé par @loic.fejoz. Pouvez-vous donner vos disponibilités sur ce Framadate : https://framadate.org/Yj51U4qzmk5FAiQs ?
On va essayer de coller au mieux à cette méthodologie tout au long du projet.
2 « J'aime »
1 « J'aime »
pour l’instant on est en pre pre pre pre Phase A 
En somme, on va avoir besoin d’accompagnement méthodologique - je comprends de tes schémas qu’on a un spécialiste dans l’équipe 
Au-delà des schémas intimidants, je pense que le point clé sera de se fixer sur les livrables concrets qui feront office de jalons au fur et à mesure. Rendez-vous semaine prochaine pour la suite ! Avec pour le moment une cible au 11/11 à 21h pour la réunion.
C’est le principe de l’ingénierie système que de faire l’intégration des différents domaines/points de vues mais je pense @fabio.mainolfi, tu le savais déjà. 
What is Systems Engineering?
Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.
INCOSE
Bien évidement, ce n’est pas l’application d’un cycle en V, mais bien à appliquer de manière itérative.
Et pour ceux qui voudrait l’appliquer façon NASA, le NASA Systems Engineering Handbook est fort intéressant ; en plus agnostique, il y a le SEBoK ; en plus guidé, il y a Arcadia.
Et si @fabio.mainolfi me dit qu’il faut faire du DO178-C pour l’implémentation, on peut aussi en parler. 
1 « J'aime »
@loic.fejoz de mon côté je ne suis pas un expert mais des vieilles connaissances à dépoussiérer 
.
En effet il y a plein de methodes d’ingénierie système et chaque organisation a la sienne et il y a plein de standard et groupes de travails sur le sujet. L’enjeu est donc (bien d’accord avec @loic.fejoz ) de trouver la manière d’intégrer tout cela de manière compréhensible pour le plus grand nombre. Il faudra juste veiller à avoir des points d’étape pour être conformes aux normes ECSS au moins en termes de jalons et documentation.
Pour la SE a priori c’est la ECSS‐E‐ST‐10C et en phase 0 il n’y a pas beaucoup de documents à produire
La réunion est fixée le 11/11 à 21h, c’est ajouté dans le calendar NextCloud du projet.
@loic.fejoz tu es bien dispo, puisque c’est toi qui anime 
Oui c’est bon pour moi @damien.hartmann
1 « J'aime »
Bonjour à tous,
Je découvre votre projet qui me semble très intéressant et multi-métier. A ce que je vois vous êtes en recherche d’architectures amont,selon Fabio en:
en pre pre pre pre Phase A
et selon son point sur le Design to cost,
Il serait aussi pertinent d’essayer de coupler cela avec du Design to Cost (DFM, DFA, DFT, etc.)
c’est dans cette phase où 80% des coûts d’un projet se décident et où tous les leviers de coûts sont libres.
Votre problématique m’inspire car dans nos projets spatiaux complexes, nous sommes pratiquement toujours confrontés à cette phase inspirante mais parfois frustrante de l’exploration d’architectures (en début de phase A). On a envie de tout tester mais on restreint toujours notre champs d’investigation et on limite les architectures à explorer.
Vous parlez d’utiliser Capella et c’est un bon réflexe selon moi. C’est un outil que l’on utilise même s’il nécessite une certaine maitrise. Cependant, selon moi, même s’il faut instruire Capella très tôt comme vous le faites, je pense que vous pouvez aussi initier une modélisation paramétrique en amont pour aider cette recherche d’architecture. Car attention de ne pas trop s’épuiser à rentrer dans l’architecture fonctionnelle et produit tant que vous n’avez pas « débroussaillé » les architectures possibles. Si je comprends votre projet, cette phase de recherche d’architectures doit explorer des solutions technico-économiques selon plusieurs critères de performance sur la partie « satellite » (satellites, charge utile, stations sols…) et la partie aval « IT » (infrastructure numérique, langage, stockage, calcul…). Bref vous devez traiter des systèmes de systèmes…
Pour ce faire j’ai pensé à une solution logiciel/conseil malheureusement privée et non open-source mais elle est en expansion, Française et très reconnu dans des industries de système complexes. Le CNES l’a essayé pour explorer l’architecture de drones martiens et en a été satisfait.
La solution :
http://www.geeglee.net/faq =>voir « Is Geeglee a MDO software?” pour voir le positionnement de l’outil par rapport à Capella
Et il reste aussi compatible de capella :
L’exemple du CNES présentée par le pdg de la boite. Il en a fait une présentation TeDX
ATTENTION La modélisation n’est exploitable qu’avec le logiciel sous Licence mais toute l’ingénierie et la connaissance générée est récupérable en format excel et documentaires il me semble. Et dans le cadre d’une étude, il y a quelques mois d’exploitation du modèle compris.
Personnellement je n’ai pas de part dans la boite et je n’en ai pas parlé à l’éditeur. 
Je pense simplement qu’il y a de la matière pour faire au moins une étude avec cet outil. Et je suis sûr qu’une association aussi majeure qu’OSM pourrait être aussi un relai de communication pour eux ! « L’innovation, n’est pas qu’une affaire de grands groupes! »
A vous de vous en faire une idée dans tous les cas 
Si cela vous inspire, il est peut-être possible de réfléchir à faire quelque chose avec le CNES qui aurait des ressources, de bonnes idées et connaissances aussi pour vous aider…mais là c’est pas moi qui intervient 
A bientôt et amusez vous bien sur ce projet!
Léonard Pineau (référent Themis-open, salarié CNES/ Arianeworks sous la convention CNES/OSM)
4 « J'aime »
N’étant pas familier des méthodos d’ingénierie classique, quelles seraient les alternatives habituelles pour réaliser cette phase (à part Excel) ?
Et peut-être faut-il commencer à lister les paramètres tout simplement, et selon leur nombre envisager de demander à GeeGlee une version « association gratuite » de leur soft ?
Pour donner un exemple concret de trade-off que je comprends que cet outil aiderait à faire c’est : quelle serait la durée de vie du satellite liée à son poids à une certaine orbite liée à la masse de carburant pour contrôle d’altitude lié à la puissance de calcul embarqué lié à l’énergie fournie par les panneaux solaires ? Et de pouvoir faire varier tous ces paramètres indépendamment de voir l’impact sur l’ensemble du système ?
Toutes mes excuses si mes questions très naïves de commercial enfoncent des portes ouvertes ou sont hors de propos 
Je m’associe à tes questions en tant que ingénieur-pas-système 
En tant que béotien, est-ce que tu peux expliciter @leonard.pineau ce que ça représenterait dansde notre phase de pré^3-projet ? Est-ce l’idée mettre en place une sorte de modèle basé sur les grandes lois physiques et trucs dimensionnants, afin de générer plein de configurations possibles, pour ensuite étudier plus en étails les plus intéressantes ou originales ?
Ca me semble être une bonne reco de ne pas tout de suite concevoir en détails afion de pas se retrouver dans une impasse ceci dit j’avais cru comprendre que l’approche MBSE proposée par @loic.fejoz permettait justement de partir des besoins puis de descendre vers les grandes fonctions et sous systèmes
En regardant la vidéo de @leonard.pineau (super intéressant) je comprends qu’on parle d’une phase de screening du champ des possibles où Geeglee est un outil innnovant.
Mais est que c’est pas surdimensionné par-rapport à l’expertise du groupe projet à date ?
L’alternative c’est des petits modèles dans un tableur ?
Dans tous les cas il faut qu’on parte de ce que doit faire Phoenix pour cabler le modèle paramétrique, on peut déjà commencer par là.
En tous cas merci @leonard.pineau de ton billet super détaillé, même si il génère plein de questions. on va y arriver
oui
oui
oui
A discuter donc
1 « J'aime »
Cool on commence à comprendre
OK next step prochaine réu phoenix la semaine pro on retrousse les manches ?
1 « J'aime »
Merci @leonard.pineau pour ces liens.
C’est effectivement très intéressant.
Malheureusement il manque dans ces ressources les indications sur comment décrire ces interactions entre les paramètres. 
Cela me rappelle des maquettes logiciels que j’ai pu faire dans le passé en SysML avec les diagrammes paramétriques et des simulateurs VHDL-AMS ou Modelica… 
Petite précision tout de même : leur positionnement de Capella vis à vis de leur outil est partiel. En effet, la première étape dans Capella est la description du besoin opérationnel.
Or justement, ils placent cette définition eux aussi avant.
Donc en fait, le workflow serait plutôt :
Operational Analysis Capella -> Design Exploration (par exemple avec Geeglee) -> Formalizing Architecture in Capella Functional / Logical Analysis / Physical Analysis.
Par ailleurs, la partie exploratoire dans Capella n’est pas forcément aisée. Par contre, il est aisée de développer des Add-Ons spécifiques. Je pense que OpenSpaceMaker devrait pouvoir développer des add-ons spécifiques au développement de CubeSats et autres systèmes spatiaux.
Je vois ici très bien des liens avec les divers projets concernant la dynamique de vols comme meca_vol d’Ad Astra, ou du projet Aerospace Software Engineering, ou encore simplement d’OpenRocket par exemple.
Par ailleurs, la littérature contient plein d’exemple de cosimulation similaires au back-end de Geeglee (mais l’interface de Geeglee est vraiment bien pensée). Par exemple, certains ont utilisé des algo génétiques récemment.
Mais il est vrai aussi que même la norme ISO/CEI 29110 d’ingénierie système place les tests de faisabilité bien en amont du projet.
Bref, on a de quoi s’amuser ! 
1 « J'aime »
Malheureusement il manque dans ces ressources les indications sur comment décrire ces interactions entre les paramètres.
Il s’agit concretement de gérer des bases de données caractérisées et des équations paramétriques. C’est du Excel + avec une IHM sympa , sans limitation de calculs et avec l’intervention d’algo qui facilitent l’exploration des architectures. Je suis sûr que c’est possible d’en faire un outil perso mais on peut s’y épuiser et on peut manquer l’inclusion et la discussion multi-métiers nécessaire à ce stade (il est souvent difficile d’embarquer les acteurs du projet sans un outil rassembleur et intelligible par tous selon moi).
Donc en fait, le workflow serait plutôt :
Operational Analysis Capella → Design Exploration (par exemple avec Geeglee) → Formalizing Architecture in Capella Functional / Logical Analysis / Physical Analysis.
Tout à fait je suis d’accord avec toi.
Par contre, il est aisée de développer des Add-Ons spécifiques.
Oh bien entendu! Après cela dépend de l’urgence du projet. Cela peut être fait en préalable ou en parallèle et en effet tes liens sont très explicites!
similaires au back-end de Geeglee (mais l’interface de Geeglee est vraiment bien pensée
Son critère de différenciation de toute évidence
Bref, je pense que tu es bien placé pour être l’architecte de la modélisation avec ou sans geeglee et de toute évidence, Phoenix fera office de référence dans l’approche système pour OSM en termes de méthode et d’outils.
1 « J'aime »
Je viens de publier un article sur le sujet du MBSE appliqué à Phoenix et son intérêt plus global pour Fédération. Tout feedback pour le corriger / modifier / améliorer sera le bienvenu !
2 « J'aime »
Vous retrouverez dans l’espace projet de Phoenix (session du 9/12/2020) une explication en vidéo par Loïc des premières étapes de l’application du MBSE à Phoenix. C’est une excellente introduction et à la méthode et au projet.
1 « J'aime »