Forum automatisme

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

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...

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

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

@+

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

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

@+

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 !

JC

Ç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++)

@+

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

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

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)

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

@+

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".

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...)