ISI - Ingegneria Sismica Italiana

La ISI è un'associazione tra imprese impegnate nell'ingegneria antisismica che vede tra i suoi soci Alga, Mapei e anche le softwarehouse più impegnate in questo settore: AMV, Harpaceas, CSP fea. Ed ora anche Softing è socio sostenitore dell'associazione.

La nostra adesione, già da tempo in programma, è stata determinata da Luciano Migliorini di AMV. Questo lo diciamo perché ci fa piacere cogliere l'occasione per ringraziare di questo un vecchio amico.

La AMV è l'unica software storica con la quale Softing abbia avuto sempre rapporti diremmo di amicizia, anche oltre il rispetto reciproco. Quello che più manca nel nostro settore infatti è la collaborazione per la salvaguardia di interessi comuni.

Una malintesa interpretazione di "concorrenza" ha sempre fatto sì che non vi fosse una visibilità della categoria, tesa invece a screditare gli altri per accreditare se stessi e in tal modo screditando tutti. Ciò ha danneggiato moltissimo non favorendo la visibilità della nostra categoria, come si vede chiaramente dall'emanazione delle norme che avviene nella assoluta ignoranza della realtà delle softwarehouse italiane.

Siamo convinti che un po' di collaborazione sarebbe salvifica per il nostro settore e anche utile per i nostri utenti in quanto la libera circolazione delle idee migliorerebbe i prodotti che ora invece si contendono il mercato abbassando i prezzi ed i livelli qualitativi.

Purtroppo mancano anche riferimenti culturali per cui è come se nel settore della viticultura si spingesse il gusto del consumatore verso sapori edulcorati e adulterati perché la produzione di tali vini sarebbe più conveniente per il produttore. Ciò per il vino non avviene, perché il consumatore è preparato e perché vi sono associazioni di categoria.

In un settore vitale come il software per l'ingegneria antisismica la deregulation è micidiale. E, intendiamoci, lungi da noi invocare una regulation di Stato! ma una seria associazione di categoria è indispensabile e siamo certi che ISI abbia tutte le carte in regola,

http://www.ingegneriasismicaitaliana.com

Anatomia del SI-ERC

Poiché i nostri clienti calabresi hanno ovvie difficoltà con il SI-ERC, ne abbiamo approfondito gli aspetti informatici rimanendo piuttosto sconcertati.

Innanzitutto ci aspettavamo fosse stato definito uno standard informatico dei dati, per capirci analogo a quello per il catasto. Questo perché la standardizzazione è una esigenza fondamentale dell'automazione e il problema della comunicazione telematica con la pubblica amministrazione è un problema tecnico, non solo amministrativo.

Poi siamo sconcertati dal fatto che l'iniziativa sia regionale. Come dicevamo, trattandosi di un problema di comunicazione telematica, e non solo di una formalizzazione priva di supporto tecnico come quella cartacea, uno standard nazionale è indispensabile. Non si può pensare che tra qualche tempo si abbia a che fare con 20 "standard" regionali diversi.

Un approccio simile a quello già impiegato dal catasto avrebbe potuto favorire dei sistemi di acquisizione dei dati in modo "locale" con controllo locale per inviare poi le informazioni in modo automatico ed unitario alla pubblica amministrazione.

Ci troviamo invece di fronte ad un'immissione di dati frammentaria tramite finestre di dialogo da riempire stando ad un computer collegato in rete con il timore di perdere tutti i dati, con una diagnostica stressante e soprattutto senza la possibilità che le software house producano in automatico un file di formato standard che il progettista possa poi inviare alla pubblica amministrazione.

E' chiaro dallo studio del sistema SI-ERC e del suo sviluppo che l'improvvida immissione di dati tramite dialoghi sia stata in un secondo momento, per chiara macchinosità, "rappezzata" con la possibilità di inserire dai tramite dei file in formato Excel, ma dialogo per dialogo e ciò evidentemente per non dover riprogettare l'intero sistema. Niente di più facile sbagliare a caricare uno egli innumerevoli filetti eventualmente predisposti dal progettista precedentemente.

Singolare anche il fatto che si costringa il progettista ad usare un programma commerciale prodotto da Microsoft per comunicare con una pubblica amministrazione.

Inoltre anacronisticamente il SI-ERC pretende .xls e per di più nella versione Office 97 quando perfino Microsoft ha dovuto riconoscere la necessità di utilizzare formati più aperti, ed ha sostituito dal 2007 il formato proprietario .xls con .xlsx, altrimenti noto come Office Open XML. Tale formato è tra l'altro divenuto uno standard ISO nel 2008.

Ovvio che l'uso di un formato obsoleto, e per di più binario, complica la vita a chi volesse automatizzare la procedura costringendolo a seguire con i suo lavoro l'obsolescenza del SI-ERC:

Purtroppo un circolo "vizioso", generato dalle lungaggini della entrata in vigore delle nuova normativa antisismica, ha fatto sì che la qualità dell'automazione del progetto sia sfuggita al controllo che vi era prima, per una tradizione ventennale di esperienza bruscamente recisa, e si è dequalificato il software per progettazione strutturale a livelli tali che oggi è impensabile che la software house non debba interamente prendersi l'onere di questi nuovi adempimenti inefficienti. Pare che la illogicità di certi adempimenti sia proprio occultata dal software privato che vi pone rimedio per cui il progettista non è più pienamente cosciente delle operazioni incongrue che gli sono richieste. Sarebbe interessante se per un impensabile accordo, le software house che si occupano di progettazione strutturale incrociassero le braccia. La pubblica amministrazione - non il progettista! - che farebbe? Lo capiscono che senza il nostro tramite, delle software house che operano in questo economicamente marginale settore, i loro farraginosi pensamenti e le loro assurde procedure si fermerebbero? Credo di no.

Naturalmente per i nostri clienti calabresi, oppressi da questa sciagura, stiamo già facendo qualcosa, ma chi fa software è un professionista. Ora immaginate un dentista che usa gli strumenti più innovativi per alleviare le sofferenze dei suoi pazienti e poi arriva una legge fatta da chi di odontoiatria non sa nulla e conosce solo il trapano a cinghia e gli IMPONE per legge di usare quel trapano.

Ecco: per chi fa software avere a che fare con il SI-ERC è esattamente come se, potendo usare un trapano ad ultrasuoni, fosse costretto ad usare un vecchio trapano a pedale. Lo faremo ma... turandoci il naso.

Arch. Roberto Spagnuolo, Amministratore Unico, Softing Srl

Arch. Amedeo Farello, Responsabile Sviluppo Software, Softing Srl

Mattonelle ovunque

Negli ultimi mesi ho seguito, per ovvi motivi professionali, l'evolversi nel nuovo sistema operativo di casa Microsoft, Windows 8, il cui rilascio ufficiale sembra previsto per la fine di quest'anno.
La sua principale novità è costituita dalla nuova interfaccia "Metro", direttamente derivata da quella utilizzata da Windows Phone 7, il sistema proposto da Microsoft per i dispositivi 'mobili' (smartphone e tablet) in alternativa a Apple iOS e Google Android, con le sue ubiquitarie "tiles" (mattonelle).

Microsoft sembra voler spingere Metro con decisione, tant'è che il nuovo 'MarketPlace' per le applicazioni Windows, creato in risposta al successo degli App Store e Mac App Store di Apple,  accetterà soltanto applicazioni che supportino tale interfaccia.

Metro prevede che le applicazioni girino in sostanza sempre a tutto schermo, cosa che può essere perfino necessaria su un dispositivo con un display di ridotte dimensioni, ma che risulta abbastanza assurda su un monitor da 27 pollici. Inoltre il passaggio da un'applicazione all'altra, specialmente non utilizzando le dita su uno schermo sensibile al tocco ma un mouse, è piuttosto macchinoso.

Per non essere tacciato di partigianeria, aggiungo che Apple sta affrontando le stesse problematiche, nell'apparente tentativo di far convergere verso un unico prodotto iOS e [Mac] OS X. Direi con risultati non maggiormente apprezzabili: l'applicazione Mission Control introdotta con Lion, che presenta una griglia con le icone di tutte le applicazioni installate sulla macchina, esattamente come farebbe un iPhone, è, su un computer da tavolo e senza uno schermo "touch", semplicemente priva di qualunque utilità pratica.

Confesso, sia da sviluppatore che da utente, che questa convergenza a tutti i costi mi preoccupa. Riportare l'interfaccia utente ad una singola applicazione alla volta in luogo dei sistemi multifinestra a cui siamo ormai abituati da molti anni non mi sembra un progresso, anzi. E se è vero che è perfettamente possibile disabilitare Metro e ritrovarsi di fatto con Windows 7, mi domando quale possa essere l'incentivo ad effettuare un upgrade.

Arch. Amedeo Farello, Responsabile Sviluppo Software, Softing Srl

Analisi sintetica dei criteri progettuali di Softing - II Parte

Nòlian All In One

La normativa oggi è "procedurale". Cioè, se ad esempio si impone un coefficiente riduttivo dello spettro di risposta, si assume implicitamente che la struttura sia eseguita con criteri tali da possedere la duttilità richiesta. In pratica, la validità della fase di analisi trova la sua conferma nella fase di progetto, un modo di procedere forse paradossale, senz'altro potenzialmente rischioso.
Non tutti si sono accorti del fatto che non si possano più gestire in modo indipendente le fasi di analisi e di progetto delle membrature, essendo (bene o male) frutto di un processo unico.

Questa asserzione metodologica sarebbe, inoltre, più condivisibile, se la nostra normativa non costringesse ad adempimenti quasi "formali" che poco si conciliano, come si è detto nel post precedente, con i metodi informatici tipici dell'analisi computazionale.

Questo legame stretto tra fasi progettuali ci ha costretto ad una operazione che avevamo voluto sempre evitare, perché in una informatica sana il "divide et impera" è un atteggiamento progettuale tipico. L'operazione è stata quella di unificare in un unico programma tutte le fasi del progetto e cioè di fondere l'analisi con il progetto delle membrature.

Oltre a ciò, ci si è posta l'esigenza di automatizzare al massimo il "processo" progettuale inteso come una serie di fasi logicamente tra loro connesse.

Molti altri programmi per l'ingegneria strutturale hanno adottato un approccio procedurale fin dall'inizio della loro storia, ottenendo tuttavia applicativi "rigidi". Una procedura è, infatti, applicabile solo in un contesto molto ben definito. Per cui, di norma, il mercato offre programmi dedicati al progetto delle sole strutture edili e solo se concepite in modo tipico.

Noi sappiamo bene che, invece, uno studio d'ingegneria non si confronta solo con problemi tipici ma con modifiche in corso d'opera, tali da giustificare, contestazioni, contenziosi e anche opere atipiche, tutti casi in cui un programma "procedurale", dedicato ad una specifica tipologia strutturale, è di scarso aiuto.

Per non incorrere in tali limitazioni, il nostro sistema esperto Quilian sovrappone il suo controllo sulle operazioni eseguite dalle varie componenti logiche solo se e quando lo si desidera. Il percorso "obbligato" in Quilian diventa un "pilota automatico", che può essere inserito o disinserito all'occorrenza.
Questo approccio coniuga l'esigenza di analisi sofisticate e di un uso articolato, con le esigenze di produttività, e porta ad uno dei programmi più sofisticati e flessibili finora realizzati. Un sistema per analisi lineari, dinamiche e non lineari che ha tutte le caratteristiche dei migliori programmi esteri ma che convive strettamente con le funzioni di post processo, che in Italia, per i fatti prima detti, risultano fondamentali.

Con orgoglio e convinzione, possiamo quindi affermare che, Nòlian All In One è un programma unico e assolutamente innovativo nella concezione del modo di affrontare il progetto strutturale automatizzato.

Si può condividere o meno la nostra filosofia, ma essa ha il pregio di essere progettualmente congruente e non frutto di compromessi. Riteniamo che in ingegneria questo sia un preciso dovere.

Arch. Roberto Spagnuolo, Amministratore Unico, Softing Srl
Arch. Amedeo Farello, Responsabile Sviluppo Software, Softing Srl

Analisi sintetica dei criteri progettuali di Softing - I Parte

Perché questa nota

Nella scelta di uno strumento software per il progetto di strutture, più che un elenco di specifiche o la risposta alla consueta domanda "ma lo fa questo?", contano i criteri con cui esso viene sviluppato, perché ci consentono di valutarne più  concretamente la rispondenza alle nostre esigenze professionali.

Perciò, in occasione del rilascio di Nòlian All In One, desideriamo condividere qualche  osservazione sui criteri progettuali che applichiamo nel realizzare il nostro software.

La nostra filosofia

L'analisi e la progettazione di strutture civili su elaboratore, impiegano oggi metodi derivati esclusivamente da ricerche di alto profilo condotte nei settori dell'ingegneria meccanica ed aerospaziale. Alludiamo agli algoritmi per la soluzione rapida di sistemi di equazioni, all'estrazione degli autovalori, alla formulazione a fibre per sofisticate analisi non lineari e, ovviamente, allo stesso metodo degli elementi finiti.

Il nostro ruolo, quale produttori di software, è di rendere tali metodi disponibili al pubblico, dotandoli di una interfaccia utente concepita in modo da agevolarne il più possibile l'uso per il professionista, che non è tenuto a conoscerne in dettaglio le specifiche peculiarità ma vuole concentrare, giustamente, la sua attenzione sugli aspetti progettuali.

Il problema è trovare un giusto compromesso tra l'occultamento di certe complessità non essenziali, ed il rispetto dell'impostazione scientifica dei metodi, senza alterarne le potenzialità o ridurre la qualità dei risultati ottenuti. Non è un compromesso facile da trovare.

Softing ha sempre perseguito il mantenimento dell'integrità originale delle formulazioni rigorose dei metodi. Ciò, mentre aumenta la qualità intrinseca dei suoi prodotti, può farne diminuire l'appetibilità commerciale.

Esiste anche un altro problema: molti adempimenti, richiesti soprattutto dalla recente normativa, non sembrano pensati in modo da armonizzarsi con un approccio "informatizzato" all'ingegneria, che pure è oggi di fatto imprescindibile, bensì sembrano formulati in APERTO CONTRASTO con esso, vanificando spesso gli eccezionali risultati raggiunti da questa disciplina e a volte impedendone l'impiego. Si attua una sorta di "snaturamento" della meccanica computazionale per calarla nello stretto contenitore dell'ingegneria "pratica".

Poiché in Italia la norma ha valore di legge, si verifica uno scontro tra metodi di carattere scientifico, con tutte le loro specifiche peculiarità di impiego, e l'esigenza di una "verità inconfutabile" tipica di un sistema normativo. Si tratta di una contraddizione di base che appare insolubile.

In assenza di un'attività di ricerca ufficiale sull'argomento, che fornisca risposte consolidate e validate dall'esperienza comune, il produttore di software si trova costretto a "mediare", esercitando un'attività che non gli è propria, per colmare vistose lacune.

Nel rispetto dei metodi della meccanica computazionale, che sono gli unici a fornire garanzie di scientificità, Softing ha sempre cercato di evitare, finché possibile, di impiegare soluzioni semplificate o troppo particolari, che qualcuno ha definito efficacemente "fare con il calcolatore i calcoli come si fanno a mano".
La pretesa di automatizzare i metodi semplificati usati per i calcoli "a mano" è infatti molto pericolosa, perché tali semplificazioni sono state pensate per essere applicate con "buon senso", caratteristica di cui l'elaboratore è purtroppo del tutto sprovvisto.

Arch. Roberto Spagnuolo, Amministratore Unico, Softing Srl
Arch. Amedeo Farello, Responsabile Sviluppo Software, Softing Srl