Kepler - Mission du télescope spatial

ici : http://kepler.nasa.gov/about/news.html

pour apprendre que l'engin était en mode de sauvegarde suite à un bug logiciel.
Cela a retardé l'ouverture de la protection du miroir ( un "Dust Cover" ) et donc des premières mesures de luminosité.

VONFELD

Ah ! ces bugs logiciels. :pale:
On ne peut pourtant pas dire qu'il n'y ait pas des armadas de programmeurs qualifiés, et des batteries de tests censées passer au crible toutes les lignes de code, dans tous les scénarios possibles de séquences.

Mais on reste démuni ... il y a toujours un cycle qui n'a pas été testé et qui plante à cause de ce petit grain de poussière. :affraid:

Even though this only lasts for one-tenth of a second, the spacecraft senses something it didn't expect and responds by pointing its solar arrays directly at the sun and awaiting further instructions from Earth.

Arrivera-t'on à une complète maturité dans cette science si complexe ? Le "patch" reste-t'il la solution ?

Indispensable ... de gagner encore en fiabilité logicielle pour ces missions ... même si on sait qu'on arrive souvent à rattraper le coup par télémétrie.

Si Kepler en orbite terrestre joue des tours ... les équipes vont se faire des cheveux pour le JWST qui sera au point de Lagrange.

Etant programmeur moi-même, je connais la difficulté d'arriver au zéro défaut. Je travaille en bancassurances, donc les exigences sont moins extrêmes, mais je me souviens qu'on avait rajouté une étape systématique de cahiers de validation et de tests de validation, après les tests unitaires, et avant l'homologation par les métiers. Ca avait fait passer le cout de la modification unitaire de 9 heures à 20 heures, pour un gain en fiabilité réel, mais modéré.

La programmation, ça reste un art. L'art d'anticiper tous les cas possibles. Aucune méthode connue ne permet de garantir un code fiable à 100% - car une méthode, aussi parfaite soit-elle, ne permet de tester que les cas envisagés..... même si certains sont capables de faire des choses magnifiques dans le domaine.

Ce qui est important, c'est d'avoir un système redondant, résilient ou robuste (au choix, je laisse les spécialistes préciser ), pour survivre au bug logiciel qui se produira quoi qu'on ait prévu.
Aujourd'hui toutes les sondes modernes sont expédiés vers leur destination alors que la validation du code logiciel n'est même pas encore terminée.
Spirit et Oppy ont encore réçu une mise à jour logiciel récemment...
Outre les corrections de bug, il y a également les possibilités d'amélioration des performances par ce moyen là ( par exemple les logiciels de compression utilisées par Galileo pour suppléer à la défaillance de l'antenne grand gain )

VONFELD

Vonfeld a écrit:Ce qui est important, c'est d'avoir un système redondant, résilient ou robuste (au choix, je laisse les spécialistes préciser ), pour survivre au bug logiciel qui se produira quoi qu'on ait prévu.
(.../...)

On est bien d'accord. La première chose à faire est de detecter et gérer les erreurs. Car il y en aura.

Exemple hors-contexte, une grande banque Française sort un nouveau type de carte de retrait. Prudente, elle n'ouvre le produit qu'à un seul de ses alariés histoire de vérifier que ça marche. Le salarié va retirer 20 €uros au distributeur, tout va bien. Sauf que son compte n'avait pas été débité. Dans la nuit 11 alarmes ont sonné. Des erreurs arrivent, il suffit de les detecter, et de les corriger.(enfin, c'est pas toujours aussi limpide, hein...).

Evidemment, ça n'exempte pas d'une solide campagne de qualification et d'une permanente chasse au bug.....

Les ingénieurs sont parvenus a retiré la "dust cover", ouf!! :bounce:
Le photomètre va pouvoir travailler.
http://spaceflightnow.com/news/n0904/07kepler/

Si Kepler en orbite terrestre joue des tours ... les équipes vont se faire des cheveux pour le JWST qui sera au point de Lagrange

Dans les 2 cas aucune réparation n'est possible je crois, Kepler est en orbite terrestre mais sur une orbite héliocentrique dos au soleil, sur une orbite en peu en retard sur celle-ci, sa distance avec la Terre augmente au fil des années jusqu'a atteindre 0.5 UA et être a mi-distance de L5.
http://kepler.nasa.gov/sci/design/orbit.html

:scratch: :scratch: Ouh là là, je suis complètement perdu sur l'orbite que suis Kepler.
Je crois que Kepler est en L2.



avec une vue en 3D :



si L2 est toujours derrière la terre par rapport au soleil, comment se fait-il que Kepler peut se retrouver entre la terre et le soleil. ( d'après le dernier shema d'Antares101 )

Je pense que tu "téléscope" Kepler et Herschel/Planck qui eux ce trouveront bien près de L2 je crois? Car mon schéma est tiré du site officiel.
Voici une illustration de la manip conçernant la dust cover tirée aussi du site.


Les détails du photomètre : http://kepler.nasa.gov/sci/design/spacecraft.html
Le champs de recherche de Kepler vers Cygnus :

Oups :oops: et puis bien télescopé !

Antares101 a écrit:

Si Kepler en orbite terrestre joue des tours ... les équipes vont se faire des cheveux pour le JWST qui sera au point de Lagrange

Dans les 2 cas aucune réparation n'est possible je crois

Je ne pensais pas à y aller pour réparer .... mais je pensais qu'on maitrise mieux les paramètres de cette orbite terrestre (donc les modifications par voie télémétrique seraient plus faciles) du genre secouer un peu le prunier avec les moteurs d'attitude..
Pour L2, la mécanique céleste doit être plus délicate à gérer ? et il y a un délai de transmissions plus long.
Mais peut-être ai-je tort ?

Une des "dérives" que peut rencontrer la programmation, c'est que plus çà va, plus on a de la place disponible (les quelques ko d'il y a quarante ans, sont devenus des Go) ... du coup pas sûr que la concision et la rigueur en programmation soient favorisés.
On a bien parlé de mise en place de consignes de "rigueur programmatique" ... mais j'ai comme un doute que les programmeurs s'y plient vraiment.
Il n'y a qu'à voir la panique qui peut étreindre une société quand le programmeur maison va voir ailleurs ou prend sa retraite ... et que le remplaçant n'arrive pas à "entrer dans le code" :pale:

montmein69 a écrit:(.../...)
Une des "dérives" que peut rencontrer la programmation, c'est que plus çà va, plus on a de la place disponible (les quelques ko d'il y a quarante ans, sont devenus des Go) ... du coup pas sûr que la concision et la rigueur en programmation soient favorisés.
On a bien parlé de mise en place de consignes de "rigueur programmatique" ... mais j'ai comme un doute que les programmeurs s'y plient vraiment.
Il n'y a qu'à voir la panique qui peut étreindre une société quand le programmeur maison va voir ailleurs ou prend sa retraite ... et que le remplaçant n'arrive pas à "entrer dans le code" :pale:

Ces deux points n'ont rien à voir. On programme peut être parfaitement concis, et très difficille à interpreter, ou au contraire très bavard, et très lisible. Il n'y a pas de rapport.

D'ailleurs, la "rigueur programmatique", c'est essentiellement faire un programme propre, lisible, et qui ne bouffe pas de mémoire de manière indue. Ces contraintes peuvent le rallonger. De même, des contraintes de performances peuvent, elles aussi, fortement rallonger le programme(je pense à la bufferisation, qui, dans certains cas, peut faire tripler la taille du code d'un appel référentiel, tout en le rendant bien plus performant).

J'insiste pour dire que si les programmeurs d'aujourd'hui(dont je fais partie) ont tendance à utiliser les outils qu'on leur fournit, ça n'est pas simplement par flemme. C'est aussi par souci de productivité. Un code C hyper-optimisé peut être très efficace avec très peu de ressources, mais il mobilisera de super-programmeurs pendant longtemps. Un code C++(sans même taper dans le très haut niveau d'abstraction) sera 3 fois plus lent, mais peu, avec une utilisation astucieuse des objets, représenter un gain de productivité important(ça se compte en dizaines de pourcent). Donc, le programme est prêt plus tôt, et coûte moins cher. Il est possiblement plus lisible, aussi. donc plus accessible au petit jeune.....

Quand au syndrome du vieux sage, il est simplement lié à l'extrême complexité des phénomènes que gère aujourd'hui l'informatique. La connaissance fonctionelle ne s'acquièrt pas en un jour. Et le petit jeune a besoin de temps pour assimiler la différence entre un numéro d'intermédiaire et un numéro d'agent, les subtilités d'un calcul de primes d'assurances, ou encore pour s'imprégner de l'architecture technique utilisée localement. Et ce, même si le code est impeccable(il ne l'est pas souvent, mais c'est un autre débat). Je précise qu'actuellement je travaille sur la refonte d'un programme dont la première version remonte à 1972, et que les grands anciens, eh bien parfois aussi ils codaient comme des chiens. Mais que mes difficultés ne se limitent pas, loin s'en faut, à ce type de brouillage. Et que l'épaisser du savoir fonctionnel à assimiler pour reprendre tout ça m'a longtemps freiné.

Moi je veux bien entendre tous ces arguments.
Les "dérives" ou "mauvaises pratiques" des débuts (je n'ai jamais dit qu'avant c'était mieux) .... auraient du entrainer des changements notables (à la fois parce que les programmeurs suivent des études .... et je suppose que les formations insistent sur ces points ? et parce que les sociétés veulent une meilleure efficacité des outils qu'elles doivent utiliser).

Je n'ai pourtant pas l'impression que cela ait vraiment été dans le sens de l'amélioration, avec tout le respect que j'ai pour les pratiquants de ce noble métier.
Les coûts de maintenance et d'évolution des logiciels ... restent en croissance perpétuelle. Ce n'est pas un jugement .. c'est un constat.
Maintenant il y a des sociétés dont c'est le business de sous-traiter cela, et de vendre à bon prix leur "technicité", elles ne vont pas se plaindre si leur chiffre d'affaire est en progression.

Je me dois d'apporter ma pierre à cette discussion sur l'informatique. En effet, je travaille dans l'informatique embarquée au sein d'une branche d'EADS et il y a tellement de chose qui font que les programmes sont "mal branlés". De plus, un audit du projet est en cours pour voir ce qui n'a pas marché. Voici un florilège des problèmes constatés :
- la plupart du temps, ce ne sont pas des informaticiens de formations qui sont recrutés. On a donc affaire à, entre autres, des ingénieurs d'écoles généralistes, des électroniciens. Il y a donc de gros problèmes de notions de programmations, ils ne connaissent pas les concepts, ni les fonctionnements fin des systèmes.
- les décideurs ne connaissent rien à la complexité de la conception et de l'écriture d'un programme. J'ai entendu dire récemment : faire un programme c'est 2 hommes pendant 1 an. C'est fou d'entendre des âneries pareil. Le responsable est capable de le ressortir cette phrase dans n'importe quelle situation, que ce soit pour réaliser un petit logiciel de test où le pilote automatique de l'A400M. Cela me rappelle un de me professeurs qui nous racontait qu'il avait vu des livres qui titraient "Faire de l'embarqué/temps réel en 10 leçons", il comparait ça à l'édition de livres titrant "une opération à cœur ouvert en 10 leçons" qui bizarrement n'existent pas...
- le manque de répartition des moyens et du temps : certains ingénieurs passent un temps fou à concevoir des câbles d'interconnexion qui sont d'une complexité toute relative alors que dans le même temps, il y a le même nombre de personne codant une application d'une complexité folle.
- l'utilisation systématique des sous traitants en interne comme main d'œuvre, faisant que les personnes qui acquiert de l'expérience sur le projet doivent partir (la limite des 18 mois)
- la problématique de l'environnement de développement inadapté

Je pourrai en citer tellement d'autre.
Résultat, on arrive à un projet qui marche comme suit :
Une équipe de 5 personnes dont 1 chef de projet, 1 ingénieur de la boîte et 3 sous traitants dont 2 électroniciens.
Un mois pour coder des fonctionnalité non spécifiées.
Un chef qui est persuadé que tout va bien se passer.

Je pourrai en dire plus si ça intéresse quelqu'un.

PS : j'ai la spécialité Systèmes répartis embarqués et temps réel du Master Systèmes et Applications Réparties de l'Université Pierre et Marie Curie / Paris 6 et je ne me permettrai jamais de donner mon avis sur de l'électronique où je n'y connais pratiquement rien !

Commander Ham a écrit:Je me dois d'apporter ma pierre à cette discussion sur l'informatique. En effet, je travaille dans l'informatique embarquée au sein d'une branche d'EADS et il y a tellement de chose qui font que les programmes sont "mal branlés". De plus, un audit du projet est en cours pour voir ce qui n'a pas marché. Voici un florilège des problèmes constatés :
- la plupart du temps, ce ne sont pas des informaticiens de formations qui sont recrutés. On a donc affaire à, entre autres, des ingénieurs d'écoles généralistes, des électroniciens. Il y a donc de gros problèmes de notions de programmations, ils ne connaissent pas les concepts, ni les fonctionnements fin des systèmes.
- les décideurs ne connaissent rien à la complexité de la conception et de l'écriture d'un programme. J'ai entendu dire récemment : faire un programme c'est 2 hommes pendant 1 an. C'est fou d'entendre des âneries pareil. Le responsable est capable de le ressortir cette phrase dans n'importe quelle situation, que ce soit pour réaliser un petit logiciel de test où le pilote automatique de l'A400M. Cela me rappelle un de me professeurs qui nous racontait qu'il avait vu des livres qui titraient "Faire de l'embarqué/temps réel en 10 leçons", il comparait ça à l'édition de livres titrant "une opération à cœur ouvert en 10 leçons" qui bizarrement n'existent pas...
- le manque de répartition des moyens et du temps : certains ingénieurs passent un temps fou à concevoir des câbles d'interconnexion qui sont d'une complexité toute relative alors que dans le même temps, il y a le même nombre de personne codant une application d'une complexité folle.
- l'utilisation systématique des sous traitants en interne comme main d'œuvre, faisant que les personnes qui acquiert de l'expérience sur le projet doivent partir (la limite des 18 mois)
- la problématique de l'environnement de développement inadapté

Je pourrai en citer tellement d'autre.
Résultat, on arrive à un projet qui marche comme suit :
Une équipe de 5 personnes dont 1 chef de projet, 1 ingénieur de la boîte et 3 sous traitants dont 2 électroniciens.
Un mois pour coder des fonctionnalité non spécifiées.
Un chef qui est persuadé que tout va bien se passer.

Je pourrai en dire plus si ça intéresse quelqu'un.

PS : j'ai la spécialité Systèmes répartis embarqués et temps réel du Master Systèmes et Applications Réparties de l'Université Pierre et Marie Curie / Paris 6 et je ne me permettrai jamais de donner mon avis sur de l'électronique où je n'y connais pratiquement rien !

Super, ton message a interessé, ne t'inquiète pas.
Moi, je suis dans une configuration légèrement différente, puisque je suis l'ingénieur généraliste (certes, avec une majeure en info indus), mais je comprends aussi le problème. L'art de coder proprement mériterait une formation à temps, mais le problème, c'est qu'il est aussi important de comprendre les systèmes qu'on doit commander... Et ça aussi, ça demande une certaine formation ! Et même si j'en suis au doctorat, je sais qu'on ne peut pas tout apprendre, et qu'à un moment, il faut bien commencer à faire les choses sans tout savoir ou tout du moins sans tout avoir déjà appris.

Le travail de programmation doit se faire en équipe.
Le chef peut même ne rien connaitre a la programmation mais doit voir l'ensemble du projet et être capable de faire une synthèse du projet.
Je n'est pas d'expérience de programmation embarqués mais dans des systèmes de gestion ( compta ). on ne peut pas être a la fois comptable et programmateur mais l'on doit faire un systèmes destiner au comptable donc dans les équipes on doit avoir des comptables et des programmateurs.

Bernard

Pour compléter ma réponse je dirai que le chef de projet doit être un bon gestionnaire mais qu'il doit aussi connaitre un peu le métier sinon il n'arrivera pas à chiffrer correctement et à comprendre les problèmes pour pouvoir les remonter.
Ceux qui connaissent bien le système doivent être les "spécificateur" qui rédigent les "specs".
Pour finir, ce n'est pas très grave si certains n'y connaissent pas grand chose, le projet avance quand même, mais il faut à tout prix et l'architecte logiciel soit un expert, c'est là que c'est très important car l'informatique c'est comme la tour de Pise, si la base (l'architecture logicielle) est bancale, la tour (tout le reste du programme) marchera de travers :)

Je terminerai juste par dire que l'informatique est complexe entre autres en embarqué/temps réel et il faudrait que les "décideurs" intègre cette notion. On demande tellement de chose à l'informatique maintenant qu'à chaque projet on risque l'usine à gaz :affraid:

2 petites anecdotes pour finir :
- l'aspect commercial :
Un commercial d'une grande société industrielle française répond à un appel d'offre de l'état qui a besoin d'une voiture pour écouter les téléphones portables. Il vend un concept autour d'une smart pouvant écouter à plusieurs kilomètre. A-t-il fait appel à des experts ? Mystère !
Résultat : un traffic (une camionnette) contenant tout un tas d'équipement pouvant écouter à quelques dizaines de mettre :D
Sans compter les retards ^^

- l'aspect chef de projet :
Un collègue à moi a eu une formation pour devenir chef de projet. Ils l'ont mis devant un logiciel censé être représentatif de la vie d'un projet en donnant à l'utilisateur (de ce logiciel), les choix importants à prendre aux moment cruciaux.
Résultat : Le projet commence, il est déjà en retard avec des délais super court. Le chef de projet engage qui il peut. Les personnes ne sont pas du tout adapter au travail demandé (compétences entre autres). Le projet prend encore plus de retard, les employés se sentant mal vont voir le chef de projet pour lui dire qu'ils en ont marre, qu'ils ne comprennent rien à ce qu'ils font. Que propose le logiciel : faire un barbecue pour remonter le moral de l'équipe. Au final, le projet est bancal, en retard, les chefs sont mécontents MAIS ils ont droit à un barbecue par semaine. J'en reste sans voix :D

2 liens pour continuer à rigoler :
http://www.gridshore.nl/2008/03/29/how-wtfs-improve-code-quality-awareness/
http://zschech.net/funny/SoftwareEngineeringProcess/

Pour revenir à notre Kepler, quelle est son orbite s'il passe entre la Terre et le soleil par moment ?

Un outil pour mieux faire connaissance avec les cibles de Kepler : ;)

http://kepler.nasa.gov/ed/xo/

Commander Ham a écrit:Pour revenir à notre Kepler, quelle est son orbite s'il passe entre la Terre et le soleil par moment ?

Il ne passe pas entre la Terre et le Soleil.

Il est mis sur une orbite héliosynchrone, "dans le sillage de la Terre" si je puis dire.
Le terme officiel est: "an Earth-trailing heliocentric orbit with a period of 371 days"
Il va orbiter autour du soleil sur une orbite similaire à celle de la Terre, mais un poil plus lentement. Il va dériver lentement en direction du point de Lagrange L5 (sans toutefois l'atteindre durant sa vie opérationnelle) et au bout de 4 ans il sera à 0,5 UA de la Terre.

Cette orbite permet de le garder pointé vers la région du Cygne et de la Lyre sans qu'il ne subisse de contraintes le déviant de sa visée (ou presque), la force perturbatrice la plus puissante qu'il subira sera le vent solaire...
Il va juste devoir tourner 4 fois l'an autour de son axe optique pour garder ses panneaux solaires en direction du soleil.
Autre avantage (et non des moindres), il sera toujours visible depuis les stations de poursuite du DSN.

Premières images de Kepler :
Allez, au boulot !



http://kepler.nasa.gov/about/news.html

http://kepler.nasa.gov/about/1stlight/index.html

J'ai trouvé cette petite application en ligne pour jouer au chasseur d'exo-terres !
C'est très bien fait : http://kepler.nasa.gov/ed/xo/

La chasse aux planètes similaires a la Terre commence enfin rééllement!! :bounce:
http://www.nasa.gov/mission_pages/kepler/news/kepler-200905013.html
Les scientifiques et ingénieurs ont passé les deux derniers mois à vérifier et calibrer le vaisseau spatial. Des données ont été collectées pour caractériser l'interprétation d'imagerie tout comme le niveau de bruit dans les mesures électroniques. Les scientifiques ont établi la liste des cibles pour le début de la recherche de planètes, et ces informations ont été chargées sur le vaisseau spatial...C'est parti!

Merci pour cette très belle photo fredb :bounce: :bounce:

J'ai vraiment hate d'en savoir plus !

Les premières données de travail devraient arriver le 18 juin :
http://www.aviationweek.com/aw/generic/story_channel.jsp?channel=space&id=news/KEPLER060909.xml

Découverte d'une géante gazeuse :

http://www.nasa.gov/mission_pages/kepler/news/kepler-discovery.html ;)