Ingegneria di sistema basata su modelli
Ingegneria di sistema basata su modelli, dal requisito alla variante verificata
Se si chiede a un ingegnere di sistema che cosa gli ha dato l'MBSE nel suo progetto, la risposta è spesso: un buon modello e uno strumento che fuori dal team nessuno apre. Il modello è un'isola. Risultati di simulazione, prove di test, dati dei fornitori e decisioni stanno altrove, e al confine dello strumento il filo si rompe. Ref è costruito per quel confine.
La situazione
Dove l'MBSE si blocca
CATIA Magic, Rhapsody, Enterprise Architect e Capella modellano bene i sistemi. Le difficoltà cominciano dove il modello incontra le prove. Un requisito viene verificato da un test che è girato un martedì su un banco prova. Il collegamento tra l'elemento SysML e il file di misura è una tabella, e la tabella viene tenuta a mano finché non lo è più. L'MBSE ha promesso tracciabilità e consegnato un modello che una persona deve far quadrare con la realtà.
In Ref
Una piattaforma accanto allo strumento di modellazione
Ref è il posto dove il modello, gli artefatti che ne derivano e le prove prodotte contro di esso restano collegati. I requisiti entrano come ReqIF ed escono come ReqIF. L'architettura è struttura, e la struttura appartiene ai dati che descrive: componenti, porte, connettori, interfacce e bus li modificate nel browser, voi stessi o l'agente. La geometria è l'altro caso. Richiede un kernel di modellazione e resta nel vostro sistema CAD. Il comportamento si calcola: un modello Python o Modelica contro un set di parametri, il risultato archiviato accanto al requisito che verifica. FMI e SSP coprono la cosimulazione.
I file di modello del vostro strumento attuale vengono salvati con le loro versioni e con quello che dipende da essi. Niente obbliga il team a lasciare l'editor che conosce.
Il ciclo
Il modello a V come prodotto secondario
Requisiti e architettura sul ramo sinistro, integrazione e verifica su quello destro, e i collegamenti tra i due nascono dal lavoro stesso. Un'esecuzione che verifica un requisito è collegata a esso perché è stata lanciata per esso. Non c'è un compito di documentazione separato. Una variante viene confrontata con i criteri che fissate voi, e la decisione viene registrata con le prove che erano sul tavolo.
Delimitazione
Dove un altro strumento va meglio
Nessuna macchina a stati, nessun diagramma parametrico, nessun diagramma di sequenza; dove vi serve il comportamento, lo calcolate. Nessun XMI.
Se il requisito è la copertura completa dei diagrammi e un'implementazione pilota di SysML v2, CATIA Magic o Eclipse SysON vanno meglio. È questo che dovete sapere da questa pagina.
Team piccoli
Senza ufficio metodi
Ref funziona senza ufficio metodi. Cominciate con gli artefatti che avete: un elenco di requisiti, una cartella di modelli, una cartella con risultati di test. Il lavoro secondo ISO 26262 o IEC 61508 ha bisogno della catena delle prove che questa pagina descrive. Ref consegna la catena.
Domande
Che cosa si chiede per primo
Quali strumenti MBSE funzionano con Ref?
Ogni strumento che esporta i requisiti come ReqIF. I file di modello di qualunque strumento vengono salvati con le loro versioni; l'editor resta il vostro.
Ref sostituisce il nostro strumento per i requisiti?
Può tenere i requisiti. Se Polarion o DOORS resta il riferimento, ReqIF va nelle due direzioni.
Controllo di qualità dei requisiti secondo le regole INCOSE?
Su richiesta, tramite l'agente.
Un agente può scrivere il modello SysML dai requisiti?
Abbozza la struttura, una persona corregge. SysMBench dell'Università di Pechino, 2025, ha provato 17 modelli su 151 scenari; il migliore ha raggiunto il 62 per cento sulla metrica degli autori, e gli autori la definiscono debole. Erano i modelli di metà 2025, e le generazioni successive sono migliori; la correzione da parte di una persona resta più economica di un errore che nessuno ha notato.
Pagine collegate
Se il vostro modello e le vostre prove di test stanno in posti diversi, un pilota con un sottosistema non costa nulla. Raccontateci il vostro progetto.