QReferate - referate pentru educatia ta.
Cercetarile noastre - sursa ta de inspiratie! Te ajutam gratuit, documente cu imagini si grafice. Fiecare document sau comentariu il poti downloada rapid si il poti folosi pentru temele tale de acasa.



AdministratieAlimentatieArta culturaAsistenta socialaAstronomie
BiologieChimieComunicareConstructiiCosmetica
DesenDiverseDreptEconomieEngleza
FilozofieFizicaFrancezaGeografieGermana
InformaticaIstorieLatinaManagementMarketing
MatematicaMecanicaMedicinaPedagogiePsihologie
RomanaStiinte politiceTransporturiTurism
Esti aici: Qreferat » Documente informatica

Introducere inprocesul deproiectare al sistemelor embedded



INTRODUCERE INPROCESUL DEPROIECTARE AL SISTEMELOR EMBEDDED


PRINCIPALE AVANTAJE

ALE METODOLOGIEI DE PROIECTARE

ofera posibilitatea pastrarii unei istorii / inregistrari a rezultatelor etapelor proiectarii

utila pentru documentare, testare functionala, depanare



permite dezvoltarea sau folosirea unor unelte de proiectare asistata de calculator

desfasurarea in paralel a proiectarii pentru diferite componente functionale

simplifica comunicarea dintre membrii unei echipe de proiectare.


ELEMENTE SPECIFICE

PROIECTARII EmS

. Re-utilizarea unor componente deja proiectate in alte proiecte

. Stransa interactiune dintre hardware si software

- Programatorii trebuie sa inteleaga partea hardware iar proiectantii de hardware trebuie sa inteleaga partea software

. Utilizarea de blocuri functionale +fiecare proiectant este responsabil atat de hardware cat si de software pentru o functiune, sau pentru un set de functiuni


ETAPE PROIECTARE

. Deciziile luate la un anumit pas al proiectarii sunt bazate pe estimarea a ce se va intampla mai tarziu

- Daca estimarile sunt inadecvate, trebuie sa ne intoarcem si sa indreptam deciziile noastre initiale, tinand cont de noile evenimente

. La fiecare etapa a proiectarii se adauga detalii:

-analiza proiectului la fiecare pas pentru a determina cum se indeplinesc specificatiile

-rafinarea proiectului pentru a adauga elemente de detaliu

-verificarea proiectul pentru a fi siguri ca indeplineste toate obiectivele sistemului


PRINCIPALELE ETAPE IN

PROCESUL DE PROIECTARE AL EmS


.Definirea cerintelor produsului

.Elaborare specificatii functionale

.Crearea proiectului arhitectural

.Furnizare versiune arhitecturala finala


.Implementare module

.Verificare si punere la punct

.Implementarea si integrarea sistemului


.Verificare si testare sistem in diferite

faze de implementare







Etapa I - Crearea Arhitecturii


DEFINIREA PROBLEMEI SI A CERINTELOR PRODUSULUI

. Definirea produsului descrie ce va fi si ce va face acesta

. Definirea cerintelor constituie primul pas al procesului, fiind cheia succesului in proiectarea sistemelor electronice

. Definirea cerintelor reprezinta baza documentatiei proiectului

. Documentatia descrie ce veti construi

- Spune oamenilor de marketing ce produs vor avea de vandut

- Spune proiectantilor cum sa implementeze produsul.

. Rezultatul acestei faze va fi o definire simpla a problemei, din punctul de vedere al utilizatorului (beneficiarul)

- Se va descrie problema, dar nu se vor sugera solutii

. DA: Miscarea vorbitorului nu va fi stanjenita de cablul microfonului

. NU: Se va folosi un microfon wireless

CINE DEFINESTE CERINTELE ?

. Intr-o companie foarte mare, definirea cerintelor va fi facuta de catre departamentul de marketing, sau un client important

. Intr-o companie mica schita de definire a cerintelor se poate face de catre inginerii software si hardware

. Pentru un proiecte mici, proiectantul defineste cerintele

CE TREBUIE DEFINIT CA CERINTE ?

. CERINTE FUNCTIONALE

- Intrari si iesiri (interfata cu utilizatorul si mediul)

- Functii si constrangeri de timp

. CERINTE NE-FUNCTIONALE

- Performanta.

- Costuri.

- Consumul de putere.

- Dimensiune fizica si greutatea.

- Fiabilitate, siguranta in functionare, mentenabilitate



EXEMPLU DE FORMULAR DE CERINTE TIPICE

. Nume

. Scop

. Intrari / Iesiri catre lumea externa

- Tipul datelor

- Caracteristicile generale ale datelor

- Tipuri de dispozitive de interfata cu utilizatorul

. Functii. Intrari →FUNCTII→Iesiri

. Performanta

. Costuri de fabricatie. Apreciere grosiera, sau limita maxima.

. Putere. Apreciere grosiera, sau limita maxima (baterii / retea ?)

. Dimensiune / greutate fizica


REZUMAT CERINTE


Faza

Rezultate

Definirea problemei de proiectare si elaborare cerinte

Cercetare, analiza piata

Consultare utilizator. Culegere de informatii

generale de la clienti (utilizatori sau

beneficiari)

Cerinte functionale si nefunctionale

Cercetare

→Definirea corecta a problemei

→Propunere cerinte

→Document (formular) de cerinte

→ Crearea unui plan de testare



EXEMPLU: Harta GPS



. Este un dispozitiv portabil care afiseaza pentru utilizator o harta a terenului din jurul pozitiei

curente a utilizatorului

. Harta afiseaza modificarile corespunzatoare

schimbarii pozitiei utilizatorului, sau ale dispozitivului de afisare a hartii

. Harta mobila obtine pozitia sa de la GPS


Harta GPS: Cerinte initiale

Functionalitate: proiectat pentru utilizare in trafic auto si scopuri similare; nu pentru utilizare nautica, sau aviatie, care necesita functiuni si baze de date mai specializate. Sistemul va afisa / indica principalele drumuri si alte puncte de reper disponibile in bazele de date topografice standard.

Interfata cu utilizatorul: Ecranul va avea cel putin rezolutia de 400 x 600 pixeli.

Dispozitivul va fi controlat prin maximum trei butoane. La apasarea butoanelor pe ecran se deschide un meniu pentru a permite utilizatorului sa selecteze functiile de control ale sistemului.

Performanta: Harta se va rula lent pe ecran. Dupa alimentare, afisarea cadrului initial pe ecran se va face in cel mult o secunda, iar sistemul va fi capabil sa verifice si sa afiseze pozitia sa in cel mult 15 secunde.

Cost: Costul de vanzare maxim 500$. (aproximativ de 5 ori costul componentelor).

Dimensiune / greutate: Dispozitivul se va potrivi confortabil in palma mainii.

Consum de putere: Functionare pentru cel putin 8 ore cu 4 baterii AA.

Formular de cerinte

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 userselectable 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)


ELABORAREA SPECIFICATIILOR

. Specificatiile reprezinta o descriere functionala detaliata ce respecta cerintele. Nu indica modul de implementare.

- Specificatiile usureaza intelegerea cerintelor

- Specificatiile permit urmarirea indeplinirii cerintelor pe parcursul activitatilor de proiectare

. Usureaza munca de proiectare

. Inlatura eventualele greseli, repetari sau omisiuni ale unor functii→reluari ale proiectarii

. Specificatiile sunt deosebit de importante pentru proiecte complexe, ce implica un colectiv de cercetare →sarcinile de proiectare pentru fiecare persoana din grup.

. Presupun o analiza (interna) a conceptiilor de proiectare enuntate pentru a verifica daca specificatiile cerute sunt posibil de implementat

- re-utilizarea unor parti din alte proiecte anterioare permite asigurarea succesului noului proiect (functional si ca timp de terminare)

. Specificatiile pot fi privite ca un contract intre beneficiar si proiectant

. Documentele cu cerinte si specificatii pot fi folosite pentru crearea unui plan de testare

- Documentul initial de cerinte defineste ce este nevoie este necesar a fi testata.

. Testarea este facuta, de obicei la proiectele mari, de un inginer de testare independent de colectivul de proiectare, care elaboreaza un plan de testare pe baza cerintelor.

. Separarea analizei cerintelor si specificatiilor este necesara adesea:

- diferente mari intre modul cum beneficiarii pot descrie sistemul si ceea ce au nevoie specialistii pentru a proiecta sistemul.

- beneficiarii pot avea asteptari nerealiste cu privire la ceea ce se poate face cu bugetul alocat de ei.


COMPLEXITATEA SPECIFICATIILOR

. Complexitatea si formalismul specificatiilor depind de tipul companiei proiectante si de dimensiunea produsului final.

. Se poate realizeaza o modelare a specificatiilor in scopul proiectarii arhitecturii si ulterior a proiectarii componentelor.

- Modelele sunt reprezentari conceptuale ale functionalitatii sistemului. Modelul este constituit din obiecte functionale si reguli pentru compunerea acestor obiecte.

. Descrierea grafica a specificatiilor

- fie intr-un limbaj de modelare,

- sau prin definirea si desenarea unor diagrame de analiza conceptuala a sistemului care cuprind:

. componentele cheie ale sistemului,

. functiile de baza ale fiecarei componente,

. interactiunea - caile de comunicare intre aceste componente si

. lista serviciilor oferite utilizatorului sistemului



Exemplu diagrama conceptuala pentru servicii bancare simple (Alistair Cockburn)

Servicii mica banca:

_ Verificare cont

_ Pastrare bani in cont

_ Verificare stocuri

_ Imprumuturi

Exemplu diagrama conceptual


REZUMAT SPECIFICATII

Faza

Rezultate

Elaborare Specificatii


v    Descriere de detaliu a comportarii sistemului.

v    O descriere detaliata, precisa, clara si fara

ambiguitati a cerintelor

v    Descriere functii si interactiune component system

v    Modelarea functionalitatii sistemului

v    Analiza conceptiilor de proiectare - revizie

v    Document specificatii

v    Finalizarea descrierii modelul functional

v    Crearea unui plan de testare


EXEMPLU: Harta GPS

. Lista de specificatii pentru harta de navigare GPS va include

cateva componente:

- ce date se receptioneaza de la constelatia de sateliti GPS;

- datele hartii afisate;

- interfata cu utilizatorul;

- operatii ce trebuie realizate pentru a satisface cerintele utilizatorului;

- operatii in fundal (ne-evidente) cerute pentru a pastra sistemul in functiune, cum ar fi de exemplu functionarea receptorului GPS.



PROIECTARE ARHITECTURALA

. Arhitectura este o reprezentare abstracta a implementarii sistemului si indica structura sistemului in termenii componentelor mari si interconexiunile dintre acestea

. La nivel arhitectural, componentele hardware si software sunt reprezentate ca o compozitie de elemente ce interactioneaza

- Detalii de implementare (HW & SW) sunt abstractizate, continand doar informatia de comportament si de inter-relatie intre componente

. O arhitectura embedded include elemente interne ale sistemului, elemente externe ce interactioneaza cu sistemul, proprietatile fiecarui element individual si relatiile de interactiune intre elemente

. In aceasta etapa se face partitionarea implementarii functiilor intre hardware si software


IMPORTANTA ARHITECTURII

. Indica cum se vor implementa functiile sistemului, descrise in specificatii.

. Arhitectura este documentul care:

- Defineste infrastructura proiectului

- Evidentiaza optiunile si constrangerile de proiectare

- Comunica rapid si corect, prin planul arhitectural, modul in care se va face

proiectarea / implementarea. (Comunicare catre alte persoane cu / fara pregatire tehnica)

- Este fundamentul activitatii de planificare a sarcinilor de proiectare

- Permite analiza si testarea calitatii unui dispozitiv

- Permite definirea unor modalitati de reducere a costurilor de proiectare constructie

- Permite estimarea corecta a riscurilor implicate de varianta de implementare a diverselor elemente

- Permite reutilizarea cunoasterii scaderea in viitor a costurilor


Proiectarea arhitecturala include:

Definirea componentelor sistemului. Este o estimare ce tine de experienta si de cunoasterea caracteristicilor componentelor hardware si software propuse.

Specificatii hardware / software (exista optiunea intre a cumpara si a construi prin forte proprii)

In cazul UML: modelare grafica a obiectelor componente. Obiectele corespund pieselor reale HW si SW ale proiectului.

Alegerea procesorului

Alegerea limbajului de programare

Evaluarea sistemului

Proiectare hardware si firmware

Integrare si testare functionala


DE TINUT CONT

. Este important de tinut minte ca hardware reprezinta un cost recurent (repetat), ce se repeta pentru fiecare sistem vandut.

. Software reprezinta un cost ne-recurent. Trebuie dezvoltat o singura data, dar nu apare ca si cost pe unitatea de produs, decat daca este o taxa de licenta de platit.

. Alegerea variantei de implementare hardware:

- Cu microprocesoare, microcontrollere discrete si cablaj imprimat - in aceeasi carcasa, System in Package

- Sistem distribuit

- Un-sistem-pe-un-chip (System-on-chip = SOC). Proiecte SOC pe baza de nuclee IP

- ASIC, bazat tot pe nuclee IP dar pentru aplicatii specifice si in numar extrem de mare. Sunt tot SoC, full custom design.


ALEGEREA PROCESORULUI

. Numarul de pini de IO necesari - Pini grupati in porturi de IO, restrictii, capabilitati curenti mari

. Interfete necesare

. Cerinte memorie RAM

- numarul de variabile plus suma tuturor bufferelor interne, structuri FIFO, si

dimensiunea stivei

- intern / extern, restrictii de utilizare, SFR, moduri de adresare

- eficienta compiler.

. Cerinte memorie ROM

- suma codului de program plus toate tabelele necesare a fi incluse intr-o memorie nevolatila

- regula bazata pe experienta: ocupare in proportie de maxim 80%

- Testare compilator ales portiuni de cod pentru a determina dimensiunea acestuia dupa compilare / asamblare

- dimensiunea codului depinde limbajul de programare ales pentru dezvoltare

- daca se folosesc operatii in virgula mobila, iar procesorul nu are inclus un coprocesor matematic cod mare.

. Numar de intreruperi cerut

. Consideratii real-time

. Mediul de dezvoltare. Functiuni principale ale unui mediu integrat de dezvoltare (IDE - Integrated Development Environment), ce ruleaza pe un calculator desktop (de exemplu un PC).:

- dezvoltarea programelor utilizator (de obicei in limbaj C si / sau asamblare) intr-o fereastra de editare.

- compilator si editor de legaturi

- depanarea si punerea la punct a programelor prin debugger

- asamblor pentru rutinele scrise in asamblare

- simulator pentru rularea programelor (inclusiv pas cu pas prin debugger) si urmarirea continutului registrelor interne, a memoriei, a porturilor de IO, a circuitelor timer / counter, etc.

- transferul codului (program executabil) catre memoria locala (flash, EEPROM) a microcontrollerului

- Investitii anterioare ale companiei (IDE), principii economice.

. Necesitati de viteza de prelucrare.

- In cazul cel mai dezavantajos al mai multor intreruperi aflate in curs de servire procesorul trebuie sa functioneze respectand specificatiile de proiectare.

- Lungimea buclelor de interogare suficient de scurta ca sa nu se piarda niciodata un octet de la o intrare de date seriala, sau de la oricare alta interfata.

- Frecventa de ceas a procesorului nu trebuie confundata cu frecventa oscilatorului de ceas.

- Setul de instructiuni este de asemenea foarte important. In unele aplicatii arhitectura RISC poate fi o capcana.

. ROM-ability

- Flash

- EPROM

- OTP

- ROM.

. Costuri

. In Circuit programming

. Arhitectura memoriei

. Cerinte de putere

. Cerinte de mediu

- Unele aplicatii impun ca MP sa lucreze la game extreme de temperatura si radiatie.


DEZVOLTAREA VERSIUNII ARHITECTURALE


. Proiectarea componentelor hardware si software

. Integrarea sistemului prin conectarea componentelor proiectate.

. Verificare si obtinere de informatii de feedback

. Inspectia unui proiect se face de catre o alta persoana decat proiectantul (detectarea omisiunilor, erorilor). Inspectia se face pe baza unor prezentari scrise sau orale

din partea proiectantului.

. Documentatia

- detectarea usoara a componentelor care conduc la neconformitati cu cerintele

- comunicarea dintre membrii unei echipe

- elaborarea rapoartelor cu privire la proiect

- elaborarea documentatiei finale a proiectului,

- reutilizarea componentelor proiectului pentru alte proiecte, modificare, upgrade.

. Elaborarea unui plan pentru integrarea si testarea componentelor


Proiecte la nivel de sistem. REZULTATE

Structura sistemului in termenii

componentelor mari si

interconexiunile dintre acestea

Modul de implementare a  . Specificatii pt. blocuri functionale

functiilor si modul de

implementare a componentelor

. Alegerea procesorului  . Alegere MCU/CPU

. Alegerea limbajului   . Alegere limbaj

. Definirea blocurilor majore . Revizie de proiectare a sistemului


hardware si software

. Optiune intre cumparare sau

construire prin forte proprii.

. Partitionare: Blocuri

functionale, Hw / SW



EXEMPLU: Harta GPS

Diagrama bloc ce defineste arhitectura pentru harta mobila






HARDWARE

SOFTWARE


IMPLEMENTAREA SISTEMULUI

. Implementarea hardware si software

. Proiectare de detaliu componente si constructie

- Pentru software asta inseamna proiectarea de detaliu, scriere si depanare a codului

- Pentru hardware inseamna proiectarea de detaliu, realizarea proiectului prototipului si testarea circuitelor.

. Implementare nucleu MCU

. Constructie si testare alte blocuri functionale ale arhitecturii. Daca la proiect lucreaza o singura persoana, atunci blocurile functionale sunt completate secvential. Daca exista mai multi proiectanti acestea se pot rezolva in paralel.

. Sarcinile presupuse pentru fiecare bloc functional includ proiectare hardware de detaliu si constructie, proiectare software de detaliu si constructie si apoi integrarea hardware-software si testarea

. Pot exista interdependente intre proiectarea hardware si software. Partea hardware nu poate fi testata pana cand o parte din software nu este gata, iar software nu poate fi testat pana cand partea din proiectul hardware nu este gata

. In mod tipic se construieste hardware si se testeaza minimal mai intai. Apoi majoritatea efortului se concentreaza pe scrierea de software si testarea software pe hardware.

. Documentarea sistemului


VERIFICARE SI TESTARE

. Scop: verificare, testare, incorporare de informatii de feedback pentru corectarea neconformitatilor

. Revizii:

- Reviziile sunt demonstratii, inspectii ale schemelor si inspectii ale

codului

- Revizia trebuie facuta de specialisti independenti, familiari cu proiectul

(CERINTE) si tehnologiile, care sa ajute la detectarea erorilor

- Se pot detecta omisiuni, erori

. Testarea produsului final este o continuare a activitatilor de testare din timpul proiectarii, acestea putand fi urmarite conform documentatiei elaborate la proiectare arhitecturala

. Testare publica - un proiect preliminar este distribuit unor beneficiar de la care se asteapta feedback ("beta testing"). Reactia de la clienti poate duce nu numai la detectarea unor erori, schimbarea codului, dar si la schimbarea unor specificatii. Nu e recomandata intotdeauna in domeniul EmS.


FURNIZARE PRODUS FINAL SI MENTENANTA

. Prototipul final si integrarea constituie ultima faza a proiectarii.

. Este faza in care toate blocurile functionale sunt inglobate si se construieste prototipul hardware final. De asemenea modulele software sunt combinate, iar codul este revizuit pentru a rula ca o aplicatie de sine statatoare pe prototip. Unele din componentele hardware si software au fost deja construite si testate pe un sistem de dezvoltare, inainte de aceasta faza

. In functie de complexitatea sistemului de dezvoltare utilizat aceasta ultima faza poate fi un pas usor de realizat, sau poate fi o operatie complexa.

. In mediul competitiv actual multe din deciziile luate la proiectare se bazeaza pe re-utilizarea unor componente ale proiectelor deja existente. Astfel ca ciclul de viata al unui proiect continua si dupa productie si el poate include mentenanta produsului, raportarea bugurilor si arhivarea.


FURNIZARE PRODUS FINAL SI MENTENANTA

. Documentare:

- Importanta atat pentru componentele hardware, dar si mai importanta pentru cele software. Permite detectarea usoara a componentelor care conduc la neconformitati cu cerintele, permite comunicarea dintre membrii unei echipe, elaborarea rapoartelor cu privire la proiect, elaborarea documentatiei finale a proiectului, permite reutilizarea componentelor proiectului pentru alte proiecte.

- Pentru software toate informatiile referitoare la etapele anterioare, de la punerea problemei, elaborarea algoritmului si a schemei logice (eventual diversele versiuni succesive indicand evolutia programului)

- Sursa programului (cu comentarii suficiente pentru a se corela cu schema logica), eventuale esantioane de date de intrare / iesire, daca este cazul



Nu se poate descarca referatul
Acest document nu se poate descarca

E posibil sa te intereseze alte documente despre:


Copyright © 2024 - Toate drepturile rezervate QReferat.com Folositi documentele afisate ca sursa de inspiratie. Va recomandam sa nu copiati textul, ci sa compuneti propriul document pe baza informatiilor de pe site.
{ Home } { Contact } { Termeni si conditii }