TECHNICKÁ UNIVERZITA V LIBERCI Fakulta mechatroniky, informatiky a mezioborových studií

TECHNICKÁ UNIVERZITA V LIBERCI

Fakulta mechatroniky, informatiky a mezioborových studií

NÁVRH APLIKACE PRO ZADÁVÁNÍ A KONTROLU SEMESTRÁLNÍCH PRACÍ

BAKALÁŘSKÁ PRÁCE

Liberec 2014 Jiří Chlum

NÁVRH APLIKACE PRO ZADÁVÁNÍ A KONTROLU SEMESTRÁLNÍCH PRACÍ

Bakalářská práce

Studijní program: B2612 – Elektrotechnika a informatika Studijní obor: 1802R022 – Informatika a logistika Autor práce: Jiří Chlum

Vedoucí práce: Ing. Jan Kamenický, Ph.D.

Liberec 2014

Prohlášení

Byl (a) jsem seznámen (a) s tím, že na mou bakalářskou práci se plně vztahuje zákon č.

121/2000 Sb. o právu autorském, zejména § 60 – školní dílo.

Beru na vědomí, že Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé bakalářské práce pro vnitřní potřebu TUL.

Užiji-li bakalářskou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tomto případě má TUL právo ode mne požadovat úhradu nákladů, které vynaložila na vytvoření díla, až do jejich skutečné výše.

Bakalářskou práci jsem vypracoval (a) samostatně s použitím uvedené literatury a na základě konzultací s vedoucím bakalářské práce a konzultantem.

Současně čestně prohlašuji, že tištěná verze práce se shoduje s elektronickou verzí, vloženou do IS STAG.

Datum:

Podpis:

Poděkování

Rád bych na tomto místě poděkoval Ing. Janu Kamenickému, Ph.D. za poskytnutí konzultací při tvorbě této práce.

Abstrakt

Bakalářská práce se zabývá návrhem webové aplikace pro zadávání a kontrolu semestrálních prací na předmět řízení jakosti a spolehlivosti.V teoretické části této práce jde především o seznámení s problematikou spolehlivosti v oblasti analýzy stromu poruchových stavů, blokového diagramu bezporuchovosti a údržby zaměřené na bezporuchovost. V praktické části bylo úkolem navrhnout softwarový nástroj, umožňující zadávání semestrálních prací v závislosti na unikátním znaku studenta.

Zahrnut je i návrh a budoucí zlepšení aplikace.

Klíčová slova

Aplikace, nepohotovost, pohotovost, údržba, algoritmus

Abstract

The bachelor thesis deals with the proposal of the web application for entering and checking of semester work on the subject of quality and reliability.

Theoretical part of this thesis is mainly about problems with reliability of fault tree analysis, block diagrams of reliability and reliability centred maintenance.

The task of the practical part of this thesis was to design a software tool that allows entry of semester work, depending on the unique character of the student. There is also included a proposal for future improvements of the application.

Keywords:

The application, unavailability, availability, maintenance, algorithm

Obsah

Seznam obrázku...8

Úvod...9

1 Aplikace na kontrolu semestrálních prací...10

1.1 MVC architektura...12

1.1.1 Motivace použití MVC v aplikaci...12

1.1.2 Model...12

1.1.3 View...13

1.1.4 Controller...13

1.2 Hlavní objekty aplikace...13

1.2.1 Generátor pseudonáhodných čísel...14

1.2.2 Databázový wrapper...15

1.2.3 Obecný kontroler...15

1.2.4 Směrovač (router)...17

1.3 Registrace a přihlášení...17

1.4 Databáze...19

1.5 Zabezpečení...21

2 Úloha číslo 1...22

2.1 Odeslání a uložení výsledku...23

2.2 Algoritmus pro výpočet výsledku...23

3 Úloha číslo 2...26

3.1 Odeslání a uložení výsledku...27

3.2 Algoritmus pro výpočet výsledku...27

4 Úloha 3...30

4.1 Odeslání a uložení výsledku...31

4.2 Algoritmus pro výpočet MEI...32

5 Rozhraní pro vyučující...33

5.1 Funkce automatické kontroly...33

6 Navržené zlepšení do budoucna...34

6.1 Přidání více úloh...34

6.2 Interaktivní vytváření diagramu...34

6.3 Editor zadání...35

7 Analýza stromu poruchových stavu...36

7.1 Charakteristika, cíle a postup provádění analýzy...36

7.2 Přípravná část analýzy...38

7.3 Tvorba stromu poruchových stavu...40

7.4 Kvalitativní analýza stromu poruchových stavu...42

7.4.1 Kritické řezy...42

7.5 Kvantitativní analýza stromu poruchových stavu...42

7.5.1 Metoda přímého výpočtu...43

7.5.2 Metoda minimálních kritických řezu...43

7.5.3 Algoritmus určení minimálních kritických řezu...44

7.5.4 Hodnocení závažnosti minimálních kritických řezu...44

7.5.5 Vyhodnocení analýzy...44

8 Analýza blokového diagramu bezporuchovosti...46

8.1 Základní typy diagramu a jejich řešení...47

8.1.1 Sériový systém...47

8.1.2 Paralelní systém...47

8.1.3 Smíšený systém...47

8.1.4 Výběrový systém m z n...48

9 Údržba zaměřená na bezporuchovost...49

9.1 Vstupní data...49

9.1.1 Dokumentace...49

9.1.2 Spolehlivostní funkce...49

9.1.3 Ekonomické údaje...50

9.2 Plánování údržby...50

9.2.1 RTF (Run To Failure)...51

9.2.2 TBT (Time Based Task)...51

9.2.3 CBT (Condition Based Task)...51

9.3 Princip metody RCM...52

9.4 Princip vypracování programu preventivní údržby...52

9.5 Posouzení údržby...53

Závěr...55

SEZNAM POUŽITÉ LITERATURY...56

Seznam obrázku

Obrázek 1: Diagram tříd kontrolerů...15

Obrázek 2: Relační vztahy v databázi...19

Obrázek 3: Tabulka hodnot cvičení 1...21

Obrázek 4: Diagram FTA úloha 1...23

Obrázek 5: Tabulka hodnot cvičení 2...25

Obrázek 6: Blokový diagram úloha 2...27

Obrázek 7: Tabulka neudržovaného objektu ...30

Obrázek 8: Tabulka udržovaného objektu...30

Obrázek 9: Strom poruchových stavů...37

Obrázek 10: Blokový diagram...45

Obrázek 11: Postup vypracování dynamického programu údržby...52

Úvod

V dnešní době, kdy technologie zasahují do takřka každého odvětví je dobré jejich využití i pro školní účely. Webové služby už delší dobu neslouží pouze pro výměnu informací či jejich zobrazování. Díky rostoucímu výkonu počítaču (serveru) a rozvoji programovacích jazyku, které jsou primárně určený na web, dochází k rustu počtu moderních webových aplikací. Tyto nové aplikace dosahují parametru desktopových aplikací. K jejich použití stačí pouze internetové připojení a webový prohlížeč.

Nezáleží na platformě, ze které je k nim přistupováno. To ulehčuje práci vývojářum, kteří nemusí programovat duplikativní aplikace na ruzné platformy, ale stačí jím jedna běžící na webu.

Práce se zabývá tvorbou webové aplikace pro kontrolu a zadávání semestrálních prací. Je zde uvedeno použití architektury, webových technologií a jednotlivých hlavních komponent. Aplikace poskytuje tři zadání a každé je podrobně rozebráno jak z teoretické části, tak z programovací. Uvedeny jsou i návrhy na možnosti budoucího zlepšení. Probrán je

1 Aplikace na kontrolu semestrálních prací

V dnešní době velkého rozmachu počítaču, nových technologií a především webových služeb je vhodné tyto technologie využívat při výuce. Aplikace vznikla jako pokus o zavedení elearningové výuky předmětu Řízení jakosti a spolehlivosti na fakultě Mechatroniky, informatiky a mezioborových studií. Poskytuje možnost zadávání studentum semestrální úlohy z tohoto předmětu a jejich zpětnou kontrolu. S její pomocí bude mít vyučující lepší přehled nad počtem odevzdaných prací i nad jejich výsledky.

Aplikace je vytvořena jako webová služba. Díky tomu není nutné, aby si studenti a vyučující instalovali do svých počítaču dodatečný software. Tím je získáno velké výhody, protože není nutná úprava pro jednotlivé platformy a aplikace je tím pádem s nimi kompatibilní. Stačí použít libovolný webový prohlížeč.

Pro kontrolu a zadávání jsou naprogramovány následující úlohy :

 Výpočet ustálené nepohotovosti vrcholové události podle diagramu FTA;

 výpočet pohotovosti systému, který je znázorněn blokovým diagramem;

 úloha na vypracování RCM analýzy.

Pro tvorbu softwaru byly použity následující technologie:

 PHP;

 Javascript;

 Mysql.

 HTML

 CSS

PHP je skriptovací jazyk určený především pro programování dynamických stránek a webových aplikací. Skripty jsou prováděny na straně serveru. Je nezávislý na platformě a má širokou podporu knihoven. Duležitým faktorem pro výběr toho to jazyka je jeho podpora objektově orientovaného programování. PHP je v aplikaci využito pro sestavení architektury aplikace, kde se stará o propojení vzhledu stránky s řídící logikou, tak pro výpočty výsledku úloh. [4]

Javascript je multiplatformní objektově orientovaný jazyk. Je schopný reagovat na uživatelem iniciované akce (například kliknutí na tlačítko), bez použití síťového přenosu. Na rozdíl od jazyka PHP neběží na serveru, ale na klientovi (prohlížeč). V aplikaci je využita javascriptová knihovna JQUERY, která má širokou podporu mezi prohlížeči. Je svobodná, otevřená a spadá pod licenci MIT.

Mysql je multiplatformní databázový systém. Pro komunikaci je použit jazyk SQL.

Jedná se o volně šiřitelný software, který má v současné době vysoký podíl na používaných databází.

Hyper Text Markup Language (odkazovací a značkovací jazyk) zkratkou HTML, je značkovací jazyk pro hypertext. Skládá se ze značek (tagu), samotný umožňuje dávat prvkum na stránce určitý význam. [6]

Cascading Style Sheets (kaskádové styl) zkratkou CSS, je speciální jazyk pro zpusob popisu zobrazování stránek napsaných v HTML. CSS je kaskáda proto, že v něm funguje dědičnost.

1.1 MVC architektura

Tato architektura ačkoliv vznikla na desktopech, tak se nejvíce uchytila na webu.

Snaží se o rozdělení datového modelu aplikace, uživatelského rozhraní a řídící logiky do tří nezávislých komponent:

 Model;

 view;

 controller.

1.1.1 Motivace použití MVC v aplikaci

Architektura MVC je použita zejména proto, aby byl kód aplikace v budoucnu dále jednoduše rozšířitelný nad rámec puvodního očekávání a bez náchylnosti na zanesení chyb. Výhodné je zejména to, že řeší problém duplikace kódu. Není proto nutné opisovat řídící logiku vícekrát, ale jednoduše použít již vytvořenou.[5]

1.1.2 Model

Veškerá řídící logika je uložena v modelu. Příklad použitých modelu:

 Generátor pseudonáhodných čísel;

 databázový wrapper;

 algoritmy pro kontrolu provedených výpočtu.

Model se nestará o výstup aplikace v podobě pohledu. Jeho funkce spočívá ve přijetí dat zvenku (z pohledu) jejich zpracování a následném vydání ven (do kontroleru).

1.1.3 View

Stará se o zobrazení výstupu uživateli. Je zde používáno phtml šablon, které obsahují pouze HTML a tagy php jazyka. Ten umožňuje do šablon vkládat hodnoty z proměnných. Php je značkovací jazyk, tak umožňuje takový styl zápisu, aby struktura HTML zustala zachována. Pohled zadání je pro všechny uživatele stejný a díky php se liší pouze v generovaných vstupních hodnotách, které jsou zobrazeny studentovi a se kterými bude dále počítat.

1.1.4 Controller

Stará se o vzájemnou komunikaci. Získává data z Modelu a předává je do View a zároveň zpracovává uživatelské požadavky jako je odeslání formuláře.

1.2 Hlavní objekty aplikace

Z použití objektově orientovaného programování plynou vlastnosti, které jsou pro tuto metodu vlastní to je použití objektu, dědičnosti, abstrakce a polymorfismu.

Objekty jsou vytvářeny pomocí tříd. Ta definuje jejich vlastnosti a schopnosti. Takto vytvořené objekty jsou nazývány instancemi. Instance mají stejné rozhraní jako třída, podle které jsou vytvořeny. Liší se pouze svými daty (atributy).

Dědičnost slouží k vytvoření nových datových struktur na základě již vytvořených.

Není tedy nutné znovu programovat již naprogramované funkce, ale je možné, aby nový objekt tyto funkce zdědil od svého předka. Tohoto přístupu je využito pro kontrolery, kde všechny kontrolery dědí od obecného kontroleru.

Obecný kontroler, popsán v kapitole 1.2.3, je vytvořen pouze za účelem, aby od něj ostatní kontrolery dědily. Takovým třídám se říká abstraktní.

Využití polymorfismu, kde se používá stejné rozhraní pro práci s ruznými typy objektu, je využito pro třídy, které zajišťují výpočet hodnot. Tyto třídy dědí rozhraní od jedné třídy, která implementuje metodu vypočítej. A tato metoda je v každé třídě přepsána podle toho jak výpočet probíhá. Rozhraní však zustalo zachováno a není nutné přemýšlet, jak se metoda vypočítej u každého objektu volá, ale bude volána vždy stejným zpusobem.

V aplikaci jsou používány tyto hlavní objekty:

 Generátor pseudonáhodných čísel;

 databázový wrapper;

 obecný kontroler;

 směrovač (router).

1.2.1 Generátor pseudonáhodných čísel

Pro výpočet pseudonáhodných čísel je využito Lineárního kongruentního generátoru.

Ten generuje posloupnost pseudonáhodných čísel Xn podle vzorce:

(1)

 m – perioda, m > 0;

 a – násobitel, 0 ≤ a < m;

 c – přičítaná hodnota, 0 ≤ c < m;

 X0 – seed, 0 ≤ X0 < m.

Generátor generuje náhodná čísla s rovnoměrným rozložením v rozsahu 0 ≤ Xi < m.

Generovaná čísla jsou závislá na počátečním nastavení hodnoty seed a nastavení

hodnot a, c. Pro hodnoty a, c je využito čísel ze standardní knihovny jazyka C. Seed je složen ze studentského čísla a aktuálního roku. Pro stejnou hodnotu seed je generovaná posloupnost čísel vždy stejná. Tohoto jevu je v aplikaci využito tak, že s každým novým rokem budou stejnému studentovi generována jiná čísla (ty jsou používána jako vstupní hodnoty v zadáních). Proto kdyby jakýkoliv student musel předmět opakovat, nenastane situace, že jsou mu vygenerovány stejná čísla jako předcházející nebo jakýkoliv jiný rok.

1.2.2 Databázový wrapper

Je naprogramován okolo ovladače PDO, který je poskytován přímo php. Ovladač PDO je univerzální objektový ovladač a podporuje ho více druhu databází.

Databázový wrapper poskytuje rozhraní pro komunikaci s databází. Obsahuje metody pro vkládání, aktualizování, mazání a vypsání dat z databáze. Jeho použití spočívá pouze ve vytvoření jeho instance a zavolání příslušné metody, o zbytek se postará sám.[7]

1.2.3 Obecný kontroler

Tato abstraktní třída poskytuje abstraktní funkci process, kterou každá zděděná třída musí přepsat a mimo ní implementuje i další funkce:

 Přepsání URL adresy;

 přidání a vrácení zpráv uživateli;

 ověřování zda je uživatel přihlášen.

Metoda pro přepsání adresy je volána s parametrem, ve kterém se nachází URL adresa. Tuto URL adresu umístí do hlavičky HTTP protokolu.

Přidání a vrácení zprávy uživateli funguje na principu uložení zprávy do superglobální (je možno k ní přistupovat všude v aplikaci) proměnné session (technologie pro ukládání dat během komunikace se serverem) anebo vypsání dat z této proměnné.

Při kontrole přihlášeného uživatele je kontrolována session se jménem uživatele.

Když session není vytvořena, znamená to, že uživatel není přihlášen a je přesměrován na přihlašovací stránku. Z toho to duvodu není možné, aby aplikaci používal nepřihlášený uživatel.

Obecný kontroler implementuje atributy pro ukládání dat získaných z modelu.

Pomocí tohoto atributu jsou předávána data mezi modelem a pohledem. Do dalšího atributu je ukládán název pohledu, který se má vypsat.

Od této třídy dědí (přejímají její funkce a veřejné atributy) všechny použité kontrolery. Struktura kontroleru je zobrazena na obrázku č. 1.

Obrázek 1: Diagram tříd kontroleru

1.2.4 Směrovač (router)

Práce směrovače spočívá v přijetí URL adresy a na základě jejího zpracování, přesměruje na příslušný kontroler. Směrovač sám je kontroler. Princip zpracování přijaté URL adresy:

 Oddělení části s protokolem a doménou od části s parametry;

 odstranění bílých znaku (mezery);

 rozparsování (rozebrání) podle lomítek a převedením do asociativního pole;

 zavolání příslušného kontroleru.

V aplikaci je zavedena konvence zápisu URL adres do následujícího tvaru:

Kontroler/parametr[1]/parametr[2]. Router je schopen si poradit jak s velkými tak s malými písmeny. Díky tomu to zápisu router pozná jaký kontroler a s jakými parametry má zavolat.

1.3 Registrace a přihlášení

Před prvním použití aplikace je nutné se registrovat. Bez toho není možné dále pracovat, protože neregistrovaný uživatel se není schopen dostat dál než na stránku s přihlášením nebo registrací.

Při registraci jsou od studenta vyžadovány tyto údaje:

 Email;

 jméno;

 studentské číslo;

 heslo.

Email má každý uživatel jiný, proto je ukládán a slouží jako přihlašovací údaj. Email je povolen pouze školní z duvodu registrace cizích uživatelu, kteří nemají v aplikaci co dělat.

Jméno je vyžadováno, aby měl vyučující přehled o tom, kdo odevzdané zadání vypracoval.

Studentské číslo je unikátní znak každého studenta. Zatímco muže nastat situace, kdy dva studenti mají stejné jméno, tak situace, kdy dva mají stejné studentské číslo, nastat nemuže. Toto číslo neslouží pouze k zobrazení vyučujícímu pro jasnou identifikaci studenta, ale slouží i pro nastavení seedu v generátoru pseudonáhodných čísel popsáno v kapitole 1.2.1.

Heslo pro vstup do aplikace není nijak omezeno. Po zadání hesla je na něj aplikována kryptografická funkce sha-1, kterou poskytuje php a je k němu přiřazen náhodný řetězec. Tento řetězec zajišťuje, že i hesla uložená v tabulkách otisku (tabulky, kde je k často používaným heslum přiřazen otisk) jsou zaheslována jinak než puvodní heslo.

Funkce sha-1 převádí řetězec na hash (otisk) pevné délky 40 znaku, ze kterého se puvodní řetězec nedá v rozumném čase zjistit zpátky.

Všechny tyto údaje jsou poté uloženy do databáze. Spolu s nimi je každému uživateli vygenerováno identifikační číslo, které je používáno pro jednodušší vyhledávání v tabulkách databáze. A také je nastaven příznak pro rozeznání vyučujících a studentu, popsáno v kapitole 1.4.

K přihlašování slouží, jak již bylo zmíněno email a heslo. Po zadání těchto údaju je zkontrolováno, zdali jsou tyto hodnoty správné. A na serveru se vytvoří session se jménem, studentským číslem a příznakem pro vyučující. Podle příznaku je dále přesměrováno buď na výběr zadání pro studenty, nebo na tabulky s výsledky pro učitele.

1.4 Databáze

Postavena na relační databázi Mysql. To značí, že je založena na tabulkách.

Nacházejí se v ní čtyři tabulky:

 Tabulka uživatel;

 tabulka cvičení 1;

 tabulka cvičení 2;

 tabulka cvičení 3;

 automatik;

 zadání.

Do tabulky uživatel jsou ukládána data při registraci. Uchováváno je v ní jméno, email, heslo, datum registrace, číslo studenta, příznak učitel a identifikační číslo. V příznaku učitel je nastavena hodnota 0 pro studenta a 1 pro učitele. V základním nastavení je každému nově registrovanému uživateli přidělena 0 a pouze administrátor má právo ho měnit. Identifikační číslo je automaticky inkrementováno při každé nové registraci, a proto nikdy nebude pro dva uživatele stejné. Je využíváno, jak je vidět z obrázku 2, pro identifikaci uživatele v tabulkách cvičení.

Tabulky pro cvičení 1 a 2 jsou stejné. A to z duvodu, že počet a typ hodnot do nich ukládaných je stejný. Poskytují úložiště pro první dvě úlohy. Spolu s identifikačním číslem uživatele, který vypracoval úlohu a odeslal ji k odevzdání, je do nich ukládán

i softwarově spočítaný výsledek těchto úloh. Duležité je ukládání data odevzdání, podle kterého je možné identifikovat splnění termínu odevzdání práce.

Tabulka pro cvičení 4 obsahuje identifikační číslo studenta a datum odevzdání. S těmi to údaji jsou ukládána serializovaná data o jednotlivých součástkách a softwarově spočítané indexy MEI podrobně popsáno v kapitole 4.2.

Obrázek 2: Relační vztahy v databázi

Tabulka pro zadání obsahuje slovní zadání ke každé úloze. Automatik obsahuje příznak pro rozpoznání funkce automatické opravy, podrobněji v kapitole 6.1,

1.5 Zabezpečení

Každá webová aplikace potřebuje být zabezpečena. Na internetu dochází denně k mnoha útokum na ruzné webové služby. Nejrozšířenější druhy útoku jsou:

 Cross site scripting;

 SQL injection.

Cross site scripting je útok, kdy dochází pomocí neošetřených vstupu k nahrání škodlivého kódu do html stránky. Ten muže poškodit vzhled stránek, z nefunkčnit je nebo získat citlivé údaje. Proti tomu to útoku jsou všechny vstupy v aplikaci ošetřené tak, že všechny potencionálně škodlivé znaky jsou převedeny do html entit (speciální symbol). Tím pádem by při pokusu o zapsání skriptu do stránek došlo pouze k výpisu skritpu jako textu.

Při neošetřeném vstupu, který komunikuje s databází, muže dojít k SQL injection. To je technika, kdy vsunutím nebezpečného kódu například při přihlašování, by mohlo dojít k přihlášení bez použití hesla. Proti tomuto útoku je použito parametrizování SQL dotazu. Dotaz je nejprve připraven a místo skutečných hodnot jsou použity zástupné znaky. Hodnoty a dotaz jsou následně předány databázi odděleně a ona si je sama vloží tak, aby to bylo bezpečné.

2 Úloha číslo 1

První zadání kontroluje znalosti studenta z oblasti analýzy stromu poruchových stavu, podrobněji je popsáno v kapitole 7. Student bude aplikovat své znalosti pří výpočtu ustálené nepohotovosti vrcholové události. Jako zadání slouží diagram stromu poruch s předem definovanými událostmi. K těmto událostem jsou v tabulce viz. (obrázek 3) definovány následující hodnoty:

 Střední doba do obnovy (MTTR);

 intenzita poruch (λ).

Obě tyto hodnoty jsou získány pomocí generátoru pseudonáhodných čísel a jsou generovány v intervalech MTTR (0h – 744h>, λ (10^-3h^-1, 10^-7h^-1). Hodnoty jsou pro další zpracování ukládány do pole.

Student po provedení výpočtu, který se do aplikace nezanáší. Zadá svůj vypočtený výsledek do příslušného políčka. To se nachází spolu s tlačítkem odevzdat, pod tabulkou s hodnotami. Stiskem tlačítka odevzdat, odešle svůj výsledek ke kontrole.

Obrázek 3: Tabulka hodnot cvičení 1

2.1 Odeslání a uložení výsledku

Při zpracování odeslaného výsledku je nejprve nutné zkontrolovat, v jakém tvaru se výsledek nachází. Programovací jazyk php umí pracovat s desetinnými čísly pouze v případě, že jsou, jako oddělovač desetinných míst slouží znak tečky. Proto je kontrolován tvar a v případě použití desetinné čárky je tato čárka nahrazena tečkou.

Spolu s výsledkem jsou odeslány i další údaje:

 Identifikační číslo;

 datum odevzdání;

 výsledek spočítaný softwarem.

Identifikační číslo slouží k tomu, aby bylo jasně specifikováno, jaký uživatel úlohu vypracoval.

Datum odevzdání je odesíláno z duvodu přehlednosti vyučujícího o čase odevzdání práce. Podle tohoto data je kontrolováno, jestli student v tomto roce práci již odevzdal a výsledek má být pouze aktualizován.

Správné řešení je počítáno algoritmem, popsáno níže, ve stejný moment kdy student odešle svuj výsledek. Všechny tyto údaje jsou uloženy do databáze a připraveny k nahlédnutí vyučujícímu.

2.2 Algoritmus pro výpočet výsledku

Je založený na postupném pruchodu diagramu od základních událostí po vrcholovou událost. Během pruchodu je zkoumáno, jaké hradlo je bezprostředně navázáno na základní událost. Podle tohoto hradla je rozhodnuto, jaký vzorec bude použit pro výpočet nepohotovosti události, která se nachází bezprostředně za tímto hradlem.

Celý proces je proveden v následujících krocích:

 Rozdělení vstupních dat do dvou skupin.

 Získání MTBF (střední doba mezi poruchami);

 výpočet nepohotovosti všech základních událostí;

 rozpoznání událostí vstupujících do hradla;

 výpočet nepohotovosti za hradlem.

Jako první je provedeno rozdělení vstupních dat do dvou skupin. Data do algoritmu vstupují v podobě pole. První polovina pole obsahuje hodnoty MTTR a druhá polovina hodnoty λ.

V dalším kroku je třeba převést hodnoty λ na střední dobu mezi poruchami. To je prováděno z důvodu, že pro zjednodušení, je pro výpočet nepohotovosti události

použit následující vzorec: U= MTTR ( MTBF+MTTR)

 U – ustálená nepohotovost události;

 MTBF – střední doba mezi poruchami;

 MTTR – střední doba do obnovy.

Všechny hodnoty λ je tak, nutno převést na MTBF a toho je docíleno pomocí

následujícího vzorce: MTBF=1

λ . Tím je získáno všech potřebných hodnot pro další výpočty.

V diagramu stromu poruch je definováno pět základních událostí. Pro každou tuto událost je spočítaná ustálená nepohotovost podle vzorce uvedeného výše.

Protože diagram stromu poruch je zobrazen jako obrázek (viz. Obrázek 4), je dopředu známo, které události budou vstupovat do jakého hradla. V diagramu se vyskytují pouze hradla OR a AND pro výpočet nepohotovosti události, která leží bezprostředně za nimi, jsou použity vzorce, uvedeny v kapitoly 7.5.1. Takto získané nepohotovosti událostí vedou do dalších hradel, až po vrcholovou událost. Které je algoritmem vrácena při jeho volání.

Obrázek 4: Diagram FTA úloha 1

3 Úloha číslo 2

Druhé zadání kontroluje znalosti studenta z oblasti blokových diagramu bezporuchovosti podrobněji popsáno v kapitole 3. Student bude aplikovat své znalosti při výpočtu pohotovosti systému, který je znázorněn jako blokový diagram.

Jako vstupní data slouží tabulka hodnot viz. (obrázek 5), kde je definováno:

 MTBF (střední doba mezi poruchami);

 μ – intenzita oprav

Obě tyto hodnoty jsou získány pomocí generátoru pseudonáhodných čísel a jsou generovány v intervalech MTBF (0h – 876000h> , μ (10^-4 h^-1, 10⁰ h^-1). Hodnoty jsou ukládány pro další zpracování do pole.

Student po provedení výpočtu. Zadá svůj vypočtený výsledek do příslušného políčka.

To se nachází spolu s tlačítkem odevzdat, pod tabulkou s hodnotami. Stiskem tlačítka odevzdat, odešle svůj výsledek ke kontrole.

Obrázek 5: Tabulka hodnot cvičení 2.

3.1 Odeslání a uložení výsledku

Proces odeslání a uložení výsledku od uživatele probíhá stejným zpusobem, jako je uveden v úloze 1.

3.2 Algoritmus pro výpočet výsledku

Systém, na který je algoritmus aplikován se nachází ve smíšeném zapojení, podrobněji popsán v kapitole 8.1.3. Proto je nutné systém rozdělit na jednotlivé sériové a paralelní subsystémy. Po této úpravě, budou jednotlivé subsystémy v sériovém zapojení. Systém se tak bude nacházet v poruchovém stavu, pokud jeden z jeho subsystému se bude nacházet v poruchovém stavu. Postup výpočtu je tak následující:

 Rozdělení vstupních hodnot do dvou skupin;

 získání střední doby do obnovy (MTTR);

 spočítání pohotovosti jednotlivých bloku;

 spočítání pohotovosti každého subsystému;

 spočítání pohotovosti celého systému.

Jako vstupní parametr algoritmu slouží pole generovaných hodnot, se kterými student výsledek vypočítal. Ty je třeba rozdělit do dvou skupin. První skupina obsahuje hodnoty MTBF druhá skupina μ.

V dalším kroku jsou hodnoty μ, převáděny na střední dobu do obnovy (MTTR). To je prováděno z důvodu, že pro výpočet pohotovosti jednotlivých bloků je použit

následující vzorec: A= MTBF (MTBF+MTTR )

 A – pohotovost jednoho bloku.

 MTBF – bloku;

 MTTR – bloku.

Výpočet MTTR pro jeden blok je podle vzorce : MTTR=1 μ

 MTTR – bloku;

 μ – bloku.

Po převedení hodnot, je pro všechny bloky spočítána jejich pohotovost, podle vzorce uvedeného výše.

V blokovém diagramu, jak je vidět z obrázku 10, se nachází bloky R0 a R1 v paralelním zapojení, blok R2 je k těmto blokům zapojen sériově a bloky R3,R4,R5 jsou v paralelním zapojení. Takové to zapojení, je možné rozložit na 3 subsystémy R0-R1, R2 a R3-R4-R5 a vypočítat jejich pohotovost podle následujících vzorců:

 AR0 - AR5 – pohotovosti jednotlivých bloků;

 As1, AS3 – pohotovost subsystému.

Pohotovost bloku R2, je spočítána v předchozím kroku. Teď jsou k dispozici pohotovosti jednotlivých subsystémů, které jsou spolu v paralelním zapojení.

Výpočtem pohotovosti tohoto zapojení dostaneme výslednou pohotovost systému.

Vzorec pro sériové zapojení:

 AS – výsledná pohotovost systému.

Výsledná pohotovost systému je algoritmem vracena jako jeho výstup.

Obrázek 6: Blokový diagram úloha 2

4 Úloha 3

Třetí zadání kontroluje znalosti studenta z oblasti údržby zaměřené na bezporuchovost, podrobněji popsána v kapitole 9. Student bude aplikovat své znalosti při výpočtu indexu MEI a návrhu údržby pro zařízení. Jako zadání souží popis zahradního traktoru a výčet jednotlivých součástek, pro které má analýzu vytvářet. Ke každé součástce jsou pomocí generátoru náhodných čísel vygenerovány hodnoty MTBFN 0 (střední doba do poruchy neudržovaného objektu). Počet vypracovaných součástek, záleží na studentovi avšak maximální možný počet je pět.

Výstupem této úlohy jsou jednotlivé indexy MEI pro každou součástku.

Při vstupu do úlohy jsou studentovi zobrazeny dvě oddělené tabulky viz. (obrázek 7 a 8).V první tabulce nazvanou Před údržbou, student zvolí jméno součástky a vyplní volná políčka pro:

 Ztráta z výroby;

 náklady na práci;

 náklady na náhradní díly.

Ke každým nákladum by měl být uveden i jejich popis. Ve druhé tabulce nazvanou Navržená údržba, student napíše úkony údržby a k nim uvede i náklady na tuto údržbu. Zvolí velikost MTBFuo (střední doba mezi poruchami udržovaného objektu), vypočítá index MEI(jeho výpočet je kontrolován) a napíše, zdali se jím navržená údržba vyplatí provádět.

Obrázek 7: Tabulka neudržovaného objektu

Obrázek 8: Tabulka udržovaného objektu.

4.1 Odeslání a uložení výsledku

Při zpracování odeslaného výsledku je nejprve nutné ošetřit všechny vstupy. Ošetření není jenom z duvodu možného útoku popsaného v kapitole 1.5, ale i kvuli následné serializaci dat. Odeslaná data se vyskytují ve formě dvou rozměrného pole. Toto pole používá jako svuj první index (klíč) pořadí v jakém byly jednotlivé tabulky vytvářeny. Díky tomu, je od sebe možné rozdělit jednotlivé součástky. Každá součástka má v databázi své místo pro uložení, nejprve je však nutné serializovat všechna data o součástce, aby šla uložit do jednoho místa. Toho je docíleno následovně:

 Odstranění nepovolených znaku u popisku a komentářu;

 spojení jednotlivých položek pole do řetězce.

Jako první je provedeno odstranění nepovolených znaku. Nepovolený znak je středník, a kdyby se v komentáři nebo popisku vyskytoval, tak bude nahrazen tečkou.

To je z duvodu, že při spojování jednotlivých položek do řetězce je mezi tyto položky vložen právě znak středníku. Podle kterého, je při opětovném načtení součástky z databáze možné, rozdělit jednotlivé položky od sebe. Při serializaci, dochází i k ukládání dat potřebných k výpočtu do proměnných.

Spolu s každou součástkou je do databáze uložen i příslušný index MEI, který byl softwarově spočítán.

4.2 Algoritmus pro výpočet MEI

Je volán s parametrem pole, které obsahuje informace o jednotlivých součástkách, jeho podoba je popsána v předcházející kapitole. Vrací jednotlivé indexy MEI pro každou součástku. Celý pruběh algoritmu spočívá v následujících krocích:

 Oddělení nákladu na údržbu, následky poruch, MTBFNO, MTBFUO;

 spočítání rizika neudržovaného objektu- RNO;

 spočítání rizika udržovaného objektu RUO;

 součet nákladu na údržbu;

 aplikování vzorce na výpočet MEI.

V první fázi jsou rozděleny jednotlivé náklady na údržbu, následky poruch a hodnoty MTBF udržovaného objektu a neudržovaného. Z těchto hodnot jsou vypočítaná rizika udržovaného a neudržovaného objektu, podle vzorcu popsaných v kapitole 8.5.

Dále jsou sečteny náklady na údržbu za roční období.

Dalším krokem je dosazení do vzorce pro výpočet indexu MEI, který je uveden v kapitole 8.5. Tento postup je aplikován na všechny součástky.

5 Rozhraní pro vyučující

Vyučující je rozpoznán, jak je popsáno v (kapitola 1.4) podle příznaku uloženého v databázi. Díky tomu software rozpozná, že se jedná o vyučujícího a je přesměrován na pohled s výsledky. V tomto pohledu se nachází tři oddělené tabulky pro každou úlohu jedna. První dvě obsahují jméno, studentské číslo, správné řešení, výsledek, který student vypočítal a datum odevzdání. Vše je seřazeno podle nejnovějšího data odevzdání. Díky tomu, že předmět řízení jakosti a spolehlivost je vyučován pouze v letním semestru, je možné zobrazovat výsledky pouze v aktuálním roce. Třetí tabulka, která poskytuje informace o třetí úloze, obsahuje pouze studentské číslo, datum odevzdání a jméno. Jméno je barevně odlišeno a funguje jako odkaz. Po kliknutí na něj je vyučující přesměrován na pohled, obsahující vypracované tabulky součástek. K nim přibyl také spočítaný index MEI.

5.1 Funkce automatické kontroly

Vyučující má možnost zapnout funkci automatické kontroly. Zapnutí této funkce indikuje nápis v pohledu vyučujícího doplněný o tlačítko zapnout a vypnout. Při jejím zapnutí se studentovi, který odevzdává úlohu kontroluje jeho správný výsledek a je mu odeslána zpráva o úspěšnosti.

Při odeslání výsledku studentem je nejprve kontrolován stav (zapnuto/vypnuto) této funkce. Když je funkce zapnutá provede se porovnání s softwarovým výsledkem, výsledek se uloží do databáze a studentovi je zobrazena zpráva o úspěšnosti. V případě špatné úspěšnosti může okamžitě zadat nový výsledek. Při vypnutém stavu se výsledek pouze uloží a student je přesměrován na stránku s výběrem zadání.

6 Navržené zlepšení do budoucna

Díky použité architektuře bude možné aplikaci dobře rozšiřovat. Proto bych navrhoval tyto zlepšení:

 Přidání více úloh;

 interaktivní vytváření diagramu;

 editor zadání;

6.1 Přidání více úloh

Na předmětu řízení jakosti a spolehlivosti je vyučováno více analýz, než je uvedeno v této práci. Proto by nebylo špatné úlohy, které se v aplikaci nevyskytují přidat. A rozšířit tak možnosti zadávání semestrálních úloh o více témat.

6.2 Interaktivní vytváření diagramu

V dnešní době je možné na webu pomocí javascriptu programovat aplikace, které běží na klientské straně a interagovat tak s uživatelem přímo, bez nutnosti znovu načtení stránky. S pomocí technologie SVG (škálovatelná vektorová grafika), která umí pracovat s DOM (objektový model dokumentu) událostmi, by bylo možné naprogramovat knihovny, pomocí nichž by studenti mohli vytvářet v prohlížeči diagramy jednotlivých analýz. To by mohlo vést k lepší interaktivitě a pro studenty by to bylo zajímavější než kreslení na papír.

6.3 Editor zadání

Momentálně se všechna zadání úloh nacházejí naformátovaná v jednotlivých databázi. Za použití jednoduchého editoru bude možné jejich podobu měnit. Na to budou muset být navázány další změny. Jako například:

 Změna parametru generovaných čísel;

 úprava algoritmu pro výpočet;

 změna fungování automatické kontroly.

Změny parametru generovaných čísel lze dosáhnout snadno. Generátor přijímá interval pro generování jako parametr. Kdyby tyto parametry byli propojeny s databází, do které by se ukládaly, šlo by takto používat změnu parametru pro jednotlivé úlohy od vyučujícího.

Automatická kontrola a algoritmy pro výpočet jsou úzce spjati se zadáním. Proto při změně zapojení například u blokového diagramu, by došlo k chybným výpočtum.

Pro nové zapojení by musel být naprogramován nový algoritmus výpočtu, který je napojen i na automatickou kontrolu.

7 Analýza stromu poruchových stavu

V roce 1962 byla poprvé firmou Bell Telephone Laboratories použita metoda analýzy stromu poruchových stavu FTA (Fault Tree analysis) při vývoji startovacího systému rakety Minuteman. Dále byla metoda používána firmou Boeing, která jako první implementovala výpočtové programy umožňující kvantitativní a kvalitativní vyhodnocení stromu poruchových stavu za pomoci výpočetní techniky. Metoda byla, především uplatňována, tam kde se používaly složité technické systémy například v jaderné energetice, letectví, kosmonautice, zbrojním prumyslu a jiných oborech.

Postupem času se metoda rozšířila i do jiných oblastí a stala se jednou z nejrozšířenějších metod pro analýzy spolehlivosti, a hodnocení rizika a dusledku poruch složitých systému. [1] [2]

V roce 1990 Mezinárodní elektrotechnická komise IEC vydala normu IEC 1025 - Fault tree Analysis, která obsahuje zobecněné zkušenosti z praktického využití metody a zformulovány principy a postupy pro tvorbu a vyhodnocování stromu poruchových stavu. Norma byla vydána jako česká technická norma ČSN IEC 1025 – Analýza stromu poruchových stavu v roce 1993. V současné době tato norma již neplatí a nahradila ji norma ČSN EN 61025 – Analýza stromu poruchových stavu.

[1] [2]

V současnosti jsou na trhu uplatňovány výkonné softwarové nástroje, které metodu zjednodušují, a tak se dá očekávat její další rozšiřování. Metodu by měl i přes to používat jen kvalifikovaný odborník s širokým rozhledem. [1]

7.1 Charakteristika, cíle a postup provádění analýzy

Metoda analýzy stromu poruchových stavu patří do kategorie deduktivních metod a muže se zařazovat mezi speciální orientované grafy. Strom poruch nabývá podoby

logického diagramu, který znázorňuje logické vztahy mezi vrcholovou událostí, zvanou kořen stromu a mezi příčinami vzniku této události. Příčiny mohou vznikat v provozních podmínkách, očekávaných poruchách prvku systému, náhodných diskrétních poruchách, v odchylkách provozních parametru prvku apod. Výsledný diagram ilustruje všechny rozumné kombinace poruch prvku a poruchových jevu, které by mohli vést ke vzniku vrcholové události. Tvurce stromu je donucen přesně popsat a představit si logiku rozvoje vzniku poruchy a tím odhalit všechny kauzální vztahy mezi prvky a poruchou. Dusledkem toho je odhalení slabých míst již ve fázi návrhu a vývoje.

Strom poruch se rozvíjí od vrcholové události dále na nižší úrovně a hledá příčiny vzniku události, která stojí v diagramu o úroveň výš. Základní kladené otázky na odhalení příčiny poruchového stavu jsou: Proč? Kdy? Kde? Co?. [1]

V dnešní době již metoda stromu poruchových stavu umožňuje analýzu dynamických systému, jakou jsou regulované systémy, systémy obsahující funkce ovládané spínači na vyžádání a podřízené systémy složitým strategiím údržby. Při realizaci metody je provedena logická posloupnost pěti základních kroku:

 Přípravná část;

 tvorba stromu poruchových stavu;

 kvalitativní analýza stromu poruchových stavu;

 kvantitativní analýza stromu poruchových stavu;

 vyhodnocení analýzy. [1]

Analýza stromu poruchových stavu je provedena buď kvalitativně anebo kvantitativně. Při kvalitativním řešení je výsledkem soupis možných kombinací provozních podmínek, podmínek prostředí, chyb lidského faktoru a provozních poruch prvku, které by mohly v kombinaci s jinou událostí vést ke vzniku vrcholové

události. Při kvantitativním postupu je výsledkem pravděpodobnost, při níž muže nastat vrcholová událost během specifikovaného intervalu. Analýzu je také možné provádět oběma postupy zároveň.

Obrázek 9: Strom poruchových stavu

7.2 Přípravná část analýzy

Základním předpokladem úspěšného vykonání analýzy jsou výborné znalosti systému, funkcí a podmínek použití. Prvním krokem musí být shromáždění všech potřebných informací o systému, díky kterým je možné analýzu kvalifikovaně provést. Tyto informace jsou:

 Konstrukční uspořádání systému;

 popis funkcí systému;

 určení rozhraní a interakcí, díky nimž je možné systém oddělit od okolí;

 předpokládané provozní režimy systému;

 předpokládaný systém údržby;

 vliv lidského faktoru na činnost systému. [1]

Při sběru informací o systému se vychází z technické dokumentace, např. výkresu, specifikací, technických popisu a provozních příruček. Ve většině případu analýze stromu poruchových stavu předcházejí analýzy spolehlivosti systému jinými metodami např. FMEA nebo FMECA. V tom případě je dobrý duvod využít výsledky těchto analýz k zahrnutí do informací o systému.

Dalším nezbytným krokem analýzy je určení vrcholové události, která bude dále zkoumána. Vrcholovou událostí často bývají události, z nichž vyplývá vznik nebo existence nebezpečných podmínek nebo události představující neschopnost systému vykonávat požadovanou funkci. Vrcholová událost musí být jasně a ne-dvojznačně vymezena. Vrcholovou událost muže zastupovat i provozuschopný stav, v takovém případě jsou zkoumány podmínky, které jsou nutně potřeba pro vykonávání požadované funkce. I přesto je však vhodnější se zaobírat poruchovým stavem, protože jeho zkoumání vede ke snadnější analýze. Diagram metody vede vždy jen k jedné vrcholové události, a proto není možné analyzovat více vrcholových událostí současně. [1] [2]

Definice vrcholové události jednoznačně popisuje zkoumanou událost, musí přesně vymezovat část systému nebo celý systém. Je duležité, aby definice nebyla příliš obecná, taková vrcholová událost by mohla vést k nejasným závěrum. Na druhou stranu nesmí být definice příliš specifická, taková definice by mohla vést k úzkému rozsahu analýzy a opomenutí duležitých prvku systému. Vrcholovou událost je třeba definovat tak, aby jednoznačně určovala, zda by vrcholová událost mohla nebo nemohla nastat. Jednomu systému je možné definovat více vrcholových událostí, avšak metoda umožňuje provádět analýzu pouze s jednou vrcholovou událostí. [1]

7.3 Tvorba stromu poruchových stavu

Strom poruchových stavu vždy vychází z vrcholové události. Rozvíjení stromu probíhá analýzou možných příčin a jejich vztahu k vrcholové události. Při tomto rozvíjení je hledána odpověď na dvě základní otázky:

 Co by mohlo být příčinou vrcholové události;

 jaká je logická vazba mezi příčinou a vrcholovou událostí.

Analýzou je tedy zkoumání všech možných bezprostředních příčin vedoucích ke vzniku vrcholové události. Příčiny to jsou nutné a postačující pro vznik vrcholové události. Výsledek analýzy je zaznamenán s pomocí logických značek. To jsou značky umožňující najít logický vztah mezi událostí a jejími bezprostředními příčinami pomocí hradel. [1]

Při dalším postupu je nutné posoudit, zda bezprostřední příčiny vrcholové události představují základní události. To je taková událost, která není dále rozvíjena a její zapříčinění nemuže být zpusobeno jinou událostí. Bývá přiřazena pouze k jednomu prvku v celém systému, muže se ale vztahovat i k nějaké skupině prvku. Jestliže je zjištěno, že se o základní událost nejedná, je možná trojí postup:

 Událost rozvíjet dále;

 označit událost jako Nerozvíjenou událost;

 označit událost jako Událost analyzovanou jinde v systému. [2]

Zvolený postup je patřičně zanesen do stromu poruch. Bezprostřední příčina vrcholové události muže být také dále rozvíjena a to stejným zpusobem jakým je rozvíjena vrcholová událost a patřičně zanesena do grafu stromu poruchových stavu.

Tento postup je opakován do té doby, než jsou nalezeny základní události systému.

Při sestavování stromu poruchových stavu je možné dojít k tomu, že se jedna rozvíjená událost vyskytuje na více místech. V tom případě je využito přenosu a tak se na místo jejího výskytu použije příslušná značka, která odkazuje na další místo, kde je událost dále rozvíjena.

Tabulka 1: Základní značky analýzy FTA

Doporučená značka Alternativní značka Název a popis

Blok s názvem nebo popisem vrcholové události.

Blok s názvem nebo popisem události s Základní dále nerozvíjená událost.

Nerozvíjená událost – událost, která není dále rozvíjena.

Událost analyzována jinde

&

Hradlo AND

1

Hradlo OR

m m/n

Zálohová struktura

7.4 Kvalitativní analýza stromu poruchových stavu

Kvalitativní analýza stromu poruchových stavu si klade za cíl nalezení všech rozumně možných kombinací faktoru provozních podmínek, podmínek prostředí, chyb lidského faktoru a poruch prvku systému, které by mohli vyvolat vznik vrcholové události. [1]

7.4.1 Kritické řezy

Kritický řez je nazývána taková nerozvíjená událost nebo konečná množina takových událostí, které když nastanou, tak vedou ke vzniku vrcholové události. [1]

Minimální kritický řez stromu poruchových stavu je nazývána taková nerozvíjená událost nebo konečná množina elementárních událostí, která když nastane tak vede k vrcholové události, ale žádná její podmnožina by ke vzniku vrcholové události nevedla.[1]

7.5 Kvantitativní analýza stromu poruchových stavu

Kvantitativní analýza stromu poruchových stavu se používá v případě, pokud jsou známy parametry spolehlivosti elementárních jevu. Cílem analýzy je určení ukazatelu, charakterizujících vrcholovou událost:

 Pravděpodobnost nastání vrcholové události v zadaném intervalu;

 pravděpodobnost nenastání vrcholové události v zadaném intervalu;

 střední doba do prvního nastoupení vrcholové události;

 střední doba nastání vrcholové události v zadaném intervalu. [1]

Při výpočtech stromu poruchových stavu jsou nejčastěji používány tři metody:

 Metoda přímého výpočtu;

 metoda minimálních kritických řezu;

 simulační metody (Monte Carlo). [1]

7.5.1 Metoda přímého výpočtu

Metoda muže být použita za předpokladu, že každý elementární jev nastane pouze jednou, tedy nevyskytuje se zde více stejných jevu. Výpočet probíhá postupným procházením logických hradel zespodu, tedy od nejnižší úrovně až po vrcholovou událost.

Při výpočtu hradla AND postupuje následovně. Máme jev G, složený s elementárních jevu Ai, které jsou jeho bezprostřední příčinou a kde S je jejich počet. Dále je známa pravděpodobnost nastoupení elementárního jevu P (Ai). Pak lze pravděpodobnost nastoupení jevu G spočítat rovnicí:

V případě použití hradla OR za stejných předchozích podmínek bude rovnice:

7.5.2 Metoda minimálních kritických řezu

Metoda předpokládá znalost množiny všech kritických řezu stromu poruch. V takovém případě je možné strom poruchových stavu transformovat na sériově paralelní blokový diagram. Každá hrana takového digramu představuje právě jeden minimální kritický řez. Potom je možné diagram řešit například pravdivostní tabulkou nebo inspekční metodou. [1]

7.5.3 Algoritmus určení minimálních kritických řezu

Nalezení úplné množiny minimálních kritických řezu umožňuje transformovat složitě strukturovanou logiku všech variant poruchy systému na jednoduchou sériově-paralelní, kterou lze řešit standardními výpočty. [1] [2]

Základní používanou metodou pro určení minimálních kritických řezu je Booleovská redukce. Ta je založena na postupném vyjadřování logiky událostí jako kombinace jednotlivých událostí na nižší úrovni stromu poruch. Metodu však nelze použít tam kde je vrcholová událost přímo závislá na časování nebo posloupnosti jevu. [1] [2]

7.5.4 Hodnocení závažnosti minimálních kritických řezu

Prvním kritériem je řád řezu (počet ruzných elementárních jevu). Řezy prvního řádu jsou obvykle závažnější než řezy druhého nebo vyšších řádu. Dalším duležitým kritériem je uvažování elementárních jevu podle závažnosti např. chyby lidského faktoru, poruchy aktivních prvku nebo poruchy pasivních prvku. Díky tomu, že pravděpodobnost pruniku jevu (jevy nastanou současně) je dána součinem, tak se s každým dalším řádem pravděpodobnost snižuje, proto se obvykle používá vyhledávání souboru minimálních kritických řezu jen do třetího nebo čtvrtého řádu.

[2]

7.5.5 Vyhodnocení analýzy

Výsledky analýzy stromu poruchových stavu je vhodné shrnout do zprávy, která by měla zahrnovat.

 Cíl a předmět analýzy;

 přehled použité technické dokumentace;

 popis systému;

 uvažované provozní režimy a podmínky prostředí;

 uvažované aspekty pusobení lidského faktoru;

 definice vrcholové události;

 vytvoření stromu poruchových stavu;

 výsledky kvalitativní analýzy;

 výsledky kvantitativní analýzy.

 závěr analýzy (vyjádření, zda systém splňuje požadavky, případné návrhy na změnu konstrukce systému, podmínek provozu, prostředí atd.) [1]

8 Analýza blokového diagramu bezporuchovosti

Logický blokový diagram je další grafický model systému viz. (obrázek 3). Prvky systému jsou označeny jako bloky. Mezi bloky vedou orientované nebo neorientované hrany, které zastupují logické vazby mezi nimi. V diagramu se nachází označení pro vstupní a výstupní bránu. Vstupní brána je označena písmenem I (input) a výstupní brána O (output) označení je možné nahradit šipkami směřujícím k bloku jako vstupní brána a od bloku jako výstupní brána. [1]

Stejně jako u analýzy FTA je i u analýzy pomocí blokového diagramu možné definovat kritické řezy a úspěšné cesty systému. Z duvodu lepšího grafického vyjádření blokové diagramy pracují s úspěšnou cestou. Nalezení úspěšné cesty se provádí pruchodem od vstupní brány po výstupní a nalezená množina prvku představuje minimální úspěšnou cestu systému. [2]

Obrázek 11: Blokový diagram

8.1 Základní typy diagramu a jejich řešení

Diagramy se dělí na základní typy:

 Sériové;

 paralelní;

 smíšený systém

 výběrový systém m z n. [2]

8.1.1 Sériový systém

Je takový systém, kdy při poruše jediného prvku dochází k poruše celého systému.

Systém je tedy v provozuschopném stavu jen tehdy, jsou-li všechny jeho prvky současně v provozuschopném stavu.

8.1.2 Paralelní systém

Nachází se v provozuschopném stavu do té doby, než dojde k současné poruše všech jeho prvku.

8.1.3 Smíšený systém

Představuje kombinaci paralelních i sériových větví. Není proto možné tak lehce určit kdy se systém nachází v provozuschopném. Proto se pro výpočet používají dva typy postupu:

 Metoda dekompozice systému;

 inspekční metoda. [1]

8.1.4 Výběrový systém m z n

V bezporuchovém stavu se nachází tehdy, kdy je v bezporuchovém stavu m z n počtu jeho komponent.

9 Údržba zaměřená na bezporuchovost

Reliability Centred Maintenance (RCM) je údržba zaměřená na bezporuchovost.

Snaží se zavést program preventivní údržby, který účelně a efektivně zajistí požadovanou bezpečnost v ekonomicky optimálních mezích.

9.1 Vstupní data

Seznam duležitých informací o systému:

 Dokumentace o zařízení;

 spolehlivostní ukazatele zařízení;

 ekonomické údaje o nákladech zařízení.

9.1.1 Dokumentace

Měla by obsahovat výkresy, popis funkcí (základní a druhořadé funkce) a stávající plán údržby. Základní funkce majetku jsou například, proč byl majetek pořízen, jakou má kvalitu, rychlost atd. liší se podle zařízení. Druhotné funkce jsou takové, kdy je očekáváno, že majetek bude vykonávat i nějaké funkce navíc. [3]

9.1.2 Spolehlivostní funkce

Jsou získávány pomocí dlouhodobého a strukturovanému sběru dat o zařízení:

 Zpusob poruchy;

 příčina poruchy;

 střední doba mezi poruchami;

 střední doba do opravy;

 doba dodání;

Proto tyto data existují alternativy:

 Data obdobných zařízení;

 kvalifikované odhady expertu.

9.1.3 Ekonomické údaje

 Pořizovací ceny zařízení;

 pořizovací ceny náhradních dílu;

 mzdy jednotlivých profesí;

 náklady na podpurné úkony;

9.2 Plánování údržby

Na základě ekonomické optimalizace je hledána varianta, která bude dlouhodobě nejlevnější. Jsou zde uvažovány lidské zdroje, náklady na náhradní díly, energie, ztráty z výroby atd. Zásahy údržby jsou rozděleny na základní typy:

 RTF (Run to Failure) provozování do poruchy;

 TBT (Time Based Task) údržba v pravidelných intervalech;

 CM (Condition Monitoring) sledování stavu zařízení

 CBT (Condtion Based Task) údržba na základě stavu zařízení.

9.2.1 RTF (Run To Failure)

Je využívána především pro zařízení, která nemají vliv na výrobu a kde se finančně nevyplatí prevence. Dále je vhodná pro zařízení, která mají konstantní dobu poruch.

Jsou známi zpusoby poruch, potřebné náhradní díly, servisní postupy a střední doba mezi poruchami. Jedná se o plánovanou poruchovou údržbu. Ziskem je kratší doba do obnovy a lépe odvedené servisní zásahy.[3]

9.2.2 TBT (Time Based Task)

Je využívána pro zařízení s normálním rozdělením pravděpodobnosti poruch a také pro zařízení se skrytými módy poruch. Jedná se o plánovanou preventivní údržbu.

Ziskem je kratší doba do obnovy, lépe odvedené servisní zásahy a méně náročné zásahy než při údržbě po poruše.[3]

9.2.3 CBT (Condition Based Task)

Je vhodná pro zařízení kde lze sledovat parametry identifikující opotřebení a pro zařízení se skrytými módy poruch. Součástí je i vždy sledování stavu zařízení CM (Condition Monitoring). Ziskem je kratší doba do obnovy a lépe odvedené servisní zásahy, méně náročné zásahy než při údržbě po poruše. Zařízení se opravuje v moment, kdy vykazuje známky degradace. Z této údržby také plyne zbytkové riziko, kdy CM neodhalí poruchu včas. [3]

9.3 Princip metody RCM

Umožňuje používat strom logického rozhodování, podle kterého zjišťuje použitelné a efektivní požadavky na preventivní údržbu dle ekonomických, provozních a bezpečnostních požadavku. Výsledkem metody je posouzení provádění určitého úkolu údržby. Princip spočívá v těchto krocích:

 Definice hranic systému;

 definice funkce systému;

 identifikace významných prvku;

 identifikace příčin poruch funkce významných prvku;

 předpověď následku poruch a pravděpodobnosti jejich výskytu;

 použití logického rozhodovacího stromu ke kategorizaci následku poruch;

 identifikace efektivních údržbových zásahu, které tvoří počáteční program údržby;

 při nemožnosti identifikace údržby proces nebo prvek přepracuje;

 zavedení dynamického procesu údržby.

9.4 Princip vypracování programu preventivní údržby

Program údržby je soubor zásahu a operací. Skládá se z počátečního programu a nepřetržitě se vyvíjejícího dynamického programu viz obrázek 4.

obrázek 12: Postup vypracování dynamického programu údržby Zdroj: [3]

9.5 Posouzení údržby

Provádí se pomocí indexu MEI, který porovnává plánovanou preventivní údržbu s provozem do poruchy a je dán vzorcem:

MEI=R_no[^Kč/rok]−R_uo[^Kč/rok]

N_pu[^Kč/rok] ₍₂₎

 MEI – index efektivnosti údržby;

 Rno – riziko neudržovaného objektu;

 Ruo – riziko udržovaného objektu;

 Npu – náklady na preventivní údržbu.

R_no[^kč/rok]= N_F[^Kč]

MTBF_No[^rok] ₍₃₎

R_uo[^Kč/rok]= N_F[^Kč]

MTBF_UO[^rok] ₍₄₎

 NF – následky poruch v korunách;

 MTBFNo – střední doba mezi poruchami neudržovaného objektu;

 MTBFUO – střední doba mezi poruchami udržovaného objektu.

Výsledky:

 MEI > 1 – údržba je ekonomicky efektivní;

 MEI ~ 1 – o údržbě je třeba rozhodnout;

 MEI < 1 – údržba není ekonomicky efektivní.

Na základě těchto výsledku je rozhodnuto, zda se údržba ekonomicky vyplatí, je třeba o ní rozhodnout nebo je údržba ekonomicky neefektivní. Například při vypočítaném indexu MEI s hodnotou 2 by došlo ke snížení ročního rizika oproti stavu, kdy zařízení není udržováno o dvojnásobek ročních nákladu na údržbu.[3]

Závěr

V první kapitole jsme si vysvětlily proč aplikace vznikla jako webová služba. Zjistily jsme, že pro rozšíření na více platforem je to výhodnější cesta než desktopová aplikace. Dále byly rozebrány použité technologie a architektura aplikace. Bylo popsáno proč je použitá architektura výhodná a z jakých součástí se musí skládat. Na základě této architektury byly zmíněny i základní komponenty, které bylo nutno použít pro správný běh aplikace. Mezi hlavní komponentu lze jistě zařadit generátor pseudonáhodných čísel, který byl na základě svých vlastností vybrán. Z duvodu nutnosti ukládání dat, byla popsána databáze pro jejich ukládání. Zmíněn je její návrh, vazby mezi jednotlivými prvky a ukládaná data. Protože, do aplikace nemá mít přístup libovolný člověk, tak je rozebrána registrace a přihlášení. U těchto kapitol je vysvětlen duvod vynucených údaju pro registraci jejich popis a stručně je zmíněno fungování úpravy hesla. Jako každou webovou aplikaci je potřeba i tuto ochránit před případným útokem. Proto jsou zmíněny dva nejčastější útoky a ochrana proti nim. Celé aplikace má za cíl zadávat a kontrolovat semestrální práce tomu to tématu byly věnovány následující tři kapitoly. Kde je stručný popis zadání jednotlivých úloh jejich zpracování a popis algoritmu sloužící pro ověření správného výsledku.

Aplikace poskytuje rozhraní pro vyučujícího. Popsána jsou všechna data, která se vyučujícímu zobrazují a jejich struktura. Funkce automatické opravy se nachází taktéž v rozhraní pro vyučující.

SEZNAM POUŽITÉ LITERATURY

[1] Technická univerzita v Liberci, Řízení jakosti a spolehlivosti [online]. [vid. 1. 3.

2014]. Dostupné z: http://www.rss.tul.cz/index.php?

page=studium/predmet&zkratka=rjs

[2] Prof. Ing. R. Holub, CSc., Doc. Ing. Z. Vintr, CSc., Spolehlivost letadlové techniky. Elektronická učebnice [online]. Brno: Vysoké učení technické v Brně, 2001

[vid. 1. 3. 2014].

Dostupné z: http://lu.fme.vutbr.cz/files/SpolehlivostLetadloveTechniky.pdf

[3] ČSJ. Údržba zaměřená na bezporuchovost [online]. 17. vyd. Praha: Česká společnost pro Jakost, 2004-11-01 [vid. 2014-03-03].

Dostupné z:

http://www.csq.cz/fileadmin/user_upload/Spolkova_cinnost/Odborne_skupiny/Sp olehlivost/Sborniky/17_RCM.pdf

[4] W3Schools. PHP5 Tutorial [online]. [vid. 20. 4. 2014].

Dostupné z:http://www.w3schools.com/php/default.asp

[5] PHP. PHP Documentation [online]. [vid. 14. 4 . 2014].

Dostupné z: http://www.php.net/docs.php

[6] W3Schools. HTML4 and HTML5 Tutorial. [online]. [vid. 14. 3. 2014].

Dostupné z: http://www.w3schools.com/html/default.asp

[7] PHP. PDO Drivers [online]. [vid. 14. 4. 2014].

Dostupné z: http://www.php.net/manual/en/pdo.drivers.php