Client interne au serveur

Le
Forje
Bonjour,

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.

--
Forje
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Pimousse
Le #542532
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

-->
http://www.nexen.net/docs/php/annotee/features.commandline.php?lien=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
Le #542528
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 :)
Regis
Le #542530
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
Le #536872

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


MERCIER Pascal
Le #536870
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
Le #536311

.../...

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 #538306
le 18/02/04 19:43, Forje
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

Poster une réponse
Anonyme