Les modules de base
Dix modules livrés avec la plateforme : cinq briques prêtes à l'emploi, cinq points de départ.
L'essentiel
Un module est une application qui tourne sur l'appareil. La plateforme en fournit dix, pour que vos équipes n'écrivent pas la plomberie.
Cinq sont des briques prêtes à l'emploi : la communication entre applications, l'affichage plein écran, la synchronisation avec le cloud, les journaux, et un simulateur de matériel.
Les cinq autres sont des points de départ pour votre code métier, dans quatre langages plus l'interface — vos équipes gardent leurs habitudes.
Le simulateur mérite une mention : il joue n'importe quel capteur ou périphérique déclaré, ce qui permet de développer et de démontrer sans le matériel.
Ce que ça apporte : Vos développeurs attaquent le métier dès le premier jour, sans attendre le matériel ni réécrire la base.
En détail
Un module est une application qui tourne sur l'appareil. La plateforme en fournit dix, produit-agnostiques : cinq briques d'infrastructure utilisées telles quelles, et cinq points de départ pour le code métier, dans quatre langages plus une interface.
Les modules d'infrastructure sont livrés en binaires précompilés, obfusqués et compressés. Les points de départ sont livrés en code source. Tous se consomment par héritage d'une image de base et sont versionnés. Le catalogue est vivant : Arkipelis y ajoute des modules au fil des cas d'usage.
Infrastructure — utilisés tels quels
Hub — le bus de communication local
Permet à toutes les applications d'un appareil de se découvrir et de communiquer en temps réel, sans configuration.
- Démarre en premier : c'est l'ossature dont les autres dépendent.
- Découverte automatique des applications voisines.
- Messages temps réel — commandes, événements, états — entre applications.
- Conservation des derniers états : une application démarrée en retard les reçoit à la connexion.
- Reconnexion automatique au redémarrage d'une application.
Module fondateur : sans lui, les applications ne se trouvent pas. Il évite à l'intégrateur de concevoir son propre mécanisme de communication entre applications.
kiosk — l'affichage plein écran
Affiche une interface web en plein écran sur la sortie vidéo — écran tactile, borne, signalétique — sans menu ni barre.
- Navigateur en plein écran sur une adresse configurée.
- Rotation portrait ou paysage par appareil, et plusieurs écrans.
- Écran de démarrage au logo du client, qui neutralise les artefacts d'amorçage.
- Rechargement automatique de la page au déploiement de l'interface.
- Miroir d'écran à distance pour le diagnostic et les démonstrations.
- Décodage matériel des vidéos, pour une lecture fluide.
Il couvre le besoin d'écran tactile plein écran de tout projet de borne, de frigo connecté, de distributeur ou de kiosque interactif.
fileserverNode — la synchronisation avec le cloud
Synchronise des fichiers entre l'appareil et le cloud du client, dans les deux sens, de façon fiable et programmée.
- De l'appareil vers le cloud : exports métier — ventes, télémétrie — avec une rétention configurable.
- Du cloud vers l'appareil : configurations, médias, ressources applicatives.
- Synchronisation programmée, par défaut tous les quarts d'heure et par dossier, plus un drapeau urgent qui fait monter en secondes.
- Reprise sur erreur réseau et limitation de la bande passante.
- Suppression à distance par marqueur, et accusé après ingestion pour nettoyer le local.
logsNode — les journaux centralisés
Collecte, conserve et expose les journaux de toutes les applications de l'appareil, sous forme interrogeable.
- Ingestion automatique des journaux de toutes les applications par le bus.
- Conservation locale en base légère.
- Interrogation locale par période, application, niveau ou session.
- Archive cloud facultative, pour un audit de long terme.
Indispensable au diagnostic à distance et à la conformité : « voici ce qui s'est passé sur cet appareil, tel jour à telle heure ».
hwSimGo — le simulateur de matériel
Joue n'importe quel capteur, actionneur ou périphérique déclaré dans la configuration, sans matériel — pour développer, tester et démontrer.
- Seize types de « choses » instanciées par configuration : verrou, capteur de porte, interrupteur, éclairage, caméra, lecteur de badge, terminal de paiement, sondes, écran…
- Le même contrat que le matériel réel : commandes idempotentes, états publiés sur le bus local.
- Actions de simulation pilotables depuis le bus ou depuis un écran générique : badge, porte, main, sonde, réseau.
- Jeux d'essai partagés avec les autres implémentations.
Il permet de développer et de démontrer un projet matériel sans le matériel, et de jouer un scénario à la demande — porte forcée, coupure réseau, carte refusée. La démonstration tourne sur un poste, la production sur l'appareil, avec le même code métier.
Points de départ — le code métier
frontendReact — l'interface tactile
L'application web embarquée pour l'interface principale de l'appareil, typiquement affichée en plein écran par le module kiosk : interface tactile optimisée (gestes, retours visuels, claviers virtuels), portrait ou paysage selon la configuration, plusieurs applications dans un même module, rechargement automatique au déploiement et intégration native au bus, à la synchronisation et aux journaux.
Quatre points de départ pour les services
| Module | Ce qu'il apporte | Pourquoi le choisir |
|---|---|---|
| backendNode | Services applicatifs en TypeScript : interface locale pour le frontend, gestion de la donnée métier, orientation vers le matériel. | Le choix le plus courant pour la logique métier, avec un vivier de développeurs important. |
| backendCsharp | Services en C#, débogables dans Visual Studio sur Windows natif, pilotage du matériel par les bibliothèques industrielles. | Permet à un intégrateur .NET de livrer sans migrer sa stack ni son outillage. |
| backendGo | Services en Go : binaire unique, faible empreinte mémoire. | Pour les services système et les appareils aux ressources contraintes. |
| backendPython | Services en Python, avec l'écosystème scientifique et l'audio. | Pour le traitement du signal, l'apprentissage automatique local, et les pilotes matériels — le pilote générique commande les entrées-sorties depuis la seule déclaration des choses. |
Tous intègrent nativement le bus, délèguent la synchronisation au module de fichiers et les journaux au module de journaux.
Les modules métier livrés par Octopoda
Les suites Octopoda livrent leurs propres modules, sur exactement la même mécanique de construction et de distribution :
- L'agent de vente : il orchestre la vente sur l'appareil, du badge à la remontée de l'opération.
- Il calcule le prix en local, avec la même bibliothèque que le cloud.
- Il décide hors ligne sur son cache, et n'égare aucune opération.
- Il gère les sessions terrain et détecte une porte forcée.
- L'agent des machines à recettes : il pilote un bar à boissons ou une machine à café.
- Le versement est mesuré et facturé au prorata du volume servi.
- Le terminal de paiement certifié : un terminal physique conforme aux normes de sécurité des paiements.
- Paiement, annulation, remboursement, lecture, avec reconnexion automatique.
- Chaque transaction est journalisée.
- La télémétrie déclarative : elle écoute le bus local et en tire mesures et alertes, sans code.
- À chaque changement ou à cadence fixe, avec seuil tenu pendant une durée et retour à la normale.
- Le jumelage au point de vente : il donne son identité métier à l'appareil à la mise en route.
- Un écran embarqué pour le technicien, et un jumelage qui fonctionne hors ligne.