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 imalip . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 5.
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