La redondance de processeur ca fait des années que c'est utilisé... c'est pas une rupture techno

l'utilisation de processeur "grand public" datant pas de 20 ans, c'est pas trop la norme ds le spatial. on est dans une approche un peu differente qd meme.

Je n'ai pas parlé de logiciel propriétaire. RTEMS est censé être open source et est utilisé sur plusieurs projets ESA depuis un paquet d'années.  
Et même en propriétaire il y a du cher et du moins cher tout en ayant un bon historique.

https://i.imgur.com/nhIINiH.gif

Le vrai problème de Linux s’est l’ordonnanceur dans le cas de contraintes temps réels (temps fixe de cycle pour s’exécuter pas forcément court ou long mais qui doit être fixe et fixé dès le début), la oui il faut prendre des marges et limiter les tâches annexes pour rentrer dans les clous (un driver de mémoire flash en réalisant un Check de la mémoire toutes les 50 secondes nous plantait notre application par exemple en dépassant le cycle autorisé.

En terme de lanceur fiable, ils ne seront pas loin d'Ariane dans quelques temps du coup ...

Putain, mais ces images animées à la va vite, ca me donne envie de vomir...

 
A la va vite ?
Ca a l'air compliqué à faire plutôt non ?

En terme de lanceur fiable, ils ne seront pas loin d'Ariane dans quelques temps du coup ...

Dans le ferroviaire on utilise aussi régulièrement du Linux et des OS temps réels du marché.
Linux a un énorme intérêt pour sa stack de communication ethernet complète et gérable, sans gros bug connus, les autres OS temps réels concurrents sont assez folkloriques dans pas mal de cas.
L’époque des systèmes mono processeur non ou pas communicant n’est plus la norme.
Ensuite le support possible pour une industrie qui commande peu de license est ridicule, en gros sortie de l’automobile on ne les intéresse pas ou peu.
Il y a plein de trous dans leurs certifications utilisation, les outils autour sont dans une grande majorité moins maintenu/performant que ceux d’un Linux dédié.
Le vrai problème de Linux s’est l’ordonnanceur dans le cas de contraintes temps réels (temps fixe de cycle pour s’exécuter pas forcément court ou long mais qui doit être fixe et fixé dès le début), la oui il faut prendre des marges et limiter les tâches annexes pour rentrer dans les clous (un driver de mémoire flash en réalisant un Check de la mémoire toutes les 50 secondes nous plantait notre application par exemple en dépassant le cycle autorisé.

 
Bien tout dépend comment on considère la mission "zuma" ?

06/03/2018
 
FALCON 9 V1.2
 
05:33 à 07:33 TU

On peut m'éclairer sur les différentes façon d'écrire l'heure ? Et ça donne quoi en heure d'Europe de l'ouest ?

Le site SpaceX au Texas serait déjà bien avancé et ils prévoient les premiers lancements fin 2018.
 
http://cdn.teslarati.com/wp-conten [...] 24x570.jpg
 
Toutes les équipes qui ont travaillé sur le pad au cap Canaveral sont au Texas.
Ils ne perdent pas de temps.
 
SpaceX annonce 30 lancements pour 2018 (contre 18 il me semble en 2017).
 

 
Ils l'ont envoyée dans la bonne direction

Merci pour l'info concernant l'Ethernet sur Linux.
Même si encore une fois l'Ethernet de base ce n'est pas trop utilisé dans le spatial, et il y a d'autres protocoles éprouvés à faible latence.
Pour le reste, tu résumes l'article, sans relever mon évocation de RTEMS (le M veut dire multiprocesseurs).
Et je ne vois toujours pas pourquoi certifier un Linux serait plus facile qu'un OS temps réel.

C'est du plotagraph
Un coup dans l'application, 2/3 trucs a modifier, et tu crée ce genre de choses en moins de 5 minutes, temps de démarrer ton téléphone compris.

Tu as une source pour le site au Texas ? Je trouve qu'ils communiquent très peu dessus.

TU : temps universel (ou UTC en anglais)
c'est = l'heure de greenwich (ou GMT), donc pour avoir l'heure francaise, tu rajoutes 1h en hiver et 2h en été
Celle la, est donc pas très compliqué. Mais souvent pour les lancements, ils vont utiliser des heures locales américaines correspondant aux sites de lancement, et la c'est plus le bordel    
Par exemple, en floride, c'est l'heure "EST" (eastern time), qui est "UTC-5", donc tu lui rajoute 6h en ce moment pour avoir l'heure francaise (metropole of course).
Si t'as un doute, google peut t'afficher l'heure d'un lieu directement, tu tapes juste heure à ... et t'as pas besoin de te prendre le choux. Ou plus spécifiquement pour les lancement, on est pas mal a utiliser une app android comme "space launch now", qui te previens avant l'heure ^^.

Bonjour
 
Z'en pensez quoi? It's a joke?  
 
https://motherboard.vice.com/fr/art [...] ns-lespace
 
"Les lancer à l’aide d’une centrifugeuse de type SpinLaunch pourrait revenir à les lancer contre un mur de béton. " ^^

Bonjour
 
Z'en pensez quoi? It's a joke?  
 
https://motherboard.vice.com/fr/art [...] ns-lespace
 
"Les lancer à l’aide d’une centrifugeuse de type SpinLaunch pourrait revenir à les lancer contre un mur de béton. " ^^

Pour lancer des gens ça serait marrant.    

Pour lancer des gens ça serait marrant.

RTEMS on l'a évaluer, mais il réponds pas aux besoins (CPU utilisé présent et futur, outil utilisé, etc ....) non plus et pas certifiable simplement pour le ferroviaire (typiquement le multi core en temps réel critique est en fait quasiment incertifiable dans le ferroviaire actuellement, même si des fournisseurs privés d'os temps réel déclare le contraire, en fouillant en fait ça revient souvent à désactiver les cores pour avoir des performances, sinon on rajoute tellement de couche d'isolation entre chaque core que les perfs sont ridicules, et reste toujours le problème d'accès critique à la mémoire)
Le linux utilisé, il a passé tous les tests, on a les sources, on a passé tous les outils dessus, on a sortie les failles pour nos utilisations, etc ... . On a la possibilité de trouver des geeks qui savent faire des couches basses robustes.
Un fournisseur d'os temp réel fermé doit faire le taff lui directement, car l'accès aux sources aide à justifier énormément de défauts potentiels comme non réalisable, etc ...
Et encore une fois c'est une question de support aussi, la plupart des fournisseurs on achète pas suffisamment de licence pour les faire vivre, donc on intervient toujours en 5ème roue du carrosse.

RTEMS on l'a évaluer, mais il réponds pas aux besoins (CPU utilisé présent et futur, outil utilisé,  etc ....) non plus et pas certifiable simplement pour le ferroviaire (typiquement le multi core en temps réel critique est en fait quasiment incertifiable dans le ferroviaire actuellement, même si des fournisseurs privés d'os temps réel déclare le contraire, en fouillant en fait ça revient souvent à désactiver les cores pour avoir des performances, sinon on rajoute tellement de couche d'isolation entre chaque core que les perfs sont ridicules, et reste toujours le problème d'accès critique à la mémoire)
Le linux utilisé, il a passé tous les tests, on a les sources, on a passé tous les outils dessus, on a sortie les failles pour nos utilisations, etc ... . On a la possibilité de trouver des geeks qui savent faire des couches basses robustes.
Un fournisseur d'os temp réel fermé doit faire le taff lui directement, car l'accès aux sources aide à justifier énormément de défauts potentiels comme non réalisable, etc ...
Et encore une fois c'est une question de support aussi, la plupart des fournisseurs on achète pas suffisamment de licence pour les faire vivre, donc on intervient toujours en 5ème roue du carrosse.

~6100kg