AplicaȚie auto

APLICAȚIE AUTO

1 Arhitectura aplicației

2 Tehnologii de implementare

3 Module implementate – modul monitorizare

1 Arhitectura aplicației

Aplicația este structurata in așa fel incat sa fie flexibila, in momentul in care vine vorba de o dezvoltare și actualizare ulterioara. Aceasta flexibilitate este obținuta prin realizarea unei cuplari slabe intre module, modulele fiind cuplate intr-o arhitectura multinivel. Se pot adauga noi module prin simpla implementare a unor interfețe, și actualizarea unui fișier de configurație fara a mai fi nevoie de alte modificari in codul de baza al aplicației. De asemenea arhitectura multinivel permite separarea funcționalitaților ajungandu-se in acest fel, ca depanarea erorilor și problemelor care pot aparea la un moment dat sa fie ușor de realizat. Un alt avantaj al acestei abordari, este reprezentat de faptul ca se poate realiza o testare modulara și se pot realiza unitați de test automatizate pentru fiecare modul in parte, timpul alocat testarii putand fii diminuat cu 60 – 70%.

Un alt lucru important care s-a urmarit in momentul in care aceasta aplicație a fost proiectata, a fost separarea funcționalitații de baza, fața de interfața grafica, in felul acesta interfața grafica poate fi inlocuita in orice moment fara a fi nevoie sa se rescrie funcționalitatea de logica a aplicației (modulul de conectare la interfața auto, modulul de citire a informațiilor de la interfața auto), astfel interfața grafica poate fi actualizata foarte ușor la noile tehnologii de afșare grafica.

Modulul de acces la interfața seriala poate fi inlocuit foarte ușor in cazul in care se dorește utilizarea altei interfețe de comunicare (se doreste utilizarea unei interfețe USB, Ethernet, etc.), singurul lucru care ar trebui schimbat in acest caz este implementarea modului de comunicare pentru protocolul dorit și actualizarea in modulul de baza pentru a folosi noul modul de comunicare, specificandu-se modulul de comunicare ce va fi folosit, fara a mai fi nevoie de alte modificari in codul de baza pentru a face aplicația funcționala.

Diagrama bloc a structurii generale a aplicației

In cele ce urmeaza o sa incerc sa prezint pe scurt fiecare componenta in parte a diagramei de mai sus și rolul pe care il are, respectiva componenta, in cadrul aplicației.

1.1 Application GUI

(Application Graphical User Interface) sau Interfața Grafica de prezentare a aplicației.

Scopul principal al acestei componente este de a prezenta utilizatorului intr-un mod cat mai prietenos și mai ușor de analizat informațiile puse la dispoziție de sistemul de management al motorului, aici includem parametrii obținuți in timpul funcționarii cat și informații memorate pentru analiza in memoria interna a ECU. (Unitatea de control a motorului). Pentru a realiza o interfața care sa fie cat mai ușor de folosit, este nevoie de ca aceasta sa fie imparțita pe funcționalitați. In prima faza aplicația poate sa fie folosita in doua scopuri:

Diagnosticarea problemelor aparute la motor

Monitorizarea parametrilor de funcționare a motorului

Daca se dorește integrarea de noi funcționalitați (modul de navigare GPS, modul de Rapoarte etc.), acestea se pot integra cu aplicația prin implementarea unui nou modul și actualizarea unui fișier de configurare. Modulele noi care se implementeaza trebuie sa respecte un anumit șablon pentru a putea fi integrate, aceasta restricție este impusa de generalitatea modulelor care pot fi integrate cu aplicația. Aceste module pot totodata sa foloseasca din funcționalitatea de baza implementata pentru diagnosticare și monitorizare.

In continuare aceste module pentru interfața grafica o sa le numim plugin-uri.

Plugin-urile pot fi adaugate sau scoase din interfața grafica prin simpla editare a fișierului de configurare, așadar aplicația se poate personaliza foarte ușor.

In figura urmatoare se poate observa modalitatea in care interacționeaza interfața grafica principala cu plugin-urile.

1.2 Business Logic – Core

Logica de funcționalitate

Acest nivel implementeaza logica dupa care se realizeaza achiziția de date, și este folosit atat la implementarea achiziției de informații pentru diagnosticarea defecțiunilor cat și pentru achiziția de date in vederea monitorizarii parametrilor de funcționare. Modulul implementat pentru acest nivel se folosește de nivelul de comunicare pentru a obține informații de la interfața hardware. In momentul in care au fost obținute informațiile dorite de la interfața hardware acestea trebuie decodate pentru a putea interpreta in mod corect datele primite, iar acest lucru este realizat in acest nivel. In momentul in care informațiile sunt transmise in nivelurile superioare acestea sunt puse intr-un format corespunzator necesitaților. Spre exemplu interfața grafica, pentru a afișa numarul de rotații pe minut are nevoie de un numar intreg, dar interfața hardware trimite aceste informațiile sub forma unui șir de caractere ASCII in format hexazecimal, așadar pentru a putea utiliza informația primita este nevoie ca aceasta sa fie interpretata și adusa in formatul corespunzator. In acest context, avand in vedere faptul ca fiecare parametru citit are o interpretare diferita a informațiilor pe care le transmite este nevoie sa se implementeze efectiv, codul pentru decodificarea informațiilor corespunzatoare fiecarui paramteru in parte. In acest sens a fost creata ierarhia de de clase alaturata.

1. HW Communication Layer

Nivelul de comunicare cu dispozitivul hardware.

Nivelul de comunicare cu interfața harware a fost adaugat la aceasta aplicație pentru a putea abstractiza comunicarea intre aplicație și dispozitivul de achiziție. In acest fel in momentul in care se dorește schimbarea interfeței de comunicare software-dispozitiv hardware nu o sa fie nevoie de modificari in nivelurile superioare ala aplicației, singurele schimbari care se fac sunt realizate numai la acest nivel. Acest lucru se relizeaza practic prin definirea unor clase (interfețe) abstracte care urmeaza a fi implementate la momentul la care se cunoaște cu exactitate protocolul folosit pentru comunicare. In cadrul aplicației noastre am considerat ca modulul de comunicație trebuie sa permita executarea urmatoarelor operații de baza:

1.     Trimitere mesaje

2.     Primire mesaje          

3.     Determinarea erorilor care apar la comunicare

4.     Configurare

5.     Initializare conexiune

6.     Inchidere conexiune

La nivelul implementarii au fost considerate mai multe modalitați prin care se poate realiza parametrizarea funcțiilor de trimitere/primire de mesaje. Dupa cum se poate observa in secvența urmatoare de cod, primirea de mesaje se poate realiza prin citirea de pe interfața a datelor pana la primirea unui anumit caracter. Acesta abordare este utila in cazul dispozitivului de diagnoza auto ELM 327, pentru ca toate mesajele de raspuns la interogarile venite din partea utilizatorului se termina cu '>', și de cele mai multe ori pentru a putea interpreta informația de la dispozitiv este necesar intreg raspunsul, așadar este necesar sa se aștepte pana cand se primește semnul care marcheaza sfarșitul raspunsului.

PROIECT: Grile si spete dreptul transporturilor PROIECT: Libera circulatie a persoanelor - marfurilor, serviciilor, capitalului

class IGenericCommunication

1.4 Logger

Modulul de monitorizare a execuției

Aceasta componenta este necesara pentru a putea monitoriza erorile care pot aparea in momentul in care aplicația este folosita de utilizatori ce pot genera scenarii de utilizare care nu au fost luate in calcul in momentul in care a fost proiectata aplicația. Componenta este de fapt un modul care pune la dispoziție celorlalte module ale aplicației o interfața abstractizata pentru a marca execuția unor blocuri de cod. Marcare blocurilor de cod permite crearea unei urme de execuție care poate fi analizata pentru a reproduce pașii prin care a trecut utilizatorul inainte de obține anumite erori sau inainte de a ajunge la un comportament neașteptat din partea aplicației. Nu este de dorit intotdeauna ca acest sistem de monitorizare sa fie activat, acest lucru fiind datorat impactului pe care il poate avea asupra performanței aplicației. Avand in vedere faptul ca de cele mai multe ori, pentru stoca informația din aceste sisteme de monitorizare, se folosește harddisk-ul care are un timp de raspuns relativ mare comparativ cu memoria interna și viteza de execuție a procesorului folosirea sistemelor de monitorizare reduce in mod vizibil viteza de execuție, lucru care de cele mai multe ori, in aplicațiile in care timul de execuție este critic, nu este acceptabil. Exista totuși o soluție și pentru aceste aplicații și anume folosirea unor cozi de mesaje care sa fie descarcate mai apoi pe hard-disk folosind un fir de execuție separat. Avantajul in acest caz este faptul ca timpul de execuție al codului aplicației este influențat nesemnificativ, dar apare dezavantajul ca este posibil ca in momentul apare o eroare care sa genereze inchiderea forțata a aplicației anumiți pași de execuție sa nu fie scriși pe suportul de stocare. Un astfel de sistem de logare, care permite folosirea multithreading este log4cxx, care are deasemenea implementari pentru mai multe platforme de dezvoltare, cum ar fi Java (log4j), Microsoft .NET (log4net). In aplicația noastra nu am folosit un sistem deja implementat, ci am implementat unul nou deoarece necesitație aplicației referitor la un astfel de sistem sunt minime, de aceea nu se justifica introducerea unui sistem complex cum este log4cxx numai pentru acest lucru. De aceeea am implementat un modul simplu care realizeaza operații de baza pentru scrierea de pe hdd.

2 Tehnologiile folosite pentru dezvoltarea aplicației.

Limbajul de programare folosit este C++, in primul rand datorita flexibilitații pe care o ofera in vederea dezvoltarii ulterioare. S-au dezvoltat anumite librarii native care la un moment dat pot fi importate in orice alt limbaj de nivel inalt. Daca am fi ales un alt limbaj de programare de nivel inalt (Java sau .Net) ar fi aparut diverse restricții asupra limbajelor in care acele librarii ar putea fi utilizate. Pentru a putea extinde funcționalitatea implementata pe mai multe platforme de operare am apelat la framework-ul Qt, care este un framework Open Source și care ofera suport multi-platforma. Practic funcționalitatea implementata poate rula pe mai multe sisteme de operare și chiar pe dispozitivele mobile, atata timp cat acestea indeplinesc cerințele hardware necesare.

Acest framework are o istorie de aproximativ 20 de ani, timp in care au fost aduse imbunatațiri permanente, fapt ce ne face sa credem ca acest framework a ajuns la maturitate și prezinta garanția stabilitații modulelor in condițiile unei utilizari corecte. Inițial acest framework a fost dezvoltat de firma TrollTech pentru ca mai apoi aceasta sa fie preluata in 2008 de producatorul de dispozitive mobile Nokia, care a creat o divizie speciala (Qt Development Frameworks Team) care se ocupa in mod special de dezvoltarea și promovarea acestui produs. In momentul de fața Qt este folosit in 3 variante de licențiere:

Varianta comerciala

Varianta cu licența LGPL (licența compatibila LGPL v2.1)

Varianta cu licența GPL.

Sistemele de operare pe care este suportat oficial sunt:

Linux/X11 – Qt pentru X Window System Unix Linux

Mac OS X – Qt pentru Apple Mac OS X Suport pentru aplicațiile peste API-urile Cocoa.

Windows – Qt pentru Microsoft Windows

Embedded Linux – Qt platforme incorporate PDA Smartphone, etc.)

Windows CE – Qt pentru Windows CE

Symbian– Qt pentru Symbian. Qt va inlocui framework-ul Nokia Avkon și va deveni kitul de dezvoltare UI pentru dezvoltarea aplicațiilor pentru Symbian.

Datorita faptului ca frameworkul a devenit open source, comunitatea a inceput sa dezvolte suport și pentru alte sisteme de operare cum ar fi:

Qt for OpenSolaris – Qt pentru OpenSolaris

Qt for Haiku– Qt pentru Haiku OS

Qt for OS/2– Qt pentru OS/2 eCS platform

Qt-iPhone dezvoltare experimentala Qt pentru iPhone

Android-Lighthouse dezvoltare experimantala Qt pentru Android

Qt for Amazon Kindle DX dezvoltare experimentala pentru Amazon Kindle DX

In continuare vom prezenta o parte din componentele multi-platforma puse la dispoziție de framework-ul Qt, pentru a ne putea face o idee despre facilitație pe care le pune la dispoziție, vom prezenta in continuare principalele funcționalitați pe care acesta incearca sa le inglobeze și anume:

interfața utilizator

access la baza de date

comunicații de rețea

procesare XML

fire de execuție

librarii de grafica 3D bazate pe OpenGL.

clase template

2.1 Interfața grafica

Qt-ul a fost dezvoltat in prima faza pentru a oferi dezvoltatorilor de software un mod comun de creare a interfețelor grafice care sa se integreze cu sistemul gazda pe care ruleaza aplicația. Din aceasta cauza in momentul in care se ruleaza o aplicație Qt aceasta va avea comportamentul și asemanarea standard intalnite pe sistemul de operare gazda. Desigur se pot realiza și interfețe grafice personalizate daca cei care dezvolta software-ul doresc acest lucru. In ultimele versiuni s-a Style Sheet-ul, un meta limbaj care ofera o flexibilitate deosebita atunci cand vine vorba de personalizarea elementelor care alcatuiesc interfața grafica. Avantajul folosirii acestui framework in momentul in care se dorește o personalizare a interfețelor grafice, este acela ca optimizeaza viteza de execuție și consumul de memorie.

2.2 Accesul la baze de date

Incepand cu versiunea 0 Qt ofera suport multi-platforma și independent de tehnologia de baze de date folosita. In acest fel, in momentul in care este nevoie de migrarea de la o tehnologie de baze de date la alta codul scris folosind Qt, ramane același sau modificarile aduse sunt minore. Acesta este un avantaj major pe care Qt-ul il aduce, comparativ cu alte framework-uri gen .NET. In prezent Qt ofera suport independent de tehnologie pentru majoritatea tehnologiilor de baze de date, importante cum ar fi:

Oracle

MSSQL

Sybase

MySQL

PostgreSQL

2. Fire de execuție

Qt pune la dispoziție de asemenea și funcționalitate pentru managementul firelor de execuție, aceasta funcționalitate fiind de asemenea independenta de platforma. Acest lucru este important deoarece Qt-ul reușește sa implementeze managementul firelor de execuție la nivelul aplicației, folosind API-urile specifice platformei pe care se executa codul, spre deosebire de Java, spre exemplu la care managementul se realizeaza la nivelul masinii virtuale.

2.4. Programare in rețea

Un alt modul important al acestui framework, este modulul de comunicare in rețea. Acest modul pune la dispoziție funcționalitate de nivel inalt pentru comunicații TCP/IP, UDP, implementeaza protocoale internet de uz comun HTTP, FTP

2.5 Clase template

O alta clasa de funcționalitați, foarte importanta, pusa la dispoziție de acest framework este reprezentata de clasele de tip template pentru manipularea colecțiilor de date, și implementarea de algoritmi optimizați pentru regasirea informației.

Analizand caracteristicile de mai sus, ne putem da seama ca acest framework este unul complet, oferind funcționalitatea necesara atat pentru abordarea proiectelor simple cat și pentru proiectele mai complexe. In același timp avand in vedere faptul ca acesta se bazeaza pe C++ și in urma compilarii se obține cod nativ, performanțele obținute prin dezvoltarea folosind acest framework sunt in mod clar superioare performanțelor care ar putea fi obținute prin dezvoltarea folosind framework-uri dezvoltate pentru alte limbaje de programare.

3 Modulul de monitorizare a parametrilor motorului

1 Descriere generala, justificare

Nu intotdeauna problemele care apar la motor pot fi detectate de ECU, și ca urmare acestea nu o sa fie raportate in momentul in care se face diagnoza cu soft specializat, de aceea este necesara posibilitatea urmaririi parametrilor live,  ai motorului de catre mecanic, inginer in vederea stabiliri unui diagnostic corect. O alta utilizare a acestui modul este data de necesitatea de monitorizare in momentul in care parametrii din fabrica sunt modificați. Acest lucru se realizeaza de obicei printr-un proces de chip tunning”, iar modulul de monitorizare poate fi utilizat pentru a observa in ce masura

parametrii motorului au fost modificați in urma acestui proces, putandu-se ajusta parametrii motorului pana in momentul in care se ajunge la nivelul de performanța dorit. Un alt scop pentru care poate fi folosit acest modul este evoluția in timp a semnalelor date de catre sondele lambda pentru a putea stabili daca acestea

funcționeaza la parametrii normali și daca se emit corect comenzile de formare a amestecului de combustibil-aer. Controlul defectos al acestui amestec duce la emisii de dioxid de carbon ridicate.

Sonda Lambda este un senzor amplasat pe tubulatura de evacuare și conectat la ECU, care in esența consta intr-un conductor de curent electric a carui intensitate variaza in funcție de cantitatea de oxigen care traverseaza sonda. In interiorul acesteia exista un material ceramic poros, din dioxid de zirconiu (ZrO2). Intensitatea curentului prin placa de zirconiu variaza in functie de numarul de molecule de oxigen care traverseaza materialul ceramic. Deoarece sonda functioneaza optim doar la temperaturi mari, „la rece”, pana cand gazele de eșapament ating temperaturi de 400-500 ^OC, sonda este incalzita de o rezistența din interiorul ei, dupa care caldura ii va fi furnizata chiar de temperatura gazelor de eșapament. Autoturismele cu motorizari euro 3 si 4 au chiar 2 sonde, una amplasata inaintea catalizatorului pentru optimizarea amestecului aer/combustibil, și una dupa catalizator, pentru verificarea eficienței acestuia. Constructorii recomanda verificarea sondei la fiecare 30 000 de kilometri sau la fiecare doi-trei ani de functionare a mașinii și schimbarea sondei in cazul cand apar probleme in funcționarea acesteia.

Instrumentele de urmarire a parametrilor motorului, puse la dispoziție de modulul de monitorizare sunt urmatoarele:

Vitezometru - cu afișare clasica (ac indicator) și afișare in format numeric

Turometru (numarul de rotații pe minut pentru motor) – afișare clasica (ac indicator) și afișare in format numeric

instrument pentru monitorizarea temperaturii in amestecului de racire

instrument pentru monitorizarea masei fluxului de aer pe galeria de admisie

intrument pentru monitorizarea presiunii pe galeria de admisie

instrument pentru determinarea poziției pedalei de accelerație

3.3.2      Detalii implemetare modul de monitorizare

Detalii de integrare cu aplicația principala

Pentru a putea realiza integrarea cu aplicația principala este nevoie de implementarea interfeței IADTPlugin, și actualizarea fișierului de configurare pentru aplicație. Acest mod facil de integrare este datorat in primul rand arhitecturi interfeței grafice care a fost gandita in așa fel incat sa poata fi extinsa in permanența, fara modificari ulterioare sau cu modificari minore.

class IADTPlugin

Dupa cum se poate observa plugin-ul trebuie sa puna la dispoziție metode pentru a putea seta interfața catre modulul care incorporeaza funcționalitatea principala. Funcționalitatea principala se refera la funcționalitatea folosita pentru a accesa datele primite de la dispozitivul de achiziție. Este nevoie de un nivel intermediar intre datele brute primite de la dispozitivul hardware interfața grafica, datorita faptului ca datele primite nu se afla intr-un format care sa permita o interpretare facila. Rolul nivelului intermediar este de a comunica prin intermediul dispozitivului hardware de achiziție, cu ECU (Engine Control Unit) și a prelua informațiile pe care sa le ofere nivelelor superioare in formatul dorit, mai pe scurt acest nivel are rolul unui translator, care permite comunicarea intre utilizator și modulul de control electronic al motorului.

Detalii de implementare a modulului de achiziție

Parametrii monitorizați de aplicație se rezuma la valori numerice, așadar nu este o problema daca pornim de la premisa ca toți parametrii pot fi caracterizați prin valori numerice reale. Acest lucru este foarte important in structurarea generala a ierarhiei de clase utilizata pentru accesarea valorilor citite de la senzori. Avand in vedere ca protocolul de comunicare intre modulul software de achiziție și dispozitivul hardware este relativ simplu și exista o similiaritate pentru achiziția pe diferiții senzori, o sa avem o parte de cod comuna pentru toate clasele care se ocupa de interpretarea datelor primite de la ECU. Transpus in programarea orientata pe obiecte, acest lucru este echivalent cu implementarea unei clase de baza care implementeze funcționalitatea comuna și mai apoi derivarea claselor care se ocupa de interpretarea rezultatelor din aceasta clasa. Pentru a va crea o imagine clara a acestui aspect se poate analiza diagrama UML care urmeaza:

Metoda care se ocupa efectiv de achiziția datelor este GetSensorData, care filtreaza informația primita de la dispozitivul hardware, elimina informațiile care nu sunt necesare, transforma informația din format ASCII in format binar și returneaza rezultatul la adresa de memorie specificata. Pentru a accesa dispozitivul hardware se folosește o interfața seriala emulata, deoarece conectarea dispozitivului la PC se realizeaza prin intermediul USB. Se realizeaza de fapt un „bridge” soft intre interfața seriala și interfața USB. Dispozitivul hardware de achiziție are in componența un circuit integrat FTDI care face conversia de la USB → UART RS-232 (procesorul dispozitivului de achiziție primește comenzi prin intermediul interfeței seriale). Producatorul acestui chip pune la dispoziție driver-ul pentru crearea unui port serial irtual, lucru care ii scutește pe cei care scriu aplicațiile de necesitatea scrierii de drivere pentru comunicarea prin USB și același timp asigura compatibilitatea cu vechile aplicații care foloseau interfața seriala pentru comunicarea cu dispozitivele hardware.

Așadar la nivel de aplicație interfața de comunicarea se vede ca o interfața seriala obișnuita.

Revenind la partea de cod, dupa implementarea clasei de baza care se ocupa de aducerea datelor brute de la Unitatea de control a motorului, este nevoie de interpretarea datelor pe care le-am primit in funcție de senzorul care a furnizat informația catre ECU.

Avand in vedere faptul ca timpul de raspuns este relativ mare și depinde de viteza bus-ului intern al autovehiculului este posibila de crearea unui mecanism intern care sa furnizeze informațiile intr-un mod rapid și eventual asincron. In acest sens este nevoie de memorarea temporara a datelor primite de la autovehicul, și interpolarea acestora pentru obținerea de aproximari. Astfel exista un fir de execuție separat care interogheaza ECU in vederea primirii informațiilor dorite, iar in momentul in care aceste informații sunt primite sunt puse intr-o zona de memorie comuna care va fi utilizata apoi in momentul in care modulul de monitorizare este solicitat pentru a furniza anumite informații. Acest lucru ne asigura de faptul ca nu se ajunge la situații in care sa fie probleme cu blocarea interfeței din cauza faptului ca modulul electronic intarzie in livrarea informației dorite, facand mai puțin vizibil efectul pe care il are comunicația lenta intre dispozitivul electronic și soft.

Detalii despre integrarea modulului de achiziție cu modulul de monitorizare grafica

BIBLIOGRAFIE

1.      www.scantool.net

2.      www.wikipedia.org

www.obd-codes.com