Discussion :

[kolodz]

Mais pas sur le TR... A moins que tu ais des contraintes de temps qui soient dérisoires et auquel cas on appelle plus cela du temps réel selon moi (mais on est d'accord cela peut très bien être qualifié de système critique) si tu peux faire tourner cela sur un simple noyau linux...

En informatique, un système temps réel est une application ou plus généralement un système pour lequel le respect des contraintes temporelles dans l'exécution des traitements est aussi important que le résultat de ces traitements

Il est nullement question de temps de réponse rapide, mais bien de respect des contraintes de temps imposé. Par exemple, pour mettre à jour l'orientation d'un panneau solaire, la contrainte de temps est 5 minutes. Si une personne prouve que sont système réalise cette mise à jour systématiquement en moins de 5minutes. Alors son système est temps réel.
Voilà pour la théorie.

Pour la pratique:
Les contraintes de temps sont ridiculement dérisoire...
Pour rappel "Apollo Guidance Computer", l'ordinateur qui a permis à l'homme de marcher sur la Lune, avait une fréquence de calcule de 1,024 MHz.(c'est bien une virgule, soit 1MHz) Le Nexus One , c'est un processeur de 1Ghz, mille fois plus rapide.
Sauf erreur de ma part, même en ayant un système d’exploitation "merdique" qui rend ton programme 99% plus lent que ce qu'il devrait. Tu sera toujours 10 fois plus rapide qu'il y a 40 ans.
Voilà pour la pratique.

Mais la question qui est a se poser est selon moi est : "Est-ce que ce genre de satellite à forcément besoin de faire du temps réel?".

Pour moi, c'est la bonne question.

Un noyau linux testé sur une architecture cible montre des temps max de plusieurs centaine de millisecondes tandis qu'un simple noyau linux patché RT descends à 1000x moins (toujours sur la même architecture bien sûr). Si vos contraintes TR sont de la dixième de seconde (et personnelement je trouve cela astronomique !) alors je comprends mieux votre remarque, mais sinon je vois pas...

Pour garantir cela un système temps réel a une gestion des processus différentes. Mais, un Linux classique est capable d'assurer un environnement "temps réel" pour un processus. C'est toujours le cas, pour le processus de plus haute priorité... Vue que ces instructions passent toujours avant les autres processus.

Pour faire une analogie, c'est comme une montre accessible à n'importe qui pour 50€ et les montres hautes gammes de chez Rolex. Dans le fond, la technologie est la même : une montre reste une montre (aux différents brevets prêts.) Ce qui coute derrière, c'est la résistance des produits mais aussi la rareté (qui est une conséquence directe des critères de résistances dont peu d'applications ont besoin)

Je vais reprendre mon exemple des sous-marin nucléaire. Il se trouve que la France dispose aussi d'un sous-marin nucléaire. Pour des raisons, d'indépendance la France a choisit de développer son propre sous-marin nucléaire. Il se trouve que ce sous marin nucléaire coûte 4 fois plus cher à l'unité que la version américaine. Simplement parce que les américaines ont construit 14 sous-marin et répartie le coût de développement.
Pour ce qui est de la résistance en elle-même. Ce n'est pas le problème des composantes électronique... Mais du blindage du satellite.

Robotique et espace, c'est fichtrement pas le même genre de contraintes.

En effet, le contexte change. Mais les problèmes restent les mêmes. L'ordre d'importance change.

Pour finir :

On est tous d'accord qu'un noyau Linux non patché, comme c'est le cas d'Android, n'est pas fait pour faire du temps réel.

Mettre un nouveau système exploitation, c'est pas franchement l'opération la plus complexe au monde.

[transgohan]

Pour garantir cela un système temps réel a une gestion des processus différentes. Mais, un Linux classique est capable d'assurer un environnement "temps réel" pour un processus. C'est toujours le cas, pour le processus de plus haute priorité... Vue que ces instructions passent toujours avant les autres processus.

Tu n'as visiblement pas testé... Même avec la priorité la plus haute, ce processus ne sera pas toujours exécuté en premier si les autres process sont en masse dans la file et ont des cycles de retards (pour le cas d'un scheduler fonctionnant avec une file bien sûr).
Tu verras même que le noyau linux va mettre la plus haute priorité à des process à qui tu as mis une priorité très basse pour justement qu'ils puissent les exécuter pendant un temps. Ton processus prioritaire sera donc autant prioritaire que les autres pendant un temps et perdra totalement ses chances d'être exécuté au moment où il devrait.
Tu pourras lire cela dans n'importe quel livre parlant des ordonnanceurs.

Quand à l'explication TR, la définition est bien large je trouve... Du coup n'importe quelle application ou système est temps réel si elle respecte ce qui est annoncé sur le prospectus ?
Donc si je résume bien, en postant sur ce forum mon message si je ne me prend pas un timeout du serveur c'est que l'application est temps réel...

[kolodz]

...
Quand à l'explication TR, la définition est bien large je trouve... Du coup n'importe quelle application ou système est temps réel si elle respecte ce qui est annoncé sur le prospectus ?

Exactement ! Même si cela semble stupide... C'est pour des questions d'assurances. Et légalement, si ton avion se crache parce que t'as eu un timeout, le type qui t'as vendu le système est responsable.

Cela reste principalement des choix d'ordonnancement. Pour la partie technique, j'avoue ne pas avoir fait de tests personnels. Mais, j'ai toujours le cas du processus seul pour moi

[Freem]

N'empêche... C'est plutôt pas mal, il y aura des cabines téléphoniques spatiales comme ça.
Je me demande quel forfait ils ont pris? Remarquez, je pense qu'ils ont tout compris, alors ça doit être Free

[Napium]

Ils vont avoir du réseau là haut?

[Robxley]

Euh, les astronautes de l'ISS vont être obligés de répondre à leur concubin(e) maintenant.

"Mais chéri(e), je te dis qu'il n'y a pas de téléphone la où je vais...."
"Menteur/menteuse..."



Blagues à part, dans un satellite il n'y a pas nécessairement qu'une seule unité centrale. Souvent, ils sont composés de plusieurs ordinateurs, certains sont temps réels (pour la navigation, taches critiques...) et d'autres beaucoup moins exigeant qui ne nécessitent aucunement du temps réel. Exemple des satellites d'acquisition d'images, la compressions des images n'a surement pas besoin d'être temps réel, et je pense que les opérations de ce type sont souvent séparées des ordinateurs exécutant les taches critiques. Je pense que les smartphones ont plus vocations à remplacer ces derniers que ceux liés à l’exécution de taches plus critiques pour la survie du satellite.

Après je ne suis pas non plus spécialiste dans le domaine, donc je peux me tromper.