Dal Megaevento

Alla Megastruttura

Aeroporto L'

Della Emblema

Città Globale

Nathalie Roseau In

Che Senso L'aeroporto

ARGOMENTI

esposizione -sportiva, tecnologica, artistica o politica -è essenzialmente effimera, uno strumento di commemorazione, vetrina per dimostrazioni di future prodezze.

caratterizzano le rappresentazioni all'opera nella concezione aeroportuale. Emblemi, vetrine e nello stesso tempo, strumenti possibili di riforma: il loro carattere ambiguo di monumento del futuro si è cristallizzato in questi primi progetti e si è mantenuto nelle varie realizzazioni che sono venute in seguito. Da Atene a Pechino, da Hong Kong a Sciangai, i grandi eventi urbani hanno captato la figura aeroportuale per produrre, in modo diverso, realizzazioni spettacolari in cui convergono più criteri, tecnologici, architettonici, urbani e metropolitani. Infrastruttura decisiva per far figurare le città sulla carta degli hub globali, mezzo strategico destinato ad affermare la potenza e l'indipendenza politica delle città: più che un evento urbano circoscritto e localizzato, alcuni aeroporti hanno perfino dato inizio alla rifondazione di megalopoli vere e proprie 2 . È a queste mutazioni che consacreremo un secondo sviluppo, esplorando non solo il modo in cui queste infrastrutture diventano ibride delle condizioni urbane del sito d'accoglienza, ma ancor più influenzano, oltre i loro confini apparenti, la fabbrica urbana.

Saranno esplorate due situazioni, nate in periodi diversi e in contesti politici singolari. La prima si presenta durante la seconda metà degli anni 30: si tratta dell'aeroporto di Le Bourget, strumento di propaganda aeronautica, urbana, nazionale, ingrandito e riorganizzato in occasione dell'apertura dell'esposizione internazionale del 1937 a Parigi. La seconda appare alla fine degli anni'80 con l'aeroporto di Chep Lap Kok a Hong Kong, flagship di una città globale, che riafferma l'indipendenza dell'arcipelago nell'attesa della retrocessione dell'ex-colonia britannica alla Cina comunista nel 1997. Per quanto lontanissimi geograficamente e storicamente, questi due esempi presentano aspetti che riecheggiano tra loro e che ci riportano al tema dei grandi eventi urbani.

Come vedremo, l'atto di nascita eminentemente urbano dell'aeroporto moderno, si esplica attraverso gli stretti vincoli che lo sviluppo dell'aviazione ha molto presto instaurato con le riflessioni sulla città del futuro. Materializzando una frontiera, letterale e figurata, che segna e oltrepassa i contorni della città, la concezione aeroportuale promuove l'idea di una sperimentazione urbana, che va oltre le contingenze della città d'approdo, pur invocando regolarmente i dibattiti urbani di cui essa è l'oggetto. Come l'esposizione, l'aeroporto "racconta" e cristallizza una storia urbana, che prende parte alla realizzazione dei disegno metropolitano. In questo, questi oggetti del futuro e della modernità sono sia storici che geografici.

La città del futuro

La conquista meccanica del cielo non ha avuto come effetto naturale di consacrare l'aeroporto come figura principale di mediazione tra l'aviazione e l'ambiente urbano. Certo, degli aerodromi, flugfeld, airfield, fioriscono fin dagli albori dell'aviazione, per accogliere gli aerei, i loro hangar ed i loro piloti. Ma l'apparizione di quest'infrastruttura sommaria è accompagnata anche da un dibattito transnazionale sulla città come spazio suscettibile di essere riformato da questa nuova mobilità emergente 3 . Le imprese dei pionieri dell'aviazione usufruiranno di un supporto mediatico senza precedenti che si manifesterà a partire dagli anni 1908-1909. Saloni, riunioni sportive, dimostrazioni di volo in città: tutti questi eventi a grande risonanza mediatica rivelano la nascita dell'aviazione al grande pubblico e sono raccontati dalle cronache dei giornali illustrati. Prodezze, rischi, cadute, nascita di nuovi eroi: la loro dimensione spettacolare è anche all'origine dei primi momenti di mutazione. La realtà del volo e la mediatizzazione delle imprese eroiche sembrano allora capovolgere le visioni delle città aeree dall'universo della letteratura fantastica verso il campo pro- fessionale degli attori che operano sulla città. Viene forgiato un discorso che esalta il sogno di una libertà di spostamento in grado di liberarci dalle contingenze terrestri. Si immagina la possibilità di un trasporto personale e domestico, idea che sarà particolarmente forte negli Stati Uniti, e fino all'inizio degli anni'50 4 . Fioriscono i progetti di città in cui gli aerei giocano ben più che un ruolo di comparse. Le immagini di cittàsuperiori e di città-regione proliferano, consolidate da questa nuova mobilità. Buckminster Fuller sogna perfino di smaterializzare la città, liberandola definitivamente dalla immobilità terrestre. La città si lancia alla conquista del cielo.

Da Eugène Hénard ad Harvey Corbett, da Le Corbusier a Hugh Ferriss, dai futuristi italiani ai suprematisti russi, tetti di palazzi e di grattacieli, piazzali e piattaforme formano gli interstizi attraverso i quali l'aereo si introduce nella città. Lungi dal favorire la creazione di una tipologia specifica, l'aereo s'invita naturalmente in un universo riformato, facendo della città stessa una sua infrastruttura, rimodellando i suoi dispositivi, operando una trasformazione strutturale dell'ambiente urbano. Misurandosi con la città nel suo insieme, mettendo in luce le scelte operate, le visioni suggerite catalizzano idee latenti per esplorarle in un universo nuovo.

Il gioiello urbano

Dall'utopia delle possibilità alla materializzazione dei progetti, si elabora un supporto di riferimenti che associano l'urbano e l'aereo, sulla base del quale si spiegano le prime realizzazioni aeroportuali di grande estensione. Questo periodo «formativo» 5 , testimone della proliferazione delle immagini e dei discorsi, non è estraneo ai concetti che guideranno la realizzazione dei grandi aeroporti internazionali. Questi legami saranno tanto più caratteristici in quanto alcuni tra i visionari che immaginano città aeree rientrano tra i protagonisti della costruzione degli aeroporti delle città. L'immaginario della 'città aerea' sembra così essere un anello determinante nella catena della realizzazione materiale dell'infrastruttura, tanto come immaginario sociale che come campo di apprendimento degli attori.

È verso la metà degli anni'30 che emerge la figura urbana dell'aeroporto. L'aumento dei flussi di traffico spiega questa svolta decisiva. L'apparizione di alcuni eventi urbani a forte risonanza è anche un fattore che precipita la realizzazione dell'ambizione, agendo in un certo senso come un catalizzatore. Esposizioni universali, giochi olimpici, progetti di città intere, programmi di grandi dimensioni stimolano l'immaginazione urbana e, con essa, i progetti aeroportuali. I legami sono ancor più tangibili in quanto questi eventi investono il soggetto urbano. In previsione della commemorazione del 700° anniversario della capitale tedesca, che deve aver luogo nel 1937, Hitler affida, fin dal suo arrivo al potere, il riallestimento di Berlino all'architetto Albert Speer. La città diventa oggetto di un piano di rifondazione che prefigura il sogno megalomaniaco di una capitale del Terzo Reich, Germania, il cui progetto non vedrà mai alla luce a causa del conflitto mondiale. Il progetto iniziale di Speer consolida una città-paesaggio, opera totale articolata su viali e parchi, ritmata da monumenti su scala smisurata, elevati alla gloria del regime nazista. Il rinnovamento dell'aeroporto di Tempelhof prefigura una della future centralità emblematiche della capitale 6

. [Fig 1 e 2]

Dal canto suo, Parigi vuol fare onore al suo prestigio ed ai suoi visitatori. L'Esposizione del 1937 sarà l'occasione di rinnovare in profondità l'aeroporto di Le Bourget. Aperta il 30 Aprile 1939, l'esposizione di New York progetta il futuro con l'aiuto di dispositivi ricchi d'inventiva, che traducono la città in un modello, in un film o in un'attrazione. Il Futurama, la Democracity saranno tra gli spettacoli più visitati della manifestazione. Destinato ad accogliere gran parte dei visitatori dell'esposizione, il nuovo aeroporto La Guardia viene inaugurato qualche mese dopo, aggiungendo un nuovo gioiello all'esposizione stessa.

[Fig 3 e 4]

Limitrofo alla città, l'aeroporto prefigura la sua estensione, marcando una doppia appartenenza alla città da lui collegata ed al suo orizzonte di frontiera. I progetti sviluppano l'idea di una nuova centralità, e dispongono di amenità urbane, di confort e di attrattive; il piazzale accanto all'aeroporto riunisce un insieme di servizi urbani: fiera, albergo, negozi, scuola di pilotaggio, campi sportivi, …. I piani mostrano, senza soluzione di continuità, un insieme su larga scala, distendendo le misure, consolidando diverse funzioni in un solo edificio e organizzando secondo una razionalità senza uguali le vie, i giardini, i terreni, gli edifici. Se l'aeroporto incarna un insieme urbano, s'iscrive anche in una concorrenza mondiale. Le riviste professionali consacrano d'altra parte interi fascicoli a questo nuovo oggetto, attestando la sua mondializzazione. L'aeroporto acquisisce così molto presto uno status inedito di emblema della competizione metropolitana. Bisogna a questo scopo sottolineare l'ambivalenza del termine di «porta d'entrata», che figura nella retorica aeroportuale. È una porta che apre ai cittadini nuovi orizzonti, ma è anche una facciata emblematica della città per chi vi approda.

Una figura narrativa

Il trasporto aereo ha frantumato le frontiere e ristretto l'universo, e il mondo così osserva le città e le confronta. «Una spiacevole impressione all'arrivo. In questa regione, Parigi si presenta male con la sua periferia immediata. La capitale non ha il vestibolo che le conviene. [...] L'aeroporto è per lo straniero la facciata della nazione, questa immagine [deve estendersi] al paesaggio scoperto al momento di accedere all'Esposizione. […] In Germania tutto è stato fatto per impressionare con forza lo spirito del passeggero che prenderà contatto a Tempelhof con la 'grande Germania' [START_REF]prendra contact à Tempelhof avec la 'grande Allemagne[END_REF] .» Vessillo urbano, nazionale e politico, l'aeroporto sembra incarnare uno degli elementi più importanti della metropoli in divenire.

La controversia che suscita il concorso per l'ampliamento di Le Bourget testimonia delle poste in gioco sollevate dal programma aeroportuale. La scelta dell'insediamento dell'aeroporto internazionale di Parigi opponeva già da qualche anno i difensori del rinforzo di Le Bourget a coloro che militavano per la costruzione di un porto intercontinentale a Trappes, nel Sud-ovest della regione di Parigi. Fautore di quest'ultima soluzione, l'architetto Urbain Cassan si rivela molto critico sul programma del concorso di Le Bourget, insistendo a contrario sulle qualità del progetto di Trappes, del quale mette in risalto il vantaggio più importante: «Considero superfluo sottolineare ancora l'importanza psicologica di questi due modi di raggiungere la capitale, uno che proietterà il viaggiatore venuto dall'America, dall'Asia, dall'Europa centrale o dai paesi scandinavi, al Bois de Boulogne, poi all'Etoile e sugli Champs Elysées, questi quartieri dove l'urbanismo ha lasciato un'impronta geniale tanto ricercata dagli stranieri; l'altro che lo farà uscire da sotto terra, sulla spianata degli Invalidi, al quai d'Orsay, parola magica che, per tutti i paesi del mondo significa politicamente 'La Francia' 8 » I fautori di Le Bourget rispondono agli attacchi, spiegando che il «brutto volto» di Parigi potrebbe essere abbellito con l'installazione di vasti prati fioriti lungo la linea ferroviaria che collegherebbe l'aeroporto alle stazioni ferroviarie parigine [START_REF]L'arrivée en avion au dessus de la région de Versailles ne manque pas de majesté et les accès dans Paris sont séduisants[END_REF] Difensori o detrattori di Le Bourget confermano tutti la pregnanza dell'immagine dell'aeroporto come porta d'ingresso nobile della città. Nell'una o nell'altra situazione, l'aeroporto deve essere rimarchevole, rappresentare l'immagine perfetta di un' architettura controllato ed ambizioso. Oltre l'aeroporto in se stesso, è l'insieme del percorso dall'aeroporto alla capitale che deve, in forma narrativa, offrire un'immagine esemplare del volto della città. Nella sua presentazione delle risposte al concorso di Le Bourget, il commento della rivista Architecture d'Aujourd'hui, ci informa sull'intenzione generale di fare dell'aeroporto una vetrina ad uso locale e mondiale: «È là che il viaggiatore straniero avrà il suo primo contatto con il paese che lo riceve. […] In modo particolare è importante che la sua prima impressione sia eccellente; la nostra propaganda nazionale ha molto da guadagnarci. […] [START_REF]Il importe particulièrement que sa première impression soit excellente ; notre propagande nationale a fortement à y gagner[END_REF] » Scenografia e propaganda L'aeroporto è non solo uno strumento di propaganda urbana e nazionale, ma è anche un luogo di promozione del trasporto aereo. La tecnologia affascina, tanto più che la success story delle imprese aviatorie continua. A Parigi e New York, Lindbergh, Costes e Bellonte hanno attirato folle immense per acclamarli in occasione delle loro traversate dell'Atlantico. Questa promozione del progresso tecnologico figurerà tra gli elementi del programma aeroportuale.

Stabilito nel 1935, il programma del concorso di Le Bourget presenta le raccomandazioni del comitato di propaganda aeronautica: «L'aerostazione di Parigi deve costituire un centro di propaganda aeronautica, e come tale, deve possedere locali aperti al pubblico e che si prestino ad accogliere vaste manifestazioni [START_REF]L'aérogare de Paris doit constituer un centre de propagande aéronautique, et comme tel posséder des locaux ouverts au public, se prêtant à de larges manifestations[END_REF] » Il dispositivo delle terrazze illustra questa ambizione di aprire ampiamente l'aeroporto. Ricollegandosi ai grandi meeting di prima della guerra, passeggiate, deck, immense piattaforme, coprono i tetti degli edifici. Le grandi hall a vetri si aprono sulle piste. Si installano così un certo numero di dispositivi, la cui finalità è di permettere al maggior numero possibile di persone di usufruire dello spettacolo del volo. Le terrazze di Tempelhof che formano il tetto della gigantesca aerostazione possono accogliere simultaneamente decine di migliaia di persone e contribuiscono a fare dell'aeroporto uno strumento della propaganda nazionale a destinazione della popolazione tedesca e degli osservatori stranieri. L'aeroporto La Guardia per esempio possiede una immensa passeggiata curvilinea lunga 1500 piedi, che forma una piattaforma di osservazione e che copre la galleria d'imbarco e di sbarco dei passeggeri. Costitutiva della splendida epopea della conquista del cielo, la dimensione dello spettacolo si amplifica lungo tutta l'avventura aeroportuale, grazie a questi nuovi dispositivi spaziali e visivi.

[Fig 6]

Alla vigilia del secondo conflitto mondiale, questa figura dello spettacolo riveste una dimensione multipla. Non è più unicamente lo spettacolo degli aerei a terra o in volo che si viene a guardare, come visitatore, vicino o passeggero, ma l'aeroporto in sé, novità di un genere inedito. Il viaggio comincia fin dall'arrivo in questo luogo magico, nell'ambito del quale i curiosi vengono a riposarsi durante il giorno, commentano i modelli di aerei, ammirano il panorama sulla pista, approfittano delle attrazioni molteplici offerte dall'aeroporto. I termini del concorso organizzato nel 1935 per il nuovo aeroporto di Le Bourget evocano un insieme di programmi che insistono più sul divertimento che su una funzionalità pratica. I progetti sottoposti alla competizione accumulano un crescendo di proposte il cui obiettivo è di dotare l'aeroporto delle amenità più varie: «Giardini che costituiranno un ingresso particolarmente nobile all'aeroporto di Parigi. […] Negozi, edicole offriranno [al visitatore] tutto quel che può desiderare: articoli per fumatori, strumenti ottici, prodotti farmaceutici, souvenir […] Una grandissima sala per feste e riunioni. Un palcoscenico in grado di ospitare un'orchestra o di essere trasformato in scena di teatro […] [START_REF]Des jardins qui constitueront un accès particulièrement noble à l'aéroport de Paris[END_REF] » Conferenze, proiezioni cinematografiche possono ormai aver luogo nell'aeroporto. Questa alchimia ritorna in modo ricorrente, i partecipanti al concorso di Le Bourget -Georges Labro (vincitore del concorso e architetto del futuro aeroporto), Pingusson, Mallet-Stevens, Beaudouin e Lods -fanno infatti riferimento a dimensioni affini, nonostante le importanti differenze tra i progetti.

Il monumento del futuro

Il concorso di Le Bourget attesta la volontà di impressionare le mentalità con una grande opera: l'«aeroporto moderno». La rivista Architecture d'Aujourd'hui insi- ste: «Bisogna tuttavia augurarsi che tutto sia stato calcolato per dotare Parigi, prima città del Mondo, di un AEROPORTO uguale o superiore ai migliori che esistono all'ESTERO, e le cui lezioni debbono essere messe a profitto in vista della realizzazione di un'opera d'«ultimo grido», che peraltro sappia ben esprimere il Genio francese [START_REF]Il est cependant à souhaiter que tout ait été calculé pour doter Paris, Première ville du Monde, d'un AEROPORT égalant ou surpassant même les meilleurs qui existent à l'ETRANGER, et dont les leçons sont à tirer en vue de la réalisation d'une oeuvre «dernier cri[END_REF] » I dibattiti a proposito del concorso e dei suoi risultati contraddistinguono questo confronto tra l'immagine di un monumento simbolico ed il carattere inedito di un programma che apre nuove dimensioni. D'ispirazione classica, gli architetti concorrenti per il progetto di Le Bourget fanno evolvere le loro riflessioni. Vengono presentati dispositivi conosciuti: cortile d'onore, largo spiazzo alberato, grande hall a vetri piena di luce, simmetria delle facciate, ornamentazione. Gli aeroporti presentano tutti dimensioni impressionantiquello di Le Bourget misura 220 metri di lunghezza -condizionate dal gioco delle terrazze, ma anche dalla necessità di adeguarsi alla misura del terreno gigantesco che costituisce l'aeroporto.

Nel cuore del progetto di capitale del Terzo Reich, nell'orbita delle ambizioni urbane di Parigi o New York, l'aeroporto sembra tuttavia soffrire della stessa sindrome dei padiglioni delle esposizioni. Teatro e scena del futuro, monumento alla città di cui è il mezzo di collegamento, frontiera della metropoli dell'avvenire, l'aeroporto rivela numerose ambiguità, tra prospettiva del futuro e commemorazione di una particolare grandeur. L'eco data al grande evento urbano al quale è associata l'impresa di realizzazione dell'aeroporto mette in rilievo questo paradosso strutturale di un oggetto la cui agenda riformatrice si traduce con una spettacolarizzazione della potenza e della fierezza delle città.

La metropoli a portata di mano

Questa dimensione d'emblema futurista è restata pregnante nelle realizzazioni aeroportuali che hanno costantemente cercato di oltrepassare i limiti, architettonici ed urbani, spaziali e territoriali, strutturali e materiali. Anticipando sulla formidabile crescita del trasporto aereo, gli aeroporti realizzati dopo la guerra, in un periodo d'euforia economica e tecnologica, in un contesto d'espansione urbana, realizzano le prime megastrutture, tra le quali figurano in modo particolare l'International Arrivals Building (Skidmore, Owings and Merrill, 1957) all'aeroporto Idlewild di New York (futuro aeroporto JFK) e Orly Sud (Vicariot e Prouvé, 1961). Sempre più grossi, questi megaoggetti, questi superterritori, si sono progressivamente costituiti in enclave fisiche, tecniche ed istituzionali. Ma questa enclave non è impermeabile. All'ora dell'emergere di una "società in rete", che precipita la mondializzazione degli scambi e la megalopolizzazione dell'ambiente urbano [START_REF] Castells | La société en réseaux[END_REF] , gli aeroporti instaurano legami molto stretti con la metropoli, trasformandola oltre la cerchia strettamente aeroportuale.

In quest'ambito, la scala dello sviluppo aeroportuale mostra una nuova muta-zione. La recente frenesia che conosce la costruzione aeroportuale procede da un forte aumento del traffico aereo e da un'esplosione del fenomeno metropolitano. Osaka, Hong Kong, Sciangai, Kuala Lampur, Seul, Bangkok, Pechino…, questi aeroporti giganteschi, tutti realizzati senza soluzione di continuità, sono insieme architetture, città e territori. In un testo recente, l'architetto britannico Norman Foster, ideatore dell'aeroporto Chep Lap Kok di Hong Kong, suggeriva di 'reinventare' l'aeroporto: «A Hong Kong […], è il sito stesso che deve essere creato. Ma, ben lungi da essere un ostacolo per lo sviluppo, ciò agisce invece come un catalizzatore per il progetto delle più vaste costruzioni dei tempo moderni [START_REF] Kong | the site itself has to be created. But far from being an obstacle to development, it became instead the catalyst for the largest construction project of modern times[END_REF] » Questa dichiarazione riassume un certo numero delle caratteristiche nuove che gli aeroporti esplorano da più di un decennio.

A Hong Kong, l'aeroporto è intrinsecamente legato all'arcipelago metropolitano. Kai Tak, il vecchio aeroporto che era situato nel cuore di Kowloon, raffigurava già una centralità dove l'atterraggio assumeva aspetti da fantascienza. Impiantato a 30 chilometri dal Central Business District, sull'isola eponima di Chep Lap Kok, il nuovo insieme si trova accanto all'isola di Lantau, una delle più belle riserve naturali della regione. Questo ambiente non gli ha impedito dare l'avvio ad un nuovo sviluppo della metropoli. Linee ferroviarie, rete metropolitana, vie di scorrimento veloce, tunnel sottomarini, opere d'ingegneria civile, il programma d'infrastrutture realizzato in occasione della sua apertura è stato gigantesco. Ma non è tutto, l'aeroporto periferico ha anche suscitato il rinnovamento dell'ipercentro, attraverso la creazione di nuovi polder, e la realizzazione di un air terminal metropolitano che è oggi uno degli epicentri della città, e che fa parte di un vasto complesso urbano, l'International Finance Center, che accoglie una stazione di registrazione dei bagagli e dei passeggeri, l'interconnessione con diverse linee di metropolitana, un immenso centro commerciale di lusso, due torri di uffici (tra cui la più alta dell'isola), due alberghi, un auditorium, uno spazio di passeggiata sulle banchine, il tutto aggregato in un blocco architettonico unico, le cui dimensioni erano fino ad ora sconosciute sull'isola. Città nuove sono anche state create sul percorso del cordone ombelicale che collega l'aeroporto all'isola di Hong Kong. Il sito stesso ha accolto un gran centro di esposizioni chiamato AsiaWorldExpo. Ed ormai, la rete d'infrastrutture che serve la piattaforma pone il sito come una delle centralità principali della regione del Delta del Fiume delle Perle, futura Megalopolis della Cina del Sud [START_REF] Koolhaas R | Pearl River Delta, Harvard Project on the city" in Mutations, Harvard project on the city, ACTAR[END_REF] . Concepita come precursore dello sviluppo metropolitano, l'infrastruttura ha iniziato una metamorfosi della geografia naturale ed urbana dell'arcipelago. L'aeroporto raffigura un oggetto generatore che infiltra, rende ibrida e rimodella la metropoli in tutte le sue parti, talvolta anche nella sua interezza, formando una metastruttura. [Fig 7]

Confusione delle grandezze?

Delle «porte simboliche» della città, come ama chiamarle l'architetto, che vede nelle realizzazioni asiatiche le nuove terre del futuro urbano: «Come Londra contempla la nostalgia del suo passato e funziona su una struttura fisica ampiamente ereditata dall'età del cavallo e delle carrozze, -molto prima dell'apparizione dell'automobile -Hong Kong, che è ora a meno di quattro ore di volo dalla metà della popolazione mondiale, elabora attualmente un strategia di progetti volti alla realtà dell'espansione globale e ai flussi di scambio sempre più importanti tra i popoli [START_REF]As London contemplates the nostalgia of its past and trades on a physical infrastructure largely inherited from the age of the horse and cart[END_REF] ." Su queste «isole», l'aeroporto offre un modello che coniuga insieme iper-concentrazione e decentramento. La polarizzazione delle reti intermodali -aereo, treno ad alta velocità, treno rapido, automobile -l'integrazione crescente di funzioni commerciali e d'affari, la massificazione dei trasporti, sono in effetti dei segni espliciti di una iper-concentrazione, di cui lo Hub è una delle manifestazioni. Nello stesso tempo, l'ipermobilità favorita da questa corsa all'ubiquità, conferisce all'aeroporto una relativa autonomia. Rapidamente accessibile, può delocalizzarsi.

Questi molteplici dialoghi che l'aeroporto instaura con il suo ambiente urbano agiscono a loro volta sulla trasformazione dei vari componenti che formano questa struttura. Da un lato, di fronte ai discorsi sul carattere extra-urbano dell'aeroporto, vengono avviati dei tentativi di «civilizzazione» per riaddomesticare questi spazi in seno ai quali l'ipermodernità sfida il genius loci. L'appropriazione di segni identitari, lo spiegamento di attività urbane (commerci, alberghi,…), lo sviluppo di eventi festivi (sfilate, esposizioni, riprese di film…) e la creazione di architetture emblematiche ne sono testimoni. D'altra parte, l'immagine veicolata dall'aeroporto, di una novità e di un'efficacia perpetue, esercita un'influenza oltre i suoi limiti, conducendo talvolta a fenomeni di «aeroportuarizzazione» della città.

Architetto di diversi aeroporti, l'americano Terry Farrell difende l'idea secondo la quale il collegamento di grandi aeroporti mediante sistemi di trasporto rapidi, permette ai terminali decentrati di diventare edifici di tipo urbano e di perdere poco a poco il «loro status di città a parte». Realizzando l'altro air terminal di centro città a Kowloon -prima zona abitata dell'arcipelago di Hong Kong -, l'architetto aspira ad «urbanizzare l'aeroporto [START_REF] Powell | La ville de demain[END_REF] .» Il progetto dell'air terminal consiste nel creare il nucleo di un «Super-Kowloon», come Farrell lo chiama: 1 milione di m2 costruiti su terreni recuperati al mare, une serie di grattacieli che sfidano la skyline dell'isola di Victoria, che gli sta di fronte. Nell'air terminal la vita urbana entra in contatto con l'animazione dei viaggi internazionali. La pianta dell'air terminal, con i suoi diversi livelli e volumi collegati gli uni agli altri, detta la pianta della città situata al di sopra come sovrastruttura.

Questi due versanti dell'«aeroportuarizzazione» della città e dell'urbanizza- zione dell'aeroporto introducono una confusione, riducendo la distinzione che si poteva stabilire dall'una all'altro e attestando di un processo complesso d'ibridazione. Questi segni urbani importati nell'aeroporto procedono finalmente dalla città come reale o da un'immagine liscia e «civilizzata» che si desidera darne? Tutto ciò potrebbe non essere altro che illusione? In questo caso, una disillusione è da prevedersi, come lo illustrano d'altronde i cambiamenti permanenti che osserviamo nel mondo senza limiti degli aeroporti. Si può scommettere che i nomi attribuiti ai vari siti e luoghi dell'aeroporto saranno presto obsoleti, che i vari segni urbani dovranno cedere il posto ad altri. È questa la condizione stessa del loro emergere.

La storicità del futuro

Per concludere, vogliamo sottolineare due punti desunti in questa ricerca, che ci sembrano essere sintomatici di questa famiglia di 'eventi' urbani. Un primo punto riguarda le dimensioni localizzate di queste realizzazioni ed il modo in cui, malgrado le aspirazioni globali ed universali che esse rappresentano, esse riescono ad incarnarsi localmente in forme specifiche. Certo, questo desiderio permanente di realizzazione dell'ideale urbano che sembra marcare la costruzione delle infrastrutture del cielo, metamorfosando l'aeroporto in scena urbana e, come si osserva oggi ad Hong Kong, re-investendo la città come scena aeroportuale, interpella le nozioni generiche di megastruttura, di elasticità, di obsolescenza, prefigura gli artifici urbani. Ma se essi presentano caratteri similari, le loro forme sono differenti, perché non solo questi spazi di mediazione sono il risultato di una geografia particolare, ma procedono dal loro legame intrinseco con la loro città d'approdo. Se i programmi e le intenzioni pongono questi oggetti sulla scala globale delle città iper-moderne, si osserva che sono anche captati dai poteri locali per catalizzare e rifondere la metropoli in movimento.

Questa condizione sincronica va di pari passo con una dimensione diacronica, intrinsecamente legata al ruolo del futuro come parametro del progetto. Progettando in vivo finzioni urbane, l'aeroporto materializza uno specchio della città in divenire. Questo carattere intrinseco ci conduce al secondo punto della nostra conclusione. La narrazione, la riforma, l'emblema, il mondo in sé, la vetrina, il prototipo, la lezione: le figure intorno alle quali si dispiega l'immaginario aeroportuale, mostrano come questi luoghi fuori dalle mura possono essere compresi come dispositivi, rinviandoci ad ogni tappa della loro costruzione culturale, un'immagine condensata ed amplificata del soggetto urbano. Come Giano, questo specchio rivela sempre la sua faccia meno liscia e più cupa. Già osservata nel 1962 da Reyner Banham [START_REF] Banham | The obsolescent airport[END_REF] , l'obsolescenza aeroportuale è qui tanto più esacerbata che questi luoghi sono stati il supporto privilegiato dei progressi tecnologici più compiuti e delle visioni futuriste più estrapolate. Questo carattere intrinseco di futuro anteriore è costitutivo dell'aeroporto come oggetto storico.

Anticipando la storia, l'aeroporto vi è entrato. Ricompensa di un secolo d'in-novazioni, figura come uno dei «patrimoni del futuro». L'introduzione di questa dimensione solleva questioni ardue, suscettibili di rinnovare a loro volta questioni urbane. Cosa vale in effetti il termine di patrimonio per dei luoghi, degli edifici, i cui concetti si erano precisamente definiti rispetto al futuro e, a priori, al di fuori di una storia urbana come noi abbiamo l'abitudine di rappresentarcela ? Questo problema è spesso oggetto di aspre contese, che oppongono i gestori dell'aeroporto, rivolti verso un futuro della tabula rasa, ed i preservazionisti, difensori delle tracce di una storia del futuro [START_REF]Sul problema dell'avvenire del terminale TWA dell'aeroporto Kennedy, progettato da Eero Saarinen[END_REF] .

Attivo o riconvertito, in città o fuori le mura, l'aeroporto prosegue il suo destino di emblema urbano, e s'iscrive nell'orbita dei nuovi programmi urbani formando sempre una delle maglie indispensabili alla loro dimensione metropolitana. Oltre che all'evento, è alle condizioni che lo rendono possibile che ci siamo interessati, a questa metainfrastruttura nuova che permette il suo avvento e la sua realizzazione, così come a questo fascio di attese e di promesse che la città ha in gestazione e che l'evento cristallizza come mediatore. Ciò che impregna durevolmente il territorio è presente altrettanto se non più negli impulsi di queste molle esterne o invisibili che sotto le luci della ribalta di un effimero show urbano.

FIG. 1 .

 1 FIG. 1. ALBERT SPEER ARCHITETTO: VISTA AEREA VERSO SUD DEL PROGETTO DELL'ASSE DI BERLINO, CON LA LOCALIZ-ZAZIONE DELL'AEREOPORTO DI TEMPELHOF, A SINISTRA. FONTE: LEON KRIER (1985), ED., ALBERT SPEER, ARCHITECTURE, 1932-1942, BRUSSELS: ARCHIVES D'ARCHITECTURE MODERNE, P. 47.

  . Pubblicato nel 1936, il «Rapporto generale della commissione dei trasporti aerei» su «la scelta di un porto aereo intercontinentale nella regione di Parigi», si orienta verso la soluzione presentata di un porto misto a Trappes-Saint Quentin, adducendo che «l'arrivo in aereo sopra la regione di Versailles non manca di maestà e le vie d'accesso a Parigi sono seducenti 10 » [Fig 5]

  FIG 3. NEW YORK WORLD FAIR 1939, VISTA PROSPETTICA DEL SITO CON IL FUTURO LAGUARDIA AIRPORT A DESTRA. FONTE: COLUMBIA UNIVERSITY, NEW YORK.

  4. FIORELLO LA GUARDIA, SINDACO DI NEW YORK, INAUGURA CON ROBERT MOSES L'AEROPORTO A NORTH BEACH IN QUEENS, 15 OTTOBRE, 1939. FONTE: THOMAS KESSNER (1989), FIORELLO H. LA GUARDIA AND THE MAKING OF MOD-ERN NEW YORK, MCGRAW-HILL PUBLISHING COMPANY, P. 364.

FIG. 5 .

 5 FIG. 5. URBAIN CASSAN, "LE PORT AÉRIEN INTERCONTINENTAL DE PARIS", PROGETTO PER L'AEROPORTO DI TRAPPES, AS SUD-OVEST DI PARIGI, 1931. FONTE: ARCHIVES OF MUSÉE DE L'AIR ET DE L'ESPACE, LE BOURGET.

FIG. 6 .

 6 FIG. 6. LE BOURGET TERMINAL BUILDING, 1937, VISTA AEREA NEL GIORNO DELL'INAUGURAZIONE, 12 NOVEMBRE 1937. FONTE: "AÉROPORTS" (1937), TRANSPORTS EN COMMUN, EDITIONS ALBERT MORANCÉ, P. 77.

FIG. 7 .

 7 FIG. 7. HONG KONG, CHEP LAP KOK ISLAND, LAVORI DI COSTRUZIONE DEL NUOVO AEREOPORTO, ULTIMATO NEL 1998. FONTE: HONG KONG GOVERNMENT.

FIG. 2. IL SITO DELL'AEROPORTO DI TEMPELHOF DI BERLINO, NEL 1968, ARCHITETTO ERNST SAGEBIEL, 1937. FONTE: LANDESBILDSTELLE, BERLINO.

FIG. 8. HONG KONG, VICTORIA ISLAND, CENTRAL AIRPORT EXPRESS STATION E INTERNATIONAL FINANCE CENTER,

FOTOGRAFIA DI N.ROSEAU.


Applying Model-Based Techniques for Aerospace Projects in Accordance with DO-178C

INTRODUCTION

The main difference between the new standard for software development in civil aviation, DO-178C (see [START_REF]C "Software Considerations in Airborne Systems and Equipment Certification[END_REF]), and its predecessor, DO-178B, is that the new one has standard supplements that provide a greater scope for using new software development methods. The most important standard supplements are DO-331 (see [START_REF]Model-Based Development and Verification Supplement to DO-178C and DO-278A[END_REF]) on model-based development and model-based verification and DO-333 (see [START_REF]Formal Methods Supplement to DO-178C and DO-278A[END_REF]) on the use of formal methods, such as model checking and abstract interpretation. These key software design techniques offer enormous potential for making software development in the aerospace sector highly efficient. At the same time, they not only maintain the high quality and observe the safety requirements for software, but actually improve them. These methods are seamlessly integrated in the development scheme of DO-178C, which is shown in a simplified form in Figure 1.

OVERVIEW OF THE MODEL-BASED TOOL CHAIN FOR DO-178C, DO-331, AND DO-333

This article describes how to use a model-based tool chain including Simulink ® /Stateflow ® ( [START_REF]MATLAB/Simulink/Stateflow[END_REF]), dSPACE TargetLink ® ([5]), and tools by BTC Embedded Systems ( [START_REF]BTC EmbeddedValidator[END_REF]) to develop software right up to DO-178C Level A by using the standard supplements DO-331 and DO-333, see [START_REF]TargetLink -Model-Based Development and Verification of Airborne Software[END_REF].

The main components of the tool chain are:  Simulink/TargetLink for the graphical, model-based development environment  BTC EmbeddedSpecifier (optional) for formalizing requirements  TargetLink for automatic production code generation  BTC EmbeddedTester and BTC EmbeddedValidator for meeting different verification and testing objectives

The above tools cover the following essential steps in the software development process in accordance with DO-178C/DO-331, see Figure 2:

 Specifying high-level requirements in the form of Simulink/TargetLink models, which then constitute specification models according to DO-331  High-level requirements in the form of specification models can also be developed by using EmbeddedSpecifier, which is particularly attractive for converting existing textual requirements to formal requirements  Representing low-level requirements in the form of Simulink/TargetLink models, which thereby constitute design models according to DO-331  Automatically generating source code with TargetLink in order to convert the Simulink/TargetLink design models directly to high-quality ANSI C code  Achieving various verification objectives of DO-331 via model-based testing with BTC EmbeddedTester and BTC EmbeddedValidator to efficiently create requirements-based test cases, automatically execute them in the Simulink/TargetLink environment, and determine coverage metrics such as MC/DC at the code level and model coverage to determine requirements coverage.  Using BTC EmbeddedValidator for model checking as a formal method in the sense of DO-333 to demonstrate that the models comply with formalized requirements developed using BTC EmbeddedSpecifier.

MODELS AS A DOOR-OPENER FOR EFFICIENT SOFTWARE DEVELOPMENT

A key milestone for efficient and high-quality software development is representing requirements and specifications by models according to DO-331. A transition from purely textual to formalized requirements in the form of models opens up a wealth of possibilities for automated analysis, source code generation and verification, as will be demonstrated in this article.

Software requirements in DO-178C exist in two different forms, either as • High-level requirements (HLR) Simply put, they describe what the software is supposed to do but not how it should do it ("black box" view of the software). HLRs are derived from requirements for the entire system or subsystem, which are set up in the system process, e.g., as described in ARP 4754.

• Low-level requirements (LLR) They describe the inner workings of the software, i.e., how the software is supposed to implement the HLRs ("white box" view of the software) and they must comply with the HLRs. It must be possible to translate LLRs directly into source code, which is later translated into the executable object code.

Models in the sense of DO-331 can now be used to represent requirements on these two levels (models for software architecture, e.g., in the form of UML models, are not discussed here but are widely used in practice and also covered by DO-331). In the case of HLRs, DO-331 speaks of specification models, whereas models for representing LLRs are referred to as design models.

Specification Models for High-Level Requirements

For some functional HLRs, it is best to use dedicated tools, such as BTC EmbeddedSpecifier, that support specific formalized patterns for expressing requirements. This is particularly the case when requirements are not written as a set of mathematical equations or "pseudo code" but come in the form of rather simple signal dependencies and conditions. BTC EmbeddedSpecifier is specifically geared towards requirements of such a form. Therefore, a very generic requirements design pattern in the form of a state machine is used which includes trigger conditions for the requirement as well as actions (see Figure 3). Timing dependencies can be expressed in the requirements design pattern as well. The tool is particularly helpful for the step-by-step transformation of informal textual requirements to formalized patterns in an intuitive process. For this purpose, informal signal names are replaced by actual interfaces in Simulink/TargetLink models and the meaning of the text is translated into the requirements pattern. The tool thereby simplifies the transition from informal to formal requirements with a clearly defined syntax and semantics, which lets users later use verification methods like model checking and automatic test case generation. Moreover, due to the formal nature of the requirements pattern, there is a precise definition for "requirements coverage" to identify whether developed test cases have covered all requirements. HLRs can also be expressed by block diagrams and state diagrams in the form of Simulink/TargetLink models (see Figure 4). This is particularly useful if such models are already available from the system process. TargetLink automatically makes sure that only a "safe subset" of Simulink and Stateflow is used during the design process to avoid problems with certain modeling constructs. Moreover, compliance with company-specific standards for specification models can be verified by using automatic style checkers.

Design Models for Low-Level Requirements

By nature, representing low-level requirements (LLRs) in the form of Simulink/TargetLink models is particularly popular, as source code can be generated from them automatically in subsequent steps (Figure 5). Such design models not only describe the actual functionality but also the necessary details of the software, such as internal data structures, distribution across different functions, control flow information, and, in some cases, fixed-point representations.

GENERATING SOURCE CODE FROM DESIGN MODELS

Design models representing low-level requirements offer a direct route to creating the source codeby using automatic code generation instead of manual coding. Automatic code generators, such as TargetLink, that transform Simulink/TargetLink models directly into ANSI C code are far superior in terms of quality and reliability compared to human programmers. The source code they produce  Is generated deterministically  Is very readable and suitable for review. This is ensured by extensive source code commenting, easily understandable symbol names and the use of a proper subset of the C programming language.  Can be traced back directly to the individual parts of the design model from which the code was generated.  Contains references to the requirements of the design model. This increases requirement traceability, which represents an important part of any software development process.  Is highly configurable in terms of how to generate code, e.g., to meet company-specific coding guidelines and to integrate easily with the interfaces of the software architecture, library functions and legacy code.  Is approximately as efficient as handwritten code. Individual optimizations on a detailed level let users specify the extent to which the code will be optimized, ranging from completely unoptimized to fully optimized code.

In addition to generating the actual source code, the code generator can generates other items, thereby assuring consistency between all the artifacts. Typical examples include:

 Additional documentation files adjusted specifically to special purposes  Files with traceability information in order to support reviews and analysis of the source code  Information on the requirements implemented by the source code to build a requirements traceability matrix Using TargetLink for automatic production code generation from Simulink/Stateflow models has been widely used for many years, especially in the automotive sector, but also in DO-178B Level A projects (see [START_REF] Aloui | C Code Reaches New Heights at Nord-Micro[END_REF]).

INNOVATIVE TECHNIQUES FOR VERIFICATION

The great advantages of using models to specify requirements (HLRs and LLRs) are evident not only in automatic production code generation but also in other areas, such as verification. Particularly important activities are:

1. Verifying that models for HLRs and LLRs accurately implement the requirements from which they were developed 2. Verifying that models and source code comply with specific modeling guidelines and coding guidelines 3. Verifying that the source code exactly implements the requirements contained in the design model

Verifying that the executable object code implements HLRs and LLRs

The model-based approach combined with the formalization of the requirements in this case provides very powerful mechanisms to facilitate the verification steps, as will be shown in the following subsections.

Verifying Requirement-Model Compliance

A combination of model simulation, coverage analysis, and test case generation is especially well-suited for verifying the compliance between the requirements and the models that implement them. DO-178B and DO-178C state that test cases have to be created solely on the basis of requirements whose definitions directly include the required result. If a requirement is itself expressed as a model, e.g., a Simulink/TargetLink model, techniques for automatic test case generation, such as those provided by BTC EmbeddedTester, can be used to automatically generate test cases from the specification model (see [START_REF] Holberg | Significant Quality and Performance Gains through Fully Automated Backto-Back Testing[END_REF]). If high-level requirements were expressed formally in BTC EmbeddedSpecifier, then automatic test case generation can also be used for those. Naturally, test cases can also be developed manually or semi-automatically based on the requirements. To check the compliance of a model against the requirements from which it was developed, the previously generated or developed test cases/stimulus values are executed with the model by means of model simulation. The Simulink/TargetLink/BTC environment makes it easy to run the model simulations and check the simulation results against the previously developed test cases. Moreover, model coverage analysis is used to investigate whether the various model elements are all covered completely (Figure 6) in order to identify undesired functionality in the model. Although the simulation capabilities of models help verify the compliance between requirements and models, the traditional execution of even a high number of test cases is always incomplete in a certain sense. If a proof is desired or all requirements are to be verified simultaneously during all simulation runs, different verification methods can be used as long as the requirements were specified formally in BTC EmbeddedSpecifier. By using the model checking functionality of BTC EmbeddedValidator, users can prove or disprove compliance between the formally specified requirements and the design model. In particular, the model checking engine of EmbeddedValidator is fully capable of handling not just boolean and integer data types but also floating-point design models. Model checking is one of the techniques considered in the formal methods supplement DO-333 of DO-178C. Providing a proof of correctness is of course very appealing, but the usual limitations of model checking need to be considered, like a potential explosion of the state space with increasing complexity of the design model. If a model checking approach is not feasible, formal requirements specifications can nonetheless be very helpful to generate requirement observers, which verify all requirements simultaneously during all simulation runs.

Compliance of Models and Code with Modeling and Coding Standards

In order to check whether models comply with their respective modeling standards, style checkers such as MXAM from Model Engineering Solutions (see [START_REF]Model Examiner[END_REF]) or the Simulink Model Advisor are typically used. These tools support automatic guideline checking in order to simplify review activities on the different models. The compliance of the generated source code with coding guidelines is usually verified by using static source code analysis tools that are available on the market.

Compliance of Source Code with Design Models

In order to check that the automatically generated source correctly implements the design models from which code was generated, developers can use reviews and analyses, which is also facilitated by TargetLink. In order to simplify code reviews, traceability information as well as hyperlinks between design model elements and the respective generated source code lines are provided. In addition, further analyses can be fully or partially automated.

Compliance of Executable Object Code with High-Level and Low-Level Requirements

A typical way to verify that the executable object code implements HLRs and LLRs according to Figure 1 is to execute it on the target platform. TargetLink provides powerful mechanisms for this in the form of processorin-the-loop simulation, in which the automatically generated code is translated directly by the target compiler and executed on an evaluation board with the target processor (Figure 7). Testing is performed in the Simulink/TargetLink environment and can be directly compared with the results of a model simulation (modelin-the-loop simulation). This test design lets users reuse all test cases that were developed manually or generated automatically. BTC EmbeddedTester provides a powerful environment for performing the required tests, including the automatic comparison of model simulation and processor-in-the-loop simulation. The associated test reports are created completely automatically. BTC EmbeddedTester also supports code coverage analysis (MC/DC coverage, condition coverage, etc.), see Figure 6.

TOOL QUALIFICATION ASPECTS, LIMITATIONS AND EFFECTIVENESS OF THE TOOL CHAIN

The proposed tool chain is based on the Simulink/Stateflow modeling environment and TargetLink for automatic source code generation. But a code generator as powerful as TargetLink is very hard to qualify as a criteria 1 tool according to DO-330 (see [START_REF]Software Tool Qualification Considerations" Supplement to DO-178C and DO-278A[END_REF]), the Software Tool Qualification Considerations supplement to DO-178C. Therefore, the idea is to use an unqualified code generator and instead perform verification steps as required by DO-178C/DO-331. However, the verification steps greatly benefit especially from the use of verification tools provided by BTC, be it for the source code or the object code. This means that tools like EmbeddedTester (criteria 3 tool) and the model checking engine in EmbeddedValidator (criteria 2 tool) would have to be qualified to claim certification credits for the application of the tools.

Regarding the application of the tool chain, the following primary aspects and limitations should be considered:

 Since the whole tool chain makes extensive use of Simulink/Stateflow, its application is primarily attractive where this environment seems most appropriate judged by the nature of the algorithms and the software that is to be developed. Where algorithms are best described by block diagrams and state diagrams, the tool chain can boost efficiency.  Another limitation lies of course in the optional application of model checking to verify the compliance between models and the requirements from which the models were developed. The larger the model and the more complicated the requirement, the less likely it is that a model checking engine will be able to provide a proof in time.

It should be noted that production code generators not constitute a weakness in the tool chain. On the contrary, a modern production code generator like TargetLink produces code much more reliably and with much higher quality than a human programmer could. In summary, the tools provide powerful mechanisms not only for requirements definition and design, but especially for the various verification steps, making it possible to meet the objectives of DO-178C quite easily and with less effort than by using conventional techniques.

Figure 1 :

 1 Figure 1: Important design and verification activities according to DO-178C (architecture design and verification have been omitted).

Figure 2 :

 2 Figure 2: Model-based design tool chain for DO-178C/DO-331-compliant development.

Figure 3 :

 3 Figure 3: Converting informal textual requirements into formalized requirements.

Figure 4 :

 4 Figure 4: Simulink/TargetLink specification models for representing high-level software requirements.

Figure 5 :

 5 Figure 5: Design models in Simulink/TargetLink represent low-level requirements.

Figure 6 :

 6 Figure 6: Model coverage and code coverage reports.

Figure 7 :

 7 Figure 7: Model simulation and tests in different simulation modes.


P Dissaux

B Hall

Merging and Processing Heterogeneous Models

Introduction

Model Driven Engineering is now recognized as a way to significantly improve the development process of industrial systems and software. This approach leads to the production of various kinds of models associated to each modelling and verification step of the life cycle. All these concrete models may differ in their abstract definition (meta-model) and in their syntactic expression. Such diversity cannot be easily avoided as each modelling language brings its own specific benefit or is fundamentally associated with a particular tool or technique. However, merging and processing heterogeneous models to support all the required development activities can become a real engineering issue in the context of industrial projects.

This paper presents a solution to this problem. The proposed approach is based on the LMP [START_REF]Model Verification: Return of Experience[END_REF] (Logic Model Processing) technology to provide a unique, standardized and easy to process representation of each model that is involved in a given project. Using this solution leads to the realization of a global homogeneous repository from syntactical conversion of each input model, without altering their semantic diversity. It then dramatically facilitates the development of model processing tools, such as model explorations, model verifications, model transformations and architectural reasoning.

The model jungle

Model roles

Models can be used at the various stages of the system development life-cycle. In the descending branch of the life-cycle, we can easily find for a single project at least requirements models, design models and a set of models associated with early verification techniques. If we make the assumption that each individual model is well defined in the context of its own purpose, the key issue is then to ensure a proper inter-operability between these various steps of the life-cycle. This implies that we can manage various kinds of model dependencies, such as traceability (e.g. between design model entities and requirement model entities), transformation (e.g. between a design model and a verification model) and consistency (e.g. between the various subsets of a design model)

Model syntax

Models can be defined with different meta-modelling languages or approaches, including BNF, XML DTDs or schemas, MOF or ECore. This choice has of course an impact on the way the concrete models can be handled in a tool or a tool-chain. Most of the time, the internal representation of a model in memory is tool dependent. On the contrary, the result of a file serialization must comply with a standard representation which depends on the corresponding meta-model syntax. For instance, BNF leads to token based human readable models, XML DTD or schema leads to XML tag based models and MOF or ECore leads to XMI tag based models. In a given project, these three kinds of concrete model syntax may have to collaborate within a same tool chain.

Model correctness

Each modelling language carries semantic concepts that are defined more or less formally by the various layers of the language definition. For token based languages, syntax compliancy brings a first level of correctness that must usually be completed by the verification of additional legality rules. With other modelling languages, more rigorous structural rules, such as relation cardinalities, can be guaranteed by construct. However, the actual correctness of a model depends on its foreseen usage, and two models described with the same modelling language may have different contents according to their applicative domain. For instance, the model of a real-time system may look correct in the scope of the verification of its static architecture but not correct in terms of its timing behaviour. Another source of discrepancy may come from the compliancy with the corporate or project engineering rules. For instance the way to build a system in SysML [START_REF]SysML: Systems Modeling Language[END_REF] may significantly vary between the various users or tool vendors.

Model inter-operability

All these differences may be fully justified but can become a blocking issue for the definition of complete tool-chains or for system wide model integration. Several approaches may be considered to solve these model inter-operability issues. The first natural solution is to express all the models with the same meta-modelling language and implement all the tools within the same framework. The typical example of this solution is the use of the Eclipse platform as it has been done with the Topcased and Polarsys[3] initiatives. Such an "all-in-one" approach does minimize the inter-operability problem but raises a certain number of other issues like a lack of modularity and an increase of the effort required to include specialized legacy models and tools. Another solution consists in offering a standardized communication layer by the mean of a logical bus that can be used to ensure model transformations and tool interaction in a transparent way. An example of this solution is ModelBus[4] which allows for heterogeneous tools interaction, but is dedicated to ECore based models. The alternate approach that we are describing below does not have these restrictions. This approach is called Logic Model Processing (LMP).

Logic Model Processing

LMP is based on the use of the Prolog[5] language to formally specify rules to be applied to an appropriate representation of the applicative model. This representation of the model is composed of Prolog facts. Prolog (Programmation Logique) is a declarative language that is used to express rules applying on predicates. Rules can then be combined using Boolean Logic. Prolog syntax is very simple and most programs can be specified using AND, OR and NOT logical operators.

LMP consists of a methodology, a set of tools and prolog libraries.

Model Driven Engineering activities are supported by LMP as follows:

-The meta-model classes define prolog fact specifications whose parameters names correspond to the attributes names of the classes.

-An instantiated model consists in a populated prolog facts base, where facts parameters values correspond to classes attributes values.

-The model processing program is expressed as a set of prolog rules whose predicates are others rules or facts.

-To execute a LMP program, it is necessary to produce the facts base associated with the model to be processed, to merge it with the rules base associated with the processing to be performed and to run a query with the prolog interpreter.

With the prolog language being an ISO standard, any prolog environment can be used to support the LMP approach. The one that has been used until now is sbprolog [START_REF]Stony Brook Prolog[END_REF]. Other environments such as SWI-Prolog [START_REF]SWI-Prolog[END_REF] are also being considered. One of the particularities of sbprolog is that the facts and rules bases can be described in textual form or in a binary form (byte code). Sbprolog binary files can be concatenated which highly facilitates the realization of modular processing features and the merge of input models.

In addition to the prolog interpreter itself and its runtime environment, a set of additional tools and reusable libraries are also part of the LMP tool-box. These include in particular input model parsers and output model un-parsers (or printers). The currently available parsers are for XML/XMI models (xmlrev), AADL[8] models (aadlrev), and programming languages. Facts base generation can also be implemented for memory stored models handled by modeling tools.

The main benefits brought by the LMP approach are: -A clear separation between the model to be processed (facts base) and the model processing program (rules base).

-A strong traceability between model processing requirements and their implementation (one rule per requirement).

-The declarative and logical programming style offered by the prolog language.

-The ability to define modular set of processing rules and to link them together at run time.

-The ability to use a same implementation language for all kinds of model processing, i.e. navigation within the model language constructs (query language), verification of model properties (constraint language), model to model, model to text and text to model transformations (transformation language).

Current LMP Applications

Stood

LMP principles have been applied in their early phase in the Stood[9] design tool. It has been used in this context for more than twenty years to implement various features such as static rules checkers, code and documentation generators as well as reverse engineering tools.

One of the most significant successes of the use of the LMP technology within the Stood tool has been the qualification of customized model verification by Airbus in support of the DO 178 certification process.

AADL Inspector

After the positive experience of the use of the LMP approach for increasing the capabilities of the Stood tool, it was decided to apply it in an extensive way for the development of the AADL Inspector[10] framework.

AADL Inspector is a model processing environment that can parse AADL models and connect them to a variety of verification and generation tools, such as Cheddar [11] for scheduling analysis, Marzhin [START_REF] Dissaux | The SMART Project: Multi-Agent Scheduling Simulation of Real-time Architectures[END_REF] for event based simulation and Ocarina[13] for source code generation. AADL Inspector can also be used to convert SysML or UML-MARTE [START_REF]MARTE: Modeling and Analysis of Real-Time and Embedded Systems[END_REF] models into a corresponding AADL specification to take advantage of the existing connections with the processing tools.

AADL Inspector can thus be seen as a generic model processing framework using AADL as pivot language and LMP as transformation technique.

The TASTE tool-chain

The TASTE[15] tool-set resulted from spin-off studies of the ASSERT project, which started in 2004 with the objective to propose innovative and pragmatic solutions to develop real-time software. One of the primary targets was satellite flight software, but it appeared quickly that their characteristics were shared among various embedded systems.

The solutions that have been developed now comprise a process and several tools. The development process is based on the idea that realtime, embedded systems are heterogeneous by nature and that a unique UML-like language was helping neither their construction, nor their validation. Rather than inventing yet another "ultimate" language, TASTE makes the link between existing and mature technologies such as Simulink, SDL, ASN.1, C, Ada, and generates complete, homogeneous software-based systems that one can straightforwardly download and execute on a physical target.

Within the TASTE tool-chain, LMP is used to insure a link between the Domain Specific Models (Interface View and Deployment View) and the corresponding AADL specification that is used during the model processing phases (real-time analysis and code generation).

The PMM editors

The Property Model Methodology [START_REF]Model Based System Engineering[END_REF] is a system engineering approach that involves several interconnected models: the Specification Model, the Property Based Requirements, four kinds of Design Models and the overall System Model.

A graphical editor is being developed to support this modelling approach and the use of LMP is foreseen to insure the various required model processing needs in this context.

Using LMP to process heterogeneous models

The examples of use of the LMP technology that have been presented in the previous section are all confined in the scope of a particular tool or toolchain: processing HOOD [START_REF] Hood | Hierarchical Object Oriented Design[END_REF] models in Stood, processing AADL models in AADL Inspector and in TASTE.

However, one of the most interesting benefits of this approach is that it can easily be generalized to address the models-interoperability issue that has been expressed in section 1 of this paper. In this section, we explain how LMP can be used to convert, merge and process heterogeneous models.

Converting heterogeneous models

The role of model parsing in the LMP context consists of performing a syntactic transformation from the original model stored in memory or serialized in a file into a normalized prolog facts base.

In the case of text based input models, the conversion are insured by a parser which output consists of a list of prolog predicates.

In the case of memory based input models, which are for instance produced by a graphical tool, the prolog predicates must be generated with a dedicated printing or serialization feature.

When the sbprolog environment is used, LMP provides a C library for the production of binary predicates. This library can be linked to the model parsers or editors.

Merging heterogeneous models

The conversion step that is described in the previous paragraph can be applied to all the input models, whatever meta-model they comply with and whatever they are serialized in a file or stored in memory.

The portable way of merging converted models is to concatenate the elementary textual prolog facts bases that have been produced by each conversion tool. I can be noted that additional information can be inserted at that stage under the direct form of dedicated prolog facts. This may be especially useful to introduce processing instructions (pragmas) into the merged facts base.

The main constraint that applies at this stage is the management of facts redundancy and ordering. A good practice to avoid issues is to ensure that each conversion tool produces a different set of predicates. When this is not possible, the variation of the number of parameters (arity) can be used to avoid facts overwriting. Another solution consists of using a dedicated parameter to identify the model source.

In the case of sbprolog, it is not required to take care of the way textual facts are ordered. With other prolog environments it may be mandatory to group all the similar facts together. Moreover, sbprolog binary facts files can be also concatenated.

At this stage, the resulting facts base is a homogeneous data repository representing the merged heterogeneous input models that is ready for any kind of processing.

Processing heterogeneous models

Most of what has been explained for the input models facts base can also be applied to the model processing rules bases. The main difference is that the rules bases are usually statically defined and stored in a model processing library, whereas the facts bases are dynamically elaborated from the current state of the applicative model. Another difference comes from the facts/rules separation that has strictly been applied until now for all the LMP realizations. However, some future applications may require that rules are also specified within the input model. This may be the case for instance while adding model constraints insertions during the modelling phases.

All the variety of processing can now be applied to the merged facts base, such as static rules checkers, dedicated model generators to feed verification tools and source code generators.

Example of use

This section presents a practical example of use of the approach. This case study has been simplified as much as possible for illustrative purpose. We are addressing what could be the development process for a library of operations on complex numbers.

We consider a development workflow that would be composed of four separate steps. Each step is associated with an ISO 12207 standard activity and is likely to use different description languages and tools:

-step1: System Requirements Analysis (5.3.2). -step2: Software Requirements Analysis (5.3.4). -step3: Software Architectural Design (5.3.5).

-step4: Software Coding and Testing (5.3.7).

System requirements analysis

The table below gives a small subset of possible requirements for the realisation of a mathematical library on complex numbers.

Id

Name Text 1 R_ComplexLib

The complex number library must define the complex number type and operations on complex numbers. The two operands and the return value of the add operation must be complex numbers. 5 R_ComplexSub

The two operands and the return value of the sub operation must be complex numbers.

When done with a requirements analysis tool, such as IBM Doors or SysML compliant editors, a requirements model can be serialised in various formats. For the purpose of the example, we have selected the Requirements Interchange Format (ReqIF), as it is an OMG standard. A small fragment of the corresponding file is given below:

<SPEC-OBJECTS> <SPEC-OBJECT LONG-NAME="R_ComplexLib" ... <SPEC-OBJECT LONG-NAME="R_ComplexType" ... <SPEC-OBJECT LONG-NAME="R_ComplexAttributes" <SPEC-OBJECT LONG-NAME="R_ComplexAdd" ... <SPEC-OBJECT LONG-NAME="R_ComplexSub" ... </SPEC-OBJECTS> Applying the appropriate LMP parser (xmlrev) to this file provides the corresponding list of prolog facts: isXMLTag('#39','SPEC-OBJECTS','#13','39'). isXMLTag('#40','SPEC-OBJECT','#39','40'). isXMLAttribute('#40','SPEC-OBJECT', 'LONG-NAME','R_ComplexLib','40'). ... The fact type isXMLTag/4 keeps track of the XML tags hierarchy whereas isXMLAttribute/5 provides the name and value of each attribute for each XML tag. This low level description may be hard to use during the next steps. We can thus improve the access to relevant information by introducing a first level of processing that defines a new set of predicates of type isSpecObject/1: getSpecObjects :-isXMLTag(X,'SPEC-OBJECTS',_,_), isXMLTag(Y,'SPEC-OBJECT',X,_), isXMLAttribute(Y,_,'LONG-NAME',R,_), assert(isSpecObject(R)).

This rule creates a new list of facts that hides the syntactic complexity of the original XML structure and filters the needed data for further use, such as performing requirements traceability.

isSpecObject('R_ComplexLib'). isSpecObject('R_ComplexType'). isSpecObject('R_ComplexAttributes'). isSpecObject('R_ComplexAdd'). isSpecObject('R_ComplexSub').

Software requirements analysis

We assume that the next modelling step consists in formalizing the data type requirements thanks to a UML class diagram, as shown below: We can then use the same LMP parser as in the previous step to convert this UML model into an equivalent list of prolog facts. isXMLTag('uml#3','uml:Model','#2','3'). isXMLAttribute('#3','uml:Model', 'xmi:type','uml:Model','3'). isXMLTag('#5','packagedElement','#3','5'). isXMLAttribute('#5','packagedElement', 'xmi:type','uml:Class','5'). isXMLAttribute('#5','packagedElement', 'name','Complex','5'). isXMLTag('#6','ownedAttribute','#5','6'). isXMLAttribute('#6','ownedAttribute', 'xmi:type','uml:Property','6'). isXMLAttribute('#6','ownedAttribute', 'name','Re','6'). ... The XMI serialisation generated by UML tools may be huge even for a small model. To pre-select the useful information for a given processing purpose, we can create a more specialised facts base from the original one by specifying a filtering rule: getUmlClasses :-isXMLTag(X,'uml:Model',_,_), isXMLTag(Y,'packagedElement',X,_), isXMLAttribute(Y,_,'xmi:type','uml:Class',_), isXMLAttribute(Y,_,'name',C,_), assert(isUmlClass(C)), isXMLTag(Z,'ownedAttribute',Y,_), isXMLAttribute(Z,_,'xmi:type', 'uml:Property',_), isXMLAttribute(Z,_,'name',P,_), assert(isUmlProperty(C,P)).

The new facts base would then looks like the following, and could be easily enriched to contain other details such as attribute types or requirement satisfy abstractions.

isUmlClass('Complex'). isUmlProperty('Complex','Re'). isUmlProperty('Complex','Im').

Software architectural design

We are now considering the software architecture and express the library as an AADL package, so that it can be used by the other parts of the application. Although the AADL standard has a graphical notation, its main usage is with the textual notation that is human readable and scalable. In order to be able to process an AADL specification with LMP, we need to use the AADL parser (aadlrev). The result of the parsing is the facts base that is shown below:

For the same reason as for AADL, there is no need to create a new facts base to select the useful information.

All together

Although they are coming from different modelling languages, the syntactic transformation into prolog predicates allows for global processing of the merged model.

The facts sub-bases can be concatenated to provide all the required data to perform cross-activity processing. In particular, this can be used to verify the consistency of the workflow, such as requirements coverage or code compatibility with the architecture.

All these verification rules can be expressed in standard prolog language, as shown in the two simple examples given below.

Rule1. the data types specified in the software specification must be defined in the software architecture: checkR1 :-isUmlClass(T), /*UML*/ not(isComponentType(_,_,T,'DATA',_,_)),/*AADL*/ write('Error R1 for: '), write(T).

Rule2: the data types specified in the software architecture must be defined in the source code: Similar rules could be defined to check that all the system requirements are properly covered by design entities.

After having shown how LMP could ease static processing of merged heterogeneous models, we will now consider dynamic architectural reasoning.

Architectural Reasoning Using LMP

The prolog fact-based representation of the LMP form presents a good foundation for the logical reasoning and processing of the architectural models. In the next sections we present some simple examples to illustrate the flexibility of the LMP approach.

5.1.Physical Separation and Independence Analysis

To illustrate this potential, we present a simple LMPbased extension to illustrate how physical zonal independence can be assessed from the LMP model.

In modern aircraft, there is often a need to ensure that the independence assumed within a fault-tree is sufficient to mitigate the potential of physical damage that may arise from adverse system events such as fire, or explosions. Many manufactures require a minimum physical separation among redundant elements. In Integrated Modular Avionic (IMA) architectures, assuring that this separation is achieved for all of the hosted functions can be nontrivial, as multiple sub-function elements are distributed across the IMA processing and input/output hardware elements. As architectures become increasing networked and distributed, the complexity of such analysis may only increase, hence the ability to address it systematically is attractive.

Figure 2 : Example Wheel Brake System

To illustrate the technique we present the wheel brake system case study, shown in Figure 2. This system comprises two independent hydraulic circuits that are each controlled by a dual lane command /monitor computation system. For each circuit, the command processor modulates the expected pressure to achieve the required braking force; the monitor processor supervises the commanded braking operation, monitoring commanded output pressure sensor feedback. If the monitored pressure is not in agreement with the monitor's expected limits, the monitor closes the isolation valve and removes all hydraulic pressure, rendering the channel in active. It then yields control to the other channel.

For brevity of the presentation, our example analysis focuses on the placement of the command and monitoring processing hardware of each lane.

To introduce the physical location components onto the model a new AADL property is defined. In our simple example, we utilize a single point, but in practice this may be a series of points, which represent the physical boundaries of the components. Inherently extensible, via property sets adding such notions to an AADL model is very straightforward.

property set Location is Location: list of record ( x_pos : aadlreal; y_pos :aadlreal; z_pos : aadlreal; ) applies to ( processor, system, abstract, device ); end Location;

To represent both good and bad configurations, two system implementations are defined, by extending the base implementation. In the first configuration the command and monitor components within each lane are placed to be adjacent, and the computation elements of the Alt and Norm lanes are separated by 10 meters, as illustrated below. In the second configuration the monitor of the Alt channel is swapped with the monitor of the Norm channel. It should be noted that, this configuration is insufficient with respect to the required physical channel separation, since failure of a single physical zone will destroy critical components of both lanes of redundancy. Hence, it is our intention is to illustrate this using model analysis.

The AADL composite error model, records the assumptions of the structure of the redundancy, hence the first stage of analysis is to convert this into LMP form. This is done using the ADDL parser (aadlrev) that has been extended under this work to capture the structure of the Error Annex logical expressions. The LMP representation for the above model comprises two facts; isEMV2CompositeStateElem is used to store failure conditions, and isEMV2CompositeStateExpr facts are then used to map the logical relationships of the elements. Two example facts are shown below.

isEMV2CompositeStateExpr('wbs','wbs_com_mon_dual _lane','impl','unnamed_A1','unnamed_K1','$1','pu mpGreen.Failed','OR','isolNorm.Failed',235). isEMV2CompositeStateElem('wbs','wbs_com_mon_dual _lane','impl','unnamed_A1','unnamed_K1','$2','bc vNorm.Failed','NIL',235).

In a similar manner to other LMP parsers, element and expression identifies and indexes '$1' are maintained to support the mapping and relating of the facts. Once in LMP form, the next stage of the physical separation, is to convert the logical structure of the fault-tree into a form that can be executed with prolog, This conversion comprises a simple mapping. Each expression is converted to a dynamic prolog fact as illustrated below.

init :dynamic('pumpGreen.Failed'/0), dynamic('isolNorm.Failed'/0), dynamic('bcvNorm.Failed'/0), dynamic('monNorm.Failed'/0), dynamic('comNorm.Failed'/0), dynamic('pumpBlue.Failed'/0), dynamic('isolAlt.Failed'/0), dynamic('bcvAlt.Failed'/0), dynamic('monAlt.Failed'/0), dynamic('comAlt.Failed'/0), dynamic('pedalLeft.Failed'/0), dynamic('PedalRight.Failed'/0), dynamic('brake.Failed'/0).

The init predicate introduces all of the potential faults as dynamic facts in the prolog database. It is complimented by a clear, predicate (not shown) that retracts all facts related to failures. Clear is then used to establish a clean baseline for iterative analysis and queries. This is also useful to support working in the interactive prolog shell, when manually exploring failure combinations.

The isEMV2CompositeStateExpr are similarly reduced and mapped to a simplified executable form as illustrated below. The local facts are then grouped by component using a ftacomponent predicate as shown below, that simply maps the component name and X,Y,Z location.

ftacomponent(P,T,I,Name,X,Y,Z) :-isRecordField(P,T,I,Name,'LOCATION::LOCATION', 1,'x_pos',XA,_), isRecordField(P,T,I,Name,'LOCATION::LOCATION', 1,'y_pos',YA,_), isRecordField(P,T,I,Name,'LOCATION::LOCATION', 1,'z_pos',ZA,_), atom_number(XA,X), atom_number(YA,Y), atom_number(ZA,Z).

The system then examines all instances of the ftacomponent and generates zones of collocated component using the a simple separation auxiliary predicate, that returns true if the two components are located within a defined separation limit (Distance), which in our case was 6 meters. As illustrated below the code to build_zones is relatively terse comprising only a few lines of code. This is one of the attractions of the declarative nature of the prolog processing.

advanced predicate may check that protocols that are bound to the bus utilize a suitable end-to-end data transport protocol to mitigate the expected error-rate. More elaborate queries, such as Byzantine vulnerability analysis, are also possible, by highlighting all instances where forked data paths of the logical model, have terminals that bind to different physical components.

Related Work

The fault-tree representation used by our illustrative case-study was inspired from the original work of Shuchi [START_REF]Construction of a fault tree using prolog[END_REF].

In the area of architecture model processing, several alternate solutions have been explored, such as REAL [START_REF] Rubini | Modeling and verification of memory architectures with AADL and REAL[END_REF], RESOLUTE [START_REF]Resolute: an assurance case language for architecture models[END_REF] and AGREE [START_REF]Compositional verification of architectural models[END_REF]. The definition of a "constraint annex" is also under discussion by the AADL standardisation committee.

On-going and Future Work

LMP is used for the development of the new processing plug-ins that will be integrated in the future distributions of the AADL Inspector tool. The current work is focused on extending the import capabilities for UML profiles models such as MARTE, SysML, SCADE System, or CAPELLA as well as new processing features, especially for safety analysis.

In order to facilitate the connection with Domain Specific Modelling Languages, an automatic generation of most the prolog rules that are required to parse, navigate and process ECore based models is being developed. A similar approach is also envisaged for XSD definitions.

Following the idea that LMP allows a tool agnostic infrastructure to be developed, integration with solutions like Modelbus is also considered.

Another area of active research is the generation/ derivation of the AADL Error-Annex composite model annotations from a case-based reasoning approach of the known component failure modes in conjunction with architectural topology.

Conclusion

This paper introduces the raising issue of heterogeneous models processing and proposes an original solution to address it. This solution merges the principles of logic programming and those of model driven engineering to define the Logic Model Processing (LMP) approach.

This approach and the supporting tools are described in the paper and several examples are provided to illustrate its benefits.

Figure 1 :

 1 Figure 1 : a UML class This UML class diagram can be serialized in standard XMI format. A little fragment of the resulting .uml file is given below:

  ,_,T,'DATA',_,_), /*AADL*/ not(typeSpec(_,T,_)), /*Ada*/ write('Error R2 for: '), write(T).

  separation((X1,Y1,Z1),(X2,Y2,Z2),Distance):-Xd = X2 -X1, Yd = Y2 -Y1, Zd = Z2 -Z1, D is sqrt((Xd * Xd) + (Yd * Yd) + (Zd * Zd)), D < Distance.

Due to the token based nature of the AADL syntax as opposed to the XML/XMI based languages, the resulting facts base is much more compact and directly usable without having to define a new set of more precise predicates.

Coding

For the last step of our development process, we will process an implementation of the library in Ada language. A possible realisation in source code could be: We can then use another parser of the LMP toolbox (adarev) to build a facts base from the Ada code. Once the zones are complete, we simply instantiate a zonal related failure set for each zone, but adding zone predicates to the output. The zone predicates for the good and bad wheel brake command monitor configurations are shown below. To explore the system, it is only necessary to instantiate each of the generated zonal fault-sets with the fault tree expression logic discussed previously, and querying the state of the top-level hazard, in out case exp15. To package such analysis in smaller form large LMP database, a stand-alone file 'ftap.pro' is generated by the LMP processing logic.

This can then be loaded into the interactive SWI-Prolog environment. A trace from an interactive session following the loading of the file is shown below for the good component placement example.

- Evaluating exp15 following the single zone failure zone_good_impl0 concludes false, indicating that the failure of zone_good_impl0 is not sufficient to cause the top-level event. However, the subsequent additional failure of zone_good_impl1 does cause the top-level event, and the subsequent query of exp15.

Repeating the procedure with the bad configuration, we see that failures of the single zone are sufficient to cause the failure of the top-level event as illustrated in the trace below.

? Note, that in our toy example, we are using a simplified representation of location. In real deployments our single point may be expanded to present the component boundary points. Similarly, other types of queries such as the use of a common CPU type, cooling zone, and or power-supply distribution etc., are easily implemented given AADL's extensible property provisions. In each case basic analysis technique would remain largely unchanged, only requiring adaption of the build_zones criteria.

Modelling Completeness Checks.

A second application of the LMP processing is the implementation of automated model completion and completeness checking. In large systems the level of detail and abstraction within the model needs to be managed and maintained. Organizations often maintain modelling standards that define the required model content. However, enforcing such standards can be cumbersome without the appropriate automation.

However, if the model is expressed in LMP, the automation of consistence and compliance checks becomes very simple. Given that, all aspects of the architecture are represented by facts, simple queries against the fact bases can be generated for each requirement. For example, as shown below, only a few lines of code are necessary to execute the query to check that all processing hardware components have a consistent error model associated with them.

isComponentType(P,_,X,'PROCESSOR',_,_), not(isAnnex(P,X,_,_,'EMV2',_,_)), writeErrorMessage(P,X).

By examining the architectural model, using additional system composition predicates and/or predicates derived from fault-tolerance theory predicates, the architectural correctness may be simply validated. For example, a simple predicate may check that all bus components have a specified error model, e.g. Bit Error Rate (BER). A more