Ajout API communiquant sans modifier les programmes des existants

Partie du forum pour tout ce qui concerne la partie réseau de communication dans l'industrie. Forum, conseil, astuce et entraide sur le réseau industriel tel que la connexion modbus, ethernet, fipio .
Avatar de l’utilisateur
JC87
Mi homme - Mi automate
Mi homme - Mi automate
Messages : 1901
Inscription : 20 oct. 2015, 13:00
Localisation : Nouvelle Aquitaine

Re: Ajout API communiquant sans modifier les programmes des existants

Message par JC87 »

Bonjour,

En fait tu a déjà ta solution donc pourquoi nous demander des idées alors que tu savais des le depart que ca ne conviendrai pas et que tu resterai malgre tout sur cette brillante solution ?

JC
"On veut faire du zéro défaut mais on a zéro bonhomme et zéro budget, et bien à la fin on a zéro résultat..."
Kallysto
Créateur de langage
Créateur de langage
Messages : 732
Inscription : 27 avr. 2017, 11:11
Localisation : Loin de la civilisation

Re: Ajout API communiquant sans modifier les programmes des existants

Message par Kallysto »

A la base j'avais pas l'idée.

Après j'ai donné le "cdc" : pas d'ajout d'API, pas de logiciel tierce. J'y peux rien si ces solutions là me sont refusées. Vu que personne ne propose autre chose qu'ajouter des API ou un logiciel tierce, je peux faire quoi ?

Proposez moi autre chose alors.

L'objectif c'est d'avoir 0 arrêt de service, donc de ne pas modifier le programme API. Les pages Webs sont modifiables et rechargeables sans arrêt du service.

J'ai pas trouvé mieux que l'idée que j'ai donné.

En faisait les différentes étapes sur papier, je ne trouve pas de bugg. Mais on ne voit pas forcément tous les cas de figure sur papier. Et même en test, impossible de faire un config aussi complexe qu'en réelle donc impossible de tester à fond.

Donc si quelqu'un a autre chose, de déjà testé et validé, ou si quelqu'un y voit un bugg, je prends...
Lorent2
Maître du binaire
Maître du binaire
Messages : 484
Inscription : 27 déc. 2015, 08:52

Re: Ajout API communiquant sans modifier les programmes des existants

Message par Lorent2 »

Kallysto a écrit : 15 mai 2017, 15:39 L'objectif c'est d'avoir 0 arrêt de service, donc de ne pas modifier le programme API. Les pages Webs sont modifiables et rechargeables sans arrêt du service.
Les automates aussi :D
Si quelquefois tu te sens petit, inutile, démoralisé ou dépressif, n'oublies jamais que tu as été un jour le plus rapide et le meilleur spermatozoïde de ta bande ...
steph68
Codeur fou
Codeur fou
Messages : 268
Inscription : 21 oct. 2015, 08:23

Re: Ajout API communiquant sans modifier les programmes des existants

Message par steph68 »

hello,

le plus simple serait de pouvoir faire du multicast / broadcast:

périodiquement chaque automate envoie son état sur le réseau à destination de tous les autres
mais il faudrait que tu trouves la "couche logicielle" dans ton automate pour faire ça (habituellement c'est plutot le point à point ou unicast qui est dispo)
ou bien un genre de routeur sur ton réseau qui diffuse en multicast les paquets reçus (mais il devient alors le maillon faible = concentrateur)

--> à voir pour trouver un automate gérant le multicast

les autres stratégies seraient des usines à gaz à réaliser ... (à mon avis hors de portée des automates industriels)
il te faudra synchroniser une liste de partenaires, synchroniser l'heure (pour vérifier la fraicheur des données, puisqu'il y aura des doublons à trier) ... et j'en passe

sinon comme dit au-dessus: solution du concentrateur
argumente avec ton client que le cloud est le futur de l'industrie :mrgreen:

@+

EDIT: sur ta stratégie, tu n'anticipes qu'un seul automate en panne (si 2 automates consécutifs en panne, c'est mort).
faire une chaine n'est jamais une bonne idée car il y a toujours un maillon faible
Avatar de l’utilisateur
JC87
Mi homme - Mi automate
Mi homme - Mi automate
Messages : 1901
Inscription : 20 oct. 2015, 13:00
Localisation : Nouvelle Aquitaine

Re: Ajout API communiquant sans modifier les programmes des existants

Message par JC87 »

steph68 a écrit : 15 mai 2017, 18:56 hello,

le plus simple serait de pouvoir faire du multicast / broadcast:

périodiquement chaque automate envoie son état sur le réseau à destination de tous les autres
mais il faudrait que tu trouves la "couche logicielle" dans ton automate pour faire ça (habituellement c'est plutot le point à point ou unicast qui est dispo)
ou bien un genre de routeur sur ton réseau qui diffuse en multicast les paquets reçus (mais il devient alors le maillon faible = concentrateur)

--> à voir pour trouver un automate gérant le multicast

les autres stratégies seraient des usines à gaz à réaliser ... (à mon avis hors de portée des automates industriels)
il te faudra synchroniser une liste de partenaires, synchroniser l'heure (pour vérifier la fraicheur des données, puisqu'il y aura des doublons à trier) ... et j'en passe

sinon comme dit au-dessus: solution du concentrateur
argumente avec ton client que le cloud est le futur de l'industrie :mrgreen:

@+

EDIT: sur ta stratégie, tu n'anticipes qu'un seul automate en panne (si 2 automates consécutifs en panne, c'est mort).
faire une chaine n'est jamais une bonne idée car il y a toujours un maillon faible
Ça ressemble à du Global Data ta solution et en effet ça pourrai être intéressant dans le sens ou les infos sont partagés par tout le monde sans programmation et sans qu'il y ai besoin de réponses d'un ou de plusieurs automates absent, après ce service n'existe pas chez tous les constructeurs et on en revient au fait qu'il faut connaitre le matos utilisé. Maintenant quand je lis qu'il y a un serveur OPC sur le site qui tape tous les automates je ne comprend pas pourquoi il n'est pas possible de mettre une supervision qui récupérerai les infos via l'OPC, c'est fait pour ça et moi si j'avais le mec de informatique qui veut pas de cette solution en face je le prendrai par le colback et je lui dirai :
Toi, tu m'fous les glandes,
pi t'as rien à foutre dans mon monde,
arrache-toi d'là, t'es pas d'ma bande
casse-toi, tu pues, et marche à l'ombre !
casse-toi, tu pues, et marche à l'ombre !
ou un truc dans le genre, pasque y'en a marre d'être emmerdé par des cons qui comprennent rien rien bordel de merde ! :mrgreen: :mrgreen: :mrgreen:

JC
"On veut faire du zéro défaut mais on a zéro bonhomme et zéro budget, et bien à la fin on a zéro résultat..."
steph68
Codeur fou
Codeur fou
Messages : 268
Inscription : 21 oct. 2015, 08:23

Re: Ajout API communiquant sans modifier les programmes des existants

Message par steph68 »

Ça ressemble à du Global Data ta solution
j'avais vu ça et Siemens propose aussi du multicast sur protocole UDP avec dialogue maitre / esclave ... il y a des exemples qui trainent sur le net ; d'autres constructeurs parlent de protocole IGMP ... bref, il y a des possibilités, à voir si cet investissement en R&D vaut le "coût" vs une supervision centrale

sinon en architecture décentralisée (plus le monde de l'informatique que de l'automatisme), il y a des systèmes qui fonctionnent comme le réseau FastTrack (Kazaa) ... en cherchant sur le net, tu devrais pouvoir trouver de bonnes infos...
on en revient au fait qu'il faut connaitre le matos utilisé
oui et non. Kallysto cherchait surtout une méthodologie (un algo), une façon d'attaquer son problème ...
donc pas besoin de connaitre le matos dans un 1er temps
après le matos limite les idées initiales si on veut rester standard "industrie" (constructeur renommé) ou exotique (raspberry, advantech, keba par exemple, et là on fait ce que l'on veut car programmable en C/C++)

@+
Avatar de l’utilisateur
sinced
Mi homme - Mi automate
Mi homme - Mi automate
Messages : 1230
Inscription : 13 oct. 2015, 16:56

Re: Ajout API communiquant sans modifier les programmes des existants

Message par sinced »

Multicast, BroadCast, EGD, sans avoir d'info sur le materiel je vois mal comment proposer. Il veut une solution abstraite avec un ensemble de contraintes, desole je ne sais pas faire je m'avoue vaincu je prefre voir Mme Soleil
Kallysto
Créateur de langage
Créateur de langage
Messages : 732
Inscription : 27 avr. 2017, 11:11
Localisation : Loin de la civilisation

Re: Ajout API communiquant sans modifier les programmes des existants

Message par Kallysto »

Lorent2 a écrit : 15 mai 2017, 18:30
Kallysto a écrit : 15 mai 2017, 15:39 L'objectif c'est d'avoir 0 arrêt de service, donc de ne pas modifier le programme API. Les pages Webs sont modifiables et rechargeables sans arrêt du service.
Les automates aussi :D
Pas ceux là.
Rechargement = figeage du process pendant et remise à 0 du process une fois le téléchargement terminé.

C'est pour cela que les programmes ne doivent pas être modifiés (indépendament de la contrainte temps / argent)
Kallysto
Créateur de langage
Créateur de langage
Messages : 732
Inscription : 27 avr. 2017, 11:11
Localisation : Loin de la civilisation

Re: Ajout API communiquant sans modifier les programmes des existants

Message par Kallysto »

steph68 a écrit : 15 mai 2017, 18:56 hello,

le plus simple serait de pouvoir faire du multicast / broadcast:

périodiquement chaque automate envoie son état sur le réseau à destination de tous les autres
mais il faudrait que tu trouves la "couche logicielle" dans ton automate pour faire ça (habituellement c'est plutot le point à point ou unicast qui est dispo)
ou bien un genre de routeur sur ton réseau qui diffuse en multicast les paquets reçus (mais il devient alors le maillon faible = concentrateur)

--> à voir pour trouver un automate gérant le multicast

les autres stratégies seraient des usines à gaz à réaliser ... (à mon avis hors de portée des automates industriels)
il te faudra synchroniser une liste de partenaires, synchroniser l'heure (pour vérifier la fraicheur des données, puisqu'il y aura des doublons à trier) ... et j'en passe

sinon comme dit au-dessus: solution du concentrateur
argumente avec ton client que le cloud est le futur de l'industrie :mrgreen:

@+

EDIT: sur ta stratégie, tu n'anticipes qu'un seul automate en panne (si 2 automates consécutifs en panne, c'est mort).
faire une chaine n'est jamais une bonne idée car il y a toujours un maillon faible
Je n'ai pas le droit au broadcast... et je n'ai aucun pouvoir de management sur le réseau (donc pas de routeur... j'y avais pensé mais non). C'est le service IT et le service sécurtié réseau qui gèrent et je demande poliment des adresses pour mes automates et écrans. Et j'attends leur bon vouloir....

"Cloud" interdit, on a déjà proposé plusieurs fois, et pas plus tard qu'en février dernier, pour un relevé automatique des conso, on s'est fait jeter propre et sec.
Je n'ai même pas accès aux APIs à distance, juste à leur pages Web à condition d'être sur la session à distance proposée et paramétrée par le service info.

Oui, le problème est compliqué.... ça fait depuis décembre que je me triture les neurones là dessus.

Le seul truc qu'il pourrait y avoir c'est le serveur OPC mais c'est pareil, c'est eux qui ont la main dessus... donc faut leur aval et on avait demandé un accès pour pouvoir remettre à jour les remonter d'alarme, on s'est fait jeter une fois de plus.

Le cas de 2 APIs en panne :
si on a les API A, B, C, D, E, F, G, qui s'écrivent dessus dans cet ordre.

C et D en panne :
A et B forment une chaine à eux seuls,
D et C sont seuls.
E et F et G forment une chaine à eux seuls.

Donc les infos nouvelles de C D E F G n'arrivent plus sur A et B
Donc les infos nouvelles de A B C D n'arrivent plus sur E et F et G

Je ne vois pas d'autres implications ? (j'ai loupé un truc ?) Il y a un risque que ça ne redémarre pas propre ?

C'est pas le top les chaines mais je ne crois pas qu'il y ait une solution "totaly safe".
Kallysto
Créateur de langage
Créateur de langage
Messages : 732
Inscription : 27 avr. 2017, 11:11
Localisation : Loin de la civilisation

Re: Ajout API communiquant sans modifier les programmes des existants

Message par Kallysto »

steph68 a écrit : 15 mai 2017, 23:14
Ça ressemble à du Global Data ta solution
j'avais vu ça et Siemens propose aussi du multicast sur protocole UDP avec dialogue maitre / esclave ... il y a des exemples qui trainent sur le net ; d'autres constructeurs parlent de protocole IGMP ... bref, il y a des possibilités, à voir si cet investissement en R&D vaut le "coût" vs une supervision centrale

sinon en architecture décentralisée (plus le monde de l'informatique que de l'automatisme), il y a des systèmes qui fonctionnent comme le réseau FastTrack (Kazaa) ... en cherchant sur le net, tu devrais pouvoir trouver de bonnes infos...
on en revient au fait qu'il faut connaitre le matos utilisé
oui et non. Kallysto cherchait surtout une méthodologie (un algo), une façon d'attaquer son problème ...
donc pas besoin de connaitre le matos dans un 1er temps
après le matos limite les idées initiales si on veut rester standard "industrie" (constructeur renommé) ou exotique (raspberry, advantech, keba par exemple, et là on fait ce que l'on veut car programmable en C/C++)

@+
Le langage de programmation n'a pas de nom... on pourrait dire que c'est du "fonction block" ça pourrait être un lointain cousin du ladder, ou du ladder très très évolué et beaucoup moins rigide.

Constructeur renommé dans le domaine oui (équipe les systèmes de vie des bâteaux de la Marine Nationale, par exemple) ^^ mais pas dans l'industrie.

Et oui, c'est ça. Mes APIs communiquent en S-Bus IP. Cette donnée ne vous sert pas à grand chose vu que vous ne connaissez pas le protocole.

La supervision centrale... si un jour on en met une, c'est le client qui programmera son truc à lui... Il se recréera son logiciel "PCVue"/ "Panorama"... Donc je vais pas pousser dans cette direction, c'est déjà assez le bordel comme ça !
Il y a 4 ans ça aurait été une idée sympas mais pas maintenant qu'il y a des automates de partout sans une vraie ligne commune (ce que je "réclame" depuis 4 ans...)
Répondre