Ingineria programarii I

Curs 3
Modelul de dezvoltare in cascada de tip Ciclu V

<Ingineria programarii I>

Modelul de dezvoltare in cascada de tip Ciclu V <Gabriela Varvara>

Obiectiv general curs 3:

prezentarea detaliata a modelul “Ciclul in V” ca forma particulara de dezvoltare in

cascada pentru sisteme incorporate:

Obiectivul 1: Prezentarea motivatiei introducerii modelului ciclului in V

Obiectivul 2: Prezentarea procesului de dezvoltare de tip ciclu in V
Obiectivul 3: Prezentare avantaje/dezavantaje model

S bi
Subiecte tratate: modelul
d l l ciclului
i l l i iin V

Page 1
 <Ingineria programarii I>
Modelul de dezvoltare in cascada de tip Ciclu V <Gabriela Varvara>

Motivatia introducerii modelului

Unele clase de aplicatii software solicita folosirea de procese software puternic

controlate:

Sistemele critice din punct de vedere a sigurantei si a mediului

Sistemele complexe din punct de vedere al functionalitatilor si mediului de operare
Aplicatiile comerciale ce implica atentie sporita la costuri
Aplicatii cu cerinte extrem de severe din punct de vedere al trasabilitatii, intretinerii,
modificarii pe termen lung, documentarii

S l acestor
Scopul t procese de
d d lt
dezvoltare:
Atingerea unor standarde inalte de calitate
Favorizarea certificarii produselor
Reducerea timpului de punere in piata

<Ingineria programarii I>

Modelul de dezvoltare in cascada de tip Ciclu V <Gabriela Varvara>

Exemplu practic

Controlerul Ctrl trebuie sa pastreze nivelul de fluid in rezervor

intre 2 valori: Lmin si Lmax
Ctrl citeste in mod continuu nivelul de la un senzor analog/digital
pe 16 biti
Ctrl activeaza/dezactiveaza un releu ce inchide/deschide valva
de alimentare a rezervorului

S
Solutie:
Comportarea sistemului este divizata in 2 functii: CitesteNivel si ActiveazaReleu
CitesteNivel va fi rezolvata de echipa1 si ActiveazaReleu de echipa de dezvoltare 2
Se livreaza documentul de cerinte pentru fiecare echipa

Page 2
 <Ingineria programarii I>
Modelul de dezvoltare in cascada de tip Ciclu V <Gabriela Varvara>

Rezultat echipa 1:

Rezultat echipa 2 :

<Ingineria programarii I>

Modelul de dezvoltare in cascada de tip Ciclu V
<Gabriela Varvara>

Main – se concateneaza rezultatele

Concluzii:
Sistemul satisface cerintele
Sistemul esueaza in faza de executie

Unitatile de masura sunt diferite!!

Page 3
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Motivatii legate de punerea pe piata si costuri ale dezvoltarii

Aplicatiile software folosite in sistemele incorporate (dezvoltari pe scara mare)

vor trebui sa ia in considerare aspecte comerciale si de piata cum ar fi:

Timpul de dezvoltare – timpul necesar pentru a dezvolta produsul pana la

punerea sa pe piata. In acest sens exista constrangerea timpului mediu
pana la punerea pe piata ce, pentru majoritatea produselor, este in jur de 8
luni.
F t de
Fereastra d piata
i t – perioada
i d ini care produsul
d l inregistreaza
i i t l maii marii
cele
vanzari
Costurile erorilor de dezvoltare (cresc exponential odata cu cresterea
timpului de dezvoltare).

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2
<Gabriela Varvara>

Motivatii legate de probleme tehnice de dezvoltare

Absenta specificatiilor de cerinte

Mici variatii ale cerintelor au impact insemnat asupra codului
Imposibilitatea detectarii erorilor de proiectare si implementare in fazele timpurii
de dezvoltare
Cod ineficient, cu fiabilitate scazuta, greu de intretinut
Dificultati mari in stabilirea cu precizie a nevoilor clientilor

Page 4
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2
<Gabriela Varvara>

Modelul Cascada/ Procesul ciclului in V

Rezolvarea p g
problemelor modelului in cascada legate p
de dezvoltari complexe si /sau
critice a fost realizata odata cu elaborarea unui tip novator de proces la care s-au
adaugat dezvoltari metodologice adecvate:

Rezolvarea problemelor de tip Code & Fix

Model cascada / Versiune Ciclu in V

Metode formale

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

10

Page 5
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2
<Gabriela Varvara>

Forma revizuita – permite reveniri in pasul anterior

11

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2
<Gabriela Varvara>

Forma particulara a Modelului Ciclul in V

pentru dezvoltari din domeniul “automotive”

Coordonatele ciclului:
x- fluxul activitatilor din proces
y- echipament tinta / PC hardware

De exemplu, la inceputul procesului de dezvoltare proiectarea functionala este

data sub forma unei aplicatii matematice (ex. Schema Simulink) pe calculator.

12

Page 6
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2
<Gabriela Varvara>

Realizarea rapida a prototipului de control

( Rapid Control Prototyping – RCP)
Permite inginerului iterarea rapida si testarea propriilor strategii de control folosind
aplicatii de timp-real cu intrari/iesiri din procese externe calculatorului.
Este o varianta de hardware-in-the-loop pentru care
strategia de control este simulata pe sistemul real
si in timp real.

Aplicabilitate: in special in industria vehiculelor

terestre (trenuri, autovehicule), in aviatie,
dezvoltare de dispozitive in medicina,
automatizari industriale de tip servo-mecanisme.

13

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Realizarea rapida a prototipului de control

( Rapid Control Prototyping – RCP)
Componentele unui sistem RCP tipic sunt:
Un program de modelare, cum ar fi Simulink
Un bloc I/E pentru dezvoltare de timp real pentru Simulink
Un calculator ţintă de timp real. Acesta este, de regulă, un sistem embedded cu intrări/ieşiri analogice, numerice şi
comunicare seriala.
Un PC gazdă cu legătură de comunicare cu calculatorul ţintă.
O aplicaţie interfaţă grafică pentru încărcarea şi controlul proceselor în timp real.

14

Page 7
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Procedura tipica de dezvoltare

15

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2
<Gabriela Varvara>

Procedura tipica de dezvoltare

Procedura de dezvoltare se derulează în următorii paşi:
Strategia de control se dezvoltă cu ajutorul mediului de modelare simbolic
Simulink
Blocurile de I/E simbolice sunt importate în modelul matematic şi ataşate
punctelor I/E ale acestuia. Astfel, se vor adăuga facilităţi I/E strategiei de
control adoptate
Se invocă procesul de build ce va presupune:
Se va citi modelul şi va fi generat codul C
Codul C este compilat şi legat (linkeditare) cu cod specific ţintei de timp
real cum ar fi programatorul, rutinele I/E şi de comunicare.
Rezultatul final este un program executabil pentru calculatorul ţintă
Prin intermediul unei interfeţe grafice, executabilul este încărcat pe ţintă.
Acum programul poate fi controlat şi înstrumentat prin GUI. Acest lucru
poartă denumirea de control experimental.

16

Page 8
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2
<Gabriela Varvara>

Generare automata de cod executabil

17

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2
<Gabriela Varvara>

Avantajele folosirii generatoarelor automate de cod in mediile de

simulare
Generatoarele automate de cod sunt aplicaţii PC ce citesc fişierele cu modele matematice şi
generează cod ce poate fi compilat şi care replică comportamentul modelului. Codul C rezultat va fi
integrat în cadrul unităţii electronice de control (ECU – electronic control unit) de către utilizator
Realizeaza scalarea valorilor folosite in model
Permit executia de cod si compararea performantelor cu rezultatele modelului vizual ( software-in-
the-loop)
Permit crearea automata a codului executabil pentru fiecare modul si integrarea modulelor

18

Page 9
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Simulare in timp real ( Hardware-in-the-loop)

Avantaje: permite testarea ECU in bucla inchisa, fara deteriorare de echipamente de executie si ale
l i sau afectarea
procesului f t t l i uman, detectare
operatorului d t t id a erorilor
rapida il
Componente: model proces, model senzori, calculator tinta cu I/E si raspuns in timp real, incarcari
reale sau simulate, matrice releu pentru introducere defecte, calculator gazda cu comunicare cu
calculator tinta si legatura de diagnoza cu ECU, interfata grafica, aplicatie de testare automata.

19

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Componentele unui sistem HIL tipic

20

Page 10
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Componentele unui sistem HIL tipic

Un model matematic al procesului (ex. Motor).

Modelele senzorilor
Calculator/calculatoare tinta de timp real cu I/E.
Incarcari reale sau simulate
Mecanism de inserare a defectelor
Un PC gazda prevazut cu legatura de comunicare cu calculatorul tinta si legatura de
diagnostic cu ECU.
O aplicatie GUI pentru incarcarea si controlul procesului in timp real
O aplicatie ce automatizeaza toate aspectele testarii

21

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Componentele unui sistem HIL tipic (1)

¾Modelul – de regula Simulink, de timp real. Poate fi sintetizat pentru scopul curent sau procurat pentru un
proces tipic si adaptat. Scopul standard al modelului este testarea ECU; in acest caz modelul poate fi mai
putin elaborat. Precizia modelului va creste daca se doreste dezvoltarea capabilitatilor de control ale ECU in
raport cu modelul ( ex. daca se doreste dezvoltarea unei noi strategii de injectie multipla de carburant pentru
un motor diesel, modelul va trebui sa reactioneze la toate impulsurile in alimentarea cu motorina).
¾Modelul senzorilor – probleme apar cu senzorii reali ce au un comportament neliniar in raport cu semnalul
de intrare. In anumite limite, neliniaritatea poate fi compensata prin ECU. Pentru a obtine performante
sporite se impune introducerea in model si a formelor de transfer prin senzori. Pentru senzori cu raspuns
lent, modelul poate fi stabilit dinamic. De regula, insa, modelul senzorilor este dat sub forma tabelara
deoarece raspunsul este mult mai rapid decat constantele de timp ale procesului. Exista sisteme HIL ce au
un procesor dedicat exclusiv modelarii senzorilor, in vederea decuplarii modelului acestora de modelul
procesului.
¾Tinta real-time si I/E – sistemele HIL folosesc calculatoare embedded cu sisteme de operare de timp real
pentru executia modelelor. Astfel se decupleaza aspectele de executie in context RTOS de cele de control
p
HIL. Intre calculatoarele incorporate si sistemul I/E comunicatia se desfasoara p
prin bus-uri VME, PCI, PXI
sau proprietar.
¾Incarcarea – poate fi reala (ex. Injector de combustibil cunoscut) sau simulata (retea de inductante si
rezistente ce simuleaza raspunsul in frecventa al unui injector). Este specifica clientului si satisface cerintele
echipamentului ECU testat. Exista pe piata placi pentru care customizarea se face rapid prin prin selectie si
reglare de componente de tip R, L, C.

22

Page 11
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Componentele unui sistem HIL tipic (1)

¾Introducerea de erori – majoritatea timpului de testare a unui sistem HIL este dedicat verificarii capabilitatii
de detectie a erorilor de catre ECU. ECU din industria auto moderna au alocata pentru aceasta sarcina
jumatate din memorie. Elementul cheie consta in introducerea de erori (caderi tensiune, scurtcircuit,
intreruperi in circuite, caderi de sensori si actuatori). Pentru simularea acestora se foloseste o matrice releu
interpusa intre HIL si ECU (vezi figura din slide 20), controlata de PC gazda (permite testare manuala sau
automata). Legatura cu PC depinde de furnizor, desi adesea este folosit Controller Area Network, ce oricum
este folosit de sistemul HIL.
¾PC gazda - permite accesul la controller prin GUI, rularea aplicatiilor de control, controlul componentelor
sistemului HIL (comutare matrice introducere erori), diagnosticare ECU, dezvoltare/modificare modele si
teste, colectare/raportare/memorare rezultate teste. Legatura intre PC si sistemul de timp real este, de
regula, de tip Ethernet, dar pot fi folosite si conexiuni seriale de viteza mare sau proprietare.
¾Aplicatia de testare a controlului - este o aplicaţie ce poate fi construită în cadrul interfeţei grafice sau ca
aplicaţie de sine stătătoare. Furnizează toate facilităţile testării automate, prin autorizarea execuţiei secvenţei
de testare ce poate fi un script în Visual Basic sau Phython sau o diagramă flowchart simbolică. Testarea
p HIL nu p
controlulului de tip presupune
p un limbajj standard.
¾Sistemele HIL sunt complexe, scumpe şi presupun o implicare a companiei la nivel global pentru a
avea success. Automobilele bazate exclusiv pe sisteme HIL multi-ECU au costuri ce pot depăşi 1
milion $. Capabilitatea de testare automată face posibilă execuţia suitelor de test pe fiecare
componentă software ECU cu o economie de timp apreciabilă pentru procesul de evaluare.
Actualmente HIL reprezintă metoda de management pentru testarea software a ECU.

23

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Calibrarea – proces de optimizare (tuning) pe algoritmii de control

Calibrarea şi structura iniţială de control sunt stabilite în RCP. Urmează o fază de

codificare (manuală sau automată). Ulterior algoritmul va fi optimizat prin procesul de
calibrare.

Cazuri de calibrare:
Pentru senzori – automobilele folosesc diferite tipuri de senzori ce au la bază variaţii de
masă, presiune, temperatură, etc. Fiecare tip are un răspuns unic. Calibrarea vizează
căutarea răspunsului liniarizat adecvat în tabela de căutare aferentă senzorilor pentru un
anume tip de vehicol.
Performanţă – se poate realiza o calibrare prin optimizarea puterii de ieşire în raport cu
consumul de combustibil.
Constante – folosirea de diferite componente pentru un automobil impune schimbarea
constantelor folosite in algoritmul de control (de exemplu folosirea unor roti cu diametrul mai
mare va determina modificari in calculul vitezei de rulare).

24

Page 12
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2
<Gabriela Varvara>

Calibrarea – proces de optimizare (tuning) pe algoritmii de control

ƒ Un sistem de calibrare de bază constă dintr-o interfaţă cu ECU si o conexiune cu PC-ul
gazdă pe care există şi o aplicaţie software specifica.
ƒ Sistemele mai evaluate pot conţine suplimentar
ƒ un conector de retea ((hub)) p
pentru p
preluarea semnalelor de la masină p
prin intermediul
unor module de achiziţie de date de tip CAN.
ƒ Interfatarea cu ECU este de tip CAN (Controller Area Network) dacă se foloseşte o
metodă de calibrare bazată pe CAN, sau un emulator ROM dacă se foloseşte o metodă
de calibrare cu acces direct la memorie.
ƒ Legătura cu PC se realizează prin CAN, USB, Ethernet sau altă metodă adecvată.
Aplicatia de pe PC este de regulă MS-Windows®.

25

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Calibrarea - interfata cu ECU prin emulator ROM

Este aleasă pentru ECU ce folosesc memorie multă pentru calibrare, cum ar fi
controllerele pentru motor sau pentru unităţile de transmisie.
Această metodă are drept principal beneficiu viteza. Emulatorul ROM este conectat fizic la
bus-ul microcontrollerului de pe ECU. Memoria necesară calibrării este mapată în
exteriorul ECU pe ROM
ROM. Viteza mare de comutare a seturilor de parametri este realizata
prin comutarea intre bank-urile de memorie cu variabile de calibrare. In plus, procesorul
nu va fi afectat de procesul de calibrare, despre a carui existenţă nici nu va şti.
Partea slabă a metodei rezidă in caracterul invaziv al memoriei ROM, în sensul că aceasta
va trebui să se conecteze la bus-ul de date al ECU.

26

Page 13
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2
<Gabriela Varvara>

Calibrarea – interfata CAN cu ECU

Aceasta interfata este conectată la un port CAN al ECU. Este dependentă de o rutină
serviciu a calibrării rezidentă pe ECU ce manipulează memoria de calibrare. Aplicaţia de
calibrare de pe PC comunică cu ECU şi cu rutina de serviciu prin protocolul CCP (CAN
Calibration Protocol).
Avantajul acestei interfeţe este minima invaziune asupra hardului ECU
ECU. Este doar o
problema de conectare la bus-ul CAN. Uneori, pentru creşterea performanţei, se impune
un port CAN dedicat. De asemeni este şi cea mai ieftină metodă de calibrare deoarece nu
presupune existenţa unui emulator ROM.
Partea slabă a metodei – protocolul CCP şi rutina serviciu de calibrare se execută pe ECU,
apelând la ciclii procesorului acestuia. De asemeni există o limitare de bandă în achiziţia
şi memorarea datelor variabile deoarece ECU trebuie sa trimită această informaţie în
exterior pe bus-ul CAN.

27

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Calibrarea – aplicatia de calibrare

Este o aplicatie Windows ce permite următoarele acţiuni:
Citirea fişierelor cu date de calibrare – fiecare ECU îsi are propria localizare a memoriei
de calibrare, deşi există încercări de standardizare a arhitecturilor de acest tip. Pentru a
transmite aplicaţiei informaţii legate de calibrare vor fi folosite baze de date cu variabile,
numite “fisiere
fisiere de descriere ECU”
ECU , standardizate conform ASAM-MCD-2MC
ASAM MCD 2MC (pe scurt
ASAP2). Acestea conţin date despre variabile cum ar fi: tip, localizare în memorie, scalare,
unităţi de măsură. Datele pot fi memorate sau afişate explicit în aplicaţia de pr PC-ul gazdă.
Sistemele ce pot citi acest tip de fişiere se numesc “data-driven systems” deoarece sunt utile
doar în prezenta acestor fişiere.
citire/scriere/modificare – opţiuni complet explicate ce lasă utilizatorul sa modifice memoria
de calibrare. Operaţii mai rafinate sunt premise de anumite sisteme, cum ar fi comutarea
între zone inainte/după analiză sau mutarea unor întregi zone de memorie.
managementul seturilor de date – există browsere de date ce facilitează accesul
la/memorarea seturilor de calibrare.
inregistrare date – aplicaţia poate întregistra, corela şi afişa date din orice sursă accesibilă.
comutare – unele taskuri de calibrare sunt episodice şi de aceea cer surse/actiuni cu
declanşare. Un posibil declanşator îl poate constitui temperature lichidului de răcire, viteza,
etc. Actiunea asociată ar putea fi înregistrarea de date după impulsul declanşator.

28

Page 14
 <Ingineria programarii I>
Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2
<Gabriela Varvara>

Avantajele dezvoltarii de tip ciclu in V

Simplitate

Fiecare faza are livrabile specifice

Sanse de esec diminuate fata de model cascada – datorita planificarii testarii din
faze incipiente

Pretabil pentru proiecte mici cu cerinte clare si bine specificate

29

<Ingineria programarii I>

Capitolul 2: Modelul de dezvoltare in cascada de tip Ciclu V – curs 2 <Gabriela Varvara>

Dezavantajele dezvoltarii de tip ciclu in V

La fel de rigid ca si modelul cascada

Flexibilitate redusa; ajustarea scopului este dificila

Nu exista prototipuri executabile inaintea fazei de implementare

Modelul nu furnizeaza trasabilitatea problemelor aparute in fazele incipiente

30

Page 15