Comme tout système électronique, il peut y avoir des bugs et des pannes. Logicielles, ou même matérielles. Donc théoriquement et même pratiquement parlant, une valve peut se bloquer en position ouverte. L'usure, le froid, un bug, un défaut de fabrication. La question n'est pas de savoir si ça peut se produire, mais quels sont les risques et comment l'on s'assure qu'on a tout fait pour que ça n'arrive pas. Dans la logique: validation croisée des valeurs des capteurs, vérification du comportement des sorties (pour répondre à ta question, il y a un sacré paquet de vérifications sur la valeur des capteurs de vitesse des roues et si l'ABS n'autorise aucune admission de pression pendant un temps donné, il est coupé en urgence); dans la méthodologie: revues, traçabilité des changements, suivi des spécifications et conception, règles de codage; dans les tests: test unitaires, tests systèmes, tests de mise en circulation, ...
D'ailleurs Toyota a plus ou moins tout ça. Plus ou moins. Et avec plus ou moins de sérieux. La validation est faite, mais lorsque la tâche de la logique est tuée, ça tue aussi la validation, la revue a été faite sur un code incomplet, les règles de codage sont minimes et même pas respectées, etc. Je ne sais pas trop ce qu'il y avait avant ISO 26262, mais les mesures décrites au-dessus étaient connues et appliquées avant qu'une norme ne vienne formaliser le tout. Heureusement.
J'en profite pour corriger ce que je dis au-dessus à propos du couplage obligatoire entre la pédale de freins et les étriers. C'est valable pour un circuit hydraulique, mais pas pour du "brake-by-wire" c'est à dire un capteur électronique dont le signal est traité pour activer une pompe mais sans couplage mécanique. Dans ce cas, si j'ai bien tout retenu de ce que m'a dit le collègue, il doit y avoir deux sources d'énergie au cas où l'une tombe en panne (donc deux batteries, ce qui est finalement peu intéressant au niveau du poids). D'autre part, le système de freinage doit pouvoir proposer un système principal (service) et un système secondaire d'urgence (auxiliary) (en l’occurrence le frein à main). Au passage, le frein à main ne dispose pas de système anti-blocage d'où les longues marques des pneus sur la route.
Pour finir, je ne dis pas que le système de freinage est exempt de bugs, ni chez Toyota, ni en général. Mais dans l'affaire qui est présentée ici, il est question uniquement du contrôle moteur et en aucun cas du contrôle des freins. La sensation de ne plus pouvoir freiner étant d'après ce que j'ai lu, uniquement liée au fait que le moteur force dans l'autre sens. C'est peut être évident pour moi, et pas pour d'autres mais ces système n'ont rien à voir ensemble. Ce sont deux boites séparées, ayant chacun leur propre système embarqué (CPU, RAM, EEPROM, tout ce que vous voulez), bien souvent développés par des entreprises distinctes ayant leurs propres méthodologies. C'est un peu comme si en parlant de la faille zero-day Java, on accusait Firefox d'être un gruyère. On peut discuter de l'un ou de l'autre, mais même s'ils semblent liés d'une certaine manière, les deux n'ont rien à voir.
[^] # Re: corriger cette dépeche
Posté par Cilyan Olowen . En réponse à la dépêche Encore un exemple de code spaghetti : Toyota. Évalué à 4.
Comme tout système électronique, il peut y avoir des bugs et des pannes. Logicielles, ou même matérielles. Donc théoriquement et même pratiquement parlant, une valve peut se bloquer en position ouverte. L'usure, le froid, un bug, un défaut de fabrication. La question n'est pas de savoir si ça peut se produire, mais quels sont les risques et comment l'on s'assure qu'on a tout fait pour que ça n'arrive pas. Dans la logique: validation croisée des valeurs des capteurs, vérification du comportement des sorties (pour répondre à ta question, il y a un sacré paquet de vérifications sur la valeur des capteurs de vitesse des roues et si l'ABS n'autorise aucune admission de pression pendant un temps donné, il est coupé en urgence); dans la méthodologie: revues, traçabilité des changements, suivi des spécifications et conception, règles de codage; dans les tests: test unitaires, tests systèmes, tests de mise en circulation, ...
D'ailleurs Toyota a plus ou moins tout ça. Plus ou moins. Et avec plus ou moins de sérieux. La validation est faite, mais lorsque la tâche de la logique est tuée, ça tue aussi la validation, la revue a été faite sur un code incomplet, les règles de codage sont minimes et même pas respectées, etc. Je ne sais pas trop ce qu'il y avait avant ISO 26262, mais les mesures décrites au-dessus étaient connues et appliquées avant qu'une norme ne vienne formaliser le tout. Heureusement.
J'en profite pour corriger ce que je dis au-dessus à propos du couplage obligatoire entre la pédale de freins et les étriers. C'est valable pour un circuit hydraulique, mais pas pour du "brake-by-wire" c'est à dire un capteur électronique dont le signal est traité pour activer une pompe mais sans couplage mécanique. Dans ce cas, si j'ai bien tout retenu de ce que m'a dit le collègue, il doit y avoir deux sources d'énergie au cas où l'une tombe en panne (donc deux batteries, ce qui est finalement peu intéressant au niveau du poids). D'autre part, le système de freinage doit pouvoir proposer un système principal (service) et un système secondaire d'urgence (auxiliary) (en l’occurrence le frein à main). Au passage, le frein à main ne dispose pas de système anti-blocage d'où les longues marques des pneus sur la route.
Pour finir, je ne dis pas que le système de freinage est exempt de bugs, ni chez Toyota, ni en général. Mais dans l'affaire qui est présentée ici, il est question uniquement du contrôle moteur et en aucun cas du contrôle des freins. La sensation de ne plus pouvoir freiner étant d'après ce que j'ai lu, uniquement liée au fait que le moteur force dans l'autre sens. C'est peut être évident pour moi, et pas pour d'autres mais ces système n'ont rien à voir ensemble. Ce sont deux boites séparées, ayant chacun leur propre système embarqué (CPU, RAM, EEPROM, tout ce que vous voulez), bien souvent développés par des entreprises distinctes ayant leurs propres méthodologies. C'est un peu comme si en parlant de la faille zero-day Java, on accusait Firefox d'être un gruyère. On peut discuter de l'un ou de l'autre, mais même s'ils semblent liés d'une certaine manière, les deux n'ont rien à voir.