"veille techno" IHM pour un automate programmable

Bonjour,

Je souhaite faire une "veille techno" sur l'interfaçage IHM d'un automate programmable (par ex un Beckhoff CX1010).

J'aimerai me lancer dans la création d'un prototype IHM web en asp.net MVC III, mais je manque d'arguments pour justifier le choix de ce framework et de son language (c# vs java vs ruby vs python vs...).

Le but de départ serait de simplifier et de moderniser nos petit HMI pour des nouveaux process (prototype).

WEB ?:
Pour la séparation du contenu et du design
Pour avoir des client léger (un navigateur)
Pouvoir utiliser n'importe quel sortie (PC, PAD, mobile...).
Faciliter les updates
HTML5 ready...

Framework MVC ?:
Dans le but d'être simple à maintenir (conventions).

Pourquoi pas utiliser un outil existant (FtView, Wonderware, Zenon...) ?
A cause du prix des licences et du manque de fonctionnalités.

Je remarque que la techno. .net et plus utilisés dans le monde de l'automation industriel mais je ne trouve pas d'information objective ainsi que de comparaisons. (un des arguments serait la facilité de trouver des développeurs ayant déjà des connaissances de l'automation, c'est pour cela que j'ai un a priori pour écarter de bons frameworks comme rails mais trop "exotique" dans ce monde).

Avez vous des données relatives à ce sujet qui me permettrait de faire un choix objectif ?
Avez-vous des "user stories" et des références ?

Merci beaucoup pour votre feedback et meilleures salutations

Thierry

Bonjour,

Pour répondre à la question s'il faut utiliser un outil de supervision du marché (Wonderware Intouch, Siemens WinCC, FtView, etc.) ou faire ton propre framework, je te répondrais tout dépend de ce que tu veux faire.

Certes une licence de supervision possède un certains coût (dépendant du nombre de points que ta supervision va lire/écrire dans ton PLC) mais en contrepartie, tu risques de gagner du temps en développement. Il faut savoir que ces outils possèdent une multitude de drivers de communication. Tu n'auras donc pas à redévelopper quoique ce soit de ce côté-là. Ensuite, tu peux réaliser des IHM très très complètes très facilement grâce à l'outil de développement de la supervision (nécessite généralement une licence à part entière de la licence Runtime).
Autre avantage, tu auras peut-être plus de facilité à embaucher un automaticien capable de développer un programme sur ton PLC et connaissant l'outil de supervision que tu auras choisi puisque généralement les 2 compétences vont de paires.

Si tu veux absolument partir sur une solution spécifique, je te conseille vraiment de bien estimer le coût que cela représente car si c'est pour faire ce que tu peux faire avec un outil de supervision, au final ça te reviendra plus cher que des licences.

En revanche, si tu estimes que ce que tu souhaites faire ne peut pas être réalisé avec une supervision, et bien il faut d'abord savoir:
Comment ton IHM dialoguera avec ton PLC ?
Utiliseras-tu l'interface OPC via un serveur OPC ? Ou un autre protocole (Modbus, protocole propriétaire, etc.) ?
Utiliseras-tu une carte de communication particulière ?

Ces éléments sont importants pour savoir ensuite quel langage et quelle techno tu vas utiliser.
Il y a quelques temps, lorsque j'ai commencé à développer des applications devant dialoguer avec des PLCs via l'interface OPC, je m'étais posé la question entre Java et C#/.NET. Mon choix s'est porté sur C#/.NET parce qu'il me semblait plus difficile d'implémenter l'interface OPC en JAVA.

Ensuite, seulement tu pourras déterminer si tu pars sur du ASP.NET MVC ou autre.

++
Zoax

Merci pour ton message !

Effectivement le dialogue est un argument de choix. Je pensais utiliser un OPC serveur pour rester générique.
Pour me simplifier la vie j'avais l'intention d'utiliser un composant OPC.net pour le client et merci pour d'avoir mis cela en évidence, il y peu de chose en java.
Avais-tu développé ton propre OPC client ou est-ce que tu l'a acheté ?

Je suis persuadé que je vais dépasser le prix d'une license d'un outil de supervision du marché. Je pense utiliser ces outils pour la plupart des applications.
Mais j'aimerai avoir une solution non-dépendante et générique qui me permet de palier aux limitations de ces outils.

Du coup, j'ai déjà deux arguments pour .net dans le choix du framework.

1 Dialogue automate.
2 "Popularité" dans le mode de l'automation.

Bonne journée

PS Si d'autre personnes ont aussi des expériences sur le sujet, merci d'avance.

Bonjour à tous,

pour te repondre Thierry,

tu peux effectivement developper un composant OPC.net dans ton developpement, mais je ne crois pas que tu en trouveras gratuitement.
Peson j'ai déja developpé un client OPC sous Excel et il n'y a aucune difficulté, mais te concenant le problème sera de trouver ton serveur OPC, car un serveur OPC est fournit par le fabricant du matériel, or si tu as de vieux automate, tu as de fortes chances de ne pas trouver de serveur OPC pour ton automate.
Tu as tous de même une chance d'arriver à communiquer avec un vieil automate via un seveur OPC ....
Je te donne la solution si tu reviens lire ce post !

A+