Testarea automata a sistemelor mecatronice

Introducere
Mecatronica reprezint o abordare a inginerilor care gestioneaz integrarea sinergic a mecanicii, electronicii, control, i tiina calculatoarelor n design de produs i fabricaie, cu scopul de a dezvolta, mbuntii i/sau optimiza funcionalitatea produsului. Abordarea ingineriei tradiionale de obicei este inadecvat sau nu reuete s ndeplineasc complexitatea dezvoltrii sistemelor. n particular, partea de program a devenit foarte important. De exemplu n industria automobilelor, uni experi sunt de prere c partea de program i electronic vor costa n jur de 50% din costul total, pentru automobilele convenionale i 80% pentru automobilele hibride n urmtorii 10 ani. Saltul de la electronic la programare reprezint provocri n procesul de verificare, validare i certificarea acestor sisteme. Pentru dezvoltarea testrii automate a acestor sisteme n sisteme cea mai bun metod o reprezint aceea a ingineriei de sistem bazate pe un model. Modelul ofer o cale integrat pentru a diminua complexitatea sistemelor de mari dimensiuni, oferind precizie i interfee multiple specificaiilor pentru analiz i design. Cu ajutorul automatizrii, modele pot oferi metode de eficientizare pentru dezvoltarea sistemelor incluznd analiz, design, implementare i verificare/validare. Verificarea i validarea sunt activiti de mare importan n dezvoltarea i design-ul sistemelor mecatronice. n funcie de complexitatea sistemului i n funcie de tehnicile de testare, numrul testelor pot fi foarte mare. Tehnica de testare folosind un model (MBT) este o metodologie care suport automatizarea pentru controlul calitii. Aceast tehnic automatizeaz testele pentru procesul de control al calitii prin generarea cazurilor de testare n funcie de specificaiile pe care modelul sistemului le indic.

Cerinele pentru testarea sistemelor mecatronice

Natura eterogen i complex a sistemelor mecatronice pune multe dificulti pentru procesul de testare. Testarea automat a sistemelor mecatronice trebuie sa ndeplineasc cerinele de mai jos: Eterogenitatea sistemele mecatronice conin att componente hardware ct i parte de program. Pentru ca testarea s funcioneze, aceste componente ar trebui s poat fi accesate printr-o interfa software care s suporte configurare automat, executare i monitorizare. Dependene externe exist cazul n care componentele sau sub-sistemele mecatronice s fie produse de diferii distribuitori, muli dintre acetia pot fi indisponibili la nceputul stadiului de dezvoltare. Configurarea intern sistemele mecatronice sunt de multe ori dezvoltate ca parte a unei familii de sisteme, mprind lucruri comune, n timp ce fiecare familie are funcionaliti comune. Implementarea configuraiei sistemele mecatronice trebuie s suporte diferite implementri ale scenariilor. Mentenan infrastructura testului trebuie s permit evoluia sistemului suspus testului cu un impact minim asupra testelor existente. Mai mult de att, noile teste trebuie s poat avea posibilitatea de a fi adugate cu un impact minim asupra testelor existente. Cerine non-funcionale sistemele mecatronice sunt de obicei folosite pentru suportul activitilor critice. De aceea ele sunt supuse unor norme i reguli. Programarea i executarea automat ntr-un final mrimea complexitii sistemelor va crete,i odat cu ea va crete i costul testelor, deoarece executarea, generarea i raportarea activitilor vor crete n importan.

Verificarea bazat pe un model

Abordarea UML in mecatronic permite dezvoltarea de sisteme complexe mecatronice. Componentele i modele pot fi folosite pentru a modela arhitectura i comportamentul n timp real. O nglobare continu de cazuri n structurile componente ierarhice permite controlerelor s se integreze n componenta modelului. Comportamentul discret al componentelor i modelelor este digramelor de stare n timp real sau de extensia hibrid,digramele de reconfigurare hibride. Conceptul furnizeaz caietul de sarcini i verificarea modular de reconfigurare pe mai multe componente. Abordarea mecatronic UML sprijin, de asemenea, tehnicile de control model pentru procesarea n timp real, la nivel de sisteme mecatronice conectate. Prin sprijinirea procedurii compoziional pentru modelarea i verificarea n timp real a software-ului, abordarea evit probleme de scalabilitate ntr-o mare msur.

Generarea automata de cazuri de testare de la contraexemple

Aa cum a propus Beyer [1], vom folosi un model checker pentru a genera urme realizate de modelul nostru. Acest lucru se realizeaz prin trecerea a unei constrngeri sub forma unei formule logice temporal la verificatorul model care se tie a nu fi ndeplinite de model. Modelul checker returneaz o urm de eroare care duce la o parte a modelului care ncalc constrngerea. Aceast urm este utilizat pentru a calcula valorile iniiale i finale pentru un test.

Generare cazuri de testare

Cazuri de testare

Executare teste

Criterii de abordare

Nivel satisfacut/ nesatisfacut

Start

Componenta Descompune

Digrame actualizate in timp real

Verificare Model

Localizeaza documentul

Generare constrangeri

Constrangeri

Extrage cazurile pentru testare

Criterii de acoperire

Figura 4 Generarea cazurilor pentru testare

Acoperirea testrii
Pentru a garanta o anumit acoperire de testare, am permis special constrngerile la verificatorul modelului adaptat de la principiul automatelor observator cum a fost propus de Blom [2]. Abordarea noastr se bazeaz pe accesibilitatea de elemente care urmeaz s fie acoperit. Noi folosim model checker pentru a genera o urm care s acopere un anumit element din Statechart Real-Time. O pies model poate fi folosit ca un instrument de generare urme. Prin adoptarea unei formule logice temporal negat, ne da o urm de un anumit statut n Statechart Real-Time. Pentru a realiza acest lucru, vom invoca modelul checker cu constrngerile speciale ale formularului AG s. Constrngerea este format dup cum urmeaz. Pentru a verifica cu model checker dac starea lui este accesibila, am putea folosi o formul de forma EF. Aa cum aceasta, desigur, va reui i nu va produce contraexemplu necesar, avem de verificat opusul proprietaii care modelul nu o ndeplinete i care, astfel, o cale care duce la starea lui este returnat. De aceea trebuie s negm formula avnd n vedere urmtoarea echivalen: EF s AG s.

Figura 5 Execuia testului

Abordri existente i lucrrile conexe

Literatura de specialitate a arhitecturii software pentru testarea integrat i sisteme mecatronice pare destul de rar. Tsai *1+ prezint un proces de a dezvolta cadre de testare orientate-obiect pentru testarea sistemelor integrate, i s se concentreze pe uurina dezvoltrii a programului de test. Procesul lor produce un test pentru un sistem specific, mai degrab dect un cadru personalizabil. Lieberman *2+ prezint un cadru de testare cu straturi de abstractizare i un fiier de configurare separat, cu toate acestea, stratul de sus se rezum la instrumente de testare, dect la componentele SUT (sistemului supus ncercrii). Chegi *3+ descrie o arhitectur care permite tester-ilor s schimbe transparent instrumente fr a rescrie scenarii, abstractizarea este la nivel de instrumente, nu SUT. Nici unul dintre aceste abordri nu includ faciliti precum crearea uoar i actualizarea configuraiei a unei soluii integrate, ci mai degrab sprijinirea testrii sistemelor mecatronice de o combinaie de soluii comerciale slab-integrate i specifice industriei cum este ilustrat n figura 1. Acestea includ: cadre de captare hardware [4], motoarele de test de execuie, si instrumente de testare bazate pe modele *3+, *14+. n timp ce aceste abordri se adreseaz individual, problemele specifice pe diferite niveluri de abstractizare, rmn slab integrat, mpiedicnd adoptarea lor n medii industriale.

Abordare bazat pe model

Ex: SmartTesting, tedesco, Qtronic

Generare

Abstractizare

Motoarele /Platformele de executare a testelor

Ex: TestStand, Mathworks, Simulink, NUnit

Interfaa Hardware i Configuraia

Ex: mechatronics ATI

De exemplu, cadrele de testare, cum ar fi mecatronica ATI (infrastructura de testare automat) *4+, se arat n figura 2, sunt utilizate n cadrul SIEMENS pentru testarea sistemelor de alarm de incendiu. Acestea susin testarea sistemelor n desfurarea a diferitelor configuraii i scenarii. ATI se concentreaz pe furnizarea a unei interfee software pentru dispozitivele hardware, care permite programe de testare pentru a fi produse pentru diferite configuraii hardware.

Generare Manual

Tester

Generare Manual

Programare TestStand

NI TestStand
Executare teste

Configurare sistem

ATI Strat de abstractizare Hardware n bucl Software n bucl

Figura 2 Infrastructura testelor automate (ATI) principalele elemente i procese

n special, ATI susine strategiile ca "hardware n bucl" (HIL) i "Simulator (sau software), n bucl" (Sil), care permite testarea (incomplet) sistemelor mecatronice integrate i n diferite configuraii. n timp ce cadrele, cum ar fi dependenele externe, configurabilitate intern i ntreinere a infrastructurilor de testare, extinderea lor, configurarea i utilizare este n mare parte manual, consumatoare de timp i predispus la erori. La un alt nivel de abstractizare, off-the-shelf testele cu motoare de execuie, cum ar fi TestStand i Simulink, automatizeaz executarea de cazuri de testare, precum i generarea de rapoarte de ncercare. Ei susin testarea manual a script-urilor complexe, scrise la un nivel nalt in software-ul API SUT. Ca atare, ele sunt potrivite pentru cadrele ATI, oferind automatizrii teste de execuie. n ciuda beneficiilor lor, motoarele de test de execuie necesita n continuare dezvoltarea manual de cazuri de testare, o consumatoare de timp, i activitatea poate produce erori, care necesit o mulime de aptitudini. Ele produc, de asemenea, script-uri de testare, care sunt strns legate de infrastructura de baz, necesitnd ntreinere de testare constant care stau la baza modificrilor SUT i s evolueze.

De exemplu, tedeso este un instrument extensibil de testare, bazat pe modele care accept diferite etape de testare: de la specificaiile sistemului, verificarea modelului bazat pe reguli, generare de testare, i codul i raportul generat. O trstur distinctiv a tedeso este sprijinul pentru extensibilitate i configurabilitate a caracteristicilor sale prin intermediul plug-in-uri (reprezentate ca baloane albe din figura 3).

Figura 3 Abordarea general a elementelor tedeso

Prin utilizarea acestor mecanisme, tedeso poate fi integrat cu instrumentele i abordrile existente fa de nevoile clientului. n timp ce abordrile MBT se concentra pe strategii de generare de testare i algoritmi de acoperire, ele nu rezolva problema eterogenitii, dependenei externe i generarea de configuraii. Ele nu sunt n general responsabile pentru executarea cazurilor de testare generate, nici nu se ocup de interfaa ntre componentele hardware i software. n schimb, ele se bazeaz pe executarea de teste existente i cadre.