Sintesi Tecnica: Decomposizione dei Requisiti Funzionali nella Progettazione Basata su Insiemi

Enunciato del Problema

La progettazione di sistemi ingegnerizzati complessi (ad esempio, aeromobili commerciali) nelle fasi iniziali è caratterizzata da incertezza e ambiguità intrinseche. Sebbene la Progettazione Basata su Insiemi (Set-Based Design, SBD) offra un quadro robusto per esplorare alternative e ridurre l'incertezza attraverso lo sviluppo parallelo, la letteratura attuale manca di linee guida formali su come decomporre i requisiti funzionali all'interno di questo paradigma. Nello specifico, gli approcci SBD esistenti trattano spesso i requisiti come semplici intervalli di prestazione, il che è insufficiente per sistemi complessi che coinvolgono interazioni software e meccaniche, dove le funzioni sono definite come mappature tra ingressi e uscite. Inoltre, l'affermazione secondo cui la SBD consente uno sviluppo autonomo e parallelo da parte di team di livello inferiore manca di una prova formale rigorosa. Vi è un bisogno critico di un metodo formale per decomporre i requisiti funzionali che garantisca che il sistema risultante soddisfi i requisiti di livello superiore, sostenendo al contempo l'autonomia dei team.

Metodologia

Il documento propone un metodo formale in quattro fasi per decomporre gerarchicamente i requisiti funzionali utilizzando un ragionamento basato su insiemi. L'approccio tratta le funzioni di sistema come trasformazioni matematiche ingresso-uscita ($f: (x, u, c) \to y$), dove $x$ sono gli ingressi, $y$ sono le uscite, $u$ sono parametri incerti non controllabili e $c$ sono parametri incerti controllabili.

La metodologia è strutturata come segue:

1. Definizione e Analisi dell'Architettura Funzionale:

   • Un'architettura funzionale è definita come un insieme di sotto-funzioni connesse.
   • Il metodo aggrega le variabili delle sotto-funzioni per identificare variabili condivise e spazi di progettazione/prestazione distinti.
   • Le variabili sono classificate in sei gruppi esclusivi in base al loro contesto di definizione (ad esempio, ingressi definiti solo a livello superiore rispetto alle sotto-funzioni, uscite condivise tra sotto-funzioni, ecc.).
   • Questo passaggio stabilisce lo spazio di progettazione iniziale e lo spazio di prestazione per il sistema.

2. Esplorazione degli Spazi Fattibili Iniziali:

   • Per ogni sotto-funzione, uno spazio fattibile iniziale è caratterizzato sulla base di implementazioni fattibili.
   • Questi spazi rappresentano gli intervalli più ampi possibili per ingressi, uscite e parametri prima dell'applicazione dei vincoli a livello di sistema.

3. Riduzione degli Spazi Fattibili:

   • Intersezione: Gli intervalli delle variabili definiti attraverso più sotto-funzioni vengono intersecati per creare uno spazio di progettazione fattibile iniziale unificato ($FDS_1$) e uno spazio di prestazione unificato ($FPS_1$).
   • Soddisfacimento dei Vincoli: Il metodo applica un problema di soddisfacimento dei vincoli quantificato per restringere ulteriormente lo spazio. Nello specifico, i parametri controllabili ($c$) vengono ristretti ($R^\downarrow_c$) in modo tale che, per tutti i valori dei parametri non controllabili ($u$) e degli ingressi ($x$), l'uscita del sistema rimanga all'interno dello spazio di prestazione fattibile.
   • Analisi di Raggiungibilità: L'analisi di raggiungibilità è utilizzata per calcolare una sovrastima dello spazio di prestazione raggiungibile ($FPS_2$) dato lo spazio di progettazione ristretto ($FDS_2$). Ciò garantisce che tutti i possibili comportamenti del sistema sotto i vincoli ristretti siano catturati.

4. Determinazione dei Sottorequisiti:

   • Espansione dell'Incertezza: Per accogliere una potenziale sottostima delle incertezze iniziali, lo spazio di prestazione desiderato ($FPS^*$) viene espanso da $FPS_2$ verso $FPS_1$. Questa espansione non è arbitraria; è governata da uno studio di compromesso.
   • Ottimizzazione: Viene formulato un problema di ottimizzazione basato su una funzione barriera per determinare i confini ottimali di $FPS^*$. L'obiettivo minimizza la "distanza" dai confini di $FPS_1$ (per consentire un margine di incertezza) e di $FPS_2$ (per evitare difficoltà di implementazione), ponderati in base alle preferenze del progettista.
   • Assegnazione Finale: Lo spazio di progettazione ristretto risultante ($FDS_2$) e lo spazio di prestazione espanso ($FPS^*$) vengono assegnati come sottorequisiti formali ($R^*_x, R^*_c, R^*_u, R^*_y$) per ogni sotto-funzione.

Contributi Chiave

Il documento apporta due contributi principali alla letteratura sulla SBD:

1. Metodo Formale di Decomposizione per Sistemi Complessi:

   • A differenza degli approcci SBD esistenti che definiscono i requisiti come intervalli di spazi di prestazione (adatti per componenti meccanici), questo metodo definisce i requisiti come mappature tra intervalli di ingresso e uscita. Questa formulazione è specificamente progettata per sistemi complessi che coinvolgono componenti diversi (meccanici, software, ecc.).
   • Il metodo fornisce una procedura rigorosa e ripetibile per decomporre queste mappature in sottorequisiti.

2. Dimostrazione Formale dello Sviluppo Parallelo (Autonomia):

   • Il documento introduce e dimostra due proprietà critiche: Raffinamento (riduzione dell'incertezza dai livelli superiori a quelli inferiori) e Componibilità (compatibilità delle interfacce tra sottorequisiti).
   • Teorema: Se i sottorequisiti a ogni livello sono componibili e la loro composizione raffina i requisiti funzionali di livello superiore, allora il sistema composito formato implementando indipendentemente questi sottorequisiti soddisferà i requisiti funzionali di livello superiore.
   • Ciò fornisce la prima giustificazione formale per l'affermazione secondo cui la SBD consente uno sviluppo autonomo e parallelo tra team di progettazione distribuiti.

3. Distinzione tra Margine di Sicurezza ed Eccesso:

   • Il metodo distingue esplicitamente tra "margine di sicurezza" (buffer) (valori dei parametri che compensano incertezze controllabili) ed "eccesso" (surplus che accoglie incertezze iniziali sottostimate). Questa distinzione è integrata nelle fasi di restringimento ed espansione della metodologia.

Risultati

Il metodo proposto è stato dimostrato attraverso uno studio di caso che coinvolge la progettazione di un sistema di controllo di crociera.

• Requisito di Livello Superiore: Il sistema deve mappare la velocità iniziale ($v_0$) e la velocità di riferimento ($v_r$) in una traiettoria di velocità reale ($v(t)$) che rimanga limitata e converga verso un intervallo target entro un tempo specifico.
• Decomposizione: La funzione di livello superiore è stata decomposta in otto sotto-funzioni che rappresentano le dinamiche fisiche (forze, attrito, aerodinamica) e la logica di controllo (controllore PID).
• Esecuzione del Processo:
  • Il metodo ha identificato con successo lo spazio di progettazione (ingressi e parametri controllabili come la velocità massima del motore $\omega_m$) e lo spazio di prestazione (forze intermedie, coppie e velocità).
  • Attraverso l'intersezione e l'analisi di raggiungibilità (utilizzando lo strumento CORA), lo spazio di progettazione fattibile è stato ristretto, vincolando specificamente il parametro controllabile $\omega_m$ da $[350, 480]$ a $[365, 450]$ rad/s per garantire la stabilità.
  • Il passaggio di ottimizzazione ha determinato i sottorequisiti finali, garantendo che le sotto-funzioni fossero componibili (le variabili condivise avevano intervalli coerenti) e che il sistema composito raffinasse i requisiti di livello superiore.
• Esito: I sottorequisiti risultanti hanno consentito l'implementazione indipendente dei sottosistemi (ad esempio, motore, pneumatici, controllore) garantendo matematicamente che il sistema integrato avrebbe soddisfatto i criteri di stabilità e convergenza di livello superiore.

Significato e Affermazioni

Il documento rivendica un significato nel colmare il divario tra i benefici teorici della Progettazione Basata su Insiemi e la necessità pratica di linee guida formali e attuabili nell'ingegneria dei requisiti.

• Formalismo rispetto agli Approcci Qualitativi: Gli autori sostengono che, sebbene la SBD sia ampiamente utilizzata (in particolare nei processi Toyota), spesso si basa su metodi qualitativi. Questo documento fornisce un quadro matematico formale che elimina l'ambiguità nella decomposizione.
• Abilitazione dell'Autonomia: Dimostrando che la componibilità e il raffinamento sono condizioni sufficienti per la soddisfazione a livello superiore, il metodo convalida la promessa SBD di autonomia dei team, consentendo a team distribuiti di lavorare in parallelo senza continui lavori di rielaborazione o fallimenti di integrazione.
• Gestione dell'Incertezza: L'approccio offre un modo strutturato per gestire l'incertezza attraverso "margine di sicurezza" ed "eccesso", andando oltre i semplici fattori di sicurezza verso una gestione più sfumata delle incertezze epistemiche e aleatorie.

Gli autori mantengono una posizione modesta riguardo alla portata, riconoscendo che il metodo non risolve tutte le sfide dell'ingegneria dei requisiti (come l'elicitazione o la validazione) e si affida al giudizio dell'ingegnere per coefficienti specifici nel passaggio di ottimizzazione. Posizionano il lavoro come un quadro per cosa deve essere risolto (i vincoli e le proprietà) piuttosto che prescrivere strumenti computazionali specifici per come risolvere i problemi di ottimizzazione sottostanti.