Insegnamento

Ingegneria per l'embedded software

Settore scientifico Disciplinare

ING-INF/05

CFU

6

Descrizione dell'insegnamento

Il software traduce il pensiero umano in azioni di macchinari.  Senonché il pensiero può contenere errori, così come errori possono esser commessi nella traduzione del pensiero in mosse di macchinari, con conseguenze economiche e sociali.       
Pensiamo, ad esempio ai terminali Bancomat.  Cosa fa chi sviluppa il software per la guida di un Bancomat?  Mette innanzitutto giù il suo pensiero. Produce, cioè le cosiddette specifiche funzionali, lista delle azioni che il software deve far compiere al terminale. Successivamente, consegna le specifiche a un programmatore, il quale genera il software vero e proprio.
Senonché, le specifiche possono contenere errori, così come errori possono essere commessi dal programmatore. Con la conseguenza di imprevedibili malfunzionamenti.     
Pertanto, la Banca che commissioni il software imporrà, al produttore, un requisito di affidabilità (ad esempio, che esista una probabilità di malfunzionamento non superiore a uno su centomila nelle 24 ore). E, col requisito, fisserà anche una penale per il caso di mancato rispetto.
Quel che vale per un Bancomat vale anche per un macchinario che guidi il servo-sterzo di un’automobile, l’auto-pilota di una metropolitana, quello di un aereo o di un vettore satellitare.  In questi casi, un malfunzionamento produrrebbe perdite sia economiche che sociali.
Pertanto l’Audi, o la Boeing o la Nasa che commissioni il software imporrà, al produttore un requisito di safety cioè di sicurezza contro eventi catastrofici, oltre che un requisito di affidabilità.
Come deve, chi produce il software, operare perché esso non infranga il requisito di affidabilità e, ancor più, quello di safety?   E’ la domanda cui questo corso intende rispondere dando agli studenti gli strumenti necessari ad assicurare e valutare l’affidabilità dei software incorporati nei recenti veicoli dell’area automotive.

Obiettivi formativi (espressi come risultati di apprendimento attesi)

Dublino1: CONOSCENZA E CAPACITA’ di COMPRENSIONE

  • Trattandosi di corso Magistrale, alla fine del corso lo studente avrà conoscenze e capacità di comprensione delle metodiche di sviluppo di software embedded, che estendono e rafforzano quelle tipicamente associate al primo ciclo e consentono di elaborare e applicare idee originali, spesso in un contesto di ricerca.
Dublino 2: CAPACITA’ di APPLICARE CONOSCENZA E COMPRENSIONE
  • Trattandosi di corso Magistrale alla fine del corso lo studente sarà in grado di applicare le metodiche di sviluppo di software embedded dell’area automotive in maniera di applicare le sue conoscenze, capacità di comprensione e abilità nel risolvere problemi a tematiche nuove o non familiari, inserite in contesti più ampi (o interdisciplinari) connessi al proprio settore di studio.
Dublino 3: AUTONOMIA di GIUDIZIO
  • Trattandosi di corso Magistrale, il corso prevede prove che consentono allo studente di giudicare il livello di preparazione raggiunto con capacità di integrare le conoscenze e gestire la complessità, nonché di formulare giudizi sulla base di informazioni limitate o incomplete, includendo la riflessione sulle responsabilità sociali ed etiche collegate all’applicazione delle loro conoscenze e giudizi.
Dublino 4: ABILITA’ COMUNICATIVE
  • Trattandosi di corso Magistrale, le prove prevedono possibilità per lo studente di interagire col docente allo scopo di affinare le proprie capacità di comunicare in modo chiaro e privo di ambiguità le sue conclusioni, nonché le conoscenze e la ratio ad esse sottese, a interlocutori specialisti e non specialisti.
Dublino 5: CAPACITA’ DI APPRENDIMENTO
  • Trattandosi di corso Magistrale l’interazione con il docente prevede anche valutazioni con indicazione di errori e invito a correggere, onde sviluppare nello studente le capacità di apprendimento che gli consentano di continuare a studiare in modo autonomo.

Prerequisiti

Lo studente deve aver conoscenze nelle seguenti materie:

  • Ingegneria del Software
  • Programmazione Java o C++
  • Probabilità e Statistica

Contenuti dell'insegnamento

L’insegnamento si articola in 10 punti:
  1. Il ruolo del software nell’automotive
  2. Software di powertrain, chassis e body
  3. Architettura logica del sistema
  4. Elementi basilari del sistema
  5. Processi fondamentali di sviluppo software
  6. Processi di supporto allo sviluppo
  7. Affidabilità, monitoraggio e diagnostica
  8. Analisi e testing per affidabilità del software embedded
  9. Affidabilità e safety
  10. Analisi e testing per safety
Trattandosi di un corso di 6 CFU ed essendo previste 5 ore di didattica erogativa per CFU, i 10 punti saranno coperti da un totale di 5x6=30 ore di didattica erogativa in forma di videolezioni. Considerato che lo studente ha necessità di almeno un riascolto di ciascuna videolezione, la materia sarà coperta da 15 videolezioni.

Attività didattiche

Didattica erogativa
Come sopra specificato, l'insegnamento prevede, per ciascun CFU, 5 ore di didattica erogativa, dunque per un totale di 6x5 = 30 ore corrispondenti a 15 videolezioni. Ciascuna videolezione esplicita i propri obiettivi e argomenti, ed è corredata da materiale testuale in pdf.
Alcune videolezioni sono più teoriche con lo scopo di far conoscere le funzionalità principali nei sistemi software per automotive. Altre videolezioni hanno un carattere più pratico al fine di favorire la capacità di applicare le conoscenze teoriche da parte dello studente, presentando anche esempi di scelte effettuate per la realizzazione software per automotive. A tal riguardo, si presenteranno confronti di metodi di sviluppo al fine favorire l’apprendimento e di rendere in parte autonomo lo studente nella selezione del metodo più adatto per sviluppo di software per automotive. In entrambi i casi si farà uso di metodo adeguato agli argomenti trattati.
Didattica interattiva
L'insegnamento segue quanto previsto dalle Linee Guida di Ateneo sulla Didattica Interattiva e l’interazione didattica, e propone, per ciascun CFU, 1 ora di Didattica interattiva dedicata alle seguenti e-tivities: interazioni studente-tutor ad es. dedicate a FAQ, interazioni docente-studente (ad es. miglioramento interattivo di artefatto e probem solving, vedi poi) in cui  il docente con interazioni sia sincrone che asincrone (vedi poi) dà un feedback formativo ove valuta il livello di apprendimento degli argomenti del corso, raccoglie i dubbi e fornisce chiarimenti ed eventuali approfondimenti in base alle scelte effettuate e alle difficoltà riscontrate.

Modalità di verifica dell'apprendimento

L’esame si svolge in forma scritta. Il punteggio della prova è espresso in trentesimi.
La prova scritta ha una durata massima di 180 minuti e consiste nel sottoporre allo studente una serie di domande a risposta aperta sugli argomenti del corso alle quali lo studente dovrà rispondere producendo un relativo artefatto. Le domande richiedono la spiegazione o la descrizione dei temi trattati, e mirano a dimostrare la conoscenza e comprensione delle metodiche previste dal corso e la capacità dello studente di applicare tali conoscenze allo sviluppo di un caso di studio.
Al fine di valutare il conseguimento degli obiettivi formativi del corso, il docente terrà conto, nella valutazione dell’artefatto prodotto dallo studente: 1) della capacità di esporre l’argomento richiesto; 2) della padronanza di linguaggio dello studente; 3) della capacità di applicare le funzionalità nella progettazione del caso richiesto e 4) di valutare in modo appropriato le scelte delle metodiche a situazioni reali.
Per superare l’esame, lo studente deve superare con almeno sufficienza i punti da 1) a 4) di cui sopra. Ove questo non avvenisse, ma l’artefatto prodotto dallo studente si mostrasse recuperabile, più che bocciare lo studente si instaura una serie di interazioni docente-studente intese sviluppare nello studente le capacità di apprendimento che gli consentano di comunicare in modo chiaro e continuare a studiare in modo autonomo, come sopra indicato in Dublino 4 e 5. In particolare, il docente invia allo studente, via-email, l’artefatto con una serie di osservazione al margine in cui gli evidenza gli errori commessi e lo invita a produrre e restituire via-email una versione corretta dello stesso. Ciò può avvenire una o più volte, sino a raggiungimento di un artefatto di valore sufficiente. Ciò sia con interazioni sia asincrone (email) che sincrone (telefoniche o frontali) sino a raggiungimento di un artefatto di valore sufficiente.
Lo studente può scegliere (facoltativamente) una modalità di valutazione basata su prove in itinere (o di verifica e autoverifica intermedie) che, se superate, valgono come esonero della relativa parte programma del corso. In tal caso, come appresso specificato nel dettaglio delle modalità di verifica, l’esame verterà soltanto sulla parte rimanente del programma. Dette prove consentono allo studente di giudicare il livello di preparazione raggiunto e colmare lacune eventualmente accumulate. Anche qui, si instaura una serie di interazioni docente-studente (asincrone e sincrone) con correzioni dell’artefatto e sua restituzione corretta, intese sviluppare nello studente le capacità di apprendimento della materia che gli consentano di comunicare in modo chiaro e continuare a studiare in modo autonomo, come sopra indicato in Dublino4 e 5.
Più in dettaglio, le modalità di verifica dell’apprendimento prevedono quanto segue:
Prove in itinere (o di verifica e autoverifica intermedia).
Esistono due Tipi di prove in itinere.  Esse valgono come esonero di una parte del programma d’esame. Lo studente può scegliere di presentarsi all’esame solo dopo aver superato entrambi i tipi, oppure uno solo dei due, oppure nessuno dei due.
Prova in itinere di Tipo 1 - Studio del contenuto di un articolo su sicurezza e affidabilità del software-automotive e suo inquadramento nelle nozioni sudiate nel Testo n.1.
E’ facoltativa ma, per lo studente che la supera, vale come esonero della parte di programma che riguarda il Libro di Testo n.1.
Prova in itinere di Tipo 2 - Risposte a quesiti e progetto del testing stastistico di un prodotto software e stima della sua affidabilità.  
E’ facoltativa ma, per lo studente che la supera, vale come esonero della parte di programma che riguarda i Capp. 3, 4, 6, 7 del Libro di Testo n.2 (modelli dinamici di affidabilità, modelli “time between failures”, statistical testing, calcolo parametri modelli dinamici).
Prova d’esame
L’esame prevede che lo studente sia preparato a dare risposte alle seguenti 3 classi di quesiti:
  • A) Quesiti relativi al contenuto di un articolo su sicurezza e affidabilità del software-automotive e suo inquadramento nelle nozioni sudiate nel Testo n.1.
  • B) Quesiti relativi ai Capp. 1, 2, 8, 9, 10, del Libro di Testo n.2 (modelli statici di affidabilità, calcolo affidabilità a componenti multipli, ingegneria dell’affidabilità software, ingegneria della sicurezza software).
  • C) Quesiti relativi ai Capp 3, 4, 6, 7 del Libro di Testo n.2 (modelli dinamici di affidabilità, modelli “time between failures”, statistical testing, calcolo parametri modelli dinamici).
Allo studente che non ha superato nessuna delle 2 prove in itinere, è richiesto di rispondere alle classi A e C di quesiti.
Allo studente che ha invece superata la sola prova in itinere di Tipo 1, è richiesto di rispondere alla classe C di quesiti.
Allo studente che invece ha superata la sola prova in itinere di Tipo 2, è richiesto di rispondere alla classe A di quesiti.
Allo studente che ha superata sia la prova in itinere di Tipo 1 che quella di Tipo 2, è richiesto di rispondere alla classe B di quesiti.

Libri di testo

Oltre alle lezioni realizzate dal Docente ed ai materiali didattici pubblicati in piattaforma, è obbligatorio lo studio dei seguenti testi:

 Testo 1

  • J.Schauffele, T. Zurawka, "Automotive Software Engineering", SAE International, Warrendale, Pa, USA (copre i punti da 1 a 6 dei contenuti dell’insegnamento e la Prove Itinere di Tipo1). Da studiare nelle parti che seguono:
    • Cap 1 tutto
    • Cap 2 pp 39-51, e 84-114
    • Cap 3 tutto
    • Cap 4 tutto
    • Cap.5 pp 211-266 e 306-318

Testo 2

  • G. Iazeolla “Affidabilità e Sicurezza del Software”, Franco Angeli, 2013, Capp 1, 2, 3, 4, 6, 7, 8, 9, 10 (copre punti 7, 8, 9, 10 dei contenuti dell'insegnamento, la Prova Itinere di Tipo2 e la Prova d'esame).

Ricevimento studenti

Previo appuntamento tramite via email (g.iazeolla@unimarconi.it).