Master_Thesis

ZÁPADOČESKÁ UNIVERZITA V PLZNI
FAKULTA ELEKTROTECHNICKÁ
KATEDRA APLIKOVANÉ ELEKTRONIKY A TELEKOMUNIKACÍ
DIPLOMOVÁ PRÁCE
vedoucí práce: Ing. KUBÍK Michal
autor: Bc. VEVERKA Stanislav 2010

Anotace
Tato práce se zabývá návrhem modelu vozu Škoda Fabia první generace s motorem 1.2
HTP. Jako vývojové prostředí byl zvolen Matlab/Simulink od společnosti Mathworks. Stručný popis
tohoto prostředí lze nalézt v kapitole číslo dva. Následující kapitola popisuje hlavní vlastnosti
testovacího prostředí PROVEtech:TA od společnosti MBtech group. Tento software může být
použit pro manuální i automatické testování jednotlivých řídících jednotek stejně jako mnoha
jednotek propojených rozsáhlou sítí. Následuje rozsáhlý popis vytvořeného modelu motoru, řídící
jednotky, převodovky a jízdní dynamiky. Poslední kapitola ukazuje vytvořený Layout pro řízení a
vizualizaci manuálního testování a také sada ukázkových testovacích skriptů pro automatizované
testování společně s jejich výsledky.
Klíčová slova
ECU, SIL, HIL, Matlab, Simulink, modelování, testování.
Abstract
This thesis deals with the design of the 1.2 HTP engine model from the Škoda Fabia first
generation vehicle. As modeling environment a Matlab/Simulink tool by Mathworks was used.
A brief description of this environment can be found in chapter number two. The following
chapter describes main features of the PROVEtech:TA testing environment software by MBtech
group. This software can be used for manual and automated testing of a single electronic control
unit (ECU) as well as for testing of several networked units. This is followed by a deep description
of created models of the engine, the ECU, the transmission and vehicle dynamics. The last chapter
gives an overview of created layout for manual control and visualization of testing and also a set
of sample test scripts for automated testing together with result reports of these scripts.
Key words
ECU, SIL, HIL, Matlab, Simulink, Modeling, Testing.

Čestné prohlášení
Předkládám tímto k posouzení a obhajobě diplomovou práci, zpracovanou na závěr studia
na Fakultě elektrotechnické Západočeské univerzity v Plzni. Prohlašuji, že jsem tuto diplomovou
práci vypracoval samostatně, s využitím odborné literatury, materiálů a jiných zdrojů uvedených v
kapitole 7, případně byly informace získány na Internetu. Některé výrazy uvedené v této práci
mohou být ochrannými známkami nebo registrovanými ochrannými známkami jejich případných
vlastníků a uvedením těchto výrazů nejsou žádným způsobem zpochybněna jejich vlastnická
práva. Dále prohlašuji, že veškerý software, použitý při řešené této diplomové práce, je legální.
V Plzni dne 12. 5. 2010 Bc. VEVERKA Stanislav
Poděkování
Na tomto místě bych rád poděkoval Dr. Maňáskovi ze společnosti MBtech Bohemia za
jeho čas a úsilí, které mi v průběhu vytváření této práce věnoval, bez jeho cenných rad a
připomínek by moje práce v této podobě nemohla vzniknout. Dále bych chtěl také poděkovat
vedoucímu mojí práce Ing. Kubíkovi z Katedry aplikované elektroniky a telekomunikací ZČU, jehož
přínos byl taktéž velmi významný. V neposlední řadě také děkuji mojí rodině a přítelkyni za
poskytnutou podporu a zázemí nutnou pro vznik této práce.
Bc. VEVERKA Stanislav

Obsah
1. ÚVOD ........................................................................................................................................... 7
2. SIMULINK ..................................................................................................................................... 8
2.1. VYTVÁŘENÍ MODELŮ ..............................................................................................................................8
2.2. ČAS ....................................................................................................................................................8
2.3. STAVY SYSTÉMU ....................................................................................................................................9
2.3.1. Spojité stavy ......................................................................................................................9
2.3.2. Diskrétní stavy.................................................................................................................10
2.4. ŘEŠITELÉ S PEVNÝM VERSUS ŘEŠITELÉ S PROMĚNLIVÝM KROKEM ...................................................................10
2.5. SPOJITÍ VERSUS DISKRÉTNÍ ŘEŠITELÉ.........................................................................................................10
2.6. SYSTÉMY A SUBSYSTÉMY .......................................................................................................................11
2.6.1. Virtuální subsystémy (Virtual subsystems) .....................................................................11
2.6.2. Nevirtuální subsystémy (Nonvirtual subsystems)...........................................................11
2.6.3. Atomární subsystémy (Atomic subsystems) ...................................................................12
2.6.4. Povolované subsystémy (Enabled subsystems) ..............................................................12
2.6.5. Spouštěné subsystémy (Triggered subsystems) .............................................................12
2.6.6. Subsystémy volání funkce (Function-call subsystems)....................................................12
2.6.7. Povolované subsystémy se spouštěním (Enabled with trigger subsystems) ..................13
2.6.8. Akční subsystémy (Action subsystems)...........................................................................13
2.6.9. Subsystémy podmínky zatímco (While subsystems).......................................................14
2.6.10. Subsystémy podmínky pro (For subsystems)..................................................................14
2.7. ALGEBRAICKÉ SMYČKY (ALGEBRAIC LOOPS)...............................................................................................14
3. PROVETECH:TA........................................................................................................................... 16
3.1. WORKPAGE – PRACOVNÍ PLOCHA ...........................................................................................................17
3.1.1. Okno výběru signálu........................................................................................................18
3.1.2. Úprava a organizace ovládacích prvků............................................................................19
3.2. TEST MANAGER ..................................................................................................................................21
3.2.1. Objekty a struktura Test Manageru ................................................................................22
3.2.2. Vytváření a správa testů..................................................................................................24
3.2.3. Vykonávání testů.............................................................................................................24
3.2.4. Výsledky testů .................................................................................................................25
4. MODEL JÍZDNÍ DYNAMIKY VOZU ŠKODA FABIA......................................................................... 26
4.1. TOP-LEVEL MODEL...............................................................................................................................26
4.2. ECU – ŘÍDÍCÍ JEDNOTKA MOTORU...........................................................................................................28
4.2.1. Regulátor maximálních otáček........................................................................................30
4.2.2. Logika řízení regulátoru maximálních otáček..................................................................31
4.2.3. Regulátor minimálních otáček ........................................................................................32
4.2.4. Logika řízení regulátoru minimálních otáček ..................................................................33
4.2.5. Generování signálu pro nastavení škrticí klapky.............................................................33
4.2.6. Generování signálu pro start motoru..............................................................................34

4.3. ENGINE – MOTOR................................................................................................................................35
4.3.1. Generování krouticího momentu motorem....................................................................36
4.3.2. Ztrátový moment motoru ...............................................................................................38
4.3.3. Spouštěč motoru.............................................................................................................40
4.4. GEARBOX – PŘEVODOVÉ ÚSTROJÍ...........................................................................................................41
4.4.1. Transmission – převodovka.............................................................................................43
4.4.2. BrakeSolution – řešení brzdy...........................................................................................50
4.5. VEHICLE – VOZIDLO..............................................................................................................................52
4.5.1. Odpor vzduchu................................................................................................................53
4.5.2. Odpor valením.................................................................................................................54
4.5.3. Odpor stoupáním ............................................................................................................55
4.5.4. Odpor brzdy ....................................................................................................................55
4.6. INICIALIZACE MODELU – MODELINITIALIZATION.M.....................................................................................56
4.7. KOMPILACE MODELU............................................................................................................................58
5. LAYOUT A TESTOVACÍ SKRIPTY .................................................................................................. 60
5.1. PŘIHLÁŠENÍ A NAČTENÍ MODELU.............................................................................................................60
5.2. LAYOUT.............................................................................................................................................62
5.3. UKÁZKOVÉ TESTOVACÍ SKRIPTY...............................................................................................................64
6. ZÁVĚR......................................................................................................................................... 68
7. ZDROJE A LITERATURA............................................................................................................... 69

Seznam zkratek a anglických výrazů
Simulink Software společnosti MathWorks pro simulaci dynamických
systémů.
Target Support Package Knihovna prvků Simulinku pro přímou implementaci vyvinutého
algoritmu do cílové platformy.
Real-Time Workshop Volitelná součást Simulinku pro automatické generování kódu
v jazyku C/C++ z algoritmu vytvořeném v prostředí Simulink.
ODE Ordinary Differential Equation
Běžná diferenciální rovnice.
PROVEtech:TA Software společnosti MBtech pro ruční a automatické testování
řídících jednotek.
ECU Electronic Control Unit
Elektronická řídící jednotka, používaná k řízení nejrůznějších
procesů v dnešních automobilech.
MiL Model-in-the-Loop
Model ve smyčce, metoda testování modelů řídících algoritmů.
SiL Software-in-the-Loop
Software ve smyčce, metoda testování SW řídících algoritmů.
HiL Hardware-in-the-Loop
Hardware ve smyčce, metoda testování konkrétních ECU.
Workpage Modul PROVEtechu pro vytváření Layoutu.
Layout Rozložení zobrazovacích a nastavovacích prvků pro ruční testování.
Cockpit area Palubní deska, slouží pro umístění nejčastěji používaných prvků.
Test Manager Modul PROVEtechu pro automatizované testování.
RTAE Real Time Automation Library
Knihovna funkcí pro podporu testování v reálném čase.
Test Statistics Library Knihovna pro automatické generování statistik testů.

Úvod | 7
1. Úvod
Trend zavádění elektronických systémů, probíhající v posledních několika dekádách, je
poměrně zřejmý, nejprve jsou nejnovější systémy implementovány v prémiových modelech
jednotlivých značek a následně v průběhu několika let jsou tyto systémy pomalu zaváděny i do
modelů středních a nižších tříd. Jednotlivý výrobci automobilů spolu svádějí nelítostný
konkurenční souboj neboť prestiž značky je dána především úrovní těch nejluxusnějších modelů.
Tento fakt má za následek velmi omezený čas na vývoj nových systémů a funkcí, navíc jak již bylo
zmíněno, tyto systém jsou do sériové výroby zaváděny poprvé, jejich funkci a spolehlivost je tedy
třeba velmi důkladně testovat. Očekávání zákazníků kupujících prémiové značky a modely je totiž
diametrálně odlišné od očekávání zákazníků kupujících vozy středních a nižších tříd.
Testování elektronických systémů automobilu lze zhruba dělit na testování základních
komponentů, jako jsou jednotlivé řídící jednotky, senzory a akční členy, a na testování celého
elektronického systému skládajícího se z velkého množství sběrnicemi propojených řídících
jednotek a k nim připojených senzorů a akčních členů. Zatímco vývoj a testování samostatných
jednotek a komponentů je záležitostí dodavatelských společností, tzv. integrační testování je
prováděno výhradně samotnými výrobci automobilů, kteří mají jasnou představu o svém
budoucím voze a jednotlivé funkce realizují za pomoci dodavatelských společností. Je dnes
naprosto běžné, že těchto dodavatelů podílejících se na elektronické výbavě jednoho jediného
modelu je několik desítek. Vytváření jednotlivých specifikací, řízení celé struktury dodavatelů
jednotlivých komponentů, stejně jako zavádění dodatečných změn a úprav je dnes obrovská výzva
stojící před výrobci automobilů, kteří chtějí v tomto konkurenčním prostředí uspět.
Aby byla tato výzva vyslyšena, je nutné vývoj nových systémů a funkcí velmi těsně
provázat s jejich testováním, a to již od velmi raného stádia vývoje jednotlivých komponentů až po
integrační testování všech dílů společně. Jedna z možností jak tohoto cíle dosáhnout je využití
programu Matlab/Simulink pro vývoj řídících algoritmů a následné testování takto vyvinutého
softwaru použitím nástroje PROVEtech:TA. Má diplomová práce se zabývá právě těmito
prostředky, kdy jsem nejprve vytvořil model jízdní dynamiky vozidla Škoda Fabia a poté jsem tento
model podrobil několika tesům k ověření jeho funkčnosti.

Simulink | 8
2. Simulink
V této části bude nastíněno jak Simulink pracuje, bez zacházení do nepodstatných detailů
či opakovní již mnohokrát popsaného chování a vlastností tohoto nástroje. Větší pozornost bude
na konci této kapitoly věnována blokům, které byly použity při samotném vytváření dynamického
modelu, jež je předmětem této diplomové práce.
Simulink je softwarový balík, který umožňuje modelovat, simulovat a analyzovat systémy,
jejichž výstupy se mění v čase. Tyto systémy jsou často označovány jako dynamické systémy.
Simulink může být použit k prozkoumání chování širokého spektra dynamických systémů reálného
světa, včetně elektrických obvodů, tlumičů rázů, brzdných systémů a mnoha dalších elektrických,
mechanických nebo termodynamických systémů.
Simulování dynamického systému je dvoufázový proces. Nejprve uživatel vytvoří blokový
diagram za pomoci editoru modelu, který graficky znázorňuje časově závislé matematické vztahy
mezi vstupy, stavy a výstupy systému. Následně uživatel použije Simulink k simulaci systému
reprezentovaného vytvořeným modelem od zvoleného času začátku do konkrétního času konce
požadované simulace.
2.1. Vytváření modelů
Simulink poskytuje grafický editor, který umožňuje vytvářet a propojovat různé typy bloků
vybraných z knihoven. Knihovny bloků poskytují nejrůznější elementární bloky, kombinacemi
těchto bloků se snažíme získat výsledný systém odpovídající našim požadavkům. Tyto bloky
dodávané přímo se Simulinkem se nazývají vestavěné bloky a jsou zařazeny do již zmíněných
knihoven. Zaměření jednotlivých knihoven, sahá od leteckých a kosmických prvků, komunikačních
systémů, fuzzy logiky přes bloky měřidel a získávání dat až po specializované bloky tzv. Target
Support Package poskytující efektivní nástroj pro přímou implementaci vyvinutého algoritmu do
cílové platformy. Uživatel si samozřejmě může definovat vlastní často používané bloky a následně
je přidávat do svých modelů z vlastní knihovny.
2.2. Čas
Čas je nedělitelnou součástí každého schématu bloků. Určování chování systému v čase je
vlastně opakované řešení modelu v časových intervalech nazývaných časové kroky od počátku do
konce simulace. Tyto časové kroky je možné buď přímo zvolit v menu Configuration Parameters

Simulink | 9
nebo můžeme nechat Simulink rozhodnout jaký časový krok je pro daný moment nejvhodnější,
více viz kapitola 2.4 Řešitelé s pevným versus řešitelé s proměnlivým krokem.
2.3. Stavy systému
Velmi často výstupy některých systémů závisí na předešlé hodnotě dočasných
proměnných. Tyto dočasné proměnné nazýváme stavy nebo také vnitřní stavy systému. Během
výpočtu výstupů modelu v jednotlivých časových krocích je tedy mimo jiné nutné i uložení těchto
hodnot pro použití v příštím časovém kroku. Tato úloha se provádí během každé simulace
obsahující modely, které definují vnitřní stavy a to při každém časovém kroku. Všechny bloky,
které nějakým způsobem potřebují všechny nebo pouze některé ze svých předešlých stavů
k výpočtu následující hodnoty výstupu si tyto stavy skrytě mezi jednotlivými kroky ukládají. Tento
fakt má významný vliv na požadovaný výpočetní výkon potřebný k běhu aplikace v tzv. režimu
reálného času. V simulaci, kterou vytvářím, je krok přepočtu všech proměnných vstupů, stavů a
výstupů roven 1 ms.
V Simulinku se vyskytují dva typy stavů: diskrétní a spojitý. Spojitý stav jak název napovídá,
mění svůj stav v čase spojitě. Příkladem takového stavu může být rychlost vozidla či napětí na
kondenzátoru. Diskrétní stav se oproti spojitému mění v čase vždy po konečných (periodických či
aperiodických) intervalech. Příkladem diskrétní hodnoty může být rychlost vozidla zobrazovaná na
digitálním tachometru, který se obnovuje např. jednou za sekundu. Mezi bloky, které definují
spojité stavy, patří: integrátor, blok stavových stavů (State-Space block), blok přenosové funkce
(Transfer function), blok proměnného dopravního zpoždění a blok nul a pólů (Zero-Pole block).
Celkový počet stavů systému je dán součtem všech stavů definovaných všemi bloky modelu.
2.3.1. Spojité stavy
Výpočty spojitých stavů vyžadují znalost rychlosti změny stavu resp. jeho derivace. Jelikož
rychlost změny stavu je samo o sobě taktéž v čase proměnná veličina, lze na ni nahlížet jako na
další vnitřní stav bloku. Modelování spojitých stavů tedy v podstatě zahrnuje proces integrace
derivací stavu od počátku simulace a proces výpočtu nové derivace v každém časovém okamžiku.
V simulinku používáme blok integrátoru k indikaci požadované integrace a řetězec bloků
spojených před vstupem integrátoru reprezentuje metodu výpočtu derivace stavu. Řetězec
spojených bloků před integrátorem je grafická obdoba běžné diferenciální rovnice (ODE).
Vyjma velmi jednoduchých dynamických systémů, analytické metody pro integrování
stavů dynamických systémů reálného světa, reprezentovaných obyčejnými diferenciálními
rovnicemi, neexistují. Integrování těchto spojitých stavů vyžaduje použití numerických metod

Simulink | 10
nazývaných ODE řešitele. Simulink nabízí řadu různých automatizovaných implementacích
nejčastěji používaných ODE řešitelů z nichž si může uživatel zvolit před začátkem samotné
simulace. Přesnost takto získaných výsledků samozřejmě souvisí s velikostí intervalů mezi
jednotlivými časovými kroky, v nichž jsou stavy systému počítány. Obecně vzato, čím menší časový
krok tím vyšší přesnost.
2.3.2. Diskrétní stavy
Výpočty diskrétních stavů vyžadují znalost vztahu mezi jeho současnou a předchozí
hodnotou a dále znalost hodnot jeho současných vstupů. Modelování diskrétních stavů tedy
znamená modelování jeho závislostí na vstupech systému v předešlém časovém kroku.
2.4. Řešitelé s pevným versus řešitelé s proměnlivým krokem
Řešitel s pevným krokem (Fixed-Step solver) řeší model v pravidelných časových
intervalech od počátku do konce simulace. Velikost intervalu je nazývána velikostí kroku. Uživatel
může sám specifikovat velikost kroku nebo může nechat řešitel vybrat vhodnou velikost
automaticky. Jak již bylo řečeno, zkracování kroku simulace zvyšuje její přesnost, na druhé straně
ovšem zvyšuje čas potřebný k simulaci celého systému a také nároky na operační paměť
platformy, na které je simulace prováděna.
Řešitel s proměnlivým krokem (Variable-Step solver), jak je z jeho názvu patrné, mění krok
v průběhu samotné simulace. Snižuje tento krok ke zvýšení přesnosti v bodech, kdy se stavy
systému mění rapidně a zvyšuje ho k zamezení vykonávání nepotřebných kroků v bodech, kdy se
stavy mění pomalu. Výpočet velikosti samotného kroku zvyšuje požadavek na výpočetní výkon,
ovšem tyto metody mohou velmi často omezit celkový počet potřebných kroků a tím i snížit čas
celé simulace.
2.5. Spojití versus diskrétní řešitelé
Spojití řešitelé (Continuous solvers) používají numerickou integraci k výpočtům spojitých
stavů modelu v aktuálním časovém kroku na základě stavu v předešlém kroku a derivaci tohoto
stavu. Spojití řešitelé spoléhají na jednotlivé bloky k výpočtu hodnot diskrétních stavů modelu
v každém časovém kroku.
Matematici vyvinuli široké spektrum numerických integračních technik pro řešení
obyčejných diferenciálních rovnic, které reprezentují spojité stavy dynamických systémů. Simulink
poskytuje rozsáhlý soubor těchto řešitelů, jak pro fixní tak pro proměnný časový krok, kde každý
implementuje specifickou metodu řešení těchto rovnic.

Simulink | 11
Diskrétní řešitelé (Discrete solvers) existují primárně pro účely řešení čistě diskrétních
modelů. Jejich funkce spočívá pouze ve výpočtu následujícího časového kroku modelu. Tyto
řešitelé spoléhají na jednotlivé bloky v modelu, které musí své individuální diskrétní stavy
aktualizovat samy. Samozřejmě tyto řešitelé nepočítají stavy spojité. Z tohoto faktu vyplývá, že
pokud chceme simulovat hybridní model, to je takový, který obsahuje spojité i diskrétní stavy,
musíme vždy použít řešitele spojitého.
2.6. Systémy a subsystémy
Blokový diagram v Simulinku se obvykle skládá z několika vrstev, kde každá z těchto vrstev
je definována tzv. subsystémem. Subsystémy jsou součástí celkového diagramu a ideálně nemají
žádný dopad na smysl celého modelu a jsou v Simulinku poskytovány především z důvodů
organizačních. Subsystémy nám tedy umožňují rozčlenit celkový systém na v podstatě libovolné
množství menších celků, kdy na každém tomto subsystému může pracovat odlišná skupina
pracovníků. Tento fakt je velkým přínosem zvýšené efektivitě vývoje složitých a rozsáhlých
systémů.
V Simulinku rozlišujeme dva základní typy subsystémů: virtuální a nevirtuální. Základní
rozdíl je ten, že nevirtuální subsystémy nám umožňují řídit okamžik, kdy je jejich obsah vykonán.
2.6.1. Virtuální subsystémy (Virtual subsystems)
Virtuální subsystémy přináší grafickou hierarchii do modelu. Virtuální subsystémy nemají
žádný vliv na vykonávání jejich obsahu. Během vykonávání modelu, Simulink zploští všechny
virtuální subsystémy, tento proces je velmi podobný způsobu jakým pracují makra v jazyce C.
Jednoduše řečeno, před samotným počátkem simulace, Simulink rozvine všechny nevirtuální
subsystémy do jednoho svrchního systému nazývaného kořenový systém (Root system). Tento
úkon Simulinku se často označuje jako zplošťování hierarchie modelu.
2.6.2. Nevirtuální subsystémy (Nonvirtual subsystems)
Nevirtuální subsystémy poskytují nejenom grafickou hierarchii modelu, ale navíc i
možnost řízení kdy je daný subsystém vykonán. Nevirtuální subsystémy jsou vykonány jako jediné
jednotky výpočetním jádrem Simulinku. Můžeme vytvořit podmíněně vykonávané subsystémy,
které jsou provedeny pouze když: nastane požadovaná změna řídícího signálu, je vyvolána
požadovaná funkce nebo akce nebo je povolovací vstup uveden do příslušné hodnoty. Bloky
uvnitř nevirtuálního subsystému jsou vykonány pouze, když nastane platná kombinace všech jeho

Simulink | 12
řídících vstupů. V Simulinku jsou všechny nevirtuální subsystémy vykresleny tučnou čarou.
Simulink zavádí následující nevirtuální subsystémy:
2.6.3. Atomární subsystémy (Atomic subsystems)
Základní charakteristika atomárního subsystému je, že bloky uvnitř atomárního
subsystému jsou vykonány jako jediná jednotka. To poskytuje výhodu seskupování funkčních
aspektů modelu na úrovni vykonávání. Do tohoto subsystému mohou být umístěny jakékoliv
bloky Simulinku, včetně bloků s odlišnou rychlostí vykonávání. Vytvořit atomární subsystém je
možné například vybráním možnosti Treat as atomic unit v menu virtuálního subsystému.
2.6.4. Povolované subsystémy (Enabled subsystems)
Povolovaný subsystém se chová obdobně jako atomický subsystém, ovšem jejich obsah je
vykonán pouze tehdy, když signál přivedený na jeho povolovací port je větší než nula. Povolovaný
subsystém může být konfigurován tak, aby držel nebo resetoval stavy bloků uvnitř tohoto
subsystému pomocí States when enabling parametru. Dále je možné nastavit individuálně každý
z výstupů tak, aby držel nebo resetoval svou hodnotu v případě, že signál povolovacího portu je
roven nule pomocí Output when disabled parametru. Vytvořit povolovaný subsystém, lze
například přidáním bloku povolovací port (enable port block) do běžného subsystému.
2.6.5. Spouštěné subsystémy (Triggered subsystems)
Spouštěný subsystém vykonává svůj obsah v případě, že se na spouštěcím portu
subsystému objeví náběžná nebo sestupná hrana signálu vzhledem k nule. Směr hrany
spouštěcího signálu je definován pomocí Trigger type parametru v menu bloku spouštěcího portu
(trigger port block). Simulink omezuje typ bloků umístěných do spouštěných subsystémů pouze na
bloky, které mají vzorkovací čas -1, čili převzatý, protože obsah spouštěných subsystémů je
vykonáván aperiodickým způsobem. Vytvořit spouštěný subsystém lze obdobně jako subsystém
povolovaný, tedy vložením bloku spouštěcího portu (trigger port block) do běžného subsystému.
Stateflow diagram také může mít spouštěcí port, definovaný Stateflow editorem a z pohledu
Simulinku není žádný rozdíl mezi spouštěným subsystémem a spouštěným diagramem.
2.6.6. Subsystémy volání funkce (Function-call subsystems)
Subsystém volání funkce je subsystém, který může být vyvolán jiným blokem přímo
v průběhu simulace, obdobně jako jsou funkce vyvolávány v běžném procedurálním
programování. Vyvolávání funkčního subsystému je ekvivalentní vyvoláváním výstupních metod
bloků obsažených v tomto subsystému v definovaném pořadí. Blok, který vyvolává funkční

Simulink | 13
subsystém, se nazývá funkční iniciátor. Stateflow diagram, generátor volání funkce (Function-call
generator) nebo S-funkce může být použita jako funkční iniciátor. Vytvořit funkční subsystém lze
například přetažením subsystému volání funkce bloku do vašeho modelu nebo vybráním možnosti
function-call z menu Trigger type spouštěcího bloku. Funkční subsystém lze konfigurovat jako
hranou spouštěný nebo periodicky spouštěný pomocí Sample time type parametru.
Funkční iniciátor může vyvolat hranou spouštěný funkční subsystém nikdy, jedno nebo
vícekrát za časový krok. Vzorkovací čas všech bloků umístěných do hranou spouštěných
subsystémů volání funkce musí být nastaven na převzatý, tedy -1. Funkční iniciátor může vyvolat
periodicky spouštěný funkční subsystém pouze jednou za časový krok a musí vyvolávat tento
subsystém periodicky. V případě, že funkční iniciátor vyvolává subsystém volání funkce
aperiodicky Simulink zastaví simulaci a zobrazí chybové hlášení. Bloky v periodicky spouštěném
subsystému volání funkce nemusí mít nastaveny vzorkovací čas na převzatý, ale všechny bloky
s časem jiným než převzatým musí mít tento čas shodný.
2.6.7. Povolované subsystémy se spouštěním (Enabled with trigger
subsystems)
Povolovaný subsystém se spouštěním je, jak název napovídá, kombinací povolovaného a
spouštěného subsystému. Jeho obsah je vykonán v případě, že povolovací signál na povolovacím
portu je větší než nula a na spouštěcím portu se objeví zvolená hrana signálu. Hranu signálu lze
opět zvolit v příslušném menu a všechny bloky obsažené v tomto subsystému musí mít vzorkovací
čas nastaven jako převzatý, protože vykonávání může nastávat aperiodicky.
2.6.8. Akční subsystémy (Action subsystems)
Akční subsystémy mohou být chápany jako průnik vlastností povolovaných a subsystémů
volání funkce. Omezení akčních subsystému je v nutnosti použít stejný vzorkovací čas. Tyto akční
subsystémy mohou být vyvolány pouze iniciátorem akčních subsystémů, jako tyto iniciátory
mohou být použity bloky podmínky jestliže nebo bloky podmínky vyber případ. Všechny akční
subsystémy připojené k danému iniciátoru akčních subsystémů musí mít shodný vzorkovací čas.
Vytvořit akční subsystém lze opět přetažením bloku akčního port (action port block) do běžného
subsystému, ikona tohoto subsystému se automaticky přizpůsobí bloku, který tento subsystém
iniciuje (blok podmínky jestliže nebo blok podmínky vyber případ).
Akční subsystémy umožňují kontrolu nad tím, kdy se stavy budou resetovat pomocí
příslušného parametru. Obdobně je opět možné nastavit, jestli výstupy mají držet nebo resetovat
své hodnoty v případě, že řídící signál nemá platnou úroveň. Akční subsystémy se chovají podobně

Simulink | 14
jako subsystémy volání funkce, protože mohou být vykonány pouze za pomoci iniciačního bloku.
Rozdíl mezi těmito subsystémy je v tom, že subsystém volání funkce může být vykonáván více než
jedenkrát za jeden časový krok, na rozdíl od akčního subsystému, který lze vykonat nanejvýš
jedenkrát za časový krok.
2.6.9. Subsystémy podmínky zatímco (While subsystems)
Tyto subsystémy provedou několik iterací v každém časovém kroku. Počet těchto iterací je
řízeno podmínkou zadanou v bloku opakovače zatímco (while-iterator block). Subsystémy
podmínky zatímco jsou svým chováním podobné subsystémům volání funkce v tom, že vykonávají
svůj obsah vícekrát během jednoho korku simulace. Rozdíl oproti subsystémům volání funkce je
v tom, že subsystémy podmínky zatímco nepotřebují žádný samostatný iniciátor a navíc mohou
mít tyto subsystémy přístup k číslu aktuální iterace pomocí bloku opakovače zatímco (while
iterator block).
2.6.10. Subsystémy podmínky pro (For subsystems)
Tyto subsystémy provedou předem zadaný počet iterací během každého časového kroku.
Počet těchto iterací může být zadán externě skrz příslušný vstup nebo specifikován interně v
bloku opakovače pro (for-iterator block). Tyto subsystémy jsou velice podobné subsystémům
podmínky zatímco v tom, že poskytují přístup k číslu příslušné iterace a poskytují možnost
kontroly nad tím, zdali se mají vstupy při spouštění resetovat. Rozdílnými je činí fakt, že u
subsystémů podmínky pro je počet iterací pevně zadán, na rozdíl od subsystémů podmínky
zatímco, kde je počet iterací dán splněním resp. nesplněním zadané podmínky.
2.7. Algebraické smyčky (Algebraic loops)
Algebraické smyčky jsou častou obtíží, se kterou se můžeme během vytváření modelů
dynamických systémů setkat. Některé bloky Simulinku totiž mohou mít vstupní port s tzv. přímým
průchodem (direct feedthrough). To znamená, že výstupy takových bloků nemohou být
vypočteny, aniž bychom znali hodnotu signálu vstupujícího do tohoto portu. Mezi bloky, jež mají
své vstupy s přímým průchodem, patří: všechny matematické funkce, blok integrátoru, sumy,
součinu a zesílení, dále pak blok přenosové funkce (Transfer function), blok stavových stavů
(State-Space block) a blok nul a pólů (Zero-pole block).
Algebraická smyčka obecně nastává, když je port s přímým průchodem řízen výstupem
téhož bloku buď přímo, nebo skrz zpětnovazební cestu přes další bloky s přímým průchodem.

Simulink | 15
Pokud model obsahuje algebraickou smyčku, je v každém časovém kroku vyvolána tzv.
smyčku řešící rutina. Tento řešitel smyček vykoná několik iterací, aby zjistil řešení vzniklého
problému (pokud je toto řešení vůbec možné). Výsledkem čehož je, že modely obsahující nějakou
algebraickou smyčku jsou simulovány mnohem pomaleji.
Při spuštění simulace Matlab vypíše subsystémy, jež obsahují případnou algebraickou
smyčku a bloky, jež tuto smyčku tvoří. Příkazem ashow, zadaného do příkazového okna Matlabu,
je možné tyto algebraické smyčky zvýraznit a následně odstranit.
K odstranění algebraické smyčky je vhodné použít blok Simulinku nazývaný Algebraické
omezení (Algebraic Constraint block), jehož výstupem je hodnota nutná k vytvoření nuly na
vstupu. Výstup tohoto bloku musí ovlivňovat jeho vstup libovolnou přímou zpětnou vazbou. Dále
je možné zadat počáteční odhad algebraického stavu ke zvýšení efektivity smyčkového řešitele.
Samotný Simulink může také odstranit algebraické smyčky, jsou-li tyto smyčky umístěny
v atomickém či povolovaném subsystému nebo umístěny v bloku modelu. K umožnění
automatické minimalizace algebraických smyček je třeba vybrat parametr Minimize algebraic loop
occurrences v dialogovém menu daného bloku.
Velmi jednoduchým a přesto plně funkčním řešením, jak odstranit algebraickou smyčku, je
vložení bloku paměti (memory block) do řetězce tvořícího tuto smyčku. Tento blok má jako svůj
jediný parametr počáteční podmínku, je tedy nutné znát počáteční hodnotu signálu, jež je
objektem algebraické smyčky, a který tímto blokem rozdělujeme.

PROVEtech:TA | 16
3. PROVEtech:TA
V této části diplomové práce se pokusím popsat ve zkratce produkt PROVEtech:TA, jeho
čtyři základní části, přičemž větší pozornost bude věnována částem Workpage a Test Manager,
které budou následně využity k vytvoření tzv. Layoutu, a vzorových testovacích skriptů, viz
kapitola 5.
PROVEtech:TA je pracovní software vyvinutý v praxi skupinou MBtech pro řízení a
automatizaci testovacích systémů. Tento software umožňuje uživateli interaktivně nastavovat a
měřit všechny důležité stavy a proměnné testovaného systému. PROVEtech:TA nabízí uživatelsky
přívětivé prostředí stejně jako databázovou podporu pro vykonávání typických úkolů
managementu testů, jako například správu testovacích knihoven, testovacích sestav a výsledků
testů. S jeho širokou rozličností řídících a zobrazovacích prvků PROVEtech:TA usnadňuje přístup
k signálům potřebným pro testované scénáře. Uživatel může například nastavit pozici plynového
pedálu a sledovat výslednou rychlost vozidla. Mezi další moduly, které z tohoto nástroje činí
kompletní software pro návrh, vykonávání a řízení testů, jsou moduly pro návrh diagnostiky a
modul simulace poruch.
PROVEtech:TA nabízí ideální základ pro vykonávání automatizovaných testů na
platformách pracujících v reálném čase prostřednictvím jeho integrovaného vývojového prostředí
a knihoven programů pro vykonávání testů na počítačích pracujících v reálném čase. Architektura
tohoto nástroje je hardwarově nezávislá a umožňuje přístup více uživatelů, což ho činí optimální
pro použití v rámci pracovní skupiny. Tento software začleňuje použití databází k zajištění
konzistentního nakládání a správě používaných dat. Všechny moduly fungují pod jednotným
grafickým rozhraním a mohou být intuitivně ovládány. Pravidelné vydávání nových verzí zajišťuje,
že funkce tohoto softwaru a rozsah použitelných aplikací je rozšiřován k uspokojení rostoucích
nároků na testované systémy.
PROVEtech:TA je univerzálně aplikovatelný nástroj pro automatizaci testů od velmi
brzkých fází vývoje, přes celý proces vývoje nového produktu až po běžné výrobní inženýrství.
Některé z oblastí, kde lze tento software jsou:
• Model-in-the-Loop (MiL): Testování modelů řídících jednotek
• Software-in-the-loop (SiL): Testování softwaru řídících jednotek
• Hardware-in-the-loop (HiL): Testování jednotlivých ECU nebo sítě propojených jednotek
• On-Board-Test: Ladění a kalibrace řídících algoritmů v konkrétním vozidle

PROVEtech:TA | 17
3.1. Workpage – pracovní plocha
Část Workpage se používá ke stimulování a zobrazování signálů. Uživatel si může vybrat ze
seznamu všech dostupných signálů a nastavit na nich jím požadované hodnoty za pomoci různých
řídících prvků, například posuvné prvky nebo tlačítky. Postupný vývoj hodnoty signálů je
znázorněn například pomocí různých grafů nebo číselných hodnot. Celá část Workpage může být
obsluhována za pomoci uchopení a přetažení myší, pomocí kopírování hodnot do kontextových
nabídek nebo zadáváním konkrétních numerických hodnot klávesnicí.
Ke vstupu do části Workpage je nutné zvolit příslušný tabulátor, viz obrázek 3—1
Tabulátory základních částí PROVEtechu, tyto tabulátory představují čtyři základní části
PROVEtechu a nacházejí se v horní čtvrtině okna programu.
3—1 Tabulátory základních částí PROVEtechu
Samotná část Workpage může mít několik stránek, přístup k těmto stránkám je
zprostředkován prostřednictvím tabulátorům v dolní části okna programu. Uživatel má možnost
měnit jména, mazat či přidávat další stránky do příslušné Workpage po kliknutí pravým tlačítkem
myši na tabulátor příslušné stránky a vybráním požadované operace z kontextové nabídky. Dále je
zde možnost Import pomocí níž lze do Workpage přidat již existující stránku z dříve uloženého
Workpage. Poslední možností jak přidat další stránku Workpage je pomocí vytvořením odkazu na
existující stránku uloženou v jiném Workpage. Rozdíl oproti možnosti import je ten, že při uložení
Workpage se změny nastavení a rozmístění jednotlivých prvků na stránce přidané pomocí odkazu
v originální stránce neprojeví. V kontextové nabídce je nicméně možnost uložit změny na stránce
přidané pomocí odkazu do původní stránky.
V levé části hlavního okna programu se nachází tzv. palubní deska (cockpit area). Tato část
okna může zobrazovat stejné prvky jako část Workpage, s tím rozdílem, že tato část je vždy
viditelná a proto se hodí na zobrazování těch nejdůležitějších nebo nejčastěji používaných prvků.

PROVEtech:TA | 18
3.1.1. Okno výběru signálu
3—2 Okno výběru signálu
Okno výběru signálu lze vyvolat například vybráním příslušné položky z menu
Extras|Signals… nebo stisknutím příslušného tlačítka v hlavní liště programu a je znázorněno na
obrázku 3—2 Okno výběru signálu.
Část tohoto okna označená číslem 1 umožňuje výběr jednoho nebo několika signálů
stejným způsobem jako je možné vybírat soubory v systému Windows. Tato část obsahuje tři
odlišné typy prvků, které se v ní mohou nacházet, jsou jimi atributy (značeny modrou ikonou
složky), uzly (běžné žluté složky) a samotné signály (znázorněny ikonou představující průběh
signálu). Dále tato část okna obsahuje další informace o příslušných signálech.
Část okna označená číslem 2 slouží k určení způsobu, jakým jsou signály v tomto okně
řazeny (sestupně nebo vzestupně podle názvu signálu). Po kliknutí pravým tlačítkem myši na tuto
oblast se zobrazí kontextová nabídka, kde je možné vybrat položku Filters pomocí které lze zadat
různá kritéria pro zobrazení resp. skrytí určitých signálů.

PROVEtech:TA | 19
Horní část okna označená číslem 3 slouží jako informační panel, který zobrazuje aktuální
informace o počtu signálů vybraných k získávání z testovací platformy, maximální počtu signálů,
které lze měřit, dále o počtu aktuálně vybraných signálů a o počtu vybraných signálů, které nejsou
měřitelné. Spodní část celého okna výběru signálu zase obsahuje tlačítka, která umožňují vybrat
resp. odebrat všechny dostupné signály jako měřené, otevřít dialog výběru atributů nebo
aktivovat resp. deaktivovat výběrový filtr.
Část okna označená číslem 4 slouží pro výběr ovládacích prvků pro jednotlivé signály,
některé z nich slouží pouze pro zobrazení hodnoty signálu, jiné umožňují i nastavení konkrétní
hodnoty signálu. K umístění ovládacího prvku je nutné nejprve vybrat jeho typ a následně signál
nebo signály přetáhnout myší do oblasti Workpage, nicméně existují i další alternativy jak umístit
prvek do pracovní plochy. Výčet a popis ovládacích prvků ve stejném pořadí jako v okně:
1. Automatic type selection - PROVEtech v tomto případě sám vybere vhodný ovládací prvek
dle typu zvoleného signálu.
2. Strip chart - vykreslí zvolený signál během získávání dat jako funkci času.
3. Multi-strip chart - slouží pro zobrazení vice signálů v jednom grafu
4. XY strip chart - vykresluje závislost jednoho signálu na druhém
5. Slider or bar - slouží jako zobrazovací i nastavovací prvky
6. Switch or LED - lze použít k signalizaci nebo nastavení jednobitové informace
7. Number - zobrazuje hodnotu signálu v libovolném formátu
8. Bitmap - používá se pro zobrazení obrázku nebo textu pokud je sledovaný signál
v zadaném rozsahu
9. Bitswitch - slouží jako zobrazení nebo nastavení signálu v binárním formátu
10. Gauge – zobrazuje a umožňuje nastavit hodnotu signálu jako kruhová stupnice
11. Grid control – zobrazuje vektory nebo matice jako tabulky s možností nastavení
12. Custom – použití uživatelem definovaného prvku
13. Special – obsahuje množství různých zobrazovacích a nastavovacích prvků, které svým
vzhledem odpovídají reálným prvkům v automobilech jako například otočný ovladač
svítidel, řadicí páka, startovací klíček, otáčkoměr s tachoměrem a podobně.
3.1.2. Úprava a organizace ovládacích prvků
Úpravy a organizace veškerých ovládacích prvků je přístupná po výběru příslušné volby
v kontextové nabídce, vyvolané stisknutím pravého tlačítka myši nad libovolným prvkem. Možné
úpravy ovládacích prvků zahrnují například možnost vyjmout či kopírovat označený prvek,
kopírovat a následně vložit pouze formát určitého prvku, vymazání či reset ovládaných signálů,

PROVEtech:TA | 20
přidání či odebrání určitého signálu z měřených signálů či uložení aktuálně nastaveného vzhledu
prvku jako bitmapového obrázku.
Přesouvání a změna velikosti ovládacích prvků je možná po označení vybraného prvku
obdobným postupem jako ve zmíněném operačním systému. Kopírování označených prvků je
možné například za použití klávesy Ctrl, kterou je nutné stisknout před uvolněním levého tlačítka
myši. Každý ovládací prvek lze samozřejmě měnit individuálně v závislosti na jeho možnostech,
více v [ 3 ].
Mezi nejčastější možnosti úpravy jednotlivých prvků patří změna velikosti prvku, barva
pozadí a textu, zobrazení minimální a maximální hodnoty či výběr jmenovky zobrazovaného
signálu. Zajímavou funkcí je například konvertor jednotek přítomný u některých prvků, kterým je
možné převést měřené jednotky na jednotky více vhodné pro zobrazení. Zobrazovací prvky Strip
chart a Multi-strip chart umožňují nastavení měřítka (scale) a kompenzace (offset) pro jednotlivé
signály což opět může zlepšit čitelnost a přehlednost při některých měřeních. Všechny zobrazovací
prvky umožňují nastavení minimálních a maximálních zobrazovaných hodnot, zobrazení mřížky
pro jednotlivé osy, název jednotlivých os, tloušťku čáry a mnoho dalších parametrů, více v [ 3 ].
Jako zástupce z množství ovládacích prvků kategorie Special vybírám prvek, který je
používán jako ovládací prvek, jeho výstupem je zvolený rychlostní stupeň 5-speed shifter. Jeho
podobu zobrazuje obrázek 3—3a Prvek řadicí páky, výstupem tohoto prvku je číslo, které
odpovídá zvolenému rychlostnímu stupni dle tabulky 3—3b Hodnoty signálu prvku řadicí páky.
3—3a Prvek řadicí páky
Rychlostní stupeň Hodnota signálu
neutrál 0
1. stupeň 1
2. stupeň 2
3. stupeň 3
4. stupeň 4
5. stupeň 5
zpátečka 6
3—3b Hodnoty signálu prvku řadicí páky

PROVEtech:TA | 21
3.2. Test Manager
PROVEtech:TA umožňuje testovat reakci jednotlivé nebo více řídících jednotek (ECU) na
širokou škálu hodnot signálů ve vozidle. V reálném vozidle jsou tyto signály dodávány použitými
senzory nebo ostatními řídícími jednotkami a jsou zpracovávány opět v řídících jednotkách.
Pomocí pracovní plochy (Workpage) PROVEtechu, viz kapitola 3.1. Workpage – pracovní plocha,
lze tyto signály stimulovat manuálně pomocí ovládacích prvků a pozorovat odezvy ostatních
signálů v právě testovaném systému. Oproti tomu v Test Manageru je možné tyto stimuly
generovat automaticky za pomoci testovacích programů, tzv. skriptů, tato možnost značně
rozšiřuje možnosti testování funkcí řídících jednotek v porovnání s manuálním testováním a
zaznamenáváním naměřených údajů.
Test Manager obsahuje integrované prostředí pro programování těchto skriptů stejně
jako kompletní správu všech existujících a vykonaných testovaných případů. Tím se Test Manager
stává klíčovou komponentou tohoto softwaru pro automatizované testování. Jednotlivé testované
případy jsou implementovány jako makra v integrovaném programovacím prostředí. Testovací
skripty mohou být vykonávány odděleně nebo ve skupinách a jsou uloženy společně se svými
výsledky a protokoly. Všechny výše zmíněné rysy tohoto softwaru poskytují základ pro vysoké
testovací pokrytí a umožňuje snadné vykonávání opakujících se testů.
Pokud testovaná aplikace vyžaduje vykonávání v reálném čase, testy musí být prováděny
s pomocí Real Time Automation Engine (RTAE) na platformě pracující v reálném čase. Zmíněná
knihovna automatizace (RTAE) pomáhá definovat pořadí vykonávaných příkazů a jejich
paralelismus. Více se o této knihovně dozvíte v souboru nápovědy [ 7 ]. PROVEtech nabízí
pokročilé možnosti správy uživatelů a projektů prostřednictvím přístupových práv. Tím pádem je
možné nezávisle spravovat několik testovaných systémů avšak s použitím jednotné databáze,
tímto způsobem je možné velmi efektivně vytvářet celou řadu rozsáhlých společných knihoven
testů. Přístupová práva mohou být přidělována také pro jednotlivé uživatelské role, jako jsou
například vývoj testů, vykonávání testů a následná analýza výsledků tesů. PROVEtech dále nabízí
řízení revizí jednotlivých objektů, což umožňuje ukládat a archivovat starší testovací objekty. To je
vhodné, například pokud je vyžadován přístup ke starším verzím testů a opakování jejich výsledků.
S použitím knihovny Test Statistics Library je možné velmi snadno, rychle a automaticky
vytvářet statistiky prováděných testů a jejich výsledků ve formátu excelovských grafů. Pokrytí
testu, výsledky testů, úroveň vyzrálosti produktu a mnoho dalších informací je tedy k dispozici
v jakémkoli okamžiku a mohou být ihned prezentovány v přehledné a správně uspořádané

PROVEtech:TA | 22
formátu. Test Manager podporuje dnes nejrozšířenější databázové systémy jako Oracle, Microsoft
SQL Server nebo PostgreSQL pro sdílení uložených dat testovacích objektů a výsledků.
3.2.1. Objekty a struktura Test Manageru
3—4 Test Manager
Na obrázku 3—4 Test Manager, vidíme okno Test Manageru, které se zobrazí po kliknutí
na tabulátor se shodným názvem v horní části okna programu. Levá část, podobající se strukturou
stromu průzkumníka Windows, obsahuje uživatele, projekty a testy. Orientace je obdobná
s orientací v průzkumníku Windows, čili rozvinutí požadovaného objektu je možné po kliknutí na
symbol křížku či poklepáním na daný objekt, dále je zde také možnost navigace pomocí ikon
v horní části zpět, vpřed a skok o úroveň výše. Po zvolení některého z elementů ho můžeme
změnit dle potřeby v pravé části Test Manageru za použití některého z přítomných tabulátorů:
Průzkumník (Explorer), Verze (Versions), Informace (Info), Dokumenty (Documents), Parametry
(Parameters), Výsledky (Results) a Přehled (Overiew). Pro zjednodušení práce jsou tyto tabulátory
přidávány a odstraňovány dynamicky v závislosti na daném obsahu.
Celá struktura Test Manageru a jeho objekty jsou uloženy v databázi a samotné testy jsou
vždy obsaženy v některé z větví uživatele, projektu nebo knihovny. Tím se dostáváme k objektům,
které se v Test Managerovi mohou vyskytovat, tabulka 3—5 Seznam objektů Test Manageru,
shrnuje všechny objekty se kterými se můžeme v Test Manageru setkat.

PROVEtech:TA | 23
Systémový test
System test
Jsou obdobné složkám, čili mohou obsahovat další
systémové testy, elementární testy nebo uživatelem
definované objekty. Při jeho spuštění se postupně
provedou všechny obsažené testy.
Elementární test
Elementary test
Jsou vlastní testovací skripty, které stimulují signály
virtuálního systému a spouštějí určité procesy testovacího
systému, který následně poskytuje výsledky.
Objekt
Object
Objekt obsahuje datový typ, který poskytuje metody
k přístupu k jeho vnitřním datům ostatním modulům.
Třída
Class
Třída obsahuje datový typ, který poskytuje metody
k přístupu k jejím vnitřním datům dalším modulům.
Uživatelem definovaný
objekt
Neobsahuje kód v jazyce Basic, ale lze do něj uložit jakýkoli
jiný soubor, např. Excel nebo textový dokument.
Uživatel
User
Každý uživatel má v Test Manageru vlastní prostor, kam
může ukládat jeho testy.
Projekt
Project
Projekt stanovuje společný prostor pro práci více uživatelů.
Projekt může vytvořit pouze administrátor, který
jednotlivým uživatelům přidělí odpovídající práva přístupu.
Knihovna
Library
Lokální knihovny může vytvořit uživatel ze systémových
testů a obráceně, uživatel si v nich může uchovávat často
používané testy pro opětovné použití.
Příkladem globální knihovny je například Automation
Library nebo TestStatistics Library v nejvyšší úrovni
stromu.
Odpadkový koš
Trash folder
Funkce odpadkového koše je obdobná k funkci ve
Windows, jsou do něj umisťovány mazané testy a jeho
obsah lze obnovit.
3—5 Seznam objektů Test Manageru
3—6 Objekty pouze pro čtení
Objekty k nimž nemá uživatel v daný okamžik právo
zápisu jsou zobrazeny ikonami, které vidíme na obrázku 3—6
Objekty pouze pro čtení.
Tyto soubory nelze editovat ani vykonávat, je ovšem možné jejich obsah kopírovat,
například do prostoru, v němž má uživatel příslušná práva, zde již může uživatel tyto testy
vykonávat i editovat.

PROVEtech:TA | 24
3.2.2. Vytváření a správa testů
K vytvoření nového testu (elementárního testy, třídy nebo objektu) je nutné nejprve
vytvořit nový testovací objekt, v tomto objektu je nutné definovat obecná data jako například
jméno a popis obsahu testu. Datum a čas jsou v tomto případě vyplněny automaticky. Dále je
nutné napsat samotný testovací skript, k tomuto účelu slouží integrované prostředí pro psaní
kódu testovacího skriptu v jazyce Basic. Přístup do tohoto prostředí je prostřednictvím tabulátoru
Program, nástrojová lišta obsahuje ikony všech dostupných funkcí, mezi něž patří například
ukládání obsahu testu, zakomentování označené oblasti, vykonávání syntaktické kontroly či
vykonávání samotného testu, stejně jako umisťování bodů přerušení nebo funkce pro krokování
vytvořeného kódu.
Další možností jak vytvořit elementární test je nahrání tohoto elementárního testu jako
makra. Po výběru příslušného příkazu z kontextové nabídky se spustí nahrávání všech vykonaných
operací a po stisknutí tlačítka pro ukončení nahrávání makra se tento obsah uloží do zvoleného
elementárního testu.
Samozřejmostí je možnost již vytvořené testy přejmenovávat, kopírovat, přesouvat a
podobně, opět způsobem známým z operačního systému Windows, čili použitím příslušných
klávesových zkratek nebo přetažením myši. Další možností je export a následný import
vytvořených testů, u této možnosti si můžeme zvolit, zdali chceme samotné elementární či
systémové testy přenášet spolu s jejich výsledky, přílohami či jestli požadujeme přenos i starších
verzí.
3.2.3. Vykonávání testů
Vykonávat lze buď jednotlivé elementární testy, nebo systémové testy, které mohou
obsahovat libovolné množství elementárních testů. Přístup k možnosti vykonávat požadované
testy je prostřednictvím tabulátoru Execute. Během vykonávání nebo po vykonání vybraných testů
jsou v tomto tabulátoru navíc uvedeny informace o datu a času vykonání testu, době trvání testu
a statusu testu. Možné statusy testů jsou zobrazeny pomocí ikon připomínající LED diody a jejich
význam shrnuje tabulka 3—7 Seznam statusů elementárních testů.
Dále jsou v tomto tabulátoru k dispozici ikony funkcí například pro spuštění vykonávání
testu, zastavení či přerušení právě vykonávaného testu, znovuspuštění testu nebo provedení
syntaktické kontroly a další. Při vykonávání testu se ikona PROVEtech:TA v pravém horním rohu
programu otáčí. Pořadí vykonávání elementárních testů je dáno pořadím, v jakém jsou tyto

PROVEtech:TA | 25
elementární testy zobrazeny, toto pořadí lze změnit v okně stromu Test Manageru v levé části
okna vybráním příslušné položky kontextové nabídky.
Výběr testů, které se vykonat mají a které ne lze provést zaškrtnutím políčka nalevo od
příslušného testu.
bílá LED Testovaný objekt zatím nebyl spuštěn
žlutá LED Testovaný objekt je spuštěn právě nyní
zelená LED Testovaný objekt byl otestován s pozitivním výsledkem
červená LED Testovaný objekt byl otestován s negativním výsledkem
symbol hodin Čas vykonávání byl delší než specifikovaný časový limit
šedá LED Testovaný objekt má výsledek nerozdílný
symbol blesku Syntaktická chyba v kódu programu
zelená fajfka Syntaktická kontrola proběhla v pořádku
šedá LED s černým
čtvercem
Vykonávání testu bylo zastaveno
žádný symbol Testovaný objekt byl přeskočen nebo ignorován
3—7 Seznam statusů elementárních testů
3.2.4. Výsledky testů
Jakmile jsou vykonány elementární nebo systémové testy, je možné nahlížet na jejich
výsledky, přikládat k nim komentáře nebo další soubory. Je zde také možnost zobrazovat výsledky
starších verzí testů. Přístup k těmto výsledkům je po vybrání příslušného elementárního nebo
systémového testu prostřednictvím tabulátoru Results nebo pomocí poklepáním na vybraný test.
Zobrazí se dialogové okno se záložkami, kam je možné zadávat komentáře nebo zobrazovat
protokoly vykonaných testů. Navigace v protokolech jednotlivých testů je umožněna pomocí
tlačítek zpět (Back), vpřed (Forward), a domů (Main).
Tlačítkem Export… je možné exportovat zvolený protokol do formátu .html. Samotný
protokol testu se skládá z jednotlivých výpisů uvedených za příkazem System.Remark
v testovacím skriptu. Interní formát, ve kterém jsou protokoly uloženy je HTML, nicméně je zde
možnost přímo vytvořit protokol testu ve formátu HTML, případně XML, vepsáním tagu </pre> na
začátek skriptu a následovaný dalšími příslušnými formátovacími tagy.

Model jízdní dynamiky vozu Škoda Fabia | 26
4. Model jízdní dynamiky vozu Škoda Fabia
V této části diplomové práce bude popsáno samotné vytváření modelu dynamického
systému, který je předmětem této diplomové práce, pomocí nástroje Matlab/Simulink. Verze
Matlabu, použitého pro vytváření tohoto modelu, byla 7.8, verze Simulinku 7.3.
Jako simulovaný model dynamického systému byl zvolen model jízdní dynamiky vozu
Škoda Fabia 1.2 HTP. Celý model je díky své jednoduchosti velmi univerzální a lze jej tedy velmi
snadno upravit na model jiného, prakticky libovolného, vozu s manuální převodovkou. Samotná
parametrizace na konkrétní vůz probíhá pomocí inicializačního m-souboru, viz kapitola 4.6.
Inicializace modelu – ModelInitialization.m.
4.1. Top-level model
Tento model obsahuje sedm vstupů, které reprezentují tyto komponenty:
• Plynový, brzdový a spojkový pedál
• Napětí palubní sítě a startovací signál
• Zvolený rychlostní stupeň a úhel vozovky, po které se vůz pohybuje
Model má pouze jeden výstup, ten poskytuje informaci o aktuální rychlosti vozidla.
Obrázek 4—1 Top-level model znázorňuje nejvyšší úroveň modelu. Model je rozdělen do čtyř
subsystémů. Tyto virtuální subsystémy mají pouze hierarchický charakter, sdružují typické části a
jednotlivé funkce celého systému a nemají žádný vliv na samotné vykonávání systému jako celku.
Těmito subsystémy jsou:
• ECU – řídící jednotka motoru
• Engine – motor simulovaného vozidla
• GearBox – převodové ústrojí a
• Vehicle – samotný vůz
Vnitřními signály modelu jsou Throttle_Angle, kterým řídící jednotka nastavuje úhel škrticí
klapky motoru a Engine_Start, který znamená požadavek na nastartování motoru. Torque_Engine
signál má hodnotu aktuálně motorem generovaného točivého momentu, rpm_Engine zas
hodnotu aktuálních otáček motoru. W_Wheel představuje úhlovou rychlost otáčení kol vozidla,
tedy údaj odpovídající rychlosti samotného vozu, následně se v modelu vyskytují čtyři signály
reprezentující jednotlivé jízdní odpory.

4—1 Top-level model
rpmengine
2
Speed
1
Vehicle
w_Wheel
Hill_Angle
BrakeRelPos
Speed
T_Brake
T_Roll
T_Slope
T_Aero
GearBox
Torque_Engine
Gear_Number
ClutchRelPos
T_Brake
T_Roll
T_Slope
T_Aero
rpm_Engine
w_Wheel
Engine
Throttle_Angle
Engine_Start
rpm_Engine
Torque_Engine
ECU
ThrottleRelPos
VoltageON
IgnitionKey
rpm_Engine
Throttle_Angle
Engine_Start
Hill
7
Gear
6
Clutch
5
Brake
4
Throttle
3
Ignition
2
VoltageON
1

Všechny čtyři subsystémy, ze kterých se tento model skládá, stejně jako všechny signály
v tomto modelu obsažené budou následně vysvětleny. Dále bude popsáno, který subsystém
generuje jednotlivé vnitřní signály a jak ostatní subsystémy tyto signály využívají ke své funkci.
4.2. ECU – řídící jednotka motoru
4—2 ECU - řídící jednotka motoru
Prvním vstupem této jednotky je ThrottleRelPos, který reprezentuje polohu plynového
pedálu. Byla zavedena konvence, která říká, že hodnota 0 odpovídá plně uvolněnému pedálu a
hodnota 1 pedálu plně sešlápnutému. Tato konvence je dodržena i u ostatních dvou pedálů.
Vstup VoltageON znamená pro řídící jednotku informaci, že startovací klíč je v poloze 2
nebo v poloze 3 (start motoru). Náběžná hrana signálu přivedeného na vstup IgnitionKey je řídící
jednotkou interpretována jako informace pro spuštění startéru motoru po dobu 2 sekund nebo do
dosažení otáček motoru rovných 500 rpm.
Rpm_Engine je vstup jednotky, který udává aktuální rychlost otáčení motoru, v tomto
případě je hodnota již v jednotkách rpm, tedy počet otáček za minutu. V praxi je hodnota této
klíčové proměnné získána pomocí měření frekvence výstupu indukčního čidla připevněného do
blízkosti věnce setrvačníku. Z důvodu zjednodušení byl údaj tohoto čidla nahrazen již zmíněnou
proměnnou nesoucí informaci přímo o otáčkách motoru, tento fakt ovšem nemá žádný vliv
výsledek simulace tohoto modelu.
Obrázek 4—3 Vnitřní schéma řídící jednotky, znázorňuje vnitřní strukturu modelované
řídící jednotky. Jak je z této struktury patrné, je jednotka rozdělena do dvou funkčně oddělených
celků, kde každý z těchto jednotlivých celků obhospodařuje jeden ze dvou výstupů tohoto
subsystému. První z nich převádí informaci o poloze plynového pedálu na požadovaný úhel
natočení škrticí klapky. Druhý sleduje události na vstupech IgnitionKey a VoltageON a generuje
startovací příkaz pro spouštěč motoru. Nyní si rozebereme jednotlivé části těchto celků.
ECU
ThrottleRelPos
VoltageON
IgnitionKey
rpm_Engine
Throttle_Angle
Engine_Start

4—3 Vnitřní schéma řídící jednotky
deaktivovatstarter
prin>StarterDeactiv
deaktivovatpri
ThrottlePositionRel>=RevRegL
deaktivovatpri
ThrottlePositionRel<=RevRegH
aktivovatregulaciklapky
prin>RevRegLStart
Engine_Start2
Throttle_Angle
1
VoltageON12
StateToggle1
CondON
CondOFF
State
StateToggle
CondON
CondOFF
State
StarterDeactiv-C-
RevRegLStart-C-
RevRegLOW
revolutions[rpm]ActionLOW RevRegLAct-C-
RevRegHIGH
revolutions[rpm]ActionHigh
RevRegHAct-C-
<=
>
>=
<=
<=
>=
RelPosTOAngle
-K-
1
s
if{}
Out1
If
u1if(u1>0&u1<2)
Out1
rpm_Engine
4
IgnitionKey
3
VoltageON
2
ThrottleRelPos
1
n

Základní úlohou každé řídící jednotky motoru je generovat řídící signál pro nastavení
škrticí klapky motoru. Nejjednodušší řízení polohy škrticí klapky lze modelovat pouhým
vynásobením hodnoty o poloze plynového pedálu v rozsahu 0 až 1 číslem 90. Poté bude
požadovaná poloha škrticí klapky při plně sešlápnutém plynovém pedálu rovna 90° a při
uvolněném pedálu rovna 0°. To do jisté míry odpovídá realitě, nicméně toto zjednodušení celé
situace zanedbává dva podstatné fakty. Za prvé nutnost pootevření škrticí klapky pro udržení
minimálních (volnoběžných) otáček a za druhé omezení otáček při dosažení jisté maximální
hodnoty. Tyto vlastnosti řídící jednotky nám modelují dva použité regulátory: regulátor
maximálních otáček (RevRegHIGH) a regulátor minimálních otáček (RevRegLOW) a jejich řídící
logika reprezentována bloky StateToggle a StateToggle1 s příslušnými podmínkami.
4.2.1. Regulátor maximálních otáček
4—4 Regulátor maximálních otáček
Regulátor maximálních otáček, viz obrázek 4—4 Regulátor maximálních otáček, používá
informaci o aktuálních otáčkách motoru, od které odečítá hodnotu zvolených maximálních otáček
RevRegHAct (aktivační hodnota regulátoru max. otáček). Tento rozdíl aktuálních a maximálních
otáček motoru ݈݀݁‫ܪܽݐ‬ = ݊ − ݊_‫ܪܶܭܣ‬ je následně použit jako informace o chybě pro samotný PI
regulátor. Tento regulátor vynásobí tuto hodnotu regulační odchylky proporcionální konstantou
regulátoru a sečte ji s naintegrovanou hodnotou odchylky vynásobenou integrační konstantou
regulátoru. Hodnota proporcionální i integrační konstantou byla zvolena jako 0,01. Výstup tohoto
regulátoru je dále saturován tak, aby jeho výstup byl v rozmezí 0 až 1, a to z důvodu, aby regulátor
nepožadoval natočení klapky, které by bylo menší než 90°. Tato situace může nastat, pokud by
deltaH = n - n_AKTH
ActionHigh
1
RevRegHProportional
-K-
RevRegHIntegral
-K-
RevRegHAct
-C-
1
s
Enable
revolutions [rpm]
1
deltaH

hodnota odchylky byla delší dobu velmi vysoká, nicméně reálné minimum natočení škrticí klapky
je samozřejmě 0°.
Celý výše popsaný regulátor je umístěn do povolovaného subsystému. Z bloku
povolovacího portu je vyveden jeho výstupní port. Tento výstupní port má stejnou hodnotu jako
signál přivedený na samotný povolovací port povolovaného subsystému. Tento signál je následně
přiveden jako nulovací signál integrátoru, který je nastaven, aby vynuloval svůj stav v případě
výskytu náběžné hrany na svém externím nulovacím vstupu. Tímto je dosaženo jasně
definovaného výstupu regulátoru při jeho aktivaci. Bez této úpravy by výstup regulátoru mohl mít,
za jistých okolností, hodnotu odpovídající regulační odchylce z předchozí aktivace nebo hodnotu
velmi zápornou. V běžném režimu, kdy jsou otáčky motoru pod jejich maximální hodnotou, je
hodnota deltaH záporná a integrátor by tuto zápornou hodnotu vynásobenou integrační
konstantou neustále integroval. Tomuto jevu je dále zabráněno omezením výstupu samotného
integrátoru pouze na kladné hodnoty. Výstup tohoto subsystému je nastaven, aby jeho počáteční
hodnota byla rovna nule a dále aby byla nulována v okamžicích, kdy vykonávání tohoto subsystém
není povoleno, tedy v době, kdy jsou otáčky motoru menší než maximální.
4.2.2. Logika řízení regulátoru maximálních otáček
O samotné povolování resp. zakazování tohoto subsystému se stará blok s názvem
StateToggle, viz obrázek 4—5 Logika přepínání stavů regulátoru a na něj přivedené podmínky.
4—5 Logika přepínání stavů regulátoru
Tento blok má dva vstupy označené jako CondON a CondOFF a jeden výstup, zde označen
jako State, čili stav. Dále tento přepínač stavů obsahuje dva bloky přepínačů (Switch) s překlápěcí
úrovní rovnu nule a jeden blok paměti (Memory) s počáteční hodnotou taktéž rovnu nule. Na
první z těchto přepínačů je přiveden logický signál reprezentující splnění podmínky pro aktivaci
State
1
Memory0
1
CondOFF
2
CondON
1

regulátoru, na druhý přepínač je naopak přiveden signál znamenající, že byla splněna podmínka
pro deaktivaci regulátoru. Jednotlivé přepínače poskytují hodnotu svého výstupu danou hodnotou
bloku konstanty připojené na vstup číslo 1. Blok paměti zaručí, že výstup celého subsystému bude
hodnota přivedená na vstup číslo 1 odpovídajícího přepínače i v případě, že podmínka, která toto
vyvolala, již neplatí, ale opačná podmínka doposud nenastala. Toto zapojení se chová obdobně
jako RS klopný obvod a bylo by možné ho nahradit Stateflow diagramem, které by bylo snáze
čitelné.
Podmínka aktivace celého regulátoru maximálních otáček je splněna v případě, že aktuální
hodnota otáček motoru je větší nebo rovna než stanovená hranice maximálních otáček, v tomto
případě 4900 rpm. Jedná se tedy o stejnou hodnotu, jaká je použita pro získání odchylky
v samotném regulátoru, tedy RevRegHAct.
Podmínka pro deaktivaci regulátoru je splněna v případě, že pozice plynového pedálu
nastavena samotným uživatelem (tedy řidičem) je menší nebo rovna požadované pozici za
regulátorem. Tato situace nastává např. v situaci když: řidič sešlápne plynový pedál, motor
dosáhne svých maximálních otáček, výstup regulátor je odečten od řidičova požadavku, tudíž se
otáčky ustálí na své maximální hodnotě a řidič následně zvolí menší relativní polohu plynového
pedálu. Blok paměti v cestě signálu za výstupem regulátoru je zde pouze z důvodu odstranění
algebraické smyčky, která by při jeho nepřítomnosti vznikla a jeho vliv na modelovaný systém je
zanedbatelný (dán jako zpoždění této informace o jeden časový krok).
4.2.3. Regulátor minimálních otáček
4—6 Regulátor minimálních otáček
Funkce regulátoru minimálních otáček je analogická k funkci regulátoru maximálních
otáček. Proporcionální i integrační konstanty jsou shodné s konstantami použitými v předchozím
deltaL = n_AKTL - n
ActionLOW
1
RevRegLProportional
-K-
RevRegLIntegral
-K-RevRegLAct
-C-
1
s
Enable
revolutions [rpm]
1 deltaL

regulátoru, tedy rovny hodnotě 0,01. Stejné je i nastavení nulování integrátoru pomocí výstupu
bloku povolovacího portu a omezení jeho výstupu pouze na kladné hodnoty. Stejné je i nulování
výstupu regulátoru v okamžicích, kdy není tento subsystém aktivován, tedy v době kdy jsou
aktuální otáčky větší než stanovená minimální hodnota. Minimální otáčky motoru, a tedy i
hodnota konstanty RevRegLAct, byla stanovena na hodnotu 700 rpm.
Výstup regulátoru minimálních otáček je, na rozdíl od regulátoru maximálních otáček,
k uživatelem nastavené hodnotě přičítán. Tato situace nastává, např. když je motor vozidla
nastartován a plynový pedál je uvolněn, pak je uživatelem nastavená hodnota polohy škrticí
klapky rovna nule, ovšem motor potřebuje určité množství směsi nutné k vytvoření momentu
dostatečného k udržování minimálních otáček. Další situace, kdy je nutný zásah regulátoru
minimálních otáček, může nastat, když uživatelem nastavená poloha škrticí klapky během jízdy
není dostatečná ke generování momentu nutného k udržení minimálních otáček z důvodu zvýšení
jízdních odporů, např. odporu stoupáním.
4.2.4. Logika řízení regulátoru minimálních otáček
Podmínky k aktivaci regulátoru minimálních otáček jsou v tomto případě dvě. První
podmínka je analogická k podmínce u předchozího regulátoru, zde tedy podmínka, že aktuální
otáčky motoru jsou nižší nebo rovny stanoveným minimálním otáčkám (RevRegLAct). Další
podmínka, která musí být splněna současně s předchozí podmínkou, je ta, že otáčky motoru musí
být větší než jisté minimální otáčky nutné ke generování momentu motorem. Tato podmínka
odpovídá realitě spalovacích motorů, které potřebují jisté minimální otáčky k tomu, aby vůbec
mohli generovat moment. V tomto případě byly tyto minimální startovací otáčky stanoveny na
hodnotu 500 rpm, reprezentovány konstantou RevRegLStart.
Podmínka pro deaktivaci regulátoru minimálních otáček je analogická k podmínce použité
u regulátoru maximálních otáček. Regulátor je v tomto případě deaktivován v okamžiku, kdy
poloha plynového pedálu nastavená řidičem je větší nebo rovna poloze pedálu za regulátorem.
4.2.5. Generování signálu pro nastavení škrticí klapky
Signál pro nastavení škrticí klapky je získán jako součin polohy plynového pedálu za
oběma regulátory a čísla 90, reprezentovaného konstantou RelPosTOAngle, viz obrázek 4—3
Vnitřní schéma řídící jednotky. Tento signál je následně omezen na hodnoty v rozsahu od 0° do
90°, což jsou krajní polohy škrticí klapky. Bez tohoto omezení by výstup řídící jednotky mohl
v některých případech nabývat hodnoty větší než 90°, ačkoliv takovýto údaj neodpovídá realitě
řízeného systému. Poslední operací s požadovanou hodnotou polohy škrticí klapky je její

vynásobením logickou hodnotou reprezentující informaci o poloze startovacího klíče. V případě,
že je startovací klíč v poloze 2 nebo 3 (start motoru) je hodnota přivedená na vstup jednotky
VoltageON rovna 1 a požadovaná poloha klapky není nikterak ovlivněna. Při poloze startovacího
klíče 0 je hodnota na vstupu VoltageON rovna 0 a tedy i požadovaná poloha škrticí klapky je po
vynásobení rovna 0°. Tato část diagramu řídící jednotky představuje funkci vypnutí motoru.
4.2.6. Generování signálu pro start motoru
Další funkce implementovaná v tomto modelu řídící jednotky je funkce generování signálu
pro aktivaci spouštěče motoru. Tuto funkci zajišťuje část celkového diagramu řídící jednotky
zobrazená na následujícím obrázku 4—7 Část řídící jednotky, generování signálu spouštěče.
4—7 Část řídící jednotky, generování signálu spouštěče
Signál aktivující startér motoru je aktivní (roven 1) v případě, že jsou splněny dvě
podmínky. První podmínkou jsou otáčky motoru nižší nebo rovny konstantě StarterDeactiv.
Hodnota této konstanty byla zvolena 600 a reprezentuje fakt, že při dosažení hodnoty otáček
motoru 600 rpm je motor již schopen se točit silnou vlastního generovaného momentu a moment
startéru již není nutné dále generovat.
Další podmínkou, která musí být splněna k aktivaci startéru je vstup řídící jednotky
VoltageON roven 1, tedy fakt, že startovací klíč je v pozice 2 nebo 3.
Nyní k samotné funkci generátoru signálu pro start motoru. Konstrukčně je spouštěcí skříň
uspořádána tak, že nejprve je startovací klíč v poloze 0, pak 1, následně v pozici 2 a na krátký
okamžik v pozici 3. Doba setrvání klíče v pozici 3 je závislá pouze na vůli samotného řidiče.
V tomto modelu byla využita náběžná hrana generovaná při přechodu klíče z pozice 2 do pozice 3
na signálu IgnitionKey ke spuštění dříve povoleného subsystému (aktivní úrovní signálu ze vstupu
VoltageON). Uvnitř tohoto subsystému je pouze blok konstanty o hodnotě 1. Tato hodnota je tedy
následně integrována dříve vynulovaným integrátorem (náběžnou hranou signálu VoltageON).
deaktivovat starter
pri n > StarterDeactiv
Engine_Start 2
StarterDeactiv -C-
<=
1
s
if { }
Out1
If
u1 if(u1 > 0 & u1 < 2)
Out1
rpm_Engine
4
IgnitionKey
3
VoltageON
2
n

Tento integrátor má svůj výstup omezen od 0 do 2, přičemž do této hodnoty naintegruje přesně
po 2 vteřinách. Výstup tohoto integrátoru je následně použit jako vstup pro blok subsystému
podmínky jestliže. Tato podmínka je nastavena tak, aby byla splněna v případě, že vstup tohoto
bloku je větší než 0 a zároveň menší než 2. Tato podmínka spouští akční blok podmínky jestliže
jehož obsahem je opět pouze blok konstanty s hodnotou 1. Výsledné chování tohoto zapojení je
vygenerování pulzu o délce 2 sekundy začínajícího v okamžik kdy řidič otočí startovacím klíčem
z polohy 2 do polohy 3.
Dvě podmínky popsané výše poskytují dva možné případy startování motoru. První
nastává, v případě, že se pokoušíme nastartovat nezatížený motor, tedy standardní startování
motoru. V tomto případě je startovací pulz kratší než 2 vteřiny neboť motor dosáhne, díky
velkému momentu generovaného startérem, bez problému hodnoty otáček 600 rpm.
Druhý případ nastane například v situaci, kdy se řidič snaží nastartovat zatížený motor,
např. se zařazeným rychlostním stupněm a uvolněným spojkovým pedálem. V takovém případě
není moment generovaný startérem dostatečný k roztočení motoru na hodnotu alespoň 500 rpm
(hodnota otáček, kdy samotný motor začne generovat vlastní moment). Startovací proces v tomto
případě skončí po 2 vteřinách neúspěšně. Po takovéto situaci je nutné otočit klíčem zpět do pozice
1 nebo 0 a následně se opětovně pokusit motor nastartovat. Bez tohoto postupu by startovací
pulz nebyl generován neboť by integrátor nebyl vynulován a dále si udržoval hodnotu výstupu
rovnu 2, navazující podmínka jestliže by tedy nebyla splněna.
4.3. Engine – motor
4—8 Engine - motor
Subsystém reprezentující model motoru je zobrazen na obrázku 4—8 Engine - motor.
První dva vstupy tohoto subsystému jsou signály generované řídící jednotkou popsanou
v předchozí kapitole 4.2. ECU – řídící jednotka motoru. Throttle_Angle udává informaci o
požadovaném natočení škrticí klapky. Tento údaj je v praxi často realizován pomocí PWM signálu
Engine
Throttle_Angle
Engine_Start
rpm_Engine
Torque_Engine

přivedeného na krokový motorek ovládající samotnou klapku, v tomto modelu byla použita přímo
číselná hodnota ve stupních, tento fakt opět nemá vliv na požadovanou simulaci dynamiky
jízdních vlastností.
Druhým signálem je Engine_Start taktéž generovaný řídící jednotkou. Tento signál aktivuje
spouštěč motoru, který bude popsán v následující kapitole 4.3.3 Spouštěč motoru.
Posledním vstupem tohoto subsystému je rpm_Engine, nesoucí informaci o aktuálních
otáčkách motoru. V praxi tento signál do motoru žádným způsobem zaváděn není, motor
samozřejmě zná svojí rychlost otáčení, nicméně pro simulaci je nutné tuto informaci do tohoto
systému zavést.
Výstupem subsystému motoru je krouticí moment generovaný motorem Torque_Engine.
4—9 Vnitřní schéma motoru
Obrázek 4—9 Vnitřní schéma motoru ukazuje vnitřní strukturu modelu motoru. Je patrné,
že se skládá z 3 oddělených částí, jejichž výstupy jsou následně sečteny. Horní část schématu
představuje samotné generování momentu motoru. Část uprostřed simuluje tzv. ztrátový
moment motoru a povolovaný subsystém v dolní části reprezentuje startér motoru. Nyní si
popíšeme jednotlivé součásti subsystému motoru detailněji.
4.3.1. Generování krouticího momentu motorem
Horní část obrázku 4—9 Vnitřní schéma motoru představuje část, která v modelu motoru
generuje krouticí moment. Krouticí moment generovaný spalovacími motory obecně závisí po
Torque_Engine
1
rpm2rad
rpm rad
Throttle Dynamics
1/90
[0.06 1]
Starter
rpm StarterTorque
LossTorque
rpm LossTorque
EngineTorqueLUT
Engine Torque Scaling
-K-
0
rpm_Engine
3
Engine_Start
2
Throttle_Angle
1
Throttle
Relative Position
EngineTorque
StarterTorque
LossTorque

jistém zjednodušení (zanedbání signálu od Lambda sond, teploty motoru, teploty a tlaku
nasávaného vzduchu atd.) především na úhlu natočení škrticí klapky a otáčkách motoru. K
zanedbání signálů od Lambda sond jsme přistoupili po zavedení předpokladu, že regulace
bohatosti směsi je ideální a tudíž množství vstřikovaného paliva v každém okamžiku je přesně ve
stochastickém poměru k množství nasávaného vzduchu. Vliv teploty na velikost generovaného
momentu není příliš veliký a byl v tomto modelu zanedbán. Teplota a tlak nasávaného vzduchu
byly taktéž zanedbány, předpoklad vedoucí k tomuto kroku byl ten, že mapa momentu byla
vytvořena za jistých podmínek a tyto podmínky jsou neměnné v průběhu celé simulace.
Jak je z obrázku 4—9 Vnitřní schéma motoru patrné, je vstup Throttle_Angle zaveden na
vstup bloku přenosové funkce (Transfer function), která představuje přenos řídícího signálu,
v rozsahu 0° až 90° generovaného řídící jednotkou, na informaci o reálném relativním natočení
škrticí klapky, v rozsahu od 0 do 1. Samotná přenosová funkce byla zvolena odhadem, s časovou
konstantou rovnou 60 ms. Důvodem pro převod úhlu natočení klapky zpět na relativní natočení
byl fakt, že dostupná mapa momentu má jeden ze svých dvou parametrů právě poměrné natočení
klapky.
4—10 Mapa momentu
Zmíněná mapa momentu, zobrazená na obrázku 4—10 Mapa momentu, je úplná
charakteristika spalovacích motorů obecně. V těch jednodušších případech, jako byl tento, má
pouze dva vstupní parametry (relativní natočení klapky resp. úhel natočení a aktuální otáčky
motoru). Výstupem této funkce, typicky zadané jako tabulka naměřených nebo simulovaných dat
0
0.2
0.4
0.6
0.8
1
0100200300400500600
0
5
10
15
x 10
5
Throttle
Relative
PositionEngine rpm
Torque

je velikost momentu tímto motorem generovaným. Tento moment může být tzv. celkový, tedy
včetně ztrát nebo tzv. činný neboli bez započítání vlastních ztrát, konkrétní typ naměřených dat
závisí na konfiguraci samotného měření resp. typu simulace. V tomto případě byly k dispozici data
o činném momentu motoru Škoda Fabia 1.2 HTP.
Tato mapa momentu resp. data byly použity jako řádkové a sloupcové hodnoty v tabulce
s přímým výběrem (2D Lookup Table). Vzhledem k tomu, že máme jako vstupní informaci
k dispozici údaj o aktuálních otáčkách motoru v otáčkách za minutu, ale vstupní parametr použité
mapy momentu je třeba zadávat v radiánech za sekundu, bylo nutné použít jistý převodník.
V tomto případě nám tento převod zajišťuje blok s názvem rpm2rad, který obsahuje pouze blok
zesílení (Gain) s konstantou π/30. Samotná tabulka s přímým výběrem má jako metodu výběru
nastavenu na interpolaci-extrapolaci (Interpolation-Extrapolation). Vzhledem k tomu, že počet
naměřených dat je konečný, je volba metody s interpolací zřejmá. Extrapolaci se v tomto případě
musíme vyhnout, a to např. za pomoci omezení signálu Throttle_Angle v samotné řídící jednotce.
Další možností může být zvolení metody výběru: Interpolace-použít mezní hodnoty (Interpolation-
Use End Values).
Za tabulkou s přímým výběrem následuje blok přepínače (Switch block). Hodnota jeho
rozhodovací úrovně je nastavena na 500 rpm. Při nižších otáčkách motoru než 500 rpm je
generovaný moment nulový. Toto zapojení reprezentuje fyzikální fakt, že spalovací motor není
schopen generovat moment, pokud jeho otáčky nejsou vyšší než jisté minimální otáčky.
Následující blok zesílení pouze upravuje výstupní hodnoty mapy momentu do reálných hodnot,
vydělením číslem 10000.
4.3.2. Ztrátový moment motoru
Jak bylo již zmíněno v předchozí kapitole, v některých případech je nutné modelovat
ztrátový moment motoru zvlášť. Takový případ nastává, když data v mapě momentu reprezentují
pouze moment činný. Odlišnou konfigurací měření na testovaném motoru lze získat data
odpovídající tzv. ztrátovému momentu. Tyto data bývají opět udávána ve formě dvou vektorů
resp. tabulky. Vstupním parametrem často bývají pouze otáčky motoru, při požadavku na
přesnější údaje je možné zahrnout do vstupních parametrů i úhel natočení škrticí klapky. V tomto
případě byla k dispozici data pouze s otáčkami motoru jako vstupním parametrem, nicméně tento
parametr má dominantní vliv na ztrátový moment a v našem případě jsou taková data dostatečně
přesná.

Obrázek 4—11 ukazuje graf naměřených dat, která byla k dispozici při modelování tohoto
subsystému. Je z něj patrné, že průběh ztrátového momentu neprochází nulou, ale konverguje pro
nulové otáčky k hodnotě přibližně -10 Nm. Tento podstatný fakt je třeba brát v úvahu při zadávání
dat do samotné tabulky s přímým výběrem. Musíme mít totiž stále na mysli, že celý modelovaný
systém bude simulován na platformě s pevným časovým krokem, konkrétně 1 ms. Uvažujme
situaci kdy je ukončen přívod paliva do válců a model motor by se měl zastavit, čili otáčky motoru
by měly být po určité době nulové. Motor negeneruje žádný moment, který by ho roztáčel,
přítomen je pouze moment ztrátový. Ten ho v čase t brzdí určitým momentem, řekněme -10 Nm.
V čase ‫ݐ‬ + 1 ݉‫ݏ‬ již ovšem může být hodnota otáček motoru záporná z důvodu, že nulové otáčky
byly dosaženy někdy mezi po sobě jdoucími časovými kroky.
4—11 Průběh ztrátového momentu
Tento problém lze vyřešit například vytvořením symetrických dat použitých pro tabulku
s přímým výběrem, jak ukazuje obrázek 4—12.
4—12 Modelovaný průběh ztrátového momentu
-35
-30
-25
-20
-15
-10
-5
0
0 1000 2000 3000 4000 5000 6000
Torque
Engine rpm
-4000 -2000 0 2000 4000 6000
-30
-20
-10
0
10
20
30
Torque
Engine rpm

Detail průběhu zadaných hodnot je znázorněn na obrázku 4—13.
4—13 Detail průběhu ztrátového momentu v okolí nulových otáček
4.3.3. Spouštěč motoru
Model startéru je řešen pomocí povolovaného subsystému s názvem Starter (spouštěč),
který je povolován signálem Engine_Start z řídící jednotky, probrané v kapitole 4.2. ECU – řídící
jednotka motoru. Jeho vnitřní struktura je na obrázku 4—14 Spouštěč motoru.
4—14 Spouštěč motoru
Opět je použita jednorozměrná tabulka s přímým výběrem, s metodou výběru pomocí
interpolace-extrapolace. Tato tabulka nám reprezentuje chování samotného spouštěče, tedy
elektrického stroje, jehož moment je v okamžiku sepnutí maximální a s narůstajícími otáčkami
klesá k nule. Zvolený průběh momentu spouštěče ukazuje obrázek 4—15 Průběh momentu
spouštěče.
-40 -30 -20 -10 0 10 20 30 40
-10
-8
-6
-4
-2
0
2
4
6
8
10
Torque
Engine rpm
StarterTorque
1
Switch
Lookup Table
Constant0
Enable
rpm
1

4—15 Průběh momentu spouštěče
Za touto tabulkou s přímým výběrem se nachází přepínač, který má rozhodovací úroveň
nastavenu na hodnotu 800 rpm. Pokud jsou otáčky motoru menší, než tato hodnota, pak výstup
subsystému spouštěče odpovídá hodnotě generovaného momentu v závislosti na otáčkách. Pokud
je hodnota otáček motoru vyšší než 800 rpm a spouštěč by byl přesto spuštěn, bude jím
generovaný moment nulový. Tato skutečnost odpovídá realitě, kdy jsou skutečné spouštěče
opatřeny ochranou proti přenosu točivého momentu z motoru na spouštěč, který by jej mohl
poškodit. Tato ochrana je realizována mechanicky, např. tzv. volnoběžkou nebo pomocí systému
Bendix. Pro jednoduchost není ve spouštěči uvažován žádný vnitřní převod, na rozdíl od
skutečných spouštěčů, kde je nějaký převod pro zvýšení momentu vždy přítomen.
4.4. GearBox – Převodové ústrojí
4—16 GearBox - převodové ústrojí
Subsystém reprezentující model převodového ústrojí je zobrazen na obrázku 4—16
GearBox - převodové ústrojí. Je patrné, že jeho vstupy jsou Torque_Engine moment generovaný
motorem, Gear_Number zvolený převodový stupeň a ClutchRelPos udávající relativní sešlápnutí
0 200 400 600 800
0
20
40
60
80
100
Torque
Engine rpm
GearBox
Torque_Engine
Gear_Number
ClutchRelPos
T_Brake
T_Roll
T_Slope
T_Aero
rpm_Engine
w_Wheel

spojkového pedálu. Dále jsou zde čtyři vstupy jednotlivých jízdních odporů T_brake představující
brzdný moment, T_roll moment odvalování pneumatik, T_slope moment stoupáním a T_aero
moment odporu vzduchu.
Model převodového ústrojí obsahuje dva výstupy rotačních rychlostí. První z nich
rpm_Engine, udává rotační rychlost samotného motoru v otáčkách za minutu, tento důležitý údaj
je použit v obou subsystémech popsaných v předešlých kapitolách. Druhým výstupem tohoto
subsystému je w_Wheel, který má hodnotu úhlové rychlosti otáčení hřídele za diferenciálem a
tudíž i kmitočtu otáčení kol modelovaného vozidla, jednotky této veličiny jsou radiány za sekundu.
4—17 Schéma převodového ústrojí
w_Wheel
2
rpm_Engine
1
Transmission
Torque_Engine
Gear_Number
ClutchRelPos
Torque_Load
w_Wheel
rpm_Engine
T_GearBox
BrakeSolution
speed
T_Brake
T_Slope
T_Aero
T_Roll
T_GearBox
Torque_Load
T_Aero
7
T_Slope
6
T_Roll
5
T_Brake
4
ClutchRelPos
3
Gear_Number
2
Torque_Engine
1

Obrázek 4—17 Schéma převodového ústrojí znázorňuje vnitřní strukturu subsystému
GearBox- převodové ústrojí. Toto schéma je dále rozděleno do dvou dílčích subsystémů
Transmission, neboli převodovka a BrakeSolution představující řešení brzdy modelovaného
vozidla. Jak je z obrázku patrné, oba tyto subsystémy jsou navzájem propojeny, subsystém řešení
brzdy (BrakeSolution) potřebuje ke své funkci informaci o rychlosti vozidla a subsystém
převodovky (Transmission) zase nemůže fungovat bez informace o celkovém zátěžovém momentu
působícího na vozidlo. Nyní budou jednotlivé subsystémy probrány více podrobně.
4.4.1. Transmission – převodovka
Na první pohled je zřejmé, že tento subsystém je z celého modelu nejrozsáhlejší a zároveň
nejsložitější. Základním problémem je modelace chování spojky jako členu, který spojuje a
rozpojuje hřídel vystupující z motoru a hřídel, která pohání samotná kola, přičemž tato hřídel
může být jak hnaná tak hnací, čili model musí umožnit přenos momentu v obou směrech.
Umístění spojky v celém řetězci přenosu momentu z motoru na kola je zobrazeno na
následujícím obrázku 4—18 Schéma hnací soustavy.
4—18 Schéma hnací soustavy
Motor generuje moment motoru MM, který je spojkou přenášen na vstupní hřídel
převodovky, označme ho MS. Moment spojky je následně vynásoben převodovým poměrem i a
způsobuje otáčivý pohyb hřídele spojené s hnacími koly vozidla ωk. Proti tomuto momentu působí
ztrátový moment MZ, který odpovídá součtu všech jízdních odporů působících na vozidlo.
Převodovkou se v tomto případě myslí nejenom samotná převodová skříň, ale i diferenciál, který
má konstantní převodový poměr. Převodový poměr i je tedy součinem poměru zvoleného
převodového stupně a poměru diferenciálu. JM je moment setrvačnosti motoru a jeho hodnota je
pro daný typ motoru přibližně 0,4 ݇݃ ∙ ݉ଶ
, JV je moment setrvačnosti celého vozidla, tato hodnota
pro námi modelované vozidlo byla zvolena jako 102 ݇݃ ∙ ݉ଶ
.
i
ωM ωS ωk
JM JVMM MS MZ
motor převodovkaspojka

Připomeňme Newtonův druhý pohybový zákon o hybnosti pevných těles, označovaný také
jako zákon síly, který je využíván v celém modelu převodového ústrojí.
‫ܯ‬ = ‫ܬ‬ ∙ ߱ሶ (4-1)
Pokud známe moment setrvačnosti hřídele J, na kterou působí točivý moment M,
můžeme vypočítat její úhlové zrychlení jako:
߱ሶ =
ெ
௃
(4-2)
a její úhlovou rychlost získáme následnou integrací tohoto výrazu:
߱ =
ଵ
௃
∙ ‫׬‬ ‫ܯ‬ ݀‫ݐ‬ (4-3)
Z principu funkce spojky se tento člen může nacházet ve dvou odlišných režimech. První
režim označovaný jako režim sepnuté spojky nastává, když jsou splněny následující dvě
podmínky:
1. Rychlost otáčení hřídele před a za spojkou jsou shodné
podmínky: ߱ெ = ߱௄ ∙ ݅ a ߱ሶ ெ = ߱ሶ ௄ ∙ ݅ (4-4)
2. Moment spojky je menší nebo roven maximálnímu momentu v daném okamžiku
podmínka: ‫ܯ‬ௌ ≤ ‫ܯ‬௠௔௫ (4-5)
První podmínka je zřejmá a tedy, že se obě spojované hřídele otáčejí shodnou rychlostí.
Druhá podmínka respektuje fyzikální podstatu spojky, a to takovou, že spojkou je možné přenést
pouze omezený moment závislý na přítlačné síle působící na lamely spojky a tzv. konstantě spojky.
Konstanta spojky je úměrná počtu lamel spojky, konstantě tření daných lamel a vnitřnímu
průměru styku těchto lamel. V tomto případě byly zvoleny následující hodnoty:
• Maximální přítlačná síla ‫ܨ‬௠௔௫ = 10000 ܰ
• Počet lamel ݈ = 2
• Konstanta tření ߤ = 0,1
• Vnitřní průměru styku lamel ܵ௜௡ = 0,1 ݉ଶ
Z výše uvedených hodnot vychází konstanta spojky následovně:
• ݇ = ݈ ∙ ߤ ∙ ܵ௜௡ = 2 ∙ 0,1 ∙ 0,1 = 0,02 ሾ−ሿ

Tyto hodnoty byly zvoleny s ohledem na modelovaný motor, který je schopen generovat
přibližně 160 Nm točivého momentu, spojka s výše uvedenými parametry je schopna přenést
moment maximálně 200 Nm a tedy je možné ji použít pro tento typ motoru.
Výše uvedené schéma na obrázku 4—18 lze v sepnutém režimu popsat následujícími rovnicemi:
‫ܯ‬ெ – ‫ܯ‬ௌ = ‫ܬ‬ெ ∙ ߱ሶ ெ (4-6)
‫ܯ‬ௌ ∙ ݅ – ‫ܯ‬௓ = ‫ܬ‬௏ ∙ ߱ሶ ௞ (4-7)
߱ሶ ெ = ߱ሶ ௞ ∙ ݅ a ߱ெ = ߱௞ ∙ ݅ (4-8)
Po dosazení a vykrácení těchto výrazů získáme moment spojky jako:
‫ܯ‬ௌ =
ெಾ ∙ ௃ೇ ା ௃ಾ ∙ ெೋ ∙ ௜
௃ೇ ା ௃ಾ ∙ ௜మ
(4-9)
Tento výraz již lze velmi snadno modelovat například tímto schématem základních bloků
Simulinku:
4—19 Schéma režimu sepnuté spojky
Závěrečná operace označená jako offset elimination slouží k eliminaci offsetu, který vzniká
v důsledku numerického výpočtu zadaných rovnic. Bez eliminace tohoto offsetu by se rychlost
otáčení hřídele za spojkou jen velmi pomalu nebo dokonce nikdy nevyrovnala rychlosti otáčení
hřídele přenášející moment z motoru.
Druhým režimem, v němž se může spojka nacházet je režim prokluzující spojky. V tomto
režimu je velikost momentu přenášeného spojkou MS rovna součinu konstanty spojky ݇ = 0,02
(odvozené výše) a přítlačné síle působící v daný okamžik mezi lamelami spojky. Tato síla je přímo
offset elimination
Lock mode Clutch Torque:
(Me * Jv + Je * M_load * i)
Mc = -------------------------------------
(Jv + Je * i* i)
T_lock
1
u
2
MomentInertia.Vehicle
MomentInertia.Vehicle
MomentInertia.Engine
-K-
delta_rpm
4
GearRatio
3
T_Load
2
T_Engine
1
i * i
Jv
Je * i * i
Je * M_load * i
Me * Jv

úměrná poloze spojkového pedálu, při plně sešlápnutém pedálu je síla působící na lamely nulová,
při plně uvolněném pedálu je naopak síla maximální tedy 10000 N.
4—20 Schéma režimu prokluzující spojky
Tento moment lze modelovat například zapojením na obrázku 4—20 Schéma režimu
prokluzující spojky. Je zde na prvním místě opět blok saturace s omezením od 0 do 1 z důvodu,
aby nedocházelo k neočekávaným výsledkům při nedodržení konvence týkající se pedálů.
Následné odečtení hodnoty 1 spolu s funkcí absolutní hodnoty nám zaručí dodržení této
konvence, tedy že hodnota 1 (sešlápnutý pedál) představuje nulovou sílu mezi lamelami a tedy i
nulový přenášený moment, hodnota 0 (uvolněný pedál) nám v tomto případě bude generovat
maximální přenášený moment, tedy 200 Nm. Výstup tohoto subsystému označený jako T_max,
úměrný sešlápnutí spojkového pedálu ClutchPos, je následně použit pouze pro logiku rozhodování
mezi stavy systému. Vstupní údaje o rychlosti otáčení motoru w_Engine a rychlosti otáčení vstupní
hřídele převodovky (součin rychlosti otáčení kol w_Vehicle a převodového stupně GearRatio) jsou
použity k určení orientace přenášeného momentu v režimu prokluzující spojky. Tímto způsobem
je vyřešen problém přenášení točivého momentu v obou směrech, jak z motoru na kola (rozjezd a
samotná jízda vozidla) tak i z kola do motoru (brzdění motorem). Údaj o rozdílu rychlostí obou
hřídelí delta_rpm je použit k eliminaci offsetu při sepnuté spojce, jak již bylo vysvětleno výše.
Nyní, když máme k dispozici subsystémy reprezentující oba režimy spojky, je nutné
vytvořit logiku rozhodování který z těchto režimů je právě platný. K tomuto účelu slouží přepínač,
ve schématu 4—23 Schéma převodovky, označený jako lock/slip a blok samotné logiky
ClutchMode zobrazený na obrázku 4—21 Logika řízení režimů spojky.
T_max
3
delta_rpm
2
T_slip
1
1
Clutch Max Force
-K-
Clutch Constant
-K- |u|
w_Vehicle
4
w_Engine
3
GearRatio
2
ClutchPos
1
w kola * i

Master_Thesis

Recommended

Recommended

More Related Content

Similar to Master_Thesis

Similar to Master_Thesis (7)

Master_Thesis