|
|
|
Publicité ' | |||||||||||||||||||||||
02/03/2011, 17h12
|
#1 |
|
Invité de passage
 Pierre Inscription : mars 2011 Messages : 5  |
Supervision d'un automate TSX Premium P57262 par Modbus
Bonjour à tous,
Je cherche de l'aide. Je suis en dernière année d'ecole d'ingénieur et je travaille actuellement sur mon projet de fin d'études qui consiste à étudier les vulnérabilités d'une application de supervision SCADA d'une installation industrielle. En gros, je dois mettre en place une supervision d'un automate sur un réseau local Ethernet: ainsi je veux essayer de modifier les trames envoyées entre mes pc et mon automate afin de voir comment mon système et ma machine réagissent... C'est assez flou car je n'ai pas attaqué cette partie... J'effectue la programmation de mon automate TSX Premium P57 2623 à l'aide de PL7 Pro v4.5 afin de faire executer à ma machine un cycle de tri. A côté de celà, j'ai mis en place une application de supervision à l'aide d'InTouch. En ce qui concerne la communication actuelle avec l'automate: L’automate communique avec l’ordinateur de supervision soit via une liaison série RS-232 branchée sur le port COM 1 du PC soit via une liaison TCP/IP car l'automate dispose d'un module Ethernet. 1) Le protocole de communication par la première liaison est le protocole UNITELWAY. InTouch ne communiquant que par les protocoles DDE, FastDDE et SuiteLink, il n’est donc pas possible de récupérer les données de l’automate sous InTouch sans faire préalablement une conversion de protocole. C’est pourquoi Wonderware propose avec InTouch un logiciel permettant la conversion du protocole OPC (Protocole standard de communication pour les PLC) vers les protocoles exploitables par InTouch. Reste le problème de la conversion du protocole UNITELWAY vers le standard OPC. Pour permettre cela, j'ai utilisé un logiciel serveur OFS fournit par Schneider Electric. voir premiere image jointe (pc-tp-tapis est mon pc principal) 2) L'automate dispose donc d'un module Ethernet, ainsi j'ai pu delocalisé l'application OPCLink et laisser le serveur OFS sur le pc principal... voir deuxième image (box-intouch est un pc secondaire) Jusqu'ici tout fonctionne... Mais ce que je veux faire est assez spécial: un de mes tuteurs de projet a effectué un outil de test qui permet de lire les trames envoyées et de les modifier mais cet outil n'est applicable qu'avec une communication via Modbus... Après quelques recherches, j'ai pu constater que c'était peut être faisable... de remplacer OPCLink par Modbus, mais qu'il me fallait peut être une carte PCMCIA, ce que je ne possède pas... Je ne fais que de feuilleter la documentation technique de pl7, de l'automate, de modbus mais je suis dans le flou complet, et j'aimerai que vous puissiez me renseigner sur: - est ce que c'est faisable d'installer un protocole Modbus avec ma configuration actuelle des choses? - quelles informations voulez vous pour vous permettre de m'aider à répondre à cette première question? Merci beaucoup, cela m'aiderait énormément... Cordialement... Pierre PS: rappel de ma config matérielle sur la 3e image |
|
00
|
|
02/03/2011, 20h24
|
#2 |
|
Membre du Club
 Laurent Laurent Inscription : novembre 2010 Messages : 42 |
Bonjour,
Regarde chez Wonderware le produit : DAServer Toolkit. Le plus simple restant de les appeler pour avoir des conseils. http://www.wonderware.fr/aboutus.aspx |
|
|
10
|
|
02/03/2011, 21h45
|
#3 | |
     
  Bruno GuérangéIngénieur développement logiciels Inscription : mai 2002 Messages : 7 868 |
Citation:
Communiquer en liaison série et/ou Unitelway alors que tu as une voie Ethernet est pour moi à oublier tout simplement. Aparte : ce genre de limitations et de couches inutiles nous ont conduits de ne plus jamais utiliser les supervisions du commerce tant que ce n'est pas imposé par le client. Sans compter le prix prohébitif des licences de développement et de runtime. 
__________________
Delphi :  La F.A.Q. , 877 réponses à vos questions !264 sources à consulter/télécharger ! |
|
|
|
20
|
|
03/03/2011, 09h31
|
#4 | ||||
|
Membre régulier
 Inscription : novembre 2007 Messages : 81 |
Citation:
A titre perso, je trouve le sujet important, et je pense que nous serions nombreux à consulter ton projet de fin d'études. Citation:
2) La communication entre OFS Serveur et le PLC se fait sous quel protocole ? La deuxième image indique UNITELWAY. Citation:
Pour moi, c'est entre le OFS serveur et l'automate que tu pourras modifier des choses. Citation:
|
||||
|
|
10
|
|
03/03/2011, 14h54
|
#5 | |
|
Membre régulier
Inscription : novembre 2007 Messages : 81 |
Hello Nono40,
Citation:
Tu fais du développement spécifique ? A chaque fois, ou bien tu as ton propre logiciel de supervision ? |
|
|
|
10
|
|
04/03/2011, 10h57
|
#6 |
|
Invité de passage
Pierre Inscription : mars 2011 Messages : 5 |
A Dehell34:
A quoi sert DA Server Toolkit? A Nono40: Je sais qu'utiliser OPC est un peu de la bidouille dans les couches, mais ce choix m'était imposé. En effet, deux anciens projets existants utilisaient la supervision InTouch via OPC. Et l'automate ne disposait à la base que d'une liaison série RS232 donc je m'en suis servi pour concevoir mon interface de supervision et mettre en place mon programme de l'automate... Depuis cette année, une voie Ethernet a été installée sur l'automate Et donc maintenant, je n'utilise que la liaison Ethernet...la liaison série n'est qu'une option que je veux garder de côté afin de la configurer en liaison de sécurité, au cas où le réseau déconne en plein cycle de la machine... (mais je verrai ça plus tard) InTouch a peut être un driver ModbusIP natif, mais je ne sais pas comment l'utiliser, et surtout comment le trouver... peux tu m'aider? A Poil_dur: Effectivement c'est un sujet d'actualité et ce projet a été proposé justement à cause de Stuxnet...  Et si tu voudras consulter mon projet, je pourrai toujours te l'envoyer quand je l'aurai fini... 1) InTouch est imposé, mon école ne dispose que de la suite Wonderware 2) La communication entre l'OFS et le PLC se faisait par Unitelway dans d'anciens projets que j'ai repris pour configurer l'interface et la programmation de mon PLC. Et pour tester la supervision d'une autre ordinateur, j'ai délocalisé OPCLink et InTouch, tout en gardant le serveur OFS sur mon ordinateur principal... En fait l'idée de départ est de garder un ordinateur maître qui garde le contrôle sur la supervision de toute manière... et on avait imaginé cet ordinateur principal placé à côté du PLC en mode local et en liaison série... histoire que s'il y ait un souci dans le réseau Ethernet (en particulier si on modifie les trames envoyées vers le PLC), que l'automate se mettre sur la liaison série afin de ne pas déconner.. Mais maintenant que l'automate dispose d'une voix Ethernet, on pourrait aussi tout délocaliser... il faut juste que l'on m'aide à configurer OFS afin de le mettre en liaison TCP/IP avec le PLC... 3) Je veux Modbus en liaison TCP/IP je pense... Mais en fait, comme ce n'est pas trop mon domaine, j'ai du mal à cerner correctement les choses... Modbus remplacera complétement OPC? Comment mettre en place Modbus via TCP/IP? Sur l'ordi, et sur l'automate? ¨ Pour résumer, l'idéal pour moi serait d'avoir le PLC branché à un ordinateur principal/maître via deux liaisons: une liaison Ethernet et une liaison série RS232 Et sur le réseau Ethernet un ordinateur esclave qui peut aussi superviser le PLC à l'aide d'InTouch mais qui peut perdre le contrôle si l'ordinateur maître le décide. Enfin un dernier ordinateur relié au réseau qui peut superviser comme un ordinateur esclave, mais surtout qui soit muni de cet outil de test fait par un de mes tuteurs afin d'analyser et de modifier les trames envoyées sur le réseau, en particulier celles envoyées vers le PLC... Le tout pour simuler un réseau réel sur lequel un pirate viendrait s'amuser à perturber ma machine... C'est assez simpliste mais bon j'aimerais que ce soit réalisable. InTouch m'est imposé. J'ai OPC et OFS de base mais je peux les changer s'il le faut. Je ne connais pas du tout Modbus et comment l'installer. J'ai 2 semaines pour tout faire... Voilà  Si vous voulez plus de renseignements, n'hesitez pas! Help! I need somebody help! Merci |
|
|
00
|
|
04/03/2011, 13h43
|
#7 | ||||||||
|
Membre régulier
Inscription : novembre 2007 Messages : 81 |
Citation:
Citation:
Citation:
Citation:
Les drivers Modbus série et Modbus/TCP sont fournis, ce qui pourrait t'aider. Maintenant, à toi de voir, si tu connais bien Intouch, tu perdras du temps à regarder un autre système. Citation:
Citation:
Citation:
Citation:
Ensuite, Intouch communiquera avec OFS à travers OPCLink, avec le protocole OPC. Un point qui n'est pas clair pour moi: - tu as un seul réseau ethernet avec deux PC et un API branchés dessus (ce que je suppose), ou bien - deux réseaux ethernet distincts: l'un entre les deux PC, et une autre interface ethernet sur le pc faisant tourner OFS vers l'API seul ? De mon point de vue, pour prolonger les réflexions, les risques de piratage envisageables seraient: - la commande du procédé par un autre opérateur que celui qui se trouve devant la supervision; - le vol de savoir-faire par la récupération du programme API ou de l'application de supervision; - le sabotage par la modification du programme API ou de l'application de supervision; - la récupération de données de production, ou leur falsification. Si j'ai bien compris, le risque que tu cherches à étudier concerne le premier point: dans quelle mesure peut-on contrôler un automatisme en court-circuitant la supervision ou les commandes locales ? Pour moi, le premier point faible se trouve au niveau de l'API Schneider: à travers une liaison supportant le protocole Modbus, les TSX Premium (comme les Micro, Nano, Twido) donnent accès aussi bien en lecture qu'en écriture à l'ensemble des variables internes (%M et %MW), sans contrôle sur les adresses qui devraient n'être accessibles qu'à une application de supervision ou une IHM. L'avantage est que la communication est simple à mettre en oeuvre, mais le risque peut être énorme: une variable interne modifiée autrement que par programme peut conduire à un fonctionnement dangereux de l'automatisme. (Selon l'application, on peut adopter une manière de programmer permettant de limiter ces risques, mais ce sera léger et pas forcément pratique pour la maintenabilité du programme.) Ici, le risque dépend fortement du type de l'API utilisé. Pour ceux d'entre nous ayant déjà mis en oeuvre une liaison Modbus sur les anciens API série 7 (TSX47 par exemple), on sait que les échanges étaient pris en charge en partie par l'application de l'automate. Il fallait configurer les plages de variables accessibles en lecture ou en écriture, et les échanges entre le module de communication et le processeur étaient gérées par les sous-programmes qui vont bien. C'était chiant à faire fonctionner, mais ça permettait un contrôle fin de ce que la supervision ou l'IHM pouvait piloter. Un autre modèle / une autre marque d'API ne présentera pas forcément cette faiblesse vis-à-vis de la sécurité. Le protocole UNITELWAY permet l'accès à d'autres types de variables que les bits et mots internes: via ce protocole, on pourra contrôler les paramètres de blocs fonction, et même modifier des constantes. De ce point de vue, ce protocole présente un risque bien plus grand que Modbus. A travers le réseau ethernet entre le PC de supervision et le serveur OFS, le protocole OPC peut peut-être aussi faire l'objet du piratage. Ce protocole est-il aussi "ouvert" que Modbus ? Peut-on envoyer des requètes de modification de variables au serveur OFS sans être connu comme le PC de supervision, on bien peut-on se faire passer pour l'application de supervision pour commander l'API à travers le serveur OFS ? Sur ce point je crois, les risques se bornent sur les variables accessibles dans le serveur OFS. M'étonnerait qu'on puisse lui demander de modifier une variable arbitraire dans l'API, si celle-ci n'est pas récupérée par OFS. Dans ce cas de figure, le risque réside dans le fait que l'attaquant pourrait commander l'automatisme en se faisant passer pour un opérateur de supervision, mais sans plus de dégâts que ce que pourrait faire l'opérateur ayant le plus de droits sur le PC de supervision... sauf si le pirate modifie la config d'OFS au préalable. Ce qui nous amène à la sécurisation des postes informatiques utilisés: un firewall bien configuré, un anti-virus à jour, une politique d'accès aux postes de travail bien en place et un contrôle régulier de tout le bazar... Un problème bien plus vaste ! |
||||||||
|
|
00
|
|
04/03/2011, 17h43
|
#8 |
|
Membre du Club
Laurent Laurent Inscription : novembre 2010 Messages : 42 |
Bonjour,
DA Server permet de supprimer une couche (OFS) et de ne plus utiliser OPC Link. La liaison se fait directement entre intouch et DA Server (enfin je crois  )La doc pour Modbus en TCP Mais c'est un produit payant, que je n'ai jamais mis en place. Pour le reste je peux te donner quelques tuyaux: La carte Ethernet c'est quel modèle? Quelle version d'OFS utilise tu? Cordialement. |
|
|
00
|
|
04/03/2011, 18h23
|
#9 | ||
|
Invité de passage
Pierre Inscription : mars 2011 Messages : 5 |
A poil dur:
- Je n'en ai pas absolument besoin... mais comme j'ai déja la liaison Unitelway, je pensais m'en servir quand même en tant qu'option, si j'ai le temps de configurer ça... - Je ne connais qu'InTouch et je n'ai pas le choix donc faut que je me débrouille avec... - En ce qui concerne mon projet, si vous êtes intéressés, mettez moi votre mail en mp et je vous l'enverrai. Mais je ne peux pas non le diffuser à tout le monde. - En effet, je ne connais qu'InTouch donc je vais garder ça, ça serait de la perte de temps d'en utiliser un autre, et j'ai besoin d'au moins 50 variables de l'API. - La communication se fait toujours par Unitelway en ce moment, et j'aimerai trouver comment la configurer en Ethernet ... "pour tester" - Tu comprends bien l'idée, il faudrait que OFS bascule de la liaison ethernet sur la liaison série s'il détecte des trames à la noix côté ethernet... Je ne sais pas s'il peut faire cela, mais j'aimerai bien! C'est la prochaine étape. - Tu as l'air de me dire que Modbus serait placé entre OFS et le PLC... mais si Modbus connait les protocoles DDE, FastDDE ou SuiteLink, on ne pourrait pas "enlever" OFS et OPC? Car à la base, ce sont des intermédiaires faits pour traduire les protocoles... OPC traduit les protocoles d'InTouch FastDDE, DDE ou SuiteLink en standard OPC, puis OFS traduit le standard OPC en protocole Unitelway, comme sur mon schéma de mon premier message. Ce que je pensais obtenir ce n'est plus: InTouch =>"DDE, FastDDE ou SuiteLink"=> OPCLink =>"Standard OPC"=>OFS=>"Unitelway"=> API Mais: InTouch =>"DDE, FastDDE ou SuiteLink"=> Modbus/TCP =>"Unitelway"=>API Est ce que c'est réalisable cette config? Le point qui n'est pas clair pour toi = un seul réseau Ethernet sur lequel tout est branché En ce qui concerne les autres possibilités que tu proposes, je dois me focaliser sur mon sujet, et surtout les outils qui sont mis à ma disposition... Or je n'aurai qu'un outil qui pourra modifier les trames envoyées sur le réseau, et je dois voir ce qui se passe... Des reflexions supplémentaires seront surement faites à la suite de mon projet par les volontaires de l'année prochaine Citation:
Citation:
Le protocole Unitelway est surement plus accessible au risque mais ça je le verrai par moi même quand j'aurai inséré cet outil de test.. Et cet outil de test ne fonctionne qu'avec Modbus, donc je ne peux pas essayer de faire deconner mon automate avec OPC... |
||
|
|
00
|
|
04/03/2011, 19h22
|
#10 | |
|
Membre régulier
Inscription : novembre 2007 Messages : 81 |
Citation:
InTouch => "Modbus/TCP" => API (entre guillemets sont indiqués les protocoles utilisés, on est bien d'accord ?) Sauf que si Intouch ne propose pas nativement le protocole Modbus pour causer avec l'API directement, il faut faire passer les données à travers un autre protocole compris par Intouch: c'est là qu'entrent en jeu DDE / FastDDE / SuiteLink et OPC (à travers OPCLink et OFS). C'est entre un serveur OPC et l'API que tu peux mettre en oeuvre le protocole Modbus. Donc dans OFS (si OPCLink ne propose pas de communiquer directement avec l'API en Modbus/TCP, j'imagine ?). Ce qui complique le boulot, c'est la complexité des couches de communication. Le superviseur cause avec un serveur DDE qui cause avec un serveur OPC qui cause avec l'automate en unitelway... L'idée d'utiliser un autre superviseur, c'est que je sais que ça permettrait de causer en modbus/tcp directement. Mais bon, j'ai pigé, ça va pas être possible. Reste à voir si Intouch peut communiquer le plus directement possible avec l'API ? Bon courage ! |
|
|
|
00
|
|
05/03/2011, 21h04
|
#11 |
|
Bruno Guérangé Ingénieur développement logiciels Inscription : mai 2002 Messages : 7 868 |
L'idée est bien de supprimer de couches inutiles
Je n'utilise pas InTouch, un collègue l'a utilisé sur du Siemens et InTouch disposait bien des drivers natifs Siemens sur Ethernet. Un coup d'oeil en 10 secondes sur le site de wonderware http://www.wonderware.fr/img/file/Da...tasheet_FR.PDF Intouch dispose bien d'un driver Modbus sur Ethernet.(dernière page du pdf) D'après ce que je sais InTouch communique soit en DDE soit en FastDDE soit en SuiteLink (couche made in Wonderware). Il faut donc un driver MudbusIP dans suitelink : InTouch =>"SuiteLink"=> Modbus/TCP =>API Développer aujourd'hui un superviseur communiquant en UnitTelway, heu.. C'est encore plus lent que du modbus série. Si vous utilisez Intouch dans votre entreprise, contactez donc Wonderware pour avoir le driver ModusIP si vous ne l'avez pas déjà dans les CD d'installation.
__________________
Delphi : La F.A.Q. , 877 réponses à vos questions !264 sources à consulter/télécharger ! |
|
|
10
|
|
08/03/2011, 12h36
|
#12 |
|
Membre régulier
Inscription : novembre 2007 Messages : 81 |
Hello,
le magazine MISC n°54 de mars/avril 2011 vient de paraître et contient un article traitant des nouvelles menaces des réseaux industriels, en rapport avec Stuxnet et... Modbus et OPC, signé par François Gaspard. Sans rentrer dans les détails, l'auteur décrit bien le protocole Modbus et les risques liés à son implémentation dans les réseaux TCP/IP. Puis est décrit OPC, avec là encore une analyse des risques que cette couche introduit dans les réseaux informatiques industriels. Avec quelques figures permettant une bonne compréhension de l'environnement dans lequel sont envisagés les risques de sécurité, l'article est intéressant et propose de nombreuses références web concernant le sujet, très intéressantes à consulter (pour les deux ou trois que j'ai pu lire). Par exemple, sur le site http://secdocs.lonerunners.net/tags/details/111-scada, on trouve des articles traitant de ModScan, la sécurité sur les systèmes SCADA, etc. Un article qui tombe à pic
|
|
|
10
|
|
10/03/2011, 13h12
|
#13 |
|
Membre Expert
 Arnaud Développeur .NET Inscription : avril 2006 Messages : 1 343 |
Je viens d'acheter (outch le tarif quand même !) et de lire l'article, qui est intéressant, synthétise bien les éléments utilisés par Stuxnet, et la sensibilisation vis à vis des technos type OPC est judicieuse !
|
|
|
00
|
|
11/03/2011, 16h51
|
#14 |
|
Invité de passage
Pierre Inscription : mars 2011 Messages : 5 |
Bon j'ai éclairci certains points.
J'ai trouvé plusieurs "traducteurs" de protocoles pour mon ordi principal: en gros ce traducteur lira InTouch et du Modbus. Ca c'est bon. Maintenant j'ai deux liaisons physiques entre mon pc et l'API: la liaison série RS232 et la liaison Ethernet. Il me faut donc un driver pour le pc qui lit le modbus pour la liaison série (ce que j'ai trouvé) et un driver pour le pc qui lit le modbus pour la liaison ethernet (je ne l'ai pas trouvé). Ca c'est côté pc... Maintenant du côté de l'automate, je n'ai qu'un microprocesseur TSX P57 2623 avec module ETY PORT qui est équipé d'une connexion Ethernet... je n'ai pas de modules complémentaires, telles que des cartes PCMCIA...etc Donc j'aurai aimé savoir si cet API peut lire du modbus nativement via la liaison série, et via la liaison Ethernet... Pouvez vous m'aider sur ces points là??? J'ai trouvé de la documentation sur Modbus, Modbus plus, et Modbus Ethernet... je pense savoir à quoi correspond Modbus et Modbus Ethernet, mais à quoi sert Modbus plus? Quelles sont les différentes avec les deux autres??? Merci de m'avoir déja aidé à répondre à certaines de mes questions. Pouvez vous m'aider pour ces nouvelles questions? Merci |
|
|
00
|
|
13/03/2011, 03h42
|
#15 |
|
Bruno Guérangé Ingénieur développement logiciels Inscription : mai 2002 Messages : 7 868 |
La CPU que tu as 2623 sait dialoguer en ModbusIP (Modbus sur Ethernet) sur la voie ethernet intégrée.
Elle ne sait pas dialoguer falicement en modbus série sans carte additionnel, c'est possible de reconfigurer la prise console en Modubus esclave sur une couche physique en RS485. Mais bien sur dans ce cas on pert l'accès console. Pour avoir une liason Modbus indépendante, il faut y ajouter une carte pcmcia SCP111 (RS232), SCP112(Boucle de courant) ou SCP114 (RS485). ModbusPlus est un modbus série plus évolué et multi maitre développé sur les automates Modicon avant leur rachat par Schneider. Ca reste par pur compatibilté, à oublier. Je ne comprend pas pourquoi tu ne prend pas le driver Modbus Ethernet vendu par Intouch plutôt que d'essayer des solutions comlexes.
__________________
Delphi : La F.A.Q. , 877 réponses à vos questions !264 sources à consulter/télécharger ! |
|
|
00
|
|
13/03/2011, 17h50
|
#16 | |||
|
Invité de passage
Pierre Inscription : mars 2011 Messages : 5 |
Citation:
Citation:
Citation:
Tu dis que l'API sait dialoguer en ModbusIP par la voie Ethernet intégrée... Besoin de le configurer quelque part ça, ou c'est automatique? Merci pour l'info, je n'utiliserai alors que la liaison Ethernet pour Modbus. |
|||
|
|
00
|
|
13/03/2011, 20h47
|
#17 |
|
Bruno Guérangé Ingénieur développement logiciels Inscription : mai 2002 Messages : 7 868 |
Pour la configuration coté Intouch, aucune idée car je n'ai jamais fait.
Coté automate, tu n'as rien à faire.
__________________
Delphi : La F.A.Q. , 877 réponses à vos questions !264 sources à consulter/télécharger ! |
|
|
00
|
|
14/03/2011, 20h40
|
#18 |
|
Membre du Club
Laurent Laurent Inscription : novembre 2010 Messages : 42 |
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com