Posté(é) septembre 30, 20178 a Bonjour aux APistes et autres fashionistas des AP1, AP2... Un article très intéressant sur le codage informatique, qui concerne l'industrialisation du codage. Le point de départ c'est la complexité monstrueuse et non maîtrisée de programmes qui font des millions de lignes... bugs, problèmes de sécurité etc... https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/ Et au passage des remarques qui nous concernent spécialement, les programmes informatiques embarqués dans nos véhicules, qui n'ont pas été codés avec beaucoup de soin... cf : “Code is still, in many places, handicraft. When you’re crafting manually 10,000 lines of code, that’s okay. But you have systems that have 30 million lines of code, like an Airbus, or 100 million lines of code, like your Tesla or high-end cars—that’s becoming very, very complicated.” “There are lots of bugs in cars,” Gerard Berry, the French researcher behind Esterel, said in a talk. “It’s not like avionics—in avionics it’s taken very seriously. And it’s admitted that software is different from mechanics.” The automotive industry is perhaps among those that haven’t yet realized they are actually in the software business. “We don’t in the automaker industry have a regulator for software safety that knows what it’s doing,” says Michael Barr, the software expert who testified in the Toyota case. NHTSA, he says, “has only limited software expertise. They’ve come at this from a mechanical history.” The same regulatory pressures that have made model-based design and code generation attractive to the aviation industry have been slower to come to car manufacturing. Emmanuel Ledinot, of Dassault Aviation, speculates that there might be economic reasons for the difference, too. Automakers simply can’t afford to increase the price of a component by even a few cents, since it is multiplied so many millionfold; the computers embedded in cars therefore have to be slimmed down to the bare minimum, with little room to run code that hasn’t been hand-tuned to be as lean as possible. “Introducing model-based software development was, I think, for the last decade, too costly for them.”
Posté(é) septembre 30, 20178 a Je reviens à la charge, mais je le redis encore, un gros soucis de sécu avec les Tesla et autres véhicule constamment rattacher à un réseau informatique...
Posté(é) septembre 30, 20178 a Pour donner un point de vue : - la programmation dépend des us et coutumes des gens en place, c'est eux qui orientent le développement et forcent les développeurs à suivre un cahier des charges, des objectifs et des étages de validations pour chaque couches - un langage peut-être totalement incompréhensible car fondé sur une approche pragmatique ou hiérarchique - les programmes les plus simples et les plus robustes sont TOUJOURS pragmatiques - les programmes les plus cosmétiques et les moins fiables sont ceux dépendant de bibliothèques encapsulées externes et chargées sans en comprendre leur demande lors de leur utilisation Je suis un codeur ASM/BASIC ... et malgré cela, inutile de me demander la lune, je dois régulièrement consulter les instructions pour comprendre et connaître leurs limites. Donc, en résumé, si une industrie veut être libre ... elle doit fiabiliser sa hiérarchie de développement AVANT de vouloir des génies aux commandes. Tesla n'aime pas produire des voitures : au niveau programmation, ça crève les yeux. Raison de SpaceX d'ailleurs ... pour faire miroiter qu'après quelques mois/années chez Tesla à "résoudre des problèmes récurrents", ils pourront monter ... en grade chez SpaceX. --- Du coté coréen, c'est l'inverse : la hiérarchie fonctionne parfaitement à la manière des étages de validation Github. Les multiples intervenants que je côtoie dans cette partie du monde sont carrés comme pas 2. Les allemands à coté (bosch, etcs ...), c'est des bisounours en terme d'organisation et d'efficacité. Raison aussi et pourquoi les coréens peuvent et veulent produire à domicile tous leurs besoins d'objets électroniques : ils ont les industries et le suivi hiérarchique pour cela. On peut comparer cela à la première ère JVC/Toshiba au Japon. Leurs développeurs de l'époque étaient quasiment à coté de la ligne de fabrication et pouvaient obtenir des PCB/Die dans la journée qui suit pour tester les limites logiciels de leur programmation ou les limites d'une chaine de fabrication (plutôt ...).
Posté(é) septembre 30, 20178 a Salut, Attention, les X millions de lignes de code embarqués dans tel ou tel système (Tesla ou autre), ce ne sont pas des lignes de code écrites directement par les équipes de Tesla ou autre. J'imagine que les systèmes de Tesla (et de nombreux autres) sont basés sur le noyau Linux, qui fait actuellement lui-même presque 20 millions de lignes de code et qui est particulièrement stable ; des centaines de développeurs y travaillent et c'est géré de manière très carrée. Et à côté de ça il y a de nombreux logiciels, simples ou non, assez communs entre les différents systèmes, que ce soient des téléphones, des PC ou des voitures. Et là encore, c'est plutôt propre, avec plusieurs développeurs très impliqués. Vive l'Open Source. Il y a de nombreuses manières d'aborder le métier du développement informatique, certaines sont risquées, à la va-vite et sans grande vérification (du travail d'amateur, comme moi par exemple), d'autres sont très carrées et peu sujettes aux erreurs (utilisation de tests unitaires, etc). Concernant l'avionique, les contraintes sont lourdes, et ça se comprend. Un ami qui a travaillé avec ces environnements m'a expliqué qu'autant en matériel qu'en logiciel, tout est fait en triple, avec trois langages de programmation différents, trois types de matériels différents, trois équipes de développeurs différentes, etc. Comme ça s'il y a un bug, ça ne concernerait qu'un équipement sur trois... Une approche telle que celle-ci dans les voitures me rassurerait. Enfin, concernant « The automotive industry is perhaps among those that haven’t yet realized they are actually in the software business », je suis d'accord. Par contre, pour Tesla, à mon sens ça ne s'applique pas car, on n'est pas dans l'industrie automobile : c'est une société de développement informatique qui vend des ordinateurs avec un moteur, 4 roues et un volant...
Posté(é) octobre 18, 20178 a Je reviens à la charge, mais je le redis encore, un gros soucis de sécu avec les Tesla et autres véhicule constamment rattacher à un réseau informatique... Il faut définir "connexion", et là je pense que quand on n'est pas dans le métier, comme je le suis, on fait un amalgame permanent entre le fait d'avoir une connexion réseau et le fait de pouvoir se faire pénétrer, dans un sens ou dans l'autre : il y a la pile physique, la pile de connexion et la pile applicative, pour faire un résumé très grossier. La majeure partie des failles que l'on voit aujourd'hui fleurir sont dues au dernier point, où des tas de piles logicielles ont été développées avec pour objectif de fournir des fonctionnalités, et donc réduire le temps de développement final, au détriment de la sécurité... Piège dans lequel tout le monde tombe à plus ou moins brève échéance et plus ou moins sévèrement. Et quand on regarde l'historique de Tesla à ce sujet, il font partie des très bons élèves par rapport à tous les autres constructeurs automobiles.
