QReferate - referate pentru educatia ta.
Referatele noastre - sursa ta de inspiratie! Referate oferite gratuit, lucrari si proiecte cu imagini si grafice. Fiecare referat, proiect 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 » Referate informatica

Ingineria sistemelor in simapa





INGINERIA SISTEMELOR IN SIMAPA



Procesul ingineriei de sistem inerent in ansamblul ciclului de viata al unui sistem, asa cum este aratat in figura 1. Importanta care i se da este ilustrata in abordarea unui ciclu de viata in mod integrat, desfasurat al proiectarii si dezvoltarii sistemului, convenita prin activitatile reprezentate in blocurile 0.1 la 4.6. Aceasta include problema definirii si identificarii nevoilor clientului, rezultatul analizei fiabilitatii, dezvoltarea cerintelor operationale si a conceptului de mentenanta si intretinere, analiza functionala, cerintele alocarii s.a.m.d. Ca urmare, apare un proces iterativ de asignare si validare a sistemului si de incorporare a modificarilor pentru imbunatatirile produsului / procesului asa cum este aratat in figura 1.1 Desi procesul este mai mult indreptat catre etapele initiale ale proiectarii si dezvoltarii sistemului, pastrand perfectionarea activitatilor in fazele ulterioare ale constructiei / productiei, operarea sistemului si intretinerea si mentenanta sistemului sunt esentiale pentru intelegerea consecintelor deciziilor anterioare si stabilirea testelor pentru viitor. Cu alte cuvinte, feedback-ul este critic si constituie o parte integranta a procesului ingineriei de sistem.1



Referindu-ne la figura, fazele si obiectivele asa cum sunt prezentate nu au intentia de a se transforma intr-un foarte complex cu etape specificate sau nivele de initializare. Figura intentioneaza sa reflecte un proces de ansamblu aplicabil in achizitionarea sistemului. Cu privire la tipul, dimensiunea si complexitatea sistemului sunt prezentate aici: o cerinta de proiectare conceptuala (pentru a include analiza cerintelor), o cerinta de proiectare preliminara s.a.m.d. De fiecare data cand apare o noua cerinta pentru sistem trebuie sa o dezvoltam intr-un proces "ajustat" corespunzator sistemului particular caruia i se adreseaza.

Inerente procesului ingineriei de sistem (definit prin blocurile 0.1 la 0.8 pentru sistem, blocurile 1.1 la 1.7 pentru subsistem, etc.) sunt cerintele cu privire la logistica si proiectarea intretinerii cum este ilustrat in relationarile identificate in figura 1.7. Trebuie sa incepem cu problema definirii si cu analizarea nevoilor, rezultatul analizei fiabilitatii si selectia tehnologiilor bazate pe factorii ciclului de viata, dezvoltarea cerintelor operationale ale sistemului si a conceptului de intretinere si mentenanta, analiza functionala si identificarea functiilor mentenantei, cerintele alocarii si dezvoltarii criteriilor de proiectare a intretinerii, optimizarea proiectului si evaluarea alternativelor, luand in considerare factorii descrisi in Capitolul 2 s.a.m.d.

Obiectivul acestui capitol este de a descrie procesul ingineriei de sistem si acele activitati din interiorul acestui proces ce au legaturi cu si influenteaza logistica si proiectarea intretinerii. Figura 2 identifica pasii de baza in ciclul de viata al unui sistem, reprezentand arii cheie ale initializarii prin blocurile desenate ingrosat.


1. Definirea analizei problemelor si nevoilor


Procesul ingineriei de sistem incepe in general cu identificarea a ceea ce se "vrea" sau "doreste" pentru ceva anume si este bazata pe o deficienta reala (sau perceputa). De exemplu, capacitatile din exploatare nu sunt adecvate in termenii indeplinirii unor anumite performante cerute, nu sunt disponibile cand este nevoie, nu pot fi intretinute in mod adecvat, sunt prea













Figura 1. Cerintele sistemului tehnic de - a lungul ciclului de viata



















Figura 2. Pasii ciclului de viata al sistemului


costisitoare in operare s.a.m.d. Ca rezultat o noua cerinta de sistem este definita simultan cu prioritatea introducerii datei cand noile capacitati de sistem sunt cerute pentru uzul clientului si se estimeaza resursele necesare pentru achizitionarea noilor capacitati de sistem. Pentru a asigura un bun inceput, o "declaratie a problemelor" ar trebui prezentata in termeni specifici calitativi si cantitativi cu destule detalii pentru a justifica progresul la urmatorul pas.

Cerinta pentru identificarea nevoii (ca un punct de start) ar putea parea mai degraba "de baza", sau evidenta. Cu toate acestea, gasim deseori ca un anumit efort in proiectare este initiat ca un interes personal sau ca un capriciu politic, fara a avea de la inceput clar definite cerintele pentru acesta! In aria software-ului exista o anumita tendinta de a indeplini o suma de cerinte inainte ca acestea sa fie identificate. In plus, sunt cazuri in care inginerul crede cu tarie ca stie care sunt nevoile clientului, fara a fi implicat beneficiarul in acest proces. Filozofia "proiecteaza acum, repara mai tarziu" releva ca, in schimb, este mai degraba costisitor.

Definirea problemei este cateodata cea mia dificila parte a procesului, in mod particular daca cineva este grabit sa "ii dea drumul". Totusi, numarul "starturilor false" si a riscurilor ulterioare poate fi semnificativ daca nu este pusa o baza solida de la inceput. O descriere completa a nevoii, exprimata in parametrii de performanta cantitativi, unde este posibil, este esentiala. Este important ca rezultatele sa reflecte o cerinta reala a beneficiarului, mai ales in conditiile zilelor de astazi, cand resursele sunt limitate.

Fiind data definirea problemei, analiza nevoilor trebuie sa fie indeplinita cu obiectivul traducerii a ceea ce se vrea intr-o cerinta mai mult decat specifica a unui anumit nivel al sistemului. Intrebarile sunt: Ce se cere de la sistem in termeni functionali? Ce functii trebuie sa indeplineasca sistemul? Care sunt functiile primare? Care sunt functiile secundare? Ce trebuie indeplinit pentru a micsora o anumita deficienta? Cand trebuie aceasta sa fie indeplinita? Unde trebuie sa fie indeplinita? De cate ori? Sunt multe intrebari de baza de aceasta natura si este important sa descriem cerintele beneficiarului intr-o maniera functionala in ideea evitarii unui angajament prematur pentru un concept de proiectare specific sau o anumita configuratie, si astfel cheltuieli nenecesare sau resurse pretioase. Obiectivul final este de a defini "CE-ii" si nu "CUM-ii".

Indeplinirea analizei nevoilor intr-o maniera satisfacatoare poate fi bine realizata intr-o abordare de "echipa", implicand beneficiarul pana la ultimul utilizator (daca este diferit de consumator), contractantul sau producatorul si cei mai importanti furnizori dupa caz. Obiectivul este ca exista o buna comunicare intre partile implicate. In continuare "vocea clientului" trebuie sa fie auzita si proiectantul de sistem trebuie sa raspunda in concordanta.


2. Analiza fezabilitatii sistemului


Prin analiza nevoilor, sunt identificate functiile pe care trebuie sa le indeplineasca sistemul. Ar putea fi o singura functie cum ar fi "transportul produsului XYZ de la puntul A la punctul B" sau "comunicare intre punctele D, E si F" sau "produceti X cantitate din Y produse in timpul Z". Pe de alta parte, ar putea exista un numar de diferite functii ce trebuie indeplinite - unele primare si unele secundare. Pentru a asigura o buna proiectare, toate functiile posibile trebuie identificate, cele mai riguroase functii selectate ca o baza in definirea cerintelor de proiectare la nivel de sistem. E important ca toate posibilitatile sa fie luate in calcul pentru a asigura faptul ca tehnologiile si componentele corespunzatoare sunt selectate pentru consideratii de proiectare.

Analiza fezabilitatii este indeplinita cu obiectivul evaluarii unor abordari tehnologice diferite, ce pot fi considerate raspuns al unor cerinte functionale specificate. Considerand diferite abordari de proiectare, sunt investigate tehnologii de aplicate alternative. De exemplu: in proiectarea unui sistem de comunicatii ar trebui sa folosim tehnologia fibrelor optice, celulara sau o abordare conventional cablata? In proiectarea unei aeronave, pana unde trebuie sa extindem incorporarea materialelor compozite? Cand proiectam un automobil, trebuie sa aplicam circuite integrate de foarte mare viteza in anumite circuite de control, sau trebuie sa alegem o abordare electromecanica conventionala?

Este necesar sa (1) identificam toate alternativele posibile ce vor indeplini cerintele; (2) monitorizam si evaluam cei mai posibili candidati in vederea atingerii performantelor, eficacitatii, cerintelor logistice si criteriilor economice; (3) selectam o abordare potrivita. Obiectivul este sa selectam o abordare tehnica generala si nu specificarea anumitor componente. Ar putea fi multe alternative diferite; cu toate acestea, numarul posibilitatilor trebuie micsorat la optiunile fiabile luand in considerare resursele disponibile (de exemplu: mana de lucru, materiale si bani).

Este specific primelor stadii din ciclul de viata (de exemplu: faza proiectarii conceptuale) cand sunt luate deciziile importante relativ la adoptarea unei abordari de proiectare specifice. Cand nu sunt destule informatii disponibile, ar putea fi initiata o activitate de cercetare cu obiectivul dezvoltarii unor noi metode / tehnici pentru aplicatii specifice. In anumite programe, realizarea sarcinilor de cercetare si activitatilor de proiectare preliminare sunt indeplinite secvential, in timp ce in alte situatii, ar putea fi un numar de miniproiecte diferite in desfasurare in acelasi timp.

Rezultatele analizei fiabilitatii vor avea un impact semnificativ nu numai asupra caracteristicilor operationale ale sistemului, dar si asupra productiei si cerintelor de mentenanta. Selectarea (si aplicare) unei tehnologii date are implicatii asupra mentenabilitatii si fiabilitatii si ar putea avea un impact semnificativ asupra cerintelor pentru piesele de rezerva si echipamentelor de testare, metodelor de fabricatie si va influenta semnificativ costul ciclului de viata.


Cerintele operationale ale sistemului


O data ce au fost identificate nevoile unui sistem, este necesar sa "identificam" aceste nevoi in termenii unor cerinte operationale anticipate. In acest punct, trebuie puse urmatoarele intrebari: Care sunt cantitatile anticipate de echipament, software si personal si unde sunt ele localizate? Cum va fi utilizat sistemul si pentru cat timp? Cum va fi intretinut sistemul si de catre cine? Care este mediul inconjurator previzionat in fiecare loc operational (de exemplu: situarea utilizatorului)? Raspunsurile la aceste intrebari vor duce la definirea caracteristicilor de operare ale sistemului, la conceptul de intretinere si mentenanta a sistemului si la identificarea in linii mari a criteriilor / a modului de proiectare specific. Conceptul operational, asa cum este definit aici si ilustrat de blocul 1din figura 1.7 include urmatoarele informatii:


  1. Definirea misiunii - identificarea functiei principale a sistemului si a functiilor secundare sau alternative. Ce anume trebuie sa indeplineasca sistemul? Cum va indeplini sistemul obiectivele sale? Functia poate fi definita prin unul sau mai multe seturi de scenarii, sau profiluri operationale. Este importanta identificarea "dinamicii" caracteristicilor de operare ale unui sistem.
  2. Performantele si parametrii fizici - definirea caracteristicilor de operare sau a functiilor sistemului (de exemplu: dimensiunea, greutatea, plaja de functionare, precizia, capacitatea, transmisia, receptia, etc.). Care sunt parametrii de performanta critici ai sistemului?
  3. Desfasurarea operationala sau distributia - identificarea cantitatii de echipament, software, personal, facilitati s.a.m.d. si localizarea geografica previzionata pentru a include cerintele de transport si mobilitate. Cat de mult echipament si software asociat este repartizat si unde va fi acesta localizat? Care sunt factorii care determina ca sistemul sa fie complet operational?
  4. Ciclul de viata operational (orizontal) - timpul anticipat de operare a sistemului. Care este inventarul total de-a lungul ciclului de viata al sistemului? Cine va opera sistemul si pentru ce perioada de timp?
  5. Cerinte de utilizare - modul de utilizare anticipat al sistemului si elementele sale (de exemplu: ore de operare / zi, procentaj din capacitatea totala, cicluri de operare / luna, posibilitati de incarcare, etc.). Cum va fi sistemul utilizat de beneficiar sau de operator la locul de actiune? 
  6. Factorii de eficacitate - cerintele sistemului specificate ca factori de merit, cum ar fi: cost / eficacitatea sistemului, disponibilitatea operationala, rata de buna functionare, fiabilitatea, eficacitatea intretinerii suportului logistic, timpul mediu de buna functionare (MTBM), rata de defectare (l), timpul mediu de defectare (MDT), usurinta in utilizare (in procente), nivelul aptitudinilor si al cunostintelor necesare operatorului, eficienta personalului s.a.m.d. Acestea fiind date, sistemul va "functiona"; cat de eficient si eficace va fi?
  7. Mediul inconjurator - definirea mediului in care se asteapta ca sistemul sa opereze (de exemplu: temperatura, umiditate, teren muntos sau plan, aeropurtat, la sol, imbarcat, etc.). Acestea ar trebui sa includa un domeniu de valori aplicabil si ar trebui sa acopere toate modurile de transportare, manipulare si depozitare. Cum va fi manipulat sistemul in tranzitare? La ce va fi supus sistemul in timpul operarii si pentru cat timp? Ar trebui dezvoltat profilul complet al mediului inconjurator.

O discutie ulterioara asupra cerintelor operationale ale unui sistem este foarte bine ilustrata in trei exemple. Primul grafic este un sistem de aeronava cu o distributie mondiala. Al doilea este un sistem de comunicare cu aplicatii la sol si aeropurtate. Al treilea se refera la cerintele liniilor aeriene comerciale in functie de o zona specifica urbana. Aceste grafice sunt discutate numai pana la nivelul necesar de a arata relationarea cu diferitele aspecte ale suportului logistic.


Exemplul 1 - sistemul aviatic



Un sistem aviatic este achizitionat si desfasurat in mari cantitati in lume. Locatiile geografice anticipate, cantitatile estimative pe locatie, timpul mediu de utilizare a sistemului sunt aratate in figura 3-

Aria geografica

anul

Totalul sistemelor











America de nord si de sud












Europa












Orientul mijlociu












Africa de sud












Pacific-zona 1












Pacific-zona 2












Total













Figura 3 Cerintele operationale ale sistemului


Figura 4 Tipurile de sisteme operationale


Aeronava trebuie sa fi operationala, atat pe bazele aeriene de pe uscat, cat si de pe portavioane.

In termenii unei misiuni, fiecarei aeronave i se va cere sa zboare in trei profiluri diferite de misiune, asa cum este aratat in figura 3-3 si descris in "Specificatia 12345". In principal, o aeronava va fi pregatita pentru zbor, decolare si un scenariu specific complet al unei misiuni, intoarcerea la baza, controalele specifice si readucerea intr-o stare de "gata de misiune". Pentru scopurile planificarii, toate aeronavele vor trebui sa fie gata de zbor cel putin o data pe saptamana in una dintre cele 3 tipuri de misiune.

Aeronava va indeplini cerintele de performanta ale cerintelor sistemului in concordanta cu specificatia 12345, disponibilitatea operationala (A0) va fi de cel putin 90%; timpul mediu de defectare (MDT) nu va depasi 3 ore; Mct va fi de 30 minute sau mai putin si Mmax la 90% va fi de 2 ore; MMH / OH va fi de 10 sau mai putin; costul de intretinere la nivelul organizational nu va depasi 1000 Aeronava va avea incorporat un sistem de autotestare ce va permite depistarea defectelor la nivelul blocurilor cu o precizie de autotestare de 85%. Nu va fi permis echipament de intretinere special.

In termeni ai intretinerii sistemului la cel mai inalt nivel, trebuie sa existe posibilitatea unei intretineri la un nivel mediu, localizata la fiecare baza / portavion operational(a). In plus vor exista 2 locuri unde se va asigura intretinerea la nivel de hangar. Intregul concept de intretinere este ilustrat in figura 5.

Desi informatia prezentata anterior este mai degraba sumara, avand in vedere intregul spectru al cerintelor operationale ale sistemului, este necesar din punct de vedere logistic sa definim (1) scenariul(iile) misiunii in scopul identificarii secventelor operationale, a factorilor de stres ce actioneaza asupra sistemului, cerintelor de mediu si fiabilitatea sistemului sau frecventa anticipata a intretinerii; (2) multimea problemelor si a pozitiilor geografice in scopul determinarii magnitudinii intretinerii si determinarii locului unde suportul logistic va fi cerut; (3) ciclul de viata operational pentru a se determina durata intretinerii si a cerintelor de baza pentru aprovizionare; (4) eficacitatea factorilor in scopul determinarii frecventei, nivelului de intretinere si a resurselor anticipate ale suportului logistic, ce vor fi cerute. In esenta, intregul concept prezentat in figurile 3, 4 si 5 (subliniat de factori calitativi si cantitativi specifici) trebuie definit in ideea stabilirii unei directii de baza viitoare pentru intretinerea sistemului.


Exemplul 2 - sisteme de comunicatie


Un nou sistem de comunicatii radio cu o capacitate de acoperire mai mare si cu o fiabilitate imbunatatita este impus pentru a inlocui cateva dintre sistemule existente, ce sunt in prezent desfasurate in mari cantitati pe tot Globul. sistemul trebuie sa indeplineasca trei misiuni de baza.


Primul tip de misiune. Sistemul va fi instalat pe avioane usoare, ce evolueaza la altitudini mici (3000 m sau mai putin), un sistem / aeronava. Sistemul va fi capabil sa permita comunicatia cu vehicule situate la sol, dispersate intr-un teren muntos sau plan si cu posibilitatea unei comunicatii centralizate in zona. Se anticipeaza ca fiecare aeronava va avea 15 misiuni pe luna, cu o durata medie a unei misiuni de 2 ore. Un profil tipic de misiune este ilustrat in figura 6. Utilizarea sistemului de comunicatie este impusa a fi de 110% (1,1 ore de operare a sistemului, pentru fiecare ora de operatiune aeriana ce include timpul in aer plus o anumita perioada de timp la sol). Sistemul trebuie sa fi disponibil operational 99,5% din timp si sa aiba o fiabilitate MTBF de nu mai putin de 2000 de ore.



Al doilea tip de misiune. Sistemul va fi instalat ca echipament al unui vehicul la sol (de exemplu: masina, camioane usoare sau echivalent), cate unul pe fiecare vehicul. Sistemul va permite comunicarea cu alte vehicule la o distanta de 328 km pe un teren aproximativ plan, cu o aeronava situata la o altitudine de 3000 m sau mai putin si cu un punct central de comunicatii in zona. 65% din vehicule vor fi operationale in orice punct si orice moment si sistemul va fi utilizat 100% din acest timp pentru vehiculele operationale. Sistemul trebuie sa aiba o fiabilitate MTBF de cel putin 1800 ore si o Mct de 1 ora sau mai putin.

Figura 5 Profilul misiunii


Al treilea tip de misiune. Sistemul va fi instalat in 20 de centre de comunicatie zonale, situate de-a lungul globului cu cate 5 sisteme operationale in fiecare centru. Sistemul va permite comunicarea cu aeronave in zbor la altitudini de 3000 m sau mai putin pe o raza de 800 km fata de centru si cu vehicule aflate la sol pe o raza de 480 km pe teren aproximativ plan. 4 dintre sisteme vor fi utilizate 24 ore / zi in timp ce celelalte sisteme sunt de rezerva si folosite in medie 6 ore / zi. Fiecare sistem operational va avea o fiabilitate MTBF de cel putin 2500 ore si o Mct de 30 minute sau mai putin. Fiecare centru de comunicatie va fi localizat pe un aeroport.


In scopul diminuarii costului intretinerii (de exemplu: echipament de testare si intretinere, piese de rezerva, personal, etc.) statiile de emisie-receptie, care sunt un element important al sistemului, vor fi proiectate la modul general in vederea aplicatiilor la sol si aeropurtate si a celor care implica transportul cu vehiculele. Configuratia antenei poate fi particulara pentru fiecare caz in parte.   

Echipamentul operational de baza va fi introdus pe inventar in 4 ani incepand cu data curenta si restul echipamentului va fi achizitionat pe perioada a 8 ani. Eventualele imbunatatiri vor avea loc pe durata a 10 ani, dupa care sistemul se va casa gradual functie de uzura. Ultimele echipamente se asteapta sa fie scoase din uz in 25 de ani. O asemenea planificare de program este ilustrata in figura 7.


Asa cum s-a inceput anterior, noul sistem va inlocui anumite sisteme localizate pe glob. In special, cerintele sunt dictate de nevoia a:


20 de centre de comunicare centralizata

11 aeronave ce inzestreaza fiecare centru de comunicare


55 de vehicule destinate fiecarui centru de comunicare.


Figura 7 Planificare de program




Bazandu-ne pe cele 3 tipuri de misiune definite, apare o cerere totala pentru 1420 de echipamente primare situate intr-o serie de retele de comunicatie (intregul sistem), asa cum este ilustrat figura 8.


O buna definire a desfasurarii sistemului operational planificat (chiar daca se fac anumite presupuneri) este necesara pentru determinarea elementelor cerute ale suportului logistic si a locului unde se vor afla acestea. De exemplu, stim ca sunt impuse 1420 de echipamente de baza si ca vor fi situate in anumite locuri (determinate de necesitati) pe masura producerii lor. Este nevoie sa stim cantitatile de echipament instalate in locurile prevazute, timpul de folosire, distantele si mediul inconjurator operational pentru a se determina:


1. Echipamentul de intretinere si testare (pentru a se include cerintele de transport si manipulare), ce trebuie sa fi transportat, instalare si verificarea sistemelor la sosirea lor in bazele operationale.


2. Cerintele de personal si pregatire pentru exploatarea si intretinerea sistemului.


Tipul si cantitatile pieselor de rezerva, cerintele de inventar s.a.m.d. pentru intretinerea sistemului.


4. Datele tehnice, inclusiv instructiunile de instalare si operare a sistemului.


5. Facilitatile de procesare, operare si instalare a echipamentului.


Cerintele suportului logistic sunt identificate prin defectarea echipamentului indicat de blocurile 1, 2, 3 si 5 din figura 2.3 Dimensiunea si perioada suportului logistic este dependenta de fabricarea sistemului si de rata de livrare acestuia specificata in orarul programului (figura 7).

In sprijinul planificarii programului si al nevoilor de baza este necesara schitarea unui grafic de inventar al echipamentului, asa cum este aratat in figura 9. Aceasta va oferi o indicatie asupra cantitatii totale de echipament de baza in inventarul beneficiarului pe timpul oricarui an din ciclul de viata. Partea finala a graficului reprezinta rata de productie, care, bineinteles, poate varia in mod considerabil, depinzand de tipul si complexitatea echipamentului, de capacitatea liniei de productie si de costul productiei. Cantitatea totala de echipament de baza produsa este de 1491, care presupune (1) ca 5% din echipament se va defecta in decursul a 10 ani de folosinta datorita unor pierderi sau unor defectari care depasesc posibilitatile financiare de reparare si (2) ca productia este realizata intr-un singur ciclu de productie (pentru a se evita costurile de oprire si pornire a productiei). Cu alte cuvinte, presupunand ca productia are loc in mod continuu, 1491 de echipamente trebuie produse pentru a acoperi degradarea si totusi sa mentina cerintele operationale a 1420 de sisteme de-a lungul unei perioade de 10 ani. Dupa aceasta perioada numarul sistemelor se reduce prin degradare si / sau casare datorita imbatranirii pana in momentul in care inventarul este complet epuizat.

Cand se fac previzionarile pentru cerintele logisticii in vederea intretinerii sistemului (de exemplu: asigurarea tipului de echipament ilustrat in figura 2.33) trebuie sa determinam mai intai cererea pentru mentenanta. Aceasta fiind data, este necesar sa dezvoltam conceptul de mentenanta a sistemului asa cum este descris in sectiunea 4. Cererea pentru intretinerea sistemului este data de o analiza a profilului de inventar, de localizare a echipamentului, de utilizare a sistemului, de fiabilitate a echipamentului s.a.m.d.   


Graficul din figura 9 indica numarul total de echipamente de inventar in orice moment dat (de exemplu: 1420 / an pentru o cerere de 10 ani). Datele de desfasurare operationala vor indica localizarea specifica a echipamentului si factorii de utilizare vor oferi informatii asupra orelor de operare a sistemului. Desi utilizarea va varia de fapt de la o baza operationala la alta, cerintele misiunii descrise anterior sunt folosite in scopul planificarii.


Figura 8. Evolutia echipamentelor din inventar


Intentia este de a determina numarul total de ore de operare a sistemului pentru fiecare an din profilul inventarului (figura 9). Considerand fiecare an din cei 10 de intrebuintare integrala, putem calcula numarul total de ore astfel:


total ore / an (cantitatea de echipamente) X (orele anuale de folosire / echipament) (1)

sau

(20 de facilitati de comunicatie) X (4 echipamente) X (24 ore / zi) X

si

(20 de facilitati de comunicatie) X (1 echipament) X (6 ore / zi) X

si

(220 echipamente aeropurtate) X (30 ore / luna) X (1,1 utilizari) X (12) = 87.120

si

1100 echipamente pentru vehicule) X (65%) X (24 ore / zi) X (360) = 6.177.600

si

total ore / an = 6.999.120


totalul orelor pentru vehicul

MTBF

 
Astfel, durata totala de folosire a echipamentelor de baza in fiecare an pe o perioada de 10 ani este de 6.999.120 ore. Utilizarea intre integrarea in sistem si pana la scoaterea din uz este determinata cu aceleasi metode, cu exceptia faptului ca este redus numarul sistemelor. Utilizand factorul de fiabilitate MTBF specificat pentru fiecare misiune (aeropurtat, auto si la sol) putem previziona numarul mediu al operatiunilor de intretinere / reparatie, ce pot aparea ca rezultat al caderilor sistemului. De exemplu,

operatii de intretinere pentru sisteme ce includ vehicule (2)




  sau

actiuni de intretinere = = 3432 / an


Pentru fiecare baza de comunicatie centralizata unde suportul logistic este concentrat (55 de vehicule pe aria acoperita de o baza de comunicatie), cantitatea asteptata a actiunilor de intretinere datorita defectarilor este:



 

actiuni de intretinere = = 171 / an / baza


Luand in considerare factorii Poison discutati anterior, putem previziona cantitatea pieselor de schimb / de reparat. Prin analizarea fiecarei actiuni de intretinere, putem determina MDT, Mct, MMH / OH si resursele suportului logistic asociat.

Definirea cerintelor operationale pentru sistemul de comunicatie radio (de exemplu: utilizare, factori de eficacitate, arie de acoperire, etc.) ofera bazele determinarii conceptului de intretinere (cu referire la sectiunea 4) si identificarea fiabilitatii specifice, mentenantei si factorilor cantitativi logistici. In schimb, aceste date sunt implicate ca marimi de intrare pentru analizarea proiectarii si intretinerii sistemului. O data cu progresarea in dezvoltarea sistemului, cerintele operationale ale sistemului de comunicatie sunt mai degraba imbunatatite (avand o baza iterativa). Prezentarea unui concept operational la conceperea unui program este obligatorie pentru stabilirea unui punct de reper pentru etapele urmatoare ale programului.


Exemplul 3 - cerintele unei linii aeriene comerciale


3 companii de linii aeriene comerciale isi propun sa serveasca un mare oras pentru 8 ani. Deoarece se preconizeaza o crestere, si alte companii aeriene s-ar putea implica ulterior. In vederea planificarii, cerintele combinate anticipate de transport a pasagerilor sunt prezentate in figura 10. Cerintele pentru posibilul trafic aerian sunt:

Sosirile / plecarile anticipate ale avioanelor (vezi figura 10):



Zona orara

Zborurile anticipate intr-o zi

Punctul A

Punctul B

Punctul C

Punctul D

6:00 a.m. la 11:00 a.m.





11:00 a.m. la 4:00 p.m.





4:00 p.m. la 9:00 p.m.





9:00 p.m. la 6:00 a.m.





Total







Figura 10 prezentarea cerintelor pasagerilor


Sosirile zborurilor sunt impartite in mod egal in perioadele de timp indicate. Se presupune ca incarcarea medie pe fiecare zbor este de 100 de pasageri.


2. Disponibilitatea operationala a avioanelor este de 95%. Cu alte cuvinte, 95% din zboruri trebuie sa fie complet operationale atunci cand sunt programate (restul fiind oprite datorita starii vremii). Factorii permisivi pentru intretinerea prevazuta si incarcarea pasagerilor sunt:


Functia

Frecventa

Timpul de nefunctionare

Pregatirea nemijlocita

La fiecare zbor

30 minute

Pregatirea la intoarcere

Dupa fiecare revenire la baza

1 ora

Verificarea finala

La sfarsitul fiecarei zile de zbor

6 ore

Controlul profilactic

15 zile

9 ore


Verificarile periodice si principale vor fi realizate in alta parte.


Intretinerea neprogramata acceptata in acest caz, se va limita la nivel organizational si va include inlocuirea anumitor elemente, schimbarea cauciucurilor si inlocuirea motorului in functie de cerinte. Limitele timpului de nefunctionare (MDT) sunt:


schimbarea motorului 6 ore

schimbarea cauciucurilor 1 ora

alte probleme 1 ora.


4. Aeroportul trebuie sa ofere necesarul de mijloace de intretinere a urmatoarelor tipuri de avioane (incarcate complet): F-28, B-727, B-737, B-747, DC-10, L-1011 si V/STOL. In plus, trebuie asigurate mijloacele pentru manevrarea si depozitarea incarcaturii.


Companiile aeriene au remarcat necesitatea serviciului de transport aerian pentru o zona urbana. Din punct de vedere al liniilor aeriene, zona urbana trebuie sa ofere resursele logistice necesare (echipament de testare si intretinere, personal, facilitati s.a.) pentru a sprijini acest serviciu. Aceasta implica selectarea unui loc adecvat transportului aerian; proiectarea si constructia aerodromului, achizitionarea echipamentului de intretinere si testare, a partilor de rezerva / reparare, personal cu instructaj adecvat si date pentru sustinerea operatiunilor aeriene; mentinerea la intreaga capacitate in mod sustinut de-a lungul intregii perioade planificate.

Datorita dimensiunii programului si a caracteristicilor de dezvoltare aratate in figura 10, constructia este planificata pe 3 etape. Orarul programului este prezentat in figura 11.

Primul pas este selectarea locului pentru aerodrom. Procesul de selectie va lua in considerare terenul disponibil, structura geologica a acestuia, efectele vantului, distanta fata de zona urbana, accesul pe autostrada si sau transportul public, cerintele ecologice si de zgomot si costul. Odata ce a fost stabilit locul, constructia trebuie sa includa pistele, zonele de parcare, echipamentul de control al zborurilor, terminalele aeriene, turnul de control, cladirile operationale, hangarele, docurile de intretinere, docurile de carburant, posibilitatile de manevrare si depozitare a incarcaturii, utilitati si tot sprijinul cerut direct asociat cu nevoile si confortul pasagerilor. Constructia se va realiza in 3 faze, in functie de fluxul de pasageri si de program conform figurii 11.


Configuratia finala proiectata a facilitatilor de transport aerian se bazeaza direct pe cerintele operationale - anticiparea zborurilor sosiri / plecari, fluxul de pasageri, timpii de revenire la baza ai aeronavelor si cerintele de service si mentenanta. De exemplu, la momentul implinirii a 18 ani (figura 10, B), numarul mediu anticipat de zboruri este de 65 pe zi intre 6:00 a.m. si 11:00 a.m. Perioada




dintre zboruri este de 30 minute si timpul de imbarcare este tot de 30 minute (pentru a realiza imbarcarea pasagerilor) si numarul de reveniri la baza este de 35 cu un timp pentru traficul de pasageri de 1 ora fiecare. Timpul total impus pentru debarcare-imbarcare (considerand ca nu sunt intarzieri si presupunand existenta unui terminal pentru fiecare sosire plecare de avion) este de 50 de ore in timpul perioadei dintre 6:00 a.m. si 11:00 a.m.; astfel, sunt impuse cel putin 10 terminale pentru a satisface traficul de pasageri. Aceasta, in schimb, influenteaza dimensiunea zonelor de asteptare a pasagerilor si numarul personalului de aerogara cerut. In continuare, de service-ul si manevrarea la sol a aeronavelor impun anumite consumabile (combustibil, uleiuri, lubrifianti), piese de rezerva / reparare, echipament de testare si intretinere (camioane de alimentare, vehicule de tractare) si date tehnice (instructiuni de operare si intretinere). Posibila aparitie a unor lucrari de intretinere neprogramate dicteaza nevoia unui personal de intretinere calificat, unor piese de rezerva, unor date si unor hangare sau locuri de intretinere de rezerva.

Astfel, putem continua la infinit identificand cerintele ce vin in sprijinul nevoilor minime ale unei zone urbane si al companiilor aeriene comerciale. Devine usor de remarcat ca suportul logistic joaca un rol major. Sunt cerinte logistice asociate cu aeronavele, facilitatile de transport aerian si mediul de transport dintre aerodrom si zona urbana. Liniile comerciale aeriene prezentate aici abia ating un mic segment al problemei. Aceasta ar trebui pusa dintr-un punct de vedere sistemic, luand in considerare functiile asociate cu toate laturile lor. Aceasta ar trebui mai degraba sa sublinieze dimensiunea logisticii implicate.


Aplicatii aditionale


Cele 3 cazuri tocmai descrise sunt reprezentative pentru nevoile tipice cand trebuie definite la inceputul unui program cerintele operationale ale unui sistem si cand acestea trebuie sa serveasca ca baza pentru toate etapele urmatoare ale programului. Metodologia implicata este in principiu aceeasi pentru orice sistem, chiar daca se refera la sisteme relativ mici, elemente instalate pe o aeronava sau o nava, intr-o fabrica sau pe un unicat ce implica o constructie. In orice caz, sistemul trebuie definit in termenii proprii misiunii, performantelor, dezvoltarii operationale, ciclului de viata, utilizarii, factorilor de eficacitate si de mediu.




4. CONCEPTUL DE MENTENANTA A SISTEMULUI


Cand avem de-a face cu cerintele sistemului, tendinta este de a corela in primul rand acele elemente ale sistemului ce se refera la "performanta" - care este echipamentul de baza, software-ul operational si datele asociate, personalul de operare s.a.m.d. In acelasi timp, se acorda o foarte mica atentie intretinerii sistemului, mai ales in timpul primelor faze de proiectare si dezvoltare a sistemului. In esenta, accentul a fost pus pe o parte a sistemului si nu pe intregul sistem. Aceasta practica de a nu lua in considerare sistemul in totalitatea sa a fost mai degraba costisitoare, asa cum s-a aratat in sectiunea 1.4.

In discutiile asupra cerintelor generale ale sistemului, este esential ca toate aspectele sistemului sa fie luate in considerare. Aceasta include nu numai echipamentul primar si factorii similari, ci si capacitatea de intretinere a sistemului. Intretinerea sistemului trebuie sa fie considerata pe o baza integrata de la inceput daca produsul final trebuie sa aiba un bun raport pret-performanta. Aceasta este initial indeplinita prin definirea conceptului de mentenanta a sistemului in timpul fazelor primare a proiectarii conceptuale si planificarii avansate. Obiectivul este de a dezvolta un concept "inainte de a o face", cu ajutorul caruia sistemul propus sa fie mentinut de-a lungul ciclului de viata.

Conceptul de mentenanta dezvoltat in timpul proiectarii conceptuale evolueaza de la definirea cerintelor operationale ale sistemului dupa cum este ilustrat in diagrama din figura 1.7. Initial, trebuie sa avem in vedere fluxul de activitati si materiale de la proiectare pana la productie si la locul unde sistemul va fi utilizat. In plus, este un flux ce implica capacitatea de intretinere a sistemului. Un flux al mentenantei apare cand anumite componente sunt returnate de la locul operational la zonele de mentenanta intermediare sau la nivel de depozit. Un al doilea flux implica distributia pieselor de rezerva, a personalului, a echipamentului de testare si a datelor de la diferiti furnizori de la nivele de mentenanta intermediara si de depozit pana la locurile operationale, dupa cerinta. Diagrama din figura 12 (care este o extensie a figurilor 1.1. si 1.2) reflecta activitatile ce sunt legate de capacitatea de intretinere generala a sistemului.

Desi sunt anumite variatii in functie de natura si tipul sistemului, conceptul de mentenanta include la modul general urmatoarele informatii:


Nivele de mentenanta. Mentenanta corectiva si preventiva poate fi indeplinita de sistemul insusi (sau de un element al acestuia) la locul unde sistemul este folosit de consumator intr-o magazie intermediara aproape de locul operational al beneficiarului si / sau la o constructie sau depozit al fabricantului. Nivelul de mentenanta cu privire la distribuirea sarcinilor pentru fiecare zona unde mentenanta a fi realizata. Frecventa anticipata a mentenantei, complexitatea sarcinilor, cerintele nivelului de pregatire al personalului, nevoile

speciale ale cladirilor s.a.m.d. impun anumite functii ce trebuie indeplinite la fiecare nivel. In concordanta cu natura si misiunea sistemului, ar putea fi 2 nivele, 3 nivele sau 4 nivele ale mentenantei. Cu toate acestea, in scopul unor viitoare discutii, mentenanta poate fi clasificata ca "organizationala", "intermediara" si "furnizor / baza de reparatii".

(a) Mentenanta organizationala. Mentenanta organizationala este realizata la locul operational (de exemplu: aeronava, vehicul sau sistem de comunicatie). In general, include sarcini ce se indeplinesc de beneficiar cu propriul echipament. Personalul corespunzator nivelului organizational este, de obicei, implicat in operarea si folosirea echipamentului si are la dispozitie un timp minim pentru intretinerea in detaliu a sistemului. Mentenanta, la acest nivel, in mod obisnuit, este limitata la verificari periodice ale functionarii echipamentului, inspectari vizuale, curatirea echipamentului, un anumit service, ajustari



externe si inlocuirea sau indepartarea anumitor componente. Personalul implicat la acest nivel nu realizeaza repararea componentelor demontate, dar le transmite catre nivelul intermediar. Din punct de vedere al mentenantei, personalul cu calificarea cea mai scazuta este destinat acestei functii. Proiectarea echipamentului trebuie sa ia in considerare acest fapt (de exemplu: proiectare pentru simplicitate).

(b) Mentenanta intermediara. Sarcinile mentenantei intermediare sunt realizate de unitati si instalatii fixe, mobile sau semimobile specializate. La acest nivel, se pot realiza reparatii prin indepartarea si inlocuirea modulelor importante, a ansamblelor sau a pieselor componente. De asemenea, pot fi realizate operatiunile de intretinere programate, ce implica dezasamblarea echipamentului. Personalul de intretinere disponibil este in mod normal mai pregatit si mai bine echipat decat cel de la nivelul organizational si este raspunzator pentru realizarea unor operatii de intretinere mai detaliate.

Unitatile mobile sau semimobile sunt deseori destinate sa furnizeze o intretinere adecvata echipamentelor operationale. Aceste unitati se pot afla in autoutilitare, camioane sau containere portabile, ce contin echipament de testare si intretinere si piese de rezerva. Misiunea consta in furnizarea mentenantei la locul actiunii (in plus fata de ceea ce a indeplinit personalul cu pregatire de nivel organizational) pentru a facilita readucerea sistemului la starea de operare in timpul cel mai scurt. O unitate mobila poate fi folosita pentru a intretine mai multe locuri operationale. Un bun exemplu este vehiculul de intretinere care este deplasat de la un hangar la un avion parcat la o poarta-terminal a unei linii comerciale si are nevoie de o intretinere mai complexa.

Instalatiile fixe (magaziile permanente) sunt in general dispuse pentru a indeplini atat problemele de intretinere la nivel organizational, cat si cele ale unitatilor mobile sau semimobile. Problemele de mentenanta ce nu pot fi realizate la nivele mai scazute - datorita limitelor pregatirii personalului si a echipamentului de testare - sunt realizate aici. Calificare inalta a personalului, echipament de testare si intretinere suplimentar, piese de rezerva suplimentare si cladiri adecvate permit deseori reparatii ale echipamentului pana la nivelul modulelor si al pieselor componente. Magaziile fixe sunt de obicei localizate in zonele geografice specificate. Timpii mici ai operatiilor de intretinere prin returnare nu sunt atat de importanti aici, pe cat sunt nivelele scazute de mentenanta.

(c) Mentenanta la nivel de baza de reparatii, furnizor sau fabricant. Nivelul bazei de reparatii constituie cel mai mare tip al mentenantei si indeplineste toate problemele ce sunt sub sau deasupra capacitatilor disponibile ale nivelului intermediar. Din punct de vedere fizic, baza de reparatie poate fi o cladire specializata in repararea unui numar de sisteme / echipamente din inventar, sau poate fi chiar fabrica furnizorului. Facilitatile oferite de baza de reparatie sunt fixe si mobilitatea nu este o problema. Complexitatea si dimensiunea echipamentului, mari cantitati de piese de rezerva, elementele de control al mediului s.a.m.d. pot fi oferite in functie de cerinte. Marele volum potential din baza de reparatii sustine folosirea liniilor de asamblare, care, in schimb, permite intreprinderea unei munci relativ necalificate pentru o mare parte din operatiuni, cu o mare concentrare de specialisti cu inalta pregatire in anumite zone cheie pentru diagnosticarea defectelor si controlul calitatii.

Mentenanta la nivel de baza de reparatii include reparatia capitala, reconstruirea si calibrarea echipamentului, cat si realizarea unor operatii de intretinere de mare complexitate. In plus, baza ofera posibilitatea aprovizionarii cu piese. Bazele de reparatii sunt in general localizate in locuri indepartate pentru a satisface nevoile unor zone geografice specifice sau unor linii de productie special destinate.

Cele 3 nivele de mentenanta discutate mai sus sunt ilustrate in figura 1

Politici de reparare. Fiind date constrangerile conceptului ilustrat in figura 12 si 13, exista un numar mare de posibile politici de reparatii. O politica de reparatie specifica nivelul anticipat pana la care se va indeplini reparatia unui echipament (daca se va face). Politica de reparatie poate dicta daca o anumita problema se va considera ireparabila, partial reparabila sau complet reparabila. Politicile de reparatie sunt stabilite initial, criteriile sunt dezvoltate si proiectarea sistemului progreseaza in limitele politicii de reparatie selectate. Un exemplu al politicii de reparatie pentru Sistemul XYZ, dezvoltata ca o parte a unui concept de mentenanta de-a lungul unei proiectari conceptuale este ilustrata in figura 14.3







Responsabilitati organizationale. Indeplinirea mentenantei poate fi in responsabilitatea beneficiarului, a producatorului (sau a furnizorului), a unei terte parti, sau a unei combinatii a acestora. In plus, responsabilitatile pot varia, nu numai vis-a-vis de diferite componente ale sistemului, ci si in timp in functie de exploatare si o anumita faza in realizarea intretinerii. Deciziile referitoare la responsabilitatile operationale pot influenta proiectarea sistemului atat din punct de vedere al diagnosticarii si al ambalarii, cat si stabilirea politicilor de reparare, a conditiilor pe timpul garantiei s.a. Desi conditiile se pot schimba, anumite presupuneri initiale sunt cerute in acest moment.

4. Elementele de sustinere ale mentenantei. Ca parte a conceptului initial de mentenanta, trebuie stabilite anumite criterii legate de diferitele elemente de sustinere ale mentenantei. Aceste elemente includ service-ul (piese de rezerva si reparatii, inventar asociat, date auxiliare), echipament de testare si intretinere, personal si calificare, echipament de transport si manipulare, facilitati, informatii si resurse informatice (cu referinta la figura 1.3, sectiunea 1.2). Astfel de criterii, ca date intrare pentru proiectare, pot acoperi conditii de autotestare, cerintele testelor externe fata de autotestari, factori de standardizare si ambalare, efectivul de personal si nivelul de pregatire al acestuia, factori de transport si manipulare si alte asemenea restrictii. Conceptul de mentenanta ofera anumite criterii initiale de proiectare a sistemului referitoare la activitatile ilustrate in figura 12 si anumite determinari finale ale cerintelor referitoare la elementele de sustinere ale mentenantei si suportului logistic ce vor aparea o data cu finalizarea analizei intretinerii pe masura ce proiectarea progreseaza.

5. Cerintele eficacitatii. Acestea reprezinta factorii de eficacitate asociati capacitatii de intretinere. In zona asigurarii intretinerii pot fi incluse rata de cerere a pieselor de rezerva, probabilitatea ca o piesa de rezerva sa fie disponibila cand este nevoie, probabilitatea de succes a unei misiuni datorita unei anumite cantitati de piese de rezerva impuse in inventar si indeplinirea cerintei ca acesta sa fie economic. Din punct de vedere al echipamentului de testare, sunt considerati factori cheie: lungimea cozii in timpul asteptarii pentru testare, timpul afectat procesului de testare si fiabilitatea echipamentului de testare. Din punct de vedere al transportului sunt semnificativi: timpii de transport, rata de transport, fiabilitatea transportului si costurile acestuia. Din punct de vedere al personalului si calificarii acestuia, au importanta efectivul de personal si nivelul de pregatire al acestuia, rata erorii umane, rata de antrenare, timpii de antrenament si fiabilitatea echipamentului de antrenament. Din punct de vedere informational, factorii importanti sunt: numarul erorilor pe segment de misiune, pe modul de program sau pe linie de cod. Acesti factori trebuie luati in concordanta cu anumite cerinte ale fiecarui nivel al sistemului. Nu are rost specificarea unor cerinte minime referitoare la repararea unui element primar al sistemului atunci cand este nevoie de 6 luni pentru achizitionarea piesei de rezerva necesare. Cerintele eficacitatii aplicabile posibilitatilor de intretinere trebuie sa completeze cerintele pentru intregul sistem.

6. Mediul inconjurator. Se va defini mediul inconjurator relativ la mentenanta si service. Acesta include temperatura, soc si vibratii, zgomot, mediul tropical fata de cel arctic, teren muntos fata de cel plat, ambarcare fata de conditiile la sol s.a.m.d. cu aplicare la activitatile de intretinere si transport, manipulare si depozitare.




Pe scurt, conceptul de mentenanta ofera bazele dezvoltarii infrastructurii intretinerii si cerintelor specifice de proiectare pentru diferite elemente ale acesteia (cu referire la figura 1.3), ceea ce rezulta din definirea cerintelor operationale ale sistemului, asa cum a fost discutat in sectiunea De exemplu: fluxul prezentat in figura 15 este o extensie a fluxului sistemului de comunicatie prezentat in figura 8. Figura ilustreaza cantitatea elementelor angajate, nivelele de mentenanta si factorii cheie de eficacitate (de exemplu: MTBF, Mct, TAT si timpii fluxului logistic). Acesti factori pot fi specificati drept criterii de proiectare pentru elementele primare ale sistemului, cat si pentru structura intretinerii.


5. IDENTIFICAREA SI STABILIREA PRIORITATII MASURARILOR PERFORMANTELOR TEHNICE (MPT)4


Prin definirea cerintelor operationale si a conceptului de mentenanta a sistemului, factorii specifici de performanta sunt identificati si aplicati astfel incat sistemul sa fie proiectat si dezvoltat pentru a indeplini satisfacator misiunea(ile) desemnate. Acesti factori identificati ca masuri ale performantelor tehnice (MPT) pot fi aplicati ca fiind criterii de proiectare pentru elementele de sistem legate de misiunea principala si pentru acele elemente necesare intretinerii. Cu privire la infrastructura mentenantei si service-ului (si la proiectarea acestora), aceste masuri ale logisticii ce sunt descrise in Capitolul 2 si aplicabile prin definitia cerintelor operationale si conceptului de mentenanta pot fi identificate ca MPT critice.

In procesul de identificare al MPT pot exista diferite masuratori aplicabile si prioritati care trebuie stabilite pentru a determina gradul relativ de importanta pentru cazul in care sunt necesare anumite simplificari in proiectare (compromisuri). De exemplu, in proiectarea unui vehicul, este viteza mai importanta decat dimensiunea? Pentru o fabrica, este cantitatea productiei mai importanta decat calitatea produselor? Intr-un sistem de comunicatie, este latimea de banda mai importanta decat fidelitatea sau claritatea mesajului? Pentru un calculator, este capacitatea mai importanta decat viteza? Este fiabilitatea mai importanta decat mentenabilitatea? Sunt factorii umani mai importanti decat costul? Poate exista un anumit numar de obiective ale proiectarii si proiectantul trebuie sa inteleaga care sunt mai importante si relatia care exista intre ele. In continuare, proiectantul trebuie sa se asigure de incorporarea atributelor necesare sau a caracteristicilor ce sunt raspunzatoare de cerintele MPT in configuratia finala a sistemului si de faptul ca sunt in concordanta cu prioritatile stabilite.

Figura 16 ilustreaza rezultatele unei identificari a MPT si a efortului de stabilire a prioritatilor ce implica o echipa de indivizi reprezentand clientul (utilizatorul), proiectantul(ii), zona logisticii, etc. Observati ca MPT sunt identificati impreuna cu gradul lor relativ de importanta. Factorii de performanta ai vitezei, disponibilitatii si dimensiunii sunt vitali si constituie directia de proiectare. Caracteristicile sau atributele specifice de incorporat in proiectare (de exemplu: gradul de standardizare, conditiile de diagnostic, folosirea componentelor fiabile, a materialelor usoare, etc.) trebuie sa raspunda acestor cerinte si trebuie sa existe o urmarire a cerintelor de la cel mai scazut nivel al sistemului pana la diferitele sale elemente.

O excelenta unealta ce poate veni in ajutorul stabilirii prioritatilor MPT este modelul functiei de calitate (QF). QF constituie o abordare de "echipa" pentru a asigura faptul ca "vocea" clientului este reflectata in proiectul final. Scopul este stabilirea cerintelor necesare si traducerea acestor cerinte in solutii tehnice. Cerintele clientului si referintele sunt definite si clasificate ca atribute, care apoi sunt cantarite in functie de importanta lor. Metoda QF ofera echipei de proiectare o intelegere a dorintelor clientului, forteaza clientul sa-si clasifice aceste dorinte si permite compararea abordarilor de proiectare. Fiecare atribut al clientului este apoi satisfacut prin solutii tehnice.

Procesul QF implica constructia uneia sau mai multor matrice, dintre care prima este deseori denumita "casa calitatii (HOQ)".6 O versiune modificata a lui HOQ este prezentata in figura 17. Incepand de la partea din stanga a structurii se afla identificarea nevoilor clientului si scalarea acestor nevoi in termenii prioritatii, nivelele de importanta fiind specificate cantitativ. Aceasta reflecta "CE-urile" care trebuie adresate. O echipa cu reprezentare atat din partea clientului cat si din partea proiectantului determina prioritatile printr-un proces iterativ de revizuire, evaluare si reevaluare s.a.m.d.


Performanta tehnica

Cerintele cantitative

Performantele curente

Importanta

(dorinta clientului)

Timpul de executie

(zile)

30 zile

(maxim)

45 zile

(sistem M)


Viteza

(kph)

kph

(minim)

180 kmh

(sistem B)


Disponibilitatea

(operationala)


(minim)


(sistem H)


Marimea

(m)

5 m lungime

3 m latime

2 m inaltime

(maxim)

4,5 m

4 m

2 m

(sistem B)


Factorul uman

Mai putin de 1% rata de eroare pe an



2 % pe an

(sistem B)


Greutatea

(kg)

350 kg

(maxim)

375 kg

(sistem H)


Mentenablitatea

450 km

(minim)

425 km

(sistem H)





Figura 16 Gradul de prioritate al performantelor tehnice


Partea de sus a lui HOQ identifica raspunsul tehnic al proiectantului relativ la atributele ce trebuie incorporate in proiect pentru a raspunde nevoilor (de exemplu: "vocea clientului"). Aceasta constituie "CUM-urile" si trebuie sa fie cel putin o solutie tehnica pentru fiecare nevoie identificata a clientului. Trebuie identificata interrelationarea dintre aceste atribute (sau corelatii tehnice), precum si posibilele arii de conflict. Partea centrala a lui HOQ exprima puterea sau impactul raspunsului tehnic propus pe cerinta identificata. Partea de jos permite compararea alternativelor posibile si partea dreapta a lui HOQ este folosita in scopuri de planificare.





Metoda QF este folosita pentru a usura translatarea setului de prioritati de cerinte subiective ale clientului intr-un set de cerinte la nivel de sistem in timpul proiectarii conceptuale. O abordare similara poate fi folosita pentru a translata secvential cerintele nivelului sistem intr-un set mai detaliat de cerinte la fiecare nivel al procesului de proiectare si dezvoltate. In figura 18 "CUM-urile" dintr-o casa devin "CE-urile" din casa urmatoare. Cerintele pot fi dezvoltate pentru sistem, subsistem, componenta, proces de fabricatie, infrastructura s.a.m.d. Obiectivul este urmarirea cerintelor de sus in jos. Mai departe, cerintele trebuie sa fie formulate in termeni functionali.

Desi metoda QF n-ar fi chiar singura abordare folosita in scopul definirii cerintelor de proiectare a sistemului, totusi constituie o unealta excelenta pentru clarificarea inca de la inceput a aspectelor problemei. Unul dintre cei mai mari factori de "risc" este lipsa unui set de cerinte sau a unei specificari adecvate a sistemului. Inerent, cu specificarea sistemului trebuie sa apara identificarea si stabilirea prioritatilor masurarilor performantelor tehnice (MPT). In cadrul MPT, sistemul de masuratori asociat (de exemplu: "metric"), importanta sa relativa si performantele urmarite in termenii a ceea ce este in mod curent disponibil vor oferi proiectantilor linia de ghidare necesara pentru indeplinirea sarcinilor. Aceasta este esential pentru stabilirea nivelelor adecvate ale fazelor de proiectare, pentru definirea criteriilor ca o data de intrare pentru proiectare si pentru identificarea nivelelor posibile de risc, la care n-ar trebui sa se ajunga.7


6. ANALIZA FUNCTIONALA


Un element esential al proiectarii preliminare si conceptuale este dezvoltarea unei descrieri functionale a sistemului pentru a servi ca baza in identificarea resurselor necesare indeplinirii obiectivelor sistemului. O "functie" referitoare la o anumita actiune (sau o serie de actiuni) necesara realizarii unui obiectiv dat, este o operatie pe care sistemul trebuie sa o realizeze pentru a-si indeplini misiunea, sau o actiune de intretinere necesara readucerii sistemului in stare de functionare. Astfel de actiuni pot fi, in ultima instanta, indeplinite prin folosirea de echipament, personal, soft, cladiri, date sau combinatii ale acestora.

Cu toate acestea, in acest punct, obiectivul este specificarea "CE-urilor" si nu a "CUM-urilor", adica ce nevoi trebuie indeplinite versus cum trebuie indeplinite!8

Aceasta analiza functionala este un proces iterativ de distribuire a cerintelor de la nivelul sistem la subsistem si mai departe pana la structura minima ierarhica necesara identificarii criteriilor si / sau constrangerilor pentru variatele elemente ale sistemului.

In figura 1 analiza functionala poate fi initiata inca de la primele stadii ale proiectarii conceptuale ca parte a definirii problemelor si analizei nevoilor si functiile pe care sistemul trebuie sa le realizeze pentru a indeplini nevoile clientului. Aceste functii de operare sunt apoi extinse si formalizate prin dezvoltarea cerintelor operationale ale sistemului. Functiile primare de intretinere si service ale sistemului, care deriva din cerintele operationale, sunt identificate ca parti ale procesului de dezvoltare a conceptului de mentenanta. In continuare aceste functii trebuie extinse pentru a include toate activitatile de la identificarea initiala a nevoilor pana la scoaterea din uz a sistemului.

Indeplinirea unei analize functionale poate fi usurata prin folosirea diagramelor bloc ale fluxului functional, asa cum se ilustreaza in figura 19. Diagramele bloc sunt dezvoltate


mai ales in scopul structurarii cerintelor sistemului in "termeni functionali". Sunt dezvoltate pentru a ilustra organizarea de baza a sistemului si pentru a identifica interfetele functionale. Analiza functionala (si generarea diagramelor de flux functional) intentioneaza sa permita completarea proiectului, dezvoltarea si procesul de definire a sistemului intr-o maniera logica si inteligibila. Sunt identificate cerintele de prim nivel, partitionate pana la al doilea nivel si mai departe pana la nivelul necesar in scopul "definirii". Mai clar, abordarea functionala ajuta la asigurarea urmatoarelor:


1. Toate aspectele dezvoltarii sistemului, proiectarii, operarii, intretinerii si ale casarii sunt acoperite, adica toate activitatile importante din ciclul de viata al unui sistem.

2. Toate elementele sistemului sunt complet identificate si definite, adica echipamentul de baza, piesele de rezerva, echipamentul de testare si intretinere, cladirile, personalul, informatiile si softul.

Sunt furnizate mijloacele de intretinere si echipamentul necesar transportului si manipularii, adica satisfacerea cerintelor unui bun proiect "functional".

4. Sunt stabilite etapele adecvate de proiectare, impreuna cu elementele principale de proiectare.


Unul din obiectivele analizei functionale este asigurarea urmaririi cerintelor de la nivel sistem pana la cerintele pentru proiectul detaliat. In figura 20 se presupune ca este o nevoie de transport intre orasele A si B. In timpul analizei fezabilitatii sunt realizate studiile asupra modului optim de transport, rezultatul indicand transportul aerian ca fiind cel preferabil. In continuare, in timpul definirii cerintelor operationale, s-a concluzionat ca este o cerinta pentru un nou sistem aerian, demonstrandu-se o buna performanta si caracteristici de eficienta cu scopuri specificate cantitative pentru dimensiune, greutate, putere, distanta, volum de combustibil, fiabilitate, mentenabilitate, suportabilitate, cost s.a.m.d. Un avion trebuie sa fie proiectat si produs pentru a indeplini intr-o maniera satisfacatoare o anumita misiune, avand un anumit numar de misiuni de zbor cu profil ca acela prezentat in figura 20. Mai departe, conceptul de mentenanta indica faptul ca aeronava va fi proiectata pentru intretinere la 3 nivele de mentenanta de catre utilizator, va include conditii de autotestare si va avea un ciclu de viata operational de 10 ani.

Cu aceste informatii de baza, urmand pasii generali din figura 2, putem incepe structurarea sistemului in termeni functionali. Diagrama fluxului functional al celui mai inalt nivel poate fi dezvoltata pentru a acoperi activitatile principale identificate in ciclul de viata specificat. Fiecare dintre aceste activitati poate fi dezvoltata pana la diagrama fluxului functional de nivelul al doilea, o activitate de nivelul al doilea intr-un flux functional de nivelul trei s.a.m.d.

In timpul acestei expansiuni progresive a activitatilor functionale indreptata pentru definirea "CE-urilor" (versus "CUM-urilor"), putem evolua din profilul misiunii din figura 20 pana la o anumita capacitate a aeronavei, cum ar fi "comunicatiile". Un subsistem de comunicatii este identificat, analizele sunt realizate si este selectata o abordare de proiectare in detaliu. Sunt identificate resursele specifice necesare cerintelor functionale. Cu alte cuvinte, putem cobori de la nivel sistem pentru a identifica resursele necesare indeplinirii unor anumite functii (de exemplu: echipament, personal, cladiri si date). De asemenea, fiind data o cerinta specifica de echipament putem merge "in sus" pentru justificarea acelei cerinte. Analiza functionala ofera mecanismul urmaririi de "jos in sus".


Diagramele fluxului functional


In dezvoltarea diagramelor fluxului functional, este necesar un anumit grad de standardizare in scopul "comunicarii", in definirea sistemului. Astfel, anumite practici de baza si simboluri ar trebui folosite, de cate ori este posibil, in descrierea fizica a diagramelor functionale. Urmatoarele paragrafe ofera o anumita ghidare in aceasta directie:




  1. Blocuri functionale. Fiecare functie din diagrama functionala ar trebui prezentata intr-un singur chenar, desenat cu linie groasa. Blocurile de referinta pentru alte fluxuri ar trebui sa fie indicate cu eticheta "REF". Fiecare functiune trebuie sa fie la nivelul de detaliere cerut de nivelul functional din diagrama, dar trebuie sa fie concise si precise referitor la cerintele fata de echipament, personal, software, cladiri sau combinatii ale acestora. Functiile ambigue sau indoielnice ar trebui incluse in blocuri cu linie punctata.
  2. Numerotarea functiilor. Functiile identificate in diagramele fluxului functional la fiecare nivel trebuie numerotate intr-o maniera care sa pastreze continuitatea functiilor si sa ofere informatii care sa reflecte mersul de la ideea de baza pana la realizarea sistemului. Functiile de la cel mai inalt nivel ar trebui numerotate 1.0, 2.0, 0 s.a.m.d. Subfunctiile de la acest nivel vor contine acelasi identificator parinte si ar trebui codificate cu urmatorul nivel zecimal pentru fiecare identare. De exemplu, prima identare a functiei 0 ar fi 1, a doua 1.1, a treia 1.1.1 s.a.m.d. Pentru expansiunea unor functii de nivel mai inalt implicand un nivel particular de identare ar trebui folosita o secventa numerica pentru a pastra continuitatea functiilor. De exemplu, daca se cere mai mult de o functie pentru amplificarea functiei 0 la primul nivel de identare, secventa ar trebui sa fie 1, 2, 3, , n. Pentru dezvoltarea functiei 3 la nivel secundar, numerotarea ar trebui sa fie 1, 2, , n. Unde apar diferite nivele de identare intr-o diagrama functionala singulara ar trebui pastrat acelasi model. In timp ce regula de baza ar fi sa se mentina un nivel minim de identari pentru orice flux, devine necesara includerea unor anumite nivele pentru pastrarea continuitatii functiilor si pentru minimizarea numarului fluxurilor cerute pentru o reprezentare functionala a sistemului.
  3. Localizarea functiilor Fiecare diagrama functionala ar trebui sa contina o referire la urmatorul nivel superior din diagrama functionala prin folosirea unui bloc de referinta. De exemplu, functia 4.3 ar trebui sa fie prezentata ca bloc de referinta in cazul in care functiile 4.31, 4.2, , 4.n s.a.m.d. sunt folosite pentru a explicita complet functia 4. Blocurile de referinta ar trebui sa fie folosite de asemenea pentru a indica interfetele dintre functiuni dupa caz.
  4. Conectarea fluxului. Liniile ce leaga functiile ar trebui sa indice numai fluxul functional si n-ar trebui sa reprezinte o desfasurare in timp sau vreo activitate intermediara. Liniile orizontale si verticale dintre blocuri ar trebui sa indice ca toate functiile interconectate se desfasoara in paralel sau in serie. Liniile diagonale ar putea fi folosite pentru a indica secvente alternative (in cazul in care cai alternative duc la urmatoarea functie din secventa).
  5. Orientarea fluxului. Diagramele functionale ar trebui trasate astfel incat desfasurarea fluxului sa fie in general de la stanga la dreapta si fluxul de intoarcere, in cazul unei bucle functionale, de la dreapta la stanga. Liniile principale ar trebui sa intre in blocul functiei din partea stanga, iar iesirea principala sau linia MERGE ar trebui sa iasa prin partea dreapta si linia NU MERGE ar trebui sa iasa prin partea de jos a blocului.
  6. Porti sumatoare. Pentru reprezentarea unei porti sumatoare trebuie folosit un cerc. Ca in cazul blocurilor functionale, liniile trebuie sa intre si / sau sa iasa dupa caz. Poarta sumatoare este folosita pentru a indica convergenta sau divergenta cailor functionale paralele sau alternative si se noteaza cu termenul "SI" sau "SAU". Termenul "SI" este folosit pentru a indica faptul ca functiile paralele ce intra in poarta trebuie sa fie indeplinite inainte de a se trece la urmatoarea functie sau ca acele cai care ies din poarta "SI" trebuie sa fie indeplinite dupa functiile anterioare. Termenul "SAU" este folosit pentru a indica faptul ca oricare dintre caile (functiile) alternative duc la sau vin de la poarta "SAU". Astfel, aceasta indica faptul ca directiile alternative pot conduce sau urmari o functie particulara.
  7. Caile MERGE/NU MERGE. Simbolurile "M" si "/M" sunt folosite pentru a reprezenta caile "MERGE" si, respectiv, "NU MERGE". Simbolurile sunt introduse adiacent la liniile ce ies dintr-o anumita functie pentru a arata caile functionale alternative.
  8. Procedura de numerotare pentru schimbari in diagramele functionale. Adaugarea unor functii pentru datele existente se va realiza prin localizarea pozitiei corecte fara a afecta secventa numerotarii. Noua functie se va numerota folosind primul numar nefolosit la nivelul de identare propriu ei.

Functiile gasite nu se vor limita numai la cele necesare operarii sistemului, dar trebuie sa luam in considerare si posibilul impact al mentenantei asupra proiectarii sistemului. Diagramele fluxurilor functionale de intretinere vor fi, in cele mai multe cazuri, dezvoltate din diagramele fluxurilor functionale operationale.


Functiile operationale


Functiile operationale, in acest caz, sunt acelea care descriu activitatile ce trebuie realizate pentru a indeplini cerintele misiunii. Acestea pot include atat (1) acele activitati care implica proiectarea, dezvoltarea, productia si distributia unui sistem pentru exploatare si (2) acele activitati ce sunt legate in mod direct de completarea scenariului misiunii unui client. In a doua categoria poate fi inclusa o descriere a diferitelor moduri de utilizare si operare a sistemului. De exemplu, majoritatea modurilor de operare tipice poate fi: (1) "pregatirea aeronavei pentru zbor"; (2) "transportul materialelor de la fabrica la magazii"; (3) "initierea comunicatiilor intre producator si utilizator"; (4) "producerea unei cantitati x' de unitati in 7 zile"; (5) "procesarea simultana a 'a' date pentru 8 companii de distribuire intr-un timp 'b' cu acuratete 'c' intr-un format 'd' ". Sunt apoi descrise functiile necesare pentru a completa cu succes modurile identificate de operare.








Figura 2.1. ilustreaza o diagrama a fluxului operational simplificat. Observati ca in fiecare bloc cuvintele sunt "orientate pe actiune" si numerotarea blocurilor permite urmarirea de jos in sus a resurselor cerute. Functiile sunt explicitate pana la acel nivel necesar descrierii resurselor care vor fi impuse pentru a indeplini functiile, adica echipament, software, personal, cladiri s.a.m.d.


Functiile mentenantei


O data ce functiile operationale sunt descrise, procesul de dezvoltare a sistemului duce la identificarea functiilor mentenantei. De exemplu, este de asteptat ca anumite performante sau dimensiuni sa fie asociate fiecarui bloc din diagrama fluxului functional operational. O verificare a cerintelor functionale va indica fie o decizie MERGE, fie una NU MERGE. O decizie MERGE duce la verificarea urmatoarei functii operationale. O indicare NU MERGE (ce constituie un simptom de defectare) ofera un punct de plecare pentru dezvoltarea unei diagrame de flux functional detaliata. Tranzitia de la o functie operationala la o functie de mentenanta este ilustrata in figura 22. Figura 23 prezinta o diagrama de flux functional mai completa.


Aplicarea diagramelor fluxului functional



Analiza functionala ofera o descriere initiala a sistemului si aplicatiile sale sunt generale. Figura 24 ilustreaza o diagrama a fluxului functional la cel mai inalt nivel pentru un sistem de fabricatie, incepand cu identificarea nevoilor (blocul 1.0) si pana la retragerea sistemului (blocul 7.0). In zona unde este dorit un mai mare grad de definire blocul(rile) respectiv(e) poate fi divizat pana la un al doilea nivel, al treilea s.a.m.d. pentru a atinge nivelul adecvat de vizibilitate necesar determinarii resurselor impuse. In cazul de fata, cea mai de baza functie de fabricatie a fost identificata in blocul 5.1.


Pentru fiecare dintre blocurile din figura 24 analistul trebuie sa fie capabil sa specifice cerintele de intrare, iesirile asteptate, constrangerile sau functiile de control exterioare si mecanismele (sau resursele) necesare indeplinirii functiei specifice respective. In procesul identificarii resurselor in cauza poate fi luat in considerare un anumit numar de diferite abordari alternative. Sunt realizate studiile necesare, alternativele sunt evaluate in functie de criteriile rezultate din stabilirea masurilor performantelor tehnice (vezi MPT din sectiunea 5) si se recomanda o abordare preferentiala. In acest punct incepem sa identificam cerintele pentru hardware, software, personal, cladiri, date sau combinatii ale acestora. Figura 25 reflecta procesul care trebuie aplicat pentru fiecare bloc din figura 24.

In evaluarea fiecarei cerinte functionale, alternativele pot include o selectie a unor "commercial-off-the-shelf (COTS)" disponibili dintr-un anumit numar de surse de aprovizionare, COTS pot impune anumite grade de modificare sau "de dezvoltare", ce sunt unice pentru o anumita aplicatie si acolo unde un anumit nou proiect este cerut. Experienta arata ca se poate salva timp si bani prin selectarea echipamentului COTS disponibil rapid, software refolosibil, utilizarea cladirilor existente s.a.m.d. Figura 26 ilustreaza variatele optiuni in acest domeniu.


Figura 26 arata ca este esentiala stabilirea unei bune definiri a datelor de intrare si iesire (si a dimensiunilor adecvate) daca cineva doreste sa inteleaga pe deplin nu numai interfatarea dintre diferitele functii identificate in figura 24, dar si cerintele precise ale procesului de identificare a resurselor. Daca aceste cerinte de intrare-iesire nu sunt bine definite, atunci procesul de luare a deciziilor devine ca abordare preferentiala devine dificil; astfel, va conduce la posibilitatea initierii unui proiect costisitor si a unor eforturi de dezvoltare, cand, de fapt, un proiect (off-the-shelf item) deja existent ar putea satisface nevoia respectiva.

Analiza functionala poate usura o abordare "deschisa" a proiectului sistemului. O descriere functionala buna si inteligibila a sistemului, cu interfete bine definite (atat calitativ, cat si cantitativ), pot duce la o structura care nu numai ca va permite o rapida identificare a resurselor impuse, dar si pentru posibila incorporare a noii tehnologii mai tarziu. Obiectivul este proiectarea si dezvoltarea unui sistem ce poate fi usor modificat prin introducerea a noi tehnologii, fara a produce o reproiectare "costisitoare" a tuturor elementelor sistemului din proces (cu referire la figura 1.8).



In multe situatii, cerintele din proiect se schimba de la un detaliat "proiect la nivel de componenta" pana la proiectul sistemului, folosind o abordare de "integrare a cutiilor negre". Fiind data nevoia reducerii timpului de achizitie, cat timp se raspunde la un set de cerinte in continua schimbare si cu mult mai multi furnizori implicati, arhitectura sistemului trebuie sa permita o "usoara imbunatatire si / sau modificare". Cu alte cuvinte, structura sistemului trebuie sa fie astfel incat sa permita proiectarea intr-un mod evolutiv si cu cost minim. Aceasta poate fi imbunatatita printr-o buna si inteligibila definire functionala a sistemului inca din faza proiectarii conceptuale a ciclului de viata.

Figura 27 ilustreaza un sistem de fabricatie unde sunt multi furnizori (din diferite locuri pe tot Globul), ce produce componente pentru un anumit produs al unui client, ce trebuie efectiv integrate si testate. Exista functii de fabricatie, de subansamble, ansamble si testare. Acolo unde, de multe ori in trecut, activitatea de productie a implicat o abordare "de jos in sus", provocarile de astazi sunt legate de integrarea diferitelor componente in finalizarea produsului. Fara o buna definire si specificare inca de la inceput a interfetelor functionale, activitatea de testare si integrare finala poate duce la un proces costisitor, avand in vedere erorile. In figura, exemplul reflecta o fabrica unde subprocesele sunt indeplinite complet si eficient; cu toate acestea, au existat destule probleme considerabile, asociate cu "integrarea" activitatilor, adica cu cele 4 puncte critice de integrare. Interfetele functionale nu
au fost bine definite de la inceput, ceea ce a dus la o multime de modificari.


Completarea analizei functionale ar trebui facuta cu grija pentru a asigura ca resursele impuse sa fie bine identificate pentru fiecare functie. O analiza a duratei temporale poate fi realizata pentru a determina daca functiile trebuie indeplinite in serie sau in paralel. Este posibila impartirea resurselor pe anumite cazuri, adica aceleasi resurse pot fi utilizate la indeplinirea mai multor functii. Resursele identificate pot fi combinate si integrate la maxim. Trebuie facute toate eforturile pentru a evita specificarea resurselor ce nu sunt necesare.

Pe scurt, analiza functionala constituie un pas important inca de la inceputul proiectarii sistemului si a efortului de dezvoltare si formeaza o linie de baza pentru multe activitati ce pornesc de aici. De exemplu, serveste ca baza in dezvoltarea urmatoarelor:


Proiectarea electrica si mecanica pentru ambalare functionala, monitorizarea functionarii si conditii de diagnostic.

Fiabilitatea modelelor si diagramelor de bloc.

Modul de defectare, cauza si analiza critica.

Analiza arborelui de defectare.

Analiza mentenantei centrata pe fiabilitate.

Analiza sigurantei / hazardului sistemului.

Analiza mentenabilitatii.

Analiza nivelelor de reparare.

Analiza sarcinilor de mentenanta.

Analiza sarcinilor de operare.

Diagrama secventei operationale.

Analiza capacitatii de intretinere.

Procedurile de operare si mentenanta.

Analiza productivitatii si a casarii.


In trecut, analiza functionala nu era intotdeauna realizata in timp util, iar uneori nu era nici macar finalizata. Ca rezultat, diferitele sectii de proiectare insarcinate cu programul dat trebuiau sa-si realizeze propriile analize pentru a satisface cerintele programului. In multe cazuri, aceste eforturi erau facute independent si multe decizii de proiectare erau luate fara a benefica de o linie comuna de urmarit. Desigur, aceasta genera discrepante in proiectare si modificari costisitoare ce surveneau ulterior in ciclul de viata al sistemului.

Analiza functionala oferea o excelenta, dar foarte necesara linie de ghidare si toate activitatile de proiectare trebuiau sa "urmareasca" aceleasi date sursa pentru a indeplini obiectivele ingineriei de sistem. Din acest motiv, analiza functionala este considerata ca fiind o activitate cheie in procesul ingineriei de sistem.



7 ALOCAREA CERINTELOR


Fiind dat un nivel inalt de definire a sistemului prin analiza functionala , urmatorul pas este impartirea sistemului in componente prin partitionare.10 Aceasta implica o impartire a sistemului in subsisteme si elemente de nivel scazut. Provocarea este identificarea si gruparea functiilor strans relationate in pachete, ce implica resurse comune (de exemplu: echipament, software) pentru a indeplini cat mai multe functii si acoperind o arie cat mai mare. Desi ar putea fi relativ usoara identificarea cerintelor functionale individuale si asocierea resurselor pe principiul independentei, ar fi mai degraba costisitoare in cazul in care este vorba despre modularea, greutatea, dimensiunea sistemului s.a.m.d. Intrebarile sunt: Ce hardware sau software poate fi selectat pentru a indeplini functii multiple? Cum pot fi adaugate noile functii, fara a se adauga elemente fizice noi in structura sistemului?

Partitionarea sistemului in elemente este evolutiva in natura sa. Functii obisnuite pot fi grupate intr-o asemenea maniera incat sa ofere sistemului un grad de modulare avand in vedere obiective:


Elementele sistemului pot fi grupate dupa localizarea geografica, un mediu de exploatare asemanator, sau prin tipuri de echipament similare.

Modulele individuale ale sistemului ar trebui sa fie cat se poate de izolate, cu o minima interactiune cu celelalte module. Un obiectiv al proiectarii este capacitatea de a indeparta si inlocui un anumit modul fara fi necesara indepartarea si inlocuirea altor module din proces, sau necesitatea unui proces complex de aliniere si ajustare.

In impartirea sistemului in subsisteme trebuie selectata o configuratie unde comunicatia intre subsisteme este minima. Cu alte cuvinte, de cate ori complexitatea interna a unui subsistem poate fi mare, atunci complexitatea externa trebuie sa fie scazuta. Trebuie evitata impartirea sistemului in module acolo unde exista rate mari de transfer ale informatiei intre acestea.


Un obiectiv de proiectare general este impartirea sistemului in elemente astfel incat cat mai putine evenimente critice sa influenteze sau sa schimbe functionarea interioara a diferitelor module ce intra in arhitectura sistemului.

Ca rezultat al partitionarii, un sistem poate fi impartit pana la nivel de componenta ca in exemplul din figura 28. Procesul utilizat in identificarea si modularizarea elementelor este aratat in figura 29. Functiile sistemului sunt identificate, impartit este in subfunctii si grupate in 3 categorii de echipament, adica Unitatea A, Unitatea B si Unitatea C. Proiectul trebuie sa fie astfel incat fiecare dintre cele 3 unitati sa poata fi indepartata si inlocuita fara a avea impact asupra altora. Cu alte cuvinte, trebuie sa existe o interactiune minima intre cele 3 unitati.



Fiind realizata identificarea elementelor sistemului, urmatorul pas este alocarea sau portionarea cerintelor specifice sistemului pana la nivelul dorit pentru a oferi principala data de intrare pentru proiectare. Aceasta implica o distributie de sus in jos a criteriilor cantitative si calitative dezvoltate in sectiunea 5. De la MPT din figura 16, ce ar trebui specificat pentru nivelul unitate in figura 29 pentru a indeplini cerintele nivelului sistem?


Alocarea fiabilitatii


Dupa ce pentru sistem au fost stabilite un factor acceptabil de fiabilitate (de exemplu: probabilitatea de supravietuire) sau o rata de defectare, fiabilitatea trebuie alocata de-a lungul diferitelor tipuri de subsisteme, componente, ansamble s.a.m.d. Alocarea incepe cu realizarea diagramei bloc de fiabilitate. Diagrama bloc este apoi extinsa la diagramele de flux functional prezentate in sectiunea 6. Intentia este de a dezvolta o aproximare rezonabila a acestor elemente care trebuie sa functioneze pentru operarea cu succes a sistemului. Practic, diagrama trebuie structurata astfel incat fiecare bloc sa reprezinte o entitate functionala, relativ independenta fata de blocurile invecinate.

In dezvoltarea diagramei bloc, partile care au functionare predominant electronica sunt notate ca elemente electronice si partile care sunt mecanice la baza sunt identificate in concordanta. Partile redundante ce apar la acest nivel al sistemului ar trebui prezentate impreuna cu toate variantele alternative de functionare ale acestuia.

Figura 30 este o diagrama bloc simplificata a fiabilitatii si dezvoltarea progresiva a acesteia de la nivelul sistemului pana la detaliile de proiectare devine cunoscuta (cu referire la figura 2.10). In general, nivelele I si II sunt disponibile prin activitatea de proiectare conceptuala, in timp ce de la nivelul III in sus sunt definite in proiectarea preliminara a sistemului.

Referindu-ne la diagrama, cerinta de fiabilitate a sistemului (de exemplu: l, R, MTBF) este specificata pentru intreaga retea prezentata la nivelul I, si o cerinta individuala este


specificata pentru fiecare bloc din retea. De pilda: fiabilitatea blocului 4, Functia X, poate fi exprimata ca o probabilitate de supravietuire de 0,95 pentru o perioada de operare la nivelul I de 4 ore. Cerinte similare sunt specificate pentru blocurile 1, 2, 3 si 5. Cand acestea sunt combinate, vor indica fiabilitatea sistemului, care, in schimb, este evaluata in termenii unei cerinte generale.




Diagramele bloc sunt realizate pentru a acoperi fiecare din functiile importante identificate in figura 29. Sunt stabilite criteriile de succes (parametrii MERGE/NU MERGE) si este estimata rata defectarii (l) pentru fiecare bloc, combinarea acestora oferind un factor general pentru o serie de blocuri ce constituie functii sau subfunctii. In dependenta cu functia, una sau mai multe diagrame pot fi legate de o entitate fizica, cum ar fi Unitatea A din figura 29 sau un subansamblu al Unitatii A. Informatia referitoare la rata defectarii oferita la nivel de componenta / subansamblu reprezinta un scop in proiectarea fiabilitatii. Aceasta, in schimb, reprezinta o frecventa anticipata a mentenantei corective, ce este implicata in determinarea cerintelor resursei logistice.

Abordarea folosita in determinarea ratei de defectare poate varia in concordanta cu complexitatea definirii sistemului. Ratele de defectare pot fi extrase direct din exploatarea si / sau testele experimentale ce acopera probleme asemanatoare, rapoartele de previzionare a fiabilitatii ce acopera sisteme de natura similara sau estimari calculate, bazate pe judecata. In anumite cazuri, factorii de incarcare sunt folositi pentru a compensa complexitatea sistemului si actiunile mediului inconjurator.

Cand se realizeaza alocarea fiabilitatii, sunt luati in considerare urmatorii pasi:


  1. Evaluarea diagramei(lor) fluxurilor functionale ale sistemului si identificarea zonelor unde proiectul este cunoscut si informatiile asupra ratei de defectare sunt disponibile si usor de evaluat. Atribuirea factorilor adecvati si determinarea contributiei lor la cerintele fiabilitatii sistemului la cel mai inalt nivel. Diferenta consta in acea parte a cerintei de fiabilitate ce poate fi alocata altor arii.
  2. Identificarea ariilor noi, unde informatiile referitoare la proiectare nu sunt disponibile. Atribuirea factorilor de incarcare fiecarui bloc functional. Factorii de complexitate se pot baza pe o estimare a numarului si relatiilor dintre parti, a ciclului de serviciu al echipamentului, a modului de operare si a elementelor critice in cazul in care o anumita componenta va fi supusa la temperaturi extreme s.a.m.d. Aceasta parte a cerintei de fiabilitate a sistemului, care nu este deja alocata ariilor cunoscute de proiectare se aloca folosind factorii de incarcare.

Rezultatul final ar trebui sa constituie o serie de valori de nivel scazut, care pot fi combinate pentru a reprezenta cerintele de fiabilitate a sistemului initial specificate (de exemplu: MTBF de 450 de ore pentru Sistemul XYZ). Combinarea acestor valori este usurata prin aplicarea unui model matematic de fiabilitate.

Un model matematic de fiabilitate este dezvoltat pentru a lega fiabilitatea unui "bloc" individual cu fiabilitatea blocurilor constituente sau a elementelor. Procedura consta in simpla determinare a unei expresii matematice, ce reprezinta probabilitatea supravietuirii unei mici parti a configuratiei propuse. Aplicatii multiple ale acestui proces vor reduce in final complexitatea initiala a sistemului la o configuratie serie echivalenta. Este apoi posibil sa reprezentam sistemul printr-o singura relatie probabilistica. Unele dintre relatiile matematice folosite in acest caz au fost descrise in sectiunea 2.1.

Cand se aloca o cerinta de un anumit nivel a sistemului (de exemplu: MTBF de 450 de ore), ar trebui sa construim o impartire functionala simplificata, asa cum este ilustrat in figura 31. Diagrama trebuie sa reflecte o relationare serie-paralel.

Initial, ratele de defectare sunt identificate pentru componentele de proiectare cunoscute si sunt deduse din cerintele generale ale sistemului. Un factor de complexitate poate fi stabilit pentru fiecare din componentele ramase11. Factorii de complexitate sunt luati in considerare pentru toate componentele. Acestia sunt folositi pentru a atribui ratele de defectare de la urmatorul nivel inferior in jos. Ca verificare, ratele de defectare la nivel ansamblu sunt totalizate pentru a obtine rata de defectare a componentelor, aceasta din urma oferind rata de defectare a sistemului (observatie: Unitatile A, B si C reprezinta o operatie in serie). Factorul MTBF este de obicei considerat a fi opus ratei de defectare si fiabilitatea sistemului (R) sau a unei componente pot fi determinate din ecuatia 2.5 sau din diagrama din figura 2.




Referindu-ne la figura 31, o diagrama bloc de fiabilitate ce arata legatura functionala a 4 elemente (a, b, c si d) ilustreaza "realizarea" Ansamblului 2. Expresia matematica a celor 4 elemente este:


(3)


Folosind relatia generala in ecuatia 2.5, factorii de fiabilitate si ratele de defectare pot fi determinati. In acest caz, rata totala de defectare pentru Ansamblul 2 nu trebuie sa depaseasca 0,00155.

Revizuirea configuratiei defectarii echipamentului ilustrata in figura 31 indica o cerinta de prim nivel a sistemului, data de factorii stabiliti de la nivel de componenta in jos. Doar daca nu este specificat altfel, cerintele la nivel de componenta pot fi modificate sau inlocuite cat timp cerintele de la nivel componenta sustin obiectivele sistemului. Cu alte cuvinte, rata de defectare a Unitatii B poate fi mai mare si rata de defectare a Unitatii A poate fi mai mica decat cele indicate, fara a afecta cerinta de 0,002222 s.a.m.d.! Tehnicile tratarii separate a diferitilor parametri pentru a indeplini o cerinta generala vor fi discutate pe viitor in Capitolul 4.

Factorii de fiabilitate stabiliti pentru diferite componente identificate din figura 31 servesc ca si criterii de proiectare. De exemplu, inginerul responsabil cu Unitatea B o va proiecta cu o asemenea rata de defectare (l) ce nu va depasi 0,001866. Pe masura ce proiectarea avanseaza, predictiile fiabilitatii sunt indeplinite si valoarea previzionata este comparata cu cea impusa de 0,001866. Daca valoarea previzionata nu indeplineste cerinta (de exemplu: o rata de defectare mai mare pentru un MTBF mai mic), atunci configuratia proiectata trebuie revizuita pentru imbunatatirea fiabilitatii si schimbarile proiectate sunt implementate in consecinta.

Factorii alocati nu numai ca ofera proiectantului un criteriu de fiabilitate, dar servesc si ca indicator al frecventei intretinerii corective datorita caderilor anticipate ale echipamentului. Presupunem ca Sistemul XYZ este introdus intr-o postura operationala similara celei descrise pentru sistemul de comunicatii mobil din sectiunea 3 si timpul total de operare a sistemului intr-un an este de 60.000 de ore pentru o perioada de 10 ani. Marimea previzionata a actiunilor de intretinere a sistemului datorita defectarii este:

actiunile previzionate de intretinere =    


sau (4)

actiunile previzionate de intretinere =/ an


Presupunand ca fiecare dintre componente este in stare de operare sau este alimentata continuu cand sistemul este operational, atunci dimensiunea activitatilor de intretinere previzionate pentru fiecare componenta poate fi determinata din ecuatia (4). Rezultatele sunt 15 activitati de intretinere pe an pentru Unitatea A, 112 pentru Unitatea B si 6 pentru Unitatea C. Frecventa intretinerii este o data de intrare necesara pentru determinarea cerintelor resursei logistice (materie prima si cost) pentru un sistem sau un echipament.


Alocarea mentenabilitatii


Procesul traducerii cerintelor de mentenabilitate a sistemului (cum ar fi MTBM, Mct, Mpt, MLH/OH) in criterii de proiectare de nivel scazut este realizat prin alocarea mentenabilitatii. Alocarea impune dezvoltarea unei diagrame de defectare simplificate asa cum este ilustrat in figura 31. O defectare functionala este bazata pe un concept de mentenanta, datele analizei functionale si o descriere a unei politici de reparatie de baza, chiar daca sistemul va fi reparat printr-o inlocuire a unei componente, a unui subansamblu sau a unei parti.

In scopul ilustrarii, se presupune ca Sistemul XYZ trebuie sa fie proiectat pentru a indeplini o cerinta de disponibilitate de 0,9989, un MTBF de 450 si un MLH/OH (pentru mentenanta corectiva) de 0,2 si exista o nevoie de alocare a lui Mct si MLH/OH la nivel subansamblu . Ecuatia pentru Mct este:

sau (5)


Astfel, cerinta sistemului este: Mct = 0,5 ore   si aceasta cerinta trebuie sa fie alocata Unitatilor A, B si C si subansamblelor din interiorul fiecarei unitati. Procesul de alocare este usurat prin folosirea unui format similar celui ilustrat in tabelul 1.


Tabelul 1 Alocarea Sistemului XYZ






Component




Cantitatea de componente pe sistem (Q)




Rata de defectare

l) x 1000 h


Contributia la rata de defectare generala



Cf = (Q) (l



Contributia procentuala

Cp = Cf /aCf

x 100


Timpul de mentenanta corectiva estimata

cti (h)


Contributia la timpul total de mentenanta corectiva

Ct = (Cf) (ct

1. Unitatea A

2. Unitatea B

Unitatea C



















Total



a Cf = 2,222



a Ct = 1,077

ct pentru Sistemul XZY = h (cerinta: 0,5 ore)


Referindu-ne la tabelul 1, sunt identificate fiecare tip si cantitate (Q) de componente pe sistem. Factorii de fiabilitate alocati sunt specificati in coloana 3 si gradul in care rata de defectare a fiecarei componente contribuie la rata de defectare generala (reprezentata de Cf) este prezentat in coloana 4. Media timpului de mentenanta corectiva pentru fiecare componenta este estimata si introdusa in coloana 6 Acesti timpi depind in ultima instanta de caracteristicile proiectarii echipamentului, care nu sunt cunoscute in acest punct din ciclul de viata al sistemului. Astfel, timpii de mentenanta corectiva sunt initial determinati folosind un factor de complexitate, ce este indicat de rata de defectare. Ca scop, factorul care contribuie in cel mai mare procent la defectarile totale anticipate (de exemplu: Unitatea B) ar trebui sa impuna un Mct scazut si cei cu contributii scazute ar trebui sa impuna un Mct marit. Cu toate aceste, la anumite ocazii, costurile de proiectare asociate obtinerii unui Mct scazut pentru un element complex pot duce la o abordare modificata, care este fezabila atata timp cat rezultatul final (Mct la nivel sistem) scade pana la nivelul dorit .

Valoarea estimata a lui Cf pentru fiecare componenta e introdusa in coloana 7 si suma contributiilor pentru toate componentele poate fi folosita pentru a determina factorul Mct al sistemului ca:


  (6)


In tabelul 1, factorul Mct calculat pentru sistem este in intervalul cerut de 0,5 ore. Valorile Mct pentru unitati ofera criteriile pentru proiectare a timpilor de defectare pentru mentenanta corectiva si aceste valori sunt incluse in specificatiile proiectarii echipamentului.

O data ce alocarea este realizata la nivel de unitate, valorile rezultate Mct, pot fi alocate urmatorului echipament cu un numar de identare mai mic. De exemplu, valoarea Mct = 0,4 ore pentru Unitatea B poate fi alocat subansamblelor 1, 2 si 3 si procedura de alocare a valorilor continua in acelasi fel cu ecuatia (6). Un exemplu de alocare a valorilor pentru subansamblele Unitatii B este inclus in tabelul 2.


Tabelul 2 Alocarea Unitatii B








Ansamblul 1

Ansamblul 2

Ansamblul 3



















Total







ct pentru Unitatea B = h (cerinta: 0,4 ore)


Valoarea Mct acopera aspectul timpului scurs sau a timpului masurat pentru revizuirea operatiunilor. Cateodata acest factor, cand este combinat cu cerintele de fiabilitate, este suficient pentru a stabili caracteristicile necesare de mentenabilitate pentru proiectare. Cu alte ocazii, specificarea insasi a factorului Mct nu este adecvata deoarece poate exista un anumit numar de abordari in proiectare care vor indeplini cerinta Mct, dar nu neaparat intr-o maniera optima de pret-calitate. Indeplinirea cerintei Mct poate rezulta din cresterea nivelului de pregatire profesionala a personalului, ce indeplineste lucrarile de intretinere, marirea personalului ce indeplineste anumite operatii date de intretinere si / sau realizarea automata a unor operatiuni manuale. In fiecare caz, sunt implicate costuri; cu toate acestea, am putea dori sa specificam anumite conditii suplimentare, cum ar fi: nivelul de calificare al personalului pentru fiecare nivel de intretinere si timpul de intretinere efectuat de om / timpul de ora de functionare (MLH/OH) pentru anumite echipamente importante. Cu alte cuvinte, o anumita cerinta poate impune ca o anumita componenta sa poata fi proiectata in asemenea fel incat sa poata fi reparata intr-o perioada de timp bine specificata cu un anumit personal de o anumita calificare. Aceasta va influenta proiectarea in termenii accesibilitatii, a schemelor acoperitoare, a cerintelor de manipulare, a conditiilor de diagnostic s.a.m.d. si poate va fi mult mai importanta in termenii proiectarii suportului logistic

Factorul MLH/OH este o functie ce arata complexitatea operatiilor si frecventa intretinerii. Cerinta la nivel de sistem se aloca pe baza orelor de functionare a sistemului, a marimii anticipate de activitati de intretinere si a unui timp de intretinere estimat efectuat de om / timpul de ora de functionare. Vor fi folosite pe cat posibil date cunoscute din experienta.

Aplicand rezultatul alocarii cantitative pentru fiecare nivel identat dat al echipamentului, toate valorile sunt incluse in diagrama de defectare ilustrata in figura 32. Figura ofera o vedere de ansamblu a principalelor cerinte de proiectare ale sistemului.



Alocarea factorilor logistici


In plus fata de parametrii de mentenabilitate si fiabilitate si de impactul lor asupra proiectarii, trebuie sa luam in considerare de asemenea si alti factori considerati critici pentru operarea cu succes a sistemului. Acesti factori, dintre care unii au fost prezentati in Capitolul 2, se refera la operatiile de intretinere, echipamentul de testare si intretinere, personal si intretinerea organizationala, cladiri si mijloace de transport.

Asa cum s-a mentionat mai devreme, toate elementele sistemului trebuie sa fie dezvoltate astfel incat sa includa diferitele activitati prezentate in figura 2.3 Cu toate acestea, ar putea fi necesara stabilirea unor criterii de proiectare suplimentare, referitoare la diferite elemente ale suportului logistic. Cateva exemple sunt prezentate mai jos.


Utilizarea echipamentului de testare intr-o magazie de intretinere intermediara va fi de cel putin 80% si fiabilitatea echipamentului - de cel putin 90%.

Detalierea autotestarii sistemului (folosind capacitati de autotestare) va fi de 95% sau mai buna.

Nivelul de calificare al personalului de nivel organizational pentru intretinere va fi echivalent cu gradul x sau mai putin.

Cladirile de reparatii de nivel intermediar vor fi proiectate pentru o utilizare de minim 75%.

Timpul de transport intre locurile unde se face intretinerea organizationala si magaziile de intretinere intermediara nu va depasi 48 de ore.

Timpul de intoarcere de la magaziile de intretinere intermediara va fi de 2 zile (sau mai putin) si, respectiv, 10 zile (sau mai putin) in cazul bazelor de reparatii.

Probabilitatea disponibilitatii pieselor de rezerva pentru intretinerea nivelului organizational va fi de cel putin 95%.


In esenta, in definirea cerintelor operationale ale sistemului si a conceptului de mentenanta (descris in sectiunile 3 si 4), factorii de intretinere a sistemului trebuie sa determinati impreuna cu parametrii de performanta. Acesti factori, stabiliti la nivel sistem, pot fi alocati atat cat este necesar pentru a influenta activitatea de proiectare.


Alocarea factorilor economici


Folosind o abordare similara celei descrise in capitolul anterior, factorii de cost pot fi alocati in mod adecvat nevoilor sistemului. Daca produsul finit trebuie sa fie eficient din punct de vedere al costului, ar fi de dorit sa atribuim ca scop un pret scazut pentru diferite echipamente. De exemplu, un obiectiv ar putea fi proiectarea Sistemului XYZ astfel incat costul componentei sistem sa nu depaseasca 500.000 de dolari, bazandu-ne pe o cantitate de productie de 300 si un ciclu de viata operational de 10 ani. Costul componentelor constituie costul total al ciclului de viata (pentru a include costul de cercetare si dezvoltare, productie, operare, intretinere si casare) impartit la numarul sistemelor. Acest factor de cost, specificat la cel mai inalt nivel, poate fi atribuit pana la cele mai joase nivele de identare a echipamentului ca tinta economica pentru proiectare. Telul economic, combinat cu fiabilitatea (sau echivalentul) cerintelor poate crea o situatie limita in proiectare, asa cum s-a aratat in figura 2.30. Cu alte cuvinte, putem proiecta cu un cost anume.


SINTEZA, ANALIZA SI OPTIMIZAREA PROIECTULUI


Sinteza se refera la combinarea si structurarea componentelor astfel incat sa reprezinte o configuratie de sistem fiabila. Cerintele pentru sistem au fost stabilite, studii preliminare au fost realizate si apare necesitatea dezvoltarii unei configuratii de baza pentru a demonstra conceptele discutate mai devreme. Sinteza este proiectul. Initial, sinteza este implicata in dezvoltarea conceptelor preliminare si in stabilirea relatiilor de baza dintre diferitele componente ale sistemului. Mai tarziu cand s-au realizat suficiente definiri si descompuneri functionale, sinteza este folosita pentru a defini "CUM-urile" in raspuns la cerintele de tip "CE". Sinteza implica selectarea unei configuratii ce ar putea fi reprezentativa pentru forma pe care sistemul o va lua in final, cu toate ca, in acest moment, configuratia finala nu este definita complet.15

Procesul de sinteza conduce in mod uzual la definirea catorva alternative posibile ale abordarii in proiectare, ceea ce va constitui subiectul unor viitoare analize, evaluari, cizelari si optimizari. Asa cum aceste alternative sunt structurate initial, este esential ca termenii tehnici de performanta adecvati sa fie ajustati in modul cel mai potrivit pentru componentele sistemului. De exemplu, parametrii de performanta tehnica pot include factori cum ar fi: greutatea, dimensiunea, viteza, capacitatea, acuratetea, volumul, scala, timpul de procesare, precum si fiabilitatea, mentenabilitatea si alti factori, asa cum sunt prezentati in figura 3 Acesti parametri, sau dimensiuni trebuie luati in considerare si stabiliti pentru elementele sistemului (de exemplu: un echipament, o unitate sau un ansamblu, o componenta sau o secventa de program).

Cand definim cerintele initiale ale sistemului, masura performantelor tehnice (MPT) o stabilim bazandu-ne pe relationarea si importanta lor in indeplinirea misiunii, adica pe impactul pe care un anumit factor il are asupra eficacitatii costului sau a sistemului sau a performantelor. Aceste MPT sunt ordonate in functie de prioritate si relatiile lor sunt prezentate in formularul de consideratii de proiectare ilustrat intr-un arbore ierarhic in figura 3 Dimensiunea MPT (si a consideratiilor asupra proiectului), ce vor fi integrate in managementul programului si revizuite, vor fi foarte putin diferite de la un sistem la urmatorul. O dimensiune foarte importanta pentru un sistem ar putea fi "fiabilitatea", in timp ce "disponibilitatea" ar putea fi cea mai importanta intr-un alt caz. In orice caz, dimensiunile adecvate trebuie stabilite, ordonate si incluse in specificatie. In concordanta cu evolutia procesului de proiectare, aceste dimensiuni vor fi folosite in scopul analizei si al evaluarii.

Fiind dat un numar de alternative, procedura de evaluare progreseaza prin pasii generali ilustrati in figura 34 si descrisi dupa cum urmeaza:


Definirea scopurilor analizei. O etapa initiala impune clarificarea obiectivelor, identificarea solutiilor posibile alternative ale probleme in cauza si descrierea abordarilor analitice ce vor fi implicate. In functie de alternative, initial, trebuie luate in considerare toate variantele posibile; cu toate acestea, cu cat sunt luate in considerare mai multe alternative, cu atat mai complex devine procesul de analiza. Astfel, este de dorit ca la inceput sa fie prezentate toate posibilitatile pentru a fi siguri ca nu exista nici o omisiune, si apoi sa eliminam acele posibilitati care sunt clar neatractive, pastrand pentru evaluare numai cateva. Acestea sunt apoi evaluate in intentia selectarii unei abordari preferate.

Selectarea si dimensionarea parametrilor de evaluare. Criteriile folosite in procesul de evaluare pot diferi considerabil in concordanta cu problema in cauza, sistemul de evaluat si de adancimea si complexitatea analizei. Din figura 33, parametrii de prima importanta includ costul, eficacitatea, performanta, disponibilitatea, dependabilitatea s.a.m.d. La un nivel mai detaliat, ordinea parametrilor va fi diferita. In orice caz, parametrii sunt selectati, dimensionati, in ideea clasificarii dupa importanta si ajustati corespunzator nevoilor sistemului.

Identificarea datelor necesare. Cand evaluam o configuratie anume de sistem, este necesar sa luam in considerare cerintele operationale, conceptul de mentenanta, caracteristicile importante de proiectare, planurile de productie si / sau constructie, gradul de utilizare anticipata a sistemului si cerintele de intretinere. Indeplinirea acestor cerinte impune mai multe tipuri de date, scopul lor depinzand de tipul evaluarii ce se realizeaza si de faza programului in timpul careia este realizata evaluarea. In primele faze ale dezvoltarii sistemului, datele disponibile sunt limitate; astfel, analistul trebuie sa se bazeze pe folosirea variilor relatii estimate intre elementele sistemului, pe experienta castigata din configurarile unor sisteme similare si pe intuitie. Pe masura ce dezvoltarea sistemului progreseaza, vor fi disponibile date imbunatatite (in timpul analizei si predictiei) si sunt folosite ca intrare in efortul de evaluare. In acest moment este important sa determinam mai intai nevoile specifice de date (cum ar fi: tipul, cantitatea s.a.) si sa identifice posibilele surse de date. Natura si validitatea datelor de intrare pentru o anumita analiza ar putea avea un impact important asupra riscurilor asociate deciziilor luate pe baza rezultatelor analizelor. Astfel, am avea nevoie sa evaluam situatia cu acuratete si cat mai devreme posibil.




Identificarea tehnicilor de evaluare. Fiind data o anumita problema, este necesar sa determinam abordarea analitica ce va fi folosita si tehnicile ce pot fi aplicate pentru a usura procesul de rezolvare a problemelor. Tehnicile pot include: folosirea simularii Monte Carlo in predictionarea evenimentelor aleatoare ce pot aparea in ciclul de viata, folosirea programarii liniare in determinarea cerintelor resurselor de transport, folosirea structurii retea in stabilirea nevoilor de distributie, folosirea metodelor contabile pentru calcularea costului ciclului de viata s.a.m.d. Revizuirea problemei si identificarea uneltelor disponibile, ce pot fi folosite in rezolvarea problemei, sunt necesare in special la selectarea unui model.

Selectarea sau dezvoltarea unui model. Urmatorul pas impune combinarea diferitelor tehnici analitice intr-o schema sau un model sau o serie de modele, asa cum este ilustrat in figura 35.16 Un model, folosit ca unealta in rezolvarea problemei, ajuta in dezvoltarea unei reprezentari simplificate a lumii reale, asa cum se aplica problemei in curs de rezolvare. Modelul trebuie (a) sa reprezinte dinamica configurarii sistemului ce se evalueaza; (b) sa sublinieze acei factori de maxima importanta problemei in cauza; (c) sa fie inteligibili prin includerea tuturor factorilor relevanti si viabili in termenii repetabilitatii rezultatelor; (d) sa fie atat de simpli in structura incat sa permita














implementarea la timp in rezolvarea problemei; (e) sa fie implementati astfel incat analistul sa poata evalua configuratia sistemului ca entitate, analiza fiecarei componente a sistemului, iar apoi sa integreze rezultatele in intreg; (f) sa fie proiectat respectand conditiile unei modificari si / sau completari, care sa permita evaluarea factorilor aditionali dupa cerinte. Un obiectiv important este selectarea sau dezvoltarea unei unelte ce va ajuta in evaluarea configurarii generale a sistemului, precum si in interrelationarea dintre diferitele sale componente. Modelele (si aplicatiile lor) sunt discutate mai tarziu in Capitolul 4.

Generarea modelelor. In identificarea tehnicilor analitice si indeplinirea sarcinilor de selectare a modelului, urmatorul pas este "verificarea" sau "testarea" modelului pentru a fi siguri ca este concordanta cu cerintele analizei. Indeplineste modelul obiectivele impuse? Reactioneaza acesta la principalii parametrii ai configurarii sistemului ce este evaluat? Evaluarea modelului poate fi indeplinita prin selectarea unei entitati sistem cunoscute si compararea secventiala a rezultatelor analizei cu experienta anterioara. Parametrii de intrare pot fi modificati pentru a ne asigura de sensibilitatea caracteristicilor modelului proiectat fata de aceste modificari si ca va reflecta in cele din urma un rezultat destul de precis.

Evaluarea alternativelor de proiectare. Fiecare dintre alternativele considerate va fi ulterior evaluata folosind tehnicile si modelele selectare. Datele cerute sunt colectate din diferite surse cum ar fi bazele de date existente, predictii bazate pe datele de proiectare curente si / sau aproximari grosiere folosind analogii si relationari estimative ale parametrilor. Datele cerute, care pot fi luate dintr-o mare varietate de surse, trebuie aplicate intr-o maniera corespunzatoare. Rezultatele sunt apoi evaluate in termenii cerintelor sistemului impuse initial. Alternativele fezabile sunt apoi luate in considerare. Figura 36 ilustreaza unele consideratii acolo unde solutiile posibile fezabile intersecteaza aria solutiilor dorite.

Realizarea unei analize a senzitivitatii. In realizarea unei analize, poate exista un anumit numar de parametrii cheie ai sistemului asupra carora analistul este nesigur din cauza unor date de intrare neadecvate, unor proceduri sarace de predictie. Sunt cateva intrebari ce trebuie puse: Cat de sensibile sunt rezultatele analizei la posibila variatie a acestor parametrii de intrare nesiguri? Pana unde pot fi modificati acesti parametri de intrare inainte ca alegerea unor alternative sa modifice abordarea initial selectata? Din experienta exista cativa parametri cheie de intrare in analiza costului ciclului de viata, cum ar fi: fiabilitatea MTBF si mentenabilitatea Mct, ce sunt luati considerati vitali in determinarea costurilor mentenantei si service-ului. Cu o delimitare foarte buna a campurilor de date, exista o mare dependenta bazata pe metodele de estimare si predictie. Astfel, in scopul minimizarii riscurilor asociate luarii deciziilor incorecte, analistul poate dori sa modifice factorii de intrare MTBF si Mct in interiorul unui anumit interval de valori (sau distributii) pentru a vedea impactul asupra rezultatelor. Are o variatie relativ mica a unui factor de intrare un impact mare asupra rezultatelor analizei? Daca da, atunci acesti parametri ar putea fi clasificati ca fiind MPT critici in procesul de evaluare si revizuire generala, monitorizati indeaproape pe masura ce proiectul avanseaza si trebuie facut un efort in plus pentru a modifica proiectul, a-l imbunatati si pentru optimizarea metodelor de predictie a mentenabilitatii si fiabilitatii. In esenta, o analiza a senzitivitatii este indreptata spre determinarea relatiilor dintre deciziile de proiectare si rezultate.

Identificarea riscurilor. Procesul evaluarii proiectului duce la decizii ce au un impact semnificativ in viitor. Selectarea criteriilor de evaluare, a factorilor importanti, a determinarii perioadei ciclului de viata, a folosirii anumitor surse de date si a metodelor de predictie si presupunerile facute in interpretarea rezultatelor analizei vor influenta in mod evident aceste decizii. Inerente acestui proces sunt aspectele "riscului" si "nesigurantei", pentru ca viitorul este, bineinteles, necunoscut. Desi acesti termeni sunt deseori folositi impreuna, riscul implica de fapt disponibilitatea anumitor date in forma unei distributii probabilistice in jurul unui parametru sigur. Nesiguranta implica o situatie ce poate fi probabilistica in natura sa, dar nu poate fi ilustrata in date discrete. Anumiti factori pot fi masurabili in termeni de risc, sau pot fi clasificati in anumite conditii de nesiguranta. Aspectul riscului si al nesigurantei, asa cum intervin in procesul de dezvoltare si proiectare a sistemului, trebuie integrati intr-un plan de management al riscului de program.


Recomandarea unei abordari preferentiale. Ultimul pas in procesul de evaluare este recomandarea unei alternative preferate. Rezultatele analizei trebuie sa fie bine documentate si facute cunoscute intregului personal implicat in procesul de proiectare. O lista a ipotezelor, a descrierilor procedurilor de evaluare ce au avut loc, o descriere a diferitelor alternative ce au fost considerate si o identificarea a zonelor potentiale de risc si nesiguranta trebuie inclusa in raportul acestei analize.

In figura 1 cerintele sistemului sunt stabilite in proiectarea conceptuala, analiza si alocarea functionala sunt indeplinite ori mai tarziu in proiectarea conceptuala, ori la inceputul proiectarii preliminare a sistemului, si proiectul in detaliu este realizat pe masura ce progreseaza acestea din urma. In afara acestor serii de pasi, exista un efort continuu ce implica sinteza, analiza si optimizarea proiectarii. In primele faze ale proiectului, anumite studii pot implica evaluarea profilurilor operationale alternative, aplicatiilor tehnologice alternative, schemelor de distributie sau a conceptelor de mentenanta. La inceputul proiectului preliminar, analiza se poate concentra pe: metodele alternative pentru indeplinirea unei functii date sau a unor scheme alternative de ambalare a echipamentului. In proiectarea detaliata, problemele vor fi la un nivel scazut in structura ierarhica generala a sistemului.




In orice caz, procesul ilustrat in figura 34 este aplicabil proiectului sistemului si efortului de dezvoltare. Singura diferenta consta in profunzimea analizei, tipul datelor cerute si a modelului folosit in indeplinirea analizelor. De exemplu, putem realiza o analiza a costului ciclului de viata inca de la inceputul proiectarii conceptuale sau mai tarziu in proiectul detaliat. Procesul este acelasi in ambele cazuri, cu toate acestea profunzimea analizelor si a datelor cerute este diferita. Sinteza, analiza si procesul de optimizare trebuie sa fie ajustate problemei in cauza. Un efort prea mic va genera mari riscuri asociate luarii deciziilor de proiectare, iar un efort prea mare va fi scump.


CONSIDERATII FINALE


Procesul ingineriei de sistem, discutat in acest capitol, este prezentat in forma unei "vederi de ansamblu", cu obiectivul stabilirii unui cadru de referinta pentru capitolele urmatoare. Capitolul 1 introduce conceptele si principiile logisticii, proiectarea intretinerii si include anumiti termeni si definitii legate de subiect. Este facuta o "abordare sistemica". Capitolul 2 ofera detalii ale unor dimensiuni (cum ar fi cele "metrice") asociate cel mai bine cu mentenanta si suportul logistic al sistemului, completand conceptele introduse anterior. Acest capitol ia in discutie cadrul pentru ingineria logisticii si proiectul intretinerii, oferind ilustrari despre cum trebuie sa fie considerata logistica in proiectare si dezvoltarea sistemului. Desi activitatile logistice sunt aplicabile in toate fazele ciclului de viata ale sistemului, accentul cade pe primele stadii cand procesul de luare a deciziilor are cel mai mare impact asupra intregii logistici si a costului ciclului de viata. Pentru ca procesul ingineriei de sistem sa fi implementat cu succes, se impune ca mentenanta si logistica sistemului sa fie luate in considerare inca de la inceput si incluse ca un factor important in diferitele activitati discutate in sectiunile 1-8. Cu alte cuvinte, ingineria logisticii este un ingredient important in procesul ingineriei sistemului.

Pe masura ce se vor parcurge capitolele urmatoare, conceptele introduse aici vor fi extinse si amplificate intr-un grad mult mai mare. Procesul ingineriei de sistem, avand logistica in prim plan, continua de-a lungul activitatilor de analiza a intretinerii, a revizuirii si integrarii proiectului, a testarii si evaluarii sistemului, a utilizarii si intretinerii acestuia si a incorporarii modificarilor dupa cerinte pentru imbunatatirea produsului / procesului. Informatiile prezentate in acest capitol ofera un cadru de lucru pentru cele mai multe dintre elementele ce vor fi luate in discutie in continuare.




Cu referire la Blanchard, B. S., si W. J. Fabrycky, "Analiza ingineriei de sistem", editia a 3-a, Prentice Hall, Inc., Upper Saddle River, N.J., 1998; sau Blanchard, B. S., "Managementul ingineriei sistemelor", editia a 2-a, John Wiley & Sons, Inc., New York, N.J., 1998.



Autorul defineste "conceptul de mentenanta" ca fiind o serie de inainte de a se intampla de ilustratii si declaratii despre cum trebuie intretinu sistemul si "planul de mentenanta" defineste cerintele pentru intretinerea sistemului bazandu-se pe o configuratie cunoscuta si pe rezultatele analizei mentenabilitatii (sau echivalent). Conceptul de mentenanta este o intrare in proiectare si planul de mentenanta este rezultatul proiectarii.

Politicile de reparatie sunt in final verificate printr-o analiza a nivelului de reparatie, al carei rezultat va conduce la un plan de mentenanta. Analiza nivelului de reparatie e in mod uzual indeplinita ca parte a unei analize a mentenabilitatii, a intretinerii sau a ambelor. Vezi Capitolul 4 pentru mai multe date.

MPT se refera la acele masuratori ale sistemului, ale procesului / activitatilor, sau ale produsului, ce sunt considerate critice pentru indeplinirea cu succes a obiectivelor ingineriei de sistem. Parametrii cantitativi specifici performantelor, ce reflecta caracteristicile inerente proiectarii, ar trebuie mai intai specificati si mai tarziu verificati prin testare si evaluare. Vezi Blanchard, B. S., si W. J. Fabrycky, "Analiza ingineriei de sistem", editia a 3-a, Prentice Hall, Inc., Upper Saddle River, N.J., 1998.

Cele mai bune referinte ale procesului QF sunt: (1)Yoji Akao, "Quality Function Deployment: Integrating Customer Requirements Into Product Design", Productivity Press, Portland, OR, tradus in engleza, 1990; si Lou Cohen, "Quality Function Deployment: How to Make QFD Work for You", Addison-Wesley, Reading, MA, 1995. Metoda QF a fost dezvoltata la Kobe Shipyard of Mitsubishi Heavy Industries, Ltd., Japan, in anii '60 si de atunci a evoluat considerabil.

Hauser, J.R., si D. Clausing, "The House of Quality", Harvard Business Review, mai-iunie 1988, pag. 63-7

Pentru a avea o perspectiva completa asupra procesului QF si a avantajelor implementarii sale, cititorul este sfatuit sa consulte literatura in domeniu. Aspectul prezentat aici este succint si intentioneaza sa ofere numai o "evaluare" a procesului.

In aplicarea principiilor ingineriei de sistem, nu o piesa a echipamentului, sau software, sau anumite date, sau un element al intretinerii ar trebui identificate sau procurate, fara a fi mai intai justificate nevoile pentru acestea printr-o analiza functionala. In multe proiecte anumite lucruri sunt deseori procurate pe baza a ceea ce este initial perceput ca fiind o "cerinta", dar mai tarziu se ajunge la concluzia ca nu mai este necesara. Aceasta practica se dovedeste a fi destul de costisitoare.

In ultimii ani, Ministerul Apararii al S.U.A. a accentuat in mod deosebit folosirea preferentiala a COTS fata de cautarea unor noi proiecte si de efortul de dezvoltare. Obiectivele sunt: reducerea timpului de dezvoltare si achizitie a noi sisteme, imbunatatirea service-ului si a intretinerii sistemului prin utilizarea componentelor standard, ce pot fi usor inlocuite cu piese de rezerva rapid disponibile, precum si reducerea costului ciclului de viata al sistemului. O buna referinta la acest subiect este raportul tehnic "American Defense Preparedness Associations Commercial-off-the-Shelf (COTS Supportability Study)", ADPA, Arlington, Va., 1994.

Conceptele arhitecturii si partitionarii unui sistem sunt prezentate in Rechtin, E., "Systems Architecting: Creating and Building Complex Systems", Prentice Hall, Inc., Upper Saddle River, N.J., 1991.

In figura 31 se presupune existenta factorilor de complexitate pentru toate componentele.

MTBM si Mpt pot fi alocate similar cu MTBF si, respectiv, Mct.

Ar fi de observat ca valorile Mcti nu sunt alocate folosind factorii de greutate, cum s-a procedat in cazul fiabilitatii, costului si MLH/OH. Mai degraba, valorile Mcti sunt estimate si apoi se face un calcul pentru a vedea daca Mct de sistem indeplineste cerintele specificate.

Observati ca, in orice caz, parametrii de mentenabilitate sunt dependenti inaintea parametrilor de fiabilitate. De asemenea, va surveni des faptul ca alocarea fiabilitatii este incompatibila cu alocarea mentenabilitatii (sau invers). Din acest motiv, este obligatorie existenta unei bucle inchise de relationare intre cele doua activitati.


Sinteza este mai bine acoperita in Lacy, J., "Systems Engineering Management", McGraw-Hill, New York, N.Y., 1992.

Exista multe tipuri de modele, incluzand modele fizice, simbolice, abstracte, matematice s.a.m.d. Modelul, asa cum este definit in cazul de fata, se refera mai ales la unul matematic (sau analitic). Dezvoltarea si aplicarea diferitelor metode analitice este acoperita mai tarziu in majoritatea documentelor de cercetare operationala. Doua excelente referinte sunt (1) Hillier, F.S. si G.J. Lieberman, "Introduction to Operations Research", 6-th Ed., McGraw-Hill, New York, N.Y., 1995; si (2) Taha, H.A., "Operations Research: AN INTRODUCTION", 5-th Ed., Macmillan, New York, N.Y., 1992.



}); Nu se poate descarca referatul
Acest referat nu se poate descarca

E posibil sa te intereseze alte referate despre:




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

Referate similare:






Cauta referat