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

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.

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.

(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

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

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.