Pubblichiamo un guest post di Emanuele Rampichini
Ricordando i presupposti di cui abbiamo discusso nel precedente articolo vediamo ora cosa il panorama open source offre nell’ambito dei sistemi operativi in tempo reale.
Possiamo considerare una suddivisione in due macro aree per quanto riguarda questi tipi di sistemi:
- SISTEMI OPERATIVI ADATTATI A PARTIRE DA PROGETTI NON PENSATI PER IL TEMPO REALE
- SISTEMI OPERATIVI IN TEMPO REALE DEDICATI SCRITTI DA ZERO
La scelta dell’uno o dell’altro approccio porta ovviamente con se vantaggi e svantaggi che vanno valutati attentamente. Per esempio l’utilizzo di sistemi adattati può permettere di ereditare un supporto hardware e software molto ampio senza troppi sforzi (anche se in realtà spesso la gestione di alcune periferiche necessita di una riscrittura completa dei driver per venire incontro alle esigenze del tempo reale).
D’altro canto sistemi specializzati nascono con in mente ben fissi obbiettivi e vincoli così da incarnare al meglio quello che un sistema operativo del genere dovrebbe essere (pensiamo per esempio a footprint minime nell’ordine dei 2-4 KiB impensabili per sistemi adattati).
Oggi presenteremo alcuni di quelli appartenenti alla prima categoria e nello specifico quelli in qualche modo legati al kernel linux.
Il problema principale che il kernel linux presentava quando è iniziato lo sviluppo di tali sistemi (intorno al 2000, quindi agli albori della serie 2.4 del kernel di Torvalds) era legato al fatto che la maggior parte del codice al suo interno fosse non-preemptive.
In parole povere alcune parti del codice del sistema operativo una volta sulla CPU non potevano essere interrotte in alcun modo. Si capisce come questo tipo di comportamento poteva provocare in alcune situazioni latenze inaccettabili per le problematiche tipiche del tempo reale (in alcuni casi anche di decimi di secondo).
Vediamo ora le soluzioni aperte più conosciute che hanno affrontato questo problema:
RTLINUX
RTLinux nasce presso l’università del New Mexico per mano di Victor Yodaiken. Il problema della preemption in questo caso viene risolto con uno stratagemma molto intelligente: far girare il kernel linux come un semplice processo in background sopra ad un micro kernel realtime. Tecnicamente è stata implementata una emulazione software del controllo delle interruzioni. Quando il kernel linux invierà un comando per disabilitare le interruzioni questo sarà catturato dal sistema operativo real time sottostante che potrà gestire la chiamata senza interferire in maniera non prevedibile con i processi in tempo reale. Nel 2007 il progetto è stato acquistato dalla Wind River ma viene comunque mantenuta una doppia versione free e commerciale.
RTAILINUX – Real Time Application Interface Linux
RTAILinux è un progetto Italiano nato nel Dipartimento di Ingegneria Aerospaziale del Politecnico di Milano per mano di Paolo Mantegazza. Anche in questo caso l’idea alla base è la stessa di RTLinux. Il compito di gestire linux o altri sistemi operativi come task in background è affidato al nanokernel Adeos (anche questo un progetto free e open source). RTAI viene rilasciato sotto forma di patch da integrare nel ramo ufficiale del kernel linux. Da notare anche la presenza di un corredo di librerie e strumenti per l’interfacciamento con l’hardware e con software come simulink, matlab o scilab molto utili per facilitare la vita dei programmatori.
LINUX
“Ma come linux?” vi starete chiedendo “Non eravamo d’accordo sul fatto che non fosse adatto per l’ambito real time?“.Ovviamente negli ultimi 10 anni di evoluzione del kernel linux ufficiale sono stati fatti passi avanti di cui va tenuto conto. A partire dalle patch low-latency di Ingo Molnar e Con Kolivas passando per l’inclusione del Complete Fair Scheduler dalla versione 2.6.23 (sempre da parte di Ingo Molnar) fino ad arrivare alla recente implementazione sperimentale dell’algoritmo di schedulazione EDF (uno dei più importanti algoritmi di scheduling per sistemi real time). I lettori più attenti avranno notato sbirciando nella pagina su github linkata poco sopra i nomi di chi sta lavorando all’implementazione di EDF come Dario Faggioli dottorando all’Università di Siena, il già citato Ingo Molnar e Linus Torvalds stesso. Nomi che fanno ovviamente ben sperare per una eventuale inclusione futura dell’implementazione nella mainline del kernel linux. Personalmente credo che tale evenienza darebbe senza dubbio un bello scossone a tutto l’ambiente considerando che in moltissimi casi il kernel ufficiale ha saputo essere l’accentratore ideale degli sforzi comuni di aziende e appassionati.
Sperando di aver incuriosito qualche lettore e di non averne fatti addormentare troppi vi do appuntamento alla prossima puntata in cui verranno presentati alcuni tra i sistemi operativi open source in tempo reale scritti da zero.
Mi chiedevo appunto in che anni avessero iniziato a pensarci al linux-rt.. interessante.
Personalmente traggo molto vantaggio, più che su una piattaforma Apple, in fase di registrazione su Ubuntustudio :)
Sto seguendo il corso di Sistemi in tempo reale proprio adesso, e come progetto ho proprio portato un programmino realizzato con RTAI :-)
In ogni caso sbaglio o stiamo parlando di patch, stratagemmi e barbatrucchi ?
Non esiste proprio un kernel linux nativamente RT ?
@ D
Stratagemmi, barbatrucchi?
Sai almeno cosa significhi patch?
@D
Eh si! Si tratta ovviamente di considerare il trade-off tra questo genere di “trucchi” (appellativo valido solo per i primi 2 visto che nel caso del kernel ufficiale si parla di integrazione di una nuova classe di scheduling) e sistemi più eleganti. Ovviamente la scelta non sempre è semplice e dipende dall’ambito di applicazione.
Prevedete un articolo anche sui sistemi BSD?
eccone un altro (anche se non è Linux..)
http://www.ossblog.it/post/5687/atomthreads-open-source-rtos
una domanda per l’ autore sui rispettivi Linux e RTLinux menzionati nell’ articolo:
quello che vado a installare al posto del normale kernel quando – per esempio – voglio fare musica, quale sarebbe dei due?
“Ovviamente la scelta non sempre è semplice e dipende dall’ambito di applicazione.”
Ma se si dovesse riscrivere per intero il kernel in modo che diventi nativamente RT si potrebbe ancora parlare di kernel linux ?
Come ha già detto sopra Lele attualmente linux è predisposto per l’esecuzione in real time e comunque attualmente alcune distribuzioni linux ( archlinux per esempio) hanno un kernel precompilato real-time…
Di fatto se così non fosse non potrei eseguire il server PulseAudio a bassa latenza col kernel linux nella sua versione di default inclusa in archlinux…
“attualmente linux è predisposto per l’esecuzione in real time”
Non mi sembra proprio se le soluzioni attualmente utilizzate prevedono l’uso di un kernel veramente RT o inseriscono patch che per loro stessa natura cambieranno delle cose del sistema ma non lo rivoluzioneranno in toto.
“Di fatto se così non fosse non potrei eseguire il server PulseAudio a bassa latenza col kernel linux nella sua versione di default inclusa in archlinux…”
Merito delle patch a bassa latenza ma non ad una riscrittura di tutte quelle parti del kernel che non sono RT
@pokeroso
Putroppo non ho grosse conoscenze del mondo BSD (lo so è una bella mancanza). Per scrivere un pezzo del genere dovrei prima documentarmi e soprattutto provare con mano. Nel prossimo articolo si parlerà però di sistemi operativi rilasciati sotto licenza BSD.
@n0v0
Per quanto riguarda Atomthreads ho dato una occhiata veloce sul loro sito ma non sono ben riuscito bene a capire quali algoritmi di scheduling mette a disposizione a parte il Round Robin (che non è un algoritmo real-time)
Per la seconda domanda il kernel che installi nelle distribuzioni linux per il multimedia non ha niente a che vedere con RT-Linux. Tecnicamente parlando il termine real time in quel caso fuorviante poichè si tratta di un kernel a bassa (o bassissima) latenza.
@D
Fortunatamente non bisogna riscrivere niente per intero. Si tratta semplicemente di aggiungere algoritmi di scheduling real-time a più alta priorità (cosa che lo standard POSIX e l’implementazione di linux permettono tranquillamente). Ovviamente tutto quello che è pensato per il general purpose non va bene, ma pretendere una cosa del genere sarebbe come volere la botte piena e la moglie ubriaca.
@italyanker
Purtroppo gli attuali kernel-rt che girano sono come già detto “impropriamente” chiamati real-time. Nel caso di Arch Linux leggendo il PKGBUILD (script di compilazione per chi non conoscesse il sistema) del paccheto si vede subito che è semplicemente l’applicazione della patch BFS di Con Kolivas. Non che queste semplici patch non siano sufficienti a garantire un comportamento eccelso per esempio per la produzione audio a livello professionale.
“Ovviamente tutto quello che è pensato per il general purpose non va bene”
E nel kernel quanta roba di questo tipo si può trovare ?
@D
Ovviamente ma altrettanto ovviamente basta non utilizzarla all’interno dei task gestiti dall’algoritmo real-time. Vedila come la possibilità di poter costruire task realtime che girino nativamente sul kernel linux e contemporaneamente poter comunque sia utilizzare la parte general purpose che starà ad un livello più basso di priorità e non influenzerà in alcun modo il comportamento dei task “critici”.
Mi sono mangiato un pezzo della prima frase:
Ovviamente di questa “roba” ce n’è molta essendo linux un kernel general purpose ma altrettanto ovviamente basta non utilizzarla all’interno dei task gestiti dall’algoritmo real-time.
@ Emanuele
complimenti per l’articolo,!
aspetto con ansia anch’io l’articolo sui bsd visto che mi hanno sempre attirato (anche se non ne ho mai usato uno).
se mi permetti però ti metto in coda un’altra richiesta XD.
anche se non sono un utente apple mi piacerebbe capire meglio come funziona e come è suddiviso il kernel-space di macosx, leggendo qua e là non riesco a capire bene. Sarebbe sicuramente un articolo interessante.
concludo complimentandomi con AD, che settimana per settimana stà sfornando degli articoli interessantissimi di software,hardware e anche fisica ed energia.
(IMHO sarebbe bella una rivista mensile:D)
“Ovviamente di questa “roba” ce n’è molta essendo linux un kernel general purpose ma altrettanto ovviamente basta non utilizzarla all’interno dei task gestiti dall’algoritmo real-time.”
Ed è possibile farlo ? Cioè se una macchina ha le ruote, per forza di cose devo utilizzarle per farla spostare autonomamente. Da una parte non mi stupirei se dentro il kernel trovassimo più cose diverse realizzate per uno stesso scopo ma se così non fosse…
@Emanuele Rampichini: utilizzare un microkernel sul quale far girare il kernel di Linux è simile alla soluzione di OS X. Ma possiamo ancora parlare di kernel Linux (che è trattato alla stregua di un processo) realtime?
@Giulio
Prima di tutto grazie. Per quanto riguarda il discorso BSD ti rimando automaticamente alla risposta che ho dato a pokeroso aggiungendo che se avrò tempo di approfondire l’argomento in futuro non mancherò di scriverci su qualcosa.
@D
Non sono sicuro di aver capito bene cosa vuoi dire con il discorso della macchina e delle ruote. Mi sembra di capire che fai riferimento all’utilizzo delle risorse non appositamente scritte in ottica real time. In questo caso se si necessitano di “ruote” real time vanno comunque reimplementate mentre se in un determinato campo applicativo quelle classiche tonde vecchie ma ben rodate possono andare bene allora non conviene reinventarle. ;-)
@Cesare Di Mauro
Nel caso di RT-Linux o RTAI ovviamente non si può parlare di linux. Forse sarebbe meglio definirli come sistemi “linux compatibili”. Nel caso dell’implementazione diretta di una classe di scheduling invece credo che possiamo parlare di kernel linux realtime senza problemi.
Sto solo dicendo che il kernel è quello che in un certo senso dice alle applicazioni quello che possono fare o meno e quello che mi chiedo è quanta roba in percentuale del kernel tradizionale si può riutilizzare in ottica RT. Quanto ha senso continuare la strada del “prendo il kernel classico e metto la patch” e quanto invece l’idea di non aver paura di cestinare un’infinità di roba e riscriverla su misura
trovandomi in aeroporto costretto ad aspettare, ho deciso di rispondere a questo articolo sempre piu’ delirante…
Di linux embedded realtime ce ne sono a centinaia!
spesso si utilizzato moduli che supportano timer esterni, o emulazioni software basate su codice assembler che gira direttamente sulla cpu(accuratamente scelta) quindi comunque legato all’hardware…
alcuni li compilano staticamente nel kernel…
in genere si tratta di poche centinaia di righe di codice assembler.
in genere i sistemi sono minimali, quindi con hardware ridotto al minimo, perche’ per sistemi complessi si utilizzano le nuove tecniche di virtualizzazione….quindi i kernel linux girano su virtualmachine RT e nessuno si deve preoccupare di niente perche’ il sistema se la vede lui…
tutto quanto citato in quest’articolo e’ pura accademia…
ma cavolo andate nelle linee di produzione e vedete come funzionano le cose!
invece di citare appunti deliranti di professori che dovrebbero andarsene in pensione…
senza un adeguato supporto hardware non esiste realtime!
allora l’autore citi un sistema linux realtime che sia in produzionne ossia hardware+software e lo analizzi se vuol fare un articolo decente oppure taccia!
ps: c’e’ sempre da capire cosa c’entri un dipartimento di ingegneria aerospaziale con un progetto di ingegneria del software come un ipotetico LinuxRT…ma questo è tipico degli ingegneri che tendono sempre ad esulare dalle proprie competenze specifiche illudendosi che il loro “genio” possa spaziare in tutto l’umano scibile…poveri loro….poveri noi…poveri gli studenti…
“in genere si tratta di poche centinaia di righe di codice assembler.
in genere i sistemi sono minimali, quindi con hardware ridotto al minimo, perche’ per sistemi complessi si utilizzano le nuove tecniche di virtualizzazione….quindi i kernel linux girano su virtualmachine RT e nessuno si deve preoccupare di niente perche’ il sistema se la vede lui…”
Effettivamente il ragionamento fila e smazza i vari dubbi senza fatica. La visione accademica della cosa, probabilmente è fatta per spaziare in modo osceno e quindi farla franca quando viene presa in castagna da qualcuno meno studiato e più pratico. Infatti mi pare di capire che tutto sto discorso si potrebbe tranquillamente applicare ad un banale codec a/v come ad una centrale nucleare.
“ps: c’e’ sempre da capire cosa c’entri un dipartimento di ingegneria aerospaziale con un progetto di ingegneria del software come un ipotetico LinuxRT…”
Beh, se pensiamo che nel corso di ing. informatica piazzano roba di discutibile utilità come chimica e vari livelli di fisica (per carica roba bella e cara, ma forse più indicata per gli elettronici) spesso “standardizzati” e non specializzati (quando possibile) verso quello che si vuole fare non mi stupisco se qualcuno pensa di saltare dagli aerei ai sistemi informatici.
Mi viene però in mente un’ipotesi: che il dipartimento di aerospaziale collabori con quello di informatica al fine di creare qualcosa ottimizzato agli aerei e quindi potrebbe spiegare lo strano mix (ma in tal caso mi sa proprio che l’hardware di questo aereo sarebbe fatto su misura per un sistema RT)
@homero
Se mi dici in quale punto l’articolo è delirante magari si può intavolare una discussione seria. Sinceramente non capisco come quello di cui parla vada in qualche modo a contrapporsi a quello che ho scritto io. Non ho mai parlato di sistemi complessi, non ho mai parlato di virtualizzazione, non ho mai detto che queste soluzioni sono “La soluzione a tutti i problemi del mondo”. L’articolo esula completamente da quello di cui tu stai parlando. La mia esperienza è quella di uno studente universitario di Ingegneria Informatica e appassionato di tecnologia e quella io metto nella stesura dell’articolo.
Per il discorso degli ingegneri non ti rispondo nemmeno. Non sono uno di quelli che difende la categoria ad occhi chiusi. Credo che il valore delle persone sia indipendente dal titolo di studio ma mi piacerebbe che venisse portato rispetto nei confronti di chi fa sacrifici (e ti assicuro che non sono pochi) per studiare e comprendere a fondo problematiche anche complesse e interdisciplinari.
@D
Quello di cui parla homero è quello che viene fatto correntemente nel mondo embedded. Mi scrivo l’applicazione direttamente sull’hardware e via. È un approccio che si è certamente rivelato ed è valido ma la possibilità di utilizzare un sistema operativo è ovviamente il passo successivo per quanto riguarda la flessibilità in questo genere di applicazioni. La potenza di calcolo dei microcontrollori sta aumentando in maniera sostanziale (Pensa solo che ho sottomano un dsPIC della microchip che gira a 40Mhz) e l’utilizzo di un sistema operativo è diventata una “spesa computazionale” che ci può stare, soprattutto pensando alla flessibilità che ne deriva.
Per quanto riguarda la diatriba sui corsi di ingegneria, se vogliamo parlare dei percorsi di studio che spesso sono mal pensati e male organizzati possiamo farlo, ma far uscire dall’università in Ingegnere che non sappia niente o quasi di fisica sinceramente non mi pare una bella prospettiva. Quello che distingue un buon ingegnere da un buon tecnico è proprio la capacità di saper coniugare e collegare conoscenze multidisciplinari per risolvere problemi. Nel mondo universitario ovviamente c’è stretta collaborazione tra i dipartimenti per progetti che richiedono competenze altamente specifiche in settori diversi.
@Emanuele Rampichini (per un attimo sono stato tentato di scrivere E.R. per brevità, ti chiedo scusa XD )
però non mi pare del tutto errato affermare che l’ articolo, per quanto interessante e utile per chi non ha mai sentito parlare di certe cose o le conosce solo per sentito dire, si limiti un po’ come dire a introdurre la questione (il significato si sistema realtime, che per implementarne uno si può sostanzialmente scegliere la strada del kernel singolo o quella del cokernel, e i principali progetti per rendere linux realtime, sono cose che da me sono state dette alla prima lezione di Sistemi Operativi) senza però approfondire – che è quello che credo pensasse homero…
IMHO, sarebbe stato interessante menzionare quali problematiche pone un sistema realtime e quali accorgimenti richiede …
per consentire a un’ applicazione realtime di fare quello che deve fare entro una certa deadline è necessario garantire tempi deterministici (predicibili) noti a priori (dati dall’ esecuzione di code path di complessità costante – O(k)) o quantomeno consistentemente inferiori a un upper bound (determinato in fase di progetto) non solo in sede di attivazione e rescheduling (da cui la preemptability del kernel), ma anche nel servire le system call delle quali l’ applicazione necessita
ora, introdurre dei preemption point e aumentare la granularità delle sezioni critiche nel kernel durante le quali gli interrupt sono disabilitati, significa affrontare una parte del problema – ridurre i tempi di attivazione e risposta agli interrupt, idealmente rendendoli trascurabili o almeno al di sotto di una soglia minimale – ma non dice nulla sul tempo di esecuzione di una malloc()o di una serie di allocazioni in memoria o lettura da file, o peggio ancora, accesso in memoria stante la possibilità di paging/swapping (che infatti sui sistemi RT è bellamente disabilitata o sconsigliata), rendere deterministche le quali è un problema a parte, o un’ altra parte del problema più ampio
i sistemi real time commerciali sono in buona parte a microkernel anche per questo – da una parte, dato l’ insieme ridotto di astrazioni logiche e funzionalità (task/thread switching, IPC, IO e routing degli interrupt, ma spesso nemmeno questo) richieste, è molto meno complesso progettare e implementare un kernel “fully preemptable” micro- piuttosto che macrokernel (a parte la difficoltà ancora maggiore di rendere preemptable un macrokernel che inizialmente non lo è, peraltro uno con una code base ampia come linux)
dall’ altra, costruire una code base RT- compliant minimale, sposta il problema a livello applicativo, nelle mani dello sviluppatore dell’ applicazione realtime che su quella base girerà – il cui lavoro è sia complicato dal poter contare su facility minimali a basso livello e dover gestire parecchi aspetti direttamente, sia semplificato dal sapere di doverlo fare e dalla intrinsecamente maggiore libertà progettuale che il sistema offre
su questo hai perfettamente ragione – soprattutto per certe applicazioni proprio realtime è utile se non fondamentale avere una minima dimestichezza con le leggi che governano il sistema fisico che il controller in realtime andrà a controllare, se sto implementando una centralina ESP devo sapere cosa sono coppia motrice e momento angolare agente sulla vettura…
“ma far uscire dall’università in Ingegnere che non sappia niente o quasi di fisica”
E’ più una questione di etichetta questa.
Spiegami cosa frega ad un elettronico tutta la parte di fisica relativa ai moti ed agli attriti dal momento che gli unici moti che vedranno i componenti elettronici sarà lo spostamento dalla scatola al pcb ed eventualmente una ventolina di raffreddamento (che comunque non progetterà ma comprerà già montata).
Chimica risulta già più utile ma viene proposta in un modo e con tempistiche che la rendono solo una seccante rottura e di fatto fino ai corsi di elettronica non viene più ripresa, risultando semplicemente dimenticata.
@j
Per le abbreviazioni usa tranquillamente quelle che vuoi… non mi formalizzo certo su queste cose! ;-)
Per il resto il discorso è abbastanza semplice. La spiegazione degli algoritmi in ballo, la stima del Worst Case Execution Time, il fenomeno dell’inversione della priorità con risorse condivise, i limiti della programmazione riguardo alla ricorsione o ai cicli o alla gestione dinamica della memoria etc… sono tutti argomenti interessantissimi che ho affrontato. Il problema è la loro spendibilità. L’idea di questi articoli era quella di incuriosire quelli che di sistemi real time non ne sanno niente. Mi dispiace se qualcuno ha trovato “noiose e vecchie” le cose scritte. Detto questo non mi sembra carino definire “delirante” un articolo che per quanto possa essere non approfondito non mi sembra riporti fatti o dati inventati.
@D
Non tutti gli Ingegneri Elettronici si troveranno a lavorare esclusivamente su un pcb. Un ingegnere elettronico potrebbe tranquillamente trovarsi a lavorare alla progettazione di un sistema di controllo di apparati meccanici che sottostanno alle leggi della meccanica classica. E avere quanto meno un’idea di quello che succede può fare la differenza tra un buon lavoro ed un cattivo lavoro.
“zE avere quanto meno un’idea di quello che succede può fare la differenza tra un buon lavoro ed un cattivo lavoro.”
Quando Carmack progettò il motore di Doom3 confessò di non sapere molto di fisica quindi se la studiò sul momento il che mi pare molto più logico.
Prendi l’arte e mettila da parte ha senso fino quando non ce n’è troppa…
Mi spiace per la risposta un po’ dura, ma nella sostanza purtroppo la resa dei conti e’ questa
se si vuol parlare di OS real time si inizia da qui (1984)…
http://web-japan.org/trends/science/sci030522.html
se si vuol scrivere un articolo “scientifico divulgativo” bisogna porre dei punti fermi (citare Con Kolivas in un OS real times è veramente immaginifico…)
allora si cominci a parlare del CPU support del kernel linux perche’ e’ li’ che si gioca l’intera partita del real time, e non basterebbero le poche righe scritte in quest’articolo per farlo anche solo in maniera approssimativa…
per quanto riguarda la diatriba degli ingegneri parlo da ingegnere elettronico, laurea presa quando la laurea in ingegneria informatica non esisteva…
ho studiato fisica classica, fisica tecnica, e persino la geometria proiettiva….
tutto serve a questo mondo quando fatto bene…
…ma nonostante i master successivi in algoritmi e strutture dati, i corsi sui linguaggi di programmazione che ai miei tempi non si studiavano all’università almeno nella mia facoltà….mi rivolgo sempre ad un collega esperto per quanto riguarda materia di cui non sono pienamente padrone…
questa che alcuni chiamano umiltà è soltanto buon senso, perche’, l’ingegneria è fatta di regole, regolamenti, convenzioni e standard industriali…e per svolgere un buon progetto occorre stare in queste regole… se no si fa come fanno i cinesi…che seguono il vecchio detto…tutto va bene basta che funzioni e finche’ funziona…
la mia critica a questo articolo era proprio rivolta al fatto che un ingegnere o un futuro ingegnere deve seguire le regole d’oro che la materia che studia gli impone, non puo’ permettersi leggerezze o imprecisioni, in quanto nella vita reale imprecisioni di questo tipo possono costare caro molto caro…
cordialità
@D
Concludendo la discussione che ormai è un po fuori dal topic dell’articolo mi piacerebbe far notare che non tutti sono “John Carmack”. Probabilmente lui con le sue eccezionali capacità è riuscito a studiarsi da solo le basi quando ne ha avuto bisogno senza troppi scogli mentre per altri un problema del genere potrebbe essere una montagna insormontabile. L’obbiettivo di facoltà come quella di ingegneria è quello di darti gli strumenti per affrontare una buona varietà di problemi quando si presenteranno. Inoltre almeno nella mia facoltà durante il triennio base ci sono solo 2 esami di fisica “pura”, uno di cinetica/meccanica di base e quello di elettromagnetismo su un totale di 30 e più esami.
Più che “quando”, “se” si presenteranno e come già detto in partenza vorrei capire dove sta il “quando” per un informatico perchè tanto alla fine se avessi bisogno di una consulenza che riguarda la fisica vado da un fisico, non da un informatico.
Il mio professore di chimica(materia da me odiatissima) alla domanda “ma io sono informatico, che mi frega della chimica”, rispose “un ingegnere DEVE conoscere le tre scienze fondamentali: CHIMICA,FISICA E MATEMATICA”.
Effettivamente non ha tutti i torti.
In merito all’articolo, credo sia un’interessante introduzione,anche se i contenuti non sono “all’ultimo grido”.
@D (fuori dal topic, ma non si poteva non ribattere)
Da studente di ingegneria elettronica dissento completamente. Non tutti gli ingegneri elettronici fanno lo stesso tipo di lavoro (a uno interessa di più lavorare con i PCB, un altro magari predilige i controlli automatici, a un terzo – come me – piacerebbe lavorare nel campo della microelettronica). Un corso di ingegneria dell’informazione (e ciò comprende anche gli ingegneri informatici) DEVE fornire gli strumenti per capire problemi di ogni genere nell’ambito dell’informazione e quindi deve dare un’ottima cultura scientifica di base.
Ad esempio, a chi si occupa di sistemi di controllo una buona conoscenza della meccanica risulta certamente utile. A uno come me che ama la microelettronica ed è fortemente interessato al funzionamento dei dispositivi, serve un’OTTIMA preparazione di matematica, fisica e chimica. E sempre per restare in tema di meccanica: sfido chiunque a capire i concetti fisici fondamentali dell’elettromagnetismo o della meccanica quantistica senza avere nessuna conoscenza di meccanica classica. Sarebbe come voler imparare a risolvere equazioni differenziali prima di saper contare: forse è anche possibile, ma ha senso?
Al di là di questo, tu hai scritto che se un ingegnere ha bisogno di risolvere un problema di fisica complesso, chiede aiuto a un fisico e non fa da sè. Sono perfettamente d’accordo, ma vorrei sottolineare che il fisico e l’ingegnere per lavorare insieme su un problema complesso devono pur capirsi. Se tu non hai nessuna idea di cosa sia un campo elettromagnetico e sottoponi un bel problema complesso di elettromagnetismo a un fisico, questo te lo risolverà nel suo linguaggio: ti indicherà i valori del campo in certi punti, la potenza trasmessa, eccetera. Ma, non sapendo tu nulla di elettromagnetismo, sarà come se ti parlasse in sumero!(ovviamente il “tu” è un tu dialettico, non ho idea se tu sappia qualcosa di fisica o meno e nemmeno cosa tu faccia nella vita :D )
Quest’ultimo secondo me è il motivo più importante per avere una formazione scientifica accurata anche in facoltà di ingegneria, dove per forza l’indirizzo è fortemente specialistico: sono conoscenze fondamentali per lavorare in un team con altri ingegneri e scienziati.
“Il mio professore di chimica”
Come la professoressa di matematica alle superiori che dice “studia mate che ti serve” poi tutti si domandano perchè nessuno lo fa…
(piccolo suggerimento: forse perchè, se invece di attaccarsi a frasi fatte, ci si sforzasse di illustrare degli scenari di utilizzo plausibili magari uno potrebbe prendere la cosa sotto un’ottica diversa)
Per la cronaca ai tempi avevo una prof di latino che affermava che Cicerone serviva per l’informatica… peccato che lo stesso Lorem Ipsum è solo un accumulo di parole senza senso ed il latino in informatica non viene usato assolutamente per niente.
“Da studente di ingegneria elettronica dissento completamente. ”
In ing. Elettronica posso capire l’utilità di chimica e alcune parti della fisica, ma ne rimangono certe che di nuovo non si capisce dove vogliono condurre.
Alla fine dei conti, se si deve realizzare uno strumento informatico/elettronico che deve svolgere un lavoro meccanico, non si chiamerà in causa solo l’informatico, l’elettronico o il meccanico ma tutti e tre. Se il meccanico stabilirà che una certa cosa dovrà muoversi in un certo modo, non saranno l’informatico o l’elettronico che potranno contestarlo quindi ci sono delle parti di specializzazione nei tre personaggi che risulteranno praticamente inutili.
@D
Ho l’impressione che tu non abbia affatto letto quello che ho scritto, in particolare l’ultima parte; o magari mi sono spiegato male: provo a chiarirmi. Senza un bagaglio di conoscenze in comune, quello che tu chiami “sovrapposizioni inutili”, come possono capirsi i tre ingegneri? Immagina di avere un progetto che contenga parti meccaniche complesse controllate da un hardware su misura e, a livello più alto, da un programma per computer. Tu pensi a tre progettisti che, per inventare un oggetto del genere, lavorano in modo completamente disgiunto l’uno dall’altro sfruttando al massimo la specializzazione: ma come collegare fra loro i tre sottosistemi (meccanico, elettronico e informatico, per semplificare) se nessuno dei tre sa assolutamente nulla di altro che la sua materia specifica?
Esistono due possibili risposte. La prima è quella di chiamare una quarta figura: un “ingegnere generico” che, pur non avendo conoscenze approfondite di nessuna delle tre materie, ne sa abbastanza da poter coordinare il lavoro e mettere insieme i vari pezzi.
La seconda, apparentemente antitetica, è appunto fare in modo che i tre ingegneri siano sì fortemente specializzati, ma abbiano anche ciascuno una seppur minima conoscenza del ramo dell’altro. Così, se il meccanico dice all’informatico di modificare la variabile che controlla la coppia di un oggetto meccanico (parlo per esempio), i due si capiscono, sanno di cosa si sta parlando. Inoltre in questo modo tutti e tre gli ingegneri hanno una seppur vaga idea di come funziona l’oggetto nel suo insieme, cosa che non può che contribuire al suo buon funzionamento. L’ingegneria è appunto la scienza di risolvere problemi complessi suddividendoli in problemi (e sistemi) progressivamente più elementari, partendo o da un’idea del complesso (metodo top-down) o dai singoli mattoni fondamentali (metodo bottom-up).
Naturalmente i due metodi non sono affatto contradditori e probabilmente il meglio si ha quando sono applicati tutti e due. Rimane il fatto che, se i tre ingegneri non avessero nessuna “inutile sovrapposizione”, in mancanza di un coordinatore esterno costruire un oggetto complesso sarebbe del tutto impossibile: questo, lo ripeto, è a mio parere il motivo principale per cui una formazione completa su matematica, fisica e chimica è indispensabile per un ingegnere.
Questo non vuol dire che i corsi siano ben preparati: nel mio corso di laurea c’è una quantità enorme di matematica obbligatoria (4 esami di analisi e 1 di geometria, più altri facoltativi), abbastanza fisica (3 esami obbligatori e 1 facoltativo), ma poca chimica (nessun esame obbligatorio, solo 2 facoltativi). Anche i programmi probabilmente andrebbero adattati ai singoli corsi di laurea. Ma ciò non vuol dire che una preparazione ampia sia un male, anzi.
Quanto alla fisica utile in ingegneria elettronica… l’unica parte che è veramente poco utile (intendo nei corsi di base) è la meccanica, ma senza meccanica si capisce poco e niente di tutto il resto della fisica, anche perché vi si trovano alcuni concetti che sono un po’ la chiave di volta di tutta la fisica (almeno di quella classica): energia, lavoro, campo di forze. Tutto il resto è utilissimo: elettromagnetismo e onde sono fondamentali, termodinamica ogni tanto serve e poi è molto utile per capire meglio la chimica, che a sua volta è piuttosto importante (almeno per certi curricula di studio, come quello che intendo seguire io!). Per concludere… la meccanica quantistica (che comunque dubito sia obbligatoria nella maggior parte dei corsi) non è fondamentale a meno che uno non si voglia dedicare allo studio dei dispositivi (i transistor), soprattutto a scopi di ricerca, nel qual caso è assolutamente imprescindibile.
@D
rispetto la tua opinione, ma da ingegnere informatico posso dire che la matematica(non quella “pura” fine a se stessa) e la fisica mi son servite tutte, e molto. La chimica….fin’ora no, ma in futuro chissà…..
@Emanuele Rampichini
quindi il mio vecchio Amiga con il suo S.O. che è un multitasking preemtive è quasi un sistema real time e non lo è solo perchè non rispetta vincoli per l’esecuzione dei task in tempi certi?
@Davide
Non conosco gli internals del vecchio Amiga (pur avendo posseduto come primo computer un Amiga 500). Sicuramente AmigaOS è stato uno dei pionieri del multitasking preemptive che è la base minima sulla quale costruire qualsiasi sistema in tempo reale. Poi di mezzo c’è l’hardware e tutte quelle utilità di un sistema operativo general purpose (mi viene da pensare al DMA per esempio) che aumentano le prestazioni ma influiscono pesantemente sul determinismo delle applicazioni che ci girano sopra.
Il DMA c’è anche nei PC e, in generale, praticamente in tutti gli hardware moderni.
Tolto questo, a livello puro s.o., con AmigaOS potevi anche disabilitare istantaneamente il multitasking (come pure tutti gli interrupt e/o tutti i canali DMA) se avevi assoluto bisogno di eseguire un pezzo di codice “senza intromissioni”. ;)
sito temporaneamente non raggiungibile (working)
Ottimo articolo,bravi colleghi.
A presto.
@Emanuele Rampichini Ciao! Mi sembra un buon articolo, soprattutto per chi si avvicina al real-time per la prima volta e vuole capire come potrebbe muoversi usando Linux e varianti!
Due sole cose: (1) il progetto SCHED_DEADLINE e` per adesso ospitato su gitorious, non github (http://gitorious.org/sched_deadline/pages/Home, da aggiornare, provvedero` al piu` presto!), e (2) Dario Faggioli e dottorando alla Scuola Sant’Anna di Pisa, non all’Universita` di Siena. :-P
Cmq, ripeto, interessante davvero. Per qualunque chiarimento o ulteriore approfondimento contattami/contattatemi pure direttamente.
Ciao, Dario Faggioli