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...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.Envoyé par Wikipédia
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.
Pour moi, c'est la bonne question.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 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.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...
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 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)
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.
En effet, le contexte change. Mais les problèmes restent les mêmes. L'ordre d'importance change.Robotique et espace, c'est fichtrement pas le même genre de contraintes.
Pour finir :
Mettre un nouveau système exploitation, c'est pas franchement l'opération la plus complexe au monde.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.
Partager