Page 1 sur 1

Limites des embedded computer

Posté : mar. 21 févr. 2017 09:54
par Richard05
Bonjour à tous,

Possesseur d'une RPI2 à la maison pour le contrôle à distance de mon imprimante 3D (par réseau local), je ne suis tout de même pas un pro niveau technique de ces nouveaux (plus si nouveaux!) petits bijoux. Arduino, RPI, BananaPi, Orange Pi, je sais que je généralise alors que c'est un forum spécial RPI, mais justement c'est pour une future acquisition d'une RPI3, et j'hésite. Tous ces nouveaux Embedded computers, j'aurais aimé connaitre leurs limites (de manière générale). En effet, pour avoir un prix aussi attractif, leur industrialisé adapté pour n'importe quel user lambda et pas uniquement à l'industrie rend la chose me semble-t-il plus fragile. Je sais que la puissance de calcul de ces miniPC, ce n'est pas l'élément fragile de la chose, mais les cartes d'expansion, c'est peut etre autre chose. Mon problème est qu'aujourd'hui, je souhaite monitorer ma centrale photovoltaïque avec ça mais ce n'est tout simplement pas adapté. J'aurais aimé savoir ce qui limitait et donc la rendait inadapté. En effet, je sais que pour du photovoltaïque chez le particulier ça fonctionne très bien, on y met des pinces ampèmétriques n petit code et ça remonte bien. Beaucoup de systèmes existent déjà et font ça très bien pour le particulier. Mais moi ça serait pour mon entreprise, un entrepôt avec un toit vraiment long (l'équivalent de 20 toitures de particuliers) et la ben il y a plusieurs onduleurs (protocole de communication des onduleurs spécial fabricant), je voudrais la lecture des compteurs électriques, lecture de sondes d'ensoleillement et autres appareils de mesures (donc des entrées analogiques) des sorties Tout ou Rien, stockage, envoie sur serveur, écriture, alarmes en y connectant un routeur (etc etc etc). Je sais que tout cela peut être possible par expansion, mais de manière unitaire pas tout regroupé car sinon ça crame, et au final pour de telle taille de centrales PV ou projet, on passe par un fournisseur spécialisé dans le monitoring. Avez-vous la réponse technique à ma question, quelle/où est la limite à ces miniPC? qu'est ce qu'il bloque? :geek: n'hésitez pas à développer le coté technique ou différentes raisons (même suppositions) et la réponse "si c'est possible on peut tout faire avec o/", je vous crois mais ça ne sera pas forcément adapté et efficient.
En tout cas merci d'avance à tous et je vous souhaite une excellente continuation dans vos activités :mrgreen:

Cordialement,

Richard Roleau.

Re: Limites des embedded computer

Posté : mar. 21 févr. 2017 12:08
par destroyedlolo
Salut,

Voila beaucoup de questions qui remontent des sujets intéressant :)
Richard05 a écrit :Tous ces nouveaux Embedded computers, j'aurais aimé connaitre leurs limites (de manière générale).
Ben ... ca dépend de l'utilisation ;)
C'est sur que ce ne sont pas des I7 en terme de puissance et leur mémoire n'est pas extensible. Mais leur objectif n'est pas non plus de servir sur des machines de montages vidéo.

Pour avoir bossé sur ce genre de problématiques en tant qu'architecte, techniquement, je ne vois pas ce qui pourrait bloquer pour ce que tu veux faire. Mais il faut que l'architecture soit correctement pensée en particulier en visant plus un mode distribué à la mode IoT plutot qu'un systeme centralisé qui nécessitera un gros investissement en câblage avec les pb de robustesse et de perte associé.

Maintenant d'un point de vu plus politique d'entreprise, il faut savoir que ces SBC ne respectent pas les pré-requis qu'on attend d'un systeme professionnel critique. Typiquement, si on voulait en faire un NAS d'entreprise digne de ce nom, il faudrait au moins qu'ils aient une détection de corruption mémoire par CRC par exemple. Est-ce vraiment nécessaire ? Dans 99% des cas, non.
Mais le truc qui deviendra rapidement bloquant, c'est la maintenance. Ok, tu maitrise ton truc, il est efficace, peu cher et rempli parfaitement au besoin ... mais est-ce que qq'un peu prendre le relais si tu n'es pas la ? Qui prend la responsabilité en cas de défaillance ? Qui s'occupe d'éventuelle évolution ?
C'est pour ca que la majorité des entreprises DONT CE N'EST PAS LE METIER sous-traite ce genre de chose.

Enfin, les installateurs de solutions PRO photovoltaïques viennent généralement avec leur propre solution de monitoring.

A+

Re: Limites des embedded computer

Posté : mar. 21 févr. 2017 14:27
par Ghislain
Tout est possible même ton retour d'info mais.... faut réussir à décoder les info propre à ton installation... et la ça peut rapidement être un sacré casse tête

Tente déjà sur une seul zone mais je te souhaite bon courage ;)

PS: essai de mettre un peut en forme ton texte c'est plus facile a lire :D

Re: Limites des embedded computer

Posté : mar. 21 févr. 2017 17:16
par Richard05
Tout d’abord merci pour ces deux réponses. En effet, la réponse la plus évidente est qu’est-ce qu’on veut en faire d’abord car ça va clairement dépendre de l’utilisation. :?

Ce n’est pas la puissance de calcul qui me fait peur pour mon projet de télésurveillance solaire, mais en effet la « surcharge » de l’appareil par ses extensions et divers protocole de communications (je pense à la lecture TIC des compteurs électriques, pour mon entrepôt, on entre sur des compteurs DLMS COSEN, puis pour les onduleurs différents protocoles de communication fabricant par modbus/RS485…(ça a implémenter dedans, Ahem). Alors destroyedlolo tu parles de mode distribué style IoC, tu veux dire un appareil par fonction grosso modo répartie un peu partout sur le site et qui communiquent au contrôleur à la fin par différents moyens (radio, wifi, LoRa…) au style d’arduino. Mais cette histoire ne revient-elle pas à une solution plus chère et plus fragile ? Car tu l’as en effet souligné, le souci de maintenance pose problème. Car en dehors de leur performance technique, connait-on leur robustesse (durée de vie produit) ? A ce prix-là pour un besoin de calcul constant ça risque pas de faire long feu si ? :roll:

Dernière question, mon entrepôt basé aux Caraïbes en milieu salin, ne serait-ce pas utile (obligatoire !) de tropicalisé le(s) produit(s) en plus d’un boitier ? peut-on appliquer le vernis de tropicalisation sur les raspberry ? Je n’ai pas vu ça sur le net et j’aurais un peu peur de le faire moi-même « à la mano ».

On dirait que je suis très opposé à la RPI pour mon projet mais pas tant que ça, ce que je veux c’est glaner un maximum ‘informations affinées pour/contre le produit car je ne m’y connais pas assez dedans mais je sais que ce produit va dessiner notre avenir de communication.

Oui désolé pour la mise en forme Ghislain quand j’ai appuyé sur envoyé, je n’ai meme pas eu la force me relire et je me suis dit, qui je pourrais intéresser avec ce pavet :D . Chose corrigée dans ce commentaire.

Re: Limites des embedded computer

Posté : mar. 21 févr. 2017 20:13
par destroyedlolo
De quelle volumétrie parle-t-on ? pour quels types de calculs ? Avec quel objectif de résultat ?
Niveau puissance de calcul, je pense que tu surestime le besoin et sous-estime encore plus la puissance des SBC.

Pour les protocoles, il faut juste voir s'ils sont supportés. Pour les tics, ca fonctionne.
Richard05 a écrit :Alors destroyedlolo tu parles de mode distribué style IoC, tu veux dire un appareil par fonction grosso modo répartie un peu partout sur le site et qui communiquent au contrôleur à la fin par différents moyens
Oui ...
Richard05 a écrit :Mais cette histoire ne revient-elle pas à une solution plus chère et plus fragile ?
... ben non.
Pour le prix, tu n'es pas obligé de mettre des PI3 partout, un PI-0 ou plutot des OrangePI-0 ou des ESP sont très largement suffisants. Et je pense que t'y gagne par rapport à ce que couterait un cablage vers une palanqué de capteurs.
Pour la robustesse, ton système dans sa globalité doit être tolérant à la panne (la disparition d'un noeud ne doit pas tout bloquer).
Richard05 a écrit :connait-on leur robustesse (durée de vie produit) ? A ce prix-là pour un besoin de calcul constant ça risque pas de faire long feu si ? :roll:
Je ne vois pas pourquoi : si tu choisi du Raspberry PI-3, il faudra juste surveiller que la température du proc ne monte pas trop (talon d’Achille de ce SBC a mon avis). Sinon, hormis causes extérieurs (chocs électriques, température, humidité, ...), y'a pas de raison car l’électronique est beaucoup moins stressée que dans le moindre PC.
Mais a nouveau, de quels calculs parle-t-on ?
Richard05 a écrit :Dernière question, mon entrepôt basé aux Caraïbes en milieu salin, ne serait-ce pas utile (obligatoire !) de tropicalisé le(s) produit(s) en plus d’un boitier ?
Je n'ai jamais essayé mais ca pausera des pb au niveau des connecteurs.
Richard05 a écrit :On dirait que je suis très opposé à la RPI pour mon projet mais pas tant que ça, ce que je veux c’est glaner un maximum ‘informations affinées pour/contre le produit [...] car je ne m’y connais pas assez dedans mais je sais que ce produit va dessiner notre avenir de communication.
On n'a strictement aucune idee du but final de ton projet (hormis le coté technique), des compétences que tu/vous avez, et encore moins des moyens, limites et contraintes afférents.

Si j'avais a le faire, je partirai sur une myriades d'ESP ou d'OrangePI-0 avec Flash (ce qui évite d'avoir des problèmes de corrosion comme avec une SD). L'ESP a l'avantage de la simplicité et du WiFi, l'OrangePI-0 à quand à lui l'avantage d'un proc plus puissant que le rPI3, et permet d'avoir plus de GPIO qu'un ESP et un OS complet pour une taille riquiqui : bref, une partie non négligeable du traitement peu aussi lui être donné même si (voir meme surtout si) ils sont disséminés sur le terrain. Mais a contrario, faut savoir ce que l'on fait car il y a beaucoup moins d'aide qu'avec un rPI.

Sauf qu'a nouveau, c'est ce que JE ferai, maintenant, à savoir si ca convient à ce que tu veux faire, c'est une autre histoire.