Industrie et IoT
Les données des appareils, servies aux applications sous la même décision.
Aujourd'hui, Flexway sert le côté applications de vos plateformes IoT : publier vers vos courtiers MQTT depuis HTTP, diffuser leurs flux aux navigateurs et aux partenaires, sous contrat AsyncAPI. Le branchement direct des appareils est prévu dans une prochaine version.
Ce que Flexway décide, chez vous
Qui appelle, ce que Flexway décide, ce qui est appelé : chaque trajet est un cas d'usage de votre secteur. En pointillé, ce qui est à venir.
Architecture pour l'industrie et l'IoT : les applications de l'usine, les tableaux de bord et les partenaires passent par Flexway, dans votre infrastructure. Flexway publie sous contrat sur votre courtier, relaie les flux temps réel, envoie depuis le courtier des webhooks signés aux systèmes partenaires et tient le débit de chaque appelant, devant votre courtier MQTT ou AMQP et vos services industriels. Un appelant au-delà de son débit reçoit un 429. Les clients Kafka se branchent aussi directement sur la passerelle ; leurs quotas sont en partie livrés.
- Apps de l'usine
- Les applications qui appellent vos API : chaque requête passe par Flexway, qui vérifie le contrat et l'identité avant d'atteindre vos systèmes.
- Tableaux de bord
- Les tableaux de bord de supervision : ils reçoivent les mesures en flux temps réel (SSE, WebSocket) relayés sans retenue.
- Partenaires
- Les entreprises partenaires qui consomment vos API : identifiées par certificat client ou clé d'API, sous un quota par tenant.
- Courtier consommé
- Un courtier dont Flexway consomme les messages pour les livrer à vos partenaires en webhooks signés.
- Débit par appelant
- Un seau à jetons par appelant limite son débit ; au-delà : 429 avec Retry-After et les en-têtes RateLimit.
- Publication sous contrat
- Flexway publie sur votre courtier, sous contrat AsyncAPI et en enveloppe CloudEvents, ce qu'il reçoit en HTTP.
- Webhooks signés
- Flexway livre vos événements à vos partenaires en webhooks signés et rejouables.
- Flux temps réel
- Les flux temps réel (SSE, WebSocket) sont relayés sans retenue ; l'identité et le débit sont vérifiés à l'ouverture.
- Courtiers MQTT, Kafka
- Vos courtiers Kafka, AMQP, MQTT et NATS : Flexway y publie sous contrat AsyncAPI, en enveloppe CloudEvents.
- Services industriels
- Vos services REST et gRPC : ils ne reçoivent que les requêtes que Flexway a laissées passer, sous délai et coupe-circuit.
- Systèmes partenaires
- Les systèmes de vos partenaires : ils reçoivent vos événements en webhooks signés et rejouables.
- Ligne : un trajet
- Correspondance : décision partagée
- Requête
- Événement
- Refus
- Votre infrastructure
- Débit par appelantjetons par appelant, traces
- Publication sous contratHTTP vers courtier, CloudEvents
- Webhooks signésrejouables vers les partenaires
- Flux temps réelSSE, WebSocket, sans retenue
1Une application publie une mesure
Ce que Flexway décideLe canal est déclaré en AsyncAPI ; la passerelle publie sur votre courtier en enveloppe CloudEvents.
Ce qui est protégéAucun topic ouvert : le courtier reste derrière la passerelle.
2Un tableau de bord suit la production en direct
Ce que Flexway décideLe flux SSE ou WebSocket est relayé sans retenue, sous la même décision d'identité.
Ce qui est protégéLe navigateur ne parle jamais au courtier.
3Un partenaire reçoit les événements qui le concernent
Ce que Flexway décideDepuis le courtier, des webhooks signés et rejouables livrent au partenaire les événements de son tenant.
Ce qui est protégéLe partenaire n'a aucun accès au courtier.
Apps de l'usine
Les applications qui appellent vos API : chaque requête passe par Flexway, qui vérifie le contrat et l'identité avant d'atteindre vos systèmes.
Trajets qui passent ici
Tableaux de bord
Les tableaux de bord de supervision : ils reçoivent les mesures en flux temps réel (SSE, WebSocket) relayés sans retenue.
Trajets qui passent ici
Partenaires
Les entreprises partenaires qui consomment vos API : identifiées par certificat client ou clé d'API, sous un quota par tenant.
Trajets qui passent ici
Courtier consommé
Un courtier dont Flexway consomme les messages pour les livrer à vos partenaires en webhooks signés.
Trajets qui passent ici
Débit par appelant
Un seau à jetons par appelant limite son débit ; au-delà : 429 avec Retry-After et les en-têtes RateLimit.
- Décision
- jetons par appelant, traces
- Fonctionnalités du catalogue
- Débit par appelant (seau à jetons) ; Traces W3C propagées de bout en bout
Trajets qui passent ici
Publication sous contrat
Flexway publie sur votre courtier, sous contrat AsyncAPI et en enveloppe CloudEvents, ce qu'il reçoit en HTTP.
- Décision
- HTTP vers courtier, CloudEvents
- Fonctionnalités du catalogue
- AsyncAPI comme source du plan asynchrone ; Médiation de la frontière synchrone vers asynchrone ; AMQP(S) et MQTT
Trajets qui passent ici
Webhooks signés
Flexway livre vos événements à vos partenaires en webhooks signés et rejouables.
- Décision
- rejouables vers les partenaires
- Fonctionnalités du catalogue
- Webhooks sortants signés et rejouables
Trajets qui passent ici
Flux temps réel
Les flux temps réel (SSE, WebSocket) sont relayés sans retenue ; l'identité et le débit sont vérifiés à l'ouverture.
- Décision
- SSE, WebSocket, sans retenue
- Fonctionnalités du catalogue
- Flux relayés sans retenue : SSE et corps fragmentés ; WebSocket relayé
Trajets qui passent ici
Courtiers MQTT, Kafka
Vos courtiers Kafka, AMQP, MQTT et NATS : Flexway y publie sous contrat AsyncAPI, en enveloppe CloudEvents.
- Fonctionnalités du catalogue
- AMQP(S) et MQTT ; Proxy Kafka natif : clients Kafka branchés sur la passerelle, clusters et sujets virtuels par tenant
Trajets qui passent ici
Services industriels
Vos services REST et gRPC : ils ne reçoivent que les requêtes que Flexway a laissées passer, sous délai et coupe-circuit.
Trajets qui passent ici
Systèmes partenaires
Les systèmes de vos partenaires : ils reçoivent vos événements en webhooks signés et rejouables.
- Fonctionnalités du catalogue
- Webhooks sortants signés et rejouables
Trajets qui passent ici
Ce que le secteur exige
- MQTT · AsyncAPIDes canaux déclarés, pas des topics ouverts
- Un canal n'existe que s'il est déclaré au contrat ; une application publie en HTTP, la passerelle publie sur le courtier en enveloppe CloudEvents.
- Échanges B2BDes partenaires sans accès au courtier
- Webhooks signés et rejouables vers les partenaires ; certificats clients liés à un tenant pour ceux qui appellent.
- SupervisionDes flux temps réel jusqu'au navigateur
- Un tableau de bord consomme un flux en SSE ou WebSocket sans parler MQTT, relayé sans retenue.
- ChargeUn débit tenu par appelant
- Débit par appelant et traces de bout en bout : une application bavarde ne prive pas les autres.
Ce que le secteur attend
Les attentes de votre secteur relevées dans l'analyse du marché, et où en est Flexway pour chacune ; ce qu'un autre composant fait mieux est dit.
| Ce que les entreprises attendent | Flexway v1.6.3 |
|---|---|
| Normaliser les protocoles terrain (MQTT, Sparkplug B, OPC UA PubSub)Écouteur MQTT en proxy, Sparkplug B, OPC UA PubSub JSON | Prévu en 1.7 |
| Modbus, OPC UA client-serveur, BLE, protocoles propriétairesRôle d'une passerelle d'atelier ; Flexway gouverne ce qu'elle publie en MQTT | Laissé à un autre composant |
| CoAP des appareils contraintsAucun écouteur CoAP ; candidat sur demande réelle | À dater |
| Filtrer et agréger la télémétrieTopics fermés au contrat, charges validées ; l'agrégation de flux relève d'un moteur de traitement | En partie · suite en 1.7 |
| Fonctionner hors ligne, bufferiserAucun plan central sur le chemin : une passerelle locale décide sans réseau ; la mise en tampon reste au courtier local ; mode edge planifié | En partie · suite en 1.11 |
| Identité des équipements, certificats, segmentationX.509, jeton, clé par appareil, topic lié à l'identité | Prévu en 1.7 |
| Contrôler les commandes descendantesCommandes Sparkplug sous portée déclarée prévues ; la condition sur l'état courant du système : candidat | En partie · suite en 1.7 |
IA en périphérieLe même binaire arm64 route vers un modèle local ; l'exécution du modèle reste au runtime d'inférence | En partie · suite à dater |
| Gestion du parc d'appareils (versions, mises à jour)Une plateforme de gestion d'appareils ; Flexway gère sa propre flotte par GitOps | Laissé à un autre composant |
Versions à venir non engageantes ; « Livré » seulement quand le catalogue de la version publiée le dit.
Comment Flexway y répond
Des canaux déclarés, pas des topics ouverts
- AsyncAPI comme source du plan asynchroneLivré · v1.5.0
- AMQP(S) et MQTTLivré · v1.5.0
- Médiation de la frontière synchrone vers asynchroneLivré · v1.5.0
Des partenaires sans accès au courtier
- Webhooks sortants signés et rejouablesLivré · v1.5.0
- Clés d'API et mTLS client comme identités de premier planLivré · v0.1.0
Des flux temps réel jusqu'au navigateur
- Flux relayés sans retenue : SSE et corps fragmentésLivré · v0.1.0
- WebSocket relayéLivré · v0.1.0
Un débit tenu par appelant
- Débit par appelant (seau à jetons)Livré · v0.1.0
- Traces W3C propagées de bout en boutLivré · v0.1.0
État dans la dernière version publiée de Flexway ; une fonctionnalité n'est marquée livrée qu'avec sa version.
Ce que Flexway ne fait pas
- Le branchement direct des appareils (écouteur MQTT avec identité d'appareil, Sparkplug B, OPC UA) n'est pas dans la version publiée : il est prévu dans une prochaine version.
- Flexway n'est jamais un courtier : il s'appuie sur le vôtre.
Parlons de votre passerelle
Flexwiz est une jeune entreprise : vous parlez directement avec la personne qui la fonde. Dites-nous ce que vous voulez faire passer par Flexway. Nous parlons de votre infrastructure et de vos exigences de souveraineté numérique.
La prise de rendez-vous en ligne arrive bientôt ; d'ici là, un e-mail suffit.