Verifica automatica dei requisiti TOR nel processo di simulazione dinamica

Continuando il tema "Qual è la tua prova?", esaminiamo il problema della modellazione matematica dall'altro lato. Dopo che siamo convinti che il modello corrisponde alla verità della vita fatta in casa, possiamo rispondere alla domanda principale: "che cosa abbiamo qui esattamente?" Quando creiamo un modello di un oggetto tecnico, di solito vogliamo assicurarci che questo oggetto soddisfi le nostre aspettative. A questo scopo vengono eseguiti calcoli dinamici dei processi e il risultato viene confrontato con i requisiti. Questo è un gemello digitale, un prototipo virtuale, ecc. ragazzini alla moda che, in fase di progettazione, risolvono il problema di come assicurarsi di ottenere ciò che abbiamo pianificato.

Come possiamo assicurarci rapidamente che il nostro sistema sia esattamente ciò che progettiamo? Il nostro progetto volerà o galleggerà? E se vola, quanto in alto? E se galleggia, quanto è profondo?

Questo articolo discute l'automazione della verifica della conformità ai requisiti di un edificio tecnico durante la creazione di modelli dinamici di sistemi tecnici. Ad esempio, consideriamo un elemento delle specifiche tecniche di un sistema di raffreddamento dell'aria per un aereo.

Consideriamo quei requisiti che possono essere espressi numericamente e verificati matematicamente sulla base di uno specifico modello di calcolo. È chiaro che questi sono solo una parte dei requisiti generali di qualsiasi sistema tecnico, ma è nel controllarli che dedichiamo tempo, nervi e denaro alla creazione di modelli dinamici dell'oggetto.

Quando si descrivono i requisiti tecnici sotto forma di documento, si possono distinguere diversi tipi di requisiti diversi, ognuno dei quali richiede approcci diversi per la formazione della verifica automatica del rispetto dei requisiti.

Ad esempio, considera questo insieme piccolo ma realistico di requisiti:

1. Temperatura atmosferica dell'aria all'ingresso del sistema di trattamento dell'acqua:
   nel parcheggio - da meno 35 a 35 ºС,
   in volo - da meno 35 a 39 ºС.
2. La pressione statica dell'aria atmosferica in volo va da 700 a 1013 GPa (da 526 a 760 mm Hg).
3. La pressione totale dell'aria all'ingresso della presa d'aria SVO in volo va da 754 a 1200 GPa (da 566 a 1050 mm Hg).
4. Temperatura dell'aria di raffreddamento:
   nel parcheggio - non più di 27 ºС, per blocchi tecnici - non più di 29 ºС,
   in volo - non più di 25 ºС, per blocchi tecnici - non più di 27 ºС.
5. Flusso dell'aria di raffreddamento:
   in posizione di parcheggio - almeno 708 kg/h,
   in volo - non meno di 660 kg/h.
6. La temperatura dell'aria nei compartimenti degli strumenti non è superiore a 60 ºС.
7. La quantità di umidità fine nell'aria di raffreddamento non supera i 2 g/kg di aria secca.

Anche all’interno di questo insieme limitato di requisiti, ci sono almeno due categorie che devono essere gestite in modo diverso nel sistema:

• requisiti per le condizioni operative del sistema (clausole 1-3);
• requisiti parametrici per il sistema (clausole 3-7).

Requisiti delle condizioni operative del sistema
Le condizioni esterne per il sistema sviluppato durante la modellazione possono essere specificate come condizioni al contorno o come risultato del funzionamento del sistema generale.
Nella simulazione dinamica è necessario garantire che le condizioni operative specificate siano coperte dal processo di simulazione.

Requisiti di sistema parametrici
Questi requisiti sono parametri forniti dal sistema stesso. Durante il processo di modellazione, possiamo ottenere questi parametri come risultati del calcolo e assicurarci che i requisiti siano soddisfatti in ogni calcolo specifico.

Identificazione e codifica dei requisiti

Per facilitare l'utilizzo dei requisiti, gli standard esistenti consigliano di assegnare un identificatore a ciascun requisito. Quando si assegnano gli identificatori, è altamente auspicabile utilizzare un sistema di codifica unificato.

Un codice requisito può essere semplicemente un numero che rappresenta il numero d'ordine del requisito oppure può contenere un codice per il tipo di requisito, un codice per il sistema o l'unità a cui si applica, un codice parametro, un codice posizione e qualsiasi altra cosa che un ingegnere possa immaginare. (vedi l'articolo per l'uso della codifica)

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

1. codice della fonte dei requisiti Requisiti R TK;
2. codice tipo di requisiti E - requisiti - parametri ambientali o condizioni operative
   S - requisiti forniti dal sistema;
3. codice di stato dell'aeromobile 0 – qualsiasi, G – parcheggiato, F – in volo;
4. codice tipo parametro fisico T – temperatura, P – pressione, G – portata, umidità H;
5. numero di serie del requisito.

ID Requisiti	descrizione	Parametro
REGT01	Temperatura dell'aria ambiente all'ingresso del sistema di raffreddamento ad acqua: nel parcheggio - da meno 35ºС. fino a 35 ºС.
REFT01	Temperatura atmosferica dell'aria all'ingresso del sistema di difesa aerea: in volo - da meno 35 ºС a 39 ºС.
RIF01	La pressione atmosferica statica in volo va da 700 a 1013 hPa (da 526 a 760 mm Hg).
RIF02	La pressione totale dell'aria all'ingresso della presa d'aria SVO in volo va da 754 a 1200 hPa (da 566 a 1050 mm Hg).
RSGT01	Temperatura dell'aria di raffreddamento: a parcheggio non superiore a 27 ºС
RSGT02	Temperatura dell'aria di raffreddamento: nel parcheggio, per le unità tecniche non superiore a 29 ºС
RSFT01	La temperatura dell'aria di raffreddamento in volo non supera i 25 ºС
RSFT02	Temperatura dell'aria di raffreddamento: in volo, per le unità tecniche non superiore a 27 ºС
RSGG01	Portata aria di raffreddamento: a veicolo parcheggiato non inferiore a 708 kg/h
RSFG01	Portata d'aria di raffreddamento: in volo non inferiore a 660 kg/h
RS0T01	La temperatura dell'aria nei vani strumenti non supera i 60 ºС
RSH01	La quantità di umidità fine nell'aria di raffreddamento non supera i 2 g/kg di aria secca

Progettazione del sistema di verifica dei requisiti.

Per ogni requisito di progettazione esiste un algoritmo per valutare la corrispondenza dei parametri di progettazione e dei parametri specificati nel requisito. In generale, qualsiasi sistema di controllo contiene sempre algoritmi per verificare i requisiti semplicemente per impostazione predefinita. E anche qualsiasi regolatore li contiene. Se la temperatura esce dai limiti, il condizionatore si accende. Pertanto, la prima fase di qualsiasi regolamentazione è verificare se i parametri soddisfano i requisiti.

E poiché la verifica è un algoritmo, possiamo utilizzare gli stessi strumenti e strumenti che utilizziamo per creare programmi di controllo. Ad esempio, l'ambiente SimInTech consente di creare pacchetti di progetti contenenti varie parti del modello, eseguiti sotto forma di progetti separati (modello oggetto, modello sistema di controllo, modello ambiente, ecc.).

Il progetto di verifica dei requisiti in questo caso diventa lo stesso progetto dell'algoritmo ed è collegato al pacchetto del modello. E nella modalità di modellazione dinamica esegue un'analisi per la conformità ai requisiti delle specifiche tecniche.

Un possibile esempio di progettazione di un sistema è mostrato nella Figura 1.

Figura 1. Esempio di progettazione di un progetto di verifica.

Proprio come per gli algoritmi di controllo, i requisiti possono essere redatti come un insieme di fogli. Per la comodità di lavorare con algoritmi in ambienti di modellazione strutturale come SimInTech, Simulink, AmeSim, viene utilizzata la possibilità di creare strutture multilivello sotto forma di sottomodelli. Questa organizzazione consente di raggruppare vari requisiti in insiemi per semplificare il lavoro con una serie di requisiti, come avviene per gli algoritmi di controllo (vedi Fig. 2).

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

Ad esempio, nel caso in esame si distinguono due gruppi: requisiti per l'ambiente e requisiti direttamente per il sistema. Viene quindi utilizzata una struttura dati a due livelli: due gruppi, ciascuno dei quali è una foglia dell'algoritmo.

Per collegare i dati al modello, viene utilizzato uno schema standard per la generazione di un database di segnali, che memorizza i dati per lo scambio tra le parti del progetto.

Durante la creazione e il test del software, le letture dei sensori (analoghi dei sensori del sistema reale) utilizzati dal sistema di controllo vengono inserite in questo database.
Per un progetto di prova, eventuali parametri calcolati nel modello dinamico possono essere memorizzati nello stesso database e quindi utilizzati per verificare se i requisiti sono soddisfatti.

In questo caso, il modello dinamico stesso può essere eseguito in qualsiasi sistema di modellazione matematica o anche sotto forma di programma eseguibile. L'unico requisito è la presenza di interfacce software per l'emissione dei 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 di base è presentato nella Figura 4. Dal punto di vista dello sviluppatore, si tratta di un diagramma di calcolo convenzionale su cui viene presentato graficamente l'algoritmo di verifica dei requisiti.

Figura 4. Foglio di controllo dei requisiti.

Le parti principali del foglio di controllo sono descritte nella Figura 5. L'algoritmo di controllo è formato in modo simile ai diagrammi di progettazione degli algoritmi di controllo. Sul lato destro c'è un blocco per la lettura dei segnali dal database. Questo blocco accede al database dei segnali durante la simulazione.

I segnali ricevuti vengono analizzati per calcolare le condizioni di verifica dei requisiti. In questo caso viene eseguita l'analisi dell'altitudine per determinare la posizione dell'aereo (se è parcheggiato o in volo). A questo scopo è possibile utilizzare altri segnali e parametri calcolati del modello.

Le condizioni di verifica e i parametri da controllare vengono trasferiti a blocchi di verifica standard, in cui questi parametri vengono analizzati per verificarne la conformità ai requisiti specificati. I risultati vengono registrati nel database dei segnali in modo tale da poter essere utilizzati per generare automaticamente una lista di controllo.

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

I parametri da testare non utilizzano necessariamente i segnali contenuti nel database, che sono controllati da parametri calcolati durante il processo di simulazione. Nulla ci impedisce di effettuare calcoli aggiuntivi nell'ambito della bozza dei requisiti, così come calcoliamo le condizioni di verifica.

Ad esempio, questo requisito:

Il numero di attivazioni del sistema di correzione durante il volo verso il bersaglio non deve superare 5 e il tempo di funzionamento totale del sistema di correzione non deve superare i 30 secondi.

In questo caso, al diagramma di progettazione dei requisiti viene aggiunto un algoritmo per il conteggio del numero di avviamenti e del tempo di funzionamento totale.

Blocco tipico di verifica dei requisiti.

Ciascuna casella di controllo dei requisiti standard è progettata per calcolare il rispetto di un requisito di un determinato tipo. Ad esempio, i requisiti ambientali includono una gamma di temperature operative ambientali quando parcheggiato e in volo. Questo blocco deve ricevere come parametro la temperatura dell'aria nel modello e determinare se questo parametro copre l'intervallo di temperatura specificato./p>

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

Il primo è alimentato con il parametro da controllare. In questo caso “Temperatura esterna”.

Alla seconda porta viene fornita una variabile booleana, la condizione per eseguire il controllo.

Se viene ricevuto TRUE (1) al secondo ingresso, il blocco esegue un calcolo di verifica dei requisiti.

Se il secondo ingresso riceve FALSE (0), le condizioni del test non sono soddisfatte. Ciò è necessario affinché le condizioni di calcolo possano essere prese in considerazione. Nel nostro caso questo input viene utilizzato per abilitare o disabilitare il controllo a seconda dello stato del modello. Se l'aereo è a terra durante la simulazione, i requisiti relativi al volo non vengono controllati e viceversa, se l'aereo è in volo, i requisiti relativi all'operazione allo stand non vengono controllati.

Questo input può essere utilizzato anche durante l'impostazione del modello, ad esempio nella fase iniziale del calcolo. Quando il modello viene portato nello stato richiesto, le unità di verifica vengono disabilitate, ma non appena il sistema raggiunge la modalità operativa richiesta, le unità di verifica vengono attivate.

I parametri di questo blocco sono:

• condizioni al contorno: limiti dell'intervallo superiore (UpLimit) e inferiore (DownLimit) che devono essere controllati;
• tempo di esposizione del sistema richiesto negli intervalli limite (TimeInterval) in secondi;
• Richiedi ID ReqName;
• ammissibilità del superamento dell'intervallo Out_range è una variabile booleana che determina se un valore che supera l'intervallo controllato costituisce una violazione del requisito.

In alcuni casi, l'output del valore del test indica che il sistema ha un certo margine e potrebbe funzionare al di fuori del suo intervallo operativo. In altri casi, un'uscita significa che il sistema non è in grado di mantenere i setpoint entro l'intervallo.

Figura 6. Un tipico blocco di controllo delle proprietà nel diagramma e i relativi parametri.

In seguito al calcolo di questo blocco si forma in uscita la variabile Risultato che assume i seguenti valori:

• 0 – rNone, valore non definito;
• 1 – rFatto, il requisito è soddisfatto;
• 2 – rFault, il requisito non è soddisfatto.

L'immagine del blocco contiene:

• testo identificativo;
• visualizzazioni digitali dei parametri dei limiti di misurazione;
• identificatore di colore dello stato del parametro.

All'interno del blocco può esserci un circuito di inferenza logica piuttosto complesso.

Ad esempio, per verificare l'intervallo di temperatura operativa dell'unità mostrata nella Figura 6, il circuito interno è mostrato nella Figura 7.

Figura 7. Schema interno dell'unità di determinazione dell'intervallo di temperatura.

All'interno del blocco circuitale vengono utilizzate le proprietà specificate nei parametri del blocco.
Lo schema interno del blocco, oltre ad analizzare il rispetto dei requisiti, 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 trasmessi all'output del blocco e contemporaneamente vengono 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 determinato formato. Il formato può essere configurato arbitrariamente sul formato accettato da una particolare organizzazione.

All'interno del blocco circuitale vengono utilizzate le proprietà specificate nei parametri del blocco.
Lo schema interno del blocco, oltre ad analizzare il rispetto dei requisiti, 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 trasmessi all'output del blocco e contemporaneamente vengono 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 determinato formato. Il formato può essere configurato arbitrariamente sul formato accettato da una particolare organizzazione.

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

In questo esempio il modulo del report è configurato direttamente nelle proprietà del progetto e il formato nella tabella è impostato come segnali globali del progetto. In questo caso, SimInTech stesso risolve il problema dell'impostazione del report e il blocco per la scrittura dei risultati su un file utilizza queste righe per scrivere nel file del report.

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

Utilizzo di un database di segnali per i requisiti.

Per automatizzare il lavoro con le impostazioni delle proprietà, nel database dei segnali viene creata una struttura standard per ciascun blocco tipico. (vedi Fig. 10)

Figura 10. Esempio della struttura di un blocco di controllo dei requisiti in un database di segnali.

Il database dei segnali fornisce:

• Memorizzazione di tutti i parametri necessari per i requisiti di sistema.
• Comoda visualizzazione dei requisiti di progetto esistenti da parametri specificati e risultati di modellazione correnti.
• Impostazione di un blocco o di un gruppo di blocchi utilizzando un linguaggio di programmazione di scripting. Le modifiche nel database dei segnali portano a modifiche nei valori delle proprietà del blocco nel diagramma.
• Memorizzazione di descrizioni testuali, collegamenti a elementi di specifiche tecniche 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 di terze parti. Un diagramma generale dell'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 tra il progetto di test SimInTech e il sistema di controllo dei requisiti è la seguente:

1. I termini di riferimento sono suddivisi in requisiti.
2. Vengono individuati i requisiti delle specifiche tecniche che possono essere verificati mediante modellizzazione matematica dei processi tecnici.
3. Gli attributi dei requisiti selezionati vengono trasferiti al database dei segnali SimInTech nella struttura di blocchi standard (ad esempio, temperatura massima e minima).
4. Durante il processo di calcolo, i dati della struttura vengono trasferiti ai diagrammi di progettazione a blocchi, viene eseguita l'analisi e i risultati vengono archiviati in un database di segnali.
5. Una volta completato il calcolo, i risultati dell'analisi vengono trasferiti al sistema di gestione dei requisiti.

I passaggi dei requisiti da 3 a 5 possono essere ripetuti durante il processo di progettazione quando si verificano modifiche alla progettazione e/o ai requisiti e l'impatto delle modifiche deve essere nuovamente testato.

Conclusioni.

• Il prototipo del sistema creato prevede una significativa riduzione dei tempi di analisi dei modelli esistenti per la conformità ai requisiti delle specifiche tecniche.
• La tecnologia di test proposta utilizza modelli dinamici già esistenti e può essere utilizzata anche per qualsiasi modello dinamico, compresi quelli non eseguiti nell'ambiente SimInTech.
• L'utilizzo dell'organizzazione dei dati batch consente di creare pacchetti di verifica dei requisiti in parallelo con lo sviluppo del modello o addirittura di utilizzare questi pacchetti come specifiche tecniche per lo sviluppo del modello.
• La tecnologia può essere integrata con i sistemi di gestione dei requisiti esistenti senza costi significativi.

Per chi ha letto fino alla fine, collegamento a un video che mostra come funziona il prototipo.

Fonte: habr.com