Runtime de connecteurs

Le runtime de connecteurs de Scrydon est un seul service qui exécute l'acquisition entrante de chaque source de données (poll, push, stream, et une liaison de télémétrie MAVLink) et, là où une organisation a choisi d'y adhérer, les actions sortantes déclarées d'une source vers ce même fournisseur ou véhicule. Il compose des noyaux existants — le planificateur de scrutation, la supervision de flux, le runtime push, le tampon d'ingestion durable et (pour MAVLink) une liaison UDP détenue — et n'ajoute rien par-dessus qui duplique ce qu'ils font déjà.

Cette page est la carte pour deux publics : un opérateur qui décide quoi activer et comment lire ce qui s'est passé, et un auteur d'extension qui décide quel mode d'ingestion et quelles actions déclarées une source de données doit porter. Pour la référence d'écriture au niveau des champs, voir Modes d'ingestion et Sources de données.

Entrée : comment les données atteignent une table

Chaque source de données déclare exactement un ingest.mode. Quatre d'entre eux s'exécutent en continu sur le runtime de connecteurs :

Les sources manual, on-demand et query ne sont pas continues. Une personne déclenche un téléversement manual ou une récupération on-demand : le runtime analyse et met en correspondance cette exécution unique et renvoie ses lignes, et la plateforme les valide. Une source query ne s'exécute pas du tout sur le runtime de connecteurs ; elle lit une base de données distante via sa connexion gouvernée et ne possède aucune table gérée.

Une liaison MAVLink est une source stream avec transport: 'udp'. Le runtime lie un socket UDP, envoie vers l'extérieur vers le pair pour ouvrir le chemin de retour à travers le NAT, et décode HEARTBEAT, SYS_STATUS, SYSTEM_TIME et GLOBAL_POSITION_INT dans une table de télémétrie véhicule — réception seule, à moins que la source ne déclare aussi une action sortante (ci-dessous) et que la liaison soit signée : une liaison non signée n'envoie jamais de commande. Une liaison est signée (signing: 'signed-required') avec l'identifiant linkKey de la connexion, ou laissée unsigned-allowed ; une trame rejouée ou non signée sur une liaison signée est refusée et ne devient jamais une ligne. Voir Une liaison MAVLink sur UDP pour le manifeste complet et la déclaration de réseau privé de l'opérateur dont il dépend.

Positions en direct et l'enregistrement validé

Les lignes que la table et l'ontologie lisent sont validées environ une fois par minute et par source (STREAM_COMMIT_INTERVAL_MS), ou plus tôt lorsqu'un lot remplit une validation. Cette validation est l'enregistrement : c'est ce qu'une lecture gouvernée de la table voit et ce que la « dernière synchronisation » d'un opérateur reflète. Avant elle, un flux WebSocket ajoute ses trames au tampon d'ingestion durable dans les 250 ms de leur arrivée (STREAM_BATCH_FLUSH_MS), afin qu'un plantage entre deux validations perde le moins possible. Une liaison MAVLink ne tient pas un tel journal : ce qu'une liaison n'a pas pu valider est perdu avec elle, et sa fenêtre de santé le dit.

Une source qui déclare aussi trackProjection envoie des positions vers un flux d'ontologie gouverné correlated_tracks — c'est ainsi qu'une position de véhicule ou AIS atteint la carte d'Horizon. Chaque validation envoie les positions de ses lignes. Entre deux validations, un battement en direct au mieux, à la même cadence de 250 ms, envoie la position la plus récente par entité, après que la politique de données de l'organisation l'a examinée ; un battement n'est jamais écrit dans la table et ne compte jamais comme une synchronisation. Une ligne sans position est ignorée, jamais mise en échec. Une ligne qui porte ses propres markings n'est jamais projetée : un flux de piste ne peut pas appliquer des marques par lecteur, donc une ligne marquée reste dans la table, visible seulement aux lecteurs qui détiennent ses marques. Voir Sources de données pour la référence du champ trackProjection.

Santé de la source

Une source rapporte un statut qu'une personne lit — Healthy, Failed, Paused ou Running — plus un détail propre au mode : pour un flux, stream_disconnected / stream_silent / stream_set_aside ; pour une scrutation, last_error et consecutive_failures ; pour une source push, des avertissements de livraison. Le contrôle de santé et les alertes de la synthèse quotidienne lisent tous les deux ce même état ; rien ne le contourne.

Marquage, habilitation et prévention de perte à l'entrée

Chaque table qu'une source écrit a une colonne markings (un tableau de slugs de marque) que chaque lecture gouvernée filtre. La plateforme l'ajoute lorsque la table ne la déclare pas, et une table qui la déclare doit la déclarer comme array ; une source ne peut pas s'en exclure. Avant que toute ligne ne soit validée, elle passe la politique de données de l'organisation : une ligne que la politique réécrit est écrite réécrite, une ligne qu'elle bloque est mise de côté et comptée, et les lignes à côté sont écrites telles qu'elles sont arrivées. Une ligne trop grande pour qu'un scan l'examine est mise de côté sans scan plutôt que laissée passer sans contrôle. Un scan qui ne peut pas répondre bloque entièrement la validation — les lignes ne sont jamais écrites sans scan et jamais abandonnées silencieusement. Voir Classification et habilitation pour la règle « pas de lecture vers le haut » qui conditionne ensuite qui peut relire une ligne classifiée ou marquée.

Sortie : actions déclarées

Une source de données ne porte aucune capacité d'envoi par défaut. La seule façon d'obtenir une capacité write, invoke ou publish est une action déclarée dans son manifeste — un schéma d'entrée fermé, des unités, des préconditions, une classification, une expiration, et un requiresApproval explicite. Il n'y a pas de champ enabled sur la déclaration elle-même : l'activation est une décision séparée et auditée.

1. Activer. Un administrateur d'organisation active la définition exacte d'une action déclarée (action.catalog.enable, réservé aux administrateurs). Une demande contre une définition non activée est refusée avant que toute ligne sortante ne soit écrite.
2. Demander. La demande d'un appelant atteint le catalogue uniquement via l'opération action.tasking.dispatch d'API Platform ; rien d'autre ne peut mettre une unité en file.
3. Approuver (si requis). Une action déclarée avec requiresApproval: true retient chaque demande au même verrou d'approbation par demande exacte qu'utilise toute autre action du noyau — l'approbateur ne peut jamais être le demandeur vérifié du noyau. Une fois approuvée, le demandeur soumet à nouveau la même demande, et cette soumission consomme l'approbation : une approbation admet une demande. Approbation et activation sont indépendantes : les deux verrous doivent s'ouvrir.
4. Boîte d'envoi. Ce n'est qu'une fois que l'activation et (si requise) l'approbation admettent toutes deux la demande que le noyau de l'ontologie écrit une ligne de boîte d'envoi (action_outbound_request) et met exactement une unité en file.
5. Autorité signée, liée au bail. Le noyau génère un mandat signé asymétriquement, à courte durée (≤ 5 minutes) — l'identité de l'action, la cible, la destination, l'époque du bail de contrôle, et la preuve d'approbation. Tout détenteur de la clé publique peut le vérifier ; rien de ce qu'il porte ne permet à un vérificateur d'en générer un. Le dispatcher revérifie le mandat contre la fenêtre actuelle de la liaison immédiatement avant l'envoi, et à nouveau à chaque réessai, de sorte qu'un bail perdu entre l'émission et l'écriture n'envoie rien.
6. Envoyer. Pour une destination en mode link, le dispatcher encode et signe un COMMAND_LONG MAVLink et l'envoie sur la liaison exacte que le mandat a nommée — et seulement si cette commande est sur la liste blanche (aujourd'hui, seulement MAV_CMD_SET_MESSAGE_INTERVAL). Toute autre commande est refusée avant même d'être encodée.
7. Issue. Un COMMAND_ACK est corrélé à l'action ; un accusé de réception manquant obtient des réessais bornés, adaptés au protocole, sous le même mandat. Quand les réessais sont épuisés sans accusé, l'action se termine en issue inconnue (Outcome unknown) — jamais silencieusement en échec — et aucune action ultérieure sur cette même cible n'est revendiquée pour envoi jusqu'à ce que la ligne soit réconciliée.

Pour aller plus loin

• Modes d'ingestion — la référence d'écriture complète par mode, y compris le manifeste de liaison MAVLink.
• Sources de données — sources de données déclaratives et projections de piste.
• Guide opérateur — actions sortantes — activer, approuver, lire l'historique et réconcilier.
• Classification et habilitation — la règle « pas de lecture vers le haut » qui conditionne ce qu'un lecteur voit sur une ligne classifiée ou marquée.
• Horizon — l'image opérateur qui consomme les lignes validées et le flux de piste du runtime.