Situation maritime MIK en mer du Nord

L'extension d'exemple MIK déclare les types MaritimeTrack, MaritimeVessel, MaritimeZone et MaritimeDetection, deux règles de surveillance et une action d'accusé de réception. Téléchargez le carnet marimo, le carnet de pipeline d’exposition et le modèle de permis. Le carnet pleine largeur utilise les composants scrydon.apps pour afficher la carte, les zones, la provenance des pistes, le registre des navires et les détections.

Le tableau des contacts et les détails de la piste sélectionnée affichent l'identifiant stable trackId, même lorsqu'un contact radar non corrélé n'a pas d'identité de navire. La carte étiquette les navires connus avec vesselId et utilise l'identifiant de la piste pour les contacts inconnus.

La carte affiche deux couches de zones — la zone surveillée restreinte et des zones d'intérêt approximatives (ZEE belge, approches occidentales de la Manche, un corridor de câble sous-marin de démonstration, détroit d'Ormuz, sud de la mer Rouge, golfe de Guinée et canal du Mozambique) — et une couche de points où chaque navire d'intérêt est un navire à sa dernière position signalée, orienté selon son dernier cap et coloré selon son risque. Sélectionner un navire le sélectionne dans l'onglet Vessels of interest, qui liste douze navires fictifs avec un niveau de risque, un score et ses raisons, ainsi que les navires situés dans une zone gouvernée ; l'onglet Detections ajoute trois événements rejoués à côté des détections des surveillances en direct. Chaque couche est sa propre requête autorisée : les deux couches de zones lisent le même type MaritimeZone avec un filtre sur category.

Cet exemple est expérimental. Chaque navire, score et événement rejoué est fictif et chaque polygone est approximatif ; leurs noms et leur provenance l'indiquent. Ils arrivent comme le ferait un flux réel — des sources de données de table interrogées, liées à MaritimeVessel, MaritimeZone et MaritimeReplayEvent — si bien qu'un vrai registre, un service de risque ou un catalogue de zones remplace une source sans modifier le carnet. Les événements rejoués sont un type distinct, MaritimeReplayEvent : seules les surveillances en direct écrivent MaritimeDetection, et seules ces détections peuvent être acquittées. Le scénario AIS/radar vérifie la corrélation déterministe, les observations tardives ou futures, l'entrée dans une zone et l'absence de rapports. Il ne connecte aucun fournisseur réel.

Exposition aux zones depuis un carnet de pipeline

exposure.py est un carnet de création, jamais publié. Il lit la table du registre des navires avec scrydon.sql.query, lit les objets MaritimeZone avec scrydon.ontology.read, les joint avec pandas (un navire est exposé à une zone lorsque sa dernière position se trouve dans la limite de la zone) et écrit le résultat dans la table gérée mik_vessel_zone_exposure. Le type MaritimeZoneExposure est lié à cette table et l'app l'affiche via sa requête déclarée exposure. Exécutez le carnet une fois dans l'environnement d'espace de travail depuis lequel l'app est publiée ; chaque exécution suivante remplace les lignes. Avant la première exécution, le tableau d'exposition de l'app reste vide. Le carnet déclare duckdb et sqlglot dans son bloc de dépendances : le runtime fournit scrydon sans son moteur SQL, et les paquets s'installent depuis votre index de paquets selon la politique d'egress de votre organisation.

La version 0.4.0 remplace la source des navires par mik-vessel-registry-v4 (table mik_vessel_registry), ajoute le cap heading des navires, supprime l'anneau dessiné autour de la dernière position et ajoute MaritimeZoneExposure. La version 0.3.0 ajoute les sources de démonstration (navires, zones, événements rejoués) sous de nouveaux identifiants et noms de tables ; les tables de la version 0.2.x ne sont plus liées. La version 0.2.1 de l'exemple a introduit une identité d'extension distincte, de nouveaux identifiants de sources et de nouvelles déclarations de schéma. Les anciennes installations de test utilisaient le schéma de classification default ; une mise à jour ne peut pas modifier silencieusement le marquage de leur état gouverné. Une migration explicite du schéma est nécessaire avant de retirer une ancienne installation.

Le permis doit référencer la révision et l'empreinte SHA-256 exactes de l'ontologie publiée. createMikAppPermit(revisionId, contentHash) valide ce permis. Enregistrez app.py comme carnet marimo et utilisez le panneau de publication Analytics après l'admission de la source gouvernée north-sea-v2. Consultez les manifestes d'application et les composants marimo.

Le manifeste d'ontologie déclare trackPolicies: [{ streamId: "north-sea-v2", policy: mikFixturePolicy }] séparément de la liaison MaritimeTrack publique. L'installation fixe la politique de corrélation AIS/radar dans le stockage privé des pistes. Le scénario utilise le schéma de classification scrydon.default ; adaptez les marquages si votre organisation utilise un autre schéma. L'installateur doit disposer de l'habilitation requise pour chaque identité et association. L'enregistrement de l'extension et la liaison lisible ne révèlent que l'identifiant du flux et la révision de la politique, jamais l'association radar restreinte. Une réinstallation identique est sûre ; une modification nécessite une migration explicite et une nouvelle révision.

Une source interrogée et installée pour l'organisation peut déclarer trackProjection : flux north-sea-v2, révision exacte de la politique, marquage et colonnes de l'identifiant d'événement, de l'entité source, de l'heure observée et des coordonnées. Après une interrogation complète et l'écriture des lignes, Platform transmet les observations sous l'identifiant de la source installée et l'environnement exact. Une interrogation partielle ou en échec ne prouve pas la santé de la source. Le stockage privé n'accepte que les sources de la politique fixée et déduplique les événements immuables. Après validation de l'état sain de la source, Platform envoie un point de contrôle qui réveille la surveillance indépendante. Une ligne qui porte des marquages de ligne (la colonne markings de la table) est écartée plutôt que publiée et comptée dans l'avertissement de synchronisation de l'interrogation : le flux régit ses lectures par un schéma et un rang et ne peut pas faire respecter les slugs de marquage de ligne, donc la publier au marquage de la projection la montrerait à des lecteurs à qui la table la cache. Les lignes du scénario ne portent aucun marquage de ligne : elles sont toutes publiées.

Le fichier d'essai source-fixture.ts définit deux manifestes de sources interrogées pour l'organisation, avec des colonnes AIS et radar normalisées. Ils fixent la projection des pistes au flux et à la révision de la politique de l'extension, mais restent hors de l'extension installable. Depuis la racine du dépôt, exécutez bun apps/docs/examples/mik-north-sea/fixture-server.ts pour examiner les réponses synthétiques /ais et /radar sur le port 4019. MIK_FIXTURE_MODE=load sert à la place une charge de référence synthétique (AIS uniquement, MIK_LOAD_TRACKS pistes à MIK_LOAD_RATE mises à jour par seconde, avec une rafale facultative à partir de MIK_LOAD_BURST_AT_SEC) ; c'est un banc de mesure, pas un scénario. Pour installer les sources, exposez ce serveur derrière un point de terminaison HTTPS public. Si votre organisation applique une politique de sortie, ajoutez cet hôte à sa liste d'autorisation (Paramètres → Gouvernance → Trafic sortant) : une interrogation vers un hôte non listé est refusée avec « Outbound request blocked by organization egress policy » et la raison apparaît sur la source. Les URL HTTP, locales ou privées sont refusées. Transmettez ces URL HTTPS à createMikFixtureTrackSources, puis installez les deux manifestes dans l'organisation et l'environnement exacts. Le serveur écoute uniquement sur la machine locale par défaut ; MIK_FIXTURE_HOST et MIK_FIXTURE_PORT le configurent derrière la passerelle d'essai. Les interrogations séparées, toutes les deux secondes, montrent le déplacement puis l'absence de nouveaux rapports. Un test d'intégration dirige l'URL HTTPS du manifeste vers le serveur HTTP local au moyen du transport de test du moteur d'interrogation, puis exécute le tick Platform, l'ingestion authentifiée de l'ontologie, le stockage durable des pistes, la lecture gouvernée et le planificateur de zone. Il observe le déplacement et une entrée dans la zone sans lecteur Horizon, mais ne qualifie pas le transport de production avec résolution DNS épinglée. Un test PGlite exécute aussi les interrogations AIS/radar installées jusqu'à l'évaluateur des règles et la chaîne d'actions. Après deux interrogations complètes sans nouvelles observations, il persiste une seule détection de rapport manquant, soumise à l'habilitation, pour deux contacts silencieux sans lecteur ouvert ; répéter le point de contrôle ne la duplique pas. Ce test composé utilise des réponses contrôlées pour l'écriture et la santé d'API Table. Il ne qualifie ni l'accès HTTP à un fournisseur réel, ni la persistance d'API Table, ni le rappel Dapr, ni un COP déployé.

Pour installer les deux sources en direct via le produit, générez une extension ponctuelle pour votre hôte HTTPS et téléversez-la dans Paramètres → Extensions, puis installez fixture-ais et fixture-radar pour chaque environnement depuis le catalogue d'extensions d'Analytics :

bun apps/docs/examples/mik-north-sea/live-sources.ts \
  --ais https://<fixture-host>/ais --radar https://<fixture-host>/radar \
  --version 0.1.0 --out ./mik-live

Un nouvel hôte exige un nouveau --version. Redémarrer fixture-server.ts est sûr : chaque exécution délimite ses identifiants d'événements AIS.

Le lecteur gouverné obtient d'API Table une preuve de santé liée à la configuration pour chaque source de la politique. Une position récente ne suffit pas. Cet exemple ne fournit ni adaptateurs AIS/radar opérationnels ni identifiants de fournisseur : son scénario synthétique n'active donc pas les règles MIK. Le balayage de réparation reste configuré à cinq minutes ; le mouvement en direct, la latence et la charge doivent encore être mesurés avec plusieurs sources installées. Les règles déclarent respectivement une gravité élevée et moyenne ; le composant d'alerte filtre cette propriété gouvernée.

Pour les règles de rapports manquants, la plateforme programme également une évaluation limitée à l'environnement au prochain délai de déclaration. Une interrogation complète et récente après ce délai doit encore confirmer la santé des sources avant la persistance d'une détection. Ce minuteur dispose de tests ciblés ; le rappel MIK complet et l'objectif de cinq secondes n'ont pas été mesurés.