Journal Vive GNU/linux & Airbus A380

Posté par  .
Étiquettes : aucune
1
13
juin
2005
Ce dimanche 12 juin au cours d'une émission sur l'Airbus A380 diffusé par France2.
Lors de la diffusion de la séquence de préparation du premier vol, j'ai pu voir rapidement un écran avec le logo de la REDHAT. Il semblerait que les ordinateurs d'enregistrement des paramètres des vols d'essais soient sous GNU/linux.
Si quelqu'un a plus d'information ou bien l'enregistrement de l'émission. Il serait bien de mettre sur le site la séquence en question. Question de montrer que linux peut être aussi utilisé dans des environnements critiques.

  • # Dans le même esprit....

    Posté par  (site web personnel) . Évalué à 3.

    Et cela ne date pas d'hier :
    http://www.debian.org/News/1997/shuttle1(...)

    • [^] # Re: Dans le même esprit....

      Posté par  . Évalué à 3.

      Il est clair que je ne m'enverrais pas en l'air (voyez ça comme vous voulez) avec un Windows ME. Même en restant les pieds sur terre, j'aurais peur que le ciel me tombe sur la tête.

      • [^] # Re: Dans le même esprit....

        Posté par  (site web personnel) . Évalué à 4.

        Faut faire gaffe quand même : Windows perce de plus en plus dans l'embarqué automobile!

        • [^] # Re: Dans le même esprit....

          Posté par  (site web personnel) . Évalué à 4.

          oui !
          mais winCE est très différent de winME ;-)) (même si une seule lettre change)

          • [^] # Re: Dans le même esprit....

            Posté par  (site web personnel) . Évalué à 3.

            autant qu'entre XP et 2000 ?

            "La première sécurité est la liberté"

            • [^] # Re: Dans le même esprit....

              Posté par  . Évalué à 10.

              Ba non, entre XP et 2000, il y a plus d'une lettre qui change !

              • [^] # Re: Dans le même esprit....

                Posté par  . Évalué à 3.

                Ben, non !
                Il n'y a bien qu'un digit d'écart, car l'un s'appelle en vrai Windows NT 5.0, et l'autre est bel et bien Windows NT 5.1.

                C'est d'ailleurs rigolo quand on les appelle comme ca, et que le windozien de base rétorque "mais non, tu vois bien que c'est XP", et qu'un petit coup de demarrer->paramètres->système lui cloue le bec.

        • [^] # Re: Dans le même esprit....

          Posté par  . Évalué à 5.

          Je crois (quelqu'un peut confirmer) qu'actuellement windows n'est pas utilisé pour les taches critiques. Juste la partie interface avec l'utilisateur (GPS, indication de la route,...)

          enfin, j'espère....

        • [^] # Re: Dans le même esprit....

          Posté par  (Mastodon) . Évalué à 2.

          il me semble qu'il y'a plus de QNX que de Windows dans l'embarqué auto...

          • [^] # Re: Dans le même esprit....

            Posté par  . Évalué à 6.

            Il me semble que VxWorks a l'air pas mal represente.

            En sport automobile par contre, ca l'air d'etre plus du fait-maison pour ce que j'en ai vu (Williams, BMW, McLaren Electronics, PI research)

            • [^] # Re: Dans le même esprit....

              Posté par  . Évalué à 9.

              En fait cela dépend enormement des choix technologique fait, par exemple les calculateurs d'injection d'abs et autre sont souvent comparables a des automates industriel dans leurs méthode de programmation donc nul besoin d'un OS. Les systémes commes VxWorks ou QNX viennent après pour d'autre fonction comme la télécommunication ou la coordinations de plusieurs organes indépendant ou des opérations temps réel complexe ( c'est une question de hiérarchie, la sécurité cablée prévot sur l'automatisé, qui prévot sur la programmée ), donc sur une voiture ils vont par exemple permettre de centralisé la commande et l'affichage de l'autoradio, du GPS, la consomation instantané ou autre, mais il y a excessivement peut de chance pour qu'il ait une influence sur l'injection, le freinage, le correcteur de trajectoire les airbags ou autre.

              La différence entre un automate et un programme n'est peut étre pas très claire pour un informaticien, mais en gros un automate fonctionne et est programmer celon des méthodes très frustre qui font qu'on peut évalué son bon fonctionnement dans toutes les citations ( ce que l'on peut très difficilement faire avec un programme ).

              • [^] # Re: Dans le même esprit....

                Posté par  . Évalué à 4.

                Felicitations, rien a redire 19/20 (juste, par principe, on ne met pas 20/20) ;o)

                Le fait est que l'industrie auto, je n'ai pas vu l'aspect grand public. Pour avoir travaille chez l'un des 4 que j'ai cites, je peux dire qu'on n'hesite pas a avoir un boitier unique pour toute la gestion du chassis (plus un a part pour le moteur), aussi bien la repartition de freinage que la boite de vitesses , l'embrayage, l'accelerateur, le controle de motricite, la suspension active, le volant, plus la batterie de capteurs et les transmissions (pile IP incluse). Le tout avec un systeme fonctionnant entierement par interruptions.

                Il faut avoir confiance, mais aussi etonnant que ca puisse parraitre, ca marche, et je n'ai jamais eu echo d'un probleme logiciel en piste (a part a cause d'une patte d'un composant cassee a force de vibrations).

                Bon, a l'arrivee, ce sont de toute facon deux domaines qui n'ont pas grand chose en commun

                Note : Maintenant je fais dans la telephonie mobile, c'est moins rigolo...

                • [^] # Re: Dans le même esprit....

                  Posté par  . Évalué à 2.

                  Tu veux dire que les régulateurs fous et les problèmes de débit de multiplexage, ca n'existe pas ?

                  Merde alors encore une illusion qui s'envole :)

                • [^] # Re: Dans le même esprit....

                  Posté par  (site web personnel) . Évalué à 5.

                  Pour info, vous alliez jusqu'ou sur les preuves de bon fonctionnement ?

                  Genre, est-ce que vous faisiez des études pires cas (analyse de timing à 125°C) pour prouver que cela marche tout le temps ? Ou des études de fiabilité si tel ou tel composant lache, savoir ce qui se passe.

                  Les problèmes de régulateurs ressemblent beaucoup à des problèmes hardwares non pris en compte par le soft.

                  "La première sécurité est la liberté"

                  • [^] # Re: Dans le même esprit....

                    Posté par  . Évalué à 5.

                    Plusieurs choses.

                    Pour le cote hardware, on utilisait des boites speciales (shake & bake).
                    -Une tres violente sur les cartes avant meme le premier boot, pour de tres fortes variations de temperatures, de -30 a +90 (degres C) et tres rapides, 10 degres/minutes il me semble. Vive l'azole liquide.
                    -Une differente avec boitier en fonctionnement qui logge toutes les donnees sur tous les capteurs, avec des vibrations et accelerations. Ca prend 10g, 4g a des grosses frequences genre 100, 1000Hz, et ca tourne toujours sans broncher. On commence a avoir des problemes avec une temperature interne de 90 degres (les alims coupent un 10eme de seconde pour refroidir). Par contre on m'avait fait modifier la valeur de temperature mini avant erreur, ca tenait bien a -10. (l'erreur etant la pour signifier que le capteur de temperature est mort). A noter que les boitiers fonctionnent toujours avec un choc de 28g (dans la voiture)...
                    Bien sur, tous les composants etaient aux spec militaires.
                    J'ai vu la deuxieme servir a tester la resistance des volants et cages d'embrayage aux vibrations.

                    Niveau soft, c'est a l'ancienne, en C + asm pour les parties critiques, pas d'outil de verification formelle. Par contre le code est entierement valide avec lint histoire d'eliminer un certain nombre de risques de betises, et teste pendant tres longtemps avec un certain nombre d'outils specifiques, dont simulateurs. De memoire, il y a eu 6 mois entre les premiers essais sur banc et la premiere apparition sur piste. Ca parrait un peu surrealiste aujourd'hui, mais si les gens travaillent proprement et savent ce qu'ils font, ca se passe tres bien. Garder un design simple aide beaucoup a gerer.

                    A noter quand meme :
                    -Malgres les changements d'architecture, le code n'a jamais ete repris from scratch depuis des annees mais a evolue, ce qui explique que ce soit gere par interruptions.
                    -Il y a une nette separation bas et haut niveau. Le haut niveau (gestion boite, traction control, supension active) tend a etre arch-independant
                    -2 personnes seulement pour gerer toute la partie bas-niveau. On s'entendait bien et on se comprenait techniquement, ca aide beaucoup.
                    -La partie haut niveau, je n'y avais pas acces (j'etais en CDD), mais j'ai cru comprendre que c'etait en partie genere par Matlab.
                    -Quand un plantage veut dire "potentiellement je risque d'envoyer un mec a 360 km/h dans un mur en direct a la tele", tu vais attention :)

                    Pour situer, ca se passait il y a un an et demi, et vu que les personnes n'ont pas change depuis, je pense que les methodes sont les memes.

                    Bon, maintenant arretez de me faire en parler, ca remue le couteau dans la plaie, j'ai envie d'y retourner :P

                    • [^] # Re: Dans le même esprit....

                      Posté par  (site web personnel) . Évalué à 3.

                      A ouais... je comprends mieux le coup des régulateurs de vitesses...

                      Vous faites des testes sur 3 cartes de teste et vous "prouvé" que cela marche sur tous les composants :(

                      Dans le spatial, on fait une étude dis "pire cas". En gros, on prends tous les timing de tous les composants, on extrait le pire cas (dans les spec fournis par le service composant) et on démontre que cela marche dans tous les cas. Si cela n'est pas le cas (genre timing -55°c d'un coté et +125 de l'autre), on justifie que c'est un cas qui n'existe pas.

                      Pour vérifier, on fait aussi des testes de choc, de vibration et en étuve.

                      "La première sécurité est la liberté"

                      • [^] # Re: Dans le même esprit....

                        Posté par  . Évalué à 2.

                        A ouais... je comprends mieux le coup des régulateurs de vitesses...

                        Je le refais au cas ou ce n'etait pas deja evident. Ce n'etait pas pour des vehicules de serie mais des chassis de Formule 1. Et je peux t'assurer que ce ne sont pas les memes electroniques vu le prix.

                        Vous faites des testes sur 3 cartes de teste et vous "prouvé" que cela marche sur tous les composants :(

                        Pas du tout. On produit 36 boitiers, on passe les 36 cartes et boitiers aux tests de contraintes et validation avant de les mettre sur la piste. Et on le repasse tous les x km. Et au bout d'un certain kilometrage, il n'est plus utilise qu'a l'usine pour les tests ou il ne subira pas les contraintes de vibration et de chaleur (banc d'essais, simulateurs, etc...).

                        Quand au niveau des timings des composants, il en est evidement tenu compte dans la programmation au niveau soft.

                        Je l'ai deja ecrit, je n'ai aucune connaissance interne de l'electronique d'une voiture de serie ; donc ne tire aucune conclusion sur les problemes de regulateur de vitesse a partir de ce que j'ecris.

                        • [^] # Re: Dans le même esprit....

                          Posté par  (site web personnel) . Évalué à 3.

                          Je parle de timing de signal électrique, rien qui ne peut être vu au niveau soft.

                          C'est toujours mieux de tester toutes les boites mais cela ne te donne pas de garantie.

                          M'enfin, en spatial, on doit tenir compte du vieissement des composants. J'imagine qu'une telle boite n'a pas le temps de vieillir :)

                          "La première sécurité est la liberté"

                          • [^] # Re: Dans le même esprit....

                            Posté par  . Évalué à 2.

                            Ca reste une voiture, avant que le temps de propagation du signale influe sur le comportement du systéme ils vont devoir en rajouter du métrage de cable, ou salement augmenter la vitesse de la voiture. Les échelles de temps entre un systéme destiné a une fusé, une F1, une voiture de série et un systéme pneumatique sont pas les mêmes. Les risques humains aussi.

                            • [^] # Re: Dans le même esprit....

                              Posté par  (site web personnel) . Évalué à 2.

                              Ca reste une voiture, avant que le temps de propagation du signale influe sur le comportement du systéme ils vont devoir en rajouter du métrage de cable, ou salement augmenter la vitesse de la voiture.

                              oualalal. Maman j'ai peur... je veux pas monter dans les voitures du monsieur.

                              Y'a rien de plus chiant que de vérifier les temps de setup et de hold d'io de 2 puces mais crois moi, si un des composants à un arbre d'horloge rapide et l'autre à un arbre lent, tu va au devant de très gros emmerde. Genre un cpu avec un fpga type actel... au hasard :)

                              Les échelles de temps entre un systéme destiné a une fusé, une F1, une voiture de série et un systéme pneumatique sont pas les mêmes. Les risques humains aussi.

                              Les systèmes spatiaux européens ne mettent pas encore la vie humaine en jeu.

                              "La première sécurité est la liberté"

                              • [^] # Re: Dans le même esprit....

                                Posté par  . Évalué à 2.

                                oualalal. Maman j'ai peur... je veux pas monter dans les voitures du monsieur.

                                Ne t'en fais pas, a priori c'est pas pour demain. Et si ca devait t'arriver, on n'a jamais vu l'electronique poser probleme. Par contre, les pneus, les freins, l'embrayage, la boite, le moteur, les supensions ca s'est vu. Et quand ton saut perilleux arriere se termine, la telemetrie affiche que tu as pris 28g.

                                Y'a rien de plus chiant que de vérifier les temps de setup et de hold d'io de 2 puces mais crois moi, si un des composants à un arbre d'horloge rapide et l'autre à un arbre lent, tu va au devant de très gros emmerde. Genre un cpu avec un fpga type actel... au hasard :)

                                Comme l'a dit le monsieur au-dessus, on n'a pas les memes contraintes. On travaillait sur des plages de temperatures qui sont relativement limitees, les problemes que tu as ne s'appliquaient pas dans notre cas.

                                Les systèmes spatiaux européens ne mettent pas encore la vie humaine en jeu.

                                Ceux qui equipent les Formule 1 oui, en direct a la tele.

                                C'est bizarre, je m'attendais plutot a voir des gens reagir sur la methode de developpement logicielle plutot anachronique, pas sur l'eletronique en elle-meme...

                                • [^] # Re: Dans le même esprit....

                                  Posté par  . Évalué à 3.

                                  Et quand ton saut perilleux arriere se termine, la telemetrie affiche que tu as pris 28g.

                                  T'as pris 28 G mais t'as perdu 21 g[rammes], alors la télémétrie, t'es plus là pour la contempler...

                                  Bouh, j'suis morbide à c't'heure-là, moi. Vais me recoucher -->[]

                  • [^] # Re: Dans le même esprit....

                    Posté par  . Évalué à 2.

                    Baaaaaa....

                    Parti dans mon trip, je me rends compte que je n'ai pas vraiment repondu a ta question.

                    Pour tout ce qui est critique (commandes volant, infos de capteurs de pedale d'accelerateur surtout), tout est double par securite. Deux capteurs, chacun sur deux bus de communication vers le boitier de controle, pour lequel des decisions sont prises en cas de valeurs differentes suivant les effets que ca va avoir.

                    La pedale de freins n'en a pas besoin, vu que c'est un "bete" systeme hydraulique. La seule intervention que peut avoir l'eletronique, c'est modifier la repartition avant/arriere, donc a part pour telemetrie/controle, ce n'est pas bien grave de ne pas avoir la valeur.

                    Sinon en interne, ben si un controlleur CAN claque, on espere que le 2eme va tenir, si un CPU crame, on ne peut pas y faire grand chose (quoi que...).

                  • [^] # Re: Dans le même esprit....

                    Posté par  . Évalué à 3.

                    Pour l'automobile je ne sais pas exactement par contre dans le domaine que je connais les automates industriels les tests sont très poussé et très étonnants.
                    Déjà la plus part des opérations sont faite en double, voir plus, il intégre des systémes de WatchDog et d'autocontroles très performants qui permettent de déclencher la sécurité cablé en cas de défaillance de l'automate. Apres les automates en questions peuvent fonctionner pendant d'une demis a une seconde sans alimentation, peuvent supporter des variations de tension assez extrémes genre 400V au lieu de 230V ( au pire on grille l'alim mais pas l'automate ) et n'ont donc pas besoin d'onduleur. Ils sont aussi protégés contre les flash UV ( cas d'un court circuit et d'un arc électrique dans l'armoire électrique ) et certains même contre les rayonnements en tous genre ( pour les applications nucléaires ). Je vous épargne les écarts thermique, l'absence de pièce mobile et la résistance aux vibrations.

                    C'est d'ailleur pour toutes ces raisons qu'un automate motorisé par un processeur a 16Mhz peut avoir un prix exorbitant.

                    Apres ce qui fait la différence entre un programme automate et un programme évolué, c'est la quasi intégralité du programme automate est réalisé en langage contacte ( ou Ladder ), le graphcet n'étant souvent d'une forme de surcouche ou de macro. Les informaticiens vont s'arracher les cheuveux apprenant cela, le programmateurs de microcontroleurs connaissent surement déjà mais le langage contacte est presque uniquement constitué de combinaison de bit et d'opération logique de base, modélisé de manière a facilité l'apprenticage par des non programmeurs sous la forme de contacte électrique et de fil qui allume une lampe correspondant a une sortie ou un bit.
                    De la bonne vieille logique booléenne, ou l'on travail bit par bit, ou sur des mots assez court pour faire du comptage. De plus ce mode de programmation est remarquablement adaptés aux systémes temps réel.

                    On a donc un nombre d'entrée finie et un nombre de sortie finie ( qui dépasse rarement la centaine correspondant généralement aux éntrée et sortie de l'automate ). Il est donc tous a fait possible de tester le programme dans un très grand nombre de configuration. De plus avec un tel mode de programmation une erreur passe rarement inaperçue ( c'est du tous ou rien, et les fonctions a testés ne sont pas innombrable ), et ce que l'on demande avant tous c'est que le systéme ce comporte bien en cas d'erreur ( gestion de la sécurité ).

                    On a donc un systéme robuste qui effectue des taches simple, mais qui les effectues biens et qui sait gérer les situations de défaillance, alors qu'un programme classique plus complexe ne sera pas en mesure d'apporter autant de sécurité.

            • [^] # Re: Dans le même esprit....

              Posté par  . Évalué à 3.

              En sport automobile par contre, ca l'air d'etre plus du fait-maison pour ce que j'en ai vu


              Les écuries F1 Prost Grand Prix utilisaient Mandrake Linux, mais bon, vu qu'elles ont coulé, ce n'est pas forcément une référence... :-)

              • [^] # Re: Dans le même esprit....

                Posté par  . Évalué à 3.

                Pour les curieux, en F1, il n'y a que 3 fournisseurs d'equipement electronique embarque :
                -Magnetti Marelli, propriete du groupe Fiat
                -McLaren Electronics (ex TAG Eletronics), faisant partie du groupe McLaren
                -PI research, recement vendu par Ford avec Cosworth

                Avec ca, on couvre 90% du plateau.

                Pour le reste, c'est Williams et BMW les deux seuls a faire l'eletronique hard/soft eux-meme. (homis pour les trucs generiques du type capteurs divers et varies)

                A l'epoque, Prost utilisait du TAG.

        • [^] # Re: Dans le même esprit....

          Posté par  (site web personnel) . Évalué à 1.

          Dans les VelSatis et autres Renault, par exemple ?

  • # Mieux que ça ;)

    Posté par  . Évalué à 9.

    En fait c'est la Sagem qui a décroché le pompom pour faire le système d'information. Tout le système d'info repose sur du linux (pare-feu, etc...), la diffusion des films, les paramètres de vol etc ... l'A380 carbure au libre (réduction des coûts quand tu nous tiens :). A l'époque ils hésitaient entre Suse et RH (problèmes de crypto des bus de donnés, avec les soucis des exports des EU), mais je vois qu'ils ont fini par choisir RH :).

    L'équipe était du côté de Massy Palaiseau si mes souvenirs sont bons.

    Bon, si d'autres infos me reviennent, j'en dirais plus :)


    Caeies, candidat "malheureux" à la Sagem pour ce boulot ...

    • [^] # Re: Mieux que ça ;)

      Posté par  (site web personnel) . Évalué à 3.

      En fait c'est la Sagem qui a décroché le pompom pour faire le système d'information.
      Pompom (Girl)=hotesses de l'air ?

      la diffusion des films
      Ca risque d'etre limité, si on peut plus lire de DVD sur Linux, sans parler des brevets/formats de fichiers fermés...

      Tout le système d'info repose sur du linux (pare-feu, etc...),
      De quel type de pare-feu s'agit-il ? Ou plutot, quel type de media doit-on filtrer ?

    • [^] # Je ne veux pas être rabat-joie mais...

      Posté par  (site web personnel) . Évalué à 2.

      Désolé de jeter une ombre sur ce beau tableau, mais d'après ce que j'ai entendu dire sur l'A380, il y a peu de Linux...

      Il me semble que les calculateurs de bord, c'est plutôt de l'assembleur que du Linux (pas très sûr)

      Par contre, ce que je sais, c'est que l'ordinateur situé sur le coté du de chacun des deux pilotes et qui sert à consulter les manuels de vol, à suivre la maintenance et autres choses moins critiques, c'est du Windows 2000. A coté du pilote.

      Je rappelle pour finir que Airbus s'est prononcé largement en faveur de Microsoft dans la saga qui l'opposait à l'UE ( http://linuxfr.org/~plic/15336.html(...) )

      Par contre, pour rester dans le même domaine, dans le contrôle aérien, c'est bien plus réjouissant! (http://www.barco.com/airtrafficcontrol/en/Pressreleases/show.asp?in(...) par exemple )

      • [^] # Re: Je ne veux pas être rabat-joie mais...

        Posté par  (site web personnel) . Évalué à 2.

        Je rappelle pour finir que Airbus s'est prononcé largement en faveur de Microsoft dans la saga qui l'opposait à l'UE

        Ils ont peur que les prochains avions utilisent Windows Reduce Edition ? ;)

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Je ne veux pas être rabat-joie mais...

        Posté par  . Évalué à 1.

        Assembleur ? moi je ne dirais pas comme toi mais bon.

        Le peu de chose que je sais sur " l'avionique", c' est que le maitre mot est la redondance: plusieurs systémes qui vérifie/corrige/interpréte toutes les données/ordres et on compare les résultats.
        Pour limiter les risques (encore), les différents systémes doivent êtres différents niveaux OS, hardware, langage de programmation.
        Tout ceci est testé et retesté, et les différences entre les systémes permettent de penser qui si l' un bugge/plante les autres étant trés différents n' auront pas la même erreur au même moment.

        l' assembleur ? franchement j' ai des doutes...... Si quelqu' un peut confirmer :-)

        • [^] # Re: Je ne veux pas être rabat-joie mais...

          Posté par  (site web personnel) . Évalué à 2.

          Autant pour moi, c'est du C temps réel généré automatiquement par des outils qui "prouvent le code"

          Un truc qu'ils appellent la technologie SCADE :
          http://www.esterel-technologies.com/technology/first-flight/first-f(...)
          http://www.tttech.com/dasc.htm#model(...)

          Je n'y connais rien en temps réel, mais vu les degrés de fiabilité demandés, je ne verrais pas l'intéret de mettre Linux dessous sachant que Linux n'est pas "prouvé".

          • [^] # Re: Je ne veux pas être rabat-joie mais...

            Posté par  (site web personnel) . Évalué à 2.

            <publireportage>
            Effectivement, certaines morceaux du code emarqué critique dans l'avionique, nottamment sur l'A380, sont faits avec SCADE. C'est une techno formelle et synchrone basée sur lustre ( http://www-verimag.imag.fr/SYNCHRONE/index.php?page=lang-design(...) ). Ca n'entre pas dans les questions d'interruptions, de tâches, etc qui sont gérées par un éventuel OS (certifié ou non, type greenhills http://www.ghs.com/(...) , lynuxworks http://www.lynuxworks.com/,(...) windriver VxWorks et j'en passe). Ca permet de faire des lois de commandes et des algos sûrs, sur lesquels ont peut faire assez "facilement" de la preuve formelle, de la couverture de modèle, etc. On est un niveau d'abstraction au dessus du C. Derrière on peut générer du C ou de l'ADA, tout en concervant une excellente tracabilité (absolument nécessaire pour la certification DO-178B). J'arrête de m'étendre, pour plus d'infos aller voir là

            http://www.esterel-technologies.com/products/scade-suite/overview.h(...)

            </publireportage>

            Concernant TTech, c'est assez complémentaire avec SCADE, c'est un générateur de scheduling statique: on donne les temps d'execs maximums, les priorités et périodicités, et ça pond un code qui appelle les différentes taches dans le on ordre.

            Note: je suis le webmaster du site en question, je le passe doucement aux standards, si vous avez des remarques, n'hésitez pas ( webmaster at esterel dash technologies dot com )

            • [^] # Re: Je ne veux pas être rabat-joie mais...

              Posté par  . Évalué à 2.

              En lisant les caractéristiques du code que ca produit on comprend que c'est vraiment hyper spécialisé :

              Safe control structures

              * Mostly linear control sequences.
              * No loops, no recursion, no jumps.
              * Therefore, predictable execution time.

              Safe data structures

              * No dynamic variables.
              * Fully static memory allocation.
              * Integrity of data can thereby be ensured.


              ... bref c'est pas demain la veille qu'on pourra coder un OS généraliste avec ce genre d'outils

              • [^] # Re: Je ne veux pas être rabat-joie mais...

                Posté par  (site web personnel) . Évalué à 1.

                C'est clair que ce n'est pas fait pour ! C'est fait pour écrire le code de tout ce qui craint un max, genre les commandes de vol d'un avion de ligne, un asservissement sur un bras déplaçant du combustible nucléaire, les aiguillages sur les ligne à très grande vitesse, etc. Genre si tu fais un malloc et que le système te renvoie "y'a plus de mémoire" tu tapes minimum dans la centaine de morts. Donc pas de malloc. Pas de boucle dont tu ne peux apporter la preuve qu'elle ne finit pas, pareil pour la récursion. Les variables sont produites une et une seul fois par cycle. Garantis moi dans un programme C qu'il n'y a pas un autre endroit dans le code qui vient écraser une variable ?
                Si tu n'as pas le droit à l'erreur, tu dois bannir tout ce qui est dynamique. Le code répond à ce qui est à mon avis les normes de programmations les plus sévères au monde, la DO-178B, jusqu'à son niveau A, le maximum. N'imagine même pas coder un driver, un OS ou une application avec ça. Par contre un ABS, un contrôle moteur d'avion, un airbag, tout le X-by-wire, des ihm type tableaux de bord, infotainment, systèmes de chauffage/clim/éclairage, des pilotes automatiques, des guidages de missiles, des Cruise Control, j'en passe et des meilleurs, bref, tout ce qui DOIT marcher, vas-y, c'est fait pour. En plus, en tant que développeur, c'est très agréable à utiliser.

      • [^] # Re: Je ne veux pas être rabat-joie mais...

        Posté par  . Évalué à 1.

        D'après mes sources, il y aurait effectivement du Linux embarqué chez Airbus. Ce que je peux vous garantir, c'est que ça a au moins été testé. Je ne sais pas par contre si c'est beaucoup utilisé sur l'A380, ni même si c'est utilisé tout court (je suis pas chez Airbus !).

        Pour l'assembleur, ça m'étonne, il me semble qu'on utiliserait plutôt de l'ADA pour faire des tonnes de validations après. Enfin... c'est que mes souvenirs de cours d'avionique.

  • # Je le savais....

    Posté par  (site web personnel) . Évalué à 7.

    Je l'ai vu moi aussi.
    En fait on vois très rapidement un fond d'écran bleu pâle et le monsieur au chapeau. Typique de l'écran de login RedHat.
    On le vois à peine un quart de secondes sur la droite de l'écran mais je savais qu'il y aurait bien une moule pour nous poster ca en journal :D

  • # Youhou ???

    Posté par  . Évalué à -2.

    Il est où pasBillpasGate ? Chez Akerone ?

  • # Bong sang ...

    Posté par  . Évalué à 2.

    pourquoi n'utilisent ils pas Labview sous Windows Me? Ils n'y pas de souris dans l'Airbus A380?

    • [^] # Re: Bong sang ...

      Posté par  . Évalué à 2.

      Ils n'y pas de souris dans l'Airbus A380?
      Y'a un trackball à côté de la manette des gaz.

      Et je vous assure qu'il n'y a malheureusement pas un seul pingouin dans les systèmes de pilotage : pour cela il faudrait passer une terrible certification (norme DO178B par exemple) dont le coût est hors de portée des développeurs de logiciels libres ...
      (à vrai dire, il faut même commencer par certifier le compilateur !)

      • [^] # Re: Bong sang ...

        Posté par  . Évalué à 2.

        dont le coût est hors de portée des développeurs de logiciels libres ...

        Ya pas que des developpeurs indépendant bénévoles qui produisent et utilisent du libre... Ceci étant sur les systèmes de pilotage je ne verrais pas bien l'interet.

        (à vrai dire, il faut même commencer par certifier le compilateur !)

        Ben encore heureux... :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.