Publié le 27 juin 2016 - par

Raspberry Pi et Arduino dans le monde industriel

Panel-PC_250pxCeux d’entre vous qui ont suivi une des conférences/ateliers sur le Raspberry Pi que j’anime ont pu constater que je présente des utilisations du Raspberry Pi qui vont au delà du simple loisir.
Parmi les applications, un banc test industriel pour le test en production de systèmes automatisés de couverture de piscine, ou encore le remplacement de PC par des terminaux légers qui sont en fait des Raspberry Pi…

Le Raspberry Pi et l’Arduino en milieu industriel

Les terminaux légers

raspi_montceauphoto_08Un des exemples que je présente est celui de l’Hôpital de Montceau-les-Mines (71) qui a remplacé les PC partout où c’était possible. Ont été conservés en particulier les PC auxquels sont connectés les lecteurs de carte vitale, ou ceux qui lisent les CD/DVD des scanners, IRM…

Pour le reste… Ce sont plus de 100 Raspberry Pi qui équipent les postes de travail. En plus de l’économie financière, de l’homogénéité du parc qui facilite grandement la maintenance, je vous laisse calculer le gain en empreinte carbone et en note d’électricité quand on remplace 100 PC (dont on arrondit la consommation à 100 watts) par 100 Raspberry Pi (dont on arrondit la consommation à 2 watts)…

Vous pouvez retrouver certaines de ces applications dans un article sur framboise314.fr. Elles sont des exemples d’intégration du Raspberry Pi dans un milieu pour lequel il n’était pas conçu à l’origine.

Arduino devient un automate programmable

Je passe pas mal de temps à fouiner sur les sites pour dénicher les nouveautés, mais là c’est une vraie application industrielle de nos cartes préférées que j’ai découverte.

face_avantC’est sur le site de la société Industrial Shields, située près de Barcelone, que sont proposés des produits à visée réellement industrielle. Si vous pratiquez l’automatisme industriel vous connaissez les contraintes techniques/de sécurité/de programmation que soulève la mise en œuvre des automates programmables.

Les modules industriels

PLC-ARDUINO-M-DUINO-58-DIG-1Industrial Shields propose une gamme résolument industrielle, entrées numériques opto-isolées, sorties sur relais, communication industrielle (RS232, RS485, MODBUS, Ethernet…).

La face avant des équipements est munie de LEDs qui permettent de contrôler l’état des E/S, les connexions se font sur de solides borniers et les modules se clipsent sur un rail DIN comme celui qui équipe le fond des armoires électriques.

PLC-ARDUINO-M-DUINO-58-DIG-3Le modèle ci-dessus est le plus complet, mais il existe en fait toute une gamme de produits bâtis autour de l’Arduino :

gamme_02Les différents modèles proposent des solutions allant d’une quinzaine d’E/S à près de 60 E/S… Le tout dans un format adapté aux installations industrielles.

PLC-ARDUINO-M-DUINO-58-DIG-5PLC-ARDUINO-M-DUINO-58-DIG-2

Système compact

Ci-dessous une ArdBox Relay qui comporte

10 Entrées (5-12-24Vcc)

Analogiques (0-10Vcc) et numériques (5-12-24 Vcc)

10 Sorties (5-12-24Vcc)

Analogiques (0-10Vdc) et numériques/PWM (5-12-24Vcc)

Communication USB, RS485, RS232, I2C, SPI

PLC-ARDUINO-ARBOX-RELAY-20-5Les documentations sont bien entendues fournies et les diverses notices téléchargeables en ligne.

ARBOX-004-001-70-Relay

Cliquez pour aller sur la page d’origine

Exemple de réalisation

Sans titre 7Cette machine d’étiquetage automatique a été réalisée avec le matériel proposé par Industrial Shields :

  • Un M-Duino PLC: Ce contrôleur est le cœur du système. Il contrôle l’affichage, génère les interruptions et gère la communication.
  • Un Panel PC: Utilisé pour l’affichage de l’état du système (voir chapitre ci-dessous)
  • Les capteurs: La machine utilise des capteurs infrarouges de type « fourchette » facile à interfacer et dont la sensibilité est réglable par potentiomètre.
  • Un moteur: Utilisé pour entraîner la courroie du convoyeur à vitesse constante.
  • Un relais: Utilisé pour activer le système d’étiquetage.

Raspberry Pi équipe une console industrielle

gamme_01A côté de sa gamme de produits à base d’Arduino, j’ai eu la surprise de retrouver notre framboise intégrée à un écran de contrôle industriel. La preuve (si besoin en était) de la fiabilité de la petite carte Raspberry Pi…

Panel-PC_600px
Cet écran tactile est basé sur un Raspberry PI 3 et comporte un écran tactile 10,1 pouces. c’est sans doute le premier écran 10,1 pouces sous Linux utilisant un Raspberry Pi dans le domaine du contrôle industriel.
Ce Panel PC est équipé d’un / système d’exploitation GNU Linux  intégré à une carte SD. C’est un PC pouvant gérer toutes sortes de connexions : Ethernet, USB, wifi …
L’ensemble du système stocké sur carte SD permet de configurer des machines très facilement, grâce au clonage.

TOUCHBERRY-PANEL-PC-2

En production il est possible d’utiliser le port Ethernet pour recevoir, à distance, des informations sur l’état du système et de tous les paramètres, les données, les entrées/sorties… Il est aussi possible de commander le système à distance.

logo_industrial_shields

Le Touchberry PI peut se connecter à tous les systèmes fournis par Industrials Shields pour assurer un contrôle industriel complet de tous les équipements, machines, installations, etc.

Pour des processus complexes il est possible d’interconnecter différents Touchberry PI. Cela permet d’automatiser une usine de production et de disposer de toutes les données nécessaires à tout moment.

Vidéos

Conclusion

Cette gamme de matériel pourra intéresser ceux qui souhaitent réaliser une installation domotique fiable.

Cependant la qualité de fabrication plus le fait qu’on soit en présence d’E/S de qualité industrielle (opto isolation, boucle sèche…) devraient intéresser tous ceux qui travaillent dans le monde industriel et qui souhaitent intégrer dans leurs machines des Arduino ou des Raspberry Pi. Pas seulement parce que c’est rigolo, mais parce qu’on voit que ces cartes utilisées dans le monde des loisirs, des makers, ont tout à fait leur place dans le milieu professionnel, ô combien plus exigeant que celui qui a fait leur succès !

Si vous utilisez Arduino ou RasPi dans une application industrielle, n’hésitez pas à me contacter si vous souhaitez faire profiter la communauté de votre expérience 🙂

Sources

Downloads

Solar Monitoring System with Ardbox

 

 

 

 

Share Button

À propos François MOCQ

Électronicien d'origine, devenu informaticien, et passionné de nouvelles technologies, formateur en maintenance informatique puis en Réseau et Télécommunications. Dès son arrivée sur le marché, le potentiel offert par Raspberry Pi m’a enthousiasmé j'ai rapidement créé un blog dédié à ce nano-ordinateur (www.framboise314.fr) pour partager cette passion. .

32 réflexions au sujet de « Raspberry Pi et Arduino dans le monde industriel »

  1. antoin

    « (dont on arrondit la consommation à 100 watts) par 100 Raspberry Pi (dont on arrondit la consommation à 2 watts) »…faut pas oublier que le pi est connecté à un écran qui consomme des watts. L’économie est substantielle mais n’est pas dans un rapport de 50.

    Répondre
    1. François MOCQ Auteur de l’article

      bonjour
      c’est vrai si on prend en compte l environnement (faudrait ajouter le clavier, la souris, l’imprimante ???? )
      mais pour la partie qui nous intéresse, le remplacement du PC on passe bien de 10 Kw à 200w de gain de consommation… je n’ai pas parlé de pourcentage mais de « note d’électricité » 😀
      et… 9800 watts c’est pas rien !
      cordialement
      François
      ps pour la conso du PC standard je me suis basé sur http://www.energieplus-lesite.be/index.php?id=11455

      Répondre
  2. msg

    Bonsoir ,
    PLC en anglais , sinon en français c’est un API (Automate Programmable Industriel)

    Je n’ai pas vu d’interface de programmation en LADDER ou en GRAFCET .
    Faut-il se contentet de la programmation Arduino pour imiter le fonctionnement d’un API ?

    J’ai vu des exemples avec des commandes directe de sortie suivis de commande DELAY .
    Si c’est ça la programmation proposée , alors c’est pas gagner car un API ne fonctionne certainement pas comme cela et ce type de matériel ne sera pas plébiscité par les automaticiens pur et dur .
    Difficile dans ces conditions de faire une application multitache .

    Répondre
    1. François MOCQ Auteur de l’article

      Bonjour msg
      un automaticien peut être pas ? quoique…. il y a bien un proc. dans un automate et on peut aussi les programmer en C (même si en indus c’est moins apprécié pour des raison de sécurité )
      pour ma part j’ai bossé en info indus (sur Telemecanique et Siemens entre autres)
      et je pense qu’un bureau d etudes qui développe une machine spécifique peut très bien utiliser ce genre de matériel pour l’équiper
      l’an passé j’ai été en contact avec un de mes anciens stagiaires qui travaille dans une (très) grande entreprise industrielle mondiale -que je ne peux pas citer- et qui a développé une interface homme machine à base de Raspberry Pi….
      Une autre entreprise locale qui fabrique des cartes pour le médical (avec toutes les contraintes de certification que ça impose) utilise… un Raspberry Pi pour contrôler les gradients de température tout le long du système de soudage des CMS
      cordialement
      François

      Répondre
      1. msg

        Bien entendu qu’un programme d’automate peut être écrit en C comme en Pascal ou en Python , mais il ne sera compréhensible que par son auteur et par des personnes venant de la programmation informatique .
        La difficulté pour ces types de programmeurs , c’est d’écrire un code qui respecter les contraintes de fonctionnement et de sécurité des API dans un environnement en temps réel .

        Je ne doute pas qu’il soit possible de créer un API directement à partir d’une simple carte RPi , il suffit d’utiliser des registres à décalage à commande SPI et de mettre une base de temps externe pour donner le tempo , la seule difficultée après c’est de faire les cartes d’interfaçage E/S fiables et d’assurer le fontionnement en temps réel des temporisateurs internes .
        Une solution que j’ai envisagé sinon , c’est d’associer le RPi (interface homme-machine) avec une carte E/S gérée par un CUBLOC , CB210 ou autre .
        http://www.comfiletech.com/

        Répondre
        1. PYM

          Bonjour,

          Tout dépend aussi des temps de cycles que votre machine ou process impose.
          sur un process lent, c’est parfait, le temps réel est tout relatif … si on est à la seconde, sur une machine d’une centaine d’E/S … c’est bon à mon avis.
          Les aspects communication wireless sont intéressants à exploiter et compris dans le prix.
          La programmation en C n’est pas un réel problème … la différence est minime avec un langage structuré proposé par la norme IEC 1131-3 utilisées par la plupart des fabricants d’API.
          En ce qui me concerne, la problématique est matérielle. J’aimerais en effet utiliser un Raspberrry PI avec des E/S rattachées en USB par exemple

          Répondre
  3. franck

    soyons charitable !!
    l’idée est interessante mais linux en millieu industriel -> certainement pas.

    le pi n’est pas une carte electroniquement industrielle
    et toujours pour celui qui se revendique industriel, il n’y a pas d’USB dans ce monde.

    MODBUS et eventuellement ZIGBEE pour le sans fil
    ni USB ni WIFI.

    le bon coté maintenant oui, c’est plaisant comme interface de commande, disons domestique et qui n’implique pas la securité des personnes

    Répondre
    1. Erwann

      Nous n’avons sans doute pas les mêmes références ni un vécu comparable. Linux fait très bien l’affaire (et même mieux que Windows).
      Au niveau de la communication de terrain, cela fait déjà un bon nombre d’années que le WiFi est proposé et utilisé.
      L’avantage que je vois à un port USB est la facilité et la standardisation de la connectique pour charger des programmes, débugger, connecter un panel opérateur en local (si pas en Ethernet) voire mettre implémenter des convertisseurs pour des bus non natifs (par exemple CAN).
      Concernant la programmation, il semblerait que quelque chose soit proposé : Ladder. IEC-1131. Sinon, c’est un excellent sujet de projet pour des étudiants en Master ou des élèves ingénieur ! …

      Cet article est une excellente et intéressante nouvelle !

      Répondre
  4. François MOCQ Auteur de l’article

    Un extrait de http://www.industrie-techno.com/12-automates-programmables-polyvalents.18932
    … Reste que la citadelle du logiciel propriétaire commence à se fissurer. « Nous sommes les seuls sur le marché à offrir de paramétrer et de programmer nos automates aussi bien avec l’atelier logiciel de Siemens, Step7, qu’avec le nôtre, WinPLC7 », avance Alain Sadones, de Vipa France. Une interopérabilité qui ne manquera pas d’attirer les acheteurs, toujours soucieux de diversifier leurs approvisionnements. Dans cet esprit, le fabricant Leroy mise sur le système d’exploitation Open Source Linux. « Au départ, nous l’avons fait à la demande d’un client », rappelle Patrick Lalla… qui espère bien mettre à profit sa simplicité dans ses prochaines générations d’automates. À la clé, un gain de temps en développement. Et un cheval de Troie dans la forteresse des logiciels propriétaires.
    Les API embarquent sans cesse plus d’intelligence
    Côté services Acquisition et traitement de données, régulation, contrôle et commande d’actionneurs, calcul, automatismes, cinématique, optimisation des réglages et des procédés, communication réseaux vers les bus de capteurs actionneurs, vers les bus de terrain et les réseaux Ethernet IP (Industrial Protocol)… les API de milieu de gamme fournissent des services très larges. Côté performances Ils embarquent des modèles mathématiques très avancés en matière de commande prédictive et de sécurité. Ces fonctionnalités proviennent de la standardisation, à l’intérieur d’une marque, du logiciel embarqué et de l’atelier logiciel de programmation. Sous la pression des donneurs d’ordres, on voit apparaître des systèmes d’exploitation embarqués sous Linux.
    Industrie & Technologies 09/2009

    Répondre
  5. Ping : Raspberry Pi et Arduino dans le monde industrie...

  6. Bud Spencer

    Ne masquons pas la réalité en faisant abstraction de détails importants. Le PI dans l’entreprise ou dans l’industrie, tant que ça reste dans le cadre d’un client léger ou d’un de l’écran de supervision d’une IHM, pas de soucis, mais de là à vouloir en faire un ordinateur de bureau ou le cœur d’un automate, c’est peut-être un peu optimiste (du moins, à l’état des versions actuelles). D’ailleurs si on lit bien l’article, on voit que cet hôpital utilise ses PI uniquement comme clients de bureaux à distance. Quant aux automates présentés, ils ont tous un cœur Arduino et seul l’écran d’IHM utilise un PI. Franck a tout à fait raison et je partage son avis. La fiabilité d’un automatisme industriel repose principalement sur un system RTOS or linux n’en est pas un.

    un peu de lecture intéressante.
    http://www.on-time.com/rtos-32-versus-linux.htm

    Répondre
    1. msg

      Sur les anciens API , peut-être encore sur les API récents , la durée limite pour effectuer un SCAN programme était de 10ms , sans quoi l’API détecte un ralentissement puis se met en défaut sécurité .

      1 SCAN programme équivaut :
      – à la lecture des toutes les entrées
      – au traitement logique de toutes les lignes du programme
      – à l’écriture de toutes les sorties avec éventuellement changement d’état ..

      Qu’est-ce qui empêche d’utiliser une base de temps externe pour donner ce top de SCAN ?
      Sur la plus part des circuits d’horloges RTC , il est possible de paramétrer la sortie INT pour impulser ce signal .

      Le RPi ne serait-il pas assez rapide pour lire un changement d’état sur l’une de ces entrées pour un signal de 100Hz ?

      Répondre
    2. Erwann

      Serait-il possible de revenir aux fondamentaux ?
      Dans les années 80, un API tournait – dans le meilleurs des cas – sur des MC68000 à 16 ou 20 MHz.
      Quelque soit les limites de performance d’un RPi et des exigences « temps réel » (de quelques ms pour un API), un RPi 2 ou 3 est très largement plus puissant que le bon vieux MC 68000.
      Linux peut être configuré de manière à présenter une latence la plus faible possible : utilisation de noyau Low Latency, épuration de la configuration de base (suppression des services inutiles, chronophages ou trop gourmand en ressources).
      En 1989, j’ai vécu une des premières implémentations de SNCC (DCS) sur une base de MC68020 à 20 MHz avec VxWorks comme OS temps réel (nous étions alors les premiers clients européens de Wind River qui était totalement inconnu à l’époque). La visualisation du processus (sous X11) ainsi que l’archivage des données process étaient réalisés par des stations de travail HP9400 (MC 68030 à 33 MHz) sous HP-UX 7.x (et suivants). Il s’agissait de systèmes de contrôle en production chimique (>2’000 I/O).
      Depuis que j’ai découvert la Framboise, je rêverais de pouvoir porter ce SNCC sur cette plateforme pour les contrôleurs process avec la visualisation et l’enregistrement des données process sur PC sous Linux. La puissance de calcul d’une telle configuration est sans commune mesure avec la configuration des années 80/90.

      Répondre
  7. franck

    je clarifie ma pensée :
    LINUX n’est pas un systeme temps réel, les tentatives de le faire comme le patch prempt-rt, ou encore depuix l’exterieur avex xenomai sont des tentatives louables, et meme avec des temps de l’ordre de 100 micro secondes pour le second mais ce sont des temps non garantis.
    voir les nombreux articles de christophe BLAESS et livres.

    pour de l’industriel on prendra un RTOS sur un microcontroleur.

    l’usb n’est pas un bus de terrain.

    quant au wifi, vu le bricolage que represente le « reseau », pour acheminer des données de façon fiable, c’est compliqué.
    il faut une adresse ip totalement factice puisque c’est la MAC qui gere, sans parler des des nombreuses demandes ARP -> hey , c’est qui 192.168.0.4, merci de me donner l’adresse MAC car l’adresse IP ne me sert a rien, c’est une adresse qui ne me permet pas d’atteindre mon point d’arrivé !!!

    plus serieyusement, sortons de la caricature, avec un taux de 0.7% d’efficacité, 100 octets de protocoles pour acheminer un pauvre octet de donnée.

    le millieu industriel ne peut utiliser linux et dormir la nuit !!!
    au pire des linux reduit a la partie OS, mais la encore, il y a cette terrible mmu obligatoire et donc un micro-processeur avec l’atroce bus ram externe et des temps de demarrage affreux.
    sans parler de la cem.

    en revanche, l’arduino, qui est un microcontroleur, peut tout a fait faire du temps réél,
    je crois que c’est un ATMEL appartenant aujou’d’hui a son concurent MICROCHIP.
    je en sais pas ce que vaut cette carte niveau hardware, mais en tout cas en industriel
    -> arduino POSSIBLE
    -> pi INTERDIT

    maintenant sortez la hache pour me taper dessus, j’ai volontairement exagéré ma pensée pour que chacun comprenne mieux ce que je voulais dire plus haut.
    je terminerai en disant que j’utilise des pi, mais PAS pour des truc serieux, c’est une bellle machine
    qui fait enormement de chose, avec de grosses performances mais pas en temps reel.

    Répondre
    1. Bud Spencer

      CQFD.
      Beaucoup de gens confondent vitesse et constance de temps mais aussi supervision et logique de traitement. Un PI sous linux sait tout à fait lire et écrire sur ses E/S très rapidement et est tout à fait capable de toutes les traiter dans des cycles bien inférieurs à 10 ms même avec un vieux PI de toute première génération. En revanche il est incapable de la faire en garantissant qu’un même traitement pourra s’exécuter plusieurs fois avec exactement le même temps d’exécution. Ce n’est pas un problème lié à l’OS lui-même, c’est juste que fondamentalement, il n’est pas fait pour ça. En revanche, Utiliser linux pour superviser un système automatisé ne pose pas de problème, mais là, on ne parle plus du tout de la même chose. Toutes les machines industrielles ont aujourd’hui un micro de supervision qu’il soit sous linux, windows ou je ne sais quoi d’autre, mais ils ne font que dialoguer avec un vrai automate et c’est ce dernier qui fait le boulot sur ses propres E/S.

      Répondre
  8. lolo

    Bien sûr que Linux peut et EST utilisé dans l’industrie, et massivement qui plus est !!!
    Ce n’est que peu de reconnaissance et de considération pour tous les spécialistes du secteur (Free Electrons, Linaro etc…).

    Pourquoi le milieu industriel pour vous impose systématiquement le recours à un OS temps réel dur ?
    Ne pas confondre besoin en temps réel et OS temps réel ! Un OS classique peut parfaitement répondre en temps réel à un besoin donné, pour peu qu’il soit bien défini.
    Un Linux tout à fait normal a parfaitement sa place, et détrône même des OS propriétaires temps réels sur leur propre terrain (j’ai personnellement vu un acteur industriel majeur remplacer QNX par du Linux sur beaucoup de leurs calculateurs).

    Les raisons sont parfaitement simples :
    1 – Réduction des coûts (licences, mais pas que : développer sur un OS temps réel est coûteux car nécessite formation, technique et tests appropriés)
    2 – Augmentation des performances du hardware (le silicium sera toujours moins cher que le coût de développement)

    Mais certes, souvent, le besoin en temps réel dur est là, alors les fondeurs intègrent de plus en plus des architectures hybrides pour mixer dans un même SoC, coeur ARM type Cortex A et FPGA ou microcontrôleur ARM type Cortex M. On segmente ainsi le développement applicatif basique avec le développement critique temps réel et une modification dans l’un n’impose pas des contraintes à l’autre. L’exemple typique est l’interface utilisateur d’un côté (au sens large : IHM, réseau, terminal, webservices) et le contrôle/commande de l’autre.

    Pour en revenir au sujet (bravo à l’auteur pour l’article au passage), à savoir : le raspberry pi dans le monde industriel.
    Je dirais qu’au jour d’aujourd’hui, il est déjà possible d’utiliser un Raspberry Pi en lieu et place d’un PC vieillissant (qui ont leur place à certains postes en milieu industriel : terminal, console, etc…). Pour ce qui est de l’utilisation en tant que calculateurs ou automates, la prudence est de mise.
    Tout d’abord il convient de ne pas utiliser une distribution grand public (comme Raspbian, basée sur Debian) et même cette précaution prise, la carte SD comme support rend la solution rédhibitoire dans certaines applications (vibrations, contraintes de température, fiabilité et performances du support par rapport à de l’eMMC).
    Le compute module de la fondation est une réponse plus pertinente à cette problématique et s’inscrit mieux dans un contexte industriel. Cette carte a l’avantage de permettre de prototyper avec un Raspberry Pi standard, donc présente un très faible coût en pré-étude avant l’industrialisation. Dans cette stratégie, les solutions concurrentes des industriels sont autrement plus onéreuses (Sabre board par exemple).

    Il n’y a pas si longtemps, pour prototyper, on utilisait des cartes d’évaluation dont le montant atteignait classiquement les 4 chiffres. On peut dire que de ce côté, même sans être déployé sur le terrain, le Raspberry Pi a déjà révolutionné le monde industriel quand je vois cette carte posée sur nombre de coins de bureaux pour des prototypes ou maquettes 😉

    Répondre
      1. Thierry

        Bonsoir ! En fait je pense que vous avez tous un peu raison.
        L’incompréhension vient de la césure entre le monde de l’automatisme qui a découvert les réseaux il y a peu et qui a ses « langages » propre (ladder pour l’electro, grafcet pour « l’automaticien » st pour l’info indus. j’ai toute les peines du monde a faire utiliser des PLC Opto22, car en dépit des avantages qui présente pour nos application ils ne sont programmable qu’en organigramme !!! + pseudo ST. De plus pas d’USB dans l’industrie ? Et bien allez voir les schneider M340, M580 etc. C’est la base pour leur config. a+

        Répondre
  9. Erwann

    « le monde de l’automatisme qui a découvert les réseaux il y a peu »
    Désolé, je ne suis pas d’accord. Le monde de l’automatisme n’est pas rest à l’âge de pierre.
    Je travaille dans l’industrie depuis 1989 et j’ai toujours utilisé des systèmes de contrôle commande en réseau (chimie, pharma, infrastructure (utilités), centrales d’épuration, …).
    Ma première utilisation appliquée d’Ethernet et TCP/IP (coax 10 Mb/s) était justement fin 1989 pour faire du contrôle commande. J’ai même connu et utilisé des SNCC qui dataient du début des années 80 (cousin de TI D3) qui communiquaient via des bus TokenRings.
    Je ne suis absolument pas fan des bus de terrain propriétaire (cf. Sinec H1, Sinec L2, ProfiBus, Interbus S, et consorts). Je reste convaincu (depuis 1998) que TCP/IP avec les services qui vont bien est un excellent bus de terrain efficace et économiquement raisonnable dans la plupart des cas. En cas d’exigences de sécurité très élevées (cf. SIL), il est effectivement possible d’envisager d’autres architectures.
    Mais pour commander un climatisation, pour faire de la distribution d’énergie, pour contrôler des processus « lents » (temps de réponse attendu > 100 ms), TCP/IP et les Raspberry Pi peuvent très certainement bien faire le job.
    Évidemment, il est nécessaire d’avoir des architectures systèmes adaptées :
    – Ségrégation des réseaux
    – Utilisation de switches dédiés
    – Liaisons « backbone » en fibre optique
    – IP fixe
    – …

    Répondre
  10. Alyxs

    Bonjour, je ne pense que pas le produit fasse fureur en industrie, ou grand tertiaire, pour le moment : avis d’automaticien ! (ça se discute bien sur ! 🙂 )

    Aujourd’hui les parcs industriels sont fortement sur des marques phares (siemens, téléméca, omron), ou dans le grand tertiaire (schneider, siemens, wago,…). Le lien commun avec ces produits c’est qu’ils répondent à la norme IEC6131. Elle permet notamment la programmation, sur différents langages connus des électrotechniciens et des techniciens de maintenance qui sont les premiers utilisateurs. Le ladder, le grafcet, et le logigramme, sont même des fois imposés dans les Cdc. L ‘avantage aussi est que la recherche de panne est facilitée par la visualisation du déroulement en temps réel, alors que l’ide arduino ne permet pas cela.

    L’évolution peut se faire, aujourd’hui je tend à faire mes programmes process avec le langage ST, un langage textuel et non graphique, lorsque cela n’est pas imposé. Demain, peut être généraliser en C ou autre pourquoi pas avec beaucoup de temps.
    En comparant les prix d’industrial shield, ces derniers ne sont pas intéressants face aux solutions industrielles.

    Par contre pour faire de la domotique, je dit oui ; les solutions aujourd’hui sont chères (c’est même abusé !!! C’est pour cette raison que je me suis tourné vers le raspberry et l’arduino pour chez moi), le produit me semble intéressant, notamment pour la reprise de compteur sur RS485, une connexion IP, ou pour une gestion via imagerie. Par exemple: gestion d’un puits particulier, gestion d’énergie, d’éclairage ou encore de chauffage, je pense qu’il y a de quoi véritablement de quoi s’amuser !!!

    Répondre
    1. PortoBello

      Ces technos sont en pleine émergence dans le milieu industriel, ça vient doucement, de mon expérience,
      Témoignage:
      Jeune diplômé, ma première mission a été d’explorer les possibilités de ces systèmes et de mettre en place des Raspberry dans le milieu industriel.
      Le Raspberry m’a servi a faire communiquer un TSX57 avec une base de donnée SQL.
      Le raspberry est totalement transparent ,il gère tout en wifi et écrit par ETY110 au TSX.

      Je pense que c’est justement cette phobie du C ou des langages ST qui n’incite pas les automaticiens à passer le pas, s’il existe bien un langage Ladder, c’est gagné.

      Répondre
  11. Joël

    Merci François pour toutes tes infos.

    Juste un petit complément.

    La société 3S Smart Software Solutions qui édite le logiciel de programmation CODESYS (utilisé par Wago, IFM, Schneider, Eaton, …, il y en près de 300 !!) propose une version pour la framboise et, depuis peu, pour le Beaglebone.

    Ce logiciel de programmation, conforme à la norme CEI, permet d’utiliser les langages : Liste d’instruction (IL), Schéma à relais (LD), Bloc fonctionnel (FBD), Texte structuré (ST), Sequential Function Chatrt (SFC) et Continuous Function Chart (CFC).
    Sans license le système fonctionne pendant 2 heures (il suffit ensuite de le relancer !). Pleinement fonctionnel il permet de réaliser des applications d’automatismes, d’utiliser le webserveur (si le fabricant l’à intégré), un serveur OPC, des moyens de communication (Profibus, Modbus, Modbus TCP, …), de créer des pages de visualisation (IHM), …

    La license pour notre framboise et de l’ordre de 35 euros.

    Je n’ai pas vu trouvé d’indications sur la programmation du Touchberry PI, mais si ils implémentait CODESYS ce serait une bonne idée.

    Concernant l’USB en mode industriel, il existe pas mal d’API ou de pupitre opérateur qui possèdent un ou plusieurs ports USB.
    Ce port est utilisé pour programmer (M248 de Schneider), pour copier et transférer des données (Eaton), pour mettre à jour des OS, pour brancher des périphériques : imprimantes, lecteur de codes barres, ….

    Le wifi et même le Bluetooth sont aussi utilisé pour programmer (Zelio de Schneider) ou communiquer (Siemens par exemple). C’est très pratique quand on utilise un pupitre mobile et qu’on veut tourner autour de la machine.

    Répondre
    1. François MOCQ Auteur de l’article

      bonjour Joël
      merci pour ce retour
      il y a belle lurette que j ai dis que je ferais un article sur Codesys
      mais pas encore eu le temps !
      il faudrait que je puisse m’y mettre un bon moment pour l’utiliser « en vrai » mais je n’ai pas le temps 🙁
      la retraite approchant ça va (peut être) s’arranger un peu
      En tout cas merci pour toutes ces précisions
      cordialement
      François

      Répondre
    2. Erwann

      Merci Joël !
      C’est une super info.
      J’avais déjà posé des questions dans ce sens chez un fabricant de borniers intelligents il y a quelques mois, mais personne ne pouvait donner une réponse aussi claire (pourtant le fabricant en question est cité dans la liste ! …).

      Répondre
  12. Fred

    Premier commentaire ici et sur un article ancien mais je me rattraperai 😊

    Autant l’Arduino peut trouver sa place en industrie puisqu’il est basé sur un composant conçu pour l’industrie avec !a pérennité qui va avec, autant le Raspberry est une hérésie simple.

    Les Arduino sont basés pour !a grande majorité sur un Atmega328 dont la pérennité est garantie, dont les documentations sont disponibles, et dont des références sont qualifiées en références industrielles. Reste le problème du code source Arduino qui n’est pas spécialement propre mais rien n’empêche de le modifier et de le blinder.

    Côté Raspberry, on se retrouve avec des composants conçus pour des produits commerciaux. Outre l’endurance qui n’est pas la même ( gamme de température moins étendue, cycles de fonctionnement garantis radicalement différents), il n’y a aucune garantie de pérennité. Le meilleur exemple tout récent est le changement de processeur du Pi 2 qui le fait passer subitement d’un CPU 32 bits à un 64 bits. N’importe quel industriel sérieux comprendra les galères qui l’attendent: refonte du logiciel, changement de nomenclature, gestion d’un double stock tant logistique que software et pire que tout pour un industriel, certaines certifications à repasser avec les couts afférents.

    J’imagine la soufflante que vont prendre les ingés qui ont choisi une Pi2 pour leur production industrielle et l’autre soufflante que vont prendre les acheteurs de !a part de la direction pour avoir laissé faire ça.

    Bref, je ne suis pas un ennemi du Raspberry, je joue même avec, mais ça reste un jouet…

    Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Complétez ce captcha SVP * Time limit is exhausted. Please reload CAPTCHA.