Verifica automatica dei requisiti del capitolato tecnico durante la modellazione dinamica

Continuando il tema «Quali sono le vostre prove?», analizziamo il problema della modellazione matematica da un'altra prospettiva. Dopo aver verificato che il modello corrisponde alla cruda verità della vita, possiamo rispondere alla domanda principale: «cosa abbiamo esattamente qui?». Creando un modello di un oggetto tecnico, di solito vogliamo assicurarci che questo oggetto soddisfi le nostre aspettative. Per questo motivo vengono effettuati calcoli dinamici dei processi e il risultato viene confrontato con i requisiti. Questo è il gemello digitale, il prototipo virtuale e altre modernità che, nella fase di progettazione, risolvono il problema di come fare in modo di ottenere ciò che abbiamo pianificato.

Come possiamo assicurarci rapidamente che il nostro sistema sia esattamente ciò che stiamo progettando, volerà o navigherà la nostra costruzione? E se vola, quanto in alto? E se naviga, quanto in profondità?

In questo articolo si esamina l'automazione del controllo del rispetto dei requisiti di un edificio tecnico nella creazione di modelli dinamici di sistemi tecnici. Come esempio, consideriamo un elemento del capitolato tecnico per il sistema di raffreddamento ad aria di un aereo.

Consideriamo i requisiti che possono essere espressi numericamente e verificati matematicamente sulla base di un modello di calcolo specifico. È chiaro che questo è solo una parte dei requisiti generali per qualsiasi sistema tecnico, ma è proprio su di essi che spendiamo tempo, nervi e denaro per creare modelli dinamici dell'oggetto.

Nella descrizione dei requisiti tecnici sotto forma di documento, si possono evidenziare diverse tipologie di requisiti, ognuna delle quali richiede approcci diversi per la formazione del controllo automatico del rispetto dei requisiti.

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

1. Temperatura dell'aria atmosferica in ingresso al SVO:
   a terra − da -35 a 35 ºC,
   in volo − da -35 a 39 ºC.
2. Pressione statica dell'aria atmosferica in volo − da 700 a 1013 GPa (da 526 a 760 mmHg).
3. Pressione totale dell'aria in ingresso al condotto d'aria del SVO in volo − da 754 a 1200 GPa (da 566 a 1050 mmHg).
4. Temperatura dell'aria di raffreddamento:
   a terra − non superiore a 27 ºC, per i blocchi tecnici − non superiore a 29 ºC,
   in volo − non più di 25 ºC, per i blocchi tecnici − non più di 27 ºC.
5. Consumo dell'aria di raffreddamento:
   a terra − non meno di 708 kg/h,
   in volo − non meno di 660 kg/h.
6. La temperatura dell'aria nei compartimenti degli strumenti − non più di 60 ºC.
7. La quantità di umidità fine libera nell'aria di raffreddamento − non più di 2 g/kg di aria secca.

Anche in un insieme così limitato di requisiti, si possono distinguere almeno due categorie che devono essere trattate in modo diverso nel sistema:

• requisiti delle condizioni operative del sistema (p.p. 1-3);
• requisiti parametrici del sistema (p.p. 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 o come risultato del funzionamento dell'intero sistema.
Nella modellazione dinamica è necessario assicurarsi che le modalità di funzionamento specificate siano coperte dal processo di modellazione.

Requisiti parametrici del sistema
Questi requisiti rappresentano i parametri forniti dal sistema stesso. Durante la modellazione, possiamo ottenere questi parametri come risultati dei calcoli e assicurarci che i requisiti siano soddisfatti in ciascun calcolo specifico.

Identificazione e codifica dei requisiti

Per facilitare il lavoro con i requisiti, gli standard esistenti raccomandano di assegnare un identificatore a ciascun requisito. Durante l'assegnazione degli identificatori è molto auspicabile utilizzare un unico sistema di codifica.

Il codice di un requisito può essere semplicemente un numero che riflette il numero d'ordine del requisito, oppure può contenere 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. (per un esempio di utilizzo della codifica, vedere l'articolo)

Nella tabella 1 è fornito un semplice esempio di codifica dei requisiti.

1. codice sorgente dei requisiti R- requisiti del capitolato tecnico;
2. codice tipo di requisiti E – requisiti – parametri dell'ambiente esterno, o condizioni operative
   S — requisiti forniti dal sistema;
3. codice stato dell'aereo 0 – qualsiasi, G – a terra, F – in volo;
4. codice tipo di parametri fisici T – temperatura, P – pressione, G – portata, umidità H;
5. numero d'ordine del requisito.

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 definiti nel requisito. In sostanza, ogni sistema di controllo contiene sempre algoritmi di verifica dei requisiti per impostazione predefinita. Anche ogni regolatore li contiene. Se la temperatura supera i limiti, viene attivato il condizionatore. Pertanto, il primo passo di qualsiasi regolazione è la verifica della conformità dei parametri al requisito.

E poiché la verifica è un algoritmo, è possibile utilizzare gli stessi strumenti e mezzi che utilizziamo per creare programmi di controllo. Ad esempio, l'ambiente SimInTech consente di creare pacchetti di progetti che contengono parti diverse del modello, realizzate sotto forma di progetti separati (modello dell'oggetto, modello del sistema di controllo, 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. E in modalità di modellazione dinamica esegue l'analisi della conformità ai requisiti del capitolato.

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

Figura 1. Esempio di presentazione del progetto di verifica.

Allo stesso modo, per gli algoritmi di gestione, i requisiti possono essere organizzati come un insieme di fogli. Per facilitare il lavoro con gli algoritmi in ambienti di modellazione strutturale come SimInTech, Simulink, AmeSim vengono utilizzate le possibilità di creazione di strutture multi-livello sotto forma di sottomodelli. Questa organizzazione consente di raggruppare requisiti diversi in insiemi per semplificare il lavoro con la massa di requisiti, come si fa per gli algoritmi di gestione (vedi Fig. 2).

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

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

Per collegare i dati al modello si utilizza uno schema standard di formazione di un database di segnali, in cui vengono memorizzati i dati per lo scambio tra le parti del progetto.

Durante la creazione e il collaudo del software, in questo database vengono inserite le letture dei sensori (analoghi ai sensori reali del sistema) utilizzati dal sistema di gestione.
Per il progetto di verifica, in questo stesso database possono essere salvati qualsiasi parametri calcolati nel modello dinamico e in tal modo utilizzati per verificare il rispetto dei requisiti.

Il modello dinamico, in questo caso, può essere realizzato in qualsiasi sistema di modellazione matematica o anche sotto forma di un programma eseguibile. L'unico requisito è la presenza di interfacce software per l'emissione di dati di modellazione verso l'ambiente esterno.

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

Un esempio di foglio di verifica dei requisiti è mostrato in figura 4. Dal punto di vista dello sviluppatore, si presenta come uno schema di calcolo ordinario, in cui l'algoritmo di verifica dei requisiti è rappresentato graficamente.

Figura 4. Foglio di verifica dei requisiti.

Le parti principali del foglio di verifica sono descritte nella figura 5. L'algoritmo di verifica è formato analogamente agli schemi di calcolo degli algoritmi di gestione. Nella parte destra si trova un blocco che legge i segnali dal database. In questo blocco avviene l'accesso al database dei segnali durante la modellazione.

I segnali ricevuti 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 è in sosta o in volo). A questo scopo, è possibile utilizzare anche altri segnali e parametri calcolati del modello.

Le condizioni di verifica e i parametri da verificare vengono trasmessi a blocchi di verifica standardizzati, nei quali viene effettuata l'analisi di questi parametri per verificarne la conformità ai requisiti stabiliti. I risultati vengono registrati nel database dei segnali in modo tale da essere utilizzabili per la creazione automatica di una checklist.

Figura 5. Struttura del foglio di calcolo per la verifica dei requisiti.

Non è necessario utilizzare come parametri da verificare i segnali contenuti nel database, gestiti da parametri calcolati durante il processo di modellazione. Non c'è nulla che impedisca nel progetto dei requisiti di effettuare calcoli aggiuntivi, così 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 deve superare 5, e il tempo totale di funzionamento del sistema di correzione non deve superare i 30 secondi.

In questo caso, nell'architettura di calcolo del progetto dei requisiti viene aggiunto un algoritmo contatore per le attivazioni e il tempo totale di funzionamento.

Blocchi di verifica standardizzati per i requisiti.

Ogni blocco standardizzato per i requisiti è destinato a calcolare l'adeguatezza di un requisito di un determinato tipo. Ad esempio, nei requisiti ambientali è presente un intervallo di temperature operative dell'aria circostante sia in sosta che in volo. Questo blocco deve ricevere come parametro la temperatura dell'aria nel modello e determinare se questo parametro copre l'intervallo di temperature specificato.

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

Alla prima viene fornito il parametro da verificare. In questo caso, "Temperatura ambiente esterna".

Alla seconda porta viene fornita una variabile booleana - la condizione per l'esecuzione della verifica.

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

Se sul secondo ingresso arriva FALSE (0), le condizioni di verifica non vengono eseguite. Questo è necessario per considerare le condizioni di calcolo. Nel nostro caso, questo ingresso viene utilizzato per attivare o disattivare la verifica in base allo stato del modello. Se l'aeromobile è a terra durante la simulazione, i requisiti relativi al volo non vengono verificati, e viceversa: se l'aeromobile è in volo, non vengono verificati i requisiti relativi al lavoro in stazionamento.

Questo ingresso può essere utilizzato anche per configurare il modello, ad esempio, nelle fasi iniziali del calcolo. Quando il modello viene portato nelle condizioni richieste, i blocchi di verifica sono disattivati, ma non appena il sistema entra nella modalità di funzionamento richiesta, i blocchi di verifica vengono attivati.

I parametri di questo blocco sono:

• condizioni di confine: limiti superiori (UpLimit) e inferiori (DownLimit) delle gamme che devono essere verificate;
• tempo di mantenimento richiesto del sistema sui limiti di confine (TimeInterval) in secondi;
• identificatore del requisito ReqName;
• ammissibilità di uscita dall'intervallo Out_range – una variabile booleana che determina se l'uscita del valore dal range controllato è una violazione del requisito.

In alcuni casi, l'uscita del valore controllato indica che il sistema ha un margine e può operare oltre il range di lavoro. In altri casi, l'uscita indica che il sistema non è in grado di mantenere i parametri stabiliti all'interno del range.

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

A seguito del calcolo di questo blocco, viene generata una variabile Result in uscita, che può assumere i seguenti valori:

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

L'immagine del blocco contiene:

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

All'interno del blocco potrebbe trovarsi uno schema di deduzione logica piuttosto complesso.

Ad esempio, per controllare il range operativo delle temperature 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 del blocco si utilizzano proprietà definite nei parametri del blocco.
Oltre all'analisi della conformità ai requisiti, lo schema interno del blocco contiene un grafico necessario per visualizzare 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 trasferiti in uscita dal blocco e contemporaneamente registrati in un file di report generale, che viene creato sulla base dei risultati dell'intero progetto. (vedi fig. 8)

Un esempio di report, creato in base ai risultati della simulazione, è un file html, creato secondo un formato specificato. Il formato può essere configurato liberamente per adattarsi a quello adottato da una particolare organizzazione.

All'interno del blocco si utilizzano proprietà definite nei parametri del blocco.
Oltre all'analisi della conformità ai requisiti, lo schema interno del blocco contiene un grafico necessario per visualizzare 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 trasferiti in uscita dal blocco e contemporaneamente registrati in un file di report generale, che viene creato sulla base dei risultati dell'intero progetto. (vedi fig. 8)

Un esempio di report, creato in base ai risultati della simulazione, è un file html, creato secondo un formato specificato. Il formato può essere configurato liberamente per adattarsi a quello adottato da una particolare organizzazione.

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

In questo esempio, la configurazione della forma del report viene eseguita direttamente nelle proprietà del progetto, e il formato è specificato nella tabella come segnali globali del progetto. In questo caso, SimInTech si occupa della configurazione del report, mentre il blocco di registrazione dei risultati nel file utilizza queste righe per registrare 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 il lavoro con le impostazioni delle proprietà per ogni blocco standard, viene creata una struttura standard nel database dei segnali. (vedi fig. 10)

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

Il database dei segnali fornisce:

• Conservazione di tutti i parametri necessari a soddisfare i requisiti del sistema.
• Visualizzazione conveniente dei requisiti esistenti nel progetto basati sui parametri specificati e sui risultati correnti della simulazione.
• Impostazione di un blocco o di un gruppo di blocchi utilizzando un linguaggio di scripting. Le modifiche nel database dei segnali portano a cambiamenti nei valori delle proprietà del blocco nello schema.
• Conservazione di descrizioni testuali, collegamenti ai punti del capitolato o identificatori nel sistema di gestione dei requisiti.

Le strutture del database dei segnali per i requisiti possono essere facilmente configurate per lavorare con sistemi di gestione dei requisiti di terze parti. Lo schema generale di interazione con i sistemi di gestione dei requisiti è illustrato 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 compito tecnico viene suddiviso in requisiti.
2. Vengono identificati i requisiti del compito tecnico che possono essere verificati tramite modellazione matematica dei processi tecnici.
3. Gli attributi dei requisiti identificati vengono trasferiti nel database dei segnali SimInTech nelle strutture dei blocchi standard (ad esempio, temperatura massima e minima).
4. Durante il calcolo, i dati delle strutture vengono trasferiti negli schemi di calcolo dei blocchi, viene eseguita l'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 cambiamenti nella costruzione e/o nei requisiti e, di conseguenza, è necessaria una nuova verifica dell'impatto delle modifiche apportate.

Conclusioni.

• Il prototipo creato del sistema consente una significativa riduzione del tempo di analisi dei modelli esistenti rispetto ai requisiti del compito tecnico.
• La tecnologia di test proposta utilizza modelli dinamici già esistenti e può essere utilizzata anche per qualsiasi modello dinamico, inclusi quelli creati al di fuori dell'ambiente SimInTech.
• L'uso dell'organizzazione dati in pacchetti consente di creare pacchetti di verifica dei requisiti paralleli allo sviluppo dei modelli, o persino di utilizzare tali pacchetti come compiti tecnici per lo sviluppo di modelli.
• La tecnologia può essere integrata con le esistenti sistemi di gestione dei requisiti senza significativi costi.

Per coloro che hanno letto fino in fondo, link al video della dimostrazione del funzionamento del prototipo.

Fonte: habr.com