Djinious
Réserver une démo
Autonomie sous-marineAérospatial et marine

AUV de relevé des fonds marins Marlin-XR

Un véhicule sous-marin autonome relevant le corridor du câble d’export du parc éolien offshore de Dogger Bank. Le ledger de démonstration fourni : quarante éléments amorcés sur les onze étapes du cycle de vie, du brief de mission à la procédure de déploiement.

DjiniousEngineeringOrchestration
DjiniousEngineering
Le canevas System Ledger dans DjiniousEngineering, montré sur le projet Kestrel-SAR III : des colonnes d’étapes de cycle de vie allant de Mission & Besoin à Modèles d’ingénierie, chacune en-tête de son processus ISO 15288 et contenant des éléments typés étiquetés avec leur type d’artefact et leur classe de preuve.
éléments de ledger amorcés
40éléments de ledger amorcésLedger de démonstration amorcé
étapes de cycle de vie renseignées
11étapes de cycle de vie renseignées
code système
MRLN-XRcode systèmePlateau continental britannique — Dogger Bank

Une plongée, un corridor fixe, et aucune marge d’erreur à 300 m

Le brief de mission est précis : relevé autonome d’un corridor de câble d’export de 12 km sur Dogger Bank jusqu’à 300 m de profondeur, endurance ≥ 8 h, résolution bathymétrique ≤ 0,5 m, couverture en une seule plongée.

Endurance, résolution et couverture tirent en sens contraires ; le véhicule doit satisfaire les trois à la fois, et chaque choix qui y mène doit être traçable en arrière jusqu’à ce brief et en avant jusqu’à un essai qui le prouve.

Recette et normes

Piloté par la recette véhicule de surface / sous-marin — ISO 3691-4, COLREG / Code MASS de l’OMI.

MCA MGN 664

Porté comme norme que la recette honore pour cette classe.

IMCA S 019

Porté comme norme que la recette honore pour cette classe.

Licence maritime (MMO)

Porté comme norme que la recette honore pour cette classe.

UNCLOS Art. 60/80

Porté comme norme que la recette honore pour cette classe.

Cycle de vie de référence, recette véhicule

Faire aller le besoin de mission jusqu’à un Technical Data Package publié : dériver des exigences vérifiables, arbitrer entre trois architectures de coque, faire converger les bilans énergétique et hydrodynamique, prouver les modèles face à une réplique numérique, puis geler la référence.

  1. Cadrer

    Cadrer le besoin de mission et dériver des exigences singulières et vérifiables (endurance, résolution, couverture).

  2. Arbitrer

    Arbitrer entre trois architectures — AUV torpille, plateforme en vol stationnaire à châssis ouvert, planeur-hover hybride — notées sur endurance 0,35, manœuvrabilité 0,30, charge utile 0,20, coût 0,15.

  3. Décider

    Enregistrer la décision : adopter la configuration planeur-hover hybride.

  4. Dimensionner

    Faire converger la boucle de dimensionnement — un bloc batterie de 12,6 kWh face au budget d’endurance ≥ 8 h.

  5. Publier

    Clore la vérification, geler la référence, et émettre le Technical Data Package.

PDR — Preliminary Design Review

L’agent ne peut pas franchir la PDR tant qu’un humain n’a pas validé les éléments en amont et que les critères de la plateforme ne sont pas remplis.

Convergence

La boucle de dimensionnement a convergé.

Marges

Les marges par rapport à chaque contrainte dure sont positives.

Allocation

Chaque exigence se retrace jusqu’à un élément d’architecture qui l’implémente.

Méthode de vérification

Une méthode de vérification est assignée à chaque exigence.

Le jalon est un élément de ledger que l’agent ne peut pas contourner — il empêche une exécution autonome de concevoir par-dessus une référence non revue.

Dans la plateforme

La vue carnet lit n’importe quel ledger comme un récit du fil — les mêmes éléments, étape par étape, du besoin de mission jusqu’au dossier publié. Elle est montrée ici sur le projet Kestrel-SAR III.

DjiniousEngineering
Un System Ledger dans la vue carnet de DjiniousEngineering : les onze étapes listées à gauche, et les éléments Mission & Besoin — une spécification de haut niveau et un brief de mission — montrés comme des éléments spec_brief avec une preuve de type jugement et des commandes Valider et Rejeter.
Le fil lu d’un bout à l’autre, étape par étape, chaque élément attendant qu’un humain le valide ou le rejette.

Continuer à explorer

Cas d’usage associés

Tous les cas d’usage
Rendu RTX Isaac Sim de la cellule du drone dans la scène physique, sur NVIDIA GB10.Systèmes de dronesUne mission de quadricoptère, volée avant que le drone n’existeUn quadricoptère complet câblé à partir de pièces de bibliothèque en une seule co-simulation, son contrôleur de vol bouclant autour de la physique de corps rigide de NVIDIA Isaac Sim — et un véritable décollage, vol stationnaire, montée, descente et atterrissage enregistrés depuis cette boucle.DjiniousWorkshopLe quadricoptère Djinborn T4 complet sur le canevas DjiniousLab — batterie, quatre propulseurs, corps central, bras, injection de force, couplage gyroscopique, capteurs, et la pile de commande en cascade câblée comme une seule composition exécutableRobotique aérienneDjinborn T4 quadcopterUn drone de relevé de classe 450 comme une seule composition multicorps — cellule, propulsion, capteurs, et un pilote automatique en cascade exécutant une mission en boucle fermée à 6 degrés de liberté.DjiniousLabUne carte de mission animée montrant trois UAV effectuant un levé LiDAR d’un carré de 500 mètres près de la côte d’Al-Batinah, à Oman, avec leurs trajectoires de vol et une base mobile repérées sur un fond de carte OpenStreetMapLevé par droneLevé LiDAR par drone à Al-BatinahPlanifier et optimiser un levé LiDAR par flotte de drones sur un site de 500 × 500 m à Oman — ajuster la mission à votre flotte, vos drones et vos capteurs, puis exécuter une mission optimale face à une flotte d’UAV simulée sur une carte animée.DjiniousLab