1

INTRODUCERE N
PROCESUL DE
PROIECTARE AL
SISTEMELOR EMBEDDED
2
PRINCIPALE OBIECTIVE
ALE METODOLOGIEI DE PROIECTARE
ofer posibilitatea pstrrii unei istorii / nregistrri a
rezultatelor etapelor proiectrii (util pentru documentare,
testare funcional, depanare)
permite dezvoltarea sau folosirea unor unelte de
proiectare asistat de calculator, i desfurarea n paralel
a proiectrii pentru diferite componente.
simplific comunicarea dintre membrii unei echipe de
proiectare.
3
ELEMENTE SPECIFICE
PROIECTRII EmS
Deciziile luate la proiectare se bazeaz pe re-
utilizarea unor componente ale proiectelor deja
existente
Strnsa interaciune dintre hardware i software.
Programatorii trebuie s neleag partea hardware iar
proiectanii de hardware trebuie s neleag partea
software
Utilizarea de blocuri funcionale fiecare proiectant
este responsabil att de hardware ct i de software
pentru o funciune, sau pentru un set de funciuni
4
ETAPE PROIECTARE
Deciziile luate la un anumit pas al proiectrii sunt bazate pe estimarea a ce
se va ntmpla mai trziu
Dac estimrile sunt inadecvate, trebuie s ne ntoarcem i s ndreptm
deciziile noastre iniiale, innd cont de noile evenimente
La fiecare etap a proiectrii se adaug detalii:
analiza proiectului la fiecare pas pentru a determina cum se
ndeplinesc specificaiile
rafinarea proiectului pentru a aduga elemente de detaliu
verificarea proiectul pentru a fi siguri c ndeplinete toate
obiectivele sistemului
5
PRINCIPALELE ETAPE N
PROCESUL DE PROIECTARE AL EmS
Etapa 1: Crearea arhitecturii
Etapa 2: Implementarea arhitecturii
Etapa 3: Testarea sistemului
Etapa 4: Furnizarea prototipului
Definirea cerinelor produsului
Elaborare specificaii funcionale
Crearea proiectului arhitectural
Furnizare versiune arhitectural
final
Implementare module
Verificare i punere la punct
Implementarea i integrarea
sistemului
Verificare i testare sistem n diferite
faze de implementare
6
Et.1: Crearea
arhitecturii
Definirea cerinelor
produsului
Analiza preliminar a
cerinelor
Crearea
proiectului
arhitectural
Furnizare versiune
arhitectural
Incorporare
feedback
Dezvoltarea
versiune
arhitectural
Verificare i feedback
Furnizare
versiune arh.
final
Elaborare specificaii
funcionale
Et. 2: Implementarea
arhitecturii
Imple-
mentarea
sistemului
Incorporare
feedback
Et. 3: Testarea
sistemului
Verificare
i testare
sistem
Etapa 4: Furnizarea
prototipului
Furnizare prototip
sistem
7
DEFINIREA PROBLEMEI I A
CERINELOR PRODUSULUI
Definirea produsului descrie ce va fi i ce va face acesta
Definirea cerinelor este primul pas al procesului, fiind cheia succesului n
proiectarea sistemelor electronice: documentaia
Documentaia descrie ce vei construi
Spune oamenilor de marketing ce produs vor avea de vndut, iar
grupului de ingineri cum s implementeze produsul.
Rezultatul acestei faze va fi o definire simpl a problemei, din punctul de
vedere al utilizatorului (beneficiarul)
Se va descrie problema, dar nu se vor sugera soluii
DA: Micarea vorbitorului nu va fi stnjenit de cablul microfonului
NU: Se va folosi un microfon wireless
Etapa 1: Crearea arhitecturii
8
CINE DEFINETE CERINELE ?
ntr-o companie foarte mare, definirea cerinelor
va fi fcut de ctre departamentul de
marketing, sau un client important
ntr-o companie mic schia de definire a
cerinelor se poate face de ctre inginerii software
i hardware
Pentru un proiecte mici, proiectantul definete
cerinele
Etapa 1: Crearea arhitecturii
9
CE TREBUIE DEFINIT CA CERINE ?
CERINE FUNCIONALE
Intrri i ieiri (interfaa cu utilizatorul i mediul)
Funcii i constrngeri de timp
CERINE NE-FUNCIONALE
Performan.
Costuri.
Consumul de putere.
Dimensiune fizic i greutatea.
Fiabilitate, siguran n funcionare, mentenabilitate
Etapa 1: Crearea arhitecturii
10
EXEMPLU DE FORMULAR DE
CERINE TIPICE
Nume
Scop
Intrri / Ieiri ctre lumea extern
Tipul datelor
Caracteristicile generale ale datelor
Tipuri de dispozitive de interfa cu utilizatorul
Funcii. Intrri FUNCII Ieiri
Performan
Costuri de fabricaie. Apreciere grosier, sau limit maxim.
Putere. Apreciere grosier, sau limit maxim (baterii / reea ?)
Dimensiune / greutate fizic
Etapa 1: Crearea arhitecturii
11
REZUMAT CERINE
Faz Rezultate
Definirea problemei de proiectare i elaborare cerine
Cercetare, analiz pia
Consultare utilizator. Culegere de informaii
generale de la clieni (utilizatori sau
beneficiari)
Cerine funcionale i nefuncionale
Cercetare
Definirea corect a problemei
Propunere cerine
Document (formular) de cerine
Crearea unui plan de testare


Etapa 1: Crearea arhitecturii
12
EXEMPLU: Hart GPS
Prelucrat dup Wayne Wolf, Computers as Components, Academic Press, London 2001

lat: 40 13 lon: 32 19
I-78
S
c
o
t
c
h

R
o
a
d

Poziia utilizatorului
n latitudine /
l i di
Poziia curent a
utilizatorului
13
EXEMPLU: Hart GPS
Este un dispozitiv portabil care afieaz
pentru utilizator o hart a terenului din jurul
poziiei curente a utilizatorului.
Harta afieaz modificrile corespunztoare
schimbrii poziiei utilizatorului, sau ale
dispozitivului de afiare a hrii.
Harta mobil obine poziia sa de la GPS
14
Hart GPS: Cerine iniiale
Funcionalitate: proiectat pentru utilizare n trafic auto i scopuri similare; nu
pentru utilizare nautic, sau aviaie, care necesit funciuni i baze de date
mai specializate. Sistemul va afia / indica principalele drumuri i alte puncte
de reper disponibile n bazele de date topografice standard.
Interfaa cu utilizatorul: Ecranul va avea cel puin rezoluia de 400 x 600 pixeli.
Dispozitivul va fi controlat prin maximum trei butoane. La apsarea
butoanelor pe ecran se deschide un meniu pentru a permite utilizatorului s
selecteze funciile de control ale sistemului.
Performan: Harta se va rula lent pe ecran. Dup alimentare, afiarea cadrului
iniial pe ecran se va face n cel mult o secund, iar sistemul va fi capabil s
verifice i s afieze poziia sa n cel mult 15 secunde.
Cost: Costul de vnzare maxim 500$. (aproximativ de 5 ori costul
componentelor).
Dimensiune / greutate: Dispozitivul se va potrivi confortabil n palma minii.
Consum de putere: Funcionare pentru cel puin 8 ore cu 4 baterii AA.
15
Formular de cerine
Name

GPS moving map
Purpose

Consumer-grade moving map for driving
Inputs

Power button, two control buttons
Outputs

Back-lit LCD display 400 X 600
Functions

Uses 5-receiver GPS system; three user-
selectable resolutions; displays current
latitude and longitude

Performance

Updates screen within 0.25 seconds upon
movement

Manufacturing cost

$100 cost-of-goods- sold
Power

100 mW
Physical size/weight

no more than 2 X 6 (5cm x 15 cm), 12
ounces (340 g)

16
ELABORAREA SPECIFICAIILOR
Specificaiile reprezint o descriere funcional detaliat ce respect
cerinele. Nu indic modul de implementare.
Uureaz nelegerea cerinelor i urmresc ndeplinirea cerinelor n
timpul activitilor de proiectare.
Uureaz munca de proiectare i nltur eventualele greeli, repetri
sau omisiuni ale unor funcii reluri ale proiectrii
Specificaiile sunt deosebit de importante pentru proiecte complexe, ce
implic un colectiv de cercetare sarcinile de proiectare pentru fiecare
persoan din grup.
Presupun o analiz (intern) a concepiilor de proiectare enunate,
pentru a verifica dac specificaiile cerute sunt posibil de implementat
re-utilizarea unor pri din alte proiecte anterioare permite asigurarea
succesului noului proiect (funcional i ca timp de terminare)
Etapa 1: Crearea arhitecturii
17
ELABORAREA SPECIFICAIILOR
Specificaiile pot fi privite ca un contract ntre beneficiar i
proiectant
Documentele cu cerine i specificaii pot fi folosite pentru crearea
unui plan de testare. Documentul de cerine definete ce este
nevoie a fi testat.
Pentru proiecte mari testarea poate fi fcut de un inginer de
testare independent de colectivul de proiectare, care elaboreaz un
plan de testare pe baza cerinelor.
Separarea analizei cerinelor i specificaiilor este necesar adesea
diferene mari ntre modul cum beneficiarii pot descrie sistemul i ceea
ce au nevoie arhitecii pentru a proiecta sistemul.
beneficiarii pot avea ateptri nerealiste cu privire la ceea ce se poate
face cu bugetul alocat de ei.
Etapa 1: Crearea arhitecturii
18
ELABORAREA SPECIFICAIILOR
Complexitatea i formalismul specificaiilor depind de tipul companiei
proiectante i de dimensiunea produsului final.
Se poate realizeaza o modelare (de obicei de tip O.O:) a specificaiilor n
scopul proiectrii arhitecturii i ulterior a proiectrii componentelor.
Modelele sunt reprezentri conceptuale ale funcionalitii sistemului.
Modelul este constituit din obiecte funcionale i reguli pentru
compunerea acestor obiecte.
Descrierea grafic a specificaiilor OO
fie ntr-un limbaj de modelare (de ex. UML),
sau prin definirea i desenarea unor diagrame de analiz conceptual a
sistemului care cuprind:
componentele cheie ale sistemului,
funciile de baz ale fiecrei componente,
interaciunea cile de comunicare ntre aceste componente i
lista serviciilor oferite utilizatorului sistemului.
Etapa 1: Crearea arhitecturii
19
Exemplu diagram conceptual pentru
servicii bancare simple (Alistair Cockburn)
Servicii mica banc:
Verificare cont
Pstrare bani n cont
Verificare stocuri
mprumuturi
20
Exemplu diagram conceptual


Casier
Depozit (Seif)
Calculator
Mas
Realizeaz tranzacia
Pstreaz banii
Furnizeaz o suprafa plat
pentru completat cereri
tranzacii
Pstreaz nregistrrile
i balanele
$
Interogare balan
Detalii tranzacie
Client
21
REZUMAT SPECIFICAII
Faz Rezultate
Elaborare Specificaii
Descriere de detaliu a comportrii sistemului.
O descriere detaliat, precis, clar i fr
ambiguiti a cerinelor
Descriere funcii i interaciune componente
sistem
Modelarea funcionalitii sistemului
Analiza concepiilor de proiectare - revizie
Document specificaii
Finalizarea descrierii modelul
funcional
Crearea unui plan de testare



22
EXEMPLU: Hart GPS
Lista de specificaii pentru harta de navigare GPS va include
cteva componente:
ce date se recepioneaz de la constelaia de satelii GPS;
datele hrii afiate;
interfaa cu utilizatorul;
operaii ce trebuie realizate pentru a satisface cerinele
utilizatorului;
operaii n fundal (ne-evidente) cerute pentru a pstra
sistemul n funciune, cum ar fi de exemplu funcionarea
receptorului GPS.
23
EXEMPLU: Hart GPS
Wolf realizeaz descrierea funcional prin modelare n
UML (Unified Modeling Language)
UML:
- este un limbaj vizual care poate capta n mod sugestiv
specificaiile
- umbrete distinciile dintre hw i sw
- modeleaz comportarea sistemului
- este un generator automat de cod, putnd genera cod
HDL sau C++ pentru implementarea proiectului.
24
Un obiect Display n notaia UML
d1: Display
pixels: array[] of pixels
elements
menu_items
pixels is a
2-D array
comment
object name
class name
attributes
Un obiect include un set de atribute care definesc starea sa intern. Atunci cnd se
implementeaz ntr-un limbaj de programare, aceste atribute devin de obicei variabile,
sau constante pstrate ntr-o structur de date.
25
O clas n notaia UML

Display
pixels
elements
menu_items
mouse_click()
draw_box
operations
class name
atributes
Operaiile (metode n
C++) determin modul
cum obiectul
interacioneaz cu restul
lumii
26
O specificaie de main de stare UML (pentru o
operaie a display-ului)

region
found
got menu
item
called
menu item
found
object
object
highlighted
start state
stop state
mouse_click(x,y,button)/
find_region(region)
region = menu/
which_menu(i)
call_menu(I)
region = drawing/
find_object(objid)
highlight(objid)
27
Secvena operaiilor n timp descris
prin diagrama secvenial

m: Mouse d1: Display u: Menu
mouse_click(x,y,button)
which_menu(x,y,i)
call_menu(i)
time
lifeline
28
PROIECTARE ARHITECTURAL
Arhitectura este o reprezentare abstract a implementrii
sistemului i indic structura sistemului n termenii
componentelor mari i interconexiunile dintre acestea.
La nivel arhitectural, componentele hardware i software sunt
reprezentate ca o compoziie de elemente ce interacioneaz.
Detalii de implementare (HW & SW) sunt abstractizate,
coninnd doar informaia de comportament i de inter-
relaie ntre componente.
O arhitectur embedded include elemente interne ale
sistemului, elemente externe ce interacioneaz cu sistemul,
proprietile fiecrui element individual i relaiile de
interaciune ntre elemente
n aceast etap se face partiionarea implementrii funciilor
ntre hardware i software.
Etapa 1: Crearea arhitecturii
29
IMPORTANA ARHITECTURII
Indic cum se vor implementa funciile sistemului, descrise n
specificaii.
Arhitectura este un mijloc eficient pentru nelegerea proiectului EmS,
constituind documentul ce definete infrastructura proiectului,
diferitele opiuni de proiectare, constrngerile de proiectare. Planul
arhitectural are capacitatea de a comunica rapid i corect modul de
proiectare ctre alte persoane cu sau fr pregtire tehnic, constituind
totodat baza (fundaia) activitii de planificare a proiectrii unui
dispozitiv.
Permite analiza i testarea calitii unui dispozitiv
Permite definirea unor modaliti de reducere a costurilor de
proiectare-construcie i estimarea corect a riscurilor implicate de
implementarea diverselor elemente
Permite reutilizarea cunoaterii scderea n viitor a costurilor
Etapa 1: Crearea arhitecturii
30
PROIECTARE ARHITECTURAL
Proiectarea arhitectural include:
Definirea componentelor sistemului. Este o estimare ce ine de
experien i de cunoaterea caracteristicilor componentelor hardware i
software propuse.
Specificaii hardware / software (exist opiunea ntre a cumpra i a
construi prin fore proprii). n cazul UML: modelare grafic a obiectelor
componente. Obiectele corespund pieselor reale HW i SW ale
proiectului.
Alegerea procesorului
Alegerea limbajului de programare
Evaluarea sistemului
Proiectare hardware
Proiectare firmware
Integrare
Etapa 1: Crearea arhitecturii
31
DE INUT CONT
Este important de inut minte c hardware reprezint un cost recurent
(repetat), ce se repet pentru fiecare sistem vndut.
Software reprezint un cost ne-recurent. Trebuie dezvoltat o singur dat, dar
nu apare ca i cost pe unitatea de produs, dect dac este o tax de licen de
pltit.
Alegerea variantei de implementare hardware:
Cu microprocesoare, microcontrollere discrete i cablaj imprimat n
aceeai carcas, System in Package
Sistem distribuit.
Un-sistem-pe-un-chip (System-on-chip = SOC). Proiecte SOC pe baz
de nuclee IP
ASIC, bazat tot pe nuclee IP dar pentru aplicaii specifice i n numr
extrem de mare. Sunt tot SoC, full custom design.
Etapa 1: Crearea arhitecturii
32
ALEGEREA PROCESORULUI
Numrul de pini de IO necesari - Pini grupai n porturi de IO, restricii, capabiliti
cureni mari
Interfee necesare
Cerine memorie RAM
numrul de variabile plus suma tuturor bufferelor interne, structuri FIFO, i
dimensiunea stivei
intern / extern, restricii de utilizare, SFR, moduri de adresare
eficien compiler.
Cerine memorie ROM
suma codului de program plus toate tabelele necesare a fi incluse ntr-o memorie
nevolatil
regul bazat pe experien: ocupare n proporie de maxim 80%
Testare compilator ales poriuni de cod pentru a determina dimensiunea
acestuia dup compilare / asamblare
dimensiunea codului depinde limbajul de programare ales pentru dezvoltare
dac se folosesc operaii n virgul mobil, iar procesorul nu are inclus un co-
procesor matematic cod mare.
Etapa 1: Crearea arhitecturii
33
ALEGEREA PROCESORULUI
Numr de ntreruperi cerut
Consideraii real-time
Mediul de dezvoltare. Funciuni principale ale unui mediu integrat de
dezvoltare (IDE - Integrated Development Environment), ce ruleaz pe
un calculator desktop (de exemplu un PC).:
dezvoltarea programelor utilizator (de obicei n limbaj C i / sau
asamblare) ntr-o fereastr de editare.
compilator i editor de legturi
depanarea i punerea la punct a programelor prin debugger
asamblor pentru rutinele scrise n asamblare
simulator pentru rularea programelor (inclusiv pas cu pas prin
debugger) i urmrirea coninutului registrelor interne, a memoriei, a
porturilor de IO, a circuitelor timer / counter, etc.
transferul codului (program executabil) ctre memoria local (flash,
EEPROM) a microcontrollerului
Etapa 1: Crearea arhitecturii
34
ALEGEREA PROCESORULUI
Investiii anterioare ale companiei (IDE), principii economice.
Necesiti de vitez de prelucrare.
n cazul cel mai dezavantajos al mai multor ntreruperi aflate n curs
de servire procesorul trebuie s funcioneze respectnd specificaiile
de proiectare.
Lungimea buclelor de interogare suficient de scurt ca s nu se
piard niciodat un octet de la o intrare de date serial, sau de la
oricare alt interfa.
Frecvena de ceas a procesorului nu trebuie confundat cu frecvena
oscilatorului de ceas.
Setul de instruciuni este de asemenea foarte important. n unele
aplicaii arhitectura RISC poate fi o capcan.
Etapa 1: Crearea arhitecturii
35
ALEGEREA PROCESORULUI
ROM-ability
Flash
EPROM
OTP
ROM.
Costuri
In Circuit programming
Arhitectura memoriei
Cerine de putere
Cerine de mediu
Unele aplicaii impun ca MP s lucreze la game extreme de
temperatur i radiaie.
Etapa 1: Crearea arhitecturii
36
DEZVOLTAREA VERSIUNII
ARHITECTURALE
Proiectarea componentelor hardware i software
Integrarea sistemului prin conectarea componentelor
proiectate.
Verificare i obinere de informaii de feedback
Inspecia unui proiect se face de ctre o alt persoan
dect proiectantul (detectarea omisiunilor, erorilor).
Inspecia se face pe baza unor prezentri scrise sau orale
din partea proiectantului.
Etapa 1: Crearea arhitecturii
37
DEZVOLTAREA VERSIUNII
ARHITECTURALE
Documentarea:
detectarea uoar a componentelor care conduc la
neconformiti cu cerinele
comunicarea dintre membrii unei echipe
elaborarea rapoartelor cu privire la proiect
elaborarea documentaiei finale a proiectului,
reutilizarea componentelor proiectului pentru alte
proiecte, modificare, upgrade.
Elaborarea unui plan pentru integrarea i testarea
componentelor
Etapa 1: Crearea arhitecturii
38
REZUMAT:
ARHITECTURA I INTEGRARE
Proiecte la nivel de sistem.
Structura sistemului n termenii
componentelor mari i
interconexiunile dintre acestea.
Modul de implementare a
funciilor i modul de
implementare a componentelor
Alegerea procesorului
Alegerea limbajului
Definirea blocurilor majore
hardware i software
Opiune ntre cumprare sau
construire prin fore proprii.
Partiionare: Blocuri
funcionale, Hw / SW
REZULTATE
Specificaii pt. blocuri
funcionale
Alegere MCU/CPU
Alegere limbaj
Revizie de proiectare a
sistemului
Etapa 1: Crearea arhitecturii
39
EXEMPLU: Hart GPS
Diagrama bloc ce definete arhitectura pentru harta mobil

Receptor
GPS
Main de
cutare
Dispozitiv
de redare
Interfa
utilizator
Database
Display
40
HARDWARE

Receptor
GPS

CPU
Panou I/O

Display

Frame
Buffer

Memorie
Magistral
41
SOFTWARE

Poziie
Cutare n
baz date

Redare

Timer
Interfa
utilizator
Pixeli
42
IMPLEMENTAREA SISTEMULUI
Implementarea hardware i software
Proiectare de detaliu componente i construcie
Pentru software asta nseamn proiectarea de detaliu, scriere i
depanare a codului
Pentru hardware nseamn proiectarea de detaliu, realizarea
proiectului prototipului i testarea circuitelor.
Implementare nucleu MCU
Construcie i testare alte blocuri funcionale ale arhitecturii. Dac la
proiect lucreaz o singur persoan, atunci blocurile funcionale sunt
completate secvenial. Dac exist mai muli proiectani acestea se pot
rezolva n paralel.
2. Implementarea arhitecturii
43
IMPLEMENTAREA SISTEMULUI
Sarcinile presupuse pentru fiecare bloc funcional includ proiectare
hardware de detaliu i construcie, proiectare software de detaliu i
construcie i apoi integrarea hardware-software i testarea
Pot exista interdependene ntre proiectarea hardware i software.
Partea hardware nu poate fi testat pn cnd o parte din software nu
este gata, iar software nu poate fi testat pn cnd partea din proiectul
hardware nu este gata
n mod tipic se construiete hardware i se testeaz minimal mai nti.
Apoi majoritatea efortului se concentreaz pe scrierea de software i
testarea software pe hardware.
Documentarea sistemului
2. Implementarea arhitecturii
44
VERIFICARE I TESTARE
Scop: verificare, testare, ncorporare de informaii de feedback pentru
corectarea neconformitilor
Revizii:
Reviziile sunt demonstraii, inspecii ale schemelor i inspecii ale
codului
Revizia trebuie fcut de specialiti independeni, familiari cu proiectul
(CERINE) i tehnologiile, care s ajute la detectarea erorilor
Se pot detecta omisiuni, erori
Testarea produsului final este o continuare a activitilor de testare din
timpul proiectrii, acestea put-nd fi urmrite conform documentaiei
elaborate la proiectare arhitectural
Testare public - un proiect preliminar este distribuit unor beneficiar
de la care se ateapt feedback (beta testing). Reacia de la clieni
poate duce nu numai la detectarea unor erori, schimbarea codului, dar
i la schimbarea unor specificaii. Nu e recomandat ntotdeauna n
domeniul EmS.
3. Testarea sistemului
45
FURNIZARE PRODUS FINAL I
MENTENAN
Prototipul final i integrarea constituie ultima faz a proiectrii.
Este faza n care toate blocurile funcionale sunt nglobate i se
construiete prototipul hardware final. De asemenea modulele
software sunt combinate, iar codul este revizuit pentru a rula ca o
aplicaie de sine stttoare pe prototip. Unele din componentele
hardware i software au fost deja construite i testate pe un sistem de
dezvoltare, nainte de aceast faz
n funcie de complexitatea sistemului de dezvoltare utilizat aceast
ultim faz poate fi un pas uor de realizat, sau poate fi o operaie
complex.
n mediul competitiv actual multe din deciziile luate la proiectare se
bazeaz pe re-utilizarea unor componente ale proiectelor deja
existente. Astfel c ciclul de via al unui proiect continu i dup
producie i el poate include mentenana produsului, raportarea bug-
urilor i arhivarea.
4. Furnizare prototip
46
FURNIZARE PRODUS FINAL I
MENTENAN
Documentare:
Important att pentru componentele hardware, dar i mai
important pentru cele software. Permite detectarea uoar a
componentelor care conduc la neconformiti cu cerinele, permite
comunicarea dintre membrii unei echipe, elaborarea rapoartelor
cu privire la proiect, elaborarea documentaiei finale a proiectului,
permite reutilizarea componentelor proiectului pentru alte
proiecte.
Pentru software toate informaiile referitoare la etapele anterioare,
de la punerea problemei, elaborarea algoritmului i a schemei
logice (eventual diversele versiuni succesive indicnd evoluia
programului)
Sursa programului (cu comentarii suficiente pentru a se corela cu
schema logic), eventuale eantioane de date de intrare / ieire,
dac este cazul
4. Furnizare prototip