Verifica automatica dei requisiti del progetto durante la modellazione dinamica

Continuando il tema «Quali sono le vostre prove?», esaminiamo il problema della modellazione matematica da un'altra prospettiva. Dopo aver verificato che il modello corrisponde alla dura realtà della vita, possiamo rispondere alla domanda principale: «cosa abbiamo realmente qui?». Quando creiamo un modello di un oggetto tecnico, di solito vogliamo assicurarci che questo oggetto soddisfi le nostre aspettative. Per questo motivo vengono eseguiti calcoli dinamici dei processi e i risultati vengono confrontati con i requisiti. Questo è il gemello digitale, il prototipo virtuale e altre innovazioni alla moda, che risolvono il compito durante la fase di progettazione di garantirci ciò che avevamo pianificato.

Come possiamo assicurarci rapidamente che il nostro sistema sia esattamente quello che stiamo progettando, volerà o galleggerà, la nostra costruzione? E se vola, a che altezza? E se galleggia, a quale profondità?

In questo articolo si esamina l'automazione della verifica dei requisiti tecnici di un edificio durante la creazione di modelli dinamici di sistemi tecnici. Come esempio, consideriamo un elemento del capitolato tecnico per il sistema di raffreddamento ad aria di un velivolo.

Esaminiamo quei requisiti che possono essere espressi numericamente e verificati matematicamente sulla base di un modello di calcolo specifico. È evidente che questa è solo una parte dei requisiti generali per qualsiasi sistema tecnico, ma è proprio su di essi che dedichiamo tempo, nervi e denaro per la creazione di modelli dinamici dell'oggetto.

Nella descrizione dei requisiti tecnici in forma di documento, è possibile distinguere diversi tipi di requisiti, ciascuno dei quali richiede approcci diversi per la formazione di un controllo automatico del loro rispetto.

Ad esempio, consideriamo un piccolo ma reale insieme di requisiti:

1. Temperatura dell'aria atmosferica all'ingresso del SVO:
   in sosta − da -35 a 35 ºC,
   in volo − da -35 a 39 ºC.
2. Pressione atmosferica statica in volo − da 700 a 1013 GPa (da 526 a 760 mmHg).
3. La pressione atmosferica totale all'ingresso del sistema di raffreddamento in volo varia da 754 a 1200 hPa (da 566 a 1050 mm di Hg).
4. Temperatura dell'aria di raffreddamento:
   a terra - non oltre 27 ºC, per i blocchi tecnici - non oltre 29 ºC,
   in volo - non oltre 25 ºC, per i blocchi tecnici - non oltre 27 ºC.
5. Flusso dell'aria di raffreddamento:
   a terra - non meno di 708 kg/h,
   in volo - non meno di 660 kg/h.
6. Temperatura dell'aria nei compartimenti strumentali - non oltre 60 ºC.
7. Quantità di umidità fine libera nell'aria di raffreddamento - non oltre 2 g/kg di aria secca.

Anche in un insieme così ristretto di requisiti si possono evidenziare almeno due categorie che devono essere trattate diversamente nel sistema:

• requisiti delle condizioni operative del sistema (pp. 1-3);
• requisiti parametrali del sistema (pp. 3-7).

Requisiti delle condizioni operative del sistema
Le condizioni esterne per il sistema in fase di sviluppo possono essere definite come condizioni al contorno oppure come risultato del funzionamento del sistema generale.
Nella modellazione dinamica è necessario assicurarsi che le modalità operative definite siano coperte dal processo di modellazione.

Requisiti parametrali del sistema
Questi requisiti rappresentano i parametri forniti dal sistema stesso. Durante il processo di modellazione, possiamo ottenere questi parametri come risultati di calcolo e verificare che i requisiti siano soddisfatti in ciascun specifico calcolo.

Identificazione e codifica dei requisiti

Per facilitare il lavoro con i requisiti, gli standard esistenti raccomandano di assegnare un identificatore a ciascun requisito. È molto consigliabile utilizzare un sistema di codifica unificato per l'assegnazione degli identificatori.

Il codice di un requisito può essere semplicemente un numero che riflette il numero sequenziale del requisito, oppure può includere il codice del tipo di requisito, il codice del sistema o dell'aggregato a cui si applica, il codice del parametro, il codice della posizione e molto altro che un ingegnere possa immaginare. (puoi vedere un esempio di codifica nell'articolo)

La Tabella 1 fornisce un semplice esempio di codifica dei requisiti.

1. codice sorgente dei requisiti R - requisiti di specifiche tecniche;
2. codice tipo di requisiti E - requisiti - parametri dell'ambiente esterno, o condizioni operative
   S - requisiti forniti dal sistema;
3. codice di stato dell'aereo 0 – qualsiasi, G – a terra, F – in volo;
4. codice tipo parametri fisici T – temperatura, P – pressione, G – consumo, umidità H;
5. numero progressivo della richiesta.

Progetto del sistema di verifica dei requisiti.

Per ogni requisito di calcolo esiste un algoritmo di valutazione della conformità tra i parametri calcolati e quelli specificati nel requisito. Fondamentalmente, ogni sistema di gestione include sempre algoritmi di verifica dei requisiti come default. E anche ogni regolatore li contiene. Se la temperatura supera i limiti, si attiva l'aria condizionata. Pertanto, il primo passo di qualsiasi regolazione consiste nella verifica della conformità dei parametri al requisito.

E poiché la verifica è un algoritmo, è possibile utilizzare gli stessi mezzi e strumenti che utilizziamo per creare programmi di gestione. Ad esempio, l'ambiente SimInTech consente di creare pacchetti di progetto che contengono diverse parti del modello, realizzate come progetti separati (modello dell'oggetto, modello del sistema di gestione, modello dell'ambiente, ecc.).

Il progetto di verifica dei requisiti in questo caso diventa un progetto di algoritmi e si collega al pacchetto del modello. In modalità di modellazione dinamica, esegue un'analisi di conformità ai requisiti del documento tecnico.

Un possibile esempio di presentazione del progetto del sistema è mostrato nella figura 1.

Figura 1. Esempio di presentazione del progetto di verifica.

Analogamente agli algoritmi di gestione, i requisiti possono essere presentati come un insieme di fogli. Per facilitare il lavoro con gli algoritmi in ambienti di modellazione strutturale come SimInTech, Simulink, AmeSim, si utilizzano le funzionalità di creazione di strutture multilivello sotto forma di sottomodel. Questa organizzazione consente di raggruppare diversi requisiti in set per semplificare il lavoro con l'insieme di requisiti, come avviene per gli algoritmi di gestione (cfr. figura 2).

Figura 2. Struttura gerarchica del modello di verifica dei requisiti.

Ad esempio, nel caso in esame sono state individuate due categorie: requisiti per l'ambiente e requisiti specifici per il sistema. Pertanto, si utilizza una struttura dati a due livelli: due gruppi, ognuno dei quali è un foglio dell'algoritmo.

Per collegare i dati al modello, viene utilizzato uno schema standard per la formazione di un database di segnali, in cui sono memorizzati i dati per lo scambio tra le parti del progetto.

Durante la creazione e il test del software, in questo database vengono inseriti i valori dei sensori (analoghi ai sensori reali del sistema), che sono utilizzati dal sistema di gestione.
Per il progetto di test, in questo stesso database possono essere salvati qualsiasi parametro calcolato nel modello dinamico e utilizzato per verificare il rispetto dei requisiti.

Il modello dinamico in questo caso può essere realizzato in qualsiasi sistema di modellazione matematica o anche come programma eseguibile. L'unico requisito è la presenza di interfacce software per l'output dei dati di modellazione all'ambiente esterno.

Figura 3. Collegamento del progetto di verifica al modello complesso.

Un esempio del foglio di verifica dei requisiti è mostrato in figura 4. Dal punto di vista dello sviluppatore, rappresenta uno schema di calcolo ordinario, in cui viene visualizzato graficamente l'algoritmo di verifica dei requisiti.

Figura 4. Foglio di verifica dei requisiti.

Le principali parti della lista di controllo sono descritte nella figura 5. L'algoritmo di verifica viene formato in modo analogo agli schemi di calcolo degli algoritmi di gestione. Nella parte destra si trova il blocco di lettura dei segnali dal database. In questo blocco avviene l'accesso al database dei segnali durante la simulazione.

I segnali ottenuti vengono analizzati per calcolare le condizioni di verifica dei requisiti. Nel caso in esame, viene eseguita un'analisi dell'altezza per determinare la posizione dell'aereo (se si trova in parcheggio o in volo). A questo scopo possono essere utilizzati anche altri segnali e parametri calcolati del modello.

Le condizioni di verifica e i parametri verificati vengono trasferiti nei blocchi di verifica standard, dove avviene l'analisi dei dati di questi parametri per verificare la conformità ai requisiti stabiliti. I risultati vengono salvati nel database dei segnali in modo che possano essere utilizzati per la generazione automatica della lista di controllo.

Figura 5. Struttura della lista di verifica dei requisiti.

Non è necessario utilizzare come parametri controllati i segnali contenuti nel database, gestiti da parametri calcolati durante il processo di modellazione. Nulla vieta di effettuare calcoli aggiuntivi all'interno del progetto dei requisiti, proprio come calcoliamo le condizioni di verifica.

Ad esempio, un requisito del genere:

Il numero di attivazioni del sistema di correzione durante il volo verso l'obiettivo non dovrebbe superare 5, e il tempo totale di funzionamento del sistema di correzione non dovrebbe superare i 30 secondi.

In questo caso, nello schema di calcolo del progetto dei requisiti viene aggiunto un algoritmo per contare il numero di attivazioni e il tempo totale di funzionamento.

Modulo standard per la verifica dei requisiti.

Ogni modulo standard per la verifica dei requisiti è progettato per calcolare il soddisfacimento di un requisito di un certo tipo. Ad esempio, nei requisiti ambientali è presente un intervallo di temperature ambientali di lavoro sia durante la sosta che in volo. Questo modulo deve ricevere come parametro la temperatura dell'aria nel modello e determinare se questo valore rientra nell'intervallo di temperature stabilito.

Il blocco contiene due porte di ingresso, param e condition.

La prima porta riceve il parametro da verificare. In questo caso, è 'Temperatura esterna'.

Alla seconda porta viene fornita una variabile boolean – la condizione per l'esecuzione del controllo.

Se sulla seconda porta arriva TRUE (1), il blocco esegue il calcolo della verifica del requisito.

Se sulla seconda porta arriva FALSE (0), le condizioni di verifica non vengono eseguite. Questo è necessario per poter considerare le condizioni di calcolo. Nel nostro caso, questo ingresso viene utilizzato per attivare o disattivare il controllo a seconda dello stato del modello. Se l'UA è a terra durante la simulazione, i requisiti relativi al volo non vengono verificati, e viceversa – se l'UA è in volo, non vengono verificati i requisiti relativi all'operazione a terra.

Questo ingresso può essere utilizzato anche durante la configurazione del modello, ad esempio nella fase iniziale del calcolo. Quando il modello viene portato nelle condizioni richieste, i blocchi di verifica sono disattivati, ma non appena il sistema raggiunge la modalità di funzionamento richiesta, i blocchi di verifica vengono attivati.

Come parametri di questo blocco vengono specificati:

• condizioni limite: limite superiore (UpLimit) e limite inferiore (DownLimit) degli intervalli che devono essere verificati;
• tempo di attesa richiesto del sistema su intervalli limite (TimeInterval) in secondi;
• identificativo della richiesta ReqName;
• ammissibilità dell'uscita dall'intervallo Out_range – variabile booleana che determina se è una violazione della richiesta l'uscita del valore dall'intervallo controllato.

In alcuni casi, l'uscita del valore controllato indica che il sistema ha margine ed è in grado di operare al di fuori dell'intervallo operativo. In altri casi, l'uscita indica che il sistema non riesce a mantenere i parametri specificati all'interno dell'intervallo.

Figura 6. Blocco tipico di verifica della proprietà nello schema e i suoi parametri.

Come risultato del calcolo di questo blocco, viene generata la variabile Result, che assume i seguenti valori:

• 0 – rNone, valore non definito;
• 1 – rDone, requisito soddisfatto;
• 2 – rFault, requisito non soddisfatto.

L'immagine del blocco contiene:

• testo identificativo;
• visualizzazioni numeriche dei parametri dei limiti di misura;
• identificatore di stato del parametro di colore.

All'interno del blocco può trovarsi uno schema logico di output abbastanza complesso.

Ad esempio, per verificare l'intervallo di temperatura operativo del blocco, mostrato nella figura 6, lo schema interno è presentato nella figura 7.

Figura 7. Schema interno del blocco di determinazione dell'intervallo di temperature.

All'interno dei blocchi, gli schemi utilizzano proprietà definite nei parametri del blocco.
Oltre all'analisi della conformità ai requisiti, lo schema interno del blocco include un grafico necessario per presentare i risultati della simulazione. Questo grafico può essere utilizzato sia per la visualizzazione durante il calcolo che per l'analisi dei risultati dopo il calcolo.

I risultati del calcolo vengono trasmessi all'uscita del blocco e contemporaneamente registrati in un file di report generale, che viene creato sulla base dei risultati di tutto il progetto. (cfr. fig. 8)

Un esempio di report creato in base ai risultati della simulazione è un file HTML, generato secondo un formato specificato. Il formato può essere personalizzato arbitrariamente in base a quello adottato nella specifica organizzazione.

All'interno dei blocchi, gli schemi utilizzano proprietà definite nei parametri del blocco.
Oltre all'analisi della conformità ai requisiti, lo schema interno del blocco include un grafico necessario per presentare i risultati della simulazione. Questo grafico può essere utilizzato sia per la visualizzazione durante il calcolo che per l'analisi dei risultati dopo il calcolo.

I risultati del calcolo vengono trasmessi all'uscita del blocco e contemporaneamente registrati in un file di report generale, che viene creato sulla base dei risultati di tutto il progetto. (cfr. fig. 8)

Un esempio di report creato in base ai risultati della simulazione è un file HTML, generato secondo un formato specificato. Il formato può essere personalizzato arbitrariamente in base a quello adottato nella specifica organizzazione.

Figura 8. Esempio di file di report sui risultati della simulazione.

In questo esempio, la configurazione del modulo di report viene eseguita direttamente nelle proprietà del progetto, mentre il formato nella tabella è definito come segnali globali del progetto. In questo caso, SimInTech si occupa autonomamente della configurazione del report, e il blocco per la registrazione dei risultati nel file utilizza queste righe per scrivere nel file di report.

Figura 9. Configurazione del formato del report nei segnali globali del progetto

Utilizzo del database dei segnali per i requisiti.

Per automatizzare la gestione delle impostazioni delle proprietà per ciascun blocco standard, viene creata una struttura standard nel database dei segnali. (v. fig. 10)

Figura 10. Esempio della struttura di un blocco di verifica dei requisiti nel database dei segnali.

Il database dei segnali fornisce:

• Memorizzazione di tutti i parametri necessari ai requisiti del sistema.
• Visualizzazione conveniente dei requisiti esistenti nel progetto, sfruttando i parametri forniti e i risultati attuali della simulazione.
• Configurazione di un blocco singolo o di un gruppo di blocchi utilizzando un linguaggio di programmazione script. Le modifiche nel database dei segnali portano a una modifica dei valori delle proprietà del blocco nello schema.
• Memorizzazione di descrizioni testuali, collegamenti a elementi del capitolato o identificatori nel sistema di gestione dei requisiti.

Le strutture del database dei segnali per i requisiti possono essere facilmente configurate per funzionare con un sistema di gestione dei requisiti esterno. Lo schema generale di interazione con i sistemi di gestione dei requisiti è presentato nella Figura 11.

Figura 11. Schema di interazione con il sistema di gestione dei requisiti.

La sequenza di interazione del progetto di test SimInTech con il sistema di gestione dei requisiti è la seguente:

1. Il capitolato viene suddiviso in requisiti.
2. Vengono identificati i requisiti del capitolato che possono essere verificati tramite modellazione matematica dei processi tecnici.
3. Le caratteristiche dei requisiti identificati vengono trasferite nel database dei segnali SimInTech in strutture di blocchi standard (ad esempio, temperatura massima e minima).
4. Durante il calcolo, i dati delle strutture vengono trasferiti agli schemi di calcolo dei blocchi, viene eseguita un'analisi e i risultati vengono salvati nel database dei segnali.
5. Al termine del calcolo, i risultati dell'analisi vengono trasferiti al sistema di gestione dei requisiti.

Le fasi di lavoro con i requisiti 3-5 possono ripetersi durante il processo di progettazione, quando si verificano modifiche nella struttura e/o nei requisiti, e, di conseguenza, è necessaria una nuova verifica dell'impatto delle modifiche apportate.

Conclusioni.

• Il prototipo di sistema creato consente una significativa riduzione del tempo di analisi dei modelli esistenti in relazione ai requisiti del capitolato tecnico.
• La tecnologia di test proposta utilizza modelli dinamici esistenti e può essere applicata persino a qualsiasi modello dinamico, compresi quelli realizzati al di fuori dell'ambiente SimInTech.
• L'uso di un'organizzazione dati in pacchetti consente di creare pacchetti di verifica dei requisiti parallelamente allo sviluppo di modelli, o persino di utilizzare tali pacchetti come capitolato per lo sviluppo di modelli.
• La tecnologia può essere integrata con i sistemi di gestione dei requisiti esistenti senza costi significativi.

Per chi è arrivato fino alla fine, link al video che dimostra il funzionamento del prototipo.

Fonte: habr.com