Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství
Bakalářská práce
Webová aplikace pro prediktivní analýzu spolehlivosti Nikola Rytířová
Vedoucí práce: Ing. Martin Daňhel
14. května 2014
Poděkování V první řadě bych chtěla poděkovat svému vedoucímu práce Ing. Martinovi Daňhelovi za podporu a cenné rady, které mi poskytoval během vytváření práce. Dále bych chtěla poděkovat všem, kteří mě podporovali během celého studia, především svým rodičům, kteří mi studium umožnili.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.
V Praze dne 14. května 2014
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2014 Nikola Rytířová. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci Rytířová, Nikola. Webová aplikace pro prediktivní analýzu spolehlivosti. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.
Abstrakt Tato bakalářská práce se zabývá návrhem a implementací webové aplikace pro prediktivní analýzu spolehlivosti. Před samotným návrhem nabízí analýzu současného stavu řešené problematiky. Aplikace umožňuje spravovat systémy a jejich součásti a především vypočítávat spolehlivostní ukazatele. Kromě toho poskytuje teoretický základ pro pochopení struktury a práce s normou MILHDBK-217F, na které jsou založeny výpočty aplikace. Aplikace je založena na PHP frameworku Symfony2 a databázi MySQL. Klíčová slova Symfony2
spolehlivost, predikce, MIL-HDBK-217F, webová aplikace,
ix
Abstract This bachelor thesis deals with the design and implementation of web application for predictive analysis of reliability. Before the designing offers an analysis of current state of problematics. Application allows to manage systems and their components and primarily to calculate the dependability indicators. In addition, it provides a theoretical basis for understanding the structure and work with the MIL-HDBK-217F standard which the application calculations are based on. The application is based on the Symfony2 PHP framework and MySQL database. Keywords reliability, prediction, MIL-HDBK-217F, web application, Symfony2
x
Obsah Úvod
1
1 Cíle a struktura práce 1.1 Vymezení cílů práce . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 3 4
2 Spolehlivost a norma MIL-HDBK-217F 2.1 Základní pojmy a definice . . . . . . . . . . . . . . . . . . . . . 2.2 Norma MIL-HDBK-217F . . . . . . . . . . . . . . . . . . . . .
7 7 9
3 Analýza 3.1 Rešerše existujících řešení 3.2 Uživatelské role . . . . . . 3.3 Funkční požadavky . . . . 3.4 Nefunkční požadavky . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
15 15 21 21 22
4 Návrh relační databáze 23 4.1 Možnosti návrhu . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 Detailní popis vybraného návrhu . . . . . . . . . . . . . . . . . 25 5 Návrh webové aplikace 5.1 Výběr technologií . . . . . 5.2 Návrh webdesignu . . . . 5.3 Návrh tříd . . . . . . . . . 5.4 Porovnání návrhu s rešerší 5.5 Případy užití . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
29 29 29 30 32 33
6 Realizace 43 6.1 Použité technologie . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.2 Použité nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . 45 xi
6.3 6.4
Implementační poznámky . . . . . . . . . . . . . . . . . . . . . Nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46 53
7 Testování 55 7.1 Testování v různých prohlížečích . . . . . . . . . . . . . . . . . 55 7.2 Testování funkčnosti . . . . . . . . . . . . . . . . . . . . . . . . 55 7.3 Testování použitelnosti . . . . . . . . . . . . . . . . . . . . . . . 57 8 Výhled do budoucna
59
Závěr
61
Literatura
63
A Seznam použitých zkratek
65
B Obsah přiloženého CD
67
xii
Seznam obrázků 2.1
Sériový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 3.2 3.3 3.4 3.5
Formulář aplikace Reliability Analytics Toolkit Výsledek výpočtu aplikace Reliability Analytics Formulář aplikace SQC Online . . . . . . . . . Výstup aplikace SQC Online . . . . . . . . . . Detaily k výpočtu aplikace SQC Online . . . .
. . . . .
17 17 18 19 20
4.1
Datový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.1 5.2
Logo aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagram tříd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30 31
6.1 6.2 6.3 6.4
Architektura MVC . . . . . . . . Formulář pro přidání součástky . Schéma výpočtu intenzity poruch Model nasazení . . . . . . . . . .
44 51 52 53
. . . . . . . . . . systému . . . . .
xiii
. . . .
. . . .
. . . .
. . . . . Toolkit . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . .
8
Úvod Moderní doba s sebou přináší nové technologie a nové postupy, ale je také zdrojem nových problémů. Se spolehlivostí se setkáváme čím dál častěji na každém kroku, aniž bychom to tušili. Jak se doba mění, mění se i nástroje pro řízení, výrobu či obsluhu. Výpočetní technika dnes významně zasahuje do řízení snad všech oborů. Neoddělitelnou součástí technických požadavků na moderní systémy je jejich spolehlivost. Vysoká spolehlivost zařízení je požadována zejména u systémů, na jejichž správné funkčnosti závisí chod kritických aplikací nebo dokonce lidský život. Příkladem takovýchto systémů můžou být elektrárenská zařízení, letecké přístroje nebo lékařské vybavení. V souvislosti s termínem spolehlivosti je často zmiňován Murphyho zákon „Může-li něco selhat, pak to selže.“ Součástky mohou selhat a také selhávají a jen těžko se tomu dá zabránit. Proto je velmi důležité soustředit se spíše na znalosti charakteristik jednotlivých poruch a dále je využívat pro predikci spolehlivosti systému tak, aby se co nejvíce omezily možné závažné důsledky na celkový systém. Cílem je vytvořit systémy, v nichž poruchy jednotlivých součástek nevyvolávají změny funkčnosti, především nevedou k celkovému selhání systému. K tomuto účelu slouží prediktivní analýzy spolehlivosti. Jelikož dnešní elektronické systémy nabývají na složitosti a komplexnosti, získává studium spolehlivosti těchto systémů čím dál větší význam. Pro studium spolehlivosti je proto důležité mít nové a inovované nástroje, které umožní rychlé a přehledné spolehlivostní analýzy a výpočty. Sice existují moderní nástroje, které dokáží určit spolehlivostní parametry komplexních systémů, bohužel tyto nástroje nejsou běžnému uživateli dostupné, neboť jsou tak drahé, že si je můžou dovolit jen velmi bohaté organizace zabývající se pouze touto tematikou. Ve své bakalářské práci se zabývám tvorbou webové aplikace pro výpočet spolehlivostních parametrů dle vojenského standardu MIL-HDBK-217F N2. Má práce má sloužit jako základ pro vědecký projekt Ikaros, který se bude zabývat výpočtem spolehlivostních parametrů systémů pomocí různých norem 1
Úvod a porovnávat mezi sebou výsledky. Téma bakalářské práce jsem si vybrala především proto, že jsem viděla příležitost podílet se na nějakém větším projektu, kde bych mohla využít své tvůrčí schopnosti v oblasti návrhu webů a grafiky. Zaujala mě myšlenka, že se jedná o vědecký projekt, jehož existence je zamýšlena i po obhajobě této práce. S tím souvisí i možnost podílet se na tomto projektu v rámci své budoucí diplomové práce. Zejména pak spatřuji praktické využití své práce pro návrh spolehlivých systémů. Cílem práce je navrhnout a vytvořit webovou aplikaci, která bude umět vypočítat bezporuchovost vloženého systému a přitom bude uživatelsky přívětivá. Práce si neklade za cíl vytvořit celou škálu možností, které popisuje norma, ale naopak analyzovat možnosti návrhu webové aplikace, které jsou dnes k dispozici a pomocí nich posléze implementovat relační databázi a otestovat webové rozhraní na několika vybraných typech součástek.
2
Kapitola
1
Cíle a struktura práce 1.1
Vymezení cílů práce
Bakalářskou práci lze rozdělit mezi několik primárních a sekundárních cílů.
Primární cíle Ze zadání bakalářské práce vyplývá, že práce má čtyři primární cíle, které na sebe logicky navazují: 1. seznámit se s normou MIL-HDBK-217F (dále jen norma) 2. dle normy navrhnout strukturu relační databáze 3. vytvořit webovou aplikaci, která bude umožňovat pracovat s databází a počítat data dle normy 4. otestovat aplikaci na skutečných datech Cíl první: seznámení s normou Od prvního cíle se očekává především rozsáhlejší analýza normy, protože jak je patrné ze zadání, druhý cíl na tento přímo navazuje. Smyslem tohoto cíle není vytvořit příručku použití pro celou normu, ale v rámci bakalářské práce pochopit souvislosti a umět pracovat s normou, aby bylo možné relační databázi pokud možno jednoduše vytvořit. Cíl druhý: návrh struktury relační databáze Smyslem tohoto kroku je navrhnout a vytvořit relační databázi, která by odpovídala struktuře normy. Opět zde není cílem vytvořit relační databázi, která by pokrývala celou normu (není možné v rozsahu bakalářské práce převést celou normu do databáze i s naplněním důležitých dat z normy, tzv. číselníky), ale jen určitou výseč pro splnění cíle testování. 3
1. Cíle a struktura práce Cíl třetí: návrh webové aplikace Webová aplikace bude tvořit uživatelské rozhraní pro zadávání, mazání a editování dat v databázi. Především pak bude umět počítat spolehlivost zadaných systémů. Tento cíl by se tedy dal rozdělit na několik dalších podcílů: 1. tvorba webového rozhraní pro zadávání, editování a mazání součástek, či celých vložených systémů 2. výpočet spolehlivosti – pro každou vloženou, editovanou součástku je třeba přepočítat intenzitu poruch a to od součástky směrem k systému 3. udržování konzistence dat – pokud se uživatel rozhodne smazat součástku, ze systému, je nutné přepočítat systém tak, aby zobrazil/uložil správnou hodnotu intenzity poruch. Cíl čtvrtý: testování na skutečných datech Od vedoucího práce jsem obdržela data obsahující dva systémy včetně součástek. Cílem tohoto testování je ověřit nejen správnost výpočtu, ale i snadné ovládání aplikace.
Sekundární cíle Webová aplikace, kterou vytvářím je zamýšlena jako součást většího projektu s názvem Ikaros. Ten bude umožňovat počítat spolehlivost systémů pomocí různých revizí téže normy a také dalších existujících standardů. Z tohoto důvodu je pro webovou aplikaci zamýšlen jednotný vzhled. Tato bakalářská práce je první aplikací v tomto projektu. Proto je nutné aplikaci navrhnout tak, aby bylo možné ji dále rozšiřovat dalšími normami a standardy.
1.2
Struktura práce
Práce se skládá z osmi kapitol, které na sebe logicky navazují. První kapitola vymezuje cíle práce a pojednává o její struktuře. Druhá kapitola definuje zavedené názvosloví a uvádí použité definice, dále popisuje normu MIL-HDBK-217F N2, její spolehlivostní model, strukturu, data a uvádí dva možné přístupy k výpočtu spolehlivosti zařízení. Třetí kapitola se týká analýzy, je zde proveden rozbor běžně dostupných metod řešících prediktivní výpočet spolehlivostní analýzy, dále jsou zde rozebrány dvě existující aplikace, na jejichž základě je založeno navrhované řešení. Také jsou v této kapitole stanoveny funkční a nefunkční požadavky na aplikaci, včetně uživatelských rolí. Čtvrtá kapitola popisuje návrh relační databáze na základě požadavků uvedených v analýze a souvislosti s normou. 4
1.2. Struktura práce Pátá kapitola obsahuje návrh webové aplikace, zdůvodnění použitých vývojových systémů, zejména pak návrh webdesignu a strukturu implementace. Šestá kapitola popisuje realizaci a způsob implementace projektu. Obsahuje výčet použitých nástrojů a technologií a zabývá se implementačními otázkami, které jsem během vývoje řešila. Sedmá kapitola pojednává o testování aplikace, především o testování na experimentálních datech. Osmá kapitola se zabývá výhledem do budoucna. Navrhuje možná rozšíření a vylepšení stávající aplikace.
5
Kapitola
Spolehlivost a norma MIL-HDBK-217F 2.1
Základní pojmy a definice
Součástka V normě označována souhrnným pojmem prvek. Může být charakteru elektrického charakteru (např. rezistor, dioda) i neelektrického (např. světlovod, držák desky). Jedná se o atomickou část modelu, která je definována svými parametry, jakými jsou např. kvalita materiálu, jmenovitý výkon apod. Pro každý typ součástky můžou být, a obvykle také jsou, definovány jiné parametry.
Objekt Jedná se o velmi obecný pojem, jehož význam lze chápat podle toho, co je právě zkoumáno. Za objekt si lze dosadit libovolně malý či velký celek, který je možné zkoumat najednou. Ve své práci objekt většího celku, např. zařízení či nějaký funkční celek, označuji termínem systém.
Porucha Jev spočívající v ukončení schopnosti objektu (v tomto případě spíš prvku nebo součástky) plnit požadovanou funkci podle technických podmínek.
Chyba Rozdíl mezi správnou a skutečnou hodnotou nějaké veličiny.
Ukazatele spolehlivosti Zavedené veličiny, které lze jednotlivě vyhodnocovat. 7
2
2. Spolehlivost a norma MIL-HDBK-217F
Prediktivní hodnoty ukazatelů spolehlivosti Hodnoty, které jsou počítané na základě dříve pozorovaných nebo odhadovaných hodnot téže veličiny.
Spolehlivost Spolehlivost je dle [5] obecná vlastnost objektu, spočívající ve schopnosti plnit požadované funkce při zachování hodnot stanovených provozních ukazatelů v daných mezích a v čase podle stanovených technických podmínek. Z toho vyplývá, že spolehlivost je komplexní vlastnost, která není kvantifikovatelná. V anglosaské literatuře se spolehlivost označuje termínem Dependability, kterým je míněna ona komplexní nevyčíslitelná vlastnost. Termín Reliability se pak do češtiny překládá také jako spolehlivost, ale je míněn spíše ve smyslu životnosti či bezporuchovosti, která již lze vyjádřit číslem (Reliability je podmnožinou Dependability). Jestliže je v práci zmíněna spolehlivost, je tím myšlen termín Reliability, pokud není uvedeno jinak.
Intenzita poruch Intenzita poruch, označovaná symbolem λ, je převrácená hodnota střední doby bezporuchového provozu, lze ji chápat jako střední frekvenci poruch systému. Jednotkou intenzity poruch je čas v hodinách−1 .
MTBF (Mean Time Between Failure) Střední hodnota provozní doby objektu, během níž nenastala žádná porucha (střední doba mezi poruchami). Jednotkou této veličiny je čas v hodinách.
Sériový spolehlivostní model Využívá se v případě, kdy porucha kteréhokoliv prvku způsobí poruchu celku. Časové intervaly do poruchy jsou navzájem nezávislé náhodné veličiny. Sériový model je tvořen bloky B1 až Bn viz obrázek 2.1.
Obrázek 2.1: Sériový model s n prvky 8
2.2. Norma MIL-HDBK-217F Pokud je známa pravděpodobnost bezporuchového provozu Ri (t) pro jednotlivé prvky Bi , výslednou pravděpodobnost R(t) lze vyjádřit součinem pravděpodobností jednotlivých bloků. Čili R(t) =
n Y
Ri (t)
(2.1)
i=1
a pro konstantní intenzitu poruch λi každého bloku funkce R(t) vychází R(t) =
n Y
e−λi t = e−λt ,
(2.2)
i=1
kde λ je výsledná intenzita poruch systému, získaná jakožto součet intenzit poruch prvků λi λ=
n X
λi
(2.3)
i=1
Z tohoto vztahu pro tuto práci vyplývá velice důležitá věc, totiž, že sériové spojení n prvků se zadanými konstantními intenzitami poruch lze nahradit jedním jediným prvkem s celkovou intenzitou poruch získanou součtem intenzit poruch všech prvků. Střední dobu bezporuchového provozu lze určit integrací 2.2 v intervalu (0, ∞). Pro konstantní intenzity poruch λi vychází 1 1 Ts = Pn = (2.4) λ λ i=1 i Podrobnější informace ohledně uvedených definic a spolehlivostních modelů lze nalézt např. v [7].
2.2 2.2.1
Norma MIL-HDBK-217F Historie
Vojenská příručka MIL-HDBK-217 (Military Handbook: Reliability Prediction of Electronic Equipment), dále jen norma, se používá pro výpočet predikce bezporuchovosti elektronických zařízení. Jedná se o americkou vojenskou normu z let 1961-1995, kdy byla postupně revidována a aktualizována. Celkem existuje šest revizí, které se označují velkým písmenem za číslem normy MILHDBK-217 F. Poslední revizí je rev. F z 2. prosince roku 1991 a nahrazuje rev. E N1. Jednotlivé revize se dále často ještě postupem času aktualizovaly a daly tak vznik nové revizi normy. Aktualizace se označují N (Notice) a číslem aktualizace např. MIL-HDBK-217 E N1, poslední aktualizace rev. F pochází z 28. února 1995 a celá norma se tak označuje názvem MIL-HDBK-217 F N2, jedná se tudíž o téměř 20 let starou normu. V každé aktualizaci jsou vždy obsaženy pouze nové či editované stránky, ve kterých je jasně napsáno, kterou revizi či její aktualizaci vlastně nahrazují. 9
2. Spolehlivost a norma MIL-HDBK-217F
2.2.2
Rozvržení normy
V této práci jsem z důvodu praktičnosti použila poslední revizi a poslední aktualizaci normy z roku 1995. Pokud je v textu dále zmíněna norma, je automaticky zamýšlena včetně své poslední aktualizace N2. Bylo tedy potřeba mít k dispozici normu revizi F, aktualizaci 1 a aktualizaci 2. Vycházela jsem tedy z těchto tří dokumentů, které lze bezplatně stáhnout na internetu, např. na [3]. Norma je rozdělena na dvě části podle dvou možných metodických přístupů výpočtů predikce spolehlivosti: 1. Metoda namáhání prvků – velmi propracovaná metoda, která má definován model poruchy pro daný typ součástky. Tato metoda je použitelná, pouze pokud jsou známy parametry jednotlivých prvků jako kvalita, prostředí, materiál, typ použití a dále pak provozní hodnoty činitelů namáhání, většinou se jedná o znalost konkrétního vyzářeného výkonu, teploty apod. 2. Metoda počítání z prvků – jedná se o velmi jednoduchou metodu, která se užívá zejména, když není znám dostatek informací pro použití první metody. Její výsledky jsou tudíž značně nepřesné či spíše orientační. Ve své práci se dle zadání zaměřuji pouze na metodu namáhání prvků, která slouží právě k prediktivní analýze spolehlivosti. Tato část normy je rozdělena do 23 sekcí. Prvních pět sekcí je tvořeno úvodem, obsahem, referencemi apod. Zbylých 18 sekcí popisuje jednotlivé kategorie součástek např. rezistory, kondenzátory, indukčnosti apod. Většina sekcí se hierarchicky dělí na další podsekce, jež odpovídají různým druhům součástek v dané kategorii. Např. sekce 5 obecně popisuje mikroobvody a je dále rozdělena na hradlová, logická pole a mikroprocesory, paměti, VLSI CMOS, digitální zařízení, hybridy atd. Uživatel si tedy přesně vybere daný typ součástky (pokud jej norma zmiňuje) a podle doporučení provádí výpočet.
2.2.3
Výpočet bezporuchovosti
Základní postup pro určení celkové intenzity poruch je odvozen ze sériového spolehlivostního modelu, kde se intenzity poruch sčítají. Každou součástku si lze představit jako samostatný blok, který je definován nějakými parametry. A pro každý blok lze dle normy vypočíst intenzitu poruch λ. K získání výsledné intenzity poruch pro celý systém pak stačí sečíst všechny intenzity poruch bloků (součástek). Obecný postup pro určení intenzity poruch konkrétního typu součástky je založen na násobení základní intenzity poruch součástky koeficienty, které reprezentují zatížení, neboli namáhání součástky v provozu a prostředí. Obecná 10
2.2. Norma MIL-HDBK-217F rovnice pro určení intenzity poruch elektronické součástky λp má například následující tvar: λp = λb πT πA πR πS πC πQ πE ,
(2.5)
kde λb – základní intenzita poruch prvku πT – faktor závislosti na teplotě πA – faktor závislosti na použití πR – výkonový faktor πS – faktor zatížení πC – konstrukční faktor πQ – faktor kvality πE – faktor prostředí Nutné je však podotknout, že je tato rovnice pouze ukázková, každý prvek má jinak definovaný poruchový model, což vychází i z principu jeho funkčnosti. Obecně lze říci, že faktor prostředí a faktor kvality je obsažen téměř v každé rovnici pro intenzitu poruch daného typu prvku. Použití i význam ostatních faktorů se pro jednotlivé typy prvků liší. Konkrétní hodnoty základní intenzity poruch a všech potřebných faktorů se určují dle tabulek uvedených v normě. V mnoha případech je také možné tabulkové hodnoty aproximovat dle uvedených vzorců, je přitom třeba dát pozor na mezní vstupní hodnoty aproximace.
2.2.4
Práce s normou
Při práci s normou je velkou nevýhodou, že ji lze získat pouze ve skenované podobě na internetu a veškeré informace je tak nutné ručně přepisovat, přičemž některé údaje nejsou příliš čitelné. V této podkapitole uvádím názornou ukázku pro výpočet intenzity poruch rezistoru a je zde také mimo jiné uvedena širší možnost využití aproximačních vzorců místo předpřipravených tabulek.
Sekce 9: Rezistory V původním vydání normy rev. F o rezistorech pojednávaly sekce 9.0 až 9.17, které jsou v posledním aktualizovaném vydání rev. F N2 nahrazeny a podstatně zjednodušeny jedinou sekcí 9.1. Vzorec pro výpočet intenzity poruch rezistoru je λp = λb πT πP πS πQ πE [
poruch hodin] 106
(2.6) 11
2. Spolehlivost a norma MIL-HDBK-217F Význam jednotlivých parametrů přesně odpovídá číselníkům (dvou- či třísloupcové tabulky), které k nim jsou přiřazeny. Součástka typu rezistor má definováno tedy 6 číselníků: 1. Materiál rezistoru, který určuje základní intenzitu poruch, jinak označován jako typ rezistoru (Resistor Style — λb ) Jedná se o nejdůležitější číselník, protože mimo jiné udává odkazy do dalších dvou číselníků (teplotního a zátěžového faktoru) a podle toho, jaký materiál rezistoru uživatel zvolí, se vybere příslušný odkaz, která hodnota se má v oněch číselnících použít. 2. Teplotní faktor (Temperature Factor – πT ) Přestože má tento parametr svůj vlastní číselník norma udává i jeho možnou aproximaci pomocí vzorce h
πT = exp
−Ea 1 i 1 − , 8.617 ∗ 10−5 T + 273 298
(2.7)
kde Ea je parametr závislý na použitém materiálu a T je teplota pouzdra ve stupních Celsia. Protože je tento číselník ovlivněn volbou typu materiálu (jak bylo zmíněno výše), je potřeba zvolit i příslušnou konstantu za parametr Ea , která může nabývat pouze hodnot Ea = {0.2, 0.08, 0}. Za zmínku stojí hodnota Ea = 0, kterou jsem do vzorce doplnila. Ta znamená, že pro daný materiál není teplotní faktor definován. V takovém případě číselník automaticky předpokládá, že πT = 1. U všech součástek platí, že pokaždé, kdy není určitý faktor definován, se předpokládá jeho hodnota rovna jedné, aby se zachovala platnost obecné rovnice. Teplota pouzdra součástky může být odvozena od teploty okolí, ve kterém se součástka nachází, což lze jednoduše změřit. Dále má číselník omezení pro maximální teplotu T = 150o C. Pokud by bylo potřeba počítat s vyšší teplotou, je nutné použít právě výše uvedený aproximační vzorec 2.7. Zde je ovšem třeba mít na paměti, že maximální možnou teplotu součástky určuje výrobce, a proto teplotu nelze aproximovat do nekonečna. 3. Výkonový faktor (Power Factor – πP ) I tento faktor má vlastní číselník, ale také nabízí aproximační vzorec. πP = (P ower Dissipation)0.39
(2.8)
Ztrátový výkon (Power Dissipation) je klasicky udáván v jednotkách Watt. Aproximační vzorec je vhodný zejména proto, že číselník nemá 12
2.2. Norma MIL-HDBK-217F jednotné rozdělení, takže vybírání a zaokrouhlování ztrátového výkonu z tabulky by značně zhoršovalo výslednou přesnost vypočtené spolehlivosti. 4. Zátěžový faktor (Power Stress Factor – πS ) Stejně jako teplotní faktor πT je i zátěžový faktor závislý na materiálu rezistoru. Dle použitého typu materiálu se v tabulce vybere příslušný odkaz do číselníku zátěžového faktoru. Nejprve je ale nutné určit výkonové zatížení (Power Stress), které se udává v procentech a je to poměr aktuálního ztrátového výkonu ku maximálnímu možnému výkonu viz vzorec 2.9. Bohužel i tento číselník je rozdělen, a to po deseti procentech, čili další možná nepřesnost, která by se musela později nějak řešit. S=
Actual P ower Dissipation Rated P ower
(2.9)
Zátěžový faktor má však také aproximační rovnice a to dokonce dvě, protože dle typu materiálu se vybírá buď první (2.10), či druhý (2.11) vzorec. πS = 0.71e1.1(S)
(2.10)
πS = 0.54e2.04(S)
(2.11)
Nutno podotknout, že tato aproximace je vzhledem ke vstupním hodnotám oproti číselníku přesnější. 5. Kvalitativní faktor (Quality Factor – πQ ) Tento faktor má téměř každý prvek. Obecně se jedná se o velmi jednoduchý číselník většinou o pěti až deseti hodnotách. Asi nejzajímavějším a nejběžnějším ohodnocením kvality je označení „komerční“ nebo „neznámý“ (jedná se o nejhorší kvalitu), ostatní ohodnocení kvality jsou např. zde u rezistoru přísně specifikovány standardy, které lze najít v tabulce materiál rezistoru, kde je ve specifikacích pro daný materiál uvedena i konkrétní norma zabývající se tímto typem materiálu součástky. Samotní výrobci často u svých velmi kvalitních součástek uvádí i konkrétní ohodnocení kvality v souvislosti s touto normou, ale nebývá to pravidlem vzhledem ke stáří normy. 6. Faktor prostředí (Environment Factor – πE ) I tento faktor má téměř každý prvek. Faktor prostředí je jednoduchý číselník, který má vždy 14 záznamů, pouze se liší hodnoty u každého typu součástky. Protože se jedná o vojenskou normu, předpokládá se vývoj 13
2. Spolehlivost a norma MIL-HDBK-217F systémů nejen pro laboratoře, komerční budovy, automobilový průmyslu, ale i pro letectví, námořnictví, raketové zbraně apod. Všechny aproximační vzorce, které jsou zde uvedeny, jsem porovnala s tabulkovými hodnotami z aktualizace N2, jednak proto, abych si ověřila, že jsem špatně neopsala vzorec (norma je digitalizována pomocí skeneru a některé údaje jsou hůře čitelné) a také proto, abych případně zjistila, jaká je chyba při výpočtu.
14
Kapitola
Analýza 3.1
Rešerše existujících řešení
3.1.1
Současný stav řešené problematiky
V současné době se řeší prediktivní analýza spolehlivosti velmi sofistikovanými nástroji, které pracují podle nejrůznějších metodik. Vedle normy MIL-HDBK217F existují i jiné standardy zabývající se predikcí spolehlivosti, z nichž mnohé jsou založeny na podobných principech, a to na dlouhodobém sledování provozních ukazatelů a poruchovosti již hotových systémů.
3.1.2
Ostatní metodiky a normy
Různých metodik, norem a spolehlivostních standardů je mnoho, proto zde uvádím výčet nejznámějších, které se nějakým způsobem týkají normy MILHDBK-217F. FMEA V současnosti patří metoda FMEA (Failure Mode and Effect Analysis) k nejužívanějším metodám prediktivní analýzy bezporuchovosti a bezpečnosti systému od nižší k vyšší úrovni členění systému a zkoumá selhání pro vyšší úrovně systému. FMEA slouží k identifikaci způsobů poruch systémů, jejich příčin a důsledků. [11] RAC PRISM Jedná se o standard pro výpočet predikce za pomoci bezporuchovosti elektronických a neelektronických prvků, která obsahuje úspěšnou implementaci některých vojenských norem. Výrobcem je společnost RAC (Reliability Analysis Center) a není dostupná jinak než se softwarovým balíkem. [14] 15
3
3. Analýza FIDES Standard vytvořený konsorciem francouzských průmyslových podniků leteckého a zbrojního průmyslu. Jedná se v podstatě o evropský ekvivalent normy MIL-HDBK-217F pro elektronické vybavení. V současnosti je FIDES nejnovější metodika pro prediktivní analýzy spolehlivosti, která se využívá především v letectví (např. dopravní letadla Airbus). [4]
3.1.3
Spolehlivostní databáze
Většina metod je založena na sledování provozních ukazatelů spolehlivosti pomocí tzv. spolehlivostní databáze. Například uvedené standardy RAC PRISM nebo FIDES nejsou jen pouhými metodikami jako FMEA. Jedná se o celá softwarová řešení, které obsahují i svou vlastní databázi spolehlivosti pro jednotlivé prvky. Společnost RAC však vyvinula i samotné spolehlivostní databáze, díky kterým lze počítat spolehlivostní ukazatele dokonce podle několika různých metrik. Jedná se o dvojici databází EPRD-97 (Electronic Parts Reliability Data) a NPRD-95 (Nonelectronic Parts Reliability Data). První z databází obsahuje pouze součástky elektronického charakteru jako je dioda, tranzistor apod. Druhá databáze obsahuje prvky neelektronického charakteru, jako jsou držáky desek, světlovody, šrouby apod. Databáze se vzájemně doplňují a neobsahují duplikovaná data.
3.1.4
Dostupné webové aplikace
Samozřejmě existují i nejrůznější nástroje, ať už desktopové či webové, které jsou založeny přímo na normě MIL-HDBK-217F. Přestože samotná norma je k dispozici zdarma, existuje mnoho aplikací postavených na této normě, které již zdarma nejsou. Většinou se jedná o velmi drahé produkty, které zřídkakdy poskytují demoverzi. Protože se však má práce zabývá tvorbou webové aplikace, k rešerši předkládám dvě vybrané webové aplikace, které jsou volně dostupné. Na internetu lze najít více obdobných aplikací, které řeší predikci spolehlivosti, většinou se však jedná o beta či demoverze. Reliability Analytics Toolkit První zmíněnou aplikací je aplikace Reliability Analytics Toolkit, vyvinutá společností Reliability Analytics Corporation. Jedná se o beta verzi, která je volně dostupná na webu viz [10]. Aplikace je založena na metodě počítání z prvků, která byla zmíněna v 2.2.2, jedná se tedy o jednodušší metodu. V podstatě vše potřebné pro výpočet spolehlivosti je přehledně umístěné na pouhé jediné stránce. Celé aplikaci tak dominuje pouze jeden velký formulář sloužící k zadávání dat, ve zkrácené 16
3.1. Rešerše existujících řešení podobně je uveden na obrázku 3.1. Druhý obrázek 3.2 pak zobrazuje výsledek ukázkového výpočtu intenzity poruch systému včetně vstupních parametrů.
Obrázek 3.1: Formulář aplikace Reliability Analytics Toolkit
Obrázek 3.2: Výsledek výpočtu aplikace Reliability Analytics Toolkit Ve formuláři na obrázku 3.1 lze nastavit výchozí kvalitu a prostředí pro všechny součástky, zároveň je možné tyto hodnoty měnit pro konkrétní typ součástek. Aplikace dokonce umožňuje i pojmenování součástek, aby seznam odpovídal schématu. Dále je možné vygenerovat výsledky (vypočtenou spolehlivost) buď přímo v prohlížeči nebo do excelovského souboru. Za hlavní výhodu považuji fakt, že uživatel dostane k dispozici přímo rozpis součástek s vypočtenou spolehlivostí. Zajímavá je i možnost nastavení počtu desetinných míst od 1 do 10. Tato možnost je ovšem velmi sporná, neboť vypočtené hodnoty pro jednotlivé součástky jsou sice ve výpisu zaokrouhleny na definovaný počet míst, celkového výpočtu a výsledku se ale tato změna netýká. Zřejmě jde pouze o zpřehlednění číselného výstupu či případné bližší zkoumání jednotlivých prvků. 17
3. Analýza Výsledná tabulka s vypočítanými hodnotami opakuje vložená data ze vstupního formuláře a k jednotlivým typům součástek přikládá vypočtené hodnoty. Poté následuje konečné vypočtení intenzity poruch respektive MTBF. Dle výběru aplikace případně dodá i .xls soubor s výsledky.
SQC Online – Military Handbook MIL-HDBK-217 Druhou webovou aplikací je kalkulátor Military Handbook MIL-HDBK-217 na serveru SQC Online. [12] Opět se jedná o verzi beta. Nyní je ale aplikace založená na metodě namáhání prvků, čili pro každý typ součástky je nutné zadat podrobnější parametry. Formulář na obrázku 3.3 je určen pro výpočet intenzity poruch rezistoru, formuláře pro další součástky jsou obdobné, liší se pouze typem a počtem zadávaných parametrů.
Obrázek 3.3: Formulář aplikace SQC Online Na formuláři z obrázku 3.1 je možno vybrat parametry ze tří číselníků, typ rezistoru, kvalita a prostředí. Ostatní parametry je nutno uvést číselně. Oproti předchozí metodě je zde o poznání více parametrů. Za zmínku stojí, že tento formulář slouží k určení intenzity poruch pouze jedné součástky. Oproti tomu předchozí metoda umožňovala určit intenzitu poruch i pro několik součástek stejného typu (musí mít však shodně nastavené prostředí a kvalitu). Zejména proto je tato metoda náročnější nejen časově, ale i informačně, uživatel musí mít podrobné informace o součástkách zkoumaného systému. 18
3.1. Rešerše existujících řešení Zajímavostí této aplikace je odkaz do normy pod titulkem Notes, kde je možné podrobnější prozkoumání všech parametrů, ze kterých se skládá vzorec pro určení intenzity poruch rezistoru. Po stisknutí tlačítka Submit vypíše aplikace výsledky ve formátu zobrazeném na obrázku 3.4. Opět jsou zde pro přehlednost zopakovány vstupní parametry a všechny očekávané výsledky. Celý výstup doplňuje tabulka viz obrázek 3.5, kde jsou přehledně rozepsány výsledky jednotlivých faktorů ovlivňujících výslednou intenzitu. Z obou náhledů výstupu je patrné, že výpočet dle metody namáhání prvků je sice propracovanější a přesnější ale uživatelsky náročnější. Hlavní nevýhodou této aplikace je, že nenabízí možnost jednoduchého uložení vypočtených hodnot, jako tomu bylo u předchozí aplikace. Tato nevýhoda je dána především tím, že aplikace nabízí detailní pohled na konkrétní součástku a neřeší žádnou návaznost na systém, ve kterém je součástka obsažena.
Obrázek 3.4: Výstup aplikace SQC Online
19
3. Analýza
Obrázek 3.5: Detaily k výpočtu aplikace SQC Online
Výhody a nevýhody uvedených aplikací Výhody první zmíněné aplikace spočívají v tom, že umožňuje zadávat najednou více součástek a z nich pak spočítat spolehlivost jak pro jednotlivé součástky, tak celkovou spolehlivost. Velmi užitečné je také exportování výsledku do souboru. Drobnou nevýhodou je to, že je založena pouze na jednodušší metodě počítání z prvků a neumožňuje tak detailnější spolehlivostní analýzy. Co se týče druhé popsané aplikace, výhodou je, že už je založena na metodě namáhání prvků a její rozhraní je tak uzpůsobeno na zadávání většího množství dat. Velkou nevýhodou ale zůstává, že se omezuje na zadávání a výpočet pouze jedné součástky a je tak plně izolovaná od spolehlivosti celého systému. Její funkčnost navíc pokrývá pouze menší množství součástek. Zásadní nevýhodou obou aplikací je, že neumožňují dlouhodobější správu systémů a jejich částí a případnou další editaci. Právě tento nedostatek řeší navrhovaná webová aplikace.
20
3.2. Uživatelské role
3.2
Uživatelské role
Navrhovaná aplikace rozlišuje tři uživatelské role: 1. Anonymní uživatel 2. Přihlášený uživatel 2.1 Běžný uživatel – ROLE_USER 2.2 Správce – ROLE_ADMIN 1. Anonymní uživatel: Má přístup pouze na úvodní stránku a stránku o normě. 2.1 Běžný uživatel: Má práva pro vytváření systémů, desek, součástek a všechny operace, které s nimi lze vykonávat. Má přístup ke všem svým systémům, které vytvořil a které jsou aktivní, tzn. nesmazané. Role běžného uživatele je přidělena automaticky registrací uživatele. 2.2 Správce: Dědí všechna práva od běžného uživatele. Navíc má možnost zobrazit všechny systémy, které byly uloženy všemi uživateli, včetně smazaných. Tyto systémy ovšem nemá právo editovat nebo mazat. Role správce musí být nastavena přímo v databázi.
3.3
Funkční požadavky
F1 Autentizace uživatele F1.1 Registrace uživatele F1.2 Přihlášení uživatele F1.3 Odhlášení uživatele F2 Správa systémů F2.1 Vytvoření systému F2.2 Zobrazení detailu systému F2.3 Editace systému F2.4 Smazání systému F2.5 Zobrazení uložených systémů 21
3. Analýza F2.5.1 Zobrazení uložených systémů pouze přihlášeného uživatele F2.5.2 Zobrazení všech uložených systémů (vyžaduje ROLE_ADMIN) F3 Správa desek F3.1 Vytvoření desky F3.2 Zobrazení detailu desky F3.3 Editace desky F3.4 Smazání desky F4 Správa součástek F4.1 Vytvoření součástky F4.2 Zobrazení detailu součástky F4.3 Editace součástky F4.4 Smazání součástky
3.4
Nefunkční požadavky
N1 Implementace v jazyce PHP N2 Použití frameworku Symfony2 N3 Využití databáze MySQL N4 Webové uživatelské rozhraní využívající HTML, CSS, jQuery N5 Výpočty na základě normy MIL-HDBK-217F N2 N6 Rozšiřitelnost aplikace
22
Kapitola
Návrh relační databáze Návrh relační databáze je jednou z nejdůležitějších fází projektu, protože se jedná o základní stavební prvek celé aplikace. Databázová struktura by se v pozdějších fázích projektu velmi obtížně měnila a její změny by mohly mít katastrofální dopad na celý projekt. Proto je velmi důležité pečlivě zvážit různé možnosti návrhu databáze, aby případné změny či pozdější rozšíření aplikace byly co nejjednodušší. Před samotným návrhem bylo nutné si zodpovědět na několik otázek. 1. Co je třeba do databáze ukládat? 2. Jakým způsobem budou data z databáze vyčítána? Odpovědi na otázky jsou následující: 1. Databáze bude obsahovat velké množství dat, jelikož systémy se můžou skládat ze stovek součástek. Proto je velmi vhodné použít návrh, který bude přehledný a snadno udržovatelný. Databáze musí pokrývat všechny parametry systémů a jeho komponent a zároveň poskytovat číselníkové tabulky dané normou. 2. Vzhledem k velkému množství dat je nutné myslet také na efektivitu dotazování. Velmi důležité je navrhnout databázi tak, aby s ní uměla webová aplikace jednoduše spolupracovat a nemusela vytvářet složité dotazy.
4.1 4.1.1
Možnosti návrhu První možnost návrhu
Jeden z návrhů se zakládal na myšlence co nejobecnější a nejuniverzálnější struktury, který by se skládal pouze z několika tabulek typu 23
4
4. Návrh relační databáze 1. Objekt (systém, deska, součástka) 2. Obecná vlastnost Výhoda tohoto návrhu spočívá v tom, že se dá snadno přidat nová vlastnost i součástka bez ovlivnění dalších tabulek. Vyvstává však spoustu problémů spojených s tímto návrhem, např. by se nějak muselo řešit to, že vlastnosti nemají vždy stejně definovaný typ. Co se týče efektivity dotazování, bylo by nezbytné neustále používat JOIN, případně mnoho SELECTů, což by vedlo ke stále složitějším dotazům. Přehlednost dat v databázi by byla rovněž mizivá a vyvářel by se prostor pro další chyby, neboť veškerá integritní omezení by musela hlídat samotná aplikace. Nebylo by také možné automaticky mapovat databázové entity na PHP třídy, se kterými by aplikace mohla pracovat, vyčtená data z databáze by se musela do tříd mapovat ručně, což je zbytečné, když použitý framework Symfony2 umožňuje automatické mapování. Celá spolupráce mezi webovou aplikací a databází by tak byla velice komplikovaná. Po důkladném zvážení jsem tento návrh zavrhla.
4.1.2
Druhá možnost návrhu
Místo prvního popsaného návrhu jsem si zvolila návrh databáze takový, aby byl co nejpřehlednější a dobře se s ním pracovalo. Pro každý typ objektu (systém, deska, součástka) bude vytvořena vlastní tabulka obsahující potřebné vlastnosti. Každý typ součástky pak bude mít opět vlastní tabulku, která bude vycházet z obecné entity pro součástku. Sice se databáze bude skládat z mnoha tabulek, které budou každým rozšířením přibývat, avšak správa a údržba databáze bude i přes rostoucí počet tabulek jednodušší a hlavně čitelnější. Přidání součástky je stále jednoduché, neboť se jen přidá nová entita, případně její číselníky, která neovlivní žádné jiné tabulky. Přidání vlastnosti by sice změnilo strukturu databáze, ale změna by se týkala pouze jedné entity, navíc vlastnosti jsou jasně dané normou a nepředpokládá se tak jejich změna. Tento návrh umožňuje přímé mapování na PHP třídy, je tak efektivnější a zároveň zajišťuje jednodušší dotazování. Protože samotná norma je psaná formou tabulek, nabízí se logická možnost pro většinu tabulek s pevně danými hodnotami vytvořit číselníky. Existují však některé tabulky, které mají v normě uvedeno pouze několik záznamů a nemá smysl pro ně tvořit číselník v databázi, efektivnější je zpracovávat tyto tabulky aplikačně. Norma dále obsahuje vzorce pro výpočty intenzity poruch, tyto výpočty je výhodnější řešit aplikačně a do databáze ukládat pouze výsledky. Pokud by byly vzorce uloženy přímo v databázi, musely by se v aplikaci složitě parsovat. 24
4.2. Detailní popis vybraného návrhu
4.2
Detailní popis vybraného návrhu
Vybraný návrh databáze obsahuje dvě kategorii tabulek: 1. Tabulky, které budou přímo mapovány na PHP třídy webové aplikace. Týká se tabulek pro uživatele, systémy, desky plošných spojů a všechny typy součástek. 2. Číselníky, které budou pouze v databázi a budou sloužit pouze pro uložení globálních hodnot stanovených normou. Webová aplikace pak bude vyčítat a ukládat pouze potřebné hodnoty nutné pro výpočty spolehlivosti. Do první kategorie spadají následující tabulky. User Entita reprezentující uživatele, ve které jsou uloženy přihlašovací údaje a jednoznačný identifikátor ID_User. Uživatel může mít uloženo 0 až N systémů. System Entita reprezentující systém, která obsahuje parametry systému, z nichž některé slouží jako výchozí hodnoty pro součástky. Mezi tyto parametry patří prostředí (Environment) a teplota (Temp). U systému je uložena také spočítaná intenzita poruch celého systému (Lam) a datum vytvoření, resp. smazání systému. Systém je jednoznačně identifikován pomocí primárního klíče ID_System, zároveň obsahuje cizí klíč v podobě odkazu na uživatele (ID_User). Systém může mít 0 až N desek plošných spojů. PCB Entita PCB reprezentuje desku plošných spojů, která shromažďuje parametry potřebné k výpočtu spolehlivosti desek. Do této tabulky se rovněž ukládají parametry pro součástky s drátovými vývody jako např. počet bodů pájení. Parametry pro součástky se SMT vývody jsou ukládány v samostatné tabulce. Tabulka PCB obsahuje tři vypočtené hodnoty intenzity poruch: 1. Lam: Intenzita poruch pro součástky s drátovými vývody. 2. SumLam: Intenzita poruch celé desky, tzn. součet spolehlivostí pro součástky s drátovými vývody a pro všechny záznamy součástek se SMT vývody. 3. SumPartsLam: Součet intenzit poruch všech součástek vztažených k dané desce. 25
4. Návrh relační databáze Deska je identifikována primárním klíčem ID_PCB a odkazuje se na systém pomocí cizího klíče (ID_System). Stejně jako systém obsahuje datum vytvoření, resp. smazání desky. Deska má 0 až N součástek a 0 až N záznamů pro součástky se SMT vývody. Ačkoli norma MIL-HDBK-217F řadí desku plošných spojů na stejnou úroveň jako ostatní součástky, reálně se součástky zapojují právě na konkrétní desku. V návrhu je proto deska reprezentována samostatnou tabulkou, ke které se vztahují další součástky. PartSMT Entita reprezentující součástky se SMT vývody, která obsahuje parametry pro výpočet a vypočtenou intenzitu poruch (Lam). Také obsahuje datum přidání, resp. smazání záznamu. Jednoznačným identifikátorem je ID_Part_SMT, cizím klíčem pak odkaz na desku (ID_PC B). Part Entita reprezentující obecný popis součástky, která obsahuje společné atributy pro všechny typy součástek. Jednotlivé typy součástek jsou navrženy jako samostatné tabulky ISA hierarchie. Tabulka Part ukládá opět vypočtenou intenzitu poruch součástky (Lam), stejně tak datum vytvoření, resp. smazání součástky. Jednoznačným identifikátorem je ID_Part, cizím klíčem odkaz na desku (ID_PCB). Resistor, Capacitor a další Entity reprezentující konkrétní typ součástky. Každá taková entita dědí atributy z entity Part a dále obsahuje atributy potřebné pro daný typ součástky. Druhou kategorií tabulek jsou číselníky. Typicky pokrývají výčet materiálů, kvalit nebo druhů součástek, které může uživatel zadat. Jedná se např. o tabulky MaterialResistor, QualityResistor apod., z nichž každá se váže k danému typy součástky. Výjimečnou tabulkou je tabulka Environment, která se vztahuje ke všem typům součástek. Tato tabulka obsahuje ve sloupcích konkrétní prostředí a jednotlivé řádky pak určují typ součástky a příslušné hodnoty definované normou. Konceptuální schéma datového modelu bylo navrženo v Data Modeleru a je zobrazeno na obrázku 4.1. Návrh obsahuje velké množství tabulek, proto jsou zde zachyceny pouze tabulky potřebné pro vytvoření aplikace. Celé schéma je uloženo na přiloženém CD.
26
4.2. Detailní popis vybraného návrhu
PCB
SYSTEM # * ID_System * Title * CreateDate o DeleteDate o Lam * Temp o Note o Environment
SUBSTRATEMATERIAL
# * ID_PCB * Label * Lifetime * Quality * Layers o SolderingPointAuto o SolderingPointHand o Lam o SumLam o SumPartsLam * CreateDate o DeleteDate
# * Description * Value EQUIPMENTTYPE # * Description * Value
PARTSMT
USER #* * * * * *
ID_User Username Password Mail Salt Role
MATERIALRESISTOR #* * * * *
ResShortCut Description Lamb FactorT FactorS
QUALITYRESISTOR * Description # * Value QUALITYCAPACITOR * Description # * Value MATERIALCAPACITOR #* * * * * * *
CapShortcut Description Lamb FactorT FactorC FactorV PiSR CONNECTORGENTYPE
# * Description * Lamb CONNECTORSOCTYPE # * Description * Lamb
PART ROTDEELAPS
# * ID_Part * Label o Type o Case o Lam o Temp o Environment * CreateDate o DeleteDate
* TempOperational * TempMax FUSE o Value TUBEWAVE * Power * Frequency RESISTOR
o Value * MaxPower o VoltageOperational o CurrentOperational * DissipationPower * DPTemp * PassiveTemp o Alternate CAPACITOR * Value * VoltageMax o VoltageDC o VoltageAC * VoltageOperational o SerialResistor o PassiveTemperature
ENVIRONMENT #* * * * * * * * * * * * * * * *
ID_Section title GB GF GM NS NU AIC AIF AUC AUF ARW SF MF ML CL
CONNECTORGEN o PassiveTemp * MatingFactor * Quality * CurrentContact * ContactCnt CONNECTORSOC * Quality * ActivePins
FILTERTYPE # * Description * Lamb
# * ID_Part_SMT o LeadConfig o TCEPackage o Height o Width o TempDissipation * Cnt o Lam * CreateDate o DeleteDate
FILTER * Quality SWITCHES
SWITCHTYPE # * Description * Lamb CONNECTIONTYPE # * Description * Lamb
* ContactCnt o OperatingCurrent * RatedResistiveCurrent * LoadType * Quality CONNECTIONS
Obrázek 4.1: Datový model
27
Kapitola
Návrh webové aplikace 5.1
Výběr technologií
Pro tvorbu webových aplikací existuje spousta možností volby programovacího jazyka. Mezi vhodné programovací jazyky patří například PHP, ASP .NET nebo Java. Pro svoji aplikaci jsem si zvolila PHP hlavně proto, že jsem se s ním již setkala, na rozdíl od ostatních vhodných jazyků. Při výběru PHP frameworku jsem se rozhodovala mezi Symfony2 a Nette. Jelikož jsem ani z jedním frameworkem neměla příliš zkušeností, důležitým aspektem byla dostupná dokumentace. Na první pohled by se zdála velká výhoda české dokumentace v případě Nette, nicméně po obsahové stránce není příliš obsáhlá i kvůli tomu, že komunita kolem Nette není zatím moc rozšířená. Oproti tomu je dokumentace Symfony2 zpracována celkem kvalitně, navíc díky rozšířenosti Symfony2 existuje spoustu dostupných tutoriálů. Dalším důvodem, proč jsem se nakonec rozhodla pro Symfony2 byl i fakt, že je tento framework vyučován ve škole a nabízí se tak možnost případných konzultací. Jako databázový systém jsem si zvolila MySQL, neboť je součástí vývojového prostředí WampServer, který jsem využívala.
5.2
Návrh webdesignu
V dnešní době se na trhu objevuje spousta různých moderních zařízení s velkou škálou rozlišení, proto je kladen čím dál větší důraz na responzivní webdesign. Smysl responzivního designu spočívá v přizpůsobení webové stránky vlastnostem zařízení, na kterém je prohlížena. Základní kameny responzivního designu jsou flexibilní struktura, flexibilní obrázky a tzv. Media Queries. [8] Flexibilní struktura a obrázky zajišťují, že zobrazení stránky reaguje na různé šířky používaných zařízení a dosáhnout se jich dá tak, že místo pevných šířek v pixelech se používají procentuální šířky. Media Queries pak umožňuje měnit pravidla zobrazení na základě vlastností zařízení, např. přeskupit strukturu obsahu webu pro mobily nebo tablety. 29
5
5. Návrh webové aplikace Vzhledem k množství dat, které musí uživatel zadávat, případně analyzovat, předpokládám, že aplikace bude používána primárně jako desktopová, proto jsem ve své práci aplikovala pouze první dvě úrovně. Aplikace tedy není optimalizována pro tablety, mobily a jiná menší zařízení. Protože je aplikace zaměřená především na obsah a její stěžejní částí je funkčnost, tzn. korektní výpočty spolehlivostních parametrů, rozhodla jsem se vytvořit jednoduché grafické rozhraní, které neobsahuje rušivé elementy ani příliš kontrastní barvy. Logo Pro zpestření stránek jsem alespoň vytvořila logo znázorňující bájného Ikara, který drží normu MIL-HDBK-217F a dokresluje tak název a obsah stránek. Logo je navrženo tak, aby se dalo využít i pro další rozšíření projektu Ikaros, které počítá s výpočty i podle dalších norem. Logo se pak bude moci jednoduše přizpůsobit pro tyto další normy pouhým změněním nápisu na obrázku. Pro zpracování loga jsem si zvolila techniku vektorizace obtahem, kdy jsem si logo nejprve navrhla na papír a následně zpracovala pomocí křivek. Logo jsem vytvářela v programu Inkscape, znázorněno je na obrázku 5.1.
Obrázek 5.1: Logo aplikace – Ikaros
5.3
Návrh tříd
Vzhledem k tomu, že norma je velmi rozsáhlá a popisuje mnoho typů součástek a implementace všech by přesahovala rozsah bakalářské práce, byla vybrána reprezentativní množina součástek, které bude aplikace pokrývat. Konkrétně bylo zvoleno 10 součástek: rezistor, kondenzátor, pojistka, propojení, dva typy konektorů, spínač, filtr, měřič motohodin a permaktron. Aplikace je založena na architektuře Model-View-Controller viz 6.1.1, proto popis návrhu tříd rozdělím do tří sekcí dle jednotlivých částí MVC. 30
5.3. Návrh tříd
Obrázek 5.2: Diagram tříd
5.3.1
Návrh tříd – model
Hierarchie modelových tříd z velké části koresponduje s databázovým schématem uvedeným výše. Vyjma číselníků každá databázová entita odpovídá třídě PHP s příslušnými proměnnými dle atributů entity. Třídy navíc obsahují konstruktor a potřebné metody Get a Set pro přístup k proměnným. Diagram tříd je zobrazen na obrázku 5.2. Jelikož hierarchie obsahuje mnoho typů součástek a diagram by byl příliš rozsáhlý, jako příklad je zachycena pouze součástka typu Rezistor. Ostatní součástky jsou implementovány obdobně, tzn. každá další třída popisuje jeden typ součástky a je odvozena od rodičovské třídy Part. Proměnné těchto další tříd odpovídají databázovému schématu. Pro zjednodušení diagramu nejsou vypsány metody Get a Set ani konstruktory. Žádné další metody nejsou v třídách obsaženy.
5.3.2
Návrh šablon – view
Vykreslování stránek zajišťuje šablonovací systém Twig viz 6.1.3. Šablony jsou uspořádány dle controllerů, přičemž všechny šablony jsou odvozeny z nadřazené šablony layout.html.twig, která zajišťuje vykreslování společných částí stránek a načítání externích CSS a jQuery souborů. 31
5. Návrh webové aplikace
5.3.3
Návrh tříd – controller
Aplikace se skládá celkem ze šesti tříd typu Controller, které se starají o aplikační logiku. • DefaultController: Spravuje obsah úvodní stránky a stránky o normě. • LoginController: Spravuje přihlašování uživatele, resp. poskytuje přihlašovací formulář. Validace přihlašovacích údajů je kontrolována na předdefinované routě login_check. • RegisterConroller: Spravuje registraci uživatelů (vytvoření a validace registračního formuláře). • SystemsController: Spravuje všechny operace se systémy, tzn. vytváření systémů, jejich vypisování, editaci a mazání. • PCBController: Spravuje všechny operace s deskami plošných spojů, tzn. přidávání desek, jejich vypisování, editaci, mazání a přidávání a odebírání záznamů pro součástky se SMT vývody. Provádí výpočty spolehlivosti pro desky. • PartsController: Spravuje všechny operace se součástkami, tzn. přidávání součástek, jejich vypisování, editaci a mazání. Provádí výpočty spolehlivosti pro součástky. Smazaní systému, desky nebo součástky je realizováno vyplněním příslušného atributu DeleteDate, nikoli smazáním záznamu z databáze. Je tak z důvodu uchování zpětné vazby pro správce aplikace.
5.4
Porovnání návrhu s rešerší
Při návrhu aplikace jsem se inspirovala na dvou aplikacích uvedených v 3.1.4. Oproti kalkulátoru SQC Online, který pokrývá pouze malé množství součástek, je aplikace navržena tak, aby dokázala pokrýt co možná nejvíc typů součástek. Zároveň navrhovaná aplikace neprovádí pouze jeden samostatný výpočet intenzity poruch jedné součástky, ale distribuuje vypočtené hodnoty do spolehlivosti celého systému. Aplikace Reliability Analytics Toolkit už pokrývá více typů součástek, ale jelikož je založena na jiné metodě počítání spolehlivosti než navrhovaná aplikace, nedá se její uživatelské rozhraní příliš srovnávat ani z něj vycházet, neboť pro účely aplikace Ikaros je třeba zadávat více vstupních dat. Tato aplikace mě ale inspirovala v tom, že umožňuje zadávat více součástek a počítat jejich celkovou spolehlivost. Tuto funkčnosti pokrývá rovněž navrhovaná aplikace. 32
5.5. Případy užití Hlavním rozšířením oproti uvedeným aplikacím je to, že navrhovaná aplikace bude umožňovat dlouhodobější správu systémů a jeho komponent a zároveň bude možné dříve uložená data editovat.
5.5
Případy užití
Případy užití pokrývají akce, které může uživatel v aplikaci vykonat. Jsou zde rozděleny do kategorií dle funkčních požadavků.
Autentizace uživatele UC 1.1 Registrace uživatele Aktér: nepřihlášený uživatel Hlavní scénář: 1. Případ užití začíná ve chvíli, kdy se chce uživatel zaregistrovat. 2. Uživatel klikne na položku Registrovat v menu. 3. Aplikace zobrazí formulář pro registraci uživatele. 4. Uživatel vyplní povinná, případně i další pole formuláře. 5. Aplikace zkontroluje, zda jsou vyplněna povinná pole a zkontroluje formát zadaných dat. Pokud data projdou kontrolou, uživatel je registrován. V opačném případě se zobrazí příslušné chybové hlášky a scénář se vrací do bodu 3. UC 1.2 Přihlášení uživatele Aktér: nepřihlášený uživatel Hlavní scénář: 1. Případ užití začíná ve chvíli, kdy se chce uživatel přihlásit. 2. Uživatel klikne na položku Přihlásit v menu. 3. Aplikace zobrazí formulář pro přihlášení uživatele. 4. Uživatel vyplní povinná, případně i další pole formuláře. 5. Aplikace zkontroluje platnost zadaných dat, pokud data projdou kontrolou, uživatel je přihlášen. V opačném případě se zobrazí příslušné chybové hlášky a scénář se vrací do bodu 3. 33
5. Návrh webové aplikace UC 1.3 Odhlášení uživatele Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná ve chvíli, kdy se chce uživatel odhlásit. 2. Uživatel klikne na položku Odhlásit v menu. 3. Aplikace uživatele odhlásí.
Správa systémů UC 2.1 Vytvoření systému Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, když se uživatel rozhodne vytvořit nový systém. 2. Uživatel vybere položku Přidat systém v menu. 3. Aplikace zobrazí formulář pro vytvoření nového systému. 4. Uživatel vyplní povinná, případně i další pole formuláře. 5. Aplikace zkontroluje, zda jsou vyplněna povinná pole a zkontroluje formát zadaných dat. Pokud data projdou kontrolou, systém je uložen do databáze. V opačném případě se zobrazí příslušné chybové hlášky a scénář se vrací do bodu 3. UC 2.2 Zobrazení uložených systémů přihlášeného uživatele Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, když se uživatel rozhodne zobrazit seznam všech svých uložených systémů. 2. Uživatel vybere položku Moje systémy v menu. 3. Aplikace zobrazí seznam uložených systémů daného uživatele. UC 2.3 Zobrazení všech uložených systémů Aktér: správce aplikace Hlavní scénář: 1. Případ užití začíná, když se uživatel rozhodne zobrazit seznam všech uložených systémů. 34
5.5. Případy užití 2. Uživatel vybere položku Všechny systému v menu. 3. Aplikace zobrazí seznam všech uložených systémů spolu s informací o uživateli, který systému vytvořil. UC 2.4 Zobrazení detailu systému přihlášeného uživatele Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, když se uživatel rozhodne zobrazit detail svého systému. 2. Include (Zobrazení uložených systémů přihlášeného uživatele) 3. Uživatel vybere daný systém kliknutím na příslušný řádek tabulky systémů. 4. Aplikace zobrazí detail systému spolu s uloženými deskami a součástkami, které se vztahují k vybranému systému. UC 2.5 Zobrazení detailu jakéhokoliv systému Aktér: správce aplikace Hlavní scénář: 1. Případ užití začíná, když se uživatel rozhodne zobrazit detail systému. 2. Include (Zobrazení všech uložených systémů) 3. Uživatel vybere daný systém kliknutím na příslušný řádek tabulky systémů. 4. Aplikace zobrazí detail systému spolu s uloženými deskami a součástkami, které se vztahují k vybranému systému. UC 2.6 Editace systému Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná ve chvíli, kdy se uživatel rozhodne editovat systém. 2. Include(Zobrazení uložených systémů přihlášeného uživatele) 3. Uživatel klikne na tlačítko Upravit u příslušného řádku tabulky systémů. 4. Aplikace zobrazí informace o vybraném systému. 5. Uživatel klikne na tlačítko Upravit. 35
5. Návrh webové aplikace 6. Aplikace vytvoří formulář pro editaci systému. 7. Uživatel vyplní povinná, případně i další pole formuláře. 8. Uživatel klikne na tlačítko Uložit. 9. Aplikace zkontroluje, zda jsou vyplněna povinná pole a zkontroluje formát zadaných dat. Pokud data projdou kontrolou, změny jsou uloženy do databáze. V opačném případě se zobrazí příslušné chybové hlášky a scénář se vrací do bodu 5. Alternativní scénář 1: 1. Include (Zobrazení detailu systému daného uživatele) 2. Uživatel klikne na tlačítko Upravit u tabulky obsahující informace o vybraném systému. 3. Dále pokračuje alternativní scénář od bodu 6 hlavního scénáře. Alternativní scénář 2: 1. Alternativní scénář 2 začíná v bodě 8 hlavního scénáře. 2. Uživatel klikne na tlačítko Zrušit. 3. Aplikace ukončí možnost editovaní a zobrazí původní informace o systému. UC 2.7 Smazání systému Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, jestliže se uživatel rozhodne smazat systém. 2. Include(Zobrazení uložených systémů přihlášeného uživatele) 3. Uživatel klikne na tlačítko Smazat u příslušného řádku tabulky systémů.
Správa desek UC 3.1 Vytvoření desky Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná ve chvíli, kdy se uživatel rozhodne vytvořit desku. 2. Uživatel klikne na položku Přidat desku v menu. 36
5.5. Případy užití 3. Aplikace zobrazí formulář pro vytvoření desky spolu s výběrem systému, ke kterému se vytvořená deska přidá. 4. Uživatel vyplní povinná, případně volitelná pole formuláře. 5. Aplikace zkontroluje, zda jsou vyplněna povinná pole a zkontroluje formát zadaných dat. Pokud data projdou kontrolou, deska je uložena do databáze. V opačném případě se zobrazí příslušné chybové hlášky a scénář se vrací do bodu 3. Alternativní scénář 1: 1. Include (Zobrazení uložených systémů přihlášeného uživatele) 2. Uživatel klikne na tlačítko Přidat desku u příslušného řádku tabulky. 3. Aplikace zobrazí formulář pro vytvoření desky. 4. Dále pokračuje alternativní scénář od bodu 3 hlavního scénáře. Alternativní scénář 2: 1. Include (Zobrazení detailu systému přihlášeného uživatele) 2. Uživatel klikne na tlačítko Přidat desku u tabulky obsahující informace o vybraném systému. 3. Scénář dále pokračuje od bodu 3 alternativního scénáře 1. UC 3.2 Zobrazení detailu desky Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, když se uživatel rozhodne zobrazit detail desky. 2. Include (Zobrazení detailu systému přihlášeného uživatele) 3. Uživatel vybere desku kliknutím na příslušný řádek tabulky. 4. Aplikace zobrazí obecné informace o desce, informace o součástkách s drátovými vývody a formulář pro přidání záznamu pro součástky se SMT vývody, případně seznam uložených záznamů pro součástky se SMT vývody. 37
5. Návrh webové aplikace UC 3.3 Editace desky Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, když se uživatel rozhodne upravit desku (týká se jak obecných informací o desce, tak informací o součástkách s drátovými vývody). 2. Include (Zobrazení detailu desky) 3. Uživatel klikne na tlačítko Upravit. 4. Aplikace zobrazí formulář pro editaci desky. 5. Uživatel vyplní povinná, případně volitelná pole formuláře. 6. Uživatel klikne na tlačítko Uložit. 7. Aplikace zkontroluje, zda jsou vyplněna povinná pole a zkontroluje formát zadaných dat. Pokud data projdou kontrolou, změny jsou uloženy do databáze. V opačném případě se zobrazí příslušné chybové hlášky a scénář se vrací do bodu 4. Alternativní scénář: 1. Alternativní scénář začíná v bodě 6 hlavního scénáře. 2. Uživatel klikne na tlačítko Zrušit. 3. Aplikace ukončí možnost editovaní a zobrazí původní informace o desce. UC 3.4 Přidání záznamu pro součástky se SMT vývody k desce Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, jestliže se uživatel rozhodne vytvořit nový záznam pro součástky se SMT vývody. 2. Include (Zobrazení detailu desky) 3. Uživatel vyplní formulář Přidat součástky se SMT vývody. 4. Aplikace zkontroluje, zda jsou vyplněna povinná pole a zkontroluje formát zadaných dat. Pokud data projdou kontrolou, změny jsou uloženy do databáze. V opačném případě se zobrazí příslušné chybové hlášky a scénář se vrací do bodu 3. 38
5.5. Případy užití UC 3.5 Odebrání záznamu pro součástky se SMT vývody u desky Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, jestliže se uživatel rozhodne odebrat uložený záznam pro součástky se SMT vývody. 2. Include (Zobrazení detailu desky) 3. Uživatel klikne na tlačítko Smazat u příslušného řádku tabulky Uložené součástky se SMT vývody. UC 3.6 Smazání desky Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, když se uživatel rozhodne smazat desku. 2. Include (Zobrazení detailu systému přihlášeného uživatele) 3. Uživatel klikne na tlačítko Smazat u příslušného řádku tabulky desek.
Správa součástek UC 4.1 Vytvoření součástky Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná ve chvíli, kdy chce uživatel vytvořit novou součástku. 2. Include (Zobrazení detailu systému přihlášeného uživatele) 3. Uživatel klikne na tlačítko Přidat součástku u desky, ke které chce přiřadit novou součástku. 4. Aplikace zobrazí záložky se všemi typy součástek, které lze přidat. 5. Uživatel vybere záložku podle toho, kterou součástku chce přidat. 6. Aplikace zobrazí formulář při přidání vybraného typu součástky, případně seznam již uložených součástek stejného typu vztahujících se k vybrané desce. 7. Uživatel vyplní povinná, případně volitelná pole formuláře. 39
5. Návrh webové aplikace 8. Aplikace zkontroluje, zda jsou vyplněna povinná pole a zkontroluje formát zadaných dat. Pokud data projdou kontrolou, součástka je uložena do databáze. V opačném případě se zobrazí příslušné chybové hlášky a scénář se vrací do bodu 6. 9. Aplikace zobrazí informace o vytvořené součástce pod formulářem. Scénář se může dále opakovat od bodu 4. UC 4.2 Zobrazení detailu součástky Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, když se uživatel rozhodne zobrazit detail součástky. 2. Include (Zobrazení detailu systému přihlášeného uživatele) 3. Uživatel vybere součástku kliknutím na příslušný řádek tabulky součástek. 4. Aplikace zobrazí informace o součástce. Alternativní scénář: 1. Alternativní scénář nastává ve chvíli, kdy chce uživatel zobrazit detail součástky ihned po jejím vytvoření. 2. Include (Vytvoření součástky) 3. Uživatel se nachází v bodě 9 Vytvoření součástky. 4. Uživatel vybere součástku kliknutím na příslušný řádek tabulky pod formulářem. UC 4.3 Editace součástky Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, když se uživatel rozhodne editovat uloženou součástku. 2. Include (Zobrazení detailu systému přihlášeného uživatele) 3. Uživatel klikne na tlačítko Upravit u příslušného řádku tabulky součástek nebo přímo na tento řádek. 4. Aplikace zobrazí informace o součástce. 5. Uživatel klikne na tlačítko Upravit. 40
5.5. Případy užití 6. Aplikace zobrazí formulář pro editaci součástky. 7. Uživatel vyplní povinná, případně volitelná pole formuláře. 8. Aplikace zkontroluje, zda jsou vyplněna povinná pole a zkontroluje formát zadaných dat. Pokud data projdou kontrolou, změny jsou uloženy do databáze. V opačném případě se zobrazí příslušné chybové hlášky a scénář se vrací do bodu 6. Alternativní scénář: 1. Alternativní scénář začíná v bodě 6 hlavního scénáře. 2. Uživatel klikne na tlačítko Zrušit. 3. Aplikace ukončí možnost editovaní a zobrazí původní informace o součástce. UC 4.4 Smazání součástky Aktér: přihlášený uživatel Hlavní scénář: 1. Případ užití začíná, když se uživatel rozhodne smazat součástku. 2. Include (Zobrazení detailu systému přihlášeného uživatele) 3. Uživatel klikne na tlačítko Smazat u příslušného řádku tabulky součástek.
41
Kapitola
Realizace 6.1 6.1.1
Použité technologie Symfony2
Zakladatelem projektu Symfony se stal Fabien Potencier působící ve společnosti Sensio, pro jejíž projekty byl framework primárně určen. První verze Symfony byla vydána v roce 2005 a po úspěšném použití v mnoha projektech byla poskytnuta jako open source licence. Díky kvalitě kódu, ale také rozsáhlé dokumentaci se komunita kolem Symfony brzy rozrostla o vývojáře z celého světa.[1] Frameworky jsou zpravidla navrhovány proto, aby zefektivnily vývoj aplikací použitím vhodných návrhových vzorů, dávají kódu strukturu a usnadňují programování, neboť rozdělují komplexní operace do jednoduchých příkazů. Framework Symfony obsahuje mnoho nástrojů a tříd určených k optimalizaci vývoje komplexních webových aplikací. Symfony je napsáno v PHP 5 a je určeno pro vytváření webových aplikací v tomtéž jazyce. Je kompatibilní s většinou používaných databázových systémů jako MySQL, PostgreSQL nebo Oracle. Pro implementaci bakalářské práce jsem využila aktuální verzi Symfony2. Architektura MVC Jádro Symfony je založené na návrhovém vzoru Model-View-Controler (MVC) MVC dělí aplikaci na tři logické celky, které lze upravovat samostatně tak, aby dopad na ostatní celky byl co nejmenší. Odděluje tak business logiku, serverovou logiku a prezentační pohledy. Tyto tři celky jsou rozvrženy následovně: • Model: reprezentuje data a business logiku aplikace • View: stará se o zobrazení uživatelského rozhraní 43
6
6. Realizace • Controller: zpracovává aplikační logiku (reaguje na události a obstarává změny v modelu nebo pohledu Schéma MVC architektury je znázorněno na obrázku 6.1.
Obrázek 6.1: Architektura MVC převzato z [13]
6.1.2
Doctrine
Doctrine tvoří jednu ze základních komponent Symfony2, která ulehčuje spolupráci s databází. Pro spolupráci mezi objektově orientovaným PHP a relační databází je nezbytné rozhraní překládající objektovou logiku na logiku relační. Toto rozhraní se nazývá objektově relační mapování (ORM) a je základem právě Doctrine. ORM je založené na oddělení objektů umožňujících přístup k datům a business logiky, kterou si drží v sobě. To znamená, že Symfony2 je nezávislé na použité databázi, neboť automaticky překládá volání modelových objektů do SQL dotazů optimalizovaných dle syntaxe konkrétní databáze. Doctrine je založena na návrhovém vzoru Data Mapper. Tento vzor odděluje samotný objekt a databázové operace a zajišťuje tak nezávislost aplikace na databázi. V případě Doctrine se o tyto operace stará třída EntityManager. K definici databázových entit a jednotlivých atributů se využívají především komentářové anotace. Kromě anotací lze v Symfony2 použít také mapování pomocí XML nebo YAML.
6.1.3
Twig
Pro vykreslení uživatelského rozhraní využívá Symfony2 šablonovací systém Twig. Mezi jeho výhody patří např. dědičnost šablon, která umožňuje nadefi44
6.2. Použité nástroje novat statické vlastnosti společné pro všechny stránky webové aplikace a pro každou stránku dále editovat jen vymezené lišící se úseky. Této funkcionality jsem rovněž využila ve své aplikaci.
6.1.4
jQuery
V současné době jsou internetové technologie stále vyspělejší a je téměř nevyhnutelné vytvářet stránky dynamické a především interaktivní. A právě tyto aspekty si klade za cíl knihovna jQuery. jQuery je knihovna založená na programovacím jazyce Javascript, která pracuje nad modelem DOM. DOM neboli objektový model dokumentu je rozhraní, díky kterému je možné přistupovat k jednotlivým objektům v dokumentu a dále je přidávat, editovat nebo mazat. DOM používají i značkovací jazyky jako HTML pro reprezentaci elementů stránky. Síla jQuery spočívá právě ve výběru těchto elementů v rámci DOM a v jejich dalším zpracování bez nutnosti znovunačítání stránek. Stejně dobře podporuje jQuery kaskádové styly, které umí také lehce zpracovávat. Knihovna jQuery nabízí širokou škálu efektů a animací bez použití technologie Flash. I díky tomu se stránky rychleji načítají a jsou přístupnější pro internetové vyhledávače. Velkou výhodou je také jednotné aplikační rozhraní, které zajišťuje kompatibilitu mezi různými webovými prohlížeči. Toho jQuery dosahuje pomocí přidané abstraktní vrstvy, která normalizuje zdrojové kód pro daný prohlížeč. Při implementaci bakalářské práce jsem se inspirovala především v [6] a [9].
6.2 6.2.1
Použité nástroje WampServer
WampServer je vývojové prostředí učené speciálně pro Windows, které umožňuje vytvářet webové aplikace za pomoci webového serveru Apache2, programovacího jazyka PHP a databázového systému MySQL. Navíc obsahuje také doplněk phpMyAdmin pro snadnou správu MySQL databází. Aplikace Ikaros byla vyvíjena konkrétně na verzi WampServer 2.4, obsahující PHP 5.4.16 a MySQL 5.6.12.
6.2.2
PhpStorm
PhpStorm je komerční vývojové prostředí pro jazyk PHP, které poskytuje inteligentní editor nejen pro PHP, ale také pro HTML, CSS nebo Javascript. Hlavním důvodem, proč jsem používala právě PhpStorm je, že podporuje framework Symfony2, především jeho konsoli (app/console) a umožňuje tak vykonávat příkazy přímo z editoru. 45
6. Realizace
6.2.3
Firebug
Firebug je rozšíření prohlížeče Mozilla Firefox, které slouží k ladění webových stránek. Základními funkcemi jsou například kontrola a úprava HTML a CSS, sledování dotazů vyvolaných na stránce nebo stromové procházení DOM. Důležitým doplňkem pro mě byl především ladící nástroj pro Javascript, který umožňuje sledovat hodnoty proměnných nebo odesílané a přijímané požadavky ze serveru.
6.2.4
Inkscape
Inkscape je open-sourcový nástroj na tvorbu vektorové grafiky. Jedná se o multiplatformní grafický editor, který používá jako svůj nativní formát SVG. V bakalářské práci byl využit k vytvoření loga aplikace.
6.2.5
SQL Developer Data Modeler
SQL Developer Data Modeler já nástroj společnosti Oracle určený k modelování dat. Podporuje spoustu datových modelů jako např. logický (ER diagram), který je založen na entitách, jejich atributech a vztazích mezi entitami, nebo relační, který popisuje databázové schéma tabulek, jejich sloupců a omezení. Data Modeler také umožňuje převádět mezi logickým a relačním modelem a z výsledného relačního modelu generovat DDL skript.
6.2.6
Enterprise Architect
Enterprise Architect je komplexní nástroj pro tvorbu diagramů za použití notace UML. Poskytuje rozhraní pro modelování business procesů, doménových modelů, diagramů tříd, diagramů nasazení a spoustu dalších modelů potřebných během analýzy a vývoje softwarových systémů.
6.3 6.3.1
Implementační poznámky Mapování dědičnosti v Symfony2
Ve svém databázovém návrhu jsem jednotlivé součástky zformovala do podoby ISA hierarchie. V objektovém programování tato situace odpovídá dědičnosti tříd, přičemž v Doctrine je možných několik způsobů mapování dědičnosti. [2] 1. Mapped Superclass Tento způsob je založen na abstraktní rodičovské třídě, která sama o sobě není entitou, ale pouze poskytuje perzistentní stav entity a mapovací informace pro její podtřídy. Jelikož Mapped Superclass není entitou, není možné se nad ní ani dotazovat. Vztahy definované pomocí Mapped Superclass musí být pouze jednosměrné, a proto také nelze vytvářet asociace 1:N. 46
6.3. Implementační poznámky 2. Single Table Inheritance Tato mapovací technika vytváří pouze jednu databázovou tabulku, do které mapuje všechny třídy dané hierarchie. Výsledná tabulka pak obsahuje všechny možné atributy vyskytující se ve třídách. Aby se alespoň odlišilo, k jaké třídě patří příslušný řádek databáze, přidává se navíc tzv. DicriminatorColumn, neboli rozlišovací sloupec, který uchovává informaci o příslušnosti ke třídě. Přidání nové třídy pak spočívá v přidání nového sloupce do databáze, což může mít negativní dopad na strukturu existující databáze. Výhoda této techniky však spočívá v efektivitě, a tudíž i rychlosti dotazování, neboť na nalezení záznamů pro konkrétní třídu si programátor vystačí s klauzulí WHERE a rozlišovacím sloupcem a není potřeba vytvářet JOIN mezi tabulkami. Nevýhodou naopak může být velké množství sloupců tabulky, což vede k vysoké paměťové náročnosti. 3. Class Table Inharitance V této mapovací strategii jsou třídy naopak mapovány do různých databázových tabulek. Tabulka podtřídy je pak svázána k rodičovské třídě pomocí cizího klíče. V Doctrine je tato strategie implementována opět použitím rozlišovacího sloupce, který nabízí nejsnadnější cestu pro řešení polymorfních dotazů. Přidání nové třídy v případě Class Table Inheritance zahrnuje vložení nové tabulky do databáze a neovlivňuje tak žádné jiné tabulky. Stejně tak modifikace jakéhokoli atributu ovlivňuje vždy jen jednu tabulku, příslušnou dané třídě. Toto mapování poskytuje velkou flexibilitu během návrhu hierarchie. Nevýhodou zůstává pomalejší dotazování, neboť je nutné používat JOIN pro přístup ke všem atributům. Ve své práci jsem se rozhodla využít třetího přístupu, Class Table Inheritance. Příklad: /** * @ORM\Entity * @ORM\InheritanceType("JOINED") * @ORM\DiscriminatorColumn(name="entity_type", type="string") */ class Part { /** * @ORM\Id * @ORM\Column(type="integer", unique=true) * @ORM\GeneratedValue(strategy="AUTO") */ 47
6. Realizace protected $Id_Part; /** * @ORM\Column(length=64) */ protected $Label; // metody } /** * @ORM\Entity */ class Resistor extends Part{ /** * @ORM\Column(type="integer") */ protected $Value; /** * @var integer $Id_Part */ protected $Id_Part; /** * @var string $Label */ protected $Label; // metody }
6.3.2
Dotazování v Symfony2
V Symfony2 existuje spoustu možností vytváření a spouštění databázových dotazů. Pro názornost jsem vybrala ty nejpoužívanější. Metody pro Entity Manager Nejjednodušší způsob pro získávání entit jsou přímo vyhledávací metody Entity Manageru. Jsou však naprosto nedostačující pro složitější dotazování. Příklad: Nalezení jednoho systému s daným ID $em = 48
$this->getDoctrine()->getManager();
6.3. Implementační poznámky $RU = $em->getRepository(’BakalarkaIkarosBundle:System’); $system = $RU->findOneBy(array(’ID_System’ => $id)); DQL Doctrine zavádí jazyk DQL (Doctrine Query Language), který je velmi podobný jazyku SQL. Hlavní rozdíl spočívá v tom, že DQL nepracuje přímo s databázovými tabulkami, ale s definovanými entitami a jejich členskými proměnnými. Výhodou použití jazyka DQL je např. to, že pomocí ORM mapování dokáže automaticky rozeznat, které sloupce v databázi se mají použít pro spojení tabulek. Příklad: Nalezení aktivních systémů uživatele s daným ID $query = $em->createQuery(’SELECT s FROM BakalarkaIkarosBundle:System s WHERE s.UserID = :id AND s.DeleteDate IS NULL’); $query->setParameters(array(’id’ => $user->getIDUser())); $systems = $query->getResult(); Query Builder Query Builder je třída, která poskytuje dynamické tvořené dotazu pomocí jejích metod. Výsledkem je totéž co v podání DQL. Příklad: Nalezení systému s daným ID $q = $em->createQueryBuilder() ->select(’s’) ->from(’System’, ’s’) ->where(’s.id = ?1’) ->getQuery(); Raw SQL Ne vždy je potřeba pracovat s celým konkrétním objektem, proto Symfony umožňuje provádět klasické SQL příkazy. Hodí se např. pro složitější dotazy s agregačními funkcemi. Nevýhodou je, že výsledkem je pole hodnot, o kterém Doctrine neví nic, tedy ani nedokáže přiřadit hodnoty k žádnému objektu. Příklad: Nalezení aktivních součástek v systému s daným ID $em = $this->getDoctrine()->getManager() ->getConnection() ->prepare(’SELECT p.* FROM Part p JOIN PCB pcb ON (p.PCB_ID = pcb.ID_PCB) 49
6. Realizace WHERE pcb.SystemID = :sysID AND p.DeleteDate IS NULL AND pcb.DeleteDate IS NULL’); $em->execute(array(’:sysID’ => $id)); $parts = $em->fetchAll();
Native SQL Nativní SQL je obdobou předchozího způsobu, kdy se dotazuje pomocí klasického SQL, poskytuje však navíc možnost mapování hodnot na zvolenou entitu. Příklad: Nalezení systému s daným ID $rsm = new DoctrineORMQueryResultSetMapping; $rsm->addEntityResult(’System’, ’s’); $rsm->addFieldResult(’s’, ’id’, ’id’); $rsm->addFieldResult(’s’, ’title’, ’title’); $q = $em->createNativeQuery(’ SELECT id, title, FROM System WHERE id = ?’, $rsm); $q->setParameter(1, 1); $system = $q->getResult();
Ve své aplikaci jsem využívala jak jednoduché metody Entity Manageru, tak i DQL a Raw SQL. Při hledání konkrétních objektů jsem používala Entity Manager, především z důvodu jednoduchosti zápisu. Naopak na složitější dotazy jsem použila kombinaci DQL a SQL. V případech, kdy jsem nepotřebovala vracet přímo objekt, jsem se uchylovala spíše SQL, protože je pro mě pochopitelnější a snáze se mi tvořily dotazy.
6.3.3
Grafické rozhraní formulářů
V aplikaci Ikaros jde v první řadě o zadávání a zobrazování dat vložených uživatelem, proto je velmi důležité grafické rozhraní formulářů. Původní návrh formulářového rozhraní byl založen na horizontálním uspořádání polí po vzoru excelovských tabulek, kde by mohl uživatel zadávat více součástek najednou do jednotlivých řádků a měl tak přehled o zapisovaných hodnotách. Tento návrh se ale neosvědčil, neboť součástky obsahují příliš parametrů, které musí uživatel zadat a vyvstal tak problém, jak zobrazovat širokou tabulku. Jediným řešením tohoto problému by bylo vytvoření horizontálního posuvníku stránky, což by nepůsobilo příliš efektně, navíc by se zbytečně zkomplikovalo zadávání dat. 50
6.3. Implementační poznámky
Obrázek 6.2: Formulář pro přidání součástky
Proto jsem se rozhodla vytvořit klasický formulář a zároveň pod formulářem zobrazovat všechny již uložené součástky stejného typu přiřazené k vybrané desce. Nově vytvořená součástka se tak pomocí jQuery pouze připojí do tabulky uložených součástek a uživatel může zadávat ihned další součástku a sledovat, jaké součástky má již uložené. Další otázkou při návrhu formulářů pro součástky bylo, jak umožnit efektivní zadávání různých typů součástek bez zbytečného procházení aplikace, když každý typ součástky vyžaduje jiný formulář. Tento problém jsem vyřešila vytvořením záložek implementovaných pomocí jQuery, kde každá záložka poskytuje formulář pro příslušnou součástku. Návrh formuláře pro součástky je zobrazen na obrázku 6.2.
6.3.4
Autentizace
Autentizace uživatelů probíhá oproti databázi MySQL, v níž jsou uložená uživatelská jména a hesla zašifrovaná pomocí MD5. K šifrovanému heslu se ukládá také sůl generovaná aplikací.
6.3.5
Validace formulářů
Při vyplňování formulářů je velmi důležitá jejich validace a v případě zadání neplatných údajů také oznámení chyb uživateli. V aplikaci jsem využila několik metod validace, které popíši v následujících odstavcích. Pro přihlašování uživatelů jsem použila předdefinovanou routu login_check, která obstarává validaci právě přihlašovacích formulářů a usnadňuje tak práci vývojáři. 51
6. Realizace Na další formuláře, především pro přidávání nových objektů, jsem aplikovala zásuvný model validate pro jQuery. [15] Zásuvný model validate umožňuje definovat pravidla pro jednotlivá pole formuláře, nastavit umístění a obsah vypisovaných oznámení i přiřadit akci, která se má vykonat po stisknutí tlačítka pro odeslání. Pomocí ajaxového požadavku se pak mohou poslat data na server, kde jsou zpracována, např. uložena do databáze, aniž by uživatel musel čekat na obnovení stránky. Jelikož tato technika vyžaduje, aby měl uživatel v prohlížeči povoleno spouštění javascriptu, je žádoucí implementovat také validaci na straně serveru. K tomu v Symfony2 slouží např. metoda createFormBuilder($object), která rovněž umožňuje definování validačních pravidel přímo při vytváření formuláře a zároveň mapuje formulářová pole přímo k příslušným proměnným objektu, ke kterému se formulář vztahuje.
6.3.6
Výpočty spolehlivosti
Hlavní funkčností aplikace jsou výpočty intenzity poruch systémů a jejich součástí. Jak bylo uvedeno v 2.2.3, norma je vytvořena podle sériového spolehlivostního modelu, kde se jednotlivé intenzity poruch prvků sčítají. Na obrázku 6.3 je znázorněno blokové schéma postupného výpočtu celkové intenzity poruch pro systém. Z důvodu přehlednosti je schéma zjednodušeně zobrazeno ve stromu, kde se rozvětvuje vždy levý potomek. Význam jednotlivých bloků je následující: λSystem : intenzita poruch celého systému λP CB : intenzita poruch desky, zahrnuje navíc součet intenzit poruch všech součástek vztahujících se k dané desce λX : intenzita poruch součástky
λSystém λPCB1 λR1
λC1
λPCB2
λPCBn λX
Obrázek 6.3: Schéma výpočtu intenzity poruch systému 52
6.4. Nasazení Výpočet intenzity poruch tedy prochází metodou zdola-nahoru (BottomUp). V kořeni stromu se nachází intenzita poruch celého systému. Systém lze dále členit na desky plošných spojů, ze kterých se de facto skládá. Desky jsou zachyceny na první úrovni směrem od kořene. Pro existenci systému se předpokládá 1 až N desek plošného spoje. Každá deska plošného spoje může obsahovat definované typy konkrétních součástek, což je znázorněno ve druhé úrovni směrem od kořene. Součástky v listech přesně odpovídají elektrickému schématu. Pro každou součástku je nutné vypočítat intenzitu poruch, která se bude propagovat směrem ke kořeni. V případě přidání součástky se nová hodnota musí přičíst jak k intenzitě poruch desky, tak k intenzitě poruch celého systému. Analogicky se hodnota odečítá v případě odebrání součástky.
6.4
Nasazení
Aplikace vyžaduje webový server (Apache2), PHP a databázi MySQL. Diagram nasazení je znázorněn na obrázku 6.4.
Obrázek 6.4: Model nasazení Před samotným nasazením aplikace je třeba připravit databázi následujícím způsobem. 1. Vytvořit databázi 2. Nastavit parametry databáze v konfiguračním souboru app/config/parameters.yml
53
6. Realizace parameters: database_driver: database_host: database_port: database_name: database_user: database_password:
pdo_mysql localhost ~ IkarosDB user heslo
3. Vytvořit tabulky pomocí přiložených skriptů. Tabulky odpovídající PHP třídám lze vygenerovat pomocí příkazu app/console doctrine:schema:update –force nebo pomocí skriptu createEntities.sql. Tabulky pro číselníky je nutné vygenerovat skriptem createDials.sql. Do databáze je možné také nahrát testovací data pomocí přiloženého skriptu insertData.sql.
54
Kapitola
Testování Před samotným nasazením je nutné vytvořenou aplikaci otestovat, aby se odhalily případné chyby a nedostatky. U aplikace Ikaros bylo testováno jak správné zobrazování a funkčnost stránek v různých prohlížečích, tak i použitelnost aplikace.
7.1
Testování v různých prohlížečích
Jelikož existuje mnoho webových prohlížečů, z nichž každý se může v určitých situacích chovat trochu jinak, je nutné otestovat aplikaci v různých prohlížečích. Odlišnosti v chování webových prohlížečů se můžou týkat např. vykreslování stránek nebo chování javascriptu. Problémy s javascriptovými funkcemi řeší knihovna jQuery, která pomocí vlastní abstraktní vrstvy zajišťuje kompatibilitu. Aplikace Ikaros byla během vývoje průběžně testována v prohlížečích Google Chrome 34.0 a Mozilla Firefox 28.0. Následně byla otestována i na prohlížečích Internet Explorer 11.0 a Opera 20.0.
7.2
Testování funkčnosti
Testování funkčnosti aplikace spočívá v ověření správnosti výpočtů intenzity poruch pro součástky a desky a promítnutí vypočtených hodnot směrem k systému. Aplikaci jsem testovala průběžně během vývoje, na závěr byl proveden test s experimentální daty od vedoucího práce. Objevené chyby a nedostatky byly okamžitě opraveny a výsledná aplikace je tak plně funkční. Testování funkčnosti by se dalo rozdělit do několika kategorií.
7.2.1
Testování nesprávných dat
Abych zamezila možnosti vložení nesprávných vstupů do formulářů, vždy jsem omezila možnosti vložení na určitý typ dat. Například pokud se jedná o číslo, 55
7
7. Testování nelze vložit text. Stejně tak jsem omezila i číselný interval pokud to norma vyžadovala, například je možné vložit pouze číslo z rozmezí 1 až 18 pro počet vrstev desky plošného spoje atd. Těmito opatřeními jsem podstatně minimalizovala možnost nechtěného vložení nesprávných dat. Aplikaci jsem testovala záměrným vkládáním takovýchto nesprávných dat, abych odhalila případné nedostatky ošetření. Všechny takové nalezené nedostatky jsem ihned opravila.
7.2.2
Testování náhodných dat
Vedle nesprávných dat bylo nutné otestovat aplikaci také na správné vstupy náhodných hodnot a zkontrolovat vypočtené hodnoty intenzity poruch. Protože číselníky jsou z normy přepisovány ručně do databáze a mnohdy jsou méně čitelné, mohla nastat chyba v přepisu a digitalizaci dat. Správnost dat jsem ověřovala tak, že jsem si vždy náhodně vymyslela nějaký systém a jeho součástky. Ten jsem uložila do své aplikace a výsledek poté porovnávala s aplikací SQC Online uvedenou v 3.1.2. Pro jistotu jsem pro jednou zvolený systém měnila výchozí prostředí a teplotu či výkon, abych si ověřila i správnost aproximačních vzorců.
7.2.3
Testování experimentálních dat
Od vedoucího práce jsem dostala k dispozici parametry dvou systémů, pomocí kterých jsem ověřila správnou funkčnost vytvořené aplikace, především správnost výpočtu. Oba systémy mají vypočteny intenzity poruch pro každou součástku a to i pro několik provozních situací. V testu se teplota systémů mění, stejně tak typy prostředí a nakonec i zátěž na některých součástkách. Pro jeden systém je tak definováno 20 testů. Systémy byly následující: Systém 1 První systém se skládá z 1 desky plošného spoje a 18 součástek, které byly do systému vloženy a naměřené hodnoty byly porovnány s předpřipravenými výsledky. Test byl sestaven pro tyto součástky: 1 6 8 1 2 1 56
deska plošného spoje rezistorů kondenzátorů pojistka konektory spínač
7.3. Testování použitelnosti Systém 2 Druhý systém se skládá z 1 desky plošného spoje a 37 součástek, které byly opět vloženy do systému a otestovány. Test byl sestaven pro tyto součástky: 1 deska plošného spoje 16 rezistorů 18 kondenzátorů 2 konektory 1 pojistka Oba systémy jsem podrobila zátěžovému testu, kdy jsem postupně přidávala teplotu a měnila různé kombinace hodnot prostředí a zatížení jednotlivých součástek podle dodaných parametrů vedoucím. V zásadě lze říct, že jsem prošla většinu možností nastavení parametrů v jednotlivých formulářích, abych mohla tyto kroky uskutečnit. Výsledky aplikace se shodovaly s dodanými daty. Testovací data i systémy vložené do databáze včetně výsledků jsou k dispozici na přiloženém CD.
7.3
Testování použitelnosti
Testování použitelnosti si klade za cíl prozkoumat navržené uživatelské rozhraní, především jeho intuitivnost a uživatelskou přívětivost. Cíle testování byly stanoveny dle případů užití uvedených v 5.5, jelikož jich je poměrně hodně, nebudu je zde znovu vypisovat. Testování provedl vedoucí práce, kterému bude práce primárně sloužit. Během testování nebyly odhaleny žádné výrazné problémy. Drobné nejasnosti vznikly u editace desky, kdy jsem zapomněla znepřístupnit vstupní formulář při načtení stránky a bylo tak možné vyplňovat formulář ještě před zpřístupněním funkce editace. Tento nedostatek byl záhy opraven a výsledná aplikace už funguje v pořádku.
57
Kapitola
Výhled do budoucna Ikaros je plánován jako rozsáhlý projekt pro prediktivní analýzu spolehlivosti, který dalece přesahuje rozsah bakalářské práce a vytvořená aplikace tak implementuje plnou funkčnost pouze pro vybranou podmnožinu součástek a konkrétní normu MIL-HDBK-217F dle zadání práce. Do budoucna se však nabízí spoustu vylepšení, které bych chtěla implementovat.
Rozšíření pro všechny součástky Současná aplikace pokrývá pouze 10 typů součástek. Zásadním rozšířením, které je třeba implementovat před plným nasazením aplikace na veřejný server, je doplnění funkčnosti pro všechny typy součástek.
Výpočet pro anonymního uživatele Vytvořená webová aplikace funguje tak, že se uživatel nejprve musí registrovat a až poté může vytvářet systémy a další komponenty, z nichž aplikace vypočítá intenzity poruch. Anonymní uživatel v tomto schématu nemá žádnou možnost nechat si vypočítat intenzitu poruch pro svůj systém, aniž by se přihlásil. Aplikace je tak výhodná především pro správu více systémů, které si uživatel chce evidovat a případně editovat. V případě, že si bude chtít uživatel jednorázově spočítat spolehlivost jednoto systému nebo jedné komponenty, je zbytečné, aby se kvůli tomu musel registrovat. Dalším navrhovaným rozšířením je tedy implementace rozhraní pro anonymního uživatele, které by poskytovalo výpočet spolehlivosti bez nutnosti přihlášení. Anonymní uživatel by zároveň mohl mít možnost poskytnout zadaná data aplikaci pro účely dalšího zkoumání a statistik.
Evidování výrobců/prodejců Třetím navrhovaným rozšířením je evidence výrobců a prodejců komponent. Návrh relační databáze s touto funkčností již počítá (obsahuje potřebné ta59
8
8. Výhled do budoucna bulky), nicméně aplikace je v současném stavu neimplementuje. Evidování výrobců a prodejců by mělo být informativního charakteru a sloužit by mělo např. k identifikaci vadných sérií výrobků.
Historie a statistiky výpočtů Výpis systému je momentálně realizován tak, že běžný uživatel vidí všechny svoje aktivní systémy, tj. systémy, které nesmazal. Pokud se rozhodne editovat parametry již uloženého systému nebo jeho komponenty, staré hodnoty se v databázi přepíšou. V případě smazání systému nebo komponenty nejsou tyto záznamy pro běžného uživatele dále dostupné. Smazané systémy jsou dále viditelné pouze pro správce aplikace. Pro detailnější analýzy komponent by bylo dobré udržovat historii změn jak pro správce, tak pro samotného uživatele. Uživatel by tak mohl sledovat, které součástky kdy vyměnil nebo odebral a na základě těchto informací se např. rozhodovat, které součástky byly kvalitní či nikoliv. Současný návrh aplikace obsahuje u jednotlivých entit parametry CreateDate a DeleteDate pro sledování dat vytvoření a smazání. Toho by se dalo využít i pro rozšíření o historii. Historie by mohla být realizována např. vytvořením nového záznamu editované entity s odkazem na původní záznam. Pořadí změn v historii by se pak dalo určit jednoduše dle atributu CreateDate. Pro ještě detailnější analýzy komponent by aplikace mohla provádět také statistiky výpočtů a změn v systémech na základě této historie.
Export do souboru Dalším navrhovaným rozšířením, které by mohlo být pro uživatele užitečné, je export uložených dat do souboru, případně tvorba tiskových sestav. Export by měl poskytovat filtrování dat na základně kritérií zadaných uživatelem.
Rozšíření pro další normy Zadání práce stanovuje, že výpočty aplikace mají vycházet z normy MILHDBK-217F. Existují však také další normy viz 3.1.2, které jsou založené na jiných výpočtech. Výsledná funkčnost projektu Ikaros by tak měla být rozšířena i pro tyto další normy.
60
Závěr Tato bakalářská práce vznikla na základě poptávky po webové aplikaci, která by umožňovala prediktivní výpočet spolehlivostních parametrů dle konkrétních norem. Cílem práce bylo seznámit se standardem MIL-HDBK-217F, dle něho navrhnout strukturu relační databáze a poté vytvořit webovou aplikaci, která umožní prediktivní výpočet spolehlivostních parametrů zadaných systémů dle normy MIL-HDBK-217F. Protože uvedená norma je velice rozsáhlá, omezila jsem se pouze na výčet několika typů součástek. Bakalářská práce nabízí analýzu současného stavu řešené problematiky, zároveň se detailněji věnuje popisu a struktuře normy MIL-HDBK-217F a poskytuje tak teoretický základ k jejímu pochopení. Na příkladu také podrobně popisuje postup při výpočtu intenzity poruch dle této normy. Pro vlastní implementaci webové aplikace jsem si zvolila programovací jazyk PHP, konkrétně framework Symfony2. Práce v Symfony2 pro mě nebyla příliš jednoduchá, jelikož jsem s tímto frameworkem neměla mnoho zkušeností. Jako databázový systém jsem si vybrala MySQL. Jedním ze zásadních problémů, který se objevil již v počáteční fázi práce, byl návrh relační databáze. Jelikož je norma velmi obsáhlá a pokrývá mnoho typů součástek, zabývala jsem se tím, jak nejlépe rozvrhnout strukturu, aby s ní webová aplikace mohla jednoduše spolupracovat. Protože byl návrh databáze stěžejní pro další vývoj, musela jsem mu věnovat spoustu času a pečlivě zvážit všechny možnosti návrhu. Dalším cílem bylo testování aplikace na skutečných datech. Využití a funkčnost zde navrhované a implementované webové aplikace byly testovány a ověřovány na dvou systémech dodaných vedoucím práce. Práce na projektu Ikaros byla pro mě přínosem hned z několika důvodů. Jelikož jsem se nikdy dříve spolehlivostí systémů nezabývala, poskytla mi bakalářská práce možnost získat nové znalosti v tomto oboru. Druhým přínosem pro mě je praktická zkušenost s návrhem komplexní webové aplikace ve frameworku Symfony2 a prozkoumání možností návrhu webu, např. práce s kni61
Závěr hovnou jQuery. Obecný přínos práce spatřuji v tom, že bude sloužit jako základní kámen pro rozsáhlejší vědecký projekt Ikaros, který se bude zabývat spolehlivostní analýzou v širším měřítku. Přínosnost práce se týká zejména praktického využití pro návrh spolehlivých systémů. K obhajobě bakalářské práce tedy předkládám ucelené řešení, které splňuje požadavky zadání a je plně funkční.
62
Literatura [1]
Documentation – Introducin Symfony [online]. , [Cited 2014-04-20]. Dostupné z: http://trac.symfony-project.org/wiki/Documentation/ cs_CZ/book/1.0/01-Introducing-Symfony
[2]
Inheritance Mapping; Doctrine 2 ORM 2 documentation [online]. [Cited 2014-04-20]. Dostupné z: http://docs.doctrine-project.org/ projects/doctrine-orm/en/latest/reference/inheritancemapping.html
[3]
Military Handbook MIL-HDBK-217F [online]. 1991, [Cited 2014-05-01]. Dostupné z: http://www.sre.org/pubs/Mil-Hdbk-217F.pdf
[4]
A methodology for components reliability | FIDES [online]. 2006, [Cited 2014-05-01]. Dostupné z: http://fides-reliability.org
[5]
Český normalizační institut: ČSN IEC 50(191) (010102). 1993.
[6]
Experti komunity jQuery: jQuery: kuchařka programátora. Brno: Computer Press, 2010, ISBN 978-80-251-3152-7.
[7]
Hlavička, J.; Racek, S.; Golan, P.; aj.: Číslicové systémy odolné proti poruchám. Praha: Vydavatelství ČVUT, 1992, ISBN 80-01-00852-5, s. 14–39.
[8]
Howe, S.: Responsive Web Design – An Advanced Guide to HTML & CSS [online]. [Cited 2014-04-20]. Dostupné z: http://learn.shayhowe.com/ advanced-html-css/responsive-web-design
[9]
Margorín, M.: jQuery bez předchozích znalostí. Brno: Computer Press, 2011, ISBN 978-80-251-3379-8.
[10] Morris, S.: The Reliability Analytics Toolkit line]. 2010, [Cited 2014-04-20]. Dostupné http://reliabilityanalyticstoolkit.appspot.com/ mil_hdbk_217F_parts_count 63
[onz:
Literatura [11] P.Q.M: FMEA [online]. 2013, [Cited 2014-05-01]. Dostupné z: http:// www.pqm.cz/nvcss/fmea.html [12] Shmueli, G.: Military Handbook MIL-HDBK-217 – SQC Online [online]. 2000, [Cited 2014-04-20]. Dostupné z: http://www.sqconline.com/ military-handbook-mil-hdbk-217-beta [13] Surrel, G.: MVC Diagram (Model-View-Controller) [online]. Březen 2013, [Cited 2014-04-20]. Dostupné z: https://commons.wikimedia.org/wiki/ File:ModeleMVC.png [14] System Reliability Center: Prism [online]. , [Cited 2014-05-01]. Dostupné z: http://src.alionscience.com/prism [15] Zaefferer, J.: jQuery Validation Plugin [online]. Březen 2013, [Cited 2014-04-20]. Dostupné z: https://github.com/jzaefferer/jqueryvalidation
64
Příloha
Seznam použitých zkratek CSS Cascading Style Sheets DOM Document Object Model DQL Doctrine Query Language EPRD Electronic Parts Reliability Data FMEA Failure Mode an Effect Analysis MTBF Mean Time Between Failure MVC Model-View-Controller NPRD Nonelectronic Parts Reliability Data ORM Objektově relační modelování SQL Structured Query Language SVG Scalable Vector Graphics
65
A
Příloha
Obsah přiloženého CD
readme.txt...................................stručný popis obsahu CD src impl...................................zdrojové kódy implementace sql.......................sql skripty pro vytvoření/naplnění tabulek createDials.sql........skript pro vytvoření a naplnění číselníků createEntities.sql...................skript pro vytvoření entit insertData.sql ..... skript pro naplnění tabulek testovacími daty thesis ...................... zdrojová forma práce ve formátu LATEX appendix......................................................přílohy test.................................testovací data a výsledky testů datamodel.png ............................... celkový datový model text ....................................................... text práce thesis.pdf ............................. text práce ve formátu PDF 67
B
