VŠB – Technická univerzita Ostrava Fakulta elektrotechniky a informatiky
Katedra informatiky
Absolvování individuální odborné praxe Individual Professional Practice in the
Company
2016 Petr Nowak
Rád bych na tomto místě poděkoval kolegům a svému konzultantovi ze společnosti ArcelorMittal Ostrava, panu Radimu Lužnému RNDr., za umožnění vypracování bakalářské práce. Dále panu doc. Dr. Ing. Eduardovi Sojkovi za cenné rady při tvorbě práce. Děkuji také své rodině a přátelům za podporu při studiu.
Abstrakt
Tato bakalářská práce se zabývá průběhem individuální odborné praxe ve společnosti Arcelor- Mittal Ostrava a.s. Cílem praxe bylo vytvořit nový informační systém pro struskové hospodářství založený na moderních technologiích a nahradit již nevyhovující starý systém. Práce obsahuje vyjádření k výběru absolvování praxe, krátký popis odborného zaměření společnosti, její histo- rie a mého pracovního zařazení. Následuje popis a řešení požadované funkcionality na systém, včetně řešení vyskytlých problémů. V závěru práce je uveden osobní přínos z praxe.
Klíčová slova: praxe, ArcelorMittal, Vážní systém, .NET, C#
Abstract
This bachelor thesis deals with the process of individual professional practice in the ArcelorMittal Ostrava Inc. The aim was to create a new information system for slag economy based on modern technologies and to replace the old inconvenient system. This thesis includes reason why I have chosen the practice, a brief description of the specialization of the company, its history and my job title. Followed by a description and a solution of the required functionality for the system, including solution of appeared problems. At the conclusion of the work is described my personal benefit of practice.
Key Words: practice, ArcelorMittal, Weight system, .NET, C#
Obsah
Seznam použitých zkratek a symbolů 8
Seznam obrázků 9
Seznam tabulek 10
Seznam výpisů zdrojového kódu 12
1 Úvod 12
2 Odborné zaměření společnosti 13
2.1 Historie . . . 13
3 Odborné zaměření studenta 14
4 Zadání 15
4.1 Základní specifikace . . . 15
5 Řešení 17
5.1 Řešení základní specifikace . . . 17 5.2 Dodatečná funkcionalita . . . 23 5.3 Vlastní iniciativa . . . 27
6 Závěr 29
Literatura 30
7
Seznam použitých zkratek a symbolů
AMO – ArcelorMittal Ostrava
ASCII – American Standard Code for Information Interchange
COM – Component Object Model
ERP – Enterprise Resource Planning
GUI – Graphical User Interface
MVVM – Model–View–Viewmodel
SQL – Structured Query Language
TFS – Team Foundation Server
T-SQL – Transact Structured Query Language
WPF – Windows Presentation Foundation
XAML – Extensible Application Markup Language
XML – Extensible Markup Language
8
Seznam obrázků
1 Vizualizace komunikace s periferiemi . . . 19
2 Tvorba dodacích listů . . . 22
3 Seznam zákazníků . . . 23
4 Validace formuláře . . . 25
5 Testovací aplikace . . . 28
9
Seznam tabulek
1 Tiskové kódy [4] . . . 22
10
Seznam výpisů zdrojového kódu
1 Zpracování vstupů jedné váhy . . . 18 2 Uzavření Excelu – Windows procesy . . . 20 3 Uzavření Excelu – Uvolnění COM objektů . . . 21
11
1 Úvod
Tato bakalářská praxe byla vykonána ve společnosti ArcelorMittal Ostrava a.s., kde jsem bri- gádně pracoval již 2 roky, a proto jsem zde volil možnost vykonání bakalářské praxe.
Za tuto dobu mi bylo umožněno pracovat na vícero různorodých projektech. Cílem práce však nebude popis všech úkolů, na kterých jsem se během těchto dvou let podílel, ale pouze prvního, který byl zároveň nejobsáhlejší. Týká se návrhu a realizace informačního systému pro struskové hospodářství.
Druhá kapitola je věnována popisu společnosti, její působení, zaměření a krátce o její historii v celosvětovém měřítku a v České republice. Třetí kapitola je věnována mému zařazení v této společnosti. Čtvrtá kapitola obsahuje zadání a nastiňuje základní specifikace kladené na systém.
Pátá kapitola se zabývá řešením dílčích částí systému od základních po další rozšíření a popisuje také řešení určitých problému vzniklých při tvorbě systému. Závěrem jsou shrnuty přínosy z praxe, znalosti ze studia, které mi scházely v průběhu praxe a které mi naopak pomohly.
12
2 Odborné zaměření společnosti
ArcelorMittal je největším světovým výrobcem oceli a těžební společností s roční výrobní ka- pacitou přibližně 115 miliónů tun surové oceli a s více než 220 tisíci zaměstnanci napříč 60 zeměmi. Díky těmto faktům je lídrem na všech hlavních trzích s ocelí, včetně automobilového průmyslu, stavebnictví, domácích spotřebičů, výroby obalů a energetiky. Dále zaujímá přední místo v čele výzkumu a vývoje výroby oceli s 12 hlavními výzkumnými centry po celém světě, kde zkoumají čistší produkci a ekologičtější výrobky, které mají nižší negativní dopad na ži- votní prostředí. Mezi další zajímavosti patří fakt, že společnost usiluje o zlepšování ovzduší na Ostravsku například výstavbou odprašovacích filtrů. [1]
2.1 Historie
ArcelorMittal tak jak je znám dnes, vznikl v roce 2006, kdy došlo k převzetí lucemburské oce- lářské firmy Arcelor indonéskou společností Mittal Steel Company. Historie vývoje společnosti však spadá až do roku 1976.
V České republice se začala psát historie této společnosti již v roce 1942, tehdy Vítkovické železárny. Vzhledem k umístění železáren ve městě započala stavba jižního závodu v Kunčicích, která také spadala pod Vítkovické železárny. O pár let později proběhlo osamostatnění závodu v Kunčicích a vznikla Nová Huť Klementa Gottwalda. Během několika dalších let se uskuteč- nilo rozšíření o nové závody a jejich následnou modernizaci. V roce 2003 odkoupil Novou Huť, za účelem restrukturalizace a modernizace, Lakshmi Mittal. Následně pak došlo, v rámci vzniku společnosti ArcelorMittal, i k přejmenování ostravské společnosti na ArcelorMittal Ostrava. [2]
13
3 Odborné zaměření studenta
O odbornou placenou stáž, pro vysokoškolské studenty, ve společnosti AMO jsem se ucházel na základě inzerátu na pozici programátora, umístěném na stránkách společnosti. Po dokončení výběrového řízení, které probíhalo formou testu a krátkého pohovoru, přijali celkem 3 studenty včetně mě. Po následném rozhovoru s panem Radimem Lužným RNDr., který je zároveň mým konzultantem k bakalářské práci, jsme byli všichni tři přiřazeni na oddělení informačních tech- nologií pro závod Vysoké pece, kde jsme se setkali s dalším spolupracujícím a naším mentorem panem Ing. Daliborem Stehlíkem, od kterého jsme se podrobněji dozvěděli, na čem budeme pracovat a jaké konkrétní technologie budeme k vypracování řešení používat.
Po úvodním bezpečnostním zaškolení a získání přístupových údajů do systému, jsem se mohl se svými kolegy, studenty Bc. Michalem Rudinským a Mgr. Martinem Bagierem, pustit do práce.
14
4 Zadání
Naší úlohou bylo navrhnout a realizovat kompletně nový informační systém na aktuálních tech- nologiích pro struskové hospodářství Vysokých pecí v oblasti prodeje vysokopecní strusky.
Důvodem byla potřeba nahradit současnou verzi informačního systému Lesyco, která již nesplňuje dnešní požadavky na informační systém s ohledem na bezpečnost, podporu a další rozvoj a usnadnit a urychlit práci se systémem, jelikož obsahoval i nepotřebnou funkcionalitu.
Informační systém Lesyco byl provozován na již nepodporovaném hardwaru a operačním sys- tému Windows 98, naprogramován v jazyce Delphi verze 5 a pro ukládání dat sloužila databáze Paradox, ke které se přistupovalo za pomocí Borland Database Engine. Proto dalšími hlavními faktory bylo využití modernějších technologií pro tvorbu softwaru.
Na základě korporačních pravidel je předpokladem operační systém Windows 7 64bit. Vzhle- dem k požadavkům zadavatele bylo v první verzi informačního systému zvoleno jako hlavní datové úložiště MS Access. V druhé verzi je již použit MS SQL Server 2014. Jako technologická platforma byl zvolen .NET Framework 4.0, s použitím programovacího jazyka C#. Díky těmto technologiím je nyní umožněno systém jednoduše upravovat dle nových požadavků a rozšiřovat jej o další funkcionalitu.
4.1 Základní specifikace
Za účelem zpracování uživatelských požadavků na nový informační systém proběhlo několik schůzek s klíčovým uživatelem a seznámením se s pracovními postupy na daném pracovišti.
Na základě těchto konzultací byly také stanoveny některé z následujících základních vstupních specifikací, pro tvorbu tohoto informačního systému. Další funkcionalita byla řešena v průběhu tvorby systému.
4.1.1 Vizuální vzhled
Jedním z požadavků klíčového uživatele bylo zachování podoby uživatelského ovládání. Dále bylo nutné zohlednit požadavek na odstranění již nepotřebných funkcionalit. Vzhledem k těmto požadavkům byl vytvořen slepý formulář s minimem interakcí pro odzkoušení uživatelem. Po několika iteracích byla klíčovým uživatelem odsouhlasena finální podoba formuláře.
4.1.2 Komunikace s řídícími zařízeními
Původní systém byl propojen s řadou dalších systémů, ale také periferních zařízení. Tyto sku- tečnosti bylo nutné zohlednit také při návrhu nového systému. Jednalo se především o váhy, světelnou signalizaci a optická čidla kontrolující pozici umístění vozidla na váze. Zpracování jejich vstupních a výstupních dat za účelem dalšího použití a jejich vizuálního zobrazení byly nedílnou součástí systému. Nicméně vzhledem k stáří systému, což činí přibližně 15 let, už nebyly
15
nikde k dispozici žádné informace o tom, jaká data jsou přenášena mezi jednotlivými zařízeními a systémem, řešení tohoto problému dále popisuji v kapitole 5.1.2.
4.1.3 Tvorba reportů
Reporty jsou tvořeny dle zadaného období jako exporty dat do Excelu a jsou rozděleny do ně- kolika kategorií, kde se u každé kategorie nabízí možnost volby detailů. Tato volba přidá do vý- sledného reportu detailnější informace.
• Celkem: Celkový počet zvážených tun materiálu a celková suma.
Detail: Seznam jednotlivých vážení.
• Materiál: Seznam materiálů na jednom listu s počtem zvážených tun a cenou ke každému z nich.
Detail: Každý materiál je oddělen do samostatného listu, kde listy obsahují jednotlivá vážení daného materiálu.
• Zákazník: Seznam zákazníků na jednom listu s počtem zvážených tun a cenou ke každému z nich.
Detail: Každý zákazník je oddělen do samostatného listu, kde listy obsahují jednotlivá vážení zákazníka.
• Materiál zákazníka: Seznam zákazníků a celkové sumy vážení jimi vybíraných materiálů.
Detail: Rozdělení do listů dle zákazníka a materiálu, kde listy obsahují jednotlivá vážení zákazníka a daného materiálu.
4.1.4 Tvorba dodacích listů
Prodej materiálů je umožněn pouze firmám, které mají uzavřenou smlouvu na dané období. Fak- turace probíhá na jiném místě a proto hlavním prvkem systému, se kterým uživatel interagoval, byla tvorba dodacích listů.
Dodací listy slouží jako doklad o provedení nákupu a jako doplněk pro následnou fakturaci.
Obsahem tohoto dokumentu je číslo smlouvy, firma, jméno řidiče, SPZ, místo určení, materiál a váhy v tunách – Tara, Brutto, Netto.
Samozřejmostí pak také bylo zajištění tisku dodacích listů na jehličkové tiskárně, připojené přes paralelní port.
4.1.5 Správa dat
Systém měl také umožňovat evidenci a správu dat. Evidovaná data se týkala například vydaných dodacích listů, firem, u kterých mělo jít rozlišit, jestli má nebo nemá uzavřenou smlouvu v daném období, řidičů, vozidel, prodávaných materiálů a identifikačních karet.
16
5 Řešení
Největší část práce na novém systému probíhala v budově vedení závodu Vysoké pece. Samo- zřejmostí bylo občasné testování a finální nasazení přímo v areálu struskárny, který se nachází v Kunčičkách, to znamená mimo hlavní areál AMO, zde nás přepravovali služebním automobi- lem.
Nejprve nám byly přiděleny nové počítače a dostali jsme za úkol nainstalovat operační systém Windows 7. Dále pak potřebný software k vývoji, který zahrnoval Visual Studio 2013, Microsoft Office, ze kterého jsme využívali hlavně Excel a Access, SQL Server Management Studio a pro správu a sdílení kódu nám bylo umožněno založit TFS, což bylo nezbytnou součástí pro práci v týmu a také vhodná volba ve spojení s Visual Studiem.
Po úvodním seznámení se s provozem v areálu struskárny, jsme dostali k dispozici materi- ály starého systému, které obsahovaly veškeré zdrojové kódy a databázi. Tyto materiály nám inspirativně posloužily, avšak neznalost jazyka Delphi a velice zajímavá struktura kódu celkem ztěžovala orientaci a pochopení.
Celkový vývoj informačního systému byl převážně v naši režii, takže i jaké postupy zvolíme, bylo na nás. I na programování dílčích částí systému jsme se vždy domlouvali. Nicméně každý z nás se do jisté míry zapojil i ke zpracování ostatních částí. Já osobně jsem se z počátku zaměřil na tvorbu komunikace se všemi řídícími zařízeními a počítačem, kde běžel tento systém.
5.1 Řešení základní specifikace
V této části popíši řešení základní funkcionality systému, bez které by tento systém nemohl být nasazen do ostrého provozu.
5.1.1 Vizuální vzhled
Při volbě technologie, kterou použijeme pro vytvoření GUI, jsme si mohli v zásadě vybrat mezi WinForms a WPF. Po krátkém zkoušení co obě technologie umožňují a jak se s nimi pracuje, jsme zvolili WPF.
Protože se jedná o novější, flexibilnější a efektivnější technologii, kde se k popisu grafic- kého rozhraní v aplikaci využívá značkovacího jazyka XAML, vyvíjeném společností Microsoft a založeném na jazyce XML, proto je také kód GUI mnohem přehlednější a čitelnější.
Dále díky tomu, že lze využít takzvaného Data Bindingu, což je v kontextu .NET metoda, která umožňuje obousměrné propojení ovládacích prvků GUI s datovými zdroji. A proto je také architektura větší části systému založená na softwarovém architektonickém vzoru MVVM, díky kterému se nabízí řešení oddělení logiky aplikace od uživatelského rozhraní.
17
5.1.2 Komunikace s řídícími zařízeními
Nejprve jsme museli analyzovat datové toky mezi navrhovaným systémem a dalšími systémy, ale také periferními zařízeními jako váhy, semafory apod. Pro odchytnutí příchozích dat jsme využili aplikaci PuTTY, kde jsme nastavili příslušný sériový komunikační port a v konzoli této aplikace se nám pak zobrazovala příchozí data. Na první pohled bylo patrné, že některá data přicházejí v určitých intervalech a některá například po sejmutí karty čtečkou, nebo po změně barvy semaforu tlačítkem v aplikaci. Samozřejmě nebylo zcela jasné, co která data znamenají a k čemu bychom je měli přiřadit, protože se data zobrazovala pouze jako sekvence bajtů. To samé platilo i v případě příchozích dat z obou vah.
Zjistili jsme také, že při vypnutém systému některá data nepřicházejí. To nás dovedlo k myš- lence, že některá data přicházejí pouze jako odpověď na nějaký požadavek ze systému.
Následně jsme tato data, pro větší přehlednost, převedli z bajtové formy na znaky a zanaly- zovali je. Podařilo se nám tak zjistit příslušné sekvence dat, které k sobě patří.
Ovšem scházela nám data, která se posílají směrem k zařízením. Tato data se nám podařilo získat rozluštěním Delphi kódu starého systému. Z kódu jsme také zjistili, k čemu se využívají příslušné bajty v sekvencích příchozích i odchozích dat a také dle jakých parametrů, například parita a přenosová rychlost, je nutné programově nastavit sériové porty, aby komunikace pro- bíhala správně. Nyní jsme měli k dispozici veškerá data týkající se komunikace se zařízeními a mohli jsme je dále zpracovávat.
Na následujícím kódu můžete vidět, jakým způsobem probíhalo zpracování vstupů z vah.
Zpracování dat ze čteček karet, semaforů a světelných závor bylo trochu složitější, vzhledem k tomu, že na jeden sériový port přicházelo vícero druhů sekvencí dat. Nicméně princip je podobný. V podstatě stačilo přidat podmínku rozlišující sekvenci dle koncového znaku dané sekvence.
List<int> ReceivedBytes = new List<int>();
void ReceiveEvent(SerialPort port, SerialDataReceivedEventArgs e) {
while (port.BytesToRead > 0) {
int receivedByte = port.ReadByte();
ReceivedBytes.Add(receivedByte);
// 3 - ukoncovaci byte sekvence if (receivedByte == 3)
{ // 2 - pocatecni byte sekvence
if (ReceivedBytes.Count == 11 && ReceivedBytes[0] == 2) {
//Konverze sekvence bajtu na retezec pro dalsi zpracovani a odstraneni nepotrebnych znaku.
18
string str = ConvertToString(ReceivedBytes);
if (Regex.IsMatch(str, "(1[02]8[ -])[0-9]{5}")) {
//Pouziva se pro zjisteni ustalenosti vahy.
this.WeightPrefix = str.Substring(0, 3);
//Ziskani ciselne hodnoty vahy v tunach.
str = str.Substring(3);
this.Value = Convert.ToInt32(str);
//Vizualni aktualizace vahy.
UpdateWeightText(str);
} }
ReceivedBytes.Clear();
} } }
Výpis 1: Zpracování vstupů jedné váhy
U automatického posílání dat směrem k semaforům, za účelem přepínání barvy na zelenou při sejmutí karty, docházelo občasně k chybě, kdy se semafor na zelenou nepřepnul. Nejspíše mohlo docházet k přehlcení sériového portu, ztrátě dat po cestě k zařízení, nebo ke kolizi při využití tohoto portu, neboť se tento port využíval i k cyklickému požadavku pro zjištění v jakém stavu se nachází semafory a optické závory.
Obrázek 1: Vizualizace komunikace s periferiemi
19
Problém jsem se nejprve snažil vyřešit přidáním tří stejných příkazů pro přepnutí na zelenou ihned za sebou. Tohoto řešení jsem si všiml i v kódu starého systému. Po následujících konzulta- cích s pracovnicí na struskárně, jsem zjistil, že se situace zlepšila, nicméně chyba se vyskytovala i nadále. Pracovnice sice má možnost přepínat semafor manuálně, ale mělo by se to dít auto- maticky a ne vždy si mohla všimnout, že vozidlo stále stojí na červené a celkový provoz je tak brzděn. Proto mě napadlo směrovat veškerou komunikaci na tomto portě směrem k zařízením do fronty. Z fronty se poté data posílají na port v krátkých časových intervalech. Díky tomuto řešení již tato nepravidelná chyba vymizela.
5.1.3 Tvorba reportů
Pro tvorbu reportů jsme použili .NET knihovnuMicrosoft.Office.Interop.Excel. Tato knihovna umožňuje interakci s takzvanými COM objekty, které poskytuje objektový model Excelu. Tento model se podobá uživatelskému rozhraní Excelu tedy: Aplikace – Sešit – List -– Oblast. Aplikační objekt reprezentuje celou aplikaci a každý Sešit obsahuje kolekci Listů. Pro práci s individuálními buňkami nebo skupinami buněk pak slouží objekt Oblast. [3]
Samotná práce s Excelem týkající se vytváření sešitů, formátování a získávání či vkládání dat do buněk, je celkem jednoduchá, a to i vzhledem ke špatné oficiální dokumentaci. Na internetu se totiž dá najít spousta ukázek a návodů.
Avšak narazili jsme i na problém, týkající se ukončování Excelu. V běžících procesech ope- račního systému totiž zůstával stále spuštěn proces Excelu a to i po ukončení vážního systému.
processesBefore = Process.GetProcessesByName("excel");
//...
//... Vytvoreni noveho Excelu a export...
//...
processesAfter = Process.GetProcessesByName("excel");
foreach (Process process in processesAfter) {
if (!processesBefore.Select(p => p.Id).Contains(process.Id)) {
process.Kill();
break;
} }
Výpis 2: Uzavření Excelu – Windows procesy
Tento problém způsobují dané COM objekty, se kterými se pracovalo. Bohužel je nutné ob- jekty manuálně uzavírat. Pro úplné zavření Excelu jsme se dohledali několika způsobů. V ukázce kódu 2 je vidět první způsob, který jsme používali. Ovšem později nám přišel nevhodný, vzhle-
20
dem k nutnosti procházet procesy operačního systému a dle názvu „excel“ vyhledat ten správný proces, který je zapotřebí ukončit.
Proto jsme zvolili jiný způsob, ve kterém se sice musí uvolnit každý COM objekt manuálně, nicméně přišlo nám to jako korektnější způsob. Důležité pak také bylo dát si pozor nepoužívat
„dvě tečky s COM objekty.“ 3 void ReleaseCom(object obj) {
try { Marshal.ReleaseComObject(obj); } finally
{
obj = null;
GC.Collect();
GC.WaitForPendingFinalizers();
} }
Výpis 3: Uzavření Excelu – Uvolnění COM objektů
Další problém se týkal výkonu tvorby reportů. Na našich pracovních počítačích trvalo vy- tvoření Excelu a naplnění větším množstvím dat, tedy dat zhruba za jeden kvartál, přibližně minutu. Což nám nepřišlo až tak špatné. Ovšem při testu na počítači na struskárně, který byl méně výkonný, trvala tvorba asi 15 minut, což je opravdu dlouhá doba a bylo s tím potřeba něco udělat.
Výkonnostní problém způsobovala jednak hlavička v každém listu Excelu, která se při vytvo- ření dalšího listu znova vyplňovala a formátovala. Pomohlo vytvořit jí pouze v prvním listu a do dalších listů pak již kopírovat celou zformátovanou oblast. A dále pak pro jednotlivé záznamy bylo zapotřebí je zapsat po větším množství do oblasti daného listu a nezapisovat je po řádcích.
5.1.4 Tvorba dodacích listů
Pro rychlou tvorbu dodacích listů byl vymyšlen mechanizmus, kdy se při postupném vybírání údajů následující výběr vždy filtroval vzhledem k předcházejícím nákupům. Vážní údaje byly vybrány na základě čísla karty, zvolil se materiál, zákazník dle čísla smlouvy a následné údaje se již filtrovaly postupně vzhledem k dané firmě, SPZ vozidla a jména řidiče. Pokud například SPZ nebyla evidována, objevil se při jejím zadávání formulář pro přidání do databáze.
Po vyplnění všech údajů má uživatel možnost tyto údaje zkontrolovat v přehledu dodacího listu, který se nachází hned vedle vyplňovacího formuláře. Následně po stisknutí tlačítka pro tisk, se vytiskne dodací list na jehličkové tiskárně a do databáze se uloží nové záznamy.
Pro práci s jehličkovou tiskárnou jsme využili externího zdrojového kódu, který dynamicky mapoval základní funkcionalitu na winspool.drv, neboli Windows Spooler Driver a umožňoval
21
tak v C# jednoduše vytvořit tiskový dokument a tisk výsledného zformátovaného textového řetězce.
Obrázek 2: Tvorba dodacích listů
Dalším krokem bylo zajistit správné zakončení tiskové oblasti pro následovné utrhnutí papíru a opětovné zajetí zpět na pozici pro další tisk, protože toto tiskárna nezajišťovala sama. Po průzkumu nastavení přímo na tiskárně jsme nedocílili potřebné funkcionality. Zjistili jsme ale, že lze programově posílat na začátku a na konci tisku řídící kódy tiskárny. Toho jsme také využili a po použití správných kódů 1 uvedených v internetové dokumentaci tiskárny, jsme docílili korektního tisku.
Tabulka 1: Tiskové kódy [4]
Dekadické číslo ASCII Popis
Začátek tisku 27 67 48 06 ESC C 0 6 Nastaví délku stránky na 6 palců.
27 120 48 ESC x 0 Draft Mode - rychlejší tisk.
Konec tisku 12 FF
Form Feed - Speciální znak, který zajistí, že stránka automaticky vyjede na pozici
pro odtrhnutí.
22
5.1.5 Správa dat
Možnosti správy dat jsme v grafickém rozhraní rozdělili do jednotlivých karet dle databázových tabulek. Zobrazení dat je řešeno pomocí GUI elementu DataGrid. V zásadě je skoro u všech tabulek umožněno přidávat nové záznamy, vyhledávat dle určitých parametrů a editovat již vytvořené záznamy po kliku do vybrané buňky na řádku. Ovšem u některých sloupců bylo nutné zamezit editaci, to se hlavně týká tabulky již vytvořených dodacích listů.
V případě firem je například umožněno zobrazení pouze aktivních smluv. Při spuštění apli- kace se dle aktuálního data a data platnosti smlouvy, automaticky zkontrolují tyto smlouvy a v případě neplatnosti se deaktivují.
Deaktivační kontrola probíhá také při importu nových smluv z Excelu. Tvorba tohoto Ex- celu již nebyla v naší kompetenci, na nás bylo pouze zvolit, jaké informace by měl obsahovat a jakou by měl mít strukturu. Výsledný Excel byl získán formou exportu z podnikového ERP systému. Při importu tohoto Excelu do vážního systému bylo opět nutné dbát na problémy práce s Excelem v .NET, které již byly zmíněny v kapitole 5.1.3. Import probíhal na základě ověřování ID zákazníka, pokud již zákazník existoval v databázi systému, aktualizoval se na nové hodnoty, jinak se vytvořil nový záznam.
Obrázek 3: Seznam zákazníků 5.2 Dodatečná funkcionalita
Obsahem této kapitoly je dodatečná funkcionalita vážního systému, která byla vyžádána v prů- běhy tvorby systému.
23
5.2.1 Záznam dat za účelem analýzy
Dalším požadavkem na systém bylo vytvořit logování informací o činnosti a běhu vážního sys- tému. Ukládání informací probíhá do tří textových souborů.
• Databázový log – Zde se ukládají veškeré proběhlé příkazy nad databází, které ji nějakým způsobem modifikují, to znamená INSERT, UPDATE, DELETE. Ke každému záznamu se přidává příznak, zdali se jedná o ruční modifikaci, nebo systémovou a také jméno osoby přihlášené do systému.
• Vážní log – Do tohoto souboru se ukládají záznamy o snímaných identifikačních kartách a váze, včetně aktuálního data.
• Chybový log – Jedná se o chybový soubor, v němž se nacházejí veškeré možné vzniklé chyby aplikace. Tento log posloužil hlavně při vzniklých chybách v ostrém provozu systému, které jsme mohli následně opravit.
5.2.2 Přihlášení a práva
Přihlášení do systému probíhá formou přihlašovacího formuláře, ve kterém se zvolí uživatel, který pak zadá své heslo. Jména uživatelů jsou načtena z databáze na základě přihlášeného účtu v operačním systému Windows. To znamená, že pod jedním Windows účtem existuje více systémových účtů. Každý účet má pak svá práva, na základě kterých jsou danému uživateli povoleny přístupy k jednotlivým funkcionalitám systému. Práva se dělí do následujících kategorií, kde kategorie s vyšším stupněm má i práva nižších stupňů.
1. Spuštění aplikace, prohlížení dat a tvorba reportů 2. Obsluha vážních zařízení
3. Tvorba dodacích listů 4. Manipulace s daty 5. Nastavení systému
5.2.3 Aktualizace systému
Pro aktualizaci systému na novou verzi jsme použili již hotovou interní knihovnu. Jejíž funkcio- nality jsme využily při úplném startu systému, kdy se zavolá metoda, která dle zadané ftp cesty na server zkontroluje, zdali je nová verze porovnáním souboru na základě hašovací funkce, včetně kontroly ostatních přidružených souborů v daném kořenovém adresáři. Jako další parametr této metody byla například možnost zobrazit „loading bar“.
O úspěchu nebo neúspěchu aktualizace dávala metoda vědět několika druhy výjimek, které bylo nutné ošetřit. Nás však zajímaly dvě hlavní výjimky a to, jestli je zadaná správná cesta
24
do daného kořenového adresáře a dále pak výjimka, která indikovala, zda je, nebo není potřeba restartovat aplikaci.
5.2.4 Nastavení a konfigurační soubor
Dalším prvkem byla možnost nastavení systému. Veškerá nastavení byla ukládána do dvou kon- figuračních souborů.
První konfigurační soubor sloužil pro uživatelská nastavení, která se dala měnit přímo v aplikaci. Tento soubor se také automaticky ukládal do uživatelské složky aplikace skryté v „AppData“.
Druhý konfigurační soubor obsahoval aplikační nastavení a nacházel se přímo u spustitelného souboru aplikace.
Nastavit lze například všechny tři sériové porty bez nutnosti restartovat systém, cesty k logovacím souborům, ke složce kde se ukládají vytvořené reporty, dále cesta pro sdílený soubor a cesta k datovému zdroji. Nastavit se také dají administrativní údaje o společnosti ArcelorMittal a doplňující řádky k tisku dodacích listů.
5.2.5 Validace formulářů
Při ručních vstupech, týkajících se editace nebo přidávání nových záznamů ve formulářových oknech jsme již samozřejmě měli vytvořenou určitou validaci vstupních dat. Ovšem tato validace dávala o sobě vědět vyskakovacími okny po potvrzení formuláře. Někdy se stalo, že i když byla vstupní data v nesprávném formátu, po potvrzení formuláře se neobjevila žádná chyba ani žádné okno indikující nesprávná data. Data se sice do databáze neuložila, ale uživatel si mohl myslet, že daný záznam vytvořil korektně.
Obrázek 4: Validace formuláře
25
Proto jsme přidali do všech formulářů vizuální zobrazení chyb k daným textovým kompo- nentám a potvrzení formuláře bylo umožněno, pouze pokud byla všechna data správně zadaná.
Jednotlivé grafické komponenty formuláře, například TextBox a jeho property Text, byly vázané na properties ve třídě pojmenované ErrorHandler, která pak validovala text při každé jeho změně. Chyba validace se pak zobrazovala jako červený čtvereček s vykřičníkem vedle dané komponenty. Toho bylo docíleno přiřazením předdefinované kontrolní šablony jakožto chybová šablona k dané komponentě. Chybová hláška se pak zobrazovala jako Tooltip po najetí myší na červený čtverec. Formulářové tlačítko pro potvrzení muselo mít vázanou property z ErrorHandleru, která indikovala výskyt chyb ve formuláři. Tlačítko se pak automaticky povo- lovalo, nebo blokovalo.
5.2.6 Funkcionalita s jednou vahou v provozu
Systém pracuje ve výchozím stavu se dvěma váhami. Ovšem dostali jsme za úkol vymyslet me- chanizmus, který by umožnil pracovat pouze s jednou váhou pro oba směry, tj. průjezd prázdného vozidla do areálu a potom průjezd zpět s nákladem. Občas se totiž stane, že jedna váha nemusí fungovat. Provoz sice stále pokračuje, ale je dost zpomalen vzhledem k potřebě zadávat váhu naloženého vozidla ručně do systému. Pracovník tak musí být velmi soustředěn a dle kamerového systému sledovat každé vozidlo, které přijede s nákladem na váhu, tuto váhu nejprve zapsat na papír, kvůli nevědomosti o kterého zákazníka se jedná a až po příchodu zákazníka může dle identifikační karty zapsat váhu do systému a následně vytvořit a vytisknout dodací list.
Vymysleli jsme proto mechanizmus, díky kterému stačí v systému zaškrtnout políčko, in- dikující že je v provozu pouze jedna váha, s tím že nezáleží na tom která, to vše je vyřešeno programově.
Z přijatých dat ze čtečky karet víme, že se jedná o čtečku umístěnou na dané váze, díky tomu můžeme získat hodnotu váhy a také víme, který semafor přepínat mezi zelenou a červenou.
Ovšem mohou nastat následující situace, které bylo zapotřebí ošetřit.
Protože čtečka mohla sejmout danou kartu i několikrát za sebou, mohla by nastat situace, že by se nejprve vytvořil záznam s váhou Tara a hned na to by se zapsalo i Brutto, které by vlastně mělo stejnou hodnotu jako Tara. Proto se v paměti drží záznam o poslední kartě a v případě že se jedná o stejné číslo karty jako předchozí číslo karty, neprovede se nic.
Ovšem toto řešení vede k dalšímu problému, mohla by klidně nastat situace, i když je to nepravděpodobné, že by v daném dni projelo pouze jedno vozidlo. Tím pádem by metoda, která zajišťuje funkcionalitu jedné váhy, nikdy nevytvořila záznam s váhou Brutto, protože předchozí číslo karty je stejné jako aktuálně sejmuté. Tento problém byl vyřešen přidáním časovače, který po pár minutách nastaví poslední uložené číslo karty na nulu. Časovač se vždy opět resetuje při sejmutí další karty. Díky tomuto řešení lze používat příjezdovou, nebo odjezdovou váhu samostatně pro zvážení nenaloženého i naloženého vozidla. Vhodné potom také je, aby řidič na váhu vjel ve správném směru, aby mohl jednoduše přiložit kartu ke snímači a aby viděl, zdali se mu přepnul semafor.
26
5.3 Vlastní iniciativa
Následující funkcionalitu jsem měl možnost jakožto svoje nápady implementovat do tohoto sys- tému.
5.3.1 Notifikace
Notifikace slouží k oznamování určitých událostí v systému. Například oznámení špatné pozice vozidla na váze, neustálené váhy při sejmutí karty, různých chyb v systému, nebo informačních zpráv o provedených úkonech uživatele. Notifikace se dělí do následujících kategorií.
• Informační notifikace
• Notifikace o úspěchu dané akce
• Varovná notifikace
• Chybová notifikace
Ve WPF jsou implementovány za pomocí komponenty ItemsControl a její položky pak vy- užívají DataTemplate šablony, která umožňuje díky Bindingu zobrazení textové zprávy a také rozlišení notifikace dle výše uvedených typů barevně a ikonou. Maximální výchozí počet zobra- zených notifikací najednou je čtyři, samozřejmě lze toto číslo změnit. Další přidané notifikace se řadí do fronty. Šablona je animovaná a po určité době začne notifikace mizet. Po zmizení je vyvolána událost, která zobrazí další notifikaci z fronty.
5.3.2 Testování
Systém jsme většinou testovali po každé nově přidané funkcionalitě ve Visual Studiu za pomocí Debuggeru a případě jsme také využili diagnostických nástrojů. Ovšem otestovat komunikaci s řídícími zařízeními, mimo testování za provozu na struskárně, nebylo možné. Napadlo mě proto vytvořit aplikaci, která dokáže simulovat daná zařízení a zobrazí je vizuálně včetně projíždějících vozidel.
Aplikace se skládá ze dvou WPF oken. Jedno okno je řídící, umožňuje nastavit sériové porty, zapnout emulování obou vah a automatický pohyb vozidel včetně automatického snímaní karty, manuální výběr a snímaní karty a také zobrazuje jednotlivé sekvence bajtů probíhající komuni- kace.
Ve druhém okně probíhá grafická vizualizace provozu struskárny. Kliknutím a tahem myši lze manuálně pohybovat vozidly vertikálním směrem. Vizualizace je opravdu jednoduchá, takže se jedná pouze o pohyby barevně odlišených primitivních tvarů, jako obdélníky a kruhy.
27
Obrázek 5: Testovací aplikace
Aplikace také simuluje některé chyby, například místo čísla karty zašle sekvenci nesmyslných znaků nebo občasně prodlouží vozidlo, aby přesahovalo přes váhu a byly tak sepnuty světelné závory na dané váze. Díky tomu šlo otestovat, že vozidlo nedostane nikdy zelenou, pokud nebude celou svoji délkou na váze.
Jelikož naše pracovní počítače obsahovaly pouze jeden fyzický sériový port, využívali jsme aplikace Virtual Serial Ports Emulator, pro emulování všech potřebných sériových portů. V této aplikaci se dalo mimo jiné vytvořit takzvaného „Pair device“, který se skládal ze dvou logicky propojených virtuálních portů. Díky tomu šlo jednoduše zajistit komunikaci mezi testovací apli- kací a vážním systémem.
28
6 Závěr
Díky absolvování odborné praxe ve společnosti ArcelorMittal Ostrava a.s. jsem získal solidní nadhled a zkušenosti z hlediska řešení různých úkolů týkajících se nejen vážního systému pro struskové hospodářství. Za výhodu také považuji možnost získávat informace k vývoji přímo z provozu struskárny a od koncového uživatele systému.
Dále bych chtěl podotknout práci v týmu s dalšími studenty. Ať už jsem určitou část systému vypracovával samostatně nebo společně v rámci týmu, vždy záleželo na vzájemné komunikaci a vyjádření vlastních názorů k dané problematice. Naučil jsem se řešit problémy pod tlakem a přemýšlet nad možnými vylepšeními dané aplikace. Podařilo se nám splnit zadání a vážní systém je již přes rok nasazen v ostrém provozu. Od této doby se však dále doplňovala nová funkcionalita a upravovala stávající.
Vzhledem k nastoupení na praxi začátkem druhého semestru mi při řešení úkolů scházely hlubší znalosti programování v jazyce C#, platformy .NET a práce s relačními databázemi.
Ovšem tyto znalosti jsem během praxe prohloubil a následně uplatnil při vykonávání předmětů Programovací jazyky II, Úvod do databázových systémů a do určité míry předmětů Architektura technologie .NET a Vývoj informačních systémů. V pozdější fázi práce na systému jsem využil znalostí z předmětu Databázové a informační systémy především v oblasti tvorby procedur za pomocí jazyka T-SQL.
29
Literatura
[1] ArcelorMittal [online]. [cit. 2016-04-09]. Dostupné z: http://corporate.arcelormittal.com/
[2] ArcelorMittal Ostrava a.s. [online]. [cit. 2016-04-09].
Dostupné z: http://ostrava.arcelormittal.com/
[3] Microsoft API a referenční katalog [online]. Microsoft, 2016- [cit. 2016-04-09].
Dostupné z: https://msdn.microsoft.com/library
[4] FX-890/FX-2190: User’s Guide [online]. Nagano: EPSON, 2005 [cit. 2016-04-18].
Dostupné z: https://files.support.epson.com/pdf/fx890_/fx890_u1.pdf
30
