Djinious
Aeromobile senza equipaggioAerospaziale e navale

UAV di rilievo Kestrel-1

Un UAV di rilievo ad ala fissa, seminato come caso documentato: otto requisiti, sei componenti, quattro fornitori e quattro verifiche, cablati in un grafo di tracciabilità, con un vero system_model ELANG e un Technical Data Package inline.

DjiniousEngineering
La tabella dei requisiti di DjiniousEngineering con otto requisiti — missione, sicurezza, regolatorio, prestazioni, ambientale, payload e operativo — ciascuno con il proprio metodo di verifica, motivazione, fonte, valore, unità e tolleranza, marcato Concordato o Allocato.
requisiti
8requisitiCaso documentato
componenti
6componenti
fornitori
4fornitori
verifiche
4verifiche

Il filo conduttore completo più piccolo — ogni arco chiuso

Kestrel-1 esiste per mostrare l’intera catena chiusa su un sistema piccolo: otto requisiti derivati dalla necessità, allocati su sei componenti, approvvigionati da quattro fornitori, e ciascuno chiuso da una di quattro attività di verifica.

È l’esempio da leggere quando vuoi vedere necessità → requisiti → componenti → fornitori → verifica come veri archi di un grafo, non come lo schema di uno.

Ricetta e standard

Guidato dalla ricetta UAV sul ciclo di vita baseline.

NASA SE Handbook Rev.2

Riportato come standard che la ricetta rispetta per questa classe.

EASA UAS 2019/947

Riportato come standard che la ricetta rispetta per questa classe.

Ricetta UAV sul ciclo di vita baseline

Portare un UAV di rilievo dalla necessità a una baseline rilasciata e a un Technical Data Package, con un’attività di verifica dietro ogni requisito.

  1. Deriva

    Deriva otto requisiti singoli dalla necessità di missione.

  2. Alloca

    Alloca ogni requisito su un componente dell’architettura.

  3. Approvvigiona

    Approvvigiona i sei componenti da quattro fornitori qualificati.

  4. Verifica

    Chiudi ogni requisito con un’attività di verifica di classe di evidenza sufficiente.

  5. Rilascia

    Redigi il system_model ELANG e congela il Technical Data Package.

SRR — System Requirements Review

Il primo gate: la baseline dei requisiti deve reggere prima che qualsiasi progettazione proceda.

Singolo e verificabile

Ogni requisito è singolo e verificabile.

Metodo di verifica

A ogni requisito è assegnato un metodo di verifica.

Elenco pericoli

L’elenco pericoli iniziale esiste.

Derivazione

Ogni requisito deriva da una necessità dichiarata.

Niente chiude un requisito con JUDGMENT quando il suo metodo di verifica richiede MEASURED — la classe di evidenza è imposta, non solo consigliata.

Nella piattaforma