Post hoc, ergo propter hoc ( ...dopo di questo, quindi a causa di questo )
Simmetrie. Un elemento della logica che utilizziamo spontaneamente quando analizziamo un qualsiasi soggetto è la simmetria.
Se A = B allora B = A.
Questa relazione di logica simmetrica, che proviene dalla proprietà commutativa, è molto meno ovvia di quello che si pensa e spesso viene utilizzata quando cerchiamo di risolvere i nostri problemi. Gli Hacker, ad esempio, la utilizzano sempre quando “lavorano” facendo il reverse engineering del software che vogliono crakkare. Se a questa relazione aggiungo il termine tempo trasformo il sistema da statico come nell’esempio precedente in dinamico.
- dX/dt = F(X,t)
La relazione diventa la conseguenza temporale fra due stati o ancora meglio diventa la più nota legge del karma di causa effetto.
Banalizzo perché non so fare altro: se sono fuori dalla stanza e vedo l’interruttore della luce su on deduco che dentro la stanza la luce sarà accesa. Se è vero questo allora è anche vero che se sono dentro la stanza e vedo la luce spenta deduco che fuori il pulsante è già nello stato off.
Questo posso farlo perché ho creato una relazione commutativa fra lo stato dell’interruttore e lo stato della lampadina.
Inconsciamente cerchiamo sempre questo tipo di simmetrie, in tutte le cose che facciamo. Pensiamo che la simmetria sia una forma naturale delle cose e che la natura sia sempre amichevolmente ordinata. Nella realtà purtroppo la natura non è ordinata ed oltre ad essere caotica è pure ostile perché per lei tutto tende al disordine. Gli elementi che consideriamo immutabili, irridendoci tendono inesorabilmente a cambiare nella forma o nei contenuti, costringendoci a precipitosi ravvedimenti che rimettono in discussione tutto quello che avevamo considerato vero sino a quel momento. La locuzione latina è l'ultima dimostrazione.
Post hoc, ergo propter hoc ( ...dopo di questo, quindi a causa di questo )
Questo sofisma è un errore particolarmente attraente perché la conseguenza temporale sembra inerire al rapporto causale. L'errore è di concludere solamente in base all'ordine degli avvenimenti piuttosto che tener conto di altri fattori che possono escludere la relazione. I luoghi comuni, le credenze, le superstizioni e il pensiero magico sono il risultato di questo errore. ( Wikipedia )
Cammino lungo il marciapiede che costeggia l’azienda dove lavoro. Ha smesso di piovere da poco, e l’asfalto dopo una giornata di sole emana uno strano odore, quando è bagnato. Incrocio le ragazze del call center, hanno sempre la testa bassa, occhiali scuri, passo veloce per evitare brutti incontri. Non si sa mai.
Pensavo che però, non è bello vivere con in testa sempre un non si sa mai...
Sento un colpo di clacson è J.Black.
“Vuoi uno strappo ?”
“No grazie... a proposito come va con l’elicottero ?”
L’elicottero era un vero veicolo volante, commissionato direttamente dagli Stati uniti. La Nato aveva avviato una commessa per questi progetti militari alternativi.
“guarda lascia stare.. Lo conosci Merlini quello associato con la Stam ?”
“Merlini certo che lo conosco quello che lavora per la Marina e la Stam è la ditta della NATO”
“Bravo.. ci ha rifilato il pacco in pratica ha chiuso la commessa.. e ha pensato bene di non pagarci..”
“stai scherzando...”
“Non scherzo.. io tanto tanto mi sono salvato, il problema è Alcor che è fuori di 500000 euro”
“Non ci credo, c’era anche Alcor dentro ?”
“E certo... poi però la Stam lo ha chiamato ci deve essere stato un accordo e così si è fatto assumere..”
“e be... insomma con famiglia e figli... è comprensibile”
“eee ho capito però la ditta l’ha mandata in malora... Poi oramai noi siamo diventati degli Highlander … sulla piazza siamo rimasti io e te...”
“Meglio no ? Così facciamo cartello …”
“eee lascia stare … vabbuo ci sentiamo stammi bene fratello”
“Ciao JBlack...”
Metto la mano nella tasca e tiro fuori il cellulare per guardare l’ora, faccio così da quando ho smesso di portare l’orologio.... Sono le 8:31 e così adesso sono sicuro di essere in ritardo. Devo andare in azienda, perché sopra la scrivania ho l’sms che mi aspetta.
288C11DB070906052D2A00DB07090572F9000000000000003039303630353244324130 3044423037303930353732463930303030303030303030303030300000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000
Mi faccio una copia, che stampo e la posiziono sul PC, di lato, come se fosse il primo identikit del killer. E passo così tutto il giorno, a fare deduzioni sul codice scritto, cercando di trovare un bug che potesse creare l’errore.
Accesi la luce, erano le quattro del pomeriggio. Scandii tutto il codice per verificare se c’erano altri indizi significativi, ma non trovai nulla. Mi alzai e sentii scricchiolare la schiena, già da un po' che ero in quella posizione. Guardai la scrivania che aveva un aspetto davvero sconsolante.
Da una parte, si erano accumulate schede di produzione varie, con cover aperti e nastri carta con sopra scritto “cip fallato” o altri fantasmagorici messaggi, che gli installatori mettevano per identificare il guasto. La colpa poi era in parte anche un po' la mia, perché sono stato io a protestare, chiedendo di segnalare il problema per favorire la ricerca guasti. Adesso avevo gli assiemi dove gli installatori, vi scrivevano volutamente delle vere poesie d’arte contemporanea del tipo “non va quando si accende” oppure, i più legittimi “non risponde” oppure, quelli tecnici tipo “led spento. Batteria scarica” .
Dall’altra parte della scrivania, avevo stampato una nota tecnica per un problema avuto la settimana precedente. Avevo documentato con tanto di grafico la misura della corrente di Leakage dell’ingresso AD di un Bruz perché questa falsava la misura analogica del trasduttore che utilizzavamo in un altro apparato (che noia).
Le correnti di leakage sono correnti che scorrono sulla giunzione del silicio che idealmente sono isolate. Su un ingresso digitale treestate sono ininfluenti, invece in un ingresso AD bisogna ricordarsi che le tarature servono proprio a risolvere questi problemi...
Poi sotto la tastiera ho un paio di fotocopie ( ma solo due altrimenti mi sballonzola la tastiera ) della Cypress e del loro micro il Psoc.
La Cypress ha sviluppato un microcontrollore che è un po’ il frontend dei micro. Il suo nome e Psoc. In pratica al processore hanno aggiunto una specie di gatearray riprogrammabile per implementare le interfacce hardware dedicate. Hanno sviluppato 3 serie di controllori:
- Psoc 1 4 MIPS
- Psoc 3 33 MIPS
- Psoc 5 84 MIPS
Le prime due sono a 8 bit l’ultima è un 32 bit Cortex based. Ma il bello viene quando consideriamo le interfacce hardware. Il sistema prevede un un tool grafico in grado di modificare l’hardware del micro un po' come se fosse un gatearray. I pin diventano così ingressi o uscite general purpouse a cui noi possiamo associare il blocchetto hardware più idoneo. Una SPI(Serial_Peripheral_Interface_Bus) un Sigma_Delta, un filtro rf e così via. La modularità alle volte torna utile per alcune problemi nella progettazione del pcb. L’idea è buona ma ho l’impressione che il mercato non risponda anche perché poi alla fine il sistema ipermodulare diventa un ulteriore peso sulla progettazione e in particolare al povero firmwarista, non fosse altro che comunque dovrà passare il tempo a spiegare che le cappelle si riescono a fare anche con questo sistema di sviluppo....
Guardo più in là e vedo un po’ di resistenze di Shunt per la misura della catodica sbruciacchiate. Anche questa era una una storia di qualche anno fa, perché solo dopo un po' di tempo capimmo che erano state sottodimensionate. Infatti si è scoperto che, queste periferiche, venivano montate nei metandotti che passano sotto gli attraversamenti ferroviari. Il treno che arriva si può considerare come se fosse un gigantesco conduttore su cui passa una tensione di qualche migliaio di volt ( alimentazione presa appunto con il Pantografo sulla linea volante ). Questo conduttore che varia nel tempo è proprio sopra un altro gigantesco conduttore che è il metanodotto. ( e molti di voi sanno cosa succede quando abbiamo due conduttori contigui e ad uno facciamo passare della corrente... )
Ma riprendiamo la nostra storia. Mi riprendo il foglio e lo poso davanti alla tastiiera, così analizzo il messaggio e lo scompongo in byte o meglio dire in ottetti ( che fa tanto francese..). Perché questi sono il dato dell’sms.
28-8C-11-DB-07-09-06-05-2D-2A-00-DB-07-09-05-72-
F9-00-00-00-00-00-00-00-30-39-30-36-30-35-32-44-
32-41-30-30-44-42-30-37-30-39-30-35-37-32-46-39-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
La sequenza sbagliata, iniziava dopo la serie di ottetti a zero con i byte 30 39 30 36... e così via. Nella sequenza era il venticinquesimo byte .. oops ottetto ma non voleva dir nulla... Avevo un report di un centinaio di periferiche, quelle che avevano inviato il messaggio avariato, avevano la sequenza corrotta ( peraltro simile in tutti i casi ) in posizioni assolutamente casuali all'interno del messaggio stesso.
Il mio pc è un po’ vecchiotto, ed è messo sopra la scrivania di lato dal monitor. Io lo tengo girato, perchè lavorando con le interfaccie seriali usb e anche una parallela con il datato dongle della IAR, devo continuamente attaccare e staccare i connettori posti sul retro. Di lato, con il nastro carta ho appiccicati tutta una serie di foglietti e postit con alcuni dati che utilizzo nel lavoro. I comandi AT, i numeri di telefono interni, la configurazione dei GSM Telit l’immancabile tabella ASCII e così via.
Il centro operativo non era composto solo da periferiche stand alone. La Wasserdome aveva previsto anche una rete fatta con tutta una serie di PLC che venivano monitorati in real time. I PLC erano in realtà dei PC linux, i puristi dei controlli industriali distinguono fra RTU e PLC, comunque il protocollo di interfaccia di questa RTU era il canonico Modbus. Il protocollo è stato inventato dalla Modicon nel 1979 per interfacciare i loro PLC. Alla fine è diventato lo standard mondiale per gli apparati industriali perché è semplice da implementare e non ci sono rojality da pagare. Il protocollo Modbus ha però qualche problemino strutturale. Non si possono mappare memorie di grandi dimensioni ( maggiori di 16 bit ) e se prevediamo delle funzionalità di logging questi dati storici possono essere scambiati solo implementando artifici logici che vanno fuori dallo standard di questo protocollo. Tipicamente i costruttori di PLC ti danno una mappa di memoria dove sono memorizzati lo stato degli ingressi e delle uscite dei loro moduli. Noi semplicemente, leggendo e scrivendo in questi registri, saremo in grado di controllare il nostro processo industriale. Le interrogazioni su queste RTU venivano effettuate da un front end logico chiamato server OPC.
La Opc foundation è una associazione della Microsoft, che ha lo scopo di standardizzare questo tipo di applicazione. In pratica si sono inventati questo standard internazionale, per interfacciare i sistemi di controllo industriali PLC ( o RTU ) con gli SCADA. I sever opc, sono tipicamente degli oggetti COM e comunicano con le RTU attraverso il loro protocollo dedicato. Gli scada tipicamente sono invece dei client OPC. In realtà questi server OPC non sono oggetti COM (Component_Object_Model) ma oggetti DCOM ( distribuite COM ). La Microsoft, non si era accontentata di progettare un oggetto cross sistema operativo, perché con lo sviluppo dei network, si doveva prevedere che le proprietà di questo oggetto, non fossero disponibili solo localmente, ma anche in uno dei nodi remoti del network.
Come di consueto banalizzo un attimo: quando io accedo ad un metodo di questo server OPC automaticamente parte l’oggetto COM se è locale, altrimenti si attiva l’oggetto DCOM se è installato in un altro nodo del network. Questa partenza automatica dell’oggetto COM è possibile perché l’oggetto è registrato nel file di registro di windows.
Cosa è il file di registro ? Ritorniamo agli albori. Uno dei problemi delle installazioni in dos era che dopo un po’ si creava all’interno dei miseri HD Winchester un vero pasticcio di directory piene di librerie e dll il più delle volte replicate. Gli eseguibili non si sapeva mai dove risiedevano e si passava il tempo a cercare i file con i comandi dos dir /w. Con l’avvento di Windows le cose cambiarono quando poi inventarono questa nuova struttura dati che è il file di registro. In pratica lo possiamo considerare come un macro filesystem della macchina ( i puristi lo chiamano database di sistema ). I programmi vengono identificati da una chiave univoca che contiene delle sottochiavi, con tutti i riferimenti necessari per il loro corretto funzionamento ( parametri di avvio, path di riferimento, variabili di sistema etc etc ). Ovviamente, l’idea della chiave di registro univoca è stata utilizzata per contenere non solo le informazioni software dei programmi installati, ma anche i riferimenti hardware della macchina stessa. Per questo motivo, le modifiche improvvide in questo file, potrebbero bloccare irreparabilmente il nostro PC.
Ma ritorniamo a parlare degli oggertti DCOM per un ultimo dettaglio. Ovviamente questa distribuzione di oggetti che risiedevano su altri nodi aveva portato a casini di dimensioni apocalittiche quando si dovevano condividere proprietà o le strutture dati. Per ovviare a questi casini svilupparono tecniche dette di Marshalling che permettevano appunto di sincronizzare gli oggetti com locali con quelli remoti.
Apro il progetto nuovamente, perché orami è abbastanza appurato che il problema è firmware. E così cerco di seguire passo passo, tutta la catena di operazioni che viene fatta dal microprocessore, da quando viene letto il dato a quando viene spedito l’sm, per vedere se ci sono punti deboli, in grado di provocare quel disastro.
Ma non avevo molti appigli.
L’assieme era sopra la scrivania, con quell’unico led cuoricino che segnalava la presenza di un ciclo temporizzato all'interno del micro. Analizzo tutti i for e gli while e tutti gli indici. I dati vengono presi ogni secondo. Meglio dire che ogni secondo venivano calcolate: le medie il massimo il minimo e poi veniva salvato tutto dentro la flash. Ogni minuto veniva fatta la verifica sull’ora di invio del SM, se era quella programmata allora veniva chiamata la procedura di lettura dei dati nella flash. Questi dati, venivano presi e salvati in un'area della ferroram che era quella utilizzata dal modulo gsm per l’invio dell’SM. Poi venivano passati ad una ulteriore funzione, che li prendeva e li trasferiva in un ulteriore buffer, sempre in ferroram e questo buffer veniva poi spedito al gsm.
Ma intanto avevo nella mente quel 30 39 30 36... mi sembrava di essere Nash e di tradurre i fantastici codici criptati che si creava nella sua mente malata. Va via la luce e si spengono tutti i pc. Le bestemmie volano e si sovrappongono, io rimango in silenzio mentre tutti guardano stupefatti il mio monitor acceso. ( be... e allora ? col gruppo di continuità è facile...)
30 39 30 36... si certo, certo lo so, lo so. I più smaliziati si sono accorti che questa sembra una sequenza di caratteri ASCII ( che io prouncio ASCHII e tutte le volte la gente mi dice eeee ? ) e quindi convertiti in formato testo diventerebbero 0 9 0 6. Ma noi abbiamo un messaggio PDU cosa diavolo c’entrano questi caratteri di testo ? Si è vero per il gsm non ci sono differenze fra un sms in formato testo e uno in formato PDU. In entrambi i casi io spedisco al gsm, comunque una stringa in formato testo, ci penserà poi il GSM a gestire i caratteri in modo diverso e nel caso PDU trasformandoli in formato binario.
se devo spedire infatti un messaggio PDU prima del comando AT+CMGS devo inviare il comando
AT+CMGF=1<cr>
Ma poi mi chiedevo: che cosa c’entrano quei numeri ? Anche se fossero delle cifre vere, sarebbero comunque sbagliate perché non sono davvero quelli i numeri delle variabili dichiarate nella struttura dati del messaggio.
Squilla il telefono è Bukovsky il tecnico della Wasserdome. Rimasi come impietrito per cique minuti. Come mi aveva anticipato la volta precedente, il problema del messaggio, era uno dei problemi. Adesso aveva la conferma che, durante l’installazione, molte delle periferiche non inviavano il messaggio di battesimo, questo li rallentava non poco, perché quelle che non inviavano il messaggio, avrebbero dovuto ritornarci il giorno dopo.
“Be in percentuale quante non inviano il messaggio ?” chiesi col terrore in gola
“il 90 %” rispose con un tono ghicciato
“che culo … credevo tu tutte …”
Ma mentre parlavo guardavo quella sequenza 30 39 30 36... e c’era qualcosa di diverso. Si Bukovsky con questo nuovo problema aveva appena dato fuoco alla legna del rogo dove ero seduto. Ma ero come ipnotizzato, guardavo il messaggio e la sequenza fino a quando si aprirono gli occhi e scoprii una incredibile simmetria...
“....possiamo sentirci domani così facciamo il punto della situazione”
Chiusi il telefono
E ripresi il messaggio.
28-8C-11-DB-07-09-06-05-2D-2A-00-DB-07-09-05-72-
F9-00-00-00-00-00-00-00-30-39-30-36-30-35-32-44-
32-41-30-30-44-42-30-37-30-39-30-35-37-32-46-39-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
la sequenza 30 39 30 36 30 35 32 44 32 41... traducendola con la tabella ascii, come abbiamo appena visto, crea una sequenza numerica
0-9-0-6-0-5-2-D-2-A …
se però li raggruppo in byte ottengo
09-06-05-2D-2A …
Guardavo il messaggio e strabuzzando gli occhi mi sono accorto che partendo dal 5° byte avevo l’esatta replica del messaggio stesso.
28-8C-11-DB-07-09-06-05-2D-2A-00-DB
-07-09-05-72-F9-00-00-00-00-00-00-00-
30-39-30-36-30-35-32-44-32-41-30-30-44-42-30-37-
30-39-30-35-37-32-46-39-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-00-00-00-00-00-00-00-00-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
Rimasi per una decina di minuti in stato catatonico. Su skype il messaggio di mia moglie con l’elenco delle cose da prendere al supermercato. Gli rispondo che va bene ma che farò un pochino tardi.
Il problema era che adesso dopo la telefonata di Bukovsky il disastro era raddoppiato.
Tentai allora con la trottola, per farmi dare un onirico calcio di risveglio, ma niente da fare non stavo sognando. Scrivevo delle note, sul solito foglio, che tengo davanti alla tastiera. Faccio così da tanto tempo, in particolar modo da quando ho capito che la documentazione, mi riesce meglio se prima la scrivo a mano e poi la trascrivo sul PC. Un'occhiata alle e-mail ma, oltre al solito spam, nessuno di importante mi aveva contattato. C’era si l’avviso della Microchip e della famiglia di microcontrollori da 70 mips. Miii 70 mips ( Mips = Mega Istruction Per Second )!!!! Ma in quel momento ero troppo spossato. Cercavo tempo che non avevo, Mangusta dopo domani si sarebbe aspettato delle risposte. Alla fine, mi arresi e alzai la testa, mi guardai intorno e scoprii che ero solo. I ragazzi erano già usciti da tempo bontà loro. Io come solito ero l’ultimo dalla azienda, in tutti i sensi. Spensi il riscaldamento, il server, le luci del laboratorio, un saldatore e un alimentatore di potenza dell’Ate di collaudo. Verificai che la porta di entrata del magazzino fosse accuratemente chiusa e mi avviai verso casa.
La leggera pioggerellina con i numerosi riflessi delle luci sulla strada e il rumore d’acqua dei pneumatici mi accompagnarono consolandomi.
Avevo l’ombrello ma non lo aprii e così passeggiai sotto la pioggia, in quelle deliziose grigie vie industriali fra centrali dell’Enel e aziende portuali canticchiando “...ai siiiiinghinin in de rein..”