Model Based Design per lo sviluppo e la verifica di moduli ...Blocco di Logica in cui sono...

1

Politecnico di Torino, Centro Polifunzionale Lingotto – 11 Dicembre 2008

Model Based Design per lo sviluppo e la verifica di moduli software in ambito Automotive

Roberto Sobrito, Software Engineer - FIAT Group Automobiles

Antonio Marino, Test Engineer - FIAT Group Automobiles

Automotive SPIN Italia - 4° Workshop on Automotive Software

FGA Software Factory - Model Based Design 211 Dicembre 2008

MODEL BASED DESIGN Moduli software in ambito Automotive

Presentazione del gruppo di lavoro

L’approccio Model Based Design per lo sviluppo del software

Verifica e validazione

Applicazioni reali: Risultati & Sviluppi

Agenda

2


Presentazione del gruppo

La progettazione e sperimentazione di soluzioni tecniche, architetture, sistemi, componenti e l’innovazione tecnica di Fiat Group Automobiles (FGA) è affidata all’ente Engineering & Design.

In particolare lo sviluppo di tutte le architetture elettrico/elettroniche all’interno del veicolo è svolto dal team Electronic Architectureche provvede inoltre alla standardizzazione di tutti gli aspetti hardware, software, di reti e diagnosi.

In questo contesto, il team Software Factorysviluppa e verifica software applicativo per centraline veicolo.


Descrizione sistema veicolo

ECU: Electronic Control Unit

Centraline a bordo del veicolo

Rete di comunicazione tra le centraline

Applicativo SW 1

Applicativo SW 2

Applicativo SW n

ECU

3


Struttura architetturale proposta dal consorzio per una centralina

Architettura del Software

Microcontroller

Basic Software Layer (BSW)

Application Layer

AUTOSAR Runtime Environment (RTE)

AUTOSARInterface

ApplicationSoftware

Component

ApplicationSoftware

Component

..............

AUTOSARSoftwareAUTOSAR

InterfaceAUTOSARInterface

AUTOSARInterface

Con metodologia Model Based Design (MBD) vengono sviluppatiapplicativi relativi a funzionalità in ambito BodyComputer.Ogni Application SW Component (SWC) racchiude una parte dialgoritmo funzionale.L’AUTOSAR SWC comunica con le altre funzionalità/componenti e con i servizi del Basic Layer (BSW) attraverso lo strato RTEnecessità di standardizzazione delle interfacce

ApplicationSoftware

Component

ApplicationSoftware

Component


Ciclo a V di sviluppo del SW per centralina ECU

RequirementsAnalisi dei requisiti di ECU

Coding-Implementazione SW Applicativo-Implementazione Basic SW

System TestVerifica a livello di ECU

Architecture- Definizione dei sottosistemi (ovvero le diverse funzionalità)- Specifica delle Interfacce trasottosistemi

Attività svolte dallaFGA SW Factory

Subsystem IntegrationIntegr. SW Applicativo con BSW

Integration TestVerifica Interfacce trai vari sottosistemi

4


Ciclo di sviluppo e tracciabilità del SW Applicativo

Project Planning

Configuration Management

Sw Quality Assurance

RequirementsAnalisi dei requisiti

ArchitectureDefinizione dei sottosistemi della funzionalitàSpecifica delle Interfacce

Model Based DesignImplementazione modello Simulink/Stateflow

Auto CodingGenerazione automatica codice C

Code ValidationSoftware in the Loop (SIL) test (Automatic)

Model ValidationModel in the Loop (MIL) test (Manual/Automatic)


Model Based Design per lo sviluppo del SW

Vantaggi del MBD

Analisi dei requisiti

Struttura del modello

Vincoli di modellazione

Interfaccia grafica

Generazione di codice

5


Vantaggi del Model Based Design

Vantaggi del MBD rispetto all’approccio di design tradizionale:

Irrobustimento e maggior definizione della specificaRiduzione del rischio di errori e accorciamento del ciclo di sviluppo consentendo l’applicazione dei test per verifica e validazione già durante lo sviluppo e prima dell’integrazione.Riutilizzo dei modelliRidotta dipendenza dai prototipi fisici piattaforma di integrazione non necessariaPossibilità di valutare più rapidamente soluzioni di design diverse in termini di performance e affidabilità migliora la qualità del SW

Riduzione dei costi di design e dei tempi di sviluppo (Time to market)


Analisi critica delle specifiche funzionali (database Doors ) eventuale modifica/irrobustimentoClassificazione dei requisitiScelta architetturale a livello applicativo: decomposizione della funzionalitàin SWCs modelli Definizione delle Interfacce tra i vari SWCs e il livello RTE (inclusi i Timer): documento basilare condiviso con il fornitore di centralina/integratore del SW applicativo SW SW ComponentComponent ConfigurationConfiguration

Analisi dei requisiti e decomposizione dei moduli

DatabaseSpecifiche

SWComponentSWComponentConfigurationConfiguration

RTE

ApplicationInterface

ApplicationSoftware

Component

6


Struttura del modello – Top Level

La struttura del modello inSimulink si compone al livello piùelevato di due macro blocchi:

Blocco di Logica in cui sono sviluppate le logiche della funzionalità (dal livello Applicativo sino al Basso livello)Blocco Boundary che alloggia l’interfaccia grafica per l’interazione con l’utente, ovvero la visualizzazione delle uscite e la stimolazione degli ingressi

Logic

Boundary


Modello – Logica (1/2)

Il principale sottosistema Simulink racchiuso all’interno del blocco dilogica contiene il livello applicativoe si identifica con il SWC.

Ad esso arrivano tre tipologie di ingressi:1. Gli eventi di trigger

provenienti dal livello RTE2. Gli ingressi di dato della

funzionalità3. Le scadenze dei timer

(“expiration”)

Premessa: le logiche sviluppate per il BodyComputer sono tipicamente logiche ad eventi, ovvero l’applicativo viene “risvegliato” solo a fronte di una variazione su uno degli ingressi.

SWCTimer

RTE trigger

Data inputs

7


Modello – Logica (2/2)

I blocchi che provvedono la simulazione del basso livello (BSW), necessari per chiudere il loop di simulazione sono essenzialmente:

- il blocco di generazione degli eventi risveglianti per l’applicativo (FunctionCall generation).Rappresenta le chiamate effettuate dal livello RTE dell’architettura

-il blocco di implementazione degli allarmi (servizi temporali provvisti nella realtà dal sistema operativo) necessari all’applicativo. Le chiamate a tali servizi sono effettuate a livello di applicativo con delle funzioni.Tale blocco provvede anche i segnali di scadenza dei timer.

eventi “risveglianti” per l’applicativo

Segnale di scadenza di un timer


Interfaccia grafica utente

Viene realizzata nel blocco di BoundaryViene utilizzato il tool grafico Altia(integrato attraverso opportuna libreria in Simulink) che permette una percezione immediata del corretto funzionamento della logica attraverso la stimolazione diretta degli ingressi e la visualizzazione delle uscite.

N.B. Non sostituisce la fase di validazione vera e propria del modello a carico del test engineer

Output dal modello

Input al modello

8


Vincoli di modellazione (1/2)

Alcuni aspetti sono: Utilizzo dei ControlFlow e logica combinatoria ove possibileRiduzione del numero degli stati in StateFlowUtilizzo di Strong Data Typing nel modello

Eliminazione degli stati superfluie uso dei Control Flow

Obiettivi: rispettare i target di occupazione di memoria all’interno della centralina (in termini di Rom e Ram)Ottenere la stessa efficienza del codice scritto a mano

Si devono applicare già in fase dimodellazione dei concetti volti allamassima ottimizzazione del codicegenerato.


Vincoli di modellazione (2/2)

Logica combinatoria

StateFlow e uso dei Timer

Set del timer

Cancel del timer

Scadenza del timer

9


Generazione automatica del codice

SWComponentConfiguration

Conversione del modello da Simulink

a TargetLink

TargetLink DataDictionary

Applicazione Macro al modello TargetLink

AutogeneratedC CODE files

TargetLink CODE

Generation

Attraverso l’utilizzo di macro e il generatore di codice TargetLink si ottiene il codice C da consegnare al fornitore per l’integrazione con il Basso Livello

Macro daSWCC a DD


Testing Area – V&V per applicativi MBD

Tipologie di test

Processo di verifica

Struttura di un test case

Linee Guida per la scrittura di un test case

Validazione funzionale di un modello Simulink

“...Opendriver door…”

Definizione e traduzione del test

Verifica e validazione

10


SW Engineering

Testing Area – Attività di test

LIVELLO DEI TEST

Unit Test Test di integrazione Test di Sistema

Verifica il funzionamento singolo delle parti di software che possono essere testate. Questa tipologia di test è relativa a sottosistemi quali moduli, classi o funzioni.

È il processo che verifica l’iterazione tra più componenti software.

È relativo al comportamento del sistema nel suo complesso. In questa categoria sono verificate le interfacce esterne con altre applicazioni sia hardware che software.


Testing Area – Processo di validazione

Scrittura TEST CASE

Ingressi per il modello

SWC Simulink/Stateflow Uscite del

modello

+

-

Differenze

Sì

No Modello validato

Uscite Desiderate

Signal Builder Simulink




Utilizzo di EXCEL

11


Testing Area – Linee guida per la stesura di un test case

In un modello funzionale si considerano 3 diverse tipologie di test:

1. Requisiti Nominal2. Requisiti Fault3. Requisiti Misuse

I primi rappresentano tutti gli aspetti nominali che il SWC deve ricoprireper soddisfare la funzionalità.I Test di Fault consistono nel testare che, in condizioni di funzionamentodifettoso degli elementi a contorno, il SWC sappia gestire il difetto equindi la nuova situazione. Infine i test case della classe Misuse servono a verificare alcunerichieste da parte dell’utente poco probabili.


Testing Area – Scrittura dei Test Case – Excel

12


Testing Area – Scrittura dei Test Case – Excel


Testing Area – Realizzazione Signal Builder

Signal Builder: generatore di segnali in Simulink, contiene la sequenza temporale del test impostato in Excel.Si utilizza un programma scritto in Matlab, per trasformare le sequenze di Test generati in Excel, in un unico Signal Builder.

Applicativo MATLAB

13


Testing Area – Generazione del Signal Builder

Strumenti di lavoro utilizzati

Macro Matlab scritta in linguaggio M.

Generate Signal Builder


Testing Area – Realizzazione Signal Builder

Due Signal Builder generati: uno contenente l’evoluzione temporale degli ingressi, ed un altro contenente i valori attesi delle uscite istante per istante.

14


Testing Area – Simulazione del modello

Generato il Signal Builder (SB), si integra il blocco Simulink nel modello da testare, in particolare nella parte “Boundary”.L’integrazione del SB viene fatta in automatico.

Integrazione Signal Builder IN

Applicativo MATLAB

Boundary



Si esegue una simulazione automatica del modello del SWC con gliingressi generati dai test case.Si registrano le uscite reali in formato Signal Builder.

Software Component

Simulazione e verifica del Test applicata al modello

Boundary Element

Applicativo MATLAB

15



Finita la simulazione, si registrano le uscite reali (del SWC) in formato Signal Builder e le si confrontano con le uscite attese, quelle definite in fase di scrittura del test (Excel).

Applicativo MATLAB


Testing Area – Validazione

Confronto tra le uscite reali (Signal Builder OUT) e le uscite attese (Signal Builder OUT generato dai test case, di riferimento)

Uscite Reali Uscite Attese

Differenza

16


Testing Area – Validazione

Dall’analisi del Signal Builder delle differenze si trovano i malfunzionamenti (bachi) del SW Component. Il Test Engineer traccia e segnala al modellatore le anomalie. Il modellatore corregge i malfunzionamenti riscontrati.Una volta corretti i difetti, la differenza tra uscite REALI e uscite ATTESE ènulla.A tal punto il modello si definisce validato, ossia soddisfa tutti i requisiti richiesti dalla funzionalità.

Validazione di “non regressione”

Se un modello già validato, subisce delle modifiche in uno o piùsottosistemi che lo compongono, si rieseguono gli stessi test utilizzati per il modello precedente sui rimanenti sottosistemi rimasti immutati. Successivamente si confrontano i risultati con quelli ottenuti nella validazione precedente: gli output di quest’ultimi sottosistemi devono essere gli stessi in entrambi i casi. I sottosistemi inalterati si dice che “non regrediscono”.


Analisi della specifica funzionale.

Segnalazione eventuali punti non chiari / irrobustimento della specifica.

Gestione tracciabilità tra Test Case e requisiti (Doors )

Realizzazione e rilascio Test Case.

Esecuzione dei Test Case e validazione a livello Simulink del modello realizzato dal Software Engineer.

Realizzazione e rilascio Test Report.

Compilazione bug-list.

Definizione, mantenimento e aggiornamento del piano di test.

Testing Area – Riepilogo

17


Software Factory ha finora sviluppato e validato i seguenti applicativi integrati su progetti reali (vetture già in produzione e prossimi lanci):

Progetti reali: Risultati & Sviluppi

FunzionalitàFunzionalità

• Sbrinamento Lunotto Posteriore

• Monitoraggio Stato Alternatore

• Gestione Temperatura Esterna

• Luci Interne

• Luci Esterne

• Selettore Alfa DNA(Dynamic Normal All Weather)

• Stop & Start

• Sistema Tergitura e Lavafari

• Gestione Telecomando

• Gestione Chiusura Centralizzata

• Indicazione Livello Carburante

VetturaVettura

• Nuova 500

• Fiorino

• Alfa MiTo

• Nuova Alfa 147

• Nuovo Doblò

• Grande Punto (restyling)

• Nuova Lancia Y

• Nuova Panda


Approfondimenti

Domande, dubbi?

18


Contatti

Grazie per l’attenzione!

Roberto Sobrito, FIAT Group Automobiles, e-mail [email protected]

Antonio Marino, FIAT Group Automobiles, e-mail [email protected]

Date post:	04-Mar-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Model Based Design per lo sviluppo e la verifica di moduli ...Blocco di Logica in cui sono...

Documents