Cocotb, le cadriciel libre de vérification matérielle en Python, vient de publier sa version majeure 2.0. Cette sortie marque une étape importante dans l’évolution de ce projet qui permet de tester des circuits numériques décrits en VHDL ou Verilog directement depuis Python, sans avoir à écrire de testbench en HDL.

Pour celles et ceux qui ne connaissent pas encore cocotb, il s’agit d’un outil qui facilite grandement la vie des personnes travaillant sur la conception de circuits intégrés. Plutôt que d’écrire des bancs de test complexes en VHDL ou Verilog, cocotb permet d’utiliser Python et son écosystème riche (NumPy, pytest, etc.) pour vérifier le comportement des circuits.
Cocotb (Coroutines-based Cosimulation Test-Bench) permet d’écrire en python des bancs de test qui vont piloter directement le simulateur HDL via différentes interfaces (VPI, VHPI, FLI). La plupart des simulateurs HDL du marché sont supportés, qu’ils soient libres ou non.

Sommaire

• Une version majeure synonyme de changements
  • Principales ruptures de compatibilité
• Les nouveautés marquantes
  • Amélioration des performances
  • Prise en charge étendue des simulateurs
  • Gestion améliorée des tâches
  • Nouvelles fonctionnalités pour les signaux
  • Améliorations du typage
  • Décorateur @cocotb.parametrize
  • Gestion du logging améliorée
• Nouvelles structures de données
• Améliorations de l’écosystème
  • Flux de test en Python
  • Queues asyncio
  • Gestion des packages SystemVerilog
• Considérations sur l’adoption
• Remerciements et perspectives

Une version majeure synonyme de changements

Comme l’indique le numéro de version, cocotb 2.0 introduit des changements incompatibles avec les versions précédentes. L’équipe de développement a profité de cette version majeure pour nettoyer l’API, supprimer du code obsolète et moderniser l’architecture du projet. Un guide de migration détaillé est disponible pour accompagner la transition.

Principales ruptures de compatibilité

La transition vers cocotb 2.0 nécessite quelques adaptations du code existant :

• Suppression des coroutines à base de générateurs : La syntaxe yield (avec le décorateur @cocotb.coroutine) a été supprimée. Il faut désormais utiliser exclusivement la syntaxe moderne async/await.

• Nouvelles conventions de nommage : Les variables d’environnement ont été renommées pour éviter les conflits avec les simulateurs. Par exemple, MODULE devient COCOTB_TEST_MODULES, TOPLEVEL devient COCOTB_TOPLEVEL, etc.

• Changements dans les types de données : Les objets BinaryValue ont été remplacés par LogicArray, offrant une API plus cohérente et moderne pour manipuler les valeurs logiques.

• Modifications des déclencheurs : L’objet Join est devenu obsolète au profit d’une utilisation directe des tâches. La syntaxe await task.join() devient simplement await task.

Les nouveautés marquantes

Amélioration des performances

La nouvelle version apporte des gains de performance significatifs, notamment grâce à l’implémentation en C++ d’un générateur d’horloge (GpiClock). Cette optimisation réduit les échanges entre Python et l’interface GPI, permettant des simulations plus rapides, particulièrement pour les designs utilisant de nombreuses horloges.

Prise en charge étendue des simulateurs

Cocotb 2.0 élargit sa prise en charge des simulateurs commerciaux et libres :

• DSim (Siemens) est maintenant officiellement géré
• Questa bénéficie d’un nouveau flux de compilation qisqrun utilisant le Questa Information System pour de meilleures performances
• NVC, le simulateur VHDL libre, est désormais géré
• Verilator (version 5.036 minimum) avec le flag --timing est maintenant pleinement fonctionnel

Gestion améliorée des tâches

L’API de gestion des tâches a été modernisée pour s’aligner sur celle d’asyncio` :

# Nouvelle fonction pour démarrer une tâche
cocotb.start_soon(ma_coroutine())

# Nouveau déclencheur pour attendre la fin d’une tâche
await task.complete  # au lieu de await Join(task)

# Annulation de tâches
task.cancel()  # au lieu de task.kill()

# Variables locales aux tâches
task.locals.ma_variable = valeur

Nouvelles fonctionnalités pour les signaux

Cocotb 2.0 enrichit les possibilités d’interaction avec les signaux HDL :

• Dépôts sans délai : La classe Immediate permet d’effectuer des assignations immédiates
• Nouvelle méthode set() : Une alternative à la propriété value avec un typage plus strict
• Gestion étendue des actions : Force, Freeze, Release et Deposit pour un contrôle fin des signaux

# Différents types d’assignations
dut.signal.set(42)                    # Assignation normale
dut.signal.set(42, Immediate())       # Assignation immédiate
dut.signal.set(42, Force())           # Forcer une valeur
dut.signal.set(Release())             # Libérer un signal forcé

Améliorations du typage

Cocotb 2.0 intègre maintenant mypy dans son processus de CI, garantissant une meilleure qualité du typage. Les utilisateurs bénéficient ainsi d’une meilleure expérience avec les IDE modernes et les vérificateurs de types.

Décorateur @cocotb.parametrize

Un nouveau décorateur simplifie la création de tests paramétrés, offrant une alternative plus moderne à TestFactory :

@cocotb.parametrize(
    width=[8, 16, 32],
    signed=[True, False]
)
@cocotb.test()
async def test_additionneur(dut, width, signed):
    # Test avec différentes combinaisons de paramètres
    pass

Gestion du logging améliorée

Le système de logging a été revu pour être moins intrusif :

• Nouvelle variable COCOTB_LOG_PREFIX pour personnaliser le préfixe des logs
• Séparation des niveaux de log pour GPI avec GPI_LOG_LEVEL
• Meilleure gestion de la capture des warnings Python
• Timestamps de simulation accessibles dans les LogRecord

Nouvelles structures de données

La version 2.0 enrichit considérablement le module cocotb.types :

• LogicArray : Représentation des tableaux de valeurs logiques avec gestion des états X, Z, etc.
• Logic : Valeur logique unique avec gestion des 9 états VHDL
• Méthodes de conversion : to_signed(), to_unsigned(), to_bytes(), from_bytes() pour faciliter les conversions

from cocotb.types import LogicArray, Range

# Création d’un tableau logique
data = LogicArray("10XZ01", Range(5, "downto", 0))

# Conversions
valeur_entier = data.to_unsigned(resolve=True)
octets = data.to_bytes()

Améliorations de l’écosystème

Flux de test en Python

Le flux de test Python (Python Test Runner), introduit expérimentalement en version 1.8, est maintenant mature et constitue l’alternative recommandée au système de Makefile traditionnel. Il permet une intégration plus naturelle avec pytest et simplifie la configuration des simulations.

Queues asyncio

Cocotb 2.0 introduit des files d’attente compatibles avec asyncio (Queue, PriorityQueue, LifoQueue), facilitant la communication entre coroutines.

Gestion des packages SystemVerilog

L’accès aux packages SystemVerilog est maintenant possible via cocotb.packages, permettant d’interagir avec les définitions globales du design.

Considérations sur l’adoption

Cette version majeure représente un investissement conséquent de l’équipe de développement. Pour les utilisatrices et utilisateurs existants, la migration nécessitera quelques ajustements, mais les bénéfices en termes de maintenabilité et de performances en valent la peine.

Le projet cocotb, développé principalement par la communauté et utilisé dans l’industrie comme dans l’enseignement, continue de démontrer la pertinence de l’approche Python pour la vérification matérielle. Cette version 2.0 consolide les bases pour les évolutions futures.

Pour les personnes qui débutent avec cocotb, c’est le moment idéal pour se lancer : la documentation a été revue, les exemples mis à jour, et l’API est désormais plus cohérente.

Remerciements et perspectives

Cette version est le fruit du travail de nombreuses personnes contributrices. Le projet est hébergé sur GitHub et accepte volontiers les contributions, qu’il s’agisse de code, de documentation ou de retours d’expérience.

Les prochaines versions devraient continuer à améliorer les performances, étendre la prise en charge des simulateurs et enrichir l’écosystème de bibliothèques de vérification. La communauté cocotb est active et accueillante, n’hésitez pas à la rejoindre !

Cette dépêche fait suite à celle sur les interfaces temps réel ainsi qu’a celle sur l’informatique sans écran. C’est une dépêche de réac qui se plaint que c’était bien mieux avant et qu’on ferait bien d’écouter les anciens un peu plus.

Sommaire

• Retour vers le futur boutonneux
• C’était mieux avant ! (On était jeune)
• Ça change quoi ? Un bouton c’est un bouton, non ?
• Le patch de Colombia
• L’urgence ergonomique
• Bibliographie

C’est une note du blog de ploum qui m’a fait réaliser que l’on a besoin de remettre des boutons, des touches, des joysticks, des potentiomètres linéaires et autres boules de pointage (trackball), souris (boutons et molette), manettes… sur nos ordinateurs, télés, ordiphones, bagnoles et autres mixeurs à soupe mouchard. C’est urgent à l’heure où même nos guitares sont menacées par les écrans tactiles. Bref, une bonne interface Humain/Machine passe par un retour tactile de nos actions : on veut des boutons !

Figure 1 - Refus catégorique de ChatGPT. Peut-être que « Dessine moi un adolescent avec plein de moutons » aurait été mieux accepté. Big Data implique Big Culture, non ?

Retour vers le futur boutonneux

Avant de râler et de déclencher la Guerre des boutons, interrogeons-nous sur ces objets du quotidien. On est sérieux à nôtre âge, on n’a plus dix-sept ans.

Si on considère les touches des claviers d’instruments de musique comme les ancêtres du bouton, alors on peut remonter jusqu’à l’Antiquité et aux premiers orgues : l’hydraule, orgue où l’air est mis sous pression par une chute d’eau, date en effet du III^e siècle avant notre ère (Ctésibios d’Alexandrie). C’est aussi le premier instrument à clavier. Ses touches avaient probablement des mécanismes très simples et il n’y avait pas de touches blanches et noires, comme dans cette reconstitution d’un orgue antique (avec même le son dans la vidéo). Vers 320-322 de notre ère, Claudien écrit un poème contenant ces vers :

« Qu’un autre enfantant, par une légère pression, des sons au loin retentissant, modère les mille voix de mille tuyaux d’airain, les fasse tonner sous ses doigts errants, et d’une onde profondément agitée par le jeu du levier, tire d’harmonieuses modulations. » (Panégyrique sur le consulat de Flavius Mallius Theodorus)

Figure 2 - Reconstitution d’un orgue romain. [Source : Wikimedia, domaine public]

On trouve déjà dans cette description le constat qu’il suffit d’appuyer sur un bouton pour déclencher des tâches mobilisant une grande puissance. Seize siècles plus tard, en pleine guerre froide et deux ans après la crise des missiles de Cuba, le jeune Bob Dylan (22 ans) chante dans With God On Our Side (The Times They Are A-Changin’, 1964) :

One push of the button
And a shot the world wide

Figure 3 - Tableau de bord des missiles de croisière nucléaires du sous-marin USS Growler (1958-1964). [Source : Wikimedia, licence : CC-BY-SA par Flintmichigan]

C’est en fait dans les deux dernières décennies du XIX^e siècle, avec la diffusion de l’électricité dans les villes, que se produit la grande éruption des boutons. Nous avons bien sûr oublié à quel point c’était magique à l’époque ! Mais on s’inquiète aussi rapidement de l’avènement d’une humanité presse-bouton :

Plotnick cite un éducateur et activiste de 1916 déplorant que le fait d’appuyer sur un bouton « semble nous décharger de toute nécessité de se sentir responsable quant à ce qui se passe derrière le bouton ».

Les récits d’anticipation s’en emparent. Par exemple, Edward Morgan Forster publie en 1909 une nouvelle intitulée The Machine Stops (La Machine s’arrête) dans laquelle les êtres humains vivent sous terre isolés chacun dans une pièce, quasiment sans contact physique, la Machine satisfaisant tous leurs besoins :

Puis elle activa la lumière, et la vue de sa chambre, inondée de lumière et constellée de boutons électriques, la revigora. Il y avait des boutons et des interrupteurs partout - des boutons pour demander de la nourriture, de la musique, des vêtements. Il y avait le bouton du bain chaud, qui faisait surgir du sol une cuve en (faux) marbre, remplie à ras bord d’un liquide chaud et désodorisé. Il y avait le bouton du bain froid. Il y avait le bouton qui produisait de la littérature. Et il y avait bien sûr les boutons qui lui permettaient de communiquer avec ses amis. La chambre, bien que ne contenant rien, était connectée avec tout ce qui lui importait dans le monde. (Version originale en ligne sur The Project Gutenberg et version française éditée par l’échappée)

C’était mieux avant ! (On était jeune)

Tout râleur qui tient à sa crédibilité se doit de râler en connaissance de cause. On n’ira donc pas jusqu’à prétendre que c’était mieux sans bouton et on se contentera de notre vécu : c’était mieux avant quand il y avait de vrais boutons ! Qu’on pouvait pressurer et qui faisaient de vrais sons, « des clip, crap, des bang, des vlop et des zip », qui résistaient, qui vibraient, qui glissaient ! Bref, qui nous donnaient des sensations.

Figure 4 - Malgré cet appel touchant, les portes de la perception semblent désormais presque fermées. Le monde est devenu plat et lisse ; les êtres humains se sont enfermés dans leur caverne numérique. [Source : Wikimedia, licence : CC-BY par SunOfErat]

Bien que la technologie des écrans tactiles soit assez ancienne, c’est surtout l’envolée des ventes de smartphones et tablettes autour de 2010 qui va propager les interfaces tactiles à d’autres objets du quotidien : des appareils électroménagers jusqu’aux voitures, pour le meilleur et pour le pire. Probablement parce qu’un écran tactile avec des menus permet de remplacer de nombreux boutons et aussi par effet de mode (ça fait moderne, en attendant les interfaces cérébrales). Dans nos interfaces graphiques, telles que GTK, on retrouve des ersatz de boutons : interrupteurs On/Off, boutons radio (quand on presse sur l’un, l’autre ressort), commutateurs (switches), etc. Mais tout ça manque de relief !

Sur les lecteurs de K7, on pouvait avoir des boutons poussoir qui remettaient à zéro le compteur (mécanique). Et également des boutons qu’on poussait vers le bas et qui restaient bloqués (lecture) ou non (éjection). Press the Eject and Give Me the Tape est par exemple le titre d’un album live du groupe britannique Bauhaus sorti en 1982.

Figure 5 - Un magnétophone : appuie sur Eject et file-moi la K7 ! [Source : Wikimedia, domaine public]

Sur une chaîne Hi-Fi, on trouve de bons gros boutons cylindriques que l’on peut prendre à pleine main. Ils peuvent être continus (par exemple pour le volume), c’est-à-dire que ce sont des potentiomètres rotatifs, ou à crans (par exemple pour sélectionner une source). Ces gros boutons ont été longtemps également utilisés pour sélectionner les fréquences des stations de radio et ils faisaient bouger un curseur au-dessus des graduations. Sur nos chaînes, on peut aussi avoir des boutons de type manette, avec deux positions ou plus. Sur les radio-K7 on pouvait également rencontrer des potentiomètres linéaires pour régler le volume ou la tonalité. On les utilise aussi sur les égaliseurs, comme ci-dessous.

Figure 6 - Une éruption de boutons divers et variés, sensations garanties [source : Wikimedia, licence : CC0].

Dans la suite de cette dépêche, on va surtout évoquer les boutons poussoir (qu’ils restent bloqués ou non) car ce sont ceux que l’on rencontre le plus dans les interfaces tactiles. Mais le discours serait similaire pour les autres types de boutons.

Ça change quoi ? Un bouton c’est un bouton, non ?

Le problème de l’écran tactile, c’est que c’est l’écran qui est tactile, qui touche, qui sent notre doigt. Le doigt, quant à lui, sent juste qu’il a touché une surface, mais il ne sait pas s’il est au bon endroit. L’écran est soi-disant tactile, mais c’est avant tout un écran, ce qui implique la vue. Lorsque l’on touche le bouton avec son doigt, on le cache. Pour savoir s’il on a bien appuyé sur le bouton il faut donc retirer son doigt et regarder à nouveau si le bouton virtuel a changé d’état.

Du point de vue de l’utilisateur, on a donc plutôt affaire à des « boutons visuels » plutôt qu’à un « écran tactile ». Tout au plus l’émission d’un clic électronique ou d’une vibration non localisée confirmera qu’on a appuyé sur un bouton (parmi d’autres).

Avec de vrais boutons, c’est du 3D. Si on a mémorisé leur disposition, on peut s’en sortir sans la vue, uniquement au toucher. Intéressant quand on conduit par exemple, les doigts se promènent par exemple sur les six boutons pour choisir la station de radio et trouvent sans problème le troisième bouton. Une personne aveugle sera bien démunie face à un écran tactile. Un bouton mécanique est quant à lui vraiment tactile, c’est-à-dire que les doigts le sentent : le toucher prédomine alors sur la vision. D’ailleurs en français, les « boutons » d’un clavier, qu’il soit musical ou informatique, s’appellent des touches.

On peut aussi noter que les vrais boutons sont généralement en nombre limité (car ça prend de la place et ça coûte). Ils permettent donc d’effectuer les actions les plus courantes. Les écrans permettent de créer des menus, pour des choix plus complexes. Mais cela peut être redoutable pour certaines personnes âgées, qui n’ont pas été habituées à ces technologies, ou dont les fonctions cérébrales déclinent. Ne parlons même pas des mises à jours logiciels incessantes qui changent l’aspect et la disposition des menus.
Le pire étant le manque de performance (c'est rarement temps réel) qui nous force souvent à ré-apppuyer pour se retrouver avec un comportement que l'on avait pas prévu quand ça se débloque.

Autre problème, on a parfois besoin de protéger ses doigts avec des gants, qu’il fasse froid ou qu’on soit en train de faire une activité dangereuse pour les mains. Un bon vieux bouton reste généralement utilisable. Même avec des moufles, on pourra encore y arriver si les boutons ne sont pas trop rapprochés !

Figure 7 - Parfois on doit travailler avec des gants, ce qui entraîne une perte au niveau tactile. Il y a vraiment là de quoi faire la moue. [Source : Wikimedia, domaine public]

Revenons sur le son. Les boutons sur lesquels on appuie émettent souvent un son qui constitue un retour sensoriel supplémentaire qui nous indique si nous les avons correctement enfoncés. Au point que l’on parle de « cliquer » sur le bouton d’une souris plutôt que d’appuyer dessus. On a donc à la fois un retour tactile (une certaine résistance ou vibration) et un retour sonore, en plus de l’éventuel retour visuel si on regarde le bouton.

Avec un écran dit tactile, le retour tactile est justement bien maigre, on ne fait qu’effleurer les choses : la pression exercée importe peu, la résistance opposée par l’écran sera la même si j’appuie sur le soit-disant bouton ou à côté ! Et le vibreur de mon téléphone fera vibrer tout le téléphone au lieu de ne faire vibrer que l’endroit où j’ai appuyé. Triste topique…

Le patch de Colombia

Les constructeurs d'ordiphone s'échinent à virer les boutons de leurs appareils ? Qu'à cela ne tienne, des étudiants de l'Université de Colombia proposent une coque pour en remettre !

Sans aucune connexion électrique, ces étudiants proposent de faire vibrer le téléphone au moyen de clapet et ressort et de les détecter en utilisant l'accéléromètre.

Le type de vibration reçue permet à un logiciel de traitement du signal de détecter le type de bouton actionné et ainsi récupérer la fonctionnalité perdue.

C'est intéressant, mais pourquoi ne pas tout simplement nous rendre nos boutons !

L’urgence ergonomique

Nous savons bien que les temps changent, mais il ne faut pas céder à la mode sans raison. L’écran tactile peut être adapté à certaines machines ou situations et pas à d’autres. Faut-il vraiment « être absolument moderne », juste pour le plaisir ? Non, il faut être absolument ergonomique. Alors, si vous ne voulez pas vous faire appeler Arthur, rendez-nous nos bons vieux boutons là où ils sont parfaitement adaptés à nos besoins ! Rouvrons les portes de la perception !

Figure 8 - Un adolescent peut aussi avoir des boutons au niveau de son gilet. De plus, en voilà un qui ne sourit pas et n’a pas l’air niais. Ce qui finalement justifie peut-être le refus de ChatGPT en haut de cette dépêche. [Source : Wikimedia, Étienne Carjat (1871), domaine public]

Bibliographie

• Gwendolyn Rak, « Touchscreens Are Out, and Tactile Controls Are Back - Rachel Plotnick’s “re-buttonization” expertise is in demand », IEEE Spectrum, 3 nov. 2024.
• Rachel Plotnick, « At the Interface: The Case of the Electric Push Button, 1880–1923 », Technology and Culture 53 (4): 815‑45, 2012.
• Dans Wikipedia : Bouton (électricité), Interrupteur, Push-button.
• Entrée Bouton dans le dictionnaire TLFi.

L’informatisation et la mise en réseau des ordinateurs nous ont apporté beaucoup de choses formidables ces trente dernières années. Toute la culture musicale, cinématographique et encyclopédique est désormais à une portée de clic de quiconque. Téléphoner de n’importe où à n’importe qui tout autour de la terre est devenu quelque chose de tellement courant que plus personne ne s’en extasie. Et même si l’interlocuteurice s’exprime dans une autre langue ça n’est presque plus un problème avec les différents services de traduction en ligne que l’on peut avoir.

Ne parlons même pas de ce mini-ordinateur que presque tout le monde a désormais dans sa poche, équipé d’une chaîne hifi complète, d’un caméscope, d’un appareil photo d’excellente qualité et d’une connexion permanente au réseau mondial.

Nos logements sont désormais entièrement automatisables et pilotables à distance.

Je peux avoir de la musique ou la radio quand je veux dans mon casque sans fil grâce à la baladodiffusion.

Tous ces rêves numériques des années 90 se sont concrètement réalisés aujourd’hui, mais nous avons tout de même perdu quelque chose : le temps réel des interfaces

N. D. M. : par « temps réel » est ici utilisé dans le sens réponse immédiate humainement parlant, sans latence perceptible, réactives (voir les définitions Wiktionary ou Wikipedia pour temps réel qui, pour l’informatique, vont amener des exigences supplémentaires sur la durée maximale de réponse, la garantie du temps de réponse, etc.

Sommaire

• Le temps réel des interfaces
• Les systèmes sont devenus mous
• Revenons aux interfaces réactives
• Manifeste des interfaces temps réel
• Vers un Score-Interfaces-Temps-Réel ?
• Conclusion

Le temps réel des interfaces

En effet, avec la diffusion du numérique à tous les étages, les interfaces se sont ramollies. Aujourd’hui, lorsque nous appuyons sur un bouton pour jouer une musique, lancer une vidéo ou valider un formulaire sur Internet nous n’avons pas un retour immédiat de cet appui.

Il s’écoule souvent un temps non négligeable entre l’appui sur ledit bouton et la réaction du système. Ce problème ne se limite pas aux boutons bien sûr, c’est le même problème avec les branchements des chargeurs et autres interfaces USB, HDMI…

Nous ne sommes jamais immédiatement sûrs que l’action se soit bien passée. Si la réaction met trop de temps à venir (lancement de la musique, icône de mise en charge, validation du formulaire…) nous allons avoir tendance à réessayer au risque de se retrouver avec un « dys »fonctionnement anormal. Le bouton « play » de la musique est également le bouton pause, un ré-appui sur le bouton coupe la musique. Une absence de réaction de l’appareil au branchement va nous amener à débrancher puis rebrancher jusqu’à jeter le câble et en prendre un autre. Un ré-appui sur le bouton du formulaire va en renvoyer un autre, etc.

Nous parlons bien ici des interfaces qui ne sont pas en temps réel. Cela n’a rien à voir avec la puissance de calcul des machines. Les appareils des années 90 avaient beau avoir des interfaces temps réel, ils n’étaient pas puissants, beaucoup ne disposaient même pas de microprocesseurs.

Sur mon lecteur de cassettes audio, lorsque j’appuyais sur le bouton « play » le bouton émettait un « clic » bien distinctif et une petite vibration dans le doigt qui m’assurait que mon appui était bien pris en compte. Et si j’étais à la fin de la cassette le bouton remontait immédiatement, je savais instantanément que cela n’avait pas marché et qu’il fallait que j’appuie sur « eject » pour retourner la cassette… ou « rewind » pour rembobiner.

Pour lire ma cassette de petit ours brun, j’appuie sur le triangle et ça fait «clic» instantanément !

Alors que pour allumer la boite à histoires, il faut appuyer sur un bouton planqué sur le côté, et attendre plusieurs secondes que l’écran affiche un sourire. Ai-je bien appuyé ? Dois-je retenter ? Y a-t-il suffisamment de batterie pour que j’obtienne une réaction ? Et je ne parle même pas des deux boutons rotatifs rouge qui ne réagissent pas instantanément (en plus celui de gauche est à tourner pour le volume et celui de droite est à CLIQUER pour changer d’histoire…)

Les télévisions cathodiques des années 70-80 prenaient un certain temps à chauffer avant d’afficher l’image, mais l’appui sur le bouton « on » était marqué par un « clang » bien net, et nous savions que la télé était allumée, nous pouvions attendre d’avoir l’image. Les télés d’aujourd’hui mettent également du temps à s’allumer, mais elles ne signalent pas toujours la bonne réception de notre action sur la télécommande. Et ne parlons même pas des écrans d’ordinateur avec leur interface tactile à la noix (on doit pouvoir parler d'interfaces digitales pour le coup non ?) dont on ne voit même pas où se trouve le bouton.

Les systèmes sont devenus mous

Et cette mollesse les rend dysfonctionnels. Je ne compte plus le nombre de fois ou voulant ré-appuyer sur un bouton de validation, j’ai finalement appuyé sur un nouveau bouton venant d’apparaître sous mon doigt/curseur. Sans parler de tous ces systèmes électroniques portables qui prennent un temps dingue avant d’afficher quelque chose quand on appuie sur le bouton “ON”. Systèmes qui ne sont pas toujours réellement éteints d’ailleurs et dont l’appui long… les éteint !
Ne parlons même pas des systèmes avec boutons rotatifs de type « potards numériques » qui — non contents de générer des rebonds ou de sauter des pas — fonctionnent avec la même mollesse que les boutons « standard ».

Mais le problème ne se limite pas aux systèmes embarqués. Oh que non ! Toute l’informatique « desktop » et mobile est touchée. Les sites Web ont rouillé avec leurs méga-octets de bibliothèques javascript à télécharger avant de pouvoir appuyer sur le moindre bouton.

Le réseau étant désormais massivement sans fil (WiFi, GSM, 4g, 5g, gégé, …), l’on ne sait pas toujours pourquoi cette page met tant de temps à se charger. Attention, il n’est pas question ici de vitesse de connexion, mais plutôt d’absence d’indication claire de ce qui est en train de se passer : ai-je déconnecté, ou le lien réseau est-il tout simplement lent ?

Revenons aux interfaces réactives

C’est un problème d’ergonomie. Et l’ergonomie est visiblement toujours reléguée en fin de projet «tant qu’on a un truc qui marche». Cependant, on pourrait considérer que non, ça ne marche pas si l’interface est si lente à réagir.

Je suis persuadé que ce problème n’est pas une fatalité. Il est possible de revenir à des interfaces humain-machine qui soient vraiment temps réel.

Mais il faut que tout le monde s’y mette.

• Aux électroniciennes et électroniciens de mettre systématiquement le voyant (ou vibreur, ou son) qui va bien pour signaler le bon branchement du câble, et le bon appui sur le bouton.
• Aux développeuses et développeurs noyau de soigner l’ordonnanceur pour s’assurer que la partie interface soit bien traitée dans un temps acceptable (moins de 100 ms ?).
• Aux développeuses et développeurs d’applis de considérer un temps de réaction trop long des interfaces comme un bug qu’il faut corriger.
• Aux utilisatrices et utilisateurs de ne plus accepter un seul ralentissement de l’interface et remonter systématiquement le problème comme un bug et/ou ne pas acheter/utiliser le produit.

Manifeste des interfaces temps réel

Voici donc une proposition/un manifeste de règles pour des interfaces temps réel :

1. Toute action humaine (appui ou clic-toucher sur un bouton, branchement d’un câble…) doit être validée par un retour en moins de 100 ms par un visuel, un son ou une vibration.
2. Si le système est bloqué l’utilisateurice doit le savoir. On doit pouvoir faire la différence entre un blocage et un temps de chargement. Un genre de watchdog de l’ergonomie.
3. On peut certainement ajouter d’autres règles quand on fera des audits ITR (Interfaces Temps Réels) dans les bureaux d’études et de développement des grosses boites.

Vers un Score-Interfaces-Temps-Réel ?

Évidement, il est impossible que ces règles s’appliquent du jour au lendemain sur tous les appareils et logiciel du marché. On pourrait inventer un système de notation, à l’image du nutri-score mais pour les interfaces. Par exemple le SITR pour Score-Interfaces-Temps-Réel et développer une appli pour pouvoir récupérer le score des produits qu’on utilise.
Appli qui aurait le culot d’avoir un mauvais score histoire de faire causer.

Conclusion

Pour conclure sur ce manifeste décousu :

✊🏼 Oui l’ergonomie est importante !
✊🏽 Oui un temps de réaction trop long est un BUG !
✊🏿 Oui il faut que ça change !

Lors d’un Noël de ma tendre jeunesse pré-adolescente est arrivé un « ordinateur » dans le foyer. Ce PC (Intel 386) a été installé dans le bureau et a vite dégénéré en console de jeux. Puis les années passant c’est devenu une formidable source d’expérimentation informatique pour un geek en devenir. À cette époque on sensibilisait la jeunesse à ne pas passer trop de temps devant la télévision et la console de jeux, puis devant l’ordinateur et les jeux vidéo violents. Mais on ne parlait pas vraiment de l’écran.

Aujourd’hui les messages de sensibilisation se résument aux écrans :

• « pas d’écran avant trois ans »
• « nos jeunes passent leurs temps sur leurs écrans » (comme si les « vieux » n’y étaient pas non plus)
• « attention les écrans fabriquent une génération de crétins »
• « les écrans, les écrans, les écrans…»

Il est vrai qu’aujourd’hui l’informatique ne se résume presque plus qu’à un écran. De l’ordinateur avec clavier+souris+écran, voire crayon optique, on est passé aux tablettes et ordiphones qui n’ont plus que l’écran (tactile quand même).

Pour prendre le contre-pied de cette obsession des écrans, je me demandais donc s’il existait encore une informatique « sans écran ». La formidable multiplicité des activités que l’on peut avoir sur un ordinateur pourrait-elle se faire sans écran ? Dans quelle mesure peut-on coder, surfer sur le web, lire/envoyer des mails sans écran ? Cette informatique fantasmée par notre ex-ministre de l’éducation est elle une réalité ?

Sommaire

• L’informatique, une histoire d’abord sans écran
• L’écran ≠ la vue
• L’embarquée, une informatique massivement sans écran
• L’éducation numérique mais sans écran
• Mais peut-on se passer d’écran pour développer ?
• Pour conclure

L’informatique, une histoire d’abord sans écran

Si l’on date la naissance de l’ère de l’informatique avec Ada Lovelace, et qu’on estime l’arrivée des ordinateurs avec écrans à la fin des années 1970, alors on peut aisément dire que l’informatique a été plus longtemps sans écran qu’avec.

Malgré son look cosplay de manga elle n’a pas subi trop d’écrans dans son enfance, elle.

De même, il est raisonnable de considérer l’ordinateur comme l’outil principal pour faire de l’informatique. Il fut largement sans écran à ses débuts.

Pas d’écran pour ces deux geeks qui ont développé UNIX et le langage C (source)

L’altair8800, sorti en 1975 et sur lequel Microsoft a écrit son BASIC, se programmait avec des rubans perforées, voire avec des commutateurs, et l’affichage se faisait avec quelques diodes (DEL) en face avant.
Les cartes à trous étant plutôt utilsées avec les gros ordinateurs (aka Big Iron).

Difficile de considérer ces deux lignes de diodes rouges comme l’écran de l’Altair8800

L’écran ≠ la vue

Pour faire sans écran, on pense instinctivement à utiliser d’autres sens que la vue comme l’ouïe ou le toucher (pour le goût ou l’odorat difficile d’imaginer la chose). Mais l’histoire de l’informatique nous montre que les premières interfaces homme-machine ne fonctionnaient pas avec des écrans, et pourtant utilisaient la vue (lumière, LED, imprimante, position mécanique…).

Mais qu’appelle-t-on écran ?

D’après la définition de Wikipédia, « un écran d’ordinateur est un périphérique de sortie vidéo d’ordinateur. Il affiche les images générées par la carte graphique de l’ordinateur. Grâce au taux de rafraîchissement d’écran élevé, il permet de donner l’impression de mouvement. »

Donc si l’on s’en tient à wikipédia, un écran d’ordinateur c’est :

• des images générées par une carte graphique d’ordinateur. Exit la télé cathodique avec un tuner analogique (qui devient rare aujourd’hui avec la TNT).
• avec un taux de rafraîchissement élevé. Exit les liseuses et autres appareils utilisant un affichage type «  papier électronique ».
• pas d’indication de résolutions.

On peut sans doute rajouter les écrans (comme les télés) qui ne sont pas raccordés à une carte graphique dans la catégorie écran.

Cela serait donc la résolution (définition et taille…) et le rafraîchissement (fréquence de balayage) du périphérique de sortie vidéo qui font un écran.

La matrice 5 × 5 d’un micro:bit ne correspond pas à un critère de résolution suffisant, pas plus que les deux poussoirs ne pourraient prétendre à être un clavier.
Pourtant il affiche bien une « image » de cœur <3 !

Les afficheurs 7 segments ne peuvent pas être considérés comme des écrans. Ils n’affichent que des chiffres et quelques symboles. Difficile de créer une impression de mouvement avec seulement des segments.
En faisant un effort, on arrive à reconstituer quelques lettres.

En doublant le nombre de segments, on arrive à afficher l’ensemble des lettres de l’alphabet latin
Sans diacritiques, faut pas pousser

Un « panel » LCD 20×4 et ses caractères de 8 pixels sur 5 forme un écran de 100 pixels sur 32, la résolution est déjà meilleure, même s’il est toujours prévu pour n’afficher que du texte. Néanmoins on se rapproche de l’idée que l’on se fait d’un « écran ».

Du papier électronique ne peut pas être un écran. La résolution peut être excellente mais le rafraîchissement reste insuffisant.

Finalement la définition de Wikipédia n’est guère rigoureuse ni efficace, entre l’unique LED du panneau de contrôle et l’écran haute résolution, il y a un continuum de périphériques de sortie utilisant des signaux lumineux pour former des images. Il faut peut-être alors chercher les systèmes informatiques qui, dans leur usage normal, utilisent d’autres périphériques de sortie ou pas de périphériques de sortie du tout.

L’embarquée, une informatique massivement sans écran

Bien sûr il faut définir le mot « informatique ». Si l’on se réfère à la définition de Wikipédia :

L’informatique est un domaine d’activité scientifique, technique, et industriel concernant le traitement automatique de l’information numérique par l’exécution de programmes informatiques hébergés par des dispositifs électriques-électroniques : des systèmes embarqués, des ordinateurs, des robots, des automates, etc.

Avec cette définition, le moindre dispositif électronique embarqué est de l’informatique. Lancer une machine à laver, programmer son four ou préparer une cafetière pour le lendemain est donc une forme de manipulation informatique… qu’on peut envisager sans écran.

Cependant dès que vient le besoin de développer un système embarqué ou même de le réparer/déverminer, l’écran revient au galop. On a rapidement besoin d’un écran pour y connecter son environnement de développement et sa sonde de debug. Et même l’oscilloscope ou l’analyseur logique que l’on branche pour « voir » les signaux dispose d’un écran.

En usage normal donc, certains dispositifs informatiques sont conçus pour ne pas nécessiter d’écran parce qu’ils disposent d’un autre périphérique de sortie. Certains centres commerciaux, certaines gares proposent des distributeurs d’histoires courtes : trois boutons comme périphérique d’entrée et une imprimante thermique comme périphérique de sortie. Appuyez et vous aurez de la lecture pour une, trois ou cinq minutes.

Soyons optimistes : il n’y aura pas plus de cinq minute d’attente !

Plus courant, une box Internet domestique est aussi un dispositif informatique sans écran.

- Il est où l’écran ? - Dans ton… navigateur

Il faut reconnaître que si l’usage courant, la connexion à l’Internet, ne nécessite pas d’écran sur la box, son paramétrage en utilise bien un : celui de l’ordinateur sur lequel tourne votre navigateur préféré.

Les assistants vocaux sont des ordinateurs sans écran. Les principaux périphériques d’entrée comme de sortie sont audio : commande vocale, réponse également. Radio France fait d’ailleurs la publicité pour son offre pour enfants, une histoire et… Oli, sur cette absence d’écran, jouant, sans trop le dire, sur cette peur parentale des écrans.

Pourrait-on pousser l’utilisation de ces ordinateurs pour faire du développement et «coder en vocal» ? Possible, il est tout à fait possible de programmer l’ouverture de ses volets, la lecture d’une musique ou le thermostat de sa chaudière avec. Mais ça n’est pas du développement.

L’éducation numérique mais sans écran

Il est largement possible d’apprendre l’informatique sans écran, et même sans ordinateur.

La robotique pédagogique se développe depuis l’apparition de la tortue Logo. Actuellement, pour les plus jeunes dès l’école maternelle, c’est une abeille qui est proposée comme initiation à la programmation.

Si, si, je suis bien un ordinateur

La Bee-Bot se programme à l’aide de sept touches et les périphériques de sortie sont les moteurs de déplacement, un petit haut-parleur et en option un porte-crayon. Avec une interface HommeEnfant-Machine aussi simple, il s’agit plutôt d’une mémorisation de séquences de mouvements que de programmation à proprement parler et pour en utiliser toutes les capacités, un interfaçage avec une application ou un ordinateur plus conventionnel est possible, mais on y retrouve un écran ! De nombreux autres robots pédagogiques, un peu plus complexes et performants, existent mais ceux-ci utilisent un écran classique pour accéder à l’interface de programmation.

Quitte à supprimer les écrans autant aller au bout de la démarche et supprimer l’ordinateur dans son ensemble. Des pédagogues ont ainsi inventé l’informatique déconnectée. Un papier, un crayon, ni écran ni matériel comme le jeu du robot idiot. Les esprits chagrins pourraient y voir une solution au manque de matériel des établissements scolaires.
Plus que d’informatique il s’agit en fait d’initiation à l’algorithmie.

Mais peut-on se passer d’écran pour développer ?

Les plages braille

Il existe une catégorie de population qui est contrainte de se passer d’écran pour se servir d’un ordinateur : les aveugles.

Les personnes aveugles peuvent pourtant se servir d’ordinateur, notamment grâce à un clavier spécifiquement développé pour eux nommé « plage braille ». Grâce à ces plages brailles, les aveugles peuvent lire les caractères en braille en touchant une ligne munie de petites pointes pilotés.

Le prix de ces appareils est assez prohibitif pour quelqu’un qui voudrait jouer avec sans en avoir réellement besoin (un geek quoi). C’est pourtant une bonne manière de faire de l’informatique sans écran. Pour le codage informatique, on utilise un braille à huit points au lieu des six habituels ce qui permet d’avoir 256 combinaisons, soit autant que la table ASCII. La table braille informatique actuelle a été approuvée à l’unanimité en 2007 par la Commission Évolution du Braille Français, elle porte le numéro TBFR2007.

Que vaudrait un jeu vidéo développé pour une plage braille ? Et pourrait-on l’appeler jeu vidéo ?

Avec du papier et un stylo/machine à écrire/carte perforé puis scanner

On peut également faire beaucoup de choses un papier un crayon/stylo/pinceau puis le scanner pour qu’il soit utilisé dans l’ordinateur. Ça reste généralement qu’une étape du développement les programmes ne sont pas plus réalisés intégralement sur papier avant d’être intégré à l’ordinateur.

Pour conclure

Avec des écrits comme « la fabrique du crétin digital » et des propos comme ceux de notre ex-ministre de l’éducation, les écrans sont devenus la bête noire de tous les pédagogos.

Mais l’important n’est-il pas de savoir ce que l’on fait avec un écran ? Faut-il vraiment s’acharner à s’en passer ?

Sans doute pas.

Il serait cependant intéressant d’apprendre à se servir d’outils réservés aux aveugles par exemple. Si nous n’avons plus besoin de la vue pour coder, nous pourrions être un peu plus multi-tâches et coder tout en… regardant la télé !

Une histoire, comme il en est tant, hélas, de pratiques anticoncurrentielles dans l’industrie. Oubliez les imprimantes et les tracteurs, cette fois-ci, nous passons à une étape supérieure : les trains. Oui, oui, les trains, vous avez bien lu.

Si les faits se confirment, un constructeur de train polonais aurait été pris en flagrant délit de pratiques anti-concurrentielles.

Sommaire

• Les faits
  • Pourquoi le train est tombé en panne ?
  • Vérifier la date…
  • Surprise matérielle
  • Pas seulement à Wrocław
  • La suite
• Réponse de l’Office des transports ferroviaires (UTK)
  • Liens

Les faits

Au printemps 2022, le premier des onze trains du modèle Newag Impuls 45WE, exploités par la compagnie régionale Koleje Dolnośląskie en Basse-Silésie, est en fin de vie. Leur maintenance est gérée par la société Serwis Pojazdów Szynowych, (SPS), qui a remporté l’appel d’offre, pour un prix total d’environ 5,1 millions d’euros (22 millions de złoty). Cette inspection est obligatoire, après un million de kilomètres. Le constructeur à l’origine des trains, la société Newag, a également participé à l’appel d’offres, mais leur prix était supérieur d’environ 696 000 € (3 millions de złoty).

L’entretien d’un train est une affaire complexe : chaque pièce doit être démontée et envoyée aux fabricants concernés pour ensuite être ré-assemblées à leur retour. SPS effectue l’inspection conformément au manuel fourni, d’environ vingt mille pages. Une fois le premier train remonté, l’ordinateur de bord indique le succès de l’opération et la conformité de l’ensemble. Cependant, les onduleurs ne fournissent pas de tension aux moteurs et le train n’avance pas, sans que personne ne comprenne. Les techniciens de service recherchent, vérifient et re-vérifient les composants, parcourent les instructions – et ne trouvent aucune réponse.

Koleje Dolnośląskie dispose de onze trains Impuls et, selon le calendrier, un autre est en cours de maintenance. Tandis que le premier est toujours immobilisé, le deuxième train arrive, subit la même révision, avec malheureusement, le même résultat. Tout fonctionnait parfaitement avant la maintenance, mais les moteurs refusent de démarrer une fois celle-ci terminée. Pour empirer la situation, le constructeur refuse d’aider.

Nous avons maintenant deux trains à l’arrêt dans l’atelier. Le troisième rate l’inspection en raison d’une panne de batterie, et un quatrième train est envoyé à sa place. La société décide d’utiliser la quatrième pour remorquer une des locomotives en panne. Cependant, une fois connectée à l’une d’entre elle, la nouvelle locomotive s’arrête également, mais la raison semble différente et totalement inconnue.

Pendant ce temps, dans un autre atelier, à Szczecin, une autre locomotive Impuls tombe en panne, dans des circonstances très similaires : elle ne redémarre pas après la maintenance.

Le problème devient si grave que les médias s’en mêlent et relatent l’affaire. Les six trains les plus longs de Koleje Dolnośląskie étant hors service, les horaires doivent être réduits, des trains de remplacement doivent être envoyés, et les passagers s’entassent dans des trains trop courts. Newag explique que les trains sont bloqués par un « système de sécurité », mais rien n’est mentionné dans les pages du manuel.

Chaque journée d’un train immobilisé dans l’atelier coûtant plusieurs milliers de zlotys en pénalités contractuelles, et avec plusieurs trains en attente, la tension chez SPS augmente. Le problème n’étant identifié ni par les mécaniciens ni par les électriciens, quelqu’un finit rechercher des hackers polonais, et contacte le groupe Dragon Sector. SPS prend donc contact avec eux, dont les représentants incrédules finissent par signer le contrat. Le projet est entrepris par des membres de Dragon Sector, spécialement ceux connus pour avoir hackés le BIOS de portables Toshiba — Michał « Redford » Kowalczyk et Sergiusz « q3k » Bazański. Kuba « PanKleszcz » Stępniewicz, qui a de l’expérience dans l’automatisation industrielle, se joint également à l’équipe.

L’équipe se met rapidement au travail et Kuba part en voyage à l’atelier. Une fois sur place, ils reçoivent un train qui ne roule pas, deux ordinateurs de rechange et les fichiers SDK du fabricant de l’ordinateur. Ils commencent par écouter le bus de données CAN (Controller Area Network), mais sans information sur les protocoles, la tâche s’avère ardue. Ils tentent de télécharger le microcode de l’ordinateur de bord, mais la documentation du SDK permet uniquement les mises à jour, pas d’inspecter la version installée.

La première tentative d’utilisation d’une ancienne version du micrologiciel, sur un ordinateur de rechange se solde par un échec : l’ordinateur ne répond plus. Ils trouvent finalement l’interface de débogage sur le dernier ordinateur de rechange, et octet par octet, en extraient la mémoire. L’ordinateur est basé sur l’architecture Infineon TriCore, souvent utilisée dans l’industrie automobile, et les chercheurs finissent enfin par examiner le code en utilisant une version modifiée de Ghidra.

Les travaux avancent doucement, mais l’échéance approche et les trains tombent toujours en panne. Dos au mur, Koleje Dolnośląskie, décide de coopérer avec Newag sur l’entretien des trains en panne, y compris ceux qui, selon l’appel d’offres initial, devaient être entretenus uniquement par SPS. Le contrat devant être résilié d’ici une semaine, les chercheurs se mettent à travailler de plus belle.

Le groupe est enfin en possession de tous les micro-logiciels des trains, autant ceux en état de marche que ceux en panne. Chacun des trains ayant des fonctionnalités particulières et une version différente du logiciel, l’analyse est difficile, mais ils commencent à identifier une piste. Entre un ordinateur en état de marche et un autre en panne, certaines plages de mémoire diffèrent. Une fois corrigées sur un ordinateur en panne, celui-ci démarre enfin. Le test étant effectué sur un ordinateur isolé sur un bureau, il s’arrête dès que le logiciel détecte qu’il manque le reste du train, mais il est prêt à faire fonctionner les onduleurs.

Moins de 24 heures avant la date fatidique, les chercheurs identifient des paramètres supplémentaires pour faire démarrer le train. Malheureusement, le condensateur du dernier ordinateur de bord en état de marche brûle pendant les expériences. Après un nouveau brainstorming et de nombreuses tentatives pour combiner deux ordinateurs endommagés en un seul, le premier est réparé, et à 2 heures du matin, la veille de l’heure apocalyptique, les chercheurs configurent l’ordinateur qui fera démarrer le train.

Un de nos héros monte à bord d’un train (d’une autre compagnie) pour rejoindre l’atelier avec un ordinateur probablement en état de marche devant les représentants des chemins de fer de Basse-Silésie, qui ont annoncé leur visite pour 9h30. Malheureusement, le train que prend le chercheur pour se rendre sur place est en retard. Finalement, dans la matinée, un chercheur équipé d’un ordinateur arrive sur les lieux et le connecte au train en panne. Et celui-ci ne bouge pas… Un autre brainstorming identifie le dernier drapeau oublié et à 8h42 le train parvient enfin à démarrer !

La délégation de Koleje Dolnośląskie, voyant à 9h30 que les trains ont une chance de reprendre vie, ne résilie pas le contrat avec SPS.

Pourquoi le train est tombé en panne ?

Déterminer comment faire démarrer le train ne représentait qu’une petite partie du problème. Il fallait maintenant découvrir pourquoi il était tombé en panne.

Des mois d’analyse et de rétro-ingénierie ont permis de révéler des conditions extrêmement intéressantes inscrites dans le code logiciel de différents trains fournis par Newag. Après des centaines d’heures passées à étudier les codes émis par des dizaines de trains, il a été possible d’identifier des mécanismes provoquant des pannes soudaines dans les trains.

Les valeurs numériques 53,13845 et 17,99011 trouvées dans le code informatique semblaient familières à première vue. Il s’est rapidement avéré qu’il s’agissait de coordonnées GPS, indiquant les environs de la gare de Bydgoszcz Główna, ou, plus précisément, le centre de service PESA situé juste à côté. Bientôt, les coordonnées d’autres services susceptibles d’effectuer des réparations et des inspections de trains en Pologne ont également été trouvées. Ci-dessous, nous montrons le pseudo-code de l’algorithme :

check1 = 53.13845 < lat && lat < 53.13882 && 17.99011 < long && long < 17.99837 ;
check2 = 53.14453 < lat && lat < 53.14828 && 18.00428 < long && long < 18.00555 ;
check3 = 52.17048 < lat && lat < 52.17736 && 21.53480 < long && long < 21.54437 ;
check4 = 49.60336 < lat && lat < 49.60686 && 20.70073 < long && long < 20.70840
&& (this->lock_function_test & 1) ;
check5 = 53.10244 < lat && lat < 53.10406 && 18.07817 < long && long < 18.08243 ;
check6 = 50.12608 < lat && lat < 50.12830 && 19.38411 < long && long < 19.38872 ;
check7 = 52.77292 < lat && lat < 52.77551 && 18.22117 < long && long < 18.22724 ;

Les paires de coordonnées définissent les zones d’atelier. Il existe une condition inscrite dans le code informatique qui exige que le train soit désactivé s’il passe au moins dix jours dans l’un de ces ateliers. L’un des ateliers appartient à Newag lui-même - mais une condition logique différente a été définie pour ses coordonnées, probablement à des fins de test.

D’autres surprises furent bientôt découvertes. Il s’agissait notamment du blocage du train lorsqu’un de ses composants (vérifié par son numéro de série) était remplacé. Une option permettant d’annuler le verrouillage a également été découverte — cela ne nécessitait pas de définir des indicateurs au niveau de la mémoire de l’ordinateur, mais uniquement la séquence appropriée de clics sur les boutons dans la cabine et sur l’écran de l’ordinateur de bord.

Lorsque les informations sur le lancement réussi des trains Impuls sont parvenues aux médias, les trains ont reçu une mise à jour logicielle qui supprimait cette possibilité de « réparation ». Un code a été trouvé sur un autre train lui indiquant de « casser » après avoir parcouru un million de kilomètres.

Vérifier la date…

Une situation assez cocasse a été rencontrée dans une autre escouade qui a refusé de démarrer, le 21 novembre 2022, alors qu’elle n’était pas sur place à ce moment-là. L’ordinateur signale une panne du compresseur, les mécaniciens n’ont, pourtant, identifié aucune panne sur le compresseur. Les pantographes ne fonctionnant toujours pas, l’analyse du code informatique a détecté une condition de crash suivante, qui signalait une panne de compresseur :

si le jour est supérieur ou égal au 21 et
si le mois est supérieur ou égal à 11 et
si l’année est supérieure ou égale à 2021

La situation était amusante, car le train devait être inspecté en novembre 2021 (un an avant la panne), mais par coïncidence, la condition n’a pas fonctionné. Le train a été entretenu un instant plus tôt et n’a été relancé qu’en janvier 2022 - et cette date ne répondait plus à la condition logique sophistiquée décrite ci-dessus. C’est probablement l’incapacité de l’auteur du logiciel à écrire correctement des conditions qui a obligé à attendre le 21 novembre 2022 pour que l’on puisse constater l’effet prévu.

Surprise matérielle

Les surprises ne se cachent pas seulement dans les logiciels informatiques. Dans l’un des dépôts, les chercheurs ont découvert un dispositif signé comme « convertisseur UDP / CAN », permettant vraisemblablement une communication à distance avec le train. Le supprimer n’a pas empêché quoi que ce soit de fonctionner. L’analyse a montré que l’ordinateur de bord envoyait des informations sur l’état du verrouillage à cet appareil et que l’appareil lui-même était connecté à un modem GSM.

Pas seulement à Wrocław

L’information selon laquelle le service SPS avait réussi à réparer les trains Newag « cassés » est rapidement parvenue à d’autres services. Cela s’est avéré être un problème assez courant. À Wrocław, ils ont analysé 13 rames Impuls, mais celles qui circulaient à Koleje Mazowieckie sont également tombées en panne (une unité), deux à Opole, quatre à Cracovie, une à Zielona Góra, quatre à Szczecin et une à SKM. Heureusement, chacune a été réparée à l’aide d’un outil développé par nos chercheurs, qui supprime les verrous logiciels de l’ordinateur de bord. Au total, nos collègues ont analysé le logiciel de 29 trains, et seulement cinq ont trouvé des surprises allant au-delà des instructions d’exploitation officielles.

La suite

Nous laissons l’évaluation des solutions utilisées par le fabricant aux lecteurs et clients de cette entreprise. Il est intéressant de noter que, même si des poursuites judiciaires sont en cours, il est difficile de trouver en Pologne une institution qui ferait autre chose qu’exprimer un intérêt amical dans cette affaire.

Nous n’avons connaissance d’aucune mesure prise par « l’Office de la protection des consommateurs et de la concurrence », ni par « l’Office du transport ferroviaire », qui semble pourtant appropriée. Cette dernière à pour rôle de surveiller les pratiques des sociétés qui travaillent avec les organisations gouvernementales locales. Que des voyageurs aient subi des désagréments ou forcés à utiliser des transports alternatifs pendant des mois semble pourtant éligible à un dédommagement.

La seule institution connue à avoir pris des mesures est le CERT Polska, qui a été informé de la découverte par les chercheurs. Le commentaire que nous avons reçu montre que CERT Polska a informé les « autorités compétentes » et que l’affaire est traitée par les autorités chargées de l’application de la loi.

Nous félicitons les meilleurs hackers polonais pour leur découverte intéressante et l’exécution professionnelle de la commande. Décidément rien n’est plus motivant qu’une date limite demain matin.

L’article ci-dessus n’est qu’un bref résumé de la présentation donnée lors de la conférence Oh My H@ck le 5 décembre 2023 par les membres de l’équipe : Jakub Stępniewicz, Sergiusz Bazański et Michał Kowalczyk. L’article a omis de nombreux détails et une grande partie technique de l’analyse — nous ne pouvons qu’espérer que cela motivera les auteurs de l’étude à rédiger et publier son cours. Mis à jour le 05/12/2023 à 16h00

Réponse de l’Office des transports ferroviaires (UTK)

Nous avons reçu la position officielle de l’Office des transports ferroviaires (UTK), que nous citons intégralement ci-dessous :

Le président de l’UTK est au courant de l’affaire et a vérifié les informations concernant les analyses effectuées sur les logiciels des véhicules ferroviaires et coopère également avec les services compétents à ce sujet. En collaboration avec CERT Polska (une équipe créée pour répondre aux incidents violant la sécurité Internet), une réunion avec le constructeur ferroviaire a été organisée. Les véhicules répondent aux exigences essentielles précisées dans les dispositions des directives européennes. C’est la personne qui commande le véhicule qui détermine les conditions de service et de garantie dans le cadre de la liberté contractuelle. Ces exigences sont incluses dans les contrats d’achat de trains. Toute limitation des capacités de service, y compris les limitations introduites dans le logiciel, peut constituer un éventuel litige civil entre le client et le fabricant. Le président de l’UTK n’est pas l’autorité compétente en la matière.

Conformément à l’art. 41 alinéa 2 de la loi du 5 juillet 2018 relative au système national de cybersécurité (texte consolidé : Journal des lois de 2023, articles 913, 1703), l’autorité chargée de la cybersécurité du secteur des transports (hors sous-secteur du transport par eau) est l’autorité compétente en matière de cybersécurité.
Ministre chargé des questions de transports.

Liens

• Newag_Impuls (pl)
• Infineon_TriCore (en)
• Ghidra (en)
• CERT Polska (en)
• journal LinuxFr.org
• BadCyber Dieselgate, but for trains – some heavyweight hardware hacking (en)
• 404media Polish Hackers Repaired Trains the Manufacturer Artificially Bricked. Now The Train company is threatening them (en)
• l’histoire par un ses hackers (en)
• HackADay The Deere Disease Spreads To Trains (en)