Pensons l’objet roulant au delà de l’objet roulant
Quels standards transversaux et ouverts pouvons vous identifier et lancer le développement dés le début de la saison d’idéation ?
Pensons l’objet roulant au delà de l’objet roulant
Quels standards transversaux et ouverts pouvons vous identifier et lancer le développement dés le début de la saison d’idéation ?
Bonjour,
La question est très vaste…
Si la question est : « Que faut-il décrire pour que tout un chacun puisse créer un véhicule », je dirais qu’il faut faire un Cahier des Charges fonctionnel minimal qui permette au véhicule de remplir le minimum de fonctions qu’on attend de lui, de lui assurer un fonctionnement correct et fiable, et de répondre aux éventuelles questions d’homologation.
ce n’est pas tout a fait la question en effet.
mais plutot qu’est ce qui est commun dans les divers « cahiers des charges » des concurrents qui beneficieraient d’un travail transversal en commun en vue d’augmenter la résilience économique et industrielle des projets :
économies d’echelle,
valeur ajoutée utilisateur (customisation, localisation),
modularité inter engin,
maintenabilité facilitée (tracabilité, données de fiabilité), etc…
autrement dit éviter de réinventer la roue la ou il n’est pas nécessaire de se distinguer.
quelques idées que l’on pourrrait avoir, sans préjuger de leur valeur…
Si on prend l’exemple du moteur, les fournisseurs vont proposer 4 modules :
Il va y avoir des projets « basiques » qui vont acheter le package complet, et des projets plus évolués qui vont vouloir rajouter un composant spécifique, voire modifier un composant.
Je pense qu’il est intéressant d’avoir une liste des moteurs (et composants) associés à leur degré d’ouverture (connectique standard …), ouverture du code source du calculateur, continuité de la clause de garantie si modification …
c’est un bon exemple…
on voit deja certains fournisseurs aasiatiques offrir des controleurs dont le firmware est « ouvert » et facilement reprogrammable (il faut que je retrouve la réference) et cela semblerait tout benef de pousser cette logique jusqu’au bout, l’open source semble une évidence, mais. demande un peu de travail.
la batterie, est une sujet riche en lui même/ à décomposer en cellules, voltage / amperage entrée sortie, BMS, geometrie de la batterie; prises, protocoles de charge et plus encore. des acteurs travaillent sur le sujet de façon innovante et tres interesssante amha,…; gouach, et otonohm pour ne citer que ceux que je connais
la transmission est au coeur de l’engin, et c’est plus difficille de savoir a priori ce qui serait bénéfique, souhaitable, meme si on peut deviner qu’une transmission « by wire » est a promouvoir si on garde une part d’energie musculaire.
tiens je pose ces 2 sources d’inspiration là :
https://wiki.lafabriquedesmobilites.fr/wiki/Open_source_Electronic_Speed_Controller_ESC
Pour la transmission, il faut 2 choses :
D’un point de vue coût/fiabilité/facilité de mise en oeuvre/bruit, le plus simple est une tramsission par courroie.
Avec un moteur électrique, un rapport de transmission fixe est suffisant.
si on met le/ les moteurs dans la/les roues, on peut même se passer de transmission…
Quand sait on si on a vraiment besoin d’un différentiel ? y a t’il une regle ??
peut on avoir un differentiel « electronique » qui donnes des tensions distinctes aux roues motrices ?
dans quels cas peut on s’en passer ?
Par exemple sur mon tricycle couché biplace, à propulsion ( la roue unique du tricycle a géometrie tadpole / crapaud est motrice ) il n’y a bien sur pas de différentiel sur le train avant (qui a 2 roues donc) qui n’est pas moteur…
mais bon on s’éloigne du sujet original je crois…
Différentiel : C’est obligatoire.
Moteurs roue :
Le véhicule risquant d’être relativement lourd, je recommande un véhicule suspendu.
Homologation :
5 catégories possibles :
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000039478722/
En complément, ce qu’il faut faire pour que le véhicule soit conforme :
merci Emmanuel @manu928 pour ces infos précieuses sur l’homologation, qui est un autre sujet au coeur du Défi bien sur.
En particulier le document récapituatif est super intéressant, cela fait un moment que je cherchais quelque chose comme cela.
une question cependant, RTI, c’est pour une réception « a titre isolé », autrement dit a l’unité. est ce que les exigences changent pour une serie, petite ou grande?
Merci d’avance
Je vais creuser le sujet.
Le doc que j’ai trouvé semble ancien. Je vais voir si il est toujours à jour.
Les exigences sont basiquement les mêmes.
La RTi a certaines dispenses.
La base est quand même de construire un véhicule en construisant une « copie documentaire » du véhicule : caractéristiques techniques, n° des pièces, n° d’homologation de PV de réception s’il y a lieu …
Ensuite, il faut démontrer de la rigueur dans les processus, un processus qualité qui assure la conformité à la réception, des outils de traçabilité individuelle des véhicules, l’enregistrement des coordonnées des clients …
En fonction du volume, il faudra pouvoir montrer des dossiers de plan, des notices d’assemblage et de maintenance et des notes de calcul de plus en plus élaborés.
bonjour,
J’ai regardé un peu cela :
Je n’ai pas de doute sur le fait que cela fonctionne.
Par contre, il n’y a aucune documentation fonctionnelle :
Tout cela est nécessaire pour s’approprier le projet et l’intégrer dans son véhicule (avec ou sans modification).
Cela sera aussi nécessaire pour la réception.
Il faudra être capable de faire cette description fonctionnelle.
Suite à réunion de ce jour, une réflexion sur l’open source :
L’homologation assure 2 choses :
L’homologation est liée à l’entité de fabrication.
On peut très bien imaginer une association qui va gérer le « plan » (du type de ce qui se fait dans les projets informatique firefox, debian, … ou alliance LoRa, Zigbee …)
Dans l’automobile, il y a l’association GALIA qui génère des standards de travail qui s’appliquent à l’industrie automobile.
→ **Il faudrait une évolution des réglementations permettant l'homologation de ce plan**
Ensuite, il faudra une homologation par unité de fabrication.
Afin d’assurer la traçabilité, il faudrait demander aux unités de fabrication de s’enregistrer en tant que tel auprès de l’association. L’association pourrait gérer une attestation de conformité au plan.
GALIA fait cela et certifie des ERP qu’elle assure conforme aux standards développés.
→ **On peut aussi imaginer que cette association ait une délégation totale ou partielle de l'homologation des unités de production et des produits qui en sortent.**
Merci Emmanuel @manu928 c’est super intéressant et encourageant en effet. Je ne connaissais pas GALIA.
tout a fait d’accord, c’est une exemple, pas forcément exemplaire
le VRAI open source demande plus que juste publier du code ou des fichiers sur un Github i faut le faire en faisant de gros efforts pour que d’autres puissent se l’approprier, gros effort de clarté, de documentation, etc… il y a très peu (voire pas) d’exemples exemplaires dans notre domaine que je connaisse. peut etre les gros projets open source automotive comme automotive LINUX ou Genivi ou encore Apollo ?
En y reflechissant, on fait de l’open source dans l’industrie auto depuis 40 ans
On a définit des dimensions et caractéristiques de bacs plastiques standards qui sont fabriqués par quelques fournisseurs de bacs et achetés et utilisés par Renault, PSA et l’ensemble des fournisseurs de pièces.
faire de la standardisation ou de l’interoparabilité oui,open source je crois pas vraiment. a moisn que je puisse trouver les plans et caracterisitiques de ces bacs de façon libre et ouverte…