Univerzální aplikační software pro řízení pohonů a výkonové elektroniky

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Univerzální aplikační software pro řízení pohonů a výkonové elektroniky Bc. Michal Bruna

Vedoucí práce: Ing. František Žebra

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 1. června 2012

iv

v

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 10. 5. 2012

.............................................................

vi

Abstract This thesis is focused on design and implementation of a universal application software for the control of drives and power electronics. The result of this thesis is a set of libraries which together form a framework usable for these kind of systems. Because of the real-time character of the systems, the thesis is especially focused on distinctions of these systems. Furthermore, the thesis includes a selection of design patterns which are suitable for this kind of an application software. A functionality of the designed framework is verified at implementation of an application software which is intended for a boost converter 24 V/350 V.

Abstrakt Tato diplomová práce se zabývá návrhem a implementací univerzálního aplikačního software pro řízení elektrických pohonů a výkonové elektroniky. Výsledkem práce je sada knihoven, které dohromady tvoří framework, použitelný při návrhu software pro tento druh systémů. Jelikož se jedná o takzvané real-time systémy, práce zohledňuje zejména specifika právě těchto systémů. Dále obsahuje vytipování návrhových vzorů vhodných pro tvorbu tohoto typu aplikačního software. Funkčnost navrženého frameworku je ověřena při implementaci aplikačního software pro zvyšovací měnič 24 V/350 V.

vii

viii

Obsah 1 Úvod 1.1 Zadání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1

2 Popis problému, specifikace 2.1 Systém řízení měničů . . . 2.2 Real-time programování . 2.3 Existující architektura . . 2.4 Systém Poll 2. generace . 2.5 FreeRTOS . . . . . . . . .

cíle . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

3 3 6 6 7 7

3 Rešerše 3.1 Návrhové vzory pro real-time . . 3.1.1 Singleton . . . . . . . . . 3.1.2 Template method . . . . . 3.1.3 Facade . . . . . . . . . . . 3.1.4 Mediator . . . . . . . . . 3.1.5 X-makra . . . . . . . . . . 3.2 Tvorba automatické dokumentace 3.2.1 Doxygen . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

9 9 9 10 10 11 12 14 15

4 Analýza a návrh řešení 4.1 Analýza požadavků . . . . . . . . . . . . . . . . . . 4.1.1 Funkční požadavky . . . . . . . . . . . . . . 4.1.2 Ne-funkční požadavky . . . . . . . . . . . . 4.2 Návrh implementace . . . . . . . . . . . . . . . . . 4.2.1 Struktura aplikace . . . . . . . . . . . . . . 4.2.2 Struktura řízení měniče . . . . . . . . . . . 4.2.3 Řízení aplikace a stavové automaty . . . . . 4.2.4 Návrh knihoven . . . . . . . . . . . . . . . . 4.2.4.1 Zpracování výsledků AD převodů . 4.2.4.2 Kalibrace měření . . . . . . . . . . 4.2.4.3 Logické vstupy a výstupy . . . . . 4.2.4.4 Softwarové ochrany . . . . . . . . 4.2.4.5 Struktura řízení měniče . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

17 17 17 24 24 25 27 28 32 32 33 34 34 35

ix

x

OBSAH

4.2.4.6 4.2.4.7 4.2.4.8

Interní komunikace CAN . . . . . . . . . . . . . . . . . . . . 35 Diagnostika . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Záznam postmortů . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Realizace 5.1 Použité nástroje k implementaci . . . . . . . 5.1.1 C++ a překladač CGT C2000 5.2.2 5.1.2 Eclipse Indigo 3.7.2 . . . . . . . . . . 5.1.3 Tunning and Service Tool . . . . . . 5.2 Uložení zdrojových kódů . . . . . . . . . . . 5.3 Implementace knihoven . . . . . . . . . . . 5.3.1 Knihovna Module . . . . . . . . . . . 5.3.2 Smyčky . . . . . . . . . . . . . . . . 5.3.3 AD převodníky a kalibrace . . . . . . 5.3.4 Logické vstupy a výstupy . . . . . . 5.3.5 Ochrany . . . . . . . . . . . . . . . . 5.3.6 Obsluha zásahu ochran . . . . . . . . 5.3.7 Řízení měniče . . . . . . . . . . . . . 5.3.8 Interní komunikace CAN . . . . . . . 5.3.9 Záznamník postmortů . . . . . . . . 5.3.10 Diagnostika . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

39 39 39 39 40 40 40 40 41 41 42 42 43 43 44 44 44

6 Testování 6.1 Testování knihoven . . . . . . . . . . . . . . . . . . . 6.1.1 Unit Testing . . . . . . . . . . . . . . . . . . 6.1.2 Ostatní testování . . . . . . . . . . . . . . . . 6.2 Pilotní aplikace . . . . . . . . . . . . . . . . . . . . . 6.2.1 Zadání . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Požadavky . . . . . . . . . . . . . . . . . . . . 6.2.3 Návrh . . . . . . . . . . . . . . . . . . . . . . 6.2.4 Implementace . . . . . . . . . . . . . . . . . . 6.2.4.1 Struktura zdrojových kódů aplikace 6.2.4.2 Implementace funkčnosti . . . . . . 6.3 Srovnání s předchozí architekturou . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

45 45 45 47 48 48 50 52 54 54 54 58

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

7 Závěr

59

A Seznam použitých zkratek

63

B Obsah přiloženého DVD

65

Seznam obrázků 2.1 2.2

Blokové schéma řídícího systému . . . . . . . . . . . . . . . . . . . . . . . . . Typické blokové schéma aplikace pro řízení výkonové elektroniky . . . . . . .

3.1 3.2 3.3 3.4

Struktura Struktura Struktura Struktura

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 9 . 10 . 11 . 11

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13

Diagram třid - smyčky . . . . . . . . . . . . . . . . . Zjednodušený diagram tříd - struktura řízení měniče Stavový diagram řízení aplikace . . . . . . . . . . . . Stavový diagram řízení měniče . . . . . . . . . . . . Stavový diagram řízení regulace . . . . . . . . . . . . Diagram tříd knihovny AD převodů . . . . . . . . . Diagram tříd knihovny kalibrace . . . . . . . . . . . Diagram tříd knihovny logických vstupů . . . . . . . Diagram tříd knihovny logických výstupů . . . . . . Diagram tříd knihovny softwarových ochran . . . . . Diagram tříd knihovny intenrí komunikace CAN . . . Diagram tříd knihovny diagnostiky . . . . . . . . . . Diagram tříd knihovny záznamu postmortů . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

6.1 6.2 6.3

Elektrická Jednotka řady 575 . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Blokové schéma zapojení zvyšovacího měniče pro záložní napájení střídače . . 52 Blokové schéma regulace zvyšovače NZV3502 . . . . . . . . . . . . . . . . . . 53

vzoru vzoru vzoru vzoru

Singleton . . . . . Template Method Facade . . . . . . Mediator . . . . .

. . . .

xi

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

4 5

26 27 29 30 31 32 33 34 34 35 36 37 37

xii

SEZNAM OBRÁZKŮ

Seznam tabulek 6.1

Porovnání nové a staré architektury . . . . . . . . . . . . . . . . . . . . . . . . 58

xiii

xiv

SEZNAM TABULEK

Kapitola 1

Úvod 1.1

Zadání

Cílem práce je navrhnout a implementovat univerzální aplikační software pro řízení elektrických pohonů a výkonové elektroniky. Jedná se v podstatě o framework, nad kterým budou vznikat aplikace pro jednotlivé konkrétní projekty. Součástí práce je porovnání tohoto frameworku s předchozí architekturou aplikací používanou ve firmě Poll pro tyto účely, a to z hlediska implementační složitosti a nároků na výpočetní prostředky.

1.2

Motivace

Firma Poll, s.r.o. každoročně řeší množství projektů jejichž společným jmenovatelem je řízení elektrických měničů. Jelikož požadavky zákazníků na termíny jsou velmi přísné, je žádoucí aby příprava aplikačního software probíhala v co nejkratší možné době. Zároveň se ovšem jedná o software pro zařízení určená pro drážní vozidla, kde se klade velký důraz na spolehlivost a bezpečnost. Na základě dlouholetých zkušeností s vývojem těchto zařízení, a tedy i software, vznikla myšlenka na tvorbu univerzálního aplikačního software který by byl jednotný pro všechny projekty. Jelikož se tyto projekty v mnohém liší, bylo rozhodnuto o vytvoření souboru knihoven, které by sjednocovaly společné vlastnosti a funkcionalitu jednotlivých aplikací do frameworku. Od implementace frameworku se očekává snížení implementační náročnosti konkrétních projektů, snížení náchylnosti k chybám programátora, zlepšení dokumentovatelnosti, zvýšení znovupoužitelnosti kódu a pokud to bude možné, zlepšení nároků aplikace na výpočetní prostředky jak paměťové, tak časové.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Popis problému, specifikace cíle 2.1

Systém řízení měničů

Účelem práce je navrhnout a realizovat framework pro řízení elektrických měničů, pohonů a jiné výkonové elektroniky. Vytvoření tohoto frameworku obnáší vytvořit soubor knihoven, které budou dohromady tvořit základ pro aplikace tohoto typu. Aplikace poběží na operačním systému nazvaném Systém Poll 2. generace, o kterém se podrobněji rozepíšu níže. Tento systém je založen na mikrokernelu FreeRTOS a ve své podstatě se také jedná o soubor knihoven a dalo by se říci, že tento framework jej rozšiřuje a obohacuje. Na diagramu 2.1 je ukázáno blokové schéma systému řízení měniče. Celé zařízení lze rozdělit na výkonovou část, která se může skládat z různého počtu elektrických měničů, a řídící část, jejímž základem je procesor. Do procesoru se nahrává binární program, který je výsledkem společného překladu systémové části (zde Systém Poll 2. generace) a aplikační části. Toto nahrávání se provádí pomocí servisního nástroje TST, který je rovněž dílem firmy Poll. Podle stádia, ve kterém se projekt nachází, provede nahrání aplikace do procesoru programátor, servisní technik či zástupce zákazníka. Při běžném provozu je diagnostická linka, kterou může představovat například sběrnice USB nebo Ethernet, odpojena. Řídící část měniče ovládá výkonovou část měniče signály generovanými periferiemi procesoru, většinou pulzně šířkovou modulací. Řídící část aplikace dále komunikuje s vnějšími zařízeními (může se jednat o další zařízení firmy Poll nebo zařízení některé spolupracující firmy či zákazníka) pomocí obvyklých komunikačních linek, například CAN nebo pomocí logických signálů. Tato práce se zabývá částí, která je na diagramu označena zeleně, tedy vývojem aplikační části řídícího software.

3

4

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

Obrázek 2.1: Blokové schéma řídícího systému

2.1. SYSTÉM ŘÍZENÍ MĚNIČŮ

5

Blokové schéma 2.2 ukazuje typické rozdělení aplikace určené pro řízení elektrického měniče do logických celků. Obsahuje bloky logických vstupů a výstupů, zpracování výsledků AD převodů, ochrany a zpracování zásahu ochran, dále aplikační logiku, která je často reprezentována stavovými automaty, signálovou logiku, která se stará například o vyhodnocení podmínek pro rozběh regulace, komunikaci po CANu či servisní lince a záznamník diagnostických dat. Funkcemi jednotlivých bloků se dále budu zabývat v analýze požadavků.

Obrázek 2.2: Typické blokové schéma aplikace pro řízení výkonové elektroniky Z diagramu 2.2 není patrné časové rozvržení aplikace. Často se používá rozdělení na více vláken, která se vykonávají v různém taktu a s různou prioritou. Obvyklým řešením je rozdělení na dvě vlákna běžící s pevným taktem a asynchronní obsluhu zásahu ochran. Vlákno s rychlejším taktem a větší prioritou obvykle nazýváme rychlá smyčka, druhé vlákno, běžící v pomalejším taktu se nazývá pomalá smyčka. Na rychlé smyčce se obvykle obsluhují úlohy přímo související s fyzikální podstatou řešeného problému, například výpočet regulace. Na pomalé se počítá žádost, obsluhují se logické vstupy a výstupy, komunikace a úlohy podobného charakteru.

6

2.2


Real-time programování

Programování real-time aplikací přináší svá specifika. Kladou se významné požadavky na optimalizaci využití omezených výpočetních a paměťových prostředků. Tento požadavek je často v přímém rozporu s využitím principů objektového programování, jelikož využití nástrojů objektově orientovaného jazyka s sebou přináší režijní náklady na volání funkcí či ukládání objektů do paměti. Přestože použitý programovací jazyk je C++ a metoda volání virtuálních funkcí pomocí tabulky virtuálních funkcí je nejrychlejší možná, jsou i tyto nároky na režii tak podstatné, že jejich použití na nejrychlejší úrovni přerušení je potřeba se vyhnout kdykoliv je to jen trochu možné. Mezi další specifika real-time aplikací patří ladění. Použití debuggeru pro krokování není vždy možné a aplikace musí být navržena tak, aby umožňovala ladění pomocí programu pro PC, kterým je v tomto případě Tuning and Service Tool (TST) [13] dále odkazovaný také jako servisní nebo diagnostický nástroj. Tento program komunikuje se zařízením přes servisní linku, například Ethernet nebo USB. Při překladu se vygeneruje tabulka proměnných v aplikaci, ta je předána servisnímu nástroji a servisní nástroj umí vyčíst hodnotu proměnných z této tabulky, ve speciálním případě (pouze pro proměnné zvolené programátorem) i hodnotu do proměnné zapsat. Tento postup umožňuje přístup pouze k proměnným, které jsou globální či na ně existuje globální ukazatel. Toto je další významné omezení objektového přístupu - pro rychlou orientaci je vyžadováno, aby například proměnné nesoucí hodnoty měřených fyzikálních veličin byly globální. Proto není možné realizovat vyčtení analogového měření prostým vytvořením objektu který by se o toto postaral. Se snadnou orientací v servisním nástroji souvisí i nutnost mít globální proměnné pojmenované podle jednotné metodiky tak, aby pojmenování jednak přesně vystihovalo smysl proměnné ale také umožňovalo její rychlé nalezení jak v kódu, tak v tabulce proměnných.

2.3

Existující architektura

Současná architektura vychází z bakalářské práce na téma Aplikační část programového vybavení nabíjecí soupravy elektrické motorové jednotky řady 671 ŽSSK [2]. Architektura je založena na rozdělení aplikace do dvou smyček, jejichž obsah i forma jsou v každé aplikaci definovány zvlášť. Další podstatnou částí aplikace jsou stavové automaty. Každá aplikace obsahuje jeden stavový automat aplikace a pro každý řízený měnič navíc stavový automat regulace. Přestože velká část funkčnosti těchto stavových automatů je pro všechny projekty společná, drobné rozdíly nedovolují tyto automaty mít jednotně navržené, popsané ani implementované. Opět zde dochází k častému opakování segmentů kódu mezi projekty ale i mezi části jedné aplikace. V jedné části aplikace se často opakují i části kódu standardních funkčností jako je zpracování logických vstupů či výstupů, vyčítání analogových veličin či vyhodnocení softwarových ochran. Tato architektura se ukázala jako úspěšná, pokud ji budeme posuzovat z funkčního hlediska, nicméně některé nedostatky nelze přehlédnout. Především se jedná o opakování úloh které programátora odvádějí od projektově specifické činnosti a dále také množství kopírovaného kódu mezi jednotlivými projekty. Obě tyto vlastnosti mají za následek zvýšení chybovosti aplikace a velmi složitou údržbu kódu.

2.4. SYSTÉM POLL 2. GENERACE

2.4

7

Systém Poll 2. generace

Systém Poll 2. generace je označení pro soubor softwarových knihoven a způsobu práce na vývoji software pro řízení elektrických měničů a podobných zařízení. Systém je vyvíjen s důrazem na platformní nezávislost samotného systému i aplikace, resp. co nejjednodušší přizpůsobitelnost nové platformě (tj. použitého procesoru). Hlavním motivem vzniku systému Poll 2. generace je maximální zjednodušení vývoje aplikací, respektive oddělení úlohy vývoje aplikací od úlohy přizpůsobení HW platformě. K dalším cílům systému 2. generace patří: • vytvoření balíků běžně používaných funkčností (ovladače periferií, matematické funkce, komunikační protokoly atd.) • vytvoření jednotného systému, co nejvíce nezávislého na platformě, pro psaní kódu a překlad (využívá technologií Eclipse a GNU make) • zavedení a podpora psaní kódu v C/C++, zastupitelnost jednotlivých autorů kódu (v systému Poll 1. generace byl psán kód v assembleru a nesl velké nároky na znalost platformy a byl velmi obtížně delegovatelný na jiného autora) • vývoj a podpora nového grafického ladícího a servisního nástroje (TST) • unifikace uživatelského rozhraní (podpora diagnostiky systému, testování a dalších vlastností přímo v systémové části firmware)

2.5

FreeRTOS

Systémová část programového vybavení nabíjecí soupravy (řídící systém Poll 2. generace) využívá mikrokernel FreeRTOS. Tento mikrokernel je použit zejména z těchto důvodů: • Šetření vývojového času a tím i snižování nákladů na vývojové práce. • Použití osvědčeného a otestovaného systémového jádra eliminuje komplikace při jeho nasazení. • Z FreeRTOSu je možný přechod na systémy OpenRTOS a SafeRTOS, z nichž druhý jmenovaný je certifikován na SIL3, což je bezpečnostní úroveň která může být v budoucnu vyžadována u některých typů vyvíjených aplikací. O bezpečnostních certifikacích SIL se můžete dozvědět více například zde [14]. FreeRTOS [8] je real-time operační systém pro embedded zařízení. Podporuje mnoho rozličných architektur, v našem případě však bylo nutné přizpůsobit FreeRTOS mikrokontrolerům Texas rodiny TMS320F28xx. FreeRTOS je licencován GNU GPL s výjimkou, že samotný aplikační kód nemusí být zveřejněn. FreeRTOS je navržen tak, aby byl jednoduchý a malý. Samotné jádro se skládá pouze z několika zdrojových souborů v jazyce C. V assembleru jsou psány pouze některé funkce, většinou závislé na architektuře. Výhodou FreeRTOSu je možnost strukturování aplikace jako několik nezávislých úloh (tasků), které mohou

8


být uspány a probouzeny na základě přerušení. FreeRTOS využívá preemptivní plánování úloh a podporuje několik úrovní priorit. Pro synchronizaci tasků lze využít semafory, které jsou součástí jádra.

Kapitola 3

Rešerše 3.1

Návrhové vzory pro real-time

Návrhové vzory představují obecná řešení často se vyskytujících problémů při návrhu a implementaci software. Vzory jsou nezávislé na použitém programovacím jazyku. Jedná se v podstatě o šablonu jak daný problém řešit. Objektově orientované návrhové vzory většinou ukazují vztahy mezi třídami nebo objekty. Pro zobrazení těchto vztahů použiji class diagramy UML. Tento modelovací jazyk použiji i dále pro analýzu a návrh aplikace. Informace o návrhových vzorech byly čerpány z e-knihy Design Patterns v OOP [3]. Zde se nebudu zabývat všemi vzory, ale jen těmi, které budu v implementaci využívat. Vyzvednu jejich použitelnost v real-time aplikacích s ohledem na paměťovou a časovou náročnost jejich použití v implementaci.

3.1.1

Singleton

Smysl tohoto návrhového vzoru je zabezpečit, aby v aplikaci mohla vzniknout pouze jedna instance dané třídy, která bude viditelná odkudkoliv. Toto je v real-time aplikacích velmi častá situace, není například zapotřebí mít více instancí ovladače AD převodníku procesoru, ale je nutné aby k tomuto ovladači byl umožněn přístup ze všech míst kde se používají analogové veličiny.

Obrázek 3.1: Struktura vzoru Singleton Ve třídě, ze které chceme vyrobit singleton, je zavedená privátní statická proměnná typu této třídy. V konstruktoru se pak do této proměnné přiřadí právě vyráběná instance. Pomocí 9

10

KAPITOLA 3. REŠERŠE

veřejné statické metody getInstance() pak v místě odkud chceme k singletonu přistupovat získáme instanci se kterou můžeme nyní provádět operace. Jak je zmíněno výše, použití v real-time systémech je velmi žádoucí, neboť případy, kdy potřebujeme zajistit přítomnost jediné instance a zároveň viditelnost této instance z různých míst aplikace, jsou obvyklé. Metoda getInstance() může být implementována jako inline funkce, čímž se režijní časové nároky minimalizují. Paměťová náročnost s použitím vzoru neroste, jelikož instance uložená v singletonu (nebo spíše ukazatel na ni) by musela být vytvořena i bez použití vzoru. Použitím statické proměnné je zajištěna i viditelnost z diagnostického nástroje, neboť adresa takovéto proměnné je známa v době překladu.

3.1.2

Template method

Vzor zavádí na úrovni předka scénář složený z volání několika polymorfních metod. Potomci pak polymorfní metody přepisují nebo implementují a tím konkretizují daný scénář. Tímto postupem je umožněno provést abstrakci metod, jejichž detaily nemusíme v předkovi znát ale známe kostru, podle které se bude postupovat. Polymorfní metody v předkovi nemusí být nezbytně abstraktní a třída předka tedy také nemusí být abstraktní.

Obrázek 3.2: Struktura vzoru Template Method Tento vzor je velmi známý a rozšířený a své uplatnění najde i v real-time systémech. Velkou nevýhodou ovšem bude nutnost volání virtuálních funkcí, což pro nejrychlejší úrovně přerušení je velmi nepříjemné. Je tedy potřeba s použitím tohoto vzoru na těchto úrovních nakládat velmi opatrně a to jen tehdy, je-li to nezbytné k dosažení znovupoužitelnosti kódu.

3.1.3

Facade

Smyslem vzoru je zjednodušit přístup k subsystému tak, že pro celý subsystém nabídne jeden nebo více interfaců. Tento interface obsahuje metody, které jsou přístupné vnějšímu klientovi a používají třídy ze subsystému. Tento často složitý subsystém je tak odstíněn od klienta, který vidí pouze interface. Opět se jedná o velmi rozšířený vzor a lze jej použít i v real-time aplikacích. Pokud jde o časové režijní náklady, lze je minimalizovat použitím inline funkcí v interfacu a vzor je tedy

3.1. NÁVRHOVÉ VZORY PRO REAL-TIME

11

Obrázek 3.3: Struktura vzoru Facade použitelný pro všechny úrovně přerušení. Paměťové náklady na použití vzoru závisí na počtu komponent v subsystému jelikož interface si musí udržovat ukazatele na komponenty subsystému které používá. Tyto ukazatele by si bez použití vzoru musel udržovat klient a pokud je klientů více, je pravděpodobné že použitím vzoru může dojít ke snížení paměťových nároků systému.

3.1.4

Mediator

Tento vzor zavádí objekt jako prostředníka mezi jinými objekty, které oddělí a zprostředkuje jim jinak složitou komunikaci, takže tyto objekty nemusí mít přímou vazbu mezi sebou. Tohoto se docílí tím, že objekt prostředníka vidí všechny komunikující objekty, které naopak vidí pouze prostředníka. Chce-li jeden objekt komunikovat s druhým, volá tento nejdříve k tomu určenou metodu prostředníka, který následně přeposílá požadavek na konkrétní objekt ze skupiny.

Obrázek 3.4: Struktura vzoru Mediator Stejně jako u vzoru Facade, i zde je použití v real-time systémech možné a vhodné. Časové a paměťové nároky jsou taktéž stejné, tedy použitím inline funkcí lze minimalizovat

12


časovou režii a paměťová náročnost je menší než bez použití tohoto vzoru, neboť každý ze skupiny komunikujících objektů si udržuje pouze odkaz na prostředníka a ten jediný drží odkazy na všechny objekty ze skupiny. Bez použití vzoru by každý objekt udržoval ukazatele na všechny nebo část objektů ze skupiny, čímž by se paměťová náročnost značně zvýšila.

3.1.5

X-makra

X-makro je méně známe využití preprocesoru jazyka C/C++. Jedná se v podstatě o generování kódu uvnitř samotného jazyka a tím šetření práce programátora. Obvyklá implementace využívá hlavičkového souboru, který obsahuje volání maker. Tento hlavičkový soubor se vkládá na různá místa v kódu, kde těsně před jeho vložením jsou volaná makra definována a po vložení souboru jsou definice těchto maker zrušeny. Zrušení definic umožňuje na jiném místě použít definici makra jinou a proto vložení souboru s voláním maker na různém místě v aplikaci má za následek různý kód po expanzi maker. Například můžeme na jednom místě definovat makro pro deklaraci proměnné a na jiném místě její inicializaci. Jelikož se využívá preprocesoru, nemá tento přístup žádny vliv na časovou či paměťovou náročnost, ale umožňuje programátorovi jediným voláním makra v jednom souboru aplikace vygenerovat kód různé funkce a tím šetřit čas programátora a snížit pravděpodobnost jeho chyby (například zapomenutí na inicializaci proměnné). Nevýhodou je méně přehledný kód a zhoršené podmínky pro ladění aplikace. Pro lepší představu přikládám použití X-makra pro vložení proměnné typu int s inicializací. Soubor, kde se proměnná vkládá pak obsahuje: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

/∗ ∗ d e k l a r a c e promenne ∗/ # define GENERUJ_PROMENNOU( name , i n i t _ v a l u e ) int name ; # include "defs.h" # undef GENERUJ_PROMENNOU .... /∗ ∗ i n i c i a l i z a c e promenne ∗/ # define GENERUJ_PROMENNOU_INT( name , i n i t _ v a l u e ) name = i n i t _ v a l u e ; # include "defs.h" # undef GENERUJ_PROMENNOU_INT

Hlavičkový soubor s voláním maker (defs.h) může vypadat takto: 1 2 3

GENERUJ_PROMENNOU_INT ( promenna_a , 1 0 ) GENERUJ_PROMENNOU_INT ( promenna_b , 2 0 )

13

3.1. NÁVRHOVÉ VZORY PRO REAL-TIME

Výsledný kód po zpracování preprocesorem bude vypadat takto: 1 2 3 4 5 6 7 8

int promenna_a ; int promenna_b ; ... promenna_a = 1 0 ; promenna_b = 2 0 ;

Pokud bych chtěl například generovat proměnnou typu float, tak by bylo nutné na každém místě kde se vkládá soubor defs.h definovat makro GENERUJ_PROMENNOU_FLOAT (když pominu možnost přidat parametr makra, která v tomto případě by byla možná ale u složitějších případu to tak vždy být nemusí). Protože množství definic maker před každým vložením souboru s voláním maker velmi znepřehledňuje kód a způsobuje nutnost častého zásahu do zdrojového kódu, je vhodné tyto definice odstínit od samotného souboru s výkonným kódem. Toho se docílí zavedením zástupného makra, které bude společné pro všechna makra volaná v hlavičkovém souboru. Na místě, kde se hlavičkový soubor vkládá, se definuje zástupné makro tak, že obsahuje volání makra konkrétní funkce pro konkrétní místo aplikace kde se generuje kód. Hlavičkový soubor s voláním maker defs.h by nyní vypadal takto: 1 2 3

VLOZ_KOD ( PROMENNA_INT , promenna_a , 1 0 ) VLOZ_KOD ( PROMENNA_FLOAT , promenna_b , 2 0 )

Soubor s definicemi maker vypadá takto. Odstínění makra spojující název a typ je nutné kvůli expanzi parametrů makra, více zde [10]. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

/∗ ∗ pomocna makra pro s k l a d a n i nazvu makra v o l a n e h o ∗ z e z d r o j o v e h o souboru ∗/ # define JMENO_MAKRA_ODSTINENI( nazev , typ ) nazev##_##typ # define JMENO_MAKRA_( nazev , typ ) JMENO_MAKRA_ODSTINENI( nazev , typ ) /∗ ∗ makra pro g e n e r o v a n i promenne typu i n t ∗/ # define PROMENNA_INT_DEKLARACE( name , i n i t _ v a l u e ) # define PROMENNA_INT_INICIALIZACE( name , i n i t _ v a l u e )

int name ; name = i n i t _ v a l u e ;

/∗ ∗ makra pro g e n e r o v a n i promenne typu f l o a t ∗/ # define PROMENNA_FLOAT_DEKLARACE( name , i n i t _ v a l u e ) float name ; # define PROMENNA_FLOAT_INICIALIZACE( name , i n i t _ v a l u e ) name = i n i t _ v a l u e ;

14


Samotný zdrojový soubor obsahuje tento kód: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

/∗ ∗ d e k l a r a c e promenne ∗ ∗ makro VLOZ_KOD j e v a r i a d i c , tedy s promennym ∗ poctem parametru , n a p r i k l a d bych mohl c h t i t promennou ∗ k t e r a s e nebude i n i c i a l i z o v a t , pak bych p o u z i l j e j e d e n ∗ parametr . ∗/ # define VLOZ_KOD(TYP_KODU, . . . ) \ JMENO_MAKRA ( TYP_KODU , DEKLARACE ) ( __VA_ARGS__ ) # include "defs.h" # undef VLOZ_KOD .... /∗ ∗ i n i c i a l i z a c e promenne ∗/ # define VLOZ_KOD(TYP_KODU, . . . ) \ JMENO_MAKRA ( TYP_KODU , INICIALIZACE ) ( __VA_ARGS__ ) # include "defs.h" # undef VLOZ_KOD

Výsledný kód po zpracování preprocesorem bude vypadat takto: 1 2 3 4 5 6 7 8

int promenna_a ; float promenna_b ; ... promenna_a = 1 0 ; promenna_b = 2 0 ;

Pokud bych nyní chtěl přidat generátor proměnných typu double, upravil bych pouze soubor s definicemi maker a do samotného zdrojového souboru by nebylo nutné zasahovat.

3.2

Tvorba automatické dokumentace

Automatické generování dokumentace je atraktivní způsob dokumentování zdrojového kódu, například proto, že se tato dokumentace generuje ze samotného kódu pomocí komentářů. Další zjevnou výhodou automaticky generované dokumentace je fakt, že při úpravě zdrojových kódů stačí dokumentaci přegenerovat a její aktuálnost je tak mnohem snazší zajistit. Výstupem automatického generování je dokumentace v textové podobě, HTML nebo obdobných formách. Generování této dokumentace ovšem vyžaduje disciplínu při psaní kódu a komentářů a dodržování pravidel, která vyžaduje generátor dokumentace. Toto pochopitelně

3.2. TVORBA AUTOMATICKÉ DOKUMENTACE

15

platí i pro real-time aplikace, jelikož na úrovni formy zdrojového kódu se jedná o zcela běžný software.

3.2.1

Doxygen

Jak uvádí oficiální stránky Doxygen.org, Doxygen je systém dokumentace pro množství programovacích jazyků (C, C++, JAVA, Python, Objective-C, PHP a další). Může sloužit ke třem účelům: • Generování dokumentace ve formátu pro on-line verzi (HTML) nebo pro off-line verzi (LaTeX ve formě dokumentovaných zdrojových kódů). Podporuje i formáty RTF, PostScript a další. Tato dokumentace se získává přímo ze zdrojového kódu dokumentovaného software • Doxygen lze využít i pro extrakci struktury zdrojového kódu z nedokumentovaných zdrojových souborů. • Nástroj lze využít i pro tvorbu normální dokumentace.

Pravidla pro psaní komentářů Doxygen Níže uvádím výňatek z pravidel pro psaní komentářů Doxygen a vybrané styly, které jsou použity v této aplikaci. Pro označení komentáře jako detailní popis bloku kódu bude používán komentář ve stylu JavaDoc s přidanou hvězdičkou. 1 2 3

/∗ ∗ ∗ . . . text . . . ∗/

Pro zkrácený popis lze použít příkaz brief. Takto je vhodné komentovat veškeré funkce, třídy a soubory. 1 2 3 4 5

/∗ ∗ ∗ \ b r i e f Kratky p o p i s ∗ ∗ . . . popis s detaily . . . ∗/

Deklarované proměnné lze okomentovat přidáním komentáře přímo za deklaraci v tomto tvaru: 1

int var ; ///< Popis promenne

16


U funkcí je nutné používat příkazy param a return pro popis parametrů funkce a návratové hodnoty: 1 2 3 4 5 6 7 8 9

/∗ ∗ ∗\ b r i e f Popis f u n k c e ∗ ∗ . . . popis s detaily . . . ∗ ∗\ param param1 p o p i s parametru ∗\ r e t u r n p o p i s n a v r a t o v e hodnoty ∗/ int function ( param1 ) ;

Každý soubor musí obsahovat komentář v takovémto tvaru (Některé informace v tomto komentáři jsou automaticky generované pomocí funkce verzovacího systému Subversion SVN Keywords, která při každém commitu souboru tyto informace aktualizuje. Jedná se o klíčová slova Author, Date, Id a HeadURL): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

/∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗/

\file \ since

datum v z n i k u souboru

\ a u t h o r a u t o r souboru \ a u t h o r \ $Author : $ // a u t o r souboru \ a u t h o r © ; Copyright POLL, s . r . o . A l l r i g h t s r e s e r v e d \ d a t e \ $Date : $ \ v e r s i o n \ $Id : $ \ v e r s i o n \$HeadURL : $

//datum m o d i f i k a c e souboru // r e v i z e souboru v S u b v e r s i o n //URL souboru v S u b v e r s i o n

\ b r i e f p o p i s souboru . . . p o p i s souboru s d e t a i l y . . .

Kapitola 4

Analýza a návrh řešení 4.1

Analýza požadavků

Analýzu požadavků na tento framework jsem provedl po důkladném prozkoumání předchozí architektury. Analýzu doprovázelo vytipování často i méně často se opakujících úloh které musely být řešeny v předchozí architektuře, konzultace s kolegy, kteří řeší podobnou problematiku a zkoumání zadání od zákazníků.

4.1.1

Funkční požadavky

Požadavky jsou pro přehlednost řazeny podle logických celků ke kterým přísluší. Tyto celky vycházejí ze zkušeností získaných při práci s předchozí architekturou aplikací pro řízení elektrických měničů a jsou znázorněny v blokovém schématu aplikace 2.2. Toto rozdělení nemusí odpovídat finálnímu rozdělení do knihoven, nicméně se očekává, že se mu bude blížit.

Zpracování výsledků AD převodů Tento blok slouží ke zpracování výsledků AD převodů, tedy vyčtení výsledků z registrů procesoru, jejich úpravu do formátu používaného v aplikaci, výpočet různých filtrů a podobně.

• Nastavení AD převodníků (počet vyčítaných proměnných, kaskádní režim, atd.) • Vyčtení výsledků AD převodníku • Převod do formátu 1.15 (ze znaménkové i neznaménkové hodnoty) 17

18

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ

• Možnost invertovat znaménkový i neznaménkový výsledek převodu • Vyčítání kritických veličin na rychlé smyčce • Filtrace analogových veličin (v základu FIR, Tau) • Převody jednotek, soustav a podobně. • Vyčítání nekritických veličin na pomalé smyčce • Eliminace offsetů – mimo stav inicializace, kdy se tyto offsety zjišťují • Přesnější měření pomocí SPI AD převodníku – výběr platné hodnoty (dokud není komunikace navázána, musí zůstat aplikace ve stavu inicializace, po uplynutí timeoutu případně přejít do klidu a signalizovat chybu v komunikaci s SPI převodníkem • Vyčítaní hodnot z převodníku po SPI • Hodnoty zobrazitelné v diagnostických panelech TST (globální proměnné) • Nastavení hodnot z terminálu TST (nejlépe i mezi jednotlivými ucelenými bloky jako filtry, převody. . . ) • Diagnosticky zakázat/povolit eliminaci offsetů

Kalibrace měření analogových veličin Kalibrace slouží ke zpřesnění výsledků AD převodů. Měřící cesty či samotný procesor mohou do měření vnášet určitý offset, úkolem tohoto bloku je umožnit tento offset eliminovat.

• Dva druhy kalibrace – online a offline • Dokud není kalibrace provedena, blokovat aplikaci ve stavu inicializace • Kalibrace se provádí určitou dobu po startu aplikace, kdy AD převodníky jsou již v ustáleném stavu • Po zjištění offsetu měření je tento předán modulu AD převodů, aby byla umožněna jejich eliminace • Omezení kalibračního offsetu – pokud bude hodnota mimo předem určený rámec, offset se nenastaví a nahlásí se chyba. • Online kalibrace se provádí automaticky po startu aplikace • Online kalibraci lze provést u hodnot, u kterých si můžeme být jisti, že pokud měnič není v běhu, tak mají určitou hodnotu. • Offline kalibraci provádí typicky zkušební technik při kusové zkoušce

4.1. ANALÝZA POŽADAVKŮ

19

• Kalibrace se provádí zadáním skutečné hodnoty fyzikální veličiny pomocí diagnostického nástroje • Při inicializaci se vyčte kalibrace z flash, pokud v ní není uložena, zaznamená se chyba. • Po provedení kalibrace je nutné informovat o provedení zápisu do flash • Kalibrace všech hodnot měření najednou.

Zpracování logických vstupů Blok logických vstupů se stará o vyčtení a zpracování binárních logických signálů. • Vyčtení stavu logického vstupu • Filtrace přes nastavitelný počet vzorků • Vyhodnocení na pomalé smyčce • Za zvláštních okolností možný požadavek i na vyhodnocení na rychlé smyčce • V rámci šetření paměťovými prostředky by bylo dobré se zamyslet zda nepoužívat k zápisu hodnot vstupů jednotlivé bity (je otázkou zda to ale neprodlouží výpočet) • Diagnostické nastavení hodnoty logického vstupu z terminálu TST za běhu i v diagnostice

Zpracování logických výstupů Tento blok se stará o zápis hodnoty do logického výstupu. • Zapsání hodnoty na výstup • Přečtení stavu výstupu • Diagnostické nastavení hodnoty výstupu z terminálu TST

Softwarové ochrany Softwarové ochrany umožňují zastavit běh měniče pokud je zjištěn nepřípustný stav, například překročení maximální hodnoty měřené fyzikální veličiny. • Umožňuje na základě SW komparací vyvolat přerušení s obslužnou rutinou

20


• Komparace příslušných veličin na minimum, maximum, nebo obojí • Komparace na minimum i maximum s hysterezí • Vyhodnocení na pomalé a rychlé smyčce • Vyhodnocení ochrany jen za určitých okolností ( např. ochrana se bude vyhodnocovat jen za běhu měniče a podobně) – podmínění příznakem • Zobrazení stavu jednotlivých ochran v TST (textová forma, výčtový typ), ale i bitová forma pro větší přehlednost při vícenásobných zásazích. • Diagnostické vyvolání zásahu jednotlivých ochran • Diagnostické potlačení (zamaskování) jednotlivých ochran

Hardwarové ochrany Hardwarové ochrany mají stejný význam jako ochrany softwarové, s tím rozdílem že jejich vyhodnocení je nezávislé na běhu aplikace a tento blok se tedy stará pouze o jejich nastavení.

• Vyvolání přerušení GZI při aktivním stavu pinu. • Zobrazení zásahu v servisním nástroji

Obsluha zásahu ochran Úkolem tohoto bloku je zareagovat na zásah ochrany (softwarové či hardwarové), zaznamenat okolnosti a typ zásahu.

• Rozlišení typu zásahu (příslušnost ke konkrétnímu měniči, HW nebo SW ochrana) • Čítání celkového počtu zásahu • Může být zásah více ochran najednou • Uchovávat současný stav zásahu ochran • Uchovávat poslední zásah ochran • Uchovávat součet všech zásahů ochran • Vyvolat uložení záznamu průběhu nejdůležitějších fyzikálních a stavových veličin • Možnost zvolit pro které ochrany se záznam uloží


21

Pro každý konkrétní měnič bude spuštěna vlastní úloha obsluhy zásahu ochran, pokud je tato ochrana platná pro tento měnič. Tato specifická obslužná úloha musí plnit tyto funkce: • Čítání počtu zásahů • Neprodleně vypnout pulzy PWM příslušného měniče • Rozdělení ochran na trvale blokující (tj. bránící opětovnému spuštění měniče) a neblokující.

Zpracování zadání Vyhodnocení žádosti je aplikačně specifická funkčnost, nelze tedy řešit obecně. Konkrétní funkčnost tak bude implementována až v konkrétní aplikaci a bude implementovat rozhraní definované v této knihovně. • Na základě signálu enable a žádané výstupní veličiny zpracovat zadání pro regulační soustavu • Poskytuje informaci a skončení rozběhu a doběhu měniče.

Regulace Regulace je téměř výhradně aplikačně specifická záležitost a nelze ji zobecnit. V obecné verzi se tato knihovna definuje jako rozhraní pro předání informací o stavu regulace ostatním knihovnám a aplikační logice.

Logika měniče Cílem knihovny je uchovávat logické stavy aplikace a jednotlivých měničů či regulací. Stavové automaty vyhodnocují podmínky pro povolení funkce měniče, vyhodnocují odstavování a vypínaní měniče, poskytují ostatním knihovnám informace o současném stavu měniče.

Logika aplikace Knihovna se stará o celkový stav aplikace, vyhodnocuje dokončení inicializace aplikace, požadavek na přechod do diagnostického režimu a povolení rozběhu jednotlivých regulací.

Generátor impulzů Knihovna se stará o předání akční veličiny do periferie pulzně šířkové modulace (PWM), umožňuje volit zdroj akční veličiny (pevné zadání z diagnostického nástroje, testovací zadání pro zkoušení hardwarových prostředků, žádost z regulace).

22


• Na základě žádosti z regulace či z diagnostického nástroje vyhodnocuje zapnutí a vypnutí pulzů. • Kontrola akční veličiny na přípustné hodnoty • Poskytuje rozhraní pro vyvolání přerušení s obslužnou rutinou • Umožňuje diagnostické nastavení deadtime, minimálního a maximálního pulzu, spínací frekvence.

Obsluha komunikace CAN Knihovna poskytuje nástroje pro obsluhu komunikace na lince CAN mezi zařízeními firmy Poll. Obsahy jednotlivých zpráv jsou závislé na konkrétní aplikaci, nicméně lze zobecnit požadavky typu poslání zprávy, zpracování přijaté zprávy, vyhodnocení výpadku komunikace, kontrola čítače lifetime u posílaných zpráv či jeho automatická inkrementace u vysílaných zpráv. Obsahy zpráv musí být definované v aplikaci, nicméně knihovna by měla poskytovat nástroj pro pohodlnou práci s touto definicí. Požadavky na příjem zpráv: • Detekce výpadku zprávy, výpadku komunikace s jednotlivými zařízeními. • Signalizace výpadků dále do aplikace • Čítání chyb (výpadků) na lince • Kontrola lifetime příchozích zpráv • Při výpadku komunikace nastavit obsah přijímaných zpráv na předvolené hodnoty • Pro testovací účely umožnit nastavit obsah přijímaných zpráv z diagnostického nástroje. • Umožnit z diagnostického nástroje vypnout kontrolu lifetime Požadavky na posílání zpráv: • Sestavení a odeslání zpráv • Odeslání zpráv s různou periodou • Posílaní lifetime (čítače zpráv) • Pro testovací účely umožnit nastavit hodnoty posílaných zpráv z diagnostického nástroje.


23

Diagnostika Knihovna poskytuje rozhraní pro volání diagnostických služeb ze servisního nástroje TST. Diagnostické služby jsou povoleny jen v diagnostickém režimu aplikace, aby jejich volání neohrozilo bezpečnost měniče. Rozlišíme dva druhy diagnostických režimů: offline a online. Offline diagnostický režim neumožňuje běh měniče a to proto, že jsou v rámci něj volány diagnostické služby, které by mohly být pro měnič nebezpečné (například testování pulzů či změnu spínací frekvence). Online diagnostický režim oproti tomu umožní běh měniče a využití pouze takových služeb, které jeho chod neohrozí. Tento režim je používán, je-li třeba provádět dané ladící operace přímo za běhu měniče (například ladění konstant PID regulátorů). Knihovna poskytne jednoduchou a přehlednou možnost jak spustit konkrétní diagnostické služby ze servisního nástroje TST.

Pomalá smyčka Tato knihovna se stará o spouštění úloh s nižší prioritou a nižšími nároky na frekvenci výpočtu. Úlohy vykonávané na této smyčce jsou částečně aplikačně závislé, je tedy potřeba poskytnout rozhraní pro jejich nastavení z aplikace. Dále knihovna musí umožňovat zvolit decimaci volání některých vykonávaných z důvodů ušetření času pokud není potřeba volat úlohu pokaždé. Dále se knihovna postará o měření periody spouštění smyčky a délky trvání výpočtu na pomalé smyčce. Maximální perioda a délka trvání se zaznamená pro diagnostické a ladící účely. Tyto maximální hodnoty je potřeba umožnit vynulovat na povel z diagnostického nástroje.

Rychlá smyčka Účelem knihovny je volat úlohy s nejvyšší prioritou a nejvyššími nároky na takt výpočtu. Smyčka běží na přerušení od AD převodníků procesoru - volá se po dokončení převodů tak, aby informace pro regulační výpočty byly aktuální. Úlohy volané na rychlé smyčce jsou částečně aplikačně závislé, knihovna proto musí poskytnout rozhraní pro jejich nastavení. Musí být umožněna i decimace volání úloh za účelem šetření výpočetního času. Dále se knihovna postará o měření periody spouštění smyčky a délky trvání výpočtu úloh volaných na rychlé smyčce. Maximální perioda a délka trvání se zaznamená pro diagnostické a ladící účely. Tyto maximální hodnoty je třeba mít možnost vynulovat na povel z diagnostického nástroje. Knihovna se postará o inicializaci a resetování hardwarového watchdogu pro zvýšení bezpečnosti aplikace.

Záznam postmortů Cílem knihovny je zaznamenání postmortů do persistentní flash paměti, aby byly k dispozici i po restartu aplikace pro diagnostické účely. Postmort je v podstatě záznam průběhu fyzikálních veličin či stavových proměnných, zachycený při poruchové události měniče. Slouží ke zjištění příčin poruchy. Tato knihovna poskytuje rozhraní k nastavování proměnných pro zápis do postmortu, umožní zadání povelu k uložení záznamu do flash (trigger) a také umožní

24


ze servisního nástroje nastavit takzvaný uživatelský trigger, což je v podstatě podmínka pro uložení záznamu i mimo poruchový stav. Tento uživatelský trigger umožní nastavit proměnnou, která se kontroluje, její hodnotu při níž se zapíše záznam do flash, sestupnou či vzestupnou hranu.

4.1.2

Ne-funkční požadavky

• Maximálně je možné využít RAM procesoru TMS320F2809, tedy 18 K x 16b. • Maximálně je možné využít FLASH procesoru TMS320F2809, tedy 128 K x 16b. • Rychlá smyčka musí být svázána s přerušením od dokončení AD převodů. • Analogové veličiny ve formátu fixed point 1.15, tedy bez použití floating point unit. • Použitý operační systém: Systém Poll 2. generace s mikrokernelem FreeRTOS. • Použitý programovací jazyk je C++. • Alokace paměti je možná pouze při inicializaci aplikace. • Software musí dodržovat drážní normu ČSN EN 50128 [1].

4.2

Návrh implementace

Implementace frameworku bude rozdělena do knihoven podle jejich funkčnosti. Toto rozdělení volně vychází z analýzy požadavků, nicméně některé knihovny bude nutné přidat pro režijní účely. Návrh bude probíhat pomocí UML diagramů. K jejich tvorbě bude použit nástroj Enterprise Architect [11]. Návrh rozdělím na tyto části:

• Návrh základní struktury aplikace - smyčky ve kterých běží celý výpočet • Návrh struktury aplikace pro samotné řízení měniče • Návrh řídících stavových automatů aplikace i měniče • Návrh jednotlivých knihoven

4.2. NÁVRH IMPLEMENTACE

4.2.1

25

Struktura aplikace

Výpočet aplikace bude rozdělen na dvě hlavní výpočetní vlákna, rychlou a pomalou smyčku. Tyto smyčky jsou volané s definovanou periodou, priorita běhu je vyšší u rychlé smyčky. Obsluha chybových událostí (zásahů ochran) má samostatné přerušení aby se minimalizoval čas mezi vznikem zásahu a odpovídajícím opatřením. Rychlá smyčka slouží k výpočtu úloh, které jsou časově kritické. Jedná se o fyzikální výpočty regulačních úloh, vyčítání výsledků AD převodů použitých v těchto výpočtech, vyhodnocení softwarových ochran, zápis do generátoru impulzů a podobně. Rychlá smyčka je spouštěna v taktu který je určen povahou regulační úlohy (většinou se perioda rychlé smyčky pohybuje v řádu desítek mikrosekund) a je tedy potřebné, aby veškeré výpočty na ní spouštěné byly časové optimalizovány. Celá smyčka poběží na přerušení od dokončení AD převodů procesoru, což minimalizuje dopravní zpoždění mezi měřením a fyzikálním výpočtem. Pomalá smyčka slouží k výpočtu časově méně kritických úloh. Její perioda je pevně nastavená na 1 ms. Implementována bude jako task FreeRTOSu, který bude v taktu 1 ms probouzen v rámci obsluhy přerušení od časovače procesoru. Přerušení od zásahu ochran má za úkol především okamžitě ukončit běh měniče, kterého se tato ochrana týká, a zaznamenat informaci o konkrétním zásahu aby zbytek aplikace mohl adekvátně reagovat. Diagram tříd návrhu smyček lze vidět na obrázku 4.1. Pro společné vlastnosti smyček jako je měření délky trvání nebo periody či decimace volání úloh, bude použit společný předek FunctionLoop. Obě smyčky budou obsahovat volání funkcí update čímž budou spouštět funkčnosti z ostatních knihoven, které dědí z třídy Module.

26


Obrázek 4.1: Diagram třid - smyčky


4.2.2

27

Struktura řízení měniče

Základní úlohou této části aplikace je poskytnout univerzální a přitom dobře nastavitelné rozhraní pro implementaci regulačních úloh tak, aby se aplikační programátor nemusel zbytečně zabývat implementací opakujících se struktur. Regulační úlohy bývají rozličné povahy a není smyslem tohoto frameworku se jimi zabývat, nicméně lze identifikovat určité společné rozhraní pro všechny typy regulačních úloh. Aplikace musí zvládat obsloužit více regulačních úloh, teoreticky libovolný počet, prakticky použitelný počet regulačních úloh se však pohybuje v menších jednotkách. Každá úloha vyžaduje vlastní stavové automaty řízení měniče a řízení regulace (o těchto automatech podrobněji níže), dále obslužnou funkci zásahu ochran, vyhodnocení zadání, výpočet regulace a generátor impulzů. Pro zjednodušení vzájemné kooperace těchto knihoven bude použit návrhový vzor Mediator, pomocí kterého budou jednotlivé knihovny komunikovat mezi sebou ale i komunikovat jako jednotný celek do ostatních částí aplikace. Diagram 4.2 zjednodušeně ukazuje (kompletní diagram lze najít v příloze na DVD, zde je kvůli velikosti zobrazen bez výčtu operací a atributů) strukturu interakce knihoven použitých k řízení měniče. Z diagramu je patrné, že nedochází k příme komunikaci mezi knihovnami, ale pouze přes Mediator (v tomto případě třída Converter ). Díky tomu dojde k eliminaci mnoha vzájemných vazeb. Také je patrné, že v případě nutnosti přidání dalšího kolegy do této struktury by bylo nutné upravit pouze třídu Converter a nikoliv ostatní kolegy, které by změna zasáhla až v případě, že by s novou třídou potřebovaly komunikovat.

Obrázek 4.2: Zjednodušený diagram tříd - struktura řízení měniče

28


4.2.3

Řízení aplikace a stavové automaty

Řízení aplikace je rozděleno do třech stavových automatů, z nichž jeden je univerzální pro celou aplikaci a dva se starají o řízení konkrétního měniče, kterých může být v aplikaci více a v tom případě pro každý měnič budou v aplikaci existovat instance těchto stavových automatů. Stavový automat řízení aplikace je jeden společný pro celou aplikaci a bude implementován za použití návrhového vzoru Singleton. Obsahuje tyto stavy: • Inicializace, v tomto stavu se vykonává inicializace částí aplikace a je zabráněno spouštění úloh které vyžadují plně inicializovaný stav • Klid, v tomto stavu se čeká na rozběh regulace • Aktivní stav, v tomto stavu se vykonávají regulace a je bráněno všem aktivitám které by mohly jejich běh narušit (diagnostické služby a podobně) • Diagnostika, v tomto stavu je umožněno vykonávat diagnostické služby Přechody mezi jednotlivými stavy: • Inicializace -> Klid, po dokončení inicializace všech částí aplikace • Klid -> Diagnostika, na žádost o diagnostický režim ze servisního nástroje • Klid -> Aktivní stav, pakliže běží alespoň jedna regulace • Aktivní stav -> Klid, pokud byly ukončeny všechny regulace • Diagnostika -> Klid, na žádost o ukončení diagnostického režimu ze servisního nástroje


29

Obrázek 4.3: Stavový diagram řízení aplikace Stavový automat řízení měniče se stará o vyhodnocení podmínek k povolení rozběhu regulační úlohy a také o dočasné či trvalé odstavení měniče z důvodu zásahu ochran. Automat má tyto stavy:

• Kontrola – v tomto stavu se vyhodnocují podmínky pro povolení rozběhu regulace • Klid - jsou splněny podmínky pro povolení regulace a čeká se na rozběh • Běh – běží regulace měniče, kontrolují se podmínky pro odstavení • Dočasné odstavení – měnič je blokován zásahem ochran, kontroluje se zda zásah stále trvá • Trvalé odstavení – měnič je odstaven po opakovaném zásahu ochran. Kontrolují se podmínky pro opuštění trvalého odstavení

Umožněny jsou tyto přechody mezi stavy:

• Kontrola –> Klid, pokud není aktivní zásah ochran po definovanou dobu • Kontrola –> Dočasné odstavení, pokud během definované doby zasáhnou ochrany měniče

30


• Klid -> Dočasné odstavení, pokud dojde k zásahu ochran • Klid -> Běh, pokud dojde ke spuštění příslušené regulace • Běh -> Dočasné odstavení, pokud dojde k zásahu ochran • Běh -> Klid, pokud dojde k ukončení příslušné regulace standardním způsobem • Dočasné odstavení -> Kontrola, po odeznění zásahu ochran a uplynutí ochranné doby • Dočasné odstavení -> Trvalé ostavení, pokud je překročen maximální povolený počet zásahů ochran • Trvalé odstavení -> Kontrola, pokud uplyne definovaná doba bez zásahu ochran a aplikace je v diagnostickém režimu nebo přijde externí povel k opuštění trvalého odstavení

Obrázek 4.4: Stavový diagram řízení měniče Stavový automat regulace se stará o zapínání a vypínání konkrétní regulační úlohy a inicializaci regulačních struktur. Rozlišují se tyto stavy regulace: • Inicializace - probíhá inicializace regulačních struktur • Klid – regulační úloha neběží, čeká se na splnění podmínek k povolení rozběhu • Rozběh – regulace se rozbíhá • Běh – běh regulace v ustáleném stavu • Doběh – regulace dobíhá, probíhá příprava na vypnutí


31

Přechody mezi stavy jsou umožněny takto:

• Inicializace -> Klid, po dokončení inicializace regulačních struktur • Klid -> Inicializace, pokud je vyhodnocen stav měniče neslučitelný s provozem (zásah ochran a podobně) • Klid -> Rozběh, pokud jsou splněny všechny podmínky k povolení běhu regulační úlohy • Rozběh -> Běh, po dosažení ustáleného stavu • Rozběh -> Doběh, pokud není žádost o běh regulační úlohy • Rozběh -> Inicializace, pokud je vyhodnocen stav měniče neslučitelný s provozem (zásah ochran a podobně) • Běh -> Doběh, pokud není žádost o běh regulační úlohy • Běh -> Inicializace, pokud je vyhodnocen stav měniče neslučitelný s provozem (zásah ochran a podobně) • Doběh -> Běh, pokud dojde k obnovení žádosti o běh regulace • Doběh -> Inicializace, po dokončení přípravy na vypnutí regulace

Obrázek 4.5: Stavový diagram řízení regulace

32

4.2.4


Návrh knihoven

Návrh všech knihoven a vazeb mezi nimi je popsaný diagramem tříd, který lze v kompletní verzi kvůli jeho velikosti najít na DVD příloze této práce. V této sekci se zaměřím na popis knihoven jednotlivě a složitější vazby mezi knihovnami popíši pomocí zjednodušených diagramů tříd (například bez výčtu atributů či operací, nebo s nekompletní sadou potomků určité třídy). Jelikož pro korektní běh regulačních úloh je nutné počkat na dokončení inicializace všech knihoven a u některých může být inicializace poměrně dlouhá a její korektní proběhnutí vyžaduje běh rychlé i pomalé smyčky (příkladem může být knihovna kalibrace, která ve variantě výpočtu offsetu za běhu používá vzorky poskytnuté činností knihovny AD převodníků), musí být nějakým způsobem zajištěna informace o dokončení inicializace všech knihoven. Proto budou všechny knihovny používané ve smyčkách dědit od společného předka (třída Module), který tuto funkcionalitu zajistí.

4.2.4.1

Zpracování výsledků AD převodů

Zpracování výsledků AD převodů zahrnuje vyčítání výsledků z registrů procesoru a následné operace s nimi (počítání filtrů, eliminace kalibračních offsetů, různé výpočty a transformace). Diagram 4.6 zjednodušeně (z důvodu velikosti neobsahuje všechny funkcionality knihovny, operace a atributy) ukazuje vztah mezi jednotlivými funkčnostmi a třídou Adc, jejíž metody update jsou volány z pomalé a rychlé smyčky. Od plně objektového návrhu bude v implementaci pravděpodobně nutné upustit kvůli časové náročnosti (obsahuje mnoho časově náročných volání virtuálních funkcí), nicméně smysl tohoto návrhu bude muset být zachován.

Obrázek 4.6: Diagram tříd knihovny AD převodů


4.2.4.2

33

Kalibrace měření

Knihovna kalibrace je úzce propojena s knihovnou AD převodů, jelikož výsledky této knihovny používá a poskytuje jí hodnoty offsetů pro jejich eliminaci. Jelikož existují dva typy kalibrace s určitými společnými vlastnostmi, budou mít společného předka, jak ukazuje diagram 4.7. Ze smyček budou volány metody update třídy Cal, ta bude posléze, volat metody jednotlivých kalibrací.

Obrázek 4.7: Diagram tříd knihovny kalibrace

34

4.2.4.3


Logické vstupy a výstupy

Jedná se o dvě samostatné knihovny, které jsou si nicméně velmi podobné z hlediska návrhu i funkčnosti. Logické vstupy i výstupy bude reprezentovat vždy jedna třída jako rozhraní používané v rychlé a pomalé smyčce, tyto třídy budou volat metody občerstvení jednotlivých logických signálů.

Obrázek 4.8: Diagram tříd knihovny logických vstupů

Obrázek 4.9: Diagram tříd knihovny logických výstupů

4.2.4.4

Softwarové ochrany

Tato knihovna obstarává kontrolu a vyhodnocení softwarových ochran (typicky porovnání naměřené hodnoty s maximální či minimální povolenou). Po vyhodnocení zásahu dojde k vyvolání přerušení. Knihovna obsahuje třídu Esw, pro níž je použit návrhový vzor Singleton, a jejíž metody jsou volány z rychlé a pomalé smyčky. Tato třída pak volá metody update jednotlivých ochran, které mají společného předka, třídu Esw_common, který implementuje společné vlastnosti všech softwarových ochran. Diagram 4.10 ukazuje zjednodušený diagram tříd této knihovny, neobsahuje všechny funkcionality. Kompletní diagram lze najít na DVD příloze.


35

Obrázek 4.10: Diagram tříd knihovny softwarových ochran

4.2.4.5

Struktura řízení měniče

Struktura řízení měniče a interakce mezi knihovnami byly již popsány výše. Podrobné diagramy všech tříd této skupiny tříd lze najít v digitální příloze této práce. Zde za zmínění stojí využití návrhových vzorů Mediator pro interakci mezi objekty a vzoru Template Method pro aplikační specifika třídy Gzi (generátor impulzů).

4.2.4.6

Interní komunikace CAN

Činnost knihovny interní komunikace po CAN lince bude zajištěna třídou CAN_internal, která bude ve smyčce obsluhovat přijímané i odesílané zprávy. Třída obsahuje ukazatel na linkovou vrstvu komunikace, které předává data pro odesílané zprávy a získává z ní data přijímaných zpráv. Třída dále obsahuje ukazatele na instance jednotlivých zpráv, jejichž metody jsou ve smyčce volány. Přijímané i posílané zprávy mají společného předka který obsahuje jejich společnou funkcionalitu. Diagram 4.11 zobrazuje návrh knihovny na úrovni tříd. Pro aplikačně specifické vlastnosti knihovny jako je vlastní plnění zpráv daty nebo zpracování přijatých informací, bude použit návrhový vzor Template Method. Díky tomu bude aplikačnímu programátorovi stačit podědit tuto třídu a pouze implementovat abstraktní metody init_messages(), get_data() a fill_data().

36


Obrázek 4.11: Diagram tříd knihovny intenrí komunikace CAN


4.2.4.7

37

Diagnostika

Tato knihovna obsahuje definice a implementace diagnostických služeb, které jsou potřebné pro každou aplikaci. Další diagnostické služby budou definovány na aplikační úrovni, pro toto rozdělení bude použit návrhový vzor Template Method. Dále je nutné mít pouze jedinou instanci diagnostiky v aplikaci, proto bude použit i návrhový vzor Singleton.

Obrázek 4.12: Diagram tříd knihovny diagnostiky

4.2.4.8

Záznam postmortů

Knihovna záznamu postmortů se stará o nastavení a záznam aplikačních proměnných při z pravidla poruchových či jinak významných událostech. O tuto funkčnost se postará třída Pomo. V aplikaci je žádoucí pouze jedna instance této třídy, nabízí se tedy použití vzoru Singleton.

Obrázek 4.13: Diagram tříd knihovny záznamu postmortů

38


Kapitola 5

Realizace V této kapitole bych se nejprve zaměřil na stručný popis použitých nástrojů k implementaci a posléze na popis uložení zdrojových kódů a zajímavé části z implementace knihoven.

5.1

Použité nástroje k implementaci

• Programovací jazyk C++ a překladač CGT C2000 5.2.2 • Integrované vývojové prostředí Eclipse Indigo 3.7.2 • Servisní nástroj Tunning and Service Tool 3.10.14

5.1.1

C++ a překladač CGT C2000 5.2.2

C++ je objektově orientovaný jazyk, který vznikl z neobjektového jazyka C. C++ je staticky typovaný, kompilovaný jazyk. Díky jeho rychlosti v porovnání s vyššími programovacími jazyky a podpoře od výrobců mikrokontrolerů, je pro vývoj real-time aplikací jeho použití vhodné. Při vývoji mi vypomáhaly knihy Od c k C++ [5] a Jazyky C a C++ [4]. Použitý překladač pro procesory Texas Instruments [12] rodiny TMS320F28xx je CGT C2000 ve verzi 5.2.2.

5.1.2

Eclipse Indigo 3.7.2

Eclipse IDE [7] je velmi flexibilní open-source nástroj, který díky rozšiřitelnosti pomocí pluginů nabízí široké možnosti při vývoji software. Podpora vývoje v programovacím jazyku 39

40

KAPITOLA 5. REALIZACE

C++ je zajištěna pomocí nástroje CDT [6]. Vývoj aplikací pro systém Poll 2. generace je na vývojovém prostředí Eclipse takřka založen a bude v něm probíhat i vývoj tohoto frameworku.

5.1.3

Tunning and Service Tool

Tunning and Service Tool [13], neboli TST, je interní nástroj firmy Poll [9] používaný k vývoji, diagnostice a pro distribuci k zákazníkovi s výrobky založenými na systému Poll 2. generace. Umožňuje sledovat všechny proměnné v aplikaci, zobrazovat je do grafu, přepisovat hodnoty proměnných, které jsou uloženy ve speciální zapisovatelné sekci RAM a tím ovlivňovat chod aplikace, aktualizovat software přes internet a nahrávat jej do zařízení přes diagnostickou linku (USB, RS232, Ethernet), vyčítání a nastavení podrobného záznamu dat a další rozličné funkce. Jedná se o nezbytný nástroj pro efektivní vývoj aplikací.

5.2

Uložení zdrojových kódů

Zdrojové kódy knihoven pro tento framework jsou uloženy na společném repositáři verzovacího systému Subversion a do aplikace jsou vkládány přes funkci Subversion externals. Pomocí tohoto nástroje se v aplikaci určí verze jednotlivých knihoven, které se mají do projektu přidat a Subversion si zdrojové kódy stáhne z repositáře. Zdrojové kódy pro tento framework se budou stahovat do adresáře /lib/conv/název knihovny/.

5.3

Implementace knihoven

Popis implementace knihoven rozdělím do skupin podle podobného účelu. Jelikož implementace je velmi rozsáhlá, nebudu ji zde popisovat dopodrobna ale uvedu jen zajímavé části. Zájemce o kompletní popis implementace odkazuji na zdrojové kódy přiložené na DVD nebo na automaticky generovanou dokumentaci Doxygen, která je také k dispozici na DVD příloze této práce.

5.3.1

Knihovna Module

Knihovna Module obsahuje společného předka všem knihovnám. Aby bylo možné rozpoznat jestli inicializace všech knihoven již proběhla, je ve společném předku zaveden statický čítač, který se v konstruktoru inkrementuje a dekrementuje se po zavolání metody initDone(). Když čítač dosáhne nuly, jsou všechny knihovny inicializované. Tento přístup je velmi výhodný, jelikož nevyžaduje žádný seznam inicializovaných objektů a tím velmi podstatně šetří paměť.

5.3. IMPLEMENTACE KNIHOVEN

5.3.2

41

Smyčky

Implementace smyček je rozdělena do tří knihoven. Jedná se o knihovnu Loops, která implementuje společné vlastnosti rychlé i pomalé smyčky, knihovnu pomalé smyčky SlowLoop a knihovnu rychlé smyčky FastLoop. Ve společné knihovně je implementována třída FunctionLoop, která implementuje vlastnosti jako jsou výpočet periody volání smyčky, výpočet délky trvání, čítač průchodů smyčky a podobně. Třídy SlowLoop a FastLoop jsou potomci třídy FunctionLoop. Pomalá smyčka implementována jako task FreeRTOSu a je spouštěna periodicky od přerušení časovače procesoru. Rychlá smyčka se celá odehrává na přerušení od dokončení AD převodů procesoru. AD převody jsou synchronizovány s periferií PWM procesoru. Nastavení funkcí volaných z obou smyček je implementováno pomocí X-maker. Oproti objektovému přístupu je tím zajištěno, že volané funkce nemusí být virtuální a smyčka si nemusí udržovat seznam funkcí které má volat, šetří se tedy výpočetní čas i paměť. Především na rychlé smyčce je šetření času kritické.

5.3.3

AD převodníky a kalibrace

V implementaci knihovny Adc bylo nutné se vzdálit od objektového návrhu kvůli nemožnosti objektově vytvářet globální proměnné, které jsou u výsledků AD převodů potřeba. Dalším důvodem je i rychlost výpočtu. Proto veškeré nastavení probíhá pomocí X-maker. Při volání X-maker se generují tyto části kódu: • Deklarace globálních proměnných • Deklarace externu globálních proměnných • Deklarace členských proměnných třídy Adc • Inicializace členských proměnných třídy Adc • Vyčtení/výpočet hodnoty • Deklarace a implementace diagnostických služeb (v knihovně diagnostiky) Pomocí X-maker se nastavuje i knihovna kalibrace (Cal). Generují se tyto části kódu: • Deklarace globálních proměnných

42


• Deklarace externu globálních proměnných • Vytvoření instance kalibrace • Eliminace offsetu (v knihovně Adc)

5.3.4

Logické vstupy a výstupy

Implementace logických vstupů a výstupů je rozdělena do dvou knihoven. Jedná se o knihovny Lin (logické vstupy) a Lout (logické výstupy). Samotnou implementací jsou si knihovny velmi podobné. Implementace odpovídá návrhu, nastavení logických vstupů a výstupů je zajištěno pomocí X-maker. Při vložení logického vstupu nebo výstupu pomocí X-maker se generují následující části kódu: • Deklarace globální proměnné s hodnotou vstupu/výstupu • Deklarace externu globální proměnné pro její použití v jiných souborech. • Deklarace členské proměnné ve třídě Lin/Lout reprezentující logický vstup/výstup • Inicializace členské proměnné • Deklarace diagnostických služeb (v knihovně diagnostiky) • Implementace diagnostických služeb (v knihovně diagnostiky)

5.3.5

Ochrany

Ochrany zahrnují dvě knihovny, hardwarové (Ehw) a softwarové ochrany (Esw). Knihnovna Ehw obsahuje pouze nastavení hardwarových ochran a jejich návaznosti na řízené měniče. Za běhu programu se žádný kód nevykonává, zásah je vyvolán hardwarově periferií PWM procesoru. V implementaci knihovny Esw došlo k drobnému odklonu od objektového návrhu. Není přípustné pro vyhodnocení každé ochrany volat virtuální funkci, došlo by k přílišnému prodloužení doby výpočtu rychlé smyčky. Softwarové ochrany jsou implementovány tak, aby jejich nastavení bylo prováděno pomocí X-maker. Při každém volání X-makra se generují tyto části kódu:

5.3. IMPLEMENTACE KNIHOVEN

43

• Deklarace členské proměnné třídy Esw • Inicializace členské proměnné • Vyhodnocení ochrany • Deklarace diagnostické služby (v knihovně diagnostiky) • Implementace diagnostické služby (v knihovně diagnostiky) • Generování struktur s příznaky zásahu ochran (v knihovně obsluhy zásahu ochran)

5.3.6

Obsluha zásahu ochran

Oblsuha zásahu ochran je implementována v knihovně Fault. Obsluha je spouštěna po vyvolání přerušení od periferie PWM procesoru. Při zásahu se volá metoda loop() ve třídě Fault, ve které se uloží příznaky zásahu ochran (typ ochrany která přerušení vyvolala) a podle nastavení ochran se volají obslužné metody jednotlivých měničů. Příznaky ochran jsou generovány automaticky pomocí maker knihoven Esw a Ehw, o nastavení této knihovny se aplikační programátor nemusí starat, vše proběhne automaticky.

5.3.7

Řízení měniče

Řízení měniče zahrnuje celkem 7 knihoven. Jedná se o knihovny Regulace (Reg), žádosti (Req), stavový automat regulace (Rlog), stavový automat měniče (Clog), generátor impulzů (Gzi), obsluhu zásahu ochran (FaultSpec) a mediator pro usnadnění komunikace mezi knihovnami (Converter). Knihovny Reg a Req neobsahují žádnou funkcionalitu, pouze definují rozhraní které musí být implementováno v aplikaci. Knihovna Gzi aplikuje návrhový vzor Template Method a implementuje zapínání a vypínání pulzů, diagnostické funkce jako například nastavení deadtime nebo minimálního a maximálního pulzu, testovaná pulzů a podobně. Stavové automaty jsou pro snížení paměťových nároků implementovány napevno v programu (pomocí konstrukcí switch) a jejich modifikace je proto poměrně složitá. Výhodou je velmi nízká náročnost na paměť RAM. Knihovna FaultSpec se stará o vypnutí pulzů při zásahu ochran a vnutí stavovým automatům patřičnou reakci (ukončení činnosti regulace, přechod do odstavení).

44


Třída Converter sloužící jako mediator pro komunikaci mezi těmito knihovnami se stará o přeposílání požadavků od jedné knihovny na druhou. Prakticky to vypadá tak, že knihovny mezi sebou nekomunikují přímo, ale přes třídu Converter. To představuje při běhu programu drobné zdržení (minimalizované díky inline funkcím ve třídě Converter ), ale komunikační schéma knihoven je přehlednější.

5.3.8

Interní komunikace CAN

Knihovna interní komunikace po CANu (Can_internal) je implementována podle návrhu. Jsou použity návrhové vzory Singleton a Template Method, v aplikaci je nutné vytvořit potomka třídy a implementovat metody init_messages(), fill_data() a get_data(). Nastavení knihovny se kromě vytvoření potomka provádí i pomocí maker, kterými se definují například parametry komunikace jako bitrate a podobně.

5.3.9

Záznamník postmortů

Knihovna záznamníku dat (Pomo) je implementována s využitím návrhového vzoru Singleton. Velká část funkčnosti je aplikačně závislá a musí být implementována až v aplikaci. Zde je definováno rozhraní pro komunikaci s ostatními knihovnami a implementována funkčnost uživatelského triggeru, pomocí níž si uživatel muže ze servisního nástroje definovat okolnosti při kterých se záznam uloží (muže zvolit hodnotu proměnnou, její hodnotu při které se záznamu uloží, jestli chce reagovat na vzestupnou či sestupnou hranu a podobně).

5.3.10

Diagnostika

Implementace knihovny diagnostiky (Diag) se skládá z třídy Diag a výčtového typu se seznamem diagnostických funkcí (servisní nástroj umožňuje u výčtových typů zadávat pomocí výběru v menu). Standardně jsou implementovány tyto diagnostické funkce: • Nastavení všech knihoven do původního stavu • Diagnostické nastavení hodnoty logických vstupů • Diagnostické nastavení hodnoty logických výstupů • Diagnostické nastavení výsledků AD převodů • Diagnostika CANu (manuální posílání dat a podobně) Třída Diag je implementována jako Singleton.

Kapitola 6

Testování V této kapitole se budu zabývat testováním jednotlivých knihoven, jejich částí i jejich integrací do funkčního celku. Účelem je ověřit funkčnost veškerého implementovaného kódu ale také jeho použitelnost u reálných projektů, posouzení jeho kvality s ohledem na výpočetní a paměťovou náročnost.

6.1

Testování knihoven

K testování jednotlivých knihoven se budu snažit použít metodu Unit testing, která ovšem nebude použitelná pro všechny knihovny a jejich části. Kvůli speciálnímu překladači C++ pro procesory Texas Instruments [12] není možné použít standardní nástroje pro generování testů. Bohužel ani většina nástrojů pro testování real-time aplikací tento specifický procesor nepodporuje. Bez nástrojů jako jsou mock objects není možné provádět efektivní unit testing složitějších knihoven. Proto testování ostatních knihoven neprobíhalo podle předem definovaných testů ale za pomocí změn v programu za účelem navození sledovaných podmínek a pozorování patřičné odezvy. Tento způsob ovšem není řádně opakovatelný a je velmi složité pomocí něj obsáhnout všechny případy a možné scénáře. V praktických podmínkách real-time aplikace se ovšem často jedná o jediný způsob jak otestovat některé části aplikačního kódu.

6.1.1

Unit Testing

V případech, kde bylo možné tuto metodu provést i bez použití speciálních nástrojů, tedy u otestování funkcí a tříd, dostatečně jednoduchých aby bylo možné jejich korektní chování ověřit bez nutnosti zasahovat do kódu jiných tříd a funkcí, byly testy proti běžnému postupu připsány do kódu a překládány podmíněně pomocí direktivy preprocesoru. Definováním 45

46

KAPITOLA 6. TESTOVÁNÍ

makra UNIT_TESTING se aplikace přeloží ve stavu přizpůsobeném k právě tomuto testování. To znamená, že se nespouští rychlá ani pomalá smyčka, neprovede se inicializace aplikace jako za běžného stavu, ale provede se inicializace osamostatněných objektů určených k otestování a zavedou se proměnné s výsledky testů. Test proběhne automaticky po startu aplikace a jeho výsledky lze pozorovat ze servisního nástroje TST. Příkladem knihovny, kde se dal tento postup použít je knihovna softwarových ochran a v ní konkrétně jednotlivé třídy vyhodnocující určitý typ zásahu. Následující ukázka unit testingu ukazuje testování třídy Esw_min_hyst (konkrétně metoda update()), která se stará o vyhodnocení zásahu ochrany na minimální povolenou hodnotu veličiny s hysterezí. Test metodě vkládá různé hodnoty a porovnává vrácený výsledky s očekávanou hodnotou. Pro jednu hodnotu mohou nastat kvůli hysterezi různé výsledky, záleží i na předchozích hodnotách. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

/∗ ∗ vysledky testu ∗/ t_uint64 results = 0 ; /∗ ∗ i d prave provadeneho t e s t u , po kazdem p r o v e d e n i s e i n k r e m e n t u j e ∗/ t_uint16 testID = 0 ; # define TEST( esw , val ue , e x p e c t e d ) do{ r e s u l t s |= \ ( ( ( t_uint64 ) ( ( esw−>update ( value ) == expected ) ? 1 : 0 ) ) << testID ) ; \ testID++; \ } while ( 0 ) void test ( ) { /∗ ∗ ∗/

T e s t o v a n i ochrany na m i n i m a l n i hodnotu s h y s t e r e z i // v y t v o r e n i i n s t a n c e t r i d y ochrany /∗ p r v n i parametr j e i d ochrany , druhy u r c u j e z d a l i s e p r i zasahu ∗ zaznamena postmort , t r e t i parametr j e m i n i m a l n i p o v o l e n a hodnota , ∗ p o s l e d n i parametr j e h l a d i n a h y s t e r e z e ∗/ Esw_min_hyst ∗ esw_min_hyst = new Esw_min_hyst ( 0 , 1 , 1 0 0 0 , 2 0 0 0 ) ; TEST ( esw_min_hyst , 5 0 0 0 , 0 ) ; TEST ( esw_min_hyst , 2 0 0 0 , 0 ) ; TEST ( esw_min_hyst , 1 0 0 1 , 0 ) ; TEST ( esw_min_hyst , 1 0 0 0 , 1 ) ; TEST ( esw_min_hyst , 9 9 9 , 1 ) ; TEST ( esw_min_hyst , 1 0 0 0 , 1 ) ; TEST ( esw_min_hyst , 1 0 0 1 , 1 ) ;

// hodnota nad obemi h l a d i n a m i // hodnota v h l a d i n e h y s t e r e z e // hodnota mezi h y s t e r e z n i a min . hodnotou // hodnota na u r o v n i minima // pod u r o v n i minima // z p e t na uroven minima // nad u r o v n i minima

6.1. TESTOVÁNÍ KNIHOVEN

36 37 38 39 40 41

}

47

TEST ( esw_min_hyst , 1 9 9 9 , 1 ) ; // pod u r o v n i h y s t e r e z e TEST ( esw_min_hyst , 2 0 0 0 , 1 ) ; // na u r o v n i h y s t e r e z e TEST ( esw_min_hyst , 2 0 0 1 , 0 ) ; // nad u r o v n i h y s t e r e z e TEST ( esw_min_hyst , 3 2 7 6 7 , 0 ) ; // maximalni kladna hodnota TEST ( esw_min_hyst , −32768 ,1) ; // maximalni zaporna hodnota

6.1.2

Ostatní testování

Jak bylo již uvedeno výše, ne všechny knihovny se podařilo testovat standardním způsobem za použití unit testingu. Jelikož struktura aplikace je v některých místech poměrně komplikovaná a spousta metod je časově závislých a kromě vstupních parametrů funkce hrají roli i okolnosti, které se dají velmi špatně předpovídat - například výsledky AD převodníků, časové souvislosti, data získané z komunikačních linek a podobně, nelze unit testing efektivně použít. Otestování knihoven, které se nepodařilo otestovat standardně, probíhalo za pomocí servisního nástroje TST, který umí ovlivňovat běh programu tím, že za běhu aplikace mění hodnotu proměnných umístěných ve speciální sekci paměti RAM. Pomocí těchto proměnných lze nastavit v programu podmínky pro navození situací které je potřeba otestovat. Tento způsob je ovšem značně závislý na předvídavosti a zručnosti programátora. Jelikož se nejedná o pevně definované testování, nelze uvést konkrétní příklady testování s výsledky, ale rád bych na příkladu uvedl postup při tomto testování. Pro toto jsem si vybral knihovnu Kalibrace měření, konkrétně funkčnost kalibrace pomocí zápisu offsetu do externí flash paměti, neboť představuje konkrétní případ, který by pomocí unit testingu bez speciálních nástrojů šel otestovat velmi špatně. Je totiž závislá na mnoha vnějších faktorech: výsledek AD převodu, zápis externě změřené hodnoty ze servisního nástroje TST a samozřejmě také komunikace s externí flash pamětí po SPI. Testování probíhalo takto • Aplikace nastavena tak, aby kalibrovala jednu hodnotu • Spuštění aplikace s prázdnou flash pamětí, pozorování proměnných, zdali se inicializují na správné hodnoty a kalibrační offset je nastaven na 0. • Kontrola, zdali komunikace s flash pamětí proběhla v pořádku (podařilo se vyčíst data, i když prázdná). Tento pokus opakován i s nefunkční komunikací s flash pamětí pro zjištění, zdali je správně vyhodnocena chyba komunikace. • Pokus o zápis kalibrace - záměrně zvolen hodnota mimo povolený rozsah, aby k zápisu nedošlo. Kontrola, jestli je vyhodnocena chyba offsetu. Po restartu aplikace kontroluji, jestli je offset nastaven stále na 0 nikoliv na chybně zadanou hodnotu.

48


• Pokus o zápis kalibrace, tentokrát s přijatelnou hodnotou. Kontrola jestli k zápisu došlo, po restartu aplikace se musí vyčíst offset správně. • Pokus o provedení nové kalibrace. Kontrola jestli je offset vypočítán správně. Nalezena chyba, výpočet offsetu neuvažoval přítomnost předchozího offsetu. • Změna maximálního povoleného offsetu tak, aby předchozí zápis byl neplatný. Kontrola po restartu aplikace jestli je offset nastaven na 0. • V aplikaci změna nastavení kalibrace tak, aby vyžadovala kalibraci dvou veličin a opakování pokusů. Z uvedeného scénáře lze vidět, že tento způsob testování je velmi časově náročný a závislý na scénářích, které je schopen programátor vymyslet. Do budoucna by bylo velmi vhodné zajistit standardizaci testů a zajistit, aby testování bylo prováděno někým jiným, než je programátor dané knihovny. Ten může být svými zkušenostmi z programování ovlivněn a nemusí být schopen chyby odhalit.

6.2

Pilotní aplikace

Pro ověření použitelnosti implementovaného frameworku je nutné praktické vyzkoušení na reálném projektu. Toto ověření dále poslouží k integračnímu otestování knihoven a posouzení splnění záměrů práce, tedy ke zjištění časové náročnosti na implementaci, posouzení výpočetní náročnosti a zjištění míst náchylných na chyby programátora.

6.2.1

Zadání

Pro pilotní aplikaci byl zvolen projekt zvyšovacího měniče napětí z 24 V na 350 V stejnosměrného napětí s označením NZV3502, určeného pro elektrickou jednotku řady 575 (na obrázku 6.1), dodávanou firmou Škoda Transportation do Litvy. Účelem tohoto zařízení je záložní napájení jednofázového střídače 230 V 50 Hz. Střídač je při běžném provozu napájen ze snižovacího měniče, který ovšem při nepřítomnosti napětí v primární síti nemůže dodávat energii. Tento stav je za jízdy vlaku poměrně častý. Střídač napájí automat na kávu a není přijatelné, aby vypínal při každém přejezdu nenapájeného úseku troleje. Pokud by k tomuto docházelo, nemohla by být zaručena korektní obsluha cestujících. Proto je nutné při výpadku napětí okamžitě začít napájet střídač z baterie a k tomuto účelu poslouží právě tento zvyšovací měnič. Zvyšovací měnič pracuje na principu ZVS (Zero voltage switching). Kvůli velkým nárokům na výkon a tím i proud přenášený z baterie budou funkci zvyšovacího měniče zastávat dva paralelní měniče. Tento princip umožní pracovat s polovičním proudem, ovšem na samotné řízení bude náročnější. Je nutné zvládnout řízení dvou měničů v jednom procesoru.

6.2. PILOTNÍ APLIKACE

Obrázek 6.1: Elektrická Jednotka řady 575

49

50


6.2.2

Požadavky

Aplikační software musí zajistit zpracování těchto měřených veličin

• Vstupní napětí • Vstupní proud • Výstupní napětí • Výstupní proud prvního měniče • Výstupní proud druhého měniče • Teplota chladiče • Dohlížení napájení 1.8 V • Dohlížení napájení 3.3 V

Pro zlepšení přesnosti měření budou kalibrovány následující hodnoty:

• Vstupní proud (online kalibrace) • Výstupní proud prvního měniče (online kalibrace) • Výstupní proud druhého měniče (online kalibrace) • Výstupní napětí (offline kalibrace)

Proudy budou po startu aplikace inicializovány na nulu, neboť je jisté, že při neběžící regulaci nebude měničem procházet žádný proud. Výstupní napětí bude kalibrováno zápisem kalibračního offsetu zkušebním technikem do flash paměti. Zařízení obsahuje tyto hardwarové ochrany: • Ochrana vstupu (spojená komparace vstupního proudu a vstupního napětí) • Ochrana výstupu (spojená komparace obou výstupních proudů měniče) • Ochrana napájení Softwarové ochrany budou následující:


51

• Ochrana přepětí na výstupu s hysterezí • Ochrana přepětí na vstupu s hysterezí • Ochrana nadproudu na vstupu • Ochrana nadproudu na výstupu 1 • Ochrana nadproudu na výstupu 2 • Ochrana přehřátí měniče Aplikační software bude obsahovat dva logické vstupy a dva logické výstupy • Výstup - signalizace běhu měniče • Výstup - zapnutí ventilace • Vstup - zapnutí měniče • Vstup - rezerva Při běhu měnič žádá o zapnutí ventilace, aby zamezil vlastnímu přehřívání. Rezervní logický vstup bude zahrnut pro případ jeho možné potřeby. V aplikaci musí být obsluhován pro účely testování. Zvyšovací měnič nebude komunikovat s napájeným střídačem 230V/50Hz, ani jiným externím zařízením po komunikační lince CAN, ovšem pro jistotu bude tato komunikace hardwarově umožněna a aplikační software musí pro testovací účely obsluhu komunikace obsahovat. Bude vysílat jednu zprávu s inkrementujícím čítačem a druhou zprávu bude přijímat, tím bude umožněno zkušebním technikům ověřit funkčnost hardware. Stěžejní částí aplikace je samotná regulační úloha, konkrétně udržení napětí v meziobvodu 350 V. Návrhem regulační struktury se budu zabývat v další sekci. Pro nepřerušovaný chod střídače je potřeba okamžitý náběh zvyšovacího měniče při poklesu napětí v meziobvodu. Měnič ovšem nemusí běžet pokud bude napájen snižovací měnič, což bez přítomnosti CAN komunikace lze zjistit podle hladiny napětí v meziobvodu, kde snižovací měnič má žádanou hladinu napětí o 10 V vyšší. Pokud tedy zvyšovací měnič zjistí přítomnost vyššího napětí v meziobvodu, může svoji činnost ukončit. Další variantou je nechat běžet zvyšovací měnič po celou dobu s tím, že při vyšším napětí ze snižovacího měniče bude proud dodáván právě z něj. Pokud by se obě tyto varianty ukázaly jako neefektivní, bude potřeba doplnit mezi střídač a snižovací měnič CAN komunikaci a zajistit vypínání zvyšovacího měniče podle povelu od střídače nebo snižovacího měniče. Blokové schéma zapojení měničů je vidět na obrázku 6.2.

52


Obrázek 6.2: Blokové schéma zapojení zvyšovacího měniče pro záložní napájení střídače

6.2.3

Návrh

Jak bylo uvedeno výše, aplikační software bude obsluhovat řízení dvou dílčích měničů. Oba měniče jsou svoji činností zcela totožné, nicméně s ohledem na efektivitu řízení bude muset být implementace různá. Na diagramu 6.3 je vidět blokové schéma regulace zvyšovacího měniče. Jelikož obě větve zvyšovacího měniče jsou paralelně spojené, jejich výstupní napětí je totožné a nemá smysl regulovat toto napětí dvakrát, proto bude regulátor implementován pouze u prvního měniče s tím, že jeho výstup bude vydělen dvěmi a sdílen oběma regulátory proudu. Musí být zajištěna korektní práce regulátoru napětí ve všech případech, tedy jak za běhu obou měničů, tak i každého samostatně.


Obrázek 6.3: Blokové schéma regulace zvyšovače NZV3502

53

54

6.2.4


Implementace

K implementaci se v maximální možné míře použije framework popsaný v předchozích částech práce. Proto zde nebudu popisovat detaily implementace, jelikož se jedná o velmi aplikačně specifickou záležitost, ale zaměřím se na způsob použití konkrétních částí frameworku.

6.2.4.1

Struktura zdrojových kódů aplikace

Zdrojové kódy jsou uspořádány do následující adresářové struktury

/lib /conv /... /common /config /src /can_internal /cmd /conv0 /conv1 /diag /main /pomo /slog /defs

6.2.4.2

knihovny frameworku pro řízení měničů adresáře jednotlivých knihoven, linkované přes svn externals obsahuje konfigurační soubory společné pro všechny aplikace ze skupiny (v tom obsahuje konfigurační soubory této aplikace obsahuje zdrojové kódy aplikace zdrojové kódy komunikace po interní lince CAN nastavení linkeru zdrojové kódy pro řízení měniče zdrojové kódy pro řízení měniče zdrojové kódy diagnostiky aplikace inicializace aplikace zdrojové kódy záznamníku dat aplikační logika obsahuje konfigurační soubory frameworku pro řízení měniče

Implementace funkčnosti

Řízení měniče Pro řízení obou měničů bylo nutné vytvořit potomky knihovních tříd reprezentující regulaci (třída Reg), žádost (Req) a generátor impulzů (Gzi) a implementovat jejich funkčnost. V potomcích tříd Reg a Req se jedná o implementaci kompletní funkčnosti, jelikož je zcela aplikačně závislá. Pro korektní spolupráci se stavovými automaty regulace a měniče je nutné správně implementovat virtuální funkce isRegInitDone(), pro zjištění zdali je regulace správně inicializovaná, a v třídě Req funkce isInitDone(), opět pro zjištění dokončení inicializace, isStartDone() a isStopDone(), pro zjištění dokončení rozběhu a doběhu regulační úlohy. V potomkovi třídy Gzi je nutné implementovat metodu writeOpening() (podle vzoru Template


55

Method), která se stará o předání akční veličiny regulace do ovladače periferie PWM procesoru. Výběr akční veličiny se provádí podle stavu ve kterém se měnič nachází, v diagnostice je umožněno ji zadávat ručně ze servisního nástroje. Následující ukázka kódu ukazuje implementaci funkce writeOpening() jednoho měniče. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

void Gzi0 : : writeOpening ( conv : : gzic : : t_gzi_states gzi_state ) { switch ( gzi_state ) { case conv : : gzic : : GZI_STATE_TEST : // d i a g n o s t i k a o f f l i n e , pouze pevne o t e v r e n i − predem n a s t a v e n e . gzi0_phaseShift = 0 ; break ; case conv : : gzic : : GZI_STATE_FIXED : gzi0_phaseShift = math : : q15 : : addSat ( diag_gzi0_phaseShift , reg0_ptr−>getDeadTime_h ( ) ) ; // pevne o t e v r e n i − p r i o n l i n e d i a g n o s t i c e break ; case conv : : gzic : : GZI_STATE_REGULATION : gzi0_phaseShift = reg0_phaseShift ; default : // o t e v r e n i p o d l e z a d o s t i r e g u l a c e break ; } }

m_gzi−>setDutyCyclePhaseShift ( gzi0_phaseShift , 0 , 0 , 0 ) ;

Dále je potřeba vytvořit instance knihovních tříd FaultSpec, Rlog a Clog, které se starají o logiku měniče a obsluhu zásahu ochran. Všechny vytvořené instance je pak nutné propojit pomocí třídy Converter, která je mediatorem podle stejnojmenného návrhového vzoru.

Komunikace CAN Jak je zmíněno v požadavcích výše, přítomnost obsluhy této komunikace je v tomto aplikačním software jen z důvodu zkoušení funkčnosti hardwarové cesty, k praktickým účelům bude použita jen v případě rozšíření požadavků. V aplikačně specifické části je potřeba vytvořit potomka knihovní třídy Can_internal a implementovat funkce init_messages(), fill_data() a get_data() podle vzoru Tempate Method.

56


Diagnostika Pro implementaci diagnostiky jsem opět vytvoři potomka knihovní třídy podle vzoru Template Method. V metodě services_app() je potřeba implementovat žádané diagnostické služby aplikace a v metodě setDefaults_app() je potřeba zajistit návrat všech diagnostikovaných částí aplikace do původního stavu (metoda se volá po opuštění diagnostiky). V aplikačním software jsou implementovány tyto diagnostické služby • Zamaskování vstupního podpětí • Vynucení vstupního podpětí • Test pulzů GZI - start • Test pulzů GZI - stop • Nastavení deadtime GZI • Nastavení konstant regulátoru napětí • Nastavení konstant regulátorů proudu Ostatní diagnostické služby, jako je diagnostické nastavování stavu logických vstupů či výstupů, maskování softwarových ochran a podobně jsou generované automaticky v knihovní třídě.

Záznamník Postmortů Při implementaci záznamníku postmortů do aplikačního software je potřeba vytvořit potomka knihovní třídy Pomo, implementovat metody pro občerstvení záznamu na rychlé a pomale smyčce. V inicializační metodě je potřeba záznamník dat nastavit, tzn. zvolit proměnné pro záznam, takt záznamu a délku doběhu.

Signálová logika Jedná se o zcela aplikačně specifickou funkčnost. Tato část aplikačního software obsahuje například ovládání logických výstupů, vyhodnocuje podmínky pro start regulace a podobně. Implementována může být celkem libovolně, zde jsem se rozhodl vytvořit třídu, která tyto funkčnosti obsahuje a její metoda update() je volána z pomalé smyčky.

Nastavení knihoven Ostatní funkce aplikačního software jsou implementovány pomocí knihoven. Je ovšem nutné tyto knihovny správně nastavit a to pomocí definičních souborů v adresáři defs. Příklad nastavení knihovny kalibrace (soubor cal_def.hh) je zobrazen v následující ukázce kódu.


1 2 3 4 5 6 7 8 9 10 11 12 13 14

57

# include "conv/cal/ conv_cal .hh" # include " config / NZV3502_derived_config .hh" # include " common / NZV3502_project_config .hh" INSERT_CAL_FEATURE ( CAL_ONLINE_FAST , adc_Iout0 , \ 0 , T_FRAC15 ( 1 . 0 / NORMA_IOUT ) ) INSERT_CAL_FEATURE ( CAL_ONLINE_FAST , adc_Iout1 , \ 0 , T_FRAC15 ( 1 . 0 / NORMA_IOUT ) ) INSERT_CAL_FEATURE ( CAL_ONLINE_FAST , adc_Iin , \ 0 , T_FRAC15 ( 1 0 . 0 / NORMA_IIN ) ) INSERT_CAL_FEATURE ( CAL_OFFLINE_FAST , adc_Uout , \ adc_Uout_avg_fir , T_FRAC15 ( 5 0 . 0 / NORMA_UOUT ) )

Tento soubor zavádí kalibraci čtyř měření - dva výstupní proudy, vstupní proud a výstupní napětí. Proudy se automaticky po startu kalibrují na nulovou hodnotu, napětí je kalibrováno zápisem kalibračního offsetu do flash paměti. Podobným způsobem jsou nastavovány knihovny AD převodníků, rychlé a pomalé smyčky, logických vstupů a výstupů, softwarových a hardwarových ochran.

58

6.3


Srovnání s předchozí architekturou

Pro posouzení výhodnosti použití tohoto frameworku je vhodné jeho srovnání s předchozí architekturou software, používanou pro podobné projekty. To jest architekturou, popsanou v bakalářské práci Aplikační část programového vybavení nabíjecí soupravy elektrické motorové jednotky řady 671 ŽSSK [2]. Klíčové parametry pro toto posouzení jsou nároky na výpočetní čas (především délka trvání obsluhy úloh na rychlé smyčce), nároky na paměť (velikost obsazené paměti RAM a paměti Flash) a celkový čas, potřebný na implementaci aplikačního software. Pro věrohodné porovnání výpočetních nároků byl zvolen projekt implementovaný ve zmíněné bakalářské práci - zvyšovací měnič NZV3501. K posouzení časové náročnosti na implementaci byl zvolen projekt pilotní aplikace NZV3502 jako zástupce nové architektury a jako zástupce staré architektury byl zvolen projekt střídače pro napájení zásuvek NZS2312 pro podobnou složitost aplikačního software. Tabulka 6.1 uvádí srovnání uvedených parametrů. Údaje o využití paměti jsou uvedeny v bytech. DRAM je sekce pro staticky alokovaná data, HEAP RAM je sekce pro dynamicky alokovaná data, WARAM sekce pro data přepisovatelné ze servisního nástroje, PRAM je sekce pro kód uložený v RAM. Parametr DRAM HEAP RAM WARAM PRAM RAM celkem FLASH Délka trvání rychlé smyčky (µs) Délka trvání implementace (dny)

Původní architektura 3562 7970 561 2735 14828 47374 14,31 11

Nová architektura 1151 9478 592 2586 13807 43877 13,71(15,63) 2,5

Tabulka 6.1: Porovnání nové a staré architektury Z tabulky je zřejmé, že došlo k výraznému přesunu dat ze statické do dynamické sekce paměti. Také je zřejmé, že došlo k poměrně značnému ušetření paměti RAM, což je důsledkem kvalitnějšího návrhu aplikace. Porovnání délky trvání rychlé smyčky uvádí dva údaje, jelikož společně s novou architekturou došlo i k výrazné časové optimalizaci algoritmu pro záznam postmortů. Jelikož nový algoritmus je použitelný i pro starou architekturu, uvádím pro zachování objektivity u nové architektury délku s původním i novým algoritmem. Zde se dá vypozorovat mírné prodloužení výpočetního času v případě nové architektury. To lze přičíst více objektovému návrhu aplikace a s tím i zvýšení režie. Prodloužení ovšem není kritické. K nejvýraznějšímu posunu došlo u časové náročnosti na implementaci, a to téměř o řád.

Kapitola 7

Závěr Úkolem práce bylo vytvořit univerzální framework, který by umožnil efektivně implementovat aplikace pro řízení elektrických pohonů a výkonové elektroniky za využití principů objektově orientovaného programování. Dalšími dílčími úkoly bylo návrh celého frameworku dokumentovat pomocí UML a využít možnosti automaticky generované dokumentace kódu. Pro praktické vyzkoušení funkčnosti frameworku bylo třeba v něm implementovat aplikačně specifický software reálného zařízení. Při návrhu se podařilo postupovat systematicky od analýzy požadavků přes návrh a implementaci. Návrh je řádně zdokumentován a je dobrou ukázkou že i při vývoji real-time aplikací lze využít UML. Při implementaci frameworku jsem se na několika místech musel od objektového návrhu vzdálit, především kvůli efektivitě výpočtu. Díky použití X-maker se objektově orientované programování podařilo nahradit z hlediska znovupoužitelnosti kódu a usnadnění práce uživateli frameworku. V tomto ohledu se podařilo objektový návrh dokonce překonat, jelikož požadavky na real-time aplikaci především v používání globálních proměnných nemohou být objektovým návrhem zcela uspokojivě splněny. Pro automatické generování dokumentace kódu byl zvolen systém Doxygen. Při použití systému automatického generování dokumentace z kódu bylo nutné se držet pravidel pro psaní komentářů tak, aby mohly být systémem Doxygen zpracovány. Pro ověření použitelnosti frameworku na reálném aplikačně specifickém software byl zvolen projekt zvyšovacího měniče napětí pro záložní napájení střídače 230 V. Implementace tohoto software potvrdila vhodnost použití frameworku pro tento typ aplikací. Ve srovnání s předchozí architekturou podobných aplikací se ukázalo výrazné zkrácení času potřebného pro implementaci. Zároveň se podařilo snížit paměťovou náročnost aplikace, a to díky kvalitnějšímu návrhu a optimalizované implementaci. Výpočetní časová složitost implementace se mírně zvýšila, nicméně tato ztráta je kompenzována použitím více optimalizovaných algoritmů. 59

60

KAPITOLA 7. ZÁVĚR

Méně uspokojivým výsledkem práce je etapa testování. Zde se nepodařilo dosáhnout standardní podoby testování software (například metody Unit-testing) z důvodů malé podpory nástrojů určených pro tento typ testování pro námi používané typy procesorů. Budoucí použití frameworku je závislé na projektech firmy Poll, s.r.o. Počítá se s jeho nasazením na všech projektech podobného charakteru. Příkladem může být napájecí měnič klimatizace nebo nabíjecí skříň pro lokomotivu 91E.

Literatura [1] ČSN EN 50128 (342680) Drážní zařízení - Sdělovací a zabezpečovací systémy a systémy zpracování dat - Software pro drážní řídicí a ochranné systémy, 2003. [2] BRUNA, M. Aplikační část programového vybavení nabíjecí soupravy elektrické motorové jednotky řady 671 ŽSSK, 2010. [3] KRAVAL, I. Design Patterns v OOP. 2002. [4] VIRIUS, M. Jazyky C a C++. 2006. [5] VIRIUS, M. Od C k C++. 2004. [6] web:cdt. Eclipse CDT — domovksá stránka. http://www.eclipse.org/cdt, stav z 15. 4. 2012. [7] web:eclipse. Eclipse — domovksá stránka. http://www.eclipse.org, stav z 15. 4. 2012. [8] web:freertos. FreeRTOS — hlavní stránka. http://www.freertos.org, stav z 15. 4. 2012. [9] web:poll. Poll — hlavní stránka. http://www.poll.cz, stav z 15. 4. 2012. [10] web:securecoding. Understand macro replacement when concatenating tokens or performing stringification. , 22. 2. 2012. citováno 15.4.2012. [11] web:sparxsystems. Sparx Systems — hlavní stránka. http://www.sparxsystems.eu, stav z 15. 4. 2012. [12] web:ti. Texas Instruments — hlavní stránka. http://www.ti.com, stav z 15. 4. 2012. [13] web:tst. Tuning and Service Tool — hlavní stránka. http://tst.poll.cz, stav z 15. 4. 2012. [14] web:wikipediasil. Wikipedia — Safety Integrity Level. http://en.wikipedia.org/wiki/Safety_Integrity_Level, stav z 15. 4. 2012.

61

62

LITERATURA

Příloha A

Seznam použitých zkratek TST Tuning and Service Tool LED Light-emitting Diode OOP Object-oriented programming ADC Analog-to-Digital Converter SPI Serial Peripheral Interface CAN Controller Area Network RAM Random-access memoru CDT C/C++ Development Tooling PWM Pulse Width Modulation UML Unified Modeling Language RTOS Real-Time Operating System SIL Safety Integrity Level IDE Integrated development environment ZVS Zero voltage switching

63

64

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

Příloha B

Obsah přiloženého DVD Z důvodu ochrany autorských práv nejsou přiloženy zdrojovové soubory systémové části programu. V případě zájmu o tyto zdrojové soubory se prosím obraťte na zástupce firmy Poll [9] .

/text /figures /sw /NZV3502 /lib /conv /dist /UML /Doxygen

text diplomové práce v PDF a TeX obrázky k textu zdrojové soubory zdrojové soubory pilotní aplikace zdrojové soubory knihoven frameworku binární soubory - výsledky překladu diagramy UML výstup automaticky generované dokumentace Doxygen

65

Univerzální aplikační software pro řízení pohonů a výkonové elektroniky

Recommend Documents