Je sollicite votre expérience pour émettre un avis sur la pertinence
d'une architecture client serveur basée sur PHP un peu spéciale :
Le projet consiste réaliser un système de communication avec des
équipements industriels par le biais de modems radio (868 MHz). Les
communications ont pour objectif de maintenir à jour différents
paramètres des équipements et de récupérer des remontées d'alarmes.
Le fonctionnement est semi temps-réel dans le sens où la rapidité des
échanges n'est absolument pas prioritaire, avec cependant une notion de
service permanent bien que l'interface utilisateur soit asynchrone des
actions de communication radio. En clair, l'utilisateur fixe des
paramètres ou consulte des informations qui ne sont pas transmises au
moment de la consultation mais éventuellement en temps différé.
L'idée que j'ai pour l'instant est d'utiliser un PC de type industriel
(sans écran ni clavier en fonctionnement normal) fonctionnant sous linux
sur réseau ethernet et équipé d'un modem radio (sur port série).
Le système est configuré via une interface de type web (serveur Apache,
pages générées en PHP, base de données MySql).
Le fonctionnement avec le réseau radio est régi par un automate
(logiciel tournant en tâche de fond) qui se charge de communiquer avec
les équipements à surveiller (via un protocole série).
Mes interrogations portent sur la manière de faire "communiquer" la
partie "PHP/MySql" et la partie communication radio. En effet, l'idéal
serait pour moi de pouvoir faire exécuter en "local" des scripts PHP
pour accéder aux données de la base, et de profiter ainsi de toutes les
facilités qu'offre le langage PHP dans ce domaine. De même, une telle
architecture ouvrirait à l'avenir des possibilités d'envoi d'un email
sur alarme par exemple.
En résumé, quelqu'un a-t-il l'expérience d'un tel système dans lequel il
y a en quelque sorte un "client" PHP un peu spécial, se présentant sous
la forme d'un logiciel tournant en fond sur le serveur lui-même ?
Je ne sais pas si tout cela est bien clair...
Merci d'avance à ceux qui pourront apporter leur aide.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pimousse
Bonjour,
juste qq idées
- ton syst ne nécessite pas d'être en temps réel : tu peux dc fonctionner avec le cron de linux en appelant de tps à autres un fichier php en ligne de commande
- ce fichier fera le pont entre le format d'arriver des données de ton logiciel radio (fichier txt ?) vers la bdd en parsant tes données.
- après tu n'auras plus qu'à consulter par le navigateur
- tes alarmes peuvent déclencher l'envoi de mail via le même principe de cron, soit directement à l'insertion des données ds la bdd (ou même au moment du "parsage") soit en différé via un autre cron
A vous .... :D
Bonjour,
juste qq idées
- ton syst ne nécessite pas d'être en temps réel : tu peux dc
fonctionner avec le cron de linux en appelant de tps à autres un fichier
php en ligne de commande
- ce fichier fera le pont entre le format d'arriver des données de ton
logiciel radio (fichier txt ?) vers la bdd en parsant tes données.
- après tu n'auras plus qu'à consulter par le navigateur
- tes alarmes peuvent déclencher l'envoi de mail via le même principe de
cron, soit directement à l'insertion des données ds la bdd (ou même au
moment du "parsage") soit en différé via un autre cron
- ton syst ne nécessite pas d'être en temps réel : tu peux dc fonctionner avec le cron de linux en appelant de tps à autres un fichier php en ligne de commande
- ce fichier fera le pont entre le format d'arriver des données de ton logiciel radio (fichier txt ?) vers la bdd en parsant tes données.
- après tu n'auras plus qu'à consulter par le navigateur
- tes alarmes peuvent déclencher l'envoi de mail via le même principe de cron, soit directement à l'insertion des données ds la bdd (ou même au moment du "parsage") soit en différé via un autre cron
A vous .... :D
charly
Pas d'expérience mais voici une suggestion :
Tu dois rendre ton automate capable d'émettre des requetes de type HTTP et d'en lire les réponses renvoyées par ton serveur Apache - PHP - MySQL. Tu peux aussi implémenter une solution JAVA - SOAP si tu préfères : ton automate doit à ce moment intégrer un encodeur/parseur XML.
Voila, ya plus ka ki disent :)
Pas d'expérience mais voici une suggestion :
Tu dois rendre ton automate capable d'émettre des requetes de type HTTP
et d'en lire les réponses renvoyées par ton serveur Apache - PHP -
MySQL. Tu peux aussi implémenter une solution JAVA - SOAP si tu préfères
: ton automate doit à ce moment intégrer un encodeur/parseur XML.
Tu dois rendre ton automate capable d'émettre des requetes de type HTTP et d'en lire les réponses renvoyées par ton serveur Apache - PHP - MySQL. Tu peux aussi implémenter une solution JAVA - SOAP si tu préfères : ton automate doit à ce moment intégrer un encodeur/parseur XML.
Voila, ya plus ka ki disent :)
Regis
Le Mon, 16 Feb 2004 15:25:22 +0000, Forje a écrit :
Bonjour,
Bonsoir
Je sollicite votre expérience pour émettre un avis sur la pertinence d'une architecture client serveur basée sur PHP un peu spéciale :
Je vais essayé de voir si j'ai compris ce que tu dis puisque que j'ai une formation d'électricien indus :
Le projet consiste réaliser un système de communication avec des équipements industriels par le biais de modems radio (868 MHz). Les communications ont pour objectif de maintenir à jour différents paramètres des équipements et de récupérer des remontées d'alarmes.
J'ai déjà vu fonctionné sur des robots mobiles
En gros tu as un serveur qui communique avec des clients à distance (que ce soit par fils ou par radio.
Ton serveur est un LAMP (Linux Apache MySQL PHP) et ton plus gros problème est l'interface entre le résultat du serveur et le client distant via un automate.
J'ai bon ?
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog C/C++ via exec(), passthru() ou system(). C'est du moins ce que j'essayerais de faire en premier.
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de secret industriel)
<?php snip(); ?>
Je ne sais pas si tout cela est bien clair...
Pas vraiment
Merci d'avance à ceux qui pourront apporter leur aide.
Je fais ce que je peux
-- Beuvez Beuvez mais bourré jamais ! Drink drink but never Drunk ! (Rabelais)
Le Mon, 16 Feb 2004 15:25:22 +0000, Forje a écrit :
Bonjour,
Bonsoir
Je sollicite votre expérience pour émettre un avis sur la pertinence
d'une architecture client serveur basée sur PHP un peu spéciale :
Je vais essayé de voir si j'ai compris ce que tu dis puisque que j'ai une
formation d'électricien indus :
Le projet consiste réaliser un système de communication avec des
équipements industriels par le biais de modems radio (868 MHz). Les
communications ont pour objectif de maintenir à jour différents
paramètres des équipements et de récupérer des remontées d'alarmes.
J'ai déjà vu fonctionné sur des robots mobiles
En gros tu as un serveur qui communique avec des clients à distance (que
ce soit par fils ou par radio.
Ton serveur est un LAMP (Linux Apache MySQL PHP) et ton plus gros
problème est l'interface entre le résultat du serveur et le client
distant via un automate.
J'ai bon ?
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog
C/C++ via exec(), passthru() ou system(). C'est du moins ce que
j'essayerais de faire en premier.
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de
secret industriel)
<?php snip(); ?>
Je ne sais pas si tout cela est bien clair...
Pas vraiment
Merci d'avance à ceux qui pourront apporter leur aide.
Je fais ce que je peux
--
Beuvez Beuvez mais bourré jamais !
Drink drink but never Drunk !
(Rabelais)
Le Mon, 16 Feb 2004 15:25:22 +0000, Forje a écrit :
Bonjour,
Bonsoir
Je sollicite votre expérience pour émettre un avis sur la pertinence d'une architecture client serveur basée sur PHP un peu spéciale :
Je vais essayé de voir si j'ai compris ce que tu dis puisque que j'ai une formation d'électricien indus :
Le projet consiste réaliser un système de communication avec des équipements industriels par le biais de modems radio (868 MHz). Les communications ont pour objectif de maintenir à jour différents paramètres des équipements et de récupérer des remontées d'alarmes.
J'ai déjà vu fonctionné sur des robots mobiles
En gros tu as un serveur qui communique avec des clients à distance (que ce soit par fils ou par radio.
Ton serveur est un LAMP (Linux Apache MySQL PHP) et ton plus gros problème est l'interface entre le résultat du serveur et le client distant via un automate.
J'ai bon ?
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog C/C++ via exec(), passthru() ou system(). C'est du moins ce que j'essayerais de faire en premier.
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de secret industriel)
<?php snip(); ?>
Je ne sais pas si tout cela est bien clair...
Pas vraiment
Merci d'avance à ceux qui pourront apporter leur aide.
Je fais ce que je peux
-- Beuvez Beuvez mais bourré jamais ! Drink drink but never Drunk ! (Rabelais)
Forje
Bonjour,
Bonsoir
Bonsoir,
Je sollicite votre expérience pour émettre un avis sur la pertinence d'une architecture client serveur basée sur PHP un peu spéciale :
Je vais essayé de voir si j'ai compris ce que tu dis puisque que j'ai une formation d'électricien indus :
Le projet consiste réaliser un système de communication avec des équipements industriels par le biais de modems radio (868 MHz). Les communications ont pour objectif de maintenir à jour différents paramètres des équipements et de récupérer des remontées d'alarmes.
J'ai déjà vu fonctionné sur des robots mobiles
En gros tu as un serveur qui communique avec des clients à distance (que ce soit par fils ou par radio.
C'est bien ça. La physique des choses n'a en effet pas ou peu d'importance.
Ton serveur est un LAMP (Linux Apache MySQL PHP) et ton plus gros problème est l'interface entre le résultat du serveur et le client distant via un automate.
J'ai bon ?
Exact.
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog C/C++ via exec(), passthru() ou system(). C'est du moins ce que j'essayerais de faire en premier.
Le PHP doit être "esclave". Dans son message plus haut Pimousse propose de lancer périodiquement des scripts en ligne de commande. Je pense que vais effectivement tenter quelque chose dans ce genre là. Exemple, toutes les 15 min, exécution d'un script, lancé par cron, qui va procéder à la tournée de tous les équipements pour relève des alarmes et éventuellement mise à jour des paramètres selon état de la base. J'ai commencé à regarder le traitement des ports comm depuis PHP, ça n'a pas l'air très commun (pas facile de gérer la réception de caractères) mais ça a le mérite d'exister (fopen, fputs, etc...). Je vais creuser un peu avant d'appeler au secours. Et si trop complexe en PHP je trouverai bien un autre moyen.
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de secret industriel)
Le fonctionnement décrit plus haut sera limité à une configuration PC maître, ce qui me convient dans un premier temps. Plus tard, il y aura des équipements susceptibles de s'adresser spontanéement au PC. Il faudra alors un autre système (une activation périodique ne suffira plus) l'arrivée d'un message devra pouvoir provoquer l'exécution d'un script.
<?php snip(); ?>
Je ne sais pas si tout cela est bien clair...
Pas vraiment
Ta transcription n'est pas si éloigné de ce que j'avais en tête au moment de mon message.
Merci d'avance à ceux qui pourront apporter leur aide.
Je fais ce que je peux
Merci à toi et aussi à Pimousse et Charly.
-- Forje
Bonjour,
Bonsoir
Bonsoir,
Je sollicite votre expérience pour émettre un avis sur la pertinence
d'une architecture client serveur basée sur PHP un peu spéciale :
Je vais essayé de voir si j'ai compris ce que tu dis puisque que j'ai une
formation d'électricien indus :
Le projet consiste réaliser un système de communication avec des
équipements industriels par le biais de modems radio (868 MHz). Les
communications ont pour objectif de maintenir à jour différents
paramètres des équipements et de récupérer des remontées d'alarmes.
J'ai déjà vu fonctionné sur des robots mobiles
En gros tu as un serveur qui communique avec des clients à distance (que
ce soit par fils ou par radio.
C'est bien ça. La physique des choses n'a en effet pas ou peu d'importance.
Ton serveur est un LAMP (Linux Apache MySQL PHP) et ton plus gros
problème est l'interface entre le résultat du serveur et le client
distant via un automate.
J'ai bon ?
Exact.
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog
C/C++ via exec(), passthru() ou system(). C'est du moins ce que
j'essayerais de faire en premier.
Le PHP doit être "esclave". Dans son message plus haut Pimousse propose
de lancer périodiquement des scripts en ligne de commande. Je pense que
vais effectivement tenter quelque chose dans ce genre là. Exemple,
toutes les 15 min, exécution d'un script, lancé par cron, qui va
procéder à la tournée de tous les équipements pour relève des alarmes et
éventuellement mise à jour des paramètres selon état de la base. J'ai
commencé à regarder le traitement des ports comm depuis PHP, ça n'a pas
l'air très commun (pas facile de gérer la réception de caractères) mais
ça a le mérite d'exister (fopen, fputs, etc...). Je vais creuser un peu
avant d'appeler au secours. Et si trop complexe en PHP je trouverai bien
un autre moyen.
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de
secret industriel)
Le fonctionnement décrit plus haut sera limité à une configuration PC
maître, ce qui me convient dans un premier temps.
Plus tard, il y aura des équipements susceptibles de s'adresser
spontanéement au PC.
Il faudra alors un autre système (une activation périodique ne suffira
plus) l'arrivée d'un message devra pouvoir provoquer l'exécution d'un
script.
<?php snip(); ?>
Je ne sais pas si tout cela est bien clair...
Pas vraiment
Ta transcription n'est pas si éloigné de ce que j'avais en tête au
moment de mon message.
Merci d'avance à ceux qui pourront apporter leur aide.
Je sollicite votre expérience pour émettre un avis sur la pertinence d'une architecture client serveur basée sur PHP un peu spéciale :
Je vais essayé de voir si j'ai compris ce que tu dis puisque que j'ai une formation d'électricien indus :
Le projet consiste réaliser un système de communication avec des équipements industriels par le biais de modems radio (868 MHz). Les communications ont pour objectif de maintenir à jour différents paramètres des équipements et de récupérer des remontées d'alarmes.
J'ai déjà vu fonctionné sur des robots mobiles
En gros tu as un serveur qui communique avec des clients à distance (que ce soit par fils ou par radio.
C'est bien ça. La physique des choses n'a en effet pas ou peu d'importance.
Ton serveur est un LAMP (Linux Apache MySQL PHP) et ton plus gros problème est l'interface entre le résultat du serveur et le client distant via un automate.
J'ai bon ?
Exact.
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog C/C++ via exec(), passthru() ou system(). C'est du moins ce que j'essayerais de faire en premier.
Le PHP doit être "esclave". Dans son message plus haut Pimousse propose de lancer périodiquement des scripts en ligne de commande. Je pense que vais effectivement tenter quelque chose dans ce genre là. Exemple, toutes les 15 min, exécution d'un script, lancé par cron, qui va procéder à la tournée de tous les équipements pour relève des alarmes et éventuellement mise à jour des paramètres selon état de la base. J'ai commencé à regarder le traitement des ports comm depuis PHP, ça n'a pas l'air très commun (pas facile de gérer la réception de caractères) mais ça a le mérite d'exister (fopen, fputs, etc...). Je vais creuser un peu avant d'appeler au secours. Et si trop complexe en PHP je trouverai bien un autre moyen.
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de secret industriel)
Le fonctionnement décrit plus haut sera limité à une configuration PC maître, ce qui me convient dans un premier temps. Plus tard, il y aura des équipements susceptibles de s'adresser spontanéement au PC. Il faudra alors un autre système (une activation périodique ne suffira plus) l'arrivée d'un message devra pouvoir provoquer l'exécution d'un script.
<?php snip(); ?>
Je ne sais pas si tout cela est bien clair...
Pas vraiment
Ta transcription n'est pas si éloigné de ce que j'avais en tête au moment de mon message.
Merci d'avance à ceux qui pourront apporter leur aide.
Je fais ce que je peux
Merci à toi et aussi à Pimousse et Charly.
-- Forje
MERCIER Pascal
Je vais essayé de voir si j'ai compris ce que tu dis puisque que j'ai une formation d'électricien indus :
Le projet consiste réaliser un système de communication avec des équipements industriels par le biais de modems radio (868 MHz). Les communications ont pour objectif de maintenir à jour différents paramètres des équipements et de récupérer des remontées d'alarmes.
J'ai déjà vu fonctionné sur des robots mobiles
En gros tu as un serveur qui communique avec des clients à distance (que ce soit par fils ou par radio.
C'est bien ça. La physique des choses n'a en effet pas ou peu d'importance.
Ton serveur est un LAMP (Linux Apache MySQL PHP) et ton plus gros problème est l'interface entre le résultat du serveur et le client distant via un automate. J'ai bon ?
Exact.
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog C/C++ via exec(), passthru() ou system(). C'est du moins ce que j'essayerais de faire en premier.
Pour des raisons de sécurité "évidentes", évitez au possible d'utiliser exec, passthru ou system. Si votre automate est capable de créer et de communiquer via un PIPE, alors c'est la solution a préférer.
Le PHP doit être "esclave". Dans son message plus haut Pimousse propose de lancer périodiquement des scripts en ligne de commande. Je pense que vais effectivement tenter quelque chose dans ce genre là. Exemple, toutes les 15 min, exécution d'un script, lancé par cron, qui va procéder à la tournée de tous les équipements pour relève des alarmes et éventuellement mise à jour des paramètres selon état de la base. J'ai commencé à regarder le traitement des ports comm depuis PHP, ça n'a pas l'air très commun (pas facile de gérer la réception de caractères) mais ça a le mérite d'exister (fopen, fputs, etc...). Je vais creuser un peu avant d'appeler au secours. Et si trop complexe en PHP je trouverai bien un autre moyen.
Voir ci-dessus. Voyez les moyens mis à votre disposition par l'automate pour s'interfacer avec l'exterieur.
<petit délire> Si vous êtes motivé vous pourriez aussi porter votre automate en PHP. </petit délire>
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de secret industriel)
Le fonctionnement décrit plus haut sera limité à une configuration PC maître, ce qui me convient dans un premier temps. Plus tard, il y aura des équipements susceptibles de s'adresser spontanéement au PC. Il faudra alors un autre système (une activation périodique ne suffira plus) l'arrivée d'un message devra pouvoir provoquer l'exécution d'un script.
Utilisation d'un inetd, xinetd ou d'un autre tcp wrapper. Lorsque vos autres équipements ouvrent une connexion sur votre serveur maitre, le wrapper lancera une session de votre script/programme. Votre script se verra assigné un socket par le wrapper. Socket que vous utiliserez pour communiquer avec son client.
Je vais essayé de voir si j'ai compris ce que tu dis puisque que j'ai une
formation d'électricien indus :
Le projet consiste réaliser un système de communication avec des
équipements industriels par le biais de modems radio (868 MHz). Les
communications ont pour objectif de maintenir à jour différents
paramètres des équipements et de récupérer des remontées d'alarmes.
J'ai déjà vu fonctionné sur des robots mobiles
En gros tu as un serveur qui communique avec des clients à distance (que
ce soit par fils ou par radio.
C'est bien ça. La physique des choses n'a en effet pas ou peu d'importance.
Ton serveur est un LAMP (Linux Apache MySQL PHP) et ton plus gros
problème est l'interface entre le résultat du serveur et le client
distant via un automate.
J'ai bon ?
Exact.
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog
C/C++ via exec(), passthru() ou system(). C'est du moins ce que
j'essayerais de faire en premier.
Pour des raisons de sécurité "évidentes", évitez au possible d'utiliser exec,
passthru ou system.
Si votre automate est capable de créer et de communiquer via un PIPE, alors
c'est la solution a préférer.
Le PHP doit être "esclave". Dans son message plus haut Pimousse propose
de lancer périodiquement des scripts en ligne de commande. Je pense que
vais effectivement tenter quelque chose dans ce genre là. Exemple,
toutes les 15 min, exécution d'un script, lancé par cron, qui va
procéder à la tournée de tous les équipements pour relève des alarmes et
éventuellement mise à jour des paramètres selon état de la base. J'ai
commencé à regarder le traitement des ports comm depuis PHP, ça n'a pas
l'air très commun (pas facile de gérer la réception de caractères) mais
ça a le mérite d'exister (fopen, fputs, etc...). Je vais creuser un peu
avant d'appeler au secours. Et si trop complexe en PHP je trouverai bien
un autre moyen.
Voir ci-dessus.
Voyez les moyens mis à votre disposition par l'automate pour s'interfacer avec
l'exterieur.
<petit délire>
Si vous êtes motivé vous pourriez aussi porter votre automate en PHP.
</petit délire>
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de
secret industriel)
Le fonctionnement décrit plus haut sera limité à une configuration PC
maître, ce qui me convient dans un premier temps.
Plus tard, il y aura des équipements susceptibles de s'adresser
spontanéement au PC.
Il faudra alors un autre système (une activation périodique ne suffira
plus) l'arrivée d'un message devra pouvoir provoquer l'exécution d'un
script.
Utilisation d'un inetd, xinetd ou d'un autre tcp wrapper.
Lorsque vos autres équipements ouvrent une connexion sur votre serveur maitre,
le wrapper lancera une session de votre script/programme. Votre script se verra
assigné un socket par le wrapper. Socket que vous utiliserez pour communiquer
avec son client.
Je vais essayé de voir si j'ai compris ce que tu dis puisque que j'ai une formation d'électricien indus :
Le projet consiste réaliser un système de communication avec des équipements industriels par le biais de modems radio (868 MHz). Les communications ont pour objectif de maintenir à jour différents paramètres des équipements et de récupérer des remontées d'alarmes.
J'ai déjà vu fonctionné sur des robots mobiles
En gros tu as un serveur qui communique avec des clients à distance (que ce soit par fils ou par radio.
C'est bien ça. La physique des choses n'a en effet pas ou peu d'importance.
Ton serveur est un LAMP (Linux Apache MySQL PHP) et ton plus gros problème est l'interface entre le résultat du serveur et le client distant via un automate. J'ai bon ?
Exact.
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog C/C++ via exec(), passthru() ou system(). C'est du moins ce que j'essayerais de faire en premier.
Pour des raisons de sécurité "évidentes", évitez au possible d'utiliser exec, passthru ou system. Si votre automate est capable de créer et de communiquer via un PIPE, alors c'est la solution a préférer.
Le PHP doit être "esclave". Dans son message plus haut Pimousse propose de lancer périodiquement des scripts en ligne de commande. Je pense que vais effectivement tenter quelque chose dans ce genre là. Exemple, toutes les 15 min, exécution d'un script, lancé par cron, qui va procéder à la tournée de tous les équipements pour relève des alarmes et éventuellement mise à jour des paramètres selon état de la base. J'ai commencé à regarder le traitement des ports comm depuis PHP, ça n'a pas l'air très commun (pas facile de gérer la réception de caractères) mais ça a le mérite d'exister (fopen, fputs, etc...). Je vais creuser un peu avant d'appeler au secours. Et si trop complexe en PHP je trouverai bien un autre moyen.
Voir ci-dessus. Voyez les moyens mis à votre disposition par l'automate pour s'interfacer avec l'exterieur.
<petit délire> Si vous êtes motivé vous pourriez aussi porter votre automate en PHP. </petit délire>
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de secret industriel)
Le fonctionnement décrit plus haut sera limité à une configuration PC maître, ce qui me convient dans un premier temps. Plus tard, il y aura des équipements susceptibles de s'adresser spontanéement au PC. Il faudra alors un autre système (une activation périodique ne suffira plus) l'arrivée d'un message devra pouvoir provoquer l'exécution d'un script.
Utilisation d'un inetd, xinetd ou d'un autre tcp wrapper. Lorsque vos autres équipements ouvrent une connexion sur votre serveur maitre, le wrapper lancera une session de votre script/programme. Votre script se verra assigné un socket par le wrapper. Socket que vous utiliserez pour communiquer avec son client.
Forje
.../...
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog C/C++ via exec(), passthru() ou system(). C'est du moins ce que j'essayerais de faire en premier.
Pour des raisons de sécurité "évidentes", évitez au possible d'utiliser exec, passthru ou system. Si votre automate est capable de créer et de communiquer via un PIPE, alors c'est la solution a préférer.
Encore qu'ici la sécurité n'est pas trop un pb. Il s'agit d'un réseau interne.
Le PHP doit être "esclave". Dans son message plus haut Pimousse propose de lancer périodiquement des scripts en ligne de commande. Je pense que vais effectivement tenter quelque chose dans ce genre là. Exemple, toutes les 15 min, exécution d'un script, lancé par cron, qui va procéder à la tournée de tous les équipements pour relève des alarmes et éventuellement mise à jour des paramètres selon état de la base. J'ai commencé à regarder le traitement des ports comm depuis PHP, ça n'a pas l'air très commun (pas facile de gérer la réception de caractères) mais ça a le mérite d'exister (fopen, fputs, etc...). Je vais creuser un peu avant d'appeler au secours. Et si trop complexe en PHP je trouverai bien un autre moyen.
Voir ci-dessus. Voyez les moyens mis à votre disposition par l'automate pour s'interfacer avec l'exterieur.
<petit délire> Si vous êtes motivé vous pourriez aussi porter votre automate en PHP. </petit délire>
La difficulté semble être de garantir la capture de TOUS les caractères venant sur le port com à partir du PHP.
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de secret industriel)
Le fonctionnement décrit plus haut sera limité à une configuration PC maître, ce qui me convient dans un premier temps. Plus tard, il y aura des équipements susceptibles de s'adresser spontanéement au PC. Il faudra alors un autre système (une activation périodique ne suffira plus) l'arrivée d'un message devra pouvoir provoquer l'exécution d'un script.
Utilisation d'un inetd, xinetd ou d'un autre tcp wrapper. Lorsque vos autres équipements ouvrent une connexion sur votre serveur maitre, le wrapper lancera une session de votre script/programme. Votre script se verra assigné un socket par le wrapper. Socket que vous utiliserez pour communiquer avec son client.
Les messages des équipements arrive sur un port com série du PC. Je ne connais pas trop les inetd et autres wrappers mais j'ai l'impression que cela ne convient pas. Ce qu'il me faudrait c'est plutôt un tampon avec FIFO de messages en attente reçus en temps réel du port comm et lu en temps différé par un script pour arriver à palier la difficulté de traiter tout ça entièrement par PHP.
Quoiqu'il en soit merci pour vos conseils.
-- Forje
.../...
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog
C/C++ via exec(), passthru() ou system(). C'est du moins ce que
j'essayerais de faire en premier.
Pour des raisons de sécurité "évidentes", évitez au possible d'utiliser
exec, passthru ou system.
Si votre automate est capable de créer et de communiquer via un PIPE,
alors c'est la solution a préférer.
Encore qu'ici la sécurité n'est pas trop un pb. Il s'agit d'un réseau
interne.
Le PHP doit être "esclave". Dans son message plus haut Pimousse
propose de lancer périodiquement des scripts en ligne de commande. Je
pense que vais effectivement tenter quelque chose dans ce genre là.
Exemple, toutes les 15 min, exécution d'un script, lancé par cron, qui
va procéder à la tournée de tous les équipements pour relève des
alarmes et éventuellement mise à jour des paramètres selon état de la
base. J'ai commencé à regarder le traitement des ports comm depuis
PHP, ça n'a pas l'air très commun (pas facile de gérer la réception de
caractères) mais ça a le mérite d'exister (fopen, fputs, etc...). Je
vais creuser un peu avant d'appeler au secours. Et si trop complexe en
PHP je trouverai bien un autre moyen.
Voir ci-dessus.
Voyez les moyens mis à votre disposition par l'automate pour
s'interfacer avec l'exterieur.
<petit délire>
Si vous êtes motivé vous pourriez aussi porter votre automate en PHP.
</petit délire>
La difficulté semble être de garantir la capture de TOUS les caractères
venant sur le port com à partir du PHP.
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de
secret industriel)
Le fonctionnement décrit plus haut sera limité à une configuration PC
maître, ce qui me convient dans un premier temps.
Plus tard, il y aura des équipements susceptibles de s'adresser
spontanéement au PC.
Il faudra alors un autre système (une activation périodique ne suffira
plus) l'arrivée d'un message devra pouvoir provoquer l'exécution d'un
script.
Utilisation d'un inetd, xinetd ou d'un autre tcp wrapper.
Lorsque vos autres équipements ouvrent une connexion sur votre serveur
maitre, le wrapper lancera une session de votre script/programme. Votre
script se verra assigné un socket par le wrapper. Socket que vous
utiliserez pour communiquer avec son client.
Les messages des équipements arrive sur un port com série du PC. Je ne
connais pas trop les inetd et autres wrappers mais j'ai l'impression que
cela ne convient pas. Ce qu'il me faudrait c'est plutôt un tampon avec
FIFO de messages en attente reçus en temps réel du port comm et lu en
temps différé par un script pour arriver à palier la difficulté de
traiter tout ça entièrement par PHP.
Tu pourrais par exemple executer des scripts bash/perl/php ou un prog C/C++ via exec(), passthru() ou system(). C'est du moins ce que j'essayerais de faire en premier.
Pour des raisons de sécurité "évidentes", évitez au possible d'utiliser exec, passthru ou system. Si votre automate est capable de créer et de communiquer via un PIPE, alors c'est la solution a préférer.
Encore qu'ici la sécurité n'est pas trop un pb. Il s'agit d'un réseau interne.
Le PHP doit être "esclave". Dans son message plus haut Pimousse propose de lancer périodiquement des scripts en ligne de commande. Je pense que vais effectivement tenter quelque chose dans ce genre là. Exemple, toutes les 15 min, exécution d'un script, lancé par cron, qui va procéder à la tournée de tous les équipements pour relève des alarmes et éventuellement mise à jour des paramètres selon état de la base. J'ai commencé à regarder le traitement des ports comm depuis PHP, ça n'a pas l'air très commun (pas facile de gérer la réception de caractères) mais ça a le mérite d'exister (fopen, fputs, etc...). Je vais creuser un peu avant d'appeler au secours. Et si trop complexe en PHP je trouverai bien un autre moyen.
Voir ci-dessus. Voyez les moyens mis à votre disposition par l'automate pour s'interfacer avec l'exterieur.
<petit délire> Si vous êtes motivé vous pourriez aussi porter votre automate en PHP. </petit délire>
La difficulté semble être de garantir la capture de TOUS les caractères venant sur le port com à partir du PHP.
Plus de précisions seraient bienvenues (sans bien sûr dévoiler de secret industriel)
Le fonctionnement décrit plus haut sera limité à une configuration PC maître, ce qui me convient dans un premier temps. Plus tard, il y aura des équipements susceptibles de s'adresser spontanéement au PC. Il faudra alors un autre système (une activation périodique ne suffira plus) l'arrivée d'un message devra pouvoir provoquer l'exécution d'un script.
Utilisation d'un inetd, xinetd ou d'un autre tcp wrapper. Lorsque vos autres équipements ouvrent une connexion sur votre serveur maitre, le wrapper lancera une session de votre script/programme. Votre script se verra assigné un socket par le wrapper. Socket que vous utiliserez pour communiquer avec son client.
Les messages des équipements arrive sur un port com série du PC. Je ne connais pas trop les inetd et autres wrappers mais j'ai l'impression que cela ne convient pas. Ce qu'il me faudrait c'est plutôt un tampon avec FIFO de messages en attente reçus en temps réel du port comm et lu en temps différé par un script pour arriver à palier la difficulté de traiter tout ça entièrement par PHP.
Quoiqu'il en soit merci pour vos conseils.
-- Forje
LJVD
le 18/02/04 19:43, Forje a écrit :
La difficulté semble être de garantir la capture de TOUS les caractères venant sur le port com à partir du PHP.
Tu peux utiliser un protocole de comm type modbus ou autre, pour faire un retour d'info vers le processus qui t'envoi l'info, utiliser un checksum de trame, ou le ack/nack du rs232. La sécurité de ta comm dépend grandement de l'équipement avec lequel tu communiques et de la qualité du protocole que tu vas pouvoir implémenter ;-)
Les messages des équipements arrive sur un port com série du PC. Je ne connais pas trop les inetd et autres wrappers mais j'ai l'impression que cela ne convient pas. Ce qu'il me faudrait c'est plutôt un tampon avec FIFO de messages en attente reçus en temps réel du port comm et lu en temps différé par un script pour arriver à palier la difficulté de traiter tout ça entièrement par PHP.
Regarde dans les historiques du groupe de news fr.sci.automatique , Yves Fuchs a implémenté un modbus ( protocole de communication) avec un PHP 4,0,6 ...
Sinon, il existe des modules hard qui font usage de passerelle rs232/ ethernet qui peuvent te simplifier la vie.
-- LJVD http://www.ljvd.com
le 18/02/04 19:43, Forje <forje@alussinan.org> a écrit :
La difficulté semble être de garantir la capture de TOUS les caractères
venant sur le port com à partir du PHP.
Tu peux utiliser un protocole de comm type modbus ou autre, pour faire un
retour d'info vers le processus qui t'envoi l'info, utiliser un checksum de
trame, ou le ack/nack du rs232.
La sécurité de ta comm dépend grandement de l'équipement avec lequel tu
communiques et de la qualité du protocole que tu vas pouvoir implémenter ;-)
Les messages des équipements arrive sur un port com série du PC. Je ne
connais pas trop les inetd et autres wrappers mais j'ai l'impression que
cela ne convient pas. Ce qu'il me faudrait c'est plutôt un tampon avec
FIFO de messages en attente reçus en temps réel du port comm et lu en
temps différé par un script pour arriver à palier la difficulté de
traiter tout ça entièrement par PHP.
Regarde dans les historiques du groupe de news fr.sci.automatique ,
Yves Fuchs a implémenté un modbus ( protocole de communication)
avec un PHP 4,0,6 ...
Sinon, il existe des modules hard qui font usage de passerelle rs232/
ethernet qui peuvent te simplifier la vie.
La difficulté semble être de garantir la capture de TOUS les caractères venant sur le port com à partir du PHP.
Tu peux utiliser un protocole de comm type modbus ou autre, pour faire un retour d'info vers le processus qui t'envoi l'info, utiliser un checksum de trame, ou le ack/nack du rs232. La sécurité de ta comm dépend grandement de l'équipement avec lequel tu communiques et de la qualité du protocole que tu vas pouvoir implémenter ;-)
Les messages des équipements arrive sur un port com série du PC. Je ne connais pas trop les inetd et autres wrappers mais j'ai l'impression que cela ne convient pas. Ce qu'il me faudrait c'est plutôt un tampon avec FIFO de messages en attente reçus en temps réel du port comm et lu en temps différé par un script pour arriver à palier la difficulté de traiter tout ça entièrement par PHP.
Regarde dans les historiques du groupe de news fr.sci.automatique , Yves Fuchs a implémenté un modbus ( protocole de communication) avec un PHP 4,0,6 ...
Sinon, il existe des modules hard qui font usage de passerelle rs232/ ethernet qui peuvent te simplifier la vie.
