Voyager et informatique embarquée ?

Bonjour,

je m'intéresse à l'électronique embarquée dans les sondes et en particulier sur Voyager.

Je n'ai pas réussi à obtenir beaucoup d'infos ; je sais qu'il y a à bord un séquenceur qui gère les différents "modules" de la sonde et en particulier les timing de fonctionnement...
Ce séquenceur ressemblerait à un embrayon de microprocesseur.

J'ai cru comprendre qu'il y avait aussi un/des microprocesseurs de type COSMAC 1802, mais je n'ai jamais réussi à en avoir la confirmation. (site JPL)

Quelqu'un peut-il me donner des infos ?

Merci

Effectivement, Voyager avait 3 puces COSMAC 1802 durcies, cadencées à 6.4 MHz. Je vais voir si j'ai d'autres infos...

Merci de votre réponse. Ce qui me semble bizarre, c'est que le 1802 est sorti en 1976 et que la première sonde Voyager fut lancée en septembre 1977.
Ce court laps temps me semble vraiment court pour permettre la mise en œuvre de trois proc. , surtout que cette technologie était trop récente pour utiliser des librairies existantes.
Dans ma mémoire (je n'ai pas eu confirmation depuis), j'ai le vague souvenir que les processeurs se contrôlaient mutuellement et évinçaient celui d'entre eux qui présentait une disparité de résultat trop importante avec les autres.

decifone a écrit:...
Dans ma mémoire (je n'ai pas eu confirmation depuis), j'ai le vague souvenir que les processeurs se contrôlaient mutuellement et évinçaient celui d'entre eux qui présentait une disparité de résultat trop importante avec les autres.

Avec seulement 3 processeurs ? J'en doute. Il est démontré qu'il faut au moins 4 processeurs pour mettre en œuvre ce type de contrôle sans tomber dans le dilemme dit "des généraux byzantins".

Sur les systèmes pilotés, on peut se contenter de 3 chaînes car c'est le pilote qui, au bout du compte, lève l'indétermination mais sur un système complètement automatique, l'auto-contrôle à 3 ne fonctionne pas.

Sinon, Voyager a très certainement utilisé une autre version du COSMAC que celle commercialisée en 1976. En particulier, ces spécifications d'environnement étaient très certainement militaires plutôt que civiles. Les militaires disposent des nouveautés quelques années avant qu'elles soient commercialisées auprès du public.

Autre exemple: les GPCs du STS, conçue à la fin des années 60 étaient basés sur une architecture 32bits que l'on ne retrouvera sur le marché que bien plus tard sur les microprocesseurs (et encore, pas dans la version durcie réservée au marché militaire): http://spaceflight.nasa.gov/shuttle/reference/shutref/orbiter/avionics/dps/gpc.html

Intéressant, mais la nécessité de passer de 3 à 4 procs (ou machines) ne repose que sur le fait qu'un proc (ou calculateur) "corrompu" puisse envoyer des infos "non-publiques" divergentes aux deux autres. Si tous les messages sont "publics" (broadcast sur un réseau ou un bus) on peut revenir à 3 unités. Il reste la possibilité de se faire passer pour un autre, mais ça peut se régler (adresse mac pour un calculateur, ou un fil particulier sur le bus pour chaque proc, comme dans le mécanisme des IRQ).

Henri a écrit:Intéressant, mais la nécessité de passer de 3 à 4 procs (ou machines) ne repose que sur le fait qu'un proc (ou calculateur) "corrompu" puisse envoyer des infos "non-publiques" divergentes aux deux autres. Si tous les messages sont "publics" (broadcast sur un réseau ou un bus) on peut revenir à 3 unités. Il reste la possibilité de se faire passer pour un autre, mais ça peut se régler (adresse mac pour un calculateur, ou un fil particulier sur le bus pour chaque proc, comme dans le mécanisme des IRQ).

Ce cas est discuté à la fin de la démonstration où la topologie du réseau est prise comme paramètre. Il faut tenir compte du fait que le réseau doit être synchrone ("jitter" très petit voire inexistant) car sinon le temps de propagation des informations (ou désinformations...) entre les calculateurs va jouer un rôle et les calculateurs se désynchroniseront, ce qui en temps réel dur est inconcevable (c'est aussi une condition nécessaire du maintien d'un contexte cohérent dans les divers calculateurs car d'autres résultats théoriques démontrent qu'en l'absence d'un média à temps de propagation déterministe, les calculateurs connectés finissent par ne pas avoir tous la même vision du contexte, ce qui interdit la "reprise" en cas de panne). Il faut aussi que le tout soit multiplexé, ce qui ne laisse pas énormément de choix de la technologie d'autant que l'hypothèse, c'est que justement les calculateurs sont tous identiques (et non constitués en deux couches de criticité différente comme c'est le cas par exemple sur l'ATV) et donc ne peuvent jouer un rôle privilégié tous en même temps sur ce réseau (comme dans le cas des architectures imposant un contrôleur de Bus), ce qui d'ailleurs introduirait le risque que tu évoques de "se faire passer pour un autre". A l'époque de Voyager, de telles technologies n'existaient pas (ou alors pas assez "durcies" pour être embarquables) d'autant qu'il fallait aussi supporter jusqu'à 11 instruments.

Les démonstrations théoriques d'architectures multi-scalaires (c'est le cas ici puisque les calculateurs se doivent d'être synchronisés et non différenciés pour permettre le vote) ont fait d'énormes progrès depuis l'époque de Voyager et aujourd'hui, on ne devrait pas théoriquement concevoir une architecture comme celle-ci s'il s'agissait réellement comme l'écrit decifone de mettre en place un mécanisme de vote avec élimination.

Cependant, je suis conscient qu'encore de nos jours, dans la réalité, on s'encombre peu de ces considérations pas toujours faciles à mettre en œuvre en pratique et qu'ensuite, on galère en intégration (et hélas aussi en exploitation) pour comprendre ce qui ne va pas. Mais souvent les problèmes viennent justement de l'utilisation d'une méthode de génie des systèmes inadaptée voire inexistante: combien d'industriels utilisent couramment les démonstrations formelles d'architecture sur leurs projets ?