MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Návrh a implementace nového protokolu sběrnice MTBbus DIPLOMOVÁ PRÁCE Jan Horáček Brno, jaro 2021 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Návrh a implementace nového protokolu sběrnice MTBbus DIPLOMOVÁ PRÁCE Jan Horáček Brno, jaro 2021 Na tomto místě se v tištěné práci nachází oficiální podepsané zadání práce a prohlášení autora školního díla. Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Jan Horáček Vedoucí práce: RNDr. Zdeněk Matěj, Ph.D. i Poděkování Děkuji především všem, kteří ve mně zažehli, podporovali a podporují můj velký koníček - řízení modelové železnice. Ať už se jedná o tátu Miroslava, přítelkyni Verču, členy brněnského modelářského klubu nebo vedoucího mé diplomové práce Zdeňka Matěje. Všichni ti mi umožnili psát diplomovou práci, jejíž náplň mi dává smysl, jejíž realizace mě baví a jejíž výsledky vidím v reálném světě. Moc si vaší podpory vážím. Děkuji svému vedoucímu Zdeňku Matějovi za korektury a podporu ve změně tématu. Děkuji konzultantovi Honzu Mrázkovi za odpovídání na mé dotazy a za rady. Děkuji všem korektorům této práce: Veronice Burgerové, Miroslavu Horáčkovi a Zdeňku Matějovi. Děkuji mé přítelkyni Veronice a tučňákovi Adalbertovi za mentální podporu. ii Abstrakt Se zaváděním počítačového řízení železniční dopravy vznikaly systémy umožňující centrálnímu řídicímu počítači interakci s venkovními prvky zabezpečovacího zařízení - výhybkami, návěstidly apod. Tato práce se zaměřuje na návrh a implementaci sběrnice, která takovou interakci umožní, ovšem na kolejištích modelových. Práce navrhuje a implementuje nový protokol sběrnice pro řízení modelových kolejišť MTBbus. Je popsáno, proč je současný systém řízení kolejiště nedostatečný, jsou formulovány požadavky na nový systém, tento systém je implementován. V rámci práce vznikl detailní návrh nového protokolu, nové hardwarové moduly pro řízení kolejiště, modul pro komunikaci s počítačem, obslužný počítačový software a knihovna integrující nový hardwarový systém se současným řídicím softwarem kolejiště. Nový řídicí systém byl otestován a nasazen na skutečná kolejiště, čímž umožnil jejich další rozšiřování a zprovoznění nových způsobů řízení dopravy. Vznikl otevřený a robustní systém s výhledem dlouhodobé udržitelnosti, který svými vlastnostmi převyšuje mnohé současné komerční systémy řízení modelových kolejišť. Vzniknuvší systém je obecný, takže jej lze použít i v mnoha jiných aplikacích. iii Klíčová slova sběrnice, pic, mtb, mtbbus, rs485, embedded, stm32, qt, usb, cdc, protokol, avr, arm, dec iv Obsah 1 Úvod 3 2 Současné nasazení sběrnice MTBbus 5 2.1 Popis systému MTB 5 2.2 IR čidla 9 2.3 Systém MTB v kontextu řízení modelového kolejiště 10 2.4 Proč současný systém MTB nedostačuje 12 2.4.1 Všeobecné požadavky na nový systém MTB . . 13 3 Existující řešení 14 3.1 Digital Command Control 14 3.1.1 Sběrnice zpětného hlášení 19 3.2 BiDiB 22 3.3 Závěr 22 4 Návrh MTB v4 24 4.1 Podrobná specifikace požadavků 24 4.1.1 Periferie v kolejišti 24 4.1.2 Ovládání 26 4.1.3 Další požadavky 27 4.1.4 Shrnutí požadavků 28 4.2 Návrh systému MTB v4 29 4.2.1 Vysokoúrovňový návrh 29 4.2.2 MTBbus 31 5 Implementace MTB v4 42 5.1 MTB-USBv4 42 5.1.1 Komunikační protokol s počítačem 42 5.1.2 Hardware 45 5.1.3 Firmware 48 5.2 MTB-UNIv4 49 5.2.1 Základní parametry 49 5.2.2 Hardware 50 5.2.3 Deska plošných spojů 53 5.2.4 Firmware 53 5.3 MTB-2-AVR 55 v 5.4 IRdet 57 5.5 MTB Daemon 59 5.5.1 Protokol TCP serveru 59 5.5.2 Volba nástrojů 60 5.5.3 Implementace 61 5.6 hJOP MTB Network RCS knihovna 63 6 Závěr 64 6.1 Možná rozšíření 65 Bibliografie 67 A Přílohy 70 vi Seznam použitých zkratek API Application Interface, rozhraní aplikace. 12, 26, 31, 59, 61 BiDiB BiDirectional Bus, viz http: / / b i d i b . org/. 22, 23 CDC USB Comunications Device Class, třída USB protokolu implementující tunelování sériové linky skrze USB. 30, 31,43,46 DCC Digital Command Control, mezinárodně užívaný standardizovaný systém pro digitální řízení modelové železnice. 5,11,14,15, 17-22, 51, 65,66 DIL Duál in-line package, způsob provedení pouzdra integrovaných obvodů s dvěma řadami pinů pro osazovaní do děr (tzv. THT osazování). 52, 55 DPS Deska plošnýcn spojů. 46,47,49, 50, 52, 53, 55, 58 HID Human Interface Device, třída USB protokolu sloužící k připojení zařízení interagujících s uživatelem - myší, klávesnic apod. 43 IR Infra-red. 7-10,16, 26, 29,49, 56-58 KMŽ Brno I Klub modelářů železnic Brno I. 5,10-12,16, 22, 25-28, 63, 65 LED Light emitting diodě, součástka vydávající světlo určité barvy. 27, 28, 36,48, 55, 56 MTB Hardwarový systém pro řízení modelových kolejišť složený ze sběrnice MTBbus, MTB modulů, MTB-USB desky a počítačových knihoven. 4-7,9-13,17, 23-32, 34, 36-45,47,49,56-62, 64-66 MTB-UNI Nejrozšířenější slavě modul sběrnice MTBbus, má 16 digitálních vstupů a 16 digitálních výstupů. 7, 8,10,25, 26, 28, 29,37, 38,41,49, 50, 52-57, 64, 72 1 SEZNAM POUŽITÝCH ZKRATEK MTB-USB Master modul sběrnice MTBbus, implementuje rozhraní mezi MTBbus a počítačem (USB). 5, 6, 9, 29-32, 34, 36, 38-40, 42-47, 59, 64, 65, 71 MTBbus Model Train Bus1 , sběrnice určená pro řízení modelových kolejišť. v, 4-7, 22, 24-26, 28-32, 34, 35, 37^5,47, 53-56, 64 NMRA National Model Railroad Association. 14,19 PLC Programmable Logic Controller, robustní zařízení průmyslové automatizace. 3,4,19, 24, 64 S-COM Jednoduchý jednosměrný komunikační protokol, který umožňuje přenášet návěsti návěstidel [1]. 7,21, 24, 25,28,49 SMD Surface mount device, elektronická součástka určená pro osazení přímo na povrch plošného spoje. 46, 53, 55,58 TCP Transmission Control Protocol, používaný protokol transportní vrstvy počítačových sítí garantující spolehlivé doručování dat. 31, 59, 62 TTL Transistor-transistor-logic, v kontextu této práce standard definující jaká napěťová úroveň odpovídá jaké logické úrovni. 8, 51 USB Universal Seriál Bus, v současnosti nejpoužívanější sběrnice pro připojení periferií k počítači. 22, 30,43,44,46^8 1. Expanze zkratky do jejího plného významu nedává smysl, i tak budeme používat označení MTBbus, protože tak je zkratka zaužívaná. 2 1 Úvod Programmable Logic Controller (PLC) je vestavěný počítač, který zpracovává vstupy, provádí jejich vyhodnocování, komunikuje s dalšími PLC obvody a nastavuje výstupy [2]. Na rozdíl od běžných počítačů typu PC mají PLC větší množství vstupů a výstupů, běží na nich realtime operační systémy a jsou vysoce robustní. PLC jsou základní jednotkou průmyslové automatizace. Používají se například pro řízení světel dopravních křižovatek, výrobních linek, eskalátorů, řízení elektráren, rozvoden apod. Všude tam PLC zpracovávají data z čidel a ovládají periferie - například motorické pohony, signalizační diody, robotické ruky, lasery apod. Obrázek 1.1: Průmyslové PLC moduly. Převzato z wikimedia.org. V této práci se zaměříme na podmnožinu P L C modulů - totiž na takové, jejichž hlavním úkolem je správně zpracovávat vstupní signály a ovládat výstupní periferie. Řízení logiky průmyslového procesu přenecháme počítači, s kterým PLC moduly komunikují.1 1. V praxi může P L C modul řídit logiku procesu přímo, my však tuto situaci zkoumat nebudeme. 3 i . ÚVOD Cílem této práce je navrhnout a implementovat novou verzi komunikační sběrnice PLC obvodů zvanou MTBbus (Model Train Bus2 ). MTBbus je sběrnice, která se využívá pro řízení modelových kolejišť. Je součástí systému MTB. Skrze sběrnici lze číst signály z kolejiště (například polohy výhybek, obsazenost kolejových obvodů) a povelovat prvky v kolejišti (návěstidla, přestavníky výhybek, přejezdy apod.). Obdobným způsobem funguje zapezpečovací zařízení na skutečné železnici. V této práci autor nejprve popíše současné nasazení systému MTB. Budou formulovány důvody vedoucí k nutnosti aktualizace sběrnice. Autor popíše, proč jsou dostupná komerční řešení nevhodná a navrhne vlastní nové (1) protokoly, (2) hardwarové moduly a (3) počítačové programy, které jím formulovaný problém řeší. 2. Expanze zkratky do jejího plného významu nedává smysl, i tak budeme používat označení MTBbus, protože tak je zkratka zaužívaná. 4 2 Současné nasazení sběrnice MTBbus Systém M T B vznikl okolo roku 2000, kdy se hledal vhodný systém pro programovatelné počítačové řízení modelové železnice, spoluprací nadšenců z Klubu modelářů železnic Brno I (dále jen KMŽ Brno I) a Klubu železničních modelářů Praha 3 1 [3]. Digital Command Control (DCC), dnes pravděpodobně nej rozšířenější2 mezinárodně standardizovaný systém pro digitální řízení modelové železnice [4], tehdy ještě nebyl v České republice rozšířený. Navíc přirozeně vyvstal požadavek na minimalizaci nákladů a maximalizaci nezávislosti na komerčních produktech rodiny jednoho výrobce. Vznikl tedy systém MTB, který se pro řízení modelových kolejišť v KMŽ Brno I používá doposud [5]. Podotkněme, že systém MTB se do dalších klubů po České Republice nerozšířil - nejspíš proto, že není podporovaný komerčními softwary pro řízení modelové železnice a že jej jeho původní autor v roce 2008 přestal udržovat. 2.1 Popis systému MTB Systém MTB se skládá z: 1. sběrnice MTBbus, 2. MTB modulů, 3. MTB-USB modulu, 4. počítačových knihoven pro přístup k MTB-USB. Každé kolejiště má svou vlastní sběrnici MTBbus, ke které je připojený právě jeden MTB-USB modul a až 255 M T B modulů. MTB-USB řídí provoz sběrnice MTBbus a je připojen k počítači. M T B moduly jsou 1. Je překvapivé, že skupina nadšenců tehdy dokázala vytvořit systém, který by se mohl poměřovat se současnými komerčními systémy řízení modelových kolejišť, viz dále. 2. Autor této práce by rád odstranil slovo pravděpodobně a uvedl řádnou citaci. Bohužel neexistují studie, které by bylo možné citovat. Rozšířenost D C C se zakládá na autorových zkušenostech. 5 2. SOUČASNÉ NASAZENÍ SBĚRNICE M T B B U S pevně instalovány v rámech kolejiště a komunikují po sběrnici MTBbus s MTB-USB modulem. Říkáme, že sběrnice je tzv. single master, multiple slaves. MTB-USB modul lze označit jako master modul, M T B moduly jsou tzv. slavě moduly. Celou situaci přehledně ilustruje obrázek 2.1. PC Řídicí SW kolejiště Systém MTB MTB-USB MTBbus - RS485 Až 255 modulů 1 2 / CO MTB-TTL MTB-UNI MTB-UNI Periferie: přestavníky, návěstidla, přejezdy,... Obrázek 2.1: Topologie systému MTB. Současná sběrnice MTBbus je založena na elektrickém standardu RS485 [6]. Sběrnice RS485 je dvouvodičová (R+, R-, GND) vícebodová sériová poloduplexní komunikační průmyslová sběrnice vyvinutá s důrazem na odolnost vůči externímu rušení. Je vhodná pro přenos dat na větší vzdálenosti, řádově až stovky metrů [7]. Pro dosažení nejlepších elektrických vlastností by sběrnice měla být lineární. Sběrnice je na obou koncích terminována rezistorem 200 R a pull-up a pull-down rezistory pro držení definované úrovně signálu. RS485 je velice snadno implementovatelná do prakticky všech mikrokontrolérů - pro přístup ke sběrnici je třeba rozhraní UART, jeden pin pro řízení směru komunikace a driver k RS485. Po sběrnici se komunikuje pevně definovaným protokolem. Protokol definuje příkazy pro moduly, odpovědi modulů, časování apod. [6] Základní parametry MTBbus shrnuje tabulka 2.1. 6 2. SOUČASNÉ NASAZENÍ SBĚRNICE M T B B U S Tabulka 2.1: Základní parametry sběrnice MTBbus [6] Typ přenosu RS485, formát dat UART Komunikační rychlost 38400 Bd, 57600 Bd, 115200 Bd Maximální počet modulů 255 Počet datových bitů 9 Stop bit 1 Parita žádná Maximální délka vedení 100 m Zaměřme se nyní na MTB moduly. Každý MTB modul má: 1. 8bitovou adresu, která se konfiguruje jumpery přímo na modulu, 2. konfiguraci (typ vstupů/výstupů, rychlost sběrnice,...), 3. vstupy (stav vstupů), 4. výstupy (stav výstupů). MTB moduly mohou být různého typu: • MTB-UNI MTB-UNI (univerzální) je nejpoužívanější typ modulu. Obsahuje 16 digitálních vstupů a 16 digitálních výstupů. Na výstupech 0-7 umožňuje kódovat návěst protokolem S - C O M 3 , což umožňuje připojení až 8 návěstidel k jednomu MTB-UNI. Modul dále umožňuje připojení IR čidel na vstupy4 . Výstupy modulu jsou v režimu otevřeného kolektoru s maximální zátěží až 0.5 A / 8 výstupů.5 • MTB-UNIm MTB-UNIm modul je zjednodušením MTB-UNI modulu. Nemá podporu IR čidel, ale má výstupy v režimu otevřených kolektorů. Umožňuje připojení až 8 S-COM návěstidel. 3. S - C O M je jednoduchý jednosměrný komunikační protokol, který umožňuje přenášet návěsti návěstidel [1]. 4. IR čidla jsou bodová čidla detekující průjezd vlaku, viz 2.2. 5. Na modulu jsou osazeny 2 budiče výstupů, přičemž každý z budičů má celkový limit 0.5 A . 7 2. SOUČASNÉ NASAZENÍ SBĚRNICE M T B B U S MTB-TTL Obrázek 2.2: Ukázka modulu MTB-TTL [3]. MTB-TTL je zjednodušením modulu MTB-UNI. Oproti MTB-UNI nemá podporu IR čidel a výstupy má v režimu TTL. O d tohoto typu modulu se v současnosti ustupuje, neboť TTL výstupy nejsou vhodné pro spínání vyšších napětí6 , a proto, že v případě neaktivního výstupu (neaktivní = +5 V; inverzní logika) aktivně napájí výstupní port, což způsobuje nechtěné chování, například pokud je na výstupním portu záměrně vypnutá periferie. V krajním případě může dojít až k přetížení TTL výstupu a jeho zničení. N a výstupy všech nasazených moduly typu MTB-TTL byly postupně instalovány dodatečné budiče s otevřenými kolektory. MTB-REG MTB-REG je modul umožňující generovat analogový výkonový výstup. Modul se připojí ke kolejím a řídí rychlost a směr lokomotivy v řízeném úseku kolejí. Tento způsob řízení jízdy (tzv analogový) je dnes již překonaný. V současnosti se pro řízení jízdy lokomotiv na kolejišti používá tzv. systém Digital Command Control (viz 3.1), kde každá lokomotiva a mnohdy i vagón v sobě má mikroprocesor a celý systém je řízen digitálně [4]. 6. Např. pokud periferie na výstupu obsahuje pull-up do +12 V. 8 2. SOUČASNÉ NASAZENÍ SBĚRNICE M T B B U S Modul MTB-REG je tedy již překonaným modulem a autor jej uvádí především pro úplnost popisu systému MTB. • MTB-POT Modul MTB-POT obsahuje 4 analogové vstupy a 4 digitální vstupy. Jeho původním účelem bylo, aby se připojil k potenciometru v pultu obsluhy kolejiště, kterým obsluha reguluje jízdu vlaku. Po sběrnici přepošle data modulu MTB-REG a tím dojde ke kýžené jízdě vlaku. Tento způsob řízení kolejišť se již nepoužívá, proto i modul MTB-POT na moderních kolejištích pozbývá svého smyslu. Práce se sběrnicí z pohledu aplikace v počítači probíhá následovně: 1. Aplikace se připojí k MTB-USB modulu. 2. Aplikace provede sken aktivních modulů sběrnice. 3. Aplikace nahraje do všech aktivních modulů konfiguraci. 4. Aplikace přečte stav vstupů. 5. Aplikace zahájí provoz sběrnice - od této chvíle všechny moduly nahlašují změny stavů vstupů. 6. Aplikace čte vstupy, nastavuje výstupy a řídí provoz. 7. Aplikace ukončí provoz sběrnice a uvede výstupy MTB modulů do základního stavu. 8. Aplikace uzavře spojení s MTB-USB. 2.2 IR čidla Nyní popíšeme princip fungování IR čidel v kolejišti, protože bude v dalších kapitolách stěžejní. IR čidlo je bodový detektor průjezdu vlaku. Mezi kolejnice se vedle sebe umístí opticky oddělená vysílací dioda a fototranzistor, oba namířené vzhůru. Při průjezdu vlaku dojde k odrazu signálu od spodní části vozu nebo lokomotivy, čímž je detekován průjezd vlaku. Výhodou je nenápadná instalace mezi kolejové pražce, která neruší celkový dojem modelu. 9 2. SOUČASNÉ NASAZENÍ SBĚRNICE M T B B U S Pro spolehlivou detekci odrazu od matných černých povrchů podvozků je třeba budit vysílací diodu vysokým proudem (až 200 m A ) , což vyžaduje použití diody v impulsním režimu. Současná MTB-UNI deska podporuje IR čidla na všech svých 16 vstupech, diody jsou buzeny tranzistory ve skupinách po 4 diodách. Aby bylo zajištěno spolehlivé vyhodnocení odraženého signálu, je vstup z fototranzistoru zapojen na digitální vstup posuvného registru přes kapacitní vazbu (viz schéma 2.3). Kapacitní vazba odstraňuje stejnosměrnou složku signálu, která vzniká vlivem okolního osvětlení. vcc vcc 1 1 JI IR 1 lOk R2 lOOk J2 CPU Cl lOOn Obrázek 2.3: Zapojení vstupu kapacitní vazbou. Vstupy MTB-UNI desky se konfigurují osazením rezistorů (běžný vstup) nebo kondenzátoru (vstup z IR čidla). Režim pinu musí být uložený v procesoru, aby se adekvátním způsobem zpracovával vstupní signál [8]. 2.3 Systém MTB v kontextu řízení modelového kolejiště V K M Z Brno I je aktuálně systém M T B nasazen na dvou kolejištích, další nasazení je na modulovém kolejišti Mendelovy univerzity v Brně ( M E N D E L U ) , s kterou klub spolupracuje. N a těchto kolejištích je aktuálně nasazeno dohromady 99 MTB modulů. Pro kontext uveďme, jak systém M T B zapadá do celkové koncepce řízení kolejiště. Viz diagram 2.4. Na první pohled je vidět, že kolejiště je řízeno dvěma různými systémy: systémem pro řízení příslušenství (modrá část diagramu) a systémem 10 2. SOUČASNÉ NASAZENÍ SBĚRNICE M T B B U S Interakce s uživatelem Panel Panel Mobilní ovladač Počítačový ovladač Staniční hlášení Debug rozhraní ethernet / WiFi PC Řídicí SW kolejiště <—• USB USB Řízení jízdy Řízení příslušenství MTB-USB DCC f f Zesilovač Zesilovač Zesilovač MTBbus - RS485 koleje Až 255 modulů i ir 2 MTB-TTL MTB-UNI MTB-UNI Periferie: přestavníky, návěstidla, přejezdy, ... koleje koleje Obrázek 2.4: Diagram komponent řízení kolejišť K M Ž Brno I. pro řízení jízdy (fialová část diagramu). Vyvstává otázka, proč je nesloučit do systému jednoho. Integrovaná řešení nabízejí majoritní výrobci hardwaru pro digitální řízení modelové železnice. Řízení jízdy i příslušenství jedním systémem (DCC) je rozšířeným řešením jak v Česku tak v zahraničí. Všechna tato řešení jsou však o kompromisech, jak se dozvíme v 3.1. U tvorby a nasazení systému M T B stály osoby, které pracují na zabezpečení skutečné železnice. Systém M T B je tak oproti komerčně dostupným řešením řízení modelových kolejišť navrhován s důrazem na spolehlivost a především bezpečnost. Uveďme dva příklady za všechny: komerčně využívaná sběrnice RS pro snímání stavu kolejiště nedokáže rozpoznat, že nějaký z RS modulů (analogie M T B modulů) přestal pracovat [9]. Dále výstupní U 2. SOUČASNÉ NASAZENÍ SBĚRNICE M T B B U S moduly nijak nepotvrzují, že opravdu provedly akci, kterou počítač požaduje [10]. Tyto příklady ilustrují, že komerčně dostupná řešení jsou podle autorova názoru blíže hračce, než bezpečnému a spolehlivému systému pro řízení modelů. Poslední část diagramu 2.4 je část zelená, která reprezentuje interakci s uživatelem. Řídicí SW kolejiště běží na samostatném serveru, ke kterému se připojují všichni uživatelé systému - dispečeři ze svých stanic, strojvedoucí ze svých ovladačů, ale také třeba technikové se svými diagnostickými nástroji nebo externí programy využívající API serveru. Server kontroluje identitu uživatelů a umožňuje jim řídit ty systémy, ke kterým mají uživatelé práva. 2.4 Proč současný systém MTB nedostačuje Systém MTB s sebou nese řadu problémů. 1. Licence, výrobní data U současné implementace systému MTB bohužel nebyly řádně vyřešeny licenční podmínky mezi jeho autorem a Klubem. Souhrou událostí se K M Z Brno I dostal do situace, kdy nemá zdrojová data schémat a layoutů desek plošných spojů ani zdrojové kódy firmwarů. Aktuální situace tak prakticky znemožňuje výrobu dalších MTB desek, o záměru chtít systém M T B nabízet mimo klub ani nemůže být řeč. 2. Hardware Systém M T B zaznamenal poslední aktualizaci hardwarových komponent v roce 2007. V současné době jsou některé použité součástky bohužel nedostupné, což znemožňuje výstavbu dalších částí kolejiště. To je zcela zásadní problém. 3. Software Současné M T B moduly využívají procesory AT89C2051 (2 kB FLASH, 128 B SRAM). Tyto procesory svými parametry odpovídají době návrhu celého systému. Firmware v procesorech naráží 12 2. SOUČASNÉ NASAZENÍ SBĚRNICE M T B B U S na jejich hardwarové limity - paměť je plná, takže nelze přidávat nové funkce. Procesorům navíc chybí některé klíčové periferie, například EEPROM paměť. Současný systém MTB byl vyhodnocen jako celkově nedostatečný, je potřeba ho buď aktualizovat nebo nahradit systémem jiným. 2.4.1 Všeobecné požadavky na nový systém MTB Na náhradu systému MTB autor práce stanovil především následující požadavky. 1. Systém musí být kompatibilní se současným řídicím softwarem kolejiště. 2. Systém musí být kompatibilní se současným hardwarem kolejiště. 3. Systém musí být udržitelný minimálně 20 let. 4. Finanční náklady a čas vložený do povýšení současného systému na nový systém by měly být minimalizovány. 5. Systém musí být schopen potvrzovat akce řídicího počítače a evidovat správnou funkčnost modulů. 6. Systém by měl být rozšiřitelný co se týče podporované funkcionality - nové požadavky by mělo být možné implementovat. K naplnění těchto požadavků lze přistoupit dvěma různými způsoby: zakoupením komerčního produktu nebo vytvořením produktu vlastního. Prozkoumejme nejprve, jestli existují komerční řešení, která naplňují definované požadavky. 13 3 Existující řešení Nyní představíme v současnosti nejrozšířenější standardy pro digitální řízení modelové železnice. Prozkoumáme zařízení, která tyto standardy podporují, a zhodnotíme jejich vlastnosti. Bude vyhodnoceno, jestli zařízení naplňují požadavky definované v předchozí kapitole. 3.1 Digital Command Control Digital Command control (DCC) je celosvětově nejrozšířenější standard pro digitální1 řízení modelové železnice [11]. K DCC existují alternativy, které však v Evropě nejsou rozšířené, proto je nebudeme uvažo­ vat.2 DCC specifikuje, které komponenty se účastní řízení kolejiště a jak se tyto komponenty mají chovat - od elektrických standardů (např. doporučený způsob zapojení vodičů pod kolejištěm) až po komunikační protokoly. D C C je otevřený standard vytvořený organizací National Model Railroad Association (NMRA), která sdružuje modelářské kluby (a tedy i modeláře), jež jsou přímými uživateli DCC. Standard DCC je tedy navržen modeláři k naplnění potřeb modelářů. Jednotlivé prvky systému DCC jsou znázorněny v 3.1. Nyní tyto prvky stručně popíšeme. Základní komponentou celého systému je DCC centrála (Command Station), která má 3 hlavní úkoly. 1. Číst stav modulů zpětného hlášení přes sběrnici zpětného hlášení (feedback bus). 2. Povelovat dekodéry (lokomotiv, přestavníků, návěstidel apod.). 3. Obousměrně komunikovat po sběrnici ovladačů (throttle bus). Řízení dekodérů centrála provádí generováním DCC signálu (červený a modrý vodič ve schématu 3.1), do kterého centrála kóduje operace 1. Digitální znamená, že mezi jednotlivými prvky řízení proudí digitální data. 2. Toto tvrzení se zakládá na autorových zkušenostech, relevantní studie neexistují. 14 3- EXISTUJÍCÍ ŘEŠENÍ Obrázek 3.1: Schéma systému DCC. Převzato a upraveno z [12]. 15 3- EXISTUJÍCÍ ŘEŠENÍ požadované po dekodérech - např. „dekodére číslo 541, zastav lokomotivu", „dekodére číslo 4741, aktivuj čelní světla". Ke sběrnici ovladačů jsou připojené buď fyzické ovladače, nebo počítače. Operátor provozu zadává příkazy, například otočením kolečka ovladače nebo interakcí s příslušným softwarem, tyto příkazy jsou přeposlány do centrály, centrála je dále přeposílá dekodérům, které přímo vykonávají požadované akce. Na sběrnici zpětného hlášení jsou připojeny moduly s digitálními vstupy, které jsou namontovány pevně v kolejišti a které čtou stav periferií. Centrála informuje uživatele skrze sběrnici ovladačů o změnách ve stavech vstupů modulů zpětného hlášení. Vstupy modulů zpětného hlášení jsou připojené například k signalizacím obsazení kolejových obvodů, takže uživatel nebo řídicí SW pozná, že se na koleji nachází nebo nenachází vlak, dále například ke koncovým spínačům poloh výhybek, takže řídicí software je schopen zabezpečit vlakovou cestu. V KMŽ Brno I se používají následující výstupy a vstupy. Výstupy: • řízení jízdy lokomotiv, • řízení osvětlení lokomotiv a vozů, • řízení zvuků lokomotiv, • nastavení poloh výhybek, výkolejek, • rozpojovace, • návěstidla, • přejezdy, • statické pouliční nebo domovní osvětlení, • indikace v pultu obsluhy. Vstupy: • indikace obsazení kolejových obvodů, • indikace bodového průjezdu vlaku daným místem skrze IR čidla (viz 2.2), • indikace koncových poloh výhybek, výkolejek, • indikace stavů přejezdů, • tlačítka v pultu obsluhy. 16 3- EXISTUJÍCÍ ŘEŠENÍ Všimněme si klíčové vlastnosti systému: pro řízení dekodérů a pro sběr informací z kolejiště jsou použity 2 různé sběrnice: dcc signál a sběrnice zpětného hlášení. Platí totiž, že signál DCC je pouze jednosměrný. Signál putuje z DCC centrály přes zesilovače a přes koleje do lokomotiv, vozů a statických dekodérů, které poveluje. Existují jen velice omezené prostředky k poslání dat z lokomotivy zpět do D C C centrály3 . Tyto prostředky navíc vznikly až v pozdějších verzích normy DCC, takže dnes nejsou všeobecně zaužívané [13]. Sběrnice DCC je tedy prakticky vzato jednosměrná - bez odpovědí dekodérů na příkazy. To znamená, že centrála musí D C C příkazy posílat opakovaně, aby zaručila, že je dekodér skutečně přijme. Může se totiž snadno stát, že lokomotiva zrovna není schopna přijímat signál - například se pohybuje po znečištěných kolejích. Problém s přijímáním dat vlivem špatného kontaktu se netýká dekodérů příslušenství (na obrázku 3.1 switch decoder a semaphore decoder). Tyto dekodéry jsou připojeny pevným kabelem ke kolejím nebo přímo k centrále, takže mají nejlepší předpoklady dekódovat DCC signál korektně. Stále však platí, že dekodér neodpoví, že přijal a provedl povel. Vykonání povelu mohlo být narušeno čímkoliv od elektromagnetického rušení signálu až po nepřijetí povelu vlivem chyby ve firmwaru dekodéru. Může se zdát, že samotný protokol D C C nesplňuje požadavky popsané v 2.4.1 a proto jej nemá smysl uvažovat jako nástupce současného systému MTB. Ačkoliv striktně vzato je tento závěr správný, je nutné si uvědomit širší souvislosti. Při řízení provozu na modelovém kolejišti sledujeme mnohé cíle, z nichž na prvním místě stojí bezpečnost. Na skutečné železnici je bezpečnost samozřejmě mnohem důležitější než na železnici modelové. Přesto například materiální škody vzniklé projetím návěsti zakazující jízdu, vykolejením soupravy, srážky nebo následného pádu modelu na zem jsou tak markantní, že je třeba bezpečnost provozu řešit. Bezpečnost řízení provozu železnice skutečné i modelové stojí na tom, že vlak nevjede do míst, kde by mu hrozila nehoda. K nehodě může dojít dvěma způsoby. 3. Takovému systému říkáme RailCom [13]. 17 3- EXISTUJÍCÍ ŘEŠENÍ 1. Vlak stojí a je nesprávně rozjet do nebezpečného místa. I přes to, že dekodéry (příslušenství) nepotvrzují přijetí signálu a provedení akce, této situace se jsme schopni vyvarovat. Všechny klíčové komponenty kolejiště, které řídí směr pohybu vlaku (výhybky, výkolejky) indikují svůj stav. To znamená, že když se nepovede provést například přestavení výhybky vlivem nedoručení příslušného DCC paketu, výhybka se nepřestaví, moduly zpětného hlášení správně indikují, že výhybka se nehýbe, řídicí software správně vyhodnotí, že nedošlo ke splnění podmínek pro rozjetí vlaku a vlak nerozjede. Z tohoto pohledu tedy nepotvrzování DCC příkazů nevede k nebezpečné situaci. Jiná situace nastane u dekodérů, které provádějí akce, aniž by indikovaly svůj stav. Takové dekodéry jsou například dekodéry návěstidel (semaphore decoder na obrázku 3.1). Tyto dekodéry však neovlivňují směr jízdy vlaku. Spatná návěst na návěstidle je nemodelová, ale ke hmotným ztrátám nedojde. 4 2. Vlak se nepovede zastavit. Může nastat situace, kdy se vlak blíží k místu zastavení, řídicí software mu správně pošle příkaz k zastavení, ale lokomotiva přesto nezastaví. Například vlivem již popsaného špatného kontaktu lokomotivy s kolejemi a tudíž neschopnosti řádně dekódovat DCC signál. Norma DCC totiž specifikuje „pokud dekodér nedekóduje signál, zůstává ve stejném stavu". Tedy například lokomotiva se pořád pohybuje vpřed. Ačkoliv popsaná situace v praxi nastává, není v záběru této práce s ní naložit. Tato práce se zaměřuje především na řízení příslušenství a snímání stavu kolejiště, nikoliv na systém řízení jízdy hnacích vozidel. 4. Jiná situace panuje na skutečné železnici, kde je návěst návěstidla důležitým komunikačním prvkem mezi dispečerem a strojvedoucím. Je nutné, aby strojvedoucí viděl správnou návěst, protože nesprávná návěst by mu mohla povolit jízdu, přestože se například proti němu blíží vlak. Nebo by například mohla povolit jízdu vyšší rychlostí, než jaká je v daném úseku předepsaná, a vlak by později nemusel stihnout zabrzdit. Proto se na skutečné železnici kontroluje, že světly návěstidel, která mají být rozsvícená, skutečně prochází proud. 18 3- EXISTUJÍCÍ ŘEŠENÍ Závěrem uveďme, že z dosavadního popisu systému D C C plyne, že tento systém je pro řízení příslušenství vhodný, i když s drobnými výhradami. 3.1.1 Sběrnice zpětného hlášení V předchozí kapitole jsme při formulování závěrů vycházeli z předpokladu, že jsme schopni bezpečně indikovat stav všech prvků v kolejišti (pomocí sběrnice zpětného hlášení -feedback bus ve schématu 3.1). Prozkoumejme spolehlivost této sběrnice. N M R A nedefinuje jednotný standard pro sběrnici zpětného hlášení [10], různí výrobci používají různé (vlastní) sběrnice [14]. Analyzujme tedy nejpoužívanější sběrnice. S88 S88 je základní sběrnice zpětného hlášení. Její fungování lze v zásadě charakterizovat jako „vylepšené posuvné registry" [15]. Jednotlivé moduly jsou řazeny za sebe, propojují se vždy sousední moduly. První modul je připojen do DCC centrály. periferie periferie periferie S88 modul < > S88 modul < > S88 modul < > DCC centrála Obrázek 3.2: Topologie sběrnice S88. S88 je nízkonákladová sběrnice určená pro malá kolejiště. Limitujícím faktorem je především napájení z 5 V, které není vhodné na delší rozvody, a malá odolnost proti rušení [15]. Jak je patrné z topologie sběrnice na obrázku 3.2, při výpadku (napájení) jednoho modulu jsou ztracena data i ze všech dalších modulů dále od centrály. Takové chování je pro profesionální P L C systém nevhodné. 19 3- EXISTUJÍCÍ ŘEŠENÍ RSbus RSbus je sběrnice firmy Lenz Elektronik. Oproti S88 je organizována do topologie sběrnice (viz obr. 3.3). Jednotlivé moduly jsou napájeny samostatně, sběrnice je dimenzovaná až na 128 modulů, každý s 8 digitálními vstupy [9] [16]. 1 periferie periferie >n n n n n f periferie i n n n n n n r i* \ RS modul RS modul RS modul DCC centrála Obrázek 3.3: Topologie sběrnice RSbus. Komunikaci po sběrnici řídí DCC centrála - posílá výzvy jednotlivým modulům a moduly odpovídají, pokud mají nějaká data k odeslání. Moduly odesílají data jen pokud došlo ke změně vstupů, což znamená, že nelze odlišit nefunkční modul od funkčního modulu se setrvalým stavem vstupů [16]. Takové chování bohužel nesplňuje požadavky definované v 2.4.1. Pokud by například došlo výpadku RS modulu a následnému obsazení kolejového obvodu, jehož stav tento modul indikuje, z pohledu řídicího softwaru by byl kolejový obvod stále volný. Řídicí software by pak povolil vjezd vlaku na obsazenou kolej, čímž by způsobil srážku. K výpadku RS modulu může dojít snadno například ztrátou napájení vlivem chybné obsluhy, reakce pojistky na přetížení, poruchy apod. LocoNET Poslední z analyzovaných sběrnic je LocoNET. LocoNET je proprietami sběrnice společnosti Digitrax [17], jejíž plná specifikace není volně dostupná [18]. Plné použití této sběrnice podléhá licenčním poplatkům [18]. Zajímavou vlastností sběrnice je, že slučuje sběrnice throttle bus afeedback bus (viz schéma 3.1). Řídicí software v počítači tak může 20 3- EXISTUJÍCÍ ŘEŠENÍ přímo dotazovat moduly zpětného hlášení a úplně tak obejít D C C centrálu. Sběrnice LocoNET je navíc obousměrná, LocoNET moduly jsou vstupně-výstupní, takže počítač může přímo povelovat periferie [17], viz 3.4. periferie j>n n ff11 M periferie periferie ítt• \ LocoNET LocoNET LocoNET modul modul modul Počítač DCC centrála Obrázek 3.4: Topologie sběrnice LocoNET. Sběrnice LocoNET umožňuje počítači zjišťovat stav modulů přímou komunikací bez zapojení centrály [19], takže počítač může rozpoznat, které moduly jsou na sběrnici přítomny, výpadek modulu a oživení modulu po výpadku. Sběrnice LocoNET splňuje požadavky na bezpečné řízení periferií definované v 2.4.1. Při bližší inspekci však zjišťujeme, že nasazení této sběrnice by znamenalo nakoupit a vyměnit cca 100 modulů v kolejišti. Výměna by navíc musela být rozsáhlejší, LocoNET moduly přímo nepodporují například generování signálu S-COM. Pro nasazení sběrnice LocoNET by musely být instalovány přídavné moduly pro řízení návěstidel. 21 3- EXISTUJÍCÍ ŘEŠENÍ 3.2 BiDiB Zajímavou alternativou k systému DCC je sběrnice BiDiB 5 (BiDirectional Bus). BiDiB je komunitní sběrnice s otevřeným protokolem, která do velké míry splňuje všechny požadavky definované v 2.4.1. Systém BiDiB lze provozovat na více komunikačních médiích (RS485, Ethernet, sériový port), návrh systému je podobný návrhu USB - na sběrnici je jeden master, až 32 slavě v každém segmentu, přičemž jedním ze slavě může být hub vedoucí do dalšího segmentu. Autoři BiDiB si dali za cíl, podobně jako autor této práce, vytvořit bezpečný systém pro řízení modelových kolejišť. Systém tak podporuje potvrzování příkazů, aktualizaci firmwaru modulů apod. Pro nasazení BiDiB by bylo třeba provést netriviální úpravy aktuálních modulů kolejiště - BiDiB například definuje standardní konektory pro propojení modulů. Dále by bylo třeba vyřešit, jak naložit s limitem 32 desek v jednom segmentu sběrnice (protože MTBbus je navržen až pro 255 modulů) a s jiným způsobem adresování modulů sběrnice. 3.3 Závěr V této kapitole byly popsány základní přístupy k řízení moderní digitální modelové železnice. Bylo zkoumáno, jestli komerční produkty splní požadavky definované v 2.4.1. Po vyloučení technicky nezpůsobilých řešení zbyly sběrnice LocoNET (s poznámkou, že její nasazení by bylo finančně náročné a pracné) a BiDiB. Při uvažování sběrnice LocoNET vyvstal problém s integrací ovládání návěstidel. Tento problém je obecnějšího rázu - jakékoliv komerční řešení není schopné nabídnout takovou flexibilitu, jakou K M Z Brno I potřebuje. Je nutné integrovat systém řízení kolejiště se současnými periferiemi, ale i s periferiemi budoucími. Je chtěné mít možnost pružně reagovat na nové periferie, které se objeví například za 10 let. 5. h t t p : / / b i d i b . o r g / 22 3- EXISTUJÍCÍ ŘEŠENÍ Uvažme také aspekt zpětné kompatibility - vlastní systém umožní co možná nejrozumněji zachovat kompatibilitu se stávajícím systémem řízení kolejiště a minimalizovat tak finanční náklady a čas nutný pro aktualizaci systému. Nutnost rozumné zpětné kompatibility tak fakticky vylučuje i nasazení BiDiB. Vnímejme tuto kapitolu tedy především jako přehled technologií, které se pro řízení současné digitální modelové železnice používají. Přistupme k návrhu nástupce současného systému M T B výrobou vlastních komponent. 23 4 Návrh MTB v4 V této kapitole představíme návrh vlastního PLC systému, který splňuje požadavky definované v 2.4.1. Návrh systému vychází z přirozeného požadavku na minimální změny v aktuálním hardwaru a softwaru kolejiště. Nový systém je navržen jako iterace současného systému MTB; jmenuje se MTB v4. MTB v4 řeší všechny problémy aktuálního systému M T B popsané v kapitole 2.4. Při návrhu byly vzaty v potaz aktuální technologie v oblasti PLC obvodů, přičemž byla zvážena vhodnost jejich implementace do systému MTB v4. Tyto úvahy popíšeme. Detailně rozebereme současnou implementaci protokolu MTBbus a u každé položky budeme argumentovat, jestli ji zachovat. 4.1 Podrobná specifikace požadavků Pro návrh systému M T B v4 je třeba formulovat přesnější specifikaci požadavků, než jsou požadavky definované v 2.4.1. Nyní tyto přesné požadavky formulujeme, přičemž budeme klást důraz na vysvětlení změn oproti současnému systému MTB. Zaměřme se nejprve na požadavky, které na systém M T B kladou komponenty, které jej užívají. 4.1.1 Periferie v kolej išti K M T B se na straně kolejiště připojují jednotlivé periferie popsané v 3.1. Všechny v současnosti na kolejišti používané vstupy jsou digitálního charakteru (binární vstupy), výstupy jsou buď digitální binární nebo S-COM. S-COM výstupy jsou ve skutečnosti digitální výstupy, do kterých M T B modul moduluje S-COM signál. S-COM signál je záměrně jednoduchý, pomalý signál, který lze s přehledem vytvářet běžným výstupním pinem procesoru nebo posuvného registru [1]. 24 4- NÁVRH MTB v4 Oproti současnému MTB by nové MTB mělo podporovat tzv. kmitavý výstup s počítačově definovanou frekvencí kmitání a pevnou střídou. Frekvence kmitání postačí v řádu jednotek Hz. Kmitavý výstup se využije pro indikace v pultech a k ovládání rozpojovačů1 .1 kmitavý výstup je však z pohledu návrhu hardwaru jednoduchý digitální výstup pro přidání kmitavého výstupu stačí upravit komunikační protokol MTBbus, software v počítači a firmware modulů. Současné moduly MTB-UNI umožňují výstupy typu S-COM pouze na pinech 0-7, což je omezení dané malou pamětí procesoru současných MTB-UNI modulů. Toto omezení by mělo MTB v4 relaxovat a umožnit tak, aby každý výstup mohl být v jednom z režimů 1. digitální, 2. S-COM, 3. kmitavý. Co se týče vstupně-výstupních požadavků periferií kolejiště, MTB v4 by si vystačilo pouze s moduly typu MTB-UNI. N a kolejištích K M Z Brno I v současnosti není žádný prvek, který by vyžadoval například analogový vstup, analogový výstup nebo PWM výstup. Na kolejištích se sice hojně používají servomotory, ale vždy pro řízení dvoupolohových prvků: výhybka, výkolejka, mechanické návěstidlo. Všechny tyto prvky k sobě mají řídicí elektroniku, která interaguje se systémem MTB pouze digitálními piny. Typicky stačí na každý takový prvek 2 digitální výstupy MTB-UNI modulu (pro nastavení požadované polohy) a případně 2 digitální vstupy (pro detekci koncové polohy). Zmiňme na tomto místě, že rozhodnutí neimplementovat P W M výstupy do MTB-UNI v4 modulu je do velké míry koncepčním rozhodnutím autora této práce. Autor preferuje distribuovaný přístup, kdy „jedna komponenta dělá jednu věc a dělá ji dobře". Redukuje se tak počet různých variant modulů, čímž se zjednodušuje sériová výroba. Autor se rozhodl vydat cestou univerzálního kompaktního snadno sériově vyrobitelného modulu s prostými digitálními vstupy a výstupy. 1. Rozpojovač je mechanické zařízení pevně spojené s kolejištěm, jehož účelem je rozpojit modelové spřáhlo bez ručního zásahu obsluhy do kolejiště. 25 4- NÁVRH MTB v4 Připomeňme, že MTB-UNI moduly umožňují speciální typ vstupů - IR vstupy (viz 2.2). Tyto vstupy vyžadují další elektroniku navíc. V nových MTB-UNI v4 je přímá podpora pro IR čidla zrušena. Bude navržen samostatný přídavný modul pro buzení a vyhodnocování stavu IR čidel, který se bude připojovat přímo k digitálním vstupům MTB-UNI modulu. Ušetří se tak elektronika na MTB-UNI modulech, na kterých se IR vstupy nevyužívají, zjednoduší se návrh desky plošných spojů MTB-UNI v4 a umožní se využít IR čidla i s jinými moduly, než MTB (např. pro přímou indikaci v pultech). V novém systému M T B tedy budou stačit pouze moduly typu MTBUNI, z nichž bude navíc odstraněna přímá podpora IR čidel. I přes to by bylo neperspektivní si podporu jiných typů modulů zavřít volbou nevhodného komunikačního protokolu modulů. Nový protokol sběrnice MTBbus by měl být navržený univerzálně pro nejrůznější možné typy desek, které v budoucnu mohou přijít. Autor této práce má již v záměru takové desky desky vytvořit, viz 6.1. 4.1.2 Ovládání Systém MTB interaguje s periferiemi v kolejišti a s řídicím softwarem (viz 2.1). Na kolejištích K M Z Brno I se v současné době využívá řídicí software hJOP2 . Tento software běží na operačním systému Windows a s hardwarem kolejiště komunikuje pomocí dynamicky linkované knihovny, která musí dodržet specifikované API [20]. Na straně řídicího softwaru jsou tedy pro návrh M T B v4 takřka neomezené mož­ nosti. Princip řízení kolejiště počítačem však definuje zásadní požadavek na organizaci sběrnice MTBbus v4: jednotlivé prvky jsou řízeny počítačem a výhradně počítačem. Novým požadavkem je, aby v počítači mohlo existovat více programů, které sběrnici řídí. V praxi totiž nastává situace, kdy jsou na jednu sběrnici připojené systémy, které mají být z principu řízeny různými programy: například řízení provozu vlaků a řízení pouličního a domovního osvětlení. Je praktické mít oba systémy zapojené do jedné 2. h t t p s : / / h j o p . k m z - b r n o . c z / 26 4- N Á V R H M T B v4 sběrnice (aby se minimalizoval počet MTB modulů). Dává však také smysl, aby software pro řízení provozu železnice neřídil osvětlení, protože to není jeho účel. Dalším příkladem z K M Z Brno I je jedna sběrnice, na které jsou připojeny periferie řízení tramvajové dopravy zároveň s periferiemi řízení silniční dopravy. Přestože oba systémy sdílí společnou sběrnici, na úrovni počítače by tyto systémy měly řídit dva různé programy. Jednou z hlavních přidaných hodnot MTB v4 je, že umožní popsané multi-master řízení. 4.1.3 Další požadavky Uveďme nyní některé méně důležité požadavky na M T B v4, jejichž naplnění nám však výrazně zpříjemní používání systému. Již teď předejměme, že všechny tyto požadavky se v implementaci podařilo naplnit. 1. Bude možné nalézt MTB moduly i po startu sběrnice. V kapitole 2.1 byl popsán striktní proces používání sběrnice - od vyhledání modulů až po ukončení práce se sběrnicí. Současná implementace tohoto procesu neumožňuje, aby počítač detekoval moduly, které na sběrnici přibudou za jejího chodu. Taková situace může nastat, například když je prvně zapnut řídicí počítač a až pak napájení sběrnice. Je nepříjemné muset v takovém případě manuálně spouštět proces skenování MTB modulů znovu. Obecně se celý postup práce se sběrnicí popsaný v kapitole 2.1 zdá být zbytečně striktním. MTB v4 by mělo tento proces zjednodušit. 2. Z počítače bude možné na každém modulu zapnout identifikační LED. Pro snadnou identifikaci konkrétního modulu v kolejišti, například při diagnostice závady, by operátor měl mít možnost z počítače na libovolném modulu zapnout indikační LED. 27 4- NÁVRH M T B v4 3. Firmware MTB modulů by mělo být možné aktualizovat přímo po sběrnici MTBbus. V kolejištích K M Z Brno I je aktuálně nasazeno 99 MTB modulů. Aktualizace jejich firmwaru ručním programováním by byla časově náročná. MTB v4 by mělo umožňovat aktualizaci firmwaru přímo po MTBbus, nejlépe za současného plného chodu zbytku modulů. 4.1.4 Shrnutí požadavků Shrňme stručně všechny požadavky na systém MTB v4. 1. MTB-UNI budou nově podporovat kmitavé výstupy. 2. MTB-UNI budou nově podporovat S-COM výstupy na všech výstupních pinech. 3. Systém M T B v4 musí být navržený univerzálně pro nejrůznější typy modulů. Jedinou společnou vlastností modulů je, že snímají vstupy a nastavují výstupy. 4. Je třeba vyřešit zpětnou kompatibilitu se stávajícími MTB moduly v kolejišti. 5. K M T B v4 se musí na straně počítače dát přistoupit skrze hJOP RCSAPI3 . 6. V počítači může běžet více softwarů řídících výstupy a snímajících vstupy modulů sběrnice MTBbus v4. 7. Moduly sběrnice MTBbus v4 by mělo být možné průběžně vyhledávat a detekovat nefunkční. 8. Z počítače bude možné na každém MTB modulu zapnout identifikační LED. 9. Firmware modulů bude možné aktualizovat přímo po MTBbus. 10. Implementace MTB v4 by měla využívat osvědčené komponenty, u nichž je dlouhodobý výhled dostupnosti. 11. MTB moduly potvrzují příkazy, lze monitorovat jejich správnou funkčnost. 12. Celé řešení by mělo být psáno opensource a openhardware. 3. h t t p s : / / h j o p . k m z - b r n o . c z / r c s 28 4- N Á V R H MTB v4 4.2 Návrh systému MTB v4 Nyní vyjdeme z detailních požadavků definovaných v předchozí kapitole a provedeme návrh nového systému pro sběr dat a ovládání periferií kolejiště. Detailně zdůvodníme každý aspekt nově navrženého systému. 4.2.1 Vysokoúrovňový návrh Základní koncept fungování systému M T B „single master, multiple slaves" zůstane zachován. Bude vytvořena nová verze řídícího modulu MTB-USB, který se stane řídicím prvkem nové sběrnice MTBbus v4. Model single master, multiple slaves je osvědčeným modelem, který se snadno implementuje, jednoduše se v něm počítají nejlepší a nejhorší časy odezvy sběrnice a obecně se dobře mapuje na problém, který systém MTB řeší. Proto jej autor zachová. Vytvořením nové verze MTB-USB autor sleduje především naplnění cíle existence svobodné implementace systému MTB. Nová deska umožní využití moderních procesorů a integrovaných obvodů, které usnadní implementaci. MTB-USB deska může být vytvořena jako úplně nová (bez nutnosti zpětné kompatibility se současným MTBUSB), protože je pouze jedna pro celé kolejiště a tedy je její výměna levná a snadná. Bude navržen nový MTB-UNI modul, který splní všechny požadavky definované výše a který bude založen na moderních, ale dlouhodobě dostupných součástkách. Nebude však nutné vyměnit všechny stávající MTB-UNI moduly v kolejišti. Stávajícím modulům se vymění pouze procesor, starým modulům tudíž bude umožněno fungovat na nové sběrnici. Autor navrhne a popíše IR desku, která si využije při zapojení IR čidel k novému modulu MTB-UNI v4. Zachování většiny stávajícího hardwaru současných MTB-UNI modulů a snaha o zachování kabeláže sběrnice s sebou nesou ponechání 29 4- NÁVRH MTB v4 sběrnice MTBbus na standardu RS485. RS485 nepřináší žádné zjevné nevýhody, takže není důvod ke změně hardwarové vrstvy sběrnice. Nové procesory umožní trvalé uložení konfigurace v MTB modulech. Přesto bude autoritativním zdrojem konfigurace modulů i nadále počítač: po nalezení modulu na sběrnici jej počítač zkonfiguruje dle konfiguračního souboru programu. Tento přístup autor zvolil, aby bylo možné konfiguraci všech modulů kolejiště centralizovane ukládat a verzovat.4 MTB moduly budou skrze MTB-USB komunikovat s počítačem po portu USB, kterým se tuneluje USB CDC protokol. V počítači tak bude MTB-USB modul dostupný jako sériový port. Počítač nemůže komunikovat po sběrnici RS485 přímo, protože není vybaven potřebnými hardwarovými periferiemi. Proto bude komunikovat s modulem MTBUSB, který řeší časově kritické operace sběrnice MTBbus5 . Otázkou zůstává, kde naplnit požadavek na multi-master řízení celého systému. Existují 2 možné přístupy: 1. MTB-USB se bude k počítači připojovat rozhraním, které nativně umožňuje komunikaci pouze s jednou aplikací (napříkld USB), řízení více programy se vyřeší na úrovni softwaru v počítači. 2. MTB-USB se připojí k počítači rozhraním, které přirozeně podporuje více připojených zařízení, například ethernet. Oba přístupy se v komerčních systémech pro digitální řízení modelové železnice běžně používají6 . Ať bude podpora více řídicích systému implementována kdekoliv, oproti jednomu řídicímu systému vyžaduje tato podpora netriviální softwarovou logiku navíc. Autor práce se rozhodl přesunout co nejvíce složitější logiky do počítačových aplikací, protože ty se mnohem snáze vyvíjejí, ladí a aktualizují než firmware v embedded procesorech. V počítači je navíc možné využívat vysokoúrovňovější nástroje. Proto se autor vydal cestou, kdy se MTB-USB 4. Uložení konfigurace v modulech i tak má smysl - například aby modul mohl aplikovat uložený základní stav výstupů ihned po zapnutí napájení a nemusel čekat na řídicí SW v počítači. 5. Například kontrola odpovědi modulu v časovém limitu cca 250 us. 6. Viz např. rozhraní Lenz LI-USB-Ethernet, centrála Digikeijs DR5000 aj. 30 4- NÁVRH M T B v4 připojuje k počítači pomocí virtuálního sériového portu, který umožňuje připojení jen jedné počítačové aplikace. V počítači vznikne nová aplikace MTB Daemon, která se na jedné straně připojí k MTB-USB a na straně druhé vystaví JSON TCP server s jednoduchým API, které umožní povelovat M T B moduly z více počítačových programů. Získá se tím mj. přehledné programové API, které umožní snadné připojení z nejrůznějších programovacích jazyků. Tím se systém MTB zpřístupní širšímu spektru programátorů. Třída CDC mezi počítačem a MTB-USB byla zvolena proto, že se jedná de facto o standard pro připojení specifických periferií k počítači, například v oblasti robotiky. Využijeme toho, že protokol C D C má nativní podporu ovladačů v majoritních operačních systémech a není tak nutné instalovat speciální ovladače. Tento aspekt umožní snadné nasazení dalším uživatelům. 4.2.2 MTBbus Nyní podrobně rozebereme návrh nové sběrnice MTBbus v4. Autorem vytvořená plnohodnotná dokumentace nové sběrnice je k dispozici online7 . Podrobné požadavky definované v 4.1.4 vynucují razantní úpravy komunikačního protokolu sběrnice8 . Autor této práce se rozhodl sběrnici navrhnout od základů znovu. Sleduje tím především zajištění přehlednosti komunikačního protokolu a také vyřešení potíží s licencováním původního protokolu. 7. https://github.com/kmzbrnol/mtbbus-protocol 8. Například umožnit odesílat delší zprávy (kvůli aktualizaci FW M T B modulů), navrhnout protokol univerzálně pro libovolné typy modulů apod. 31 4- NÁVRH M T B v4 Hardware Jak již bylo zmíněno výše, po hardwarové stránce je zachován standard RS485. Počet komunikačních bitů je ponechán na 99 . Devátý bit ve zprávách z MTB-USB do M T B modulu indikuje, že se jedná o první byte zprávy. Ostatní byty zprávy mají tento bit nastavený na 0. Devítibitová komunikace je použita s cílem zavést na sběrnici klíčový pojem zpráva. Díky devátému bitu M T B modul dokáže poznat, kde zpráva začíná. Počet stop bitů je ponechán standardně na jednom bitu, kontrola konzistence dat paritou není použita. Současná sběrnice MTBbus podporuje různé rychlosti - 38400 Bd, 57600 Bd a 115200 Bd. Komunikace vždy začíná na 38400 Bd, jedna z prvních zpráv je příkaz na změnu rychlosti. Při výpadku a opětovném oživení musí modul postupně vyzkoušet všechny 3 rychlosti a sledovat, kdy přijímá korektní data [6]. Možnost volby rychlosti by autor chtěl ponechat - některá kolejiště se spletitým zapojením sběrnice, dlouhou sběrnicí nebo sběrnicí se špatnými elektrickými vlastnostmi mohou vyžadovat nižší rychlosti. Postačí ponechat volbu mezi třemi rychlostmi. Rychlost nižší než 38400 Bd není třeba - tuto rychlost by měla zvládat každá sběrnice. Při rychlosti 115200 Bd dojde ke 20 skenům jednoho modulu za sekundu při počtu 50 modulů na sběrnici. Tato hodnota je pro účely zabezpečovacího softwaru již poměrně rozsáhlého kolejiště dostatečná, takže není třeba vyšších rychlosti. Princip komunikace Chod MTBbus řídí master deska - MTB-USB, která periodicky dotazuje všechny moduly (pomocí zprávy Module Inquiry). MTB modul na každý dotaz odpoví právě jednou zprávou1 0 . Pokud MTB modul nemá žádná data k odeslání, odpoví zprávou Acknowledgement. Tím MTBUSB modulu potvrdí, že zprávu přijal a že komunikuje. MTB-USB tak 9. V dalším textu budeme o jednotlivých devítibitových blocích dat mluvit jako o bytech, přestože se fakticky jedná o devítibitová slova. Pro účely datového využití zprávy je však relevantních jen 8 bitů - byte. 10. Proto není nutné ve směru slavě —> master nastavovat devátý bit. 32 4- N Á V R H M T B v4 může monitorovat aktivní moduly sběrnice a dokonce detekovat moduly nové. Mechanismus pravidelného dotazování modulů nazýváme polling. Příklad komunikace po sběrnici: > Module 1 Inquiry < Acknowledgement # Modul 1 žije, žádná data k odesláni > Module 2 Inquiry # Timeout - modul 2 nežije > Module 3 Inquiry < State of inputs changed, new state: ObOOOOlOlO ObllllOOOO > Module 6 Inquiry < Acknowledgement > Set Outputs of module 1 to ObOOlOlOlO ObOlOOOlOl < Outputs Set to ObOOlOlOlO ObOlOOOlOl > Module 10 Inquiry < Acknowledgement Všimněte si, že probíhá polling pouze některých adres - pro zmenšení latencí je vhodné často dotazovat aktivní moduly a neaktivní moduly dotazovat jen čas od času (aby šlo poznat, že moduly ožily). Dále si všimněte, že příkazy pro moduly (Set Outputs) se posílají nezávisle na tom, který modul je právě dotazován. Komunikační protokol Každá zpráva se skládá z následujících bytů: 1. Adresa modulu. Tento byte má jako jediný nastavený svůj 9. bit na hodnotu 1. Adresa modulu je 8bitové číslo. Adresa 0 znamená, že zpráva se posílá jako broadcast, tedy ji mají číst všechny moduly na sběrnici. Typickou zprávou typu broadcast je požadavek na reset výstupů všech modulů. Adresní prostor 255 modulů byl vyhodnocen jako dostatečně velký. 33 4- N Á V R H M T B v4 2. Délka zprávy. Tento byte obsahuje počet datových bytů zprávy plus jedna (pro kód zprávy). Pro univerzálnost protokolu bylo rozhodnuto jej navrhnout tak, aby délka zpráv nebyla součástí definice jednotlivých zpráv, ale aby byla ve zprávě obsažena explicitně. Toto rozhodnutí umožňuje například MTB-USB modulu přeposílat zprávy mezi MTBbus a počítačem, aniž by musel dekódovat obsah zpráv, případně mít uloženou tabulku typ zprávy, délka. Některé zprávy navíc mohou mít variabilní délku ze své podstaty. Maximální hodnota tohoto bytu je 121, což umožňuje zprávy bezpečně skládat například do bufferů o délce 128 bytů. Maximální délka zprávy byla zvolena s ohledem na nevelké kapacity SRAM mikrokontrolérů a časovou efektivitu případné retransmise. Současná verze protokolu MTBbus umožňuje zprávy o délce nejvýše 7 bytů [6]. Tato hodnota byla zásadně navýšena zejména proto, aby bylo možné novým protokolem posílat firmware pro aktualizaci MTB modulů. 3. Kód zprávy. Libovolné číslo v rozsahu 0-255, definuje význam zprávy. Význam jednotlivých kódů definuje specifikace protokolu. 4. Data zprávy. Až 120 bytů. 5. Kontrolní součet (2 byty). Kontrolní součet se ve zprávě uvádí, aby bylo možné ověřit integritu přijímané zprávy. Integrita zprávy může být narušena například elektromagnetickým rušením nebo špatnými elektrickými vlastnostmi přenosového média. Původní protokol MTBbus zabezpečuje integritu zprávy pomocí jednoduchého mechanismu xor: na jednotlivé byty zprávy je aplikován bitový xor a výsledná hodnota je připojena na konec zprávy. Tento způsob je vhodný pro malé zprávy. 34 4- NÁVRH M T B v4 Nová verze protokolu umožňuje delší zprávy, a tak byl navržen robustnější způsob zabezpečení. Sběrnice MTBbus v4 používá k zabezpečení integrity zprávy standardní mechanismus CRC-16. Tento mechanismus je založen na dělení polynomů se zbytkem. Konkrétně se používá verze CRC-16-IBM. Autor se inspiroval průmyslovou sběrnicí ModBus, která používá právě tento způsob [21]. Příklad zprávy: 0x105 0x001 0x001 OxODO 0x051. 1. 0x105: zpráva pro modul s adresou 5. 2. 0x001: následuje 1 byte zprávy. 3. 0x001: kód zprávy 0x01. 4. OxODO, 0x051: kontrolní součet CRC-16. Zpráva neobsahuje žádná data zprávy. Zprávy Kompletní specifikace významů a kódů zpráv je dostupná online1 1 , zde uvedeme stručný přehled. Zprávy master —> slave spolu s jejich kódy: • 0x01 Module Inquiry • 0x02 Module Information Request • 0x03 Set Configuration • 0x04 Get Configuration • 0x05 Beacon • 0x10 Get Input • 0x11 Set Output • 0x12 Reset Outputs • 0x20 Change Address • OxEO Change Speed • OxFO Firmware Upgrade Request • OxFl Firmware Write Flash 11. https://github.com/kmzbrnol/mtbbus-protocol 35 4- N Á V R H M T B V4 • 0xF2 Firmware Write Flash Status Request • OxFE Module-specific Command • OxFF Reboot Zprávy slave —> master spolu s jejich kódy: • 0x01 Acknowledgement • 0x02 Error • 0x03 Module Information • 0x04 Module Configuration • 0x10 Input Changed • 0x11 Input State • 0x12 Output Set • 0xF2 Firmware Write Flash Status • OxFE Module-specific Command Rozeberme nyní zprávy detailněji. MTB-USB průběžně skenuje aktivní i neaktivní moduly (aktivní častěji) - posílá Module Inquiry. Moduly odpovídají bud Acknowledgement, nebo Input Changed. Pomocí zpráv Module Information Request a Module Information lze zjistit základní informace o MTB modulu: jeho typ, verzi firmwaru, podporovanou verzi protokolu a jestli je modul v bootloaderu. Zpráva Set Output slouží k nastavení stavu výstupů modulu, zpráva Reset Outputs slouží k navrácení výstupů do základního stavu. Tato zpráva je typicky odesílána MTB-USB modulem při ukončení komunikace s počítačem jako broadcast. Počítač může zapisovat nebo číst konfiguraci modulů pomocí zpráv Get Configuration, Set Configuration a odpovědi Module Configuration. Počítač může zapínat a vypínat indikační L E D na M T B modulech pomocí zprávy Beacon. Modulům, které si ukládají adresu softwarově, může operátor z počítače změnit adresu pomocí zprávy Change Address. Plánovaná změna rychlosti sběrnice se modulům ohlašuje pomocí zprávy Change Speed, která je typicky odesílána jako broadcast. Každý 36 4- N Á V R H M T B v4 modul si ukládá rychlost sběrnice do nevolatilní paměti, uloženou rychlost použije při zapnutí modulu. Očekává se, že budoucí typy procesorů v modulech MTB budou schopny detekovat rychlost sběrnice automaticky. V současnosti není na sběrnici MTBbus implementován žádný mechanismus pro automatickou detekci rychlosti. V situaci, kdy je například do sběrnice doplněn nový modul, který je ale z výroby nastaven na jinou rychlost, než aktuálně sběrnice používá, se očekává, že operátor přenastaví rychlost sběrnice na rychlost nového modulu, odešle mu příkaz na změnu rychlosti a vrátí rychlost sběrnice zpět. Tyto kroky lze provést za plného chodu sběrnice. Popisu procesu aktualizace firmwaru modulů se budeme věnovat v samostatné kapitole. Poslední zajímavou zprávou je Module-specific command. Tato zpráva umožňuje odeslat MTB modulu libovolná data (a modul může odpovědět libovolnými daty). Module-specific command se používá například pro řízení specializovaných operací modulů, viz 5.3. Dvouvrstvost protokolu Specifikace MTBbus v4 je tzv. dvouvrstvá. Protokol definuje typy zpráv, ale data některých zpráv specifikují až konkrétní typy MTB modulů. Typ modulu definuje: 1. Formát dat vstupů, formát dat výstupů Protokol je navržený tak, aby moduly mohly mít libovolné typy a počty vstupů i výstupů. Obsah datových bytů zpráv Set Output, Input Changed a Input State je proto specifikovaný až ve specifikaci modulů. Například modul MTB-UNI má 16 digitálních vstupů a 16 digitálních výstupů. Protože počet vstupů i výstupů je malý, posílá se vždy celý stav. Protokol počítá s tím, že jiné moduly mohou mít vstupy a výstupy například s větším rozsahem hodnot (analogové vstupy). V takovém případě protokol umožňuje například neposílat celý stav, 37 4- NÁVRH MTB v4 ale jen relevantní část. To je také důvodem, proč existují 2 různé zprávy Input Changed (posílá se jen stav změněných vstupů) a Input State (posílá se stav všech vstupů).1 2 2. Formát konfigurace Konfigurace různých typů modulů se mohou zásadně lišit v počtu konfigurovatelných hodnot. Například modul MTB-UNI ma 26 konfiguračních bytů. Proto se celá konfigurace posílá najednou. Protokol však umožňuje libovolný způsob zasílání konfigurace - počítač si například u modulů s větším množstvím konfiguračních bytů může vyžádat pouze podmnožinu konfiguračních hodnot. Nebo naopak poslat podmnožinu konfiguračních adres a hodnoty na těchto adresách k nastavení. 3. Adresování a data paměti pro aktualizaci firmwaru Různé typy modulů typicky obsahují různé procesory, které jinak adresují paměť. Liší se například šířka slova nebo velikost paměti. Význam datových bytů zpráv pracujících s aktualizací firmwaru procesoru je proto definován pro konkrétní typy modulů. Typické fungování sběrnice Následující kroky popisují typické fungování systému MTB v4 (srovnejte s postupem definovaným na konci 2.1). 1. Je zapnut řídicí počítač kolejiště. 2. Je zapnuto napájení MTB-USB modulu a všech MTB modulů. 3. MTB moduly z paměti načtou konfiguraci, aplikují základní stav výstupů, začnou poslouchat na sběrnici. 4. MTB-USB detekuje připojené moduly a zapamatuje si je. 5. Počítačová aplikace se připojí k MTB-USB. 6. Počítačová aplikace vyčte z MTB-USB seznam aktivních modulů. 12. Všimněte si, že tento mechanismus umožňuje provádět polling vstupů místo událostního hlášení změn stavů vstupů. To je zcela záměrný prvek MTBbus v4. Využije se například u budoucích modulů s analogovými vstupy. 38 4- N Á V R H MTB v4 7. Aplikace vyčte typ připojených modulů, zkonfiguruje je. 8. Řídicí SW kolejiště používá sběrnici - čte vstupy, nastavuje vý­ stupy. 9. Při odpojení řídicího SW kolejiště je MTB modulům poslán příkaz k rešetu stavu výstupů, čímž je zajištěno, že při odpojení nebo pádu řídicího softwaru se budou nacházet výstupy v definovaném stavu. MTB v4 však nevyžaduje striktní pořadí těchto kroků. Napájení komponent může být zapnuto v libovolném pořadí, systém dokáže detekovat výpadky jednotlivých prvků a obnovovat je. Pro ilustraci uveďme několik příkladů situací, které v systému MTB v4 mohou nastat. • Jiné pořadí zapnutí prvků. Pokud je MTB-USB zapnut až po zapnutí počítače, počítač tento stav korektně detekuje (chybí zařízení) a po připojení MTB-USB jej korektně inicializuje. Sken všech adres sběrnice MTBbus (255 adres) probíhá neustále, takže pokud jsou moduly sběrnice zapnuty až po zapnutí MTBUSB, jsou korektně detekovány. • Výpadek MTB modulu. Pokud MTB modul neodpovídá na zprávy, MTB-USB situaci detekuje, nahlásí ji do počítače a počítač zareaguje. Pokud MTB-USB detekuje nový MTB modul, opět o tom zpraví počítač, ten vyčte typ modulu a zkonfiguruje jej. • Odpojení a připojení modulu za chodu sběrnice (např. výmě­ na). Vyňatý modul je při odpojení napájení nahlášen jako neaktivní, po výměně je aktivován nový modul. • Změna adresy modulu za chodu sběrnice. Původní adresa se stane neaktivní (neodpovídá na požadavky), nová adresa je nalezena a zkonfigurována. 39 4- NÁVRH M T B v4 Aktualizace firmwaru M T B modulů Sběrnice MTBbus je navržena tak, aby skrze ni mohl být aktualizován firmware M T B modulů. Při návrhu mechanismu aktualizace firmwaru bylo zvažováno, jestli aktualizaci nevést úplně jiným protokolem. MTBbus je však dostatečně obecný a navíc je třeba, aby při aktualizaci jednoho modulu ostatní moduly sběrnice aktualizační příkazy ignorovaly. Tyto argumenty vedly k implementaci mechanismu aktualizace firmwaru přímo do sběrnice MTBbus. Výhodou tohoto řešení je, že ostatní moduly sběrnice mohou při změně firmwaru jednoho modulu nadále komunikovat, aktualizace může probíhat za plného provozu. Protokol počítá s tím, že přepis flash paměti procesorů MTB modulů může probíhat pouze z bootloaderu. Aktualizační protokol proto podporuje reboot procesoru do bootloaderu. Procedura aktualizace firmwaru probíhá následovně 1 3 . 1. MTB-USB vyšle Firmware Upgrade Request. Tím informuje M T B modul, že má rebootovat do bootloaderu. 2. MTB odpoví Acknowldgement a rebootuje do bootloaderu. 3. MTB-USB pošle MTB modulu žádost o jeho obecné informace. 4. MTB odpoví obecnými informacemi, ve kterých je mj. zaznačeno, že je v bootloaderu. 5. MTB-USB pošle příkaz Firmware Write Flash, ve kterém pošle blok flash paměti k zapsání a její adresu. MTB zapíše data do své flash paměti. 6. MTB-USB se zeptá M T B modulu příkazem Firmware Write Flash Status Request, jestli již byl zápis do flash paměti dokončen. Jakmile je zápis dokončen, přesouvá se na zápis dalšího bloku paměti (krok 5). 7. Po zapsání celého firmwaru MTB-USB pošle příkaz Reboot. MTB modul provede kontrolu konzistence paměti a naběhne do hlavního programu. 13. Procedura je podrobně popsaná v dokumentaci protokolu MTBbus na https://github.com/kmzbrnol/mtbbus-protocol/blob/master/workflows.md. 40 4- N Á V R H MTB v4 Je doporučeno (a nový firmware MTB-UNI modulů toto doporučení dodržuje), aby při každém startu procesoru MTB modulu proběhla kontrola konzistence paměti programu. Kontrola konzistence v MTB-UNI v4 modulech je implementována pomocí uloženého kontrolního součtu (CRC-16) na konkrétních adresách paměti. Protokol MTBbus obsahuje atribut, kterým může MTB modul oznámit, že sice poslouchá, ale je v bootloaderu a odmítá nabootovat, protože nesedí kontrolní součet hlavního programu. Aktualizace bootloaderu přes sběrnici MTBbus není možná, protože vlivem výpadku napájení při aktualizaci by mohlo dojít k situaci, kdy se modul stane nepoužitelným. Bootloader by měl být malý a odzkoušený kus firmwaru, který se nahraje jednou a nikdy ho nebude třeba přehrávat. Přehrání bootloaderu vyžaduje přímé programování mo­ dulu. 41 5 Implementace MTB v4 5.1 MTB-USB v4 Obrázek 5.1: Prototyp modulu MTB-USB. MTB-USB modul vzniknuvší v rámci této práce byl navržen od základu znovu, inspirace současným MTB-USB modulem je minimální. Vznikly hardware, firmware a popisy komunikačních protokolů. Hlavním úkolem MTB-USB modulu je přeposílat data mezi sběrnicí MTBbus a počítačem. MTB-USB provádí časově kritické operace sběrnice - například počítání timeoutu odpovědi na zprávu od MTB modulů nebo pravidelné dotazování MTB modulů. Počítač je o dění na MTBbus informován formou událostí. 5.1.1 Komunikační protokol s počítačem Před implementací MTB-USB moduluje třeba navrhnout komunikační protokol s počítačem. Tento komunikační protokol musí být přirozeně jiný, než nový komunikační protokol sběrnice MTBbus, který jsme popsali v předchozí kapitole, protože zahrnuje jiné aktéry a funguje na jiném hardwaru. 42 5- IMPLEMENTACE M T B V4 Komunikační protokol MTB-USB a počítače je navržen tak, aby byl do velké míry nezávislý na protokolu sběrnice MTBbus. Nej důležitější zprávou mezi počítačem a MTB-USB je požadavek o přeposlání zprávy mezi USB a MTBbus. Tato zpráva umožňuje počítačovému programu poslat libovolnou zprávu libovolnému MTB modulu (a naopak), aniž by MTB-USB deska musela znát sémantiku této zprávy Na MTB-USB desku můžeme tedy pohlížet v zásadě jako na tenkého přeposílatele mezi dvěma různými sběrnicemi - tzv gateway. Plnohodnotná specifikace protokolu mezi počítačem a MTB-USB je k dispozici online1 . Popišme nyní stručně návrh protokolu. Mezi počítačem a MTB-USB se komunikuje po virtuálním sériovém portu (CDC) tunelovaným skrze USB. Toto řešení bylo vybráno, protože je prakticky standardem pro připojení speciálních periferií k počítači (zvažován byl také HID). USB nezná pojem zprávy tak, jak bychom vyžadovali2 . Protože USB podporuje pouze 8bitový sériový port, začátek zprávy je třeba označit jiným způsobem než pomocí 9. bitu. V navrženém protokolu je začátek zprávy označen speciální sekvencí dvou bytů 0x2A a 0x42. Tato sekvence se sice ve zprávě může objevit, ale pravděpodobnost, že dojde k tolika chybám, aby tato sekvence uprostřed zprávy byla považována za začátek zprávy, je malá.3 Každá zpráva mezi počítačem a MTB-USB má následující strukturu. 1. 0x2A, 2. 0x42, 3. počet následujících bytů, 4. kód zprávy, 5. data zprávy (až 122 bytů). 1. https://github.com/kmzbrnol/mtbbus-protocol/tree/master/pc 2. Při užití třídy C D C se data posílají nejčastěji každou milisekundu a to v bloku o nejvýše 64 bytech. Počítačová aplikace díky bufferování operačního systému není schopna tyto bloky spolehlivě rozlišit. 3. Rozdělování dat do zpráv na straně přijímače se nemusí řídit jen detekcí sekvence 0x2A 0x42. Pokud zprávy nechodí moc často, lze po delší době nepřijímání dat (řádově jednotky milisekund) vyprázdnit vstupní buffer a očekávat tedy že další příchozí data budou novou zprávou. Odesílatel zprávy nesmí posílat jednotlivé části zprávy s velkou prodlevou, to je ale splnitelný požadavek. 43 5- IMPLEMENTACE M T B V4 Struktura je podobná struktuře zprávy protokolu MTBbus, viz 4.2.2. Zpráva neobsahuje kontrolní součet, protože integritu zprávy řeší přímo USB. Upozorňujeme, že kód zprávy není kód zprávy MTBbus, ale kód zprávy protokolu PC - MTB-USB. Zprávy z počítače pro MTB-USB jsou: • Forward packet to MTBbus V datech zprávy následují adresa a zpráva pro MTB modul. • MTB-USB Information Request • Change Speed Požadavek na změnu komunikační rychlosti MTB-USB modulu. Změnu rychlosti jednotlivých MTB modulů je třeba provést předchozím příkazem, typicky broadcastem všem MTB modulům. • Active modules request Odpovědí na tento příkaz je seznam aktivních MTB modulů. • Ping Zprávy z MTB-USB pro počítač jsou: • Acknowledgement • Error • Packet from MTBbus Zpráva je odeslána počítači při odpovědi MTB modulu na zprávu z počítače nebo na pravidelný sken M T B modulů. Z pohledu počítače tak přichází jak odpovědi na příkazy pro M T B modul, které poslal počítač, tak asynchronní události - informace o změně stavu vstupů. • MTB-USB Information • Active modules list 44 5- IMPLEMENTACE M T B V4 • New module discovered event • Module failed event MTB-USB si udržuje seznam aktivních MTB modulů. Polling modulů probíhá v iteracích. V každé iteraci jsou osloveny všechny aktivní moduly a 10 neaktivních modulů. Tím je zaručeno, že aktivní moduly jsou skenovány často a zároveň jsou detekovány moduly nové. Pokud M T B modul neodpoví na Module Inquiry (4.2.2), počítači je odeslána zpráva Module failed event. Modul je považován za ztracený, jakmile neodpoví na Module Inquiry ve třech po sobě jdoucích iteracích. Zpráva Module failed event je při úplném výpadku modulu odeslána celkem třikrát proto, aby bylo možné z počítače monitorovat chod sběrnice. Občasné neodpovídání modulů na výzvy je dobrým indikátorem problémů sběrnice. Vlastností MTBbus je, že každý M T B modul musí vždy odpovědět na každou zprávu, kterou přijme4 . Protože MTBbus je potenciálně nespolehlivé médium, na kterém integritu příkazů zajišťujeme vlastními mechanismy, provádí modul MTB-USB retransmisi zpráv MTB modulům v případě, že na zprávu nepřijde žádná odpověď, a to až třikrát. Proto je součástí zprávy Packet from MTBbus také počítadlo, které říká, na kolikátý pokus byla odpověď přijata (u asynchronních událostí 0). Toto číslo bylo do protokolu vloženo opět se záměrem, aby bylo možné v počítači monitorovat chod sběrnice. Na dalších příkazech protokolu není vcelku nic zajímavého, pokud je čtenář chce prostudovat, je mu k dispozici plná specifikace protokolu5 . 5.1.2 Hardware Srdcem MTB-USB modulu je procesor STM32F103, což je moderní mikrokontrolér architektury ARM. Autor jej zvolil z několika důvodů. 4. Výjimkou jsou pouze broadcast zprávy. 5. https://github.com/kmzbrnol/mtbbus-protocol/tree/master/pc 45 5- IMPLEMENTACE M T B V4 Obrázek 5.2: Krabička a deska plošných spojů MTB-USB. 1. Procesor STM32F103 má hardwarovou podporu USB. 2. Procesory STM32 nabízí velké velikosti pamětí a výpočetní výkon. 3. Procesory STM32 se stávají standardy v embedded systémech. 4. Procesory STM32 se dají velice snadno debugovat. 5. Procesor STM32F103 je jako jeden z mála STM součástí basic součástek na https://jlcpcb.com/. 6. Autor se chtěl naučit pracovat s novou architekturou procesorů. Hardwarová podpora USB umožňuje výrazně vyšší flexibilitu komunikace s počítačem než použití historicky zaužívaných převodních obvodů mezi USB a sériovou linkou. V programu procesoru je tak například možné definovat, že procesor má více CDC linek - druhá se využije například pro ladění programu. Procesor může v budoucnu používat libovolnou třídu USB. Celé řešení se tak stává mnohem lépe upravitelné pouze změnou softwaru, což je méně pracné, než změna hardwaru. Všechny desky plošných spojů (DPS) navržené v rámci této práce jsou vytvořeny tak, aby se daly automaticky osazovat (firmou JLCPCB6 ). JLCPCB nabízí automatické osazování malých sérií DPS za dostupnou cenu, což výrazně zjednodušuje výrobu nových komponent. JLCPCB rozlišuje tzv. basic a extended součástky k osazení, přičemž za basic se 6. Aktuálně lze osazovat pouze jednu stranu desky a pouze S M D součástky. 46 5- IMPLEMENTACE M T B V4 neplatí režijní poplatek při osazování. Basic součástky jsou ty které se používají skutečně často (typicky diskrétní součástky - rezistory kondenzátory apod.) a u kterých se očekává, že se budou vyrábět i za desítky let. Procesor STM32F103 byl zvolen mj. proto, že je basic součástkou. Schéma a výkres DPS byly vytvořeny v nástroji KiCad, který autor této práce používal poprvé. Jedním z hlavních přínosů celé této práce pro něj je, že se naučil pracovat s programem KiCad. Schéma a výkres DPS jsou k dispozici online7 , schéma je přiloženo také jako příloha této práce (A.l). Popišme nyní stručné schéma. Schéma je na první pohled rozděleno na 2 části, které jsou na DPS galvanicky oddělené - USB část (vlevo) a MTBbus část (vpravo). USB část obsahuje procesor a je napájena přímo z USB. MTBbus část obsahuje rozhraní sběrnice MTBbus a je napájena buď z externího zdroje (ze stejného jako zbytek sběrnice MTBbus), nebo přes galvanicky oddělený měnič PSI. Osazením nebo neosazením součástek se zvolí, která varianta se bude používat. Hlavním prvkem USB části schématu je procesor STM32F103 (vlevo nahoře). K procesoru jsou připojena diagnostická rozhraní (J2, J3). Celá USB část je napájena z USB portu, přičemž je využito moderního konektoru USB-C. Rozhraní USB a MTBbus části schématu tvoří galvanicky oddělený budič sběrnice RS485 typu ADM2483. ADM2483 je osvědčený budič, který zvládá proudy sběrnice až do 250 mA [22] a je tedy vhodný pro komunikaci s větším počtem MTB modulů. Specialitou MTB-USB moduluje měřící obvod INA219 ve sběrnicové části desky, který měří napětí a proud do sběrnicové části obvodu ADM2483 a posílá naměřenou hodnotu přes galvanický oddělovač do procesoru. Procesor je tak schopen detekovat nestandardní chování sběrnice, například zkrat.8 Při návrhu desky plošných spojů bylo třeba vyřešit především to, do jaké krabičky desku vložit. MTB-USB modul totiž typicky není pevnou 7. https://github.com/kmzbrnoI/mtb-usb-4-pcb 8. Pro měření zatím není podpora v komunikačním protokolu s počítačem a ve firmwaru. Hardware je odzkoušený. Podporu je v plánu doplnit v další verzi. 47 5- IMPLEMENTACE M T B V4 součástí kolejiště, je umístěn vedle kolejiště u řídicího serveru. Vyvstal tak požadavek modul zavřít do krabičky, ideálně s možností uchycení na zeď. Po rešerši byla zvolena krabička firmy Digikeijs, jejíž zásadní výhodou je, že pro vyvedení konektorů a indikačních LED není třeba do krabičky frézovat. Navíc lze na krabičku velice elegantně nalepit potisk, který vysvětluje použití jednotlivých konektorů a význam LED. Celé řešení je zobrazeno na obrázcích 5.1 a 5.2. 5.1.3 Firmware Firmware je psaný v jazyce C, který byl zvolen především proto, že ve stejném jazyce je psána základní knihovna pro interakci s periferiemi procesoru STM32 HAL [23], kterou firmware využívá. Při práci s periferiemi je využito Direct Memory Access (DMA). Pro komunikaci přes U S B byla využita komunitní knihovna libusb_stm329 . Celý firmware je k dispozici pod opensource licencí online1 0 . 9. https://github.com/dmitrystu/libusb_stm32 10. https://github.com/kmzbrnoI/mtb-usb-4-fw 48 5- IMPLEMENTACE MTB V4 5.2 MTB-UNI v4 Další komponentou nového systému MTB je nový modul typu MTBUNI. Tento modul vznikl, aby bylo možné provádět nové instalace systému MTB a rozšiřovat současné instalace o nové moduly. 5.2.1 Základní parametry Tabulka 5.1: Základní parametry modulu MTB-UNI v4 Vstupy 16 digitálních vstupů Výstupy 16 výstupů v režimu otevřeného kolektoru, všechny umožňují kmitání a generování S-COM signálu Napájení 7-17 V D C Adresování pomocí jumperů Procesor ATmegal28 Aktuální modul MTB-UNI má 16 digitálních vstupů a 16 digitálních výstupů. Tento počet se autor práce rozhodl zachovat, protože vhodně škáluje pro malé i velké železniční stanice na modelových kolejištích. Současné MTB-UNI a MTB-TTL moduly používají různé konektory pro připojení periferií: svorkovnice nebo nasouvací konektory typu PSH 11 . Modul MTB-UNI v4 umožňuje variantní osazení jak svorkovnic, tak konektorů PSH. Tím modul slučuje současné moduly MTB-UNI, MTB-UNIm a MTB-TTL do jediné DPS, což zjednodušuje údržbu a vývoj. Hardwarové řešení výstupů je ponecháno: výstupy jsou v režimu otevřených kolektorů, jsou řízeny skrze obvody ULN2803, které umožňují dostatečný výstupní proud až 0.5 A / 8 výstupů. Všechny výstupy umožňují kmitání i vysílání signálu S-COM. Modul obsahuje 16 digitálních vstupů. Podporu IR čidel řeší samostatná deska, viz 5.4. 11. Např. https : //www.gme . cz/konektor-se-zamkem-psh02-04pg. 49 5- IMPLEMENTACE M T B V4 Deska plošných spojů je navržena tak, aby byly zachovány rozměry a umístění upevňovacích otvorů se současným nejmenším modulem - MTB-TTL. Návrh této desky vznikal ve spolupráci s MENDELU. Schéma vytvořil Robert Čížek, DPS, firmware a koncepční návrh modulu jsou dílem autora této práce. 5.2.2 Hardware Při návrhu modulu připadají v úvahu dva přístupy: 1. malý procesor, posuvné registry na vstupy a výstupy; 2. velký procesor, vstupy a výstupy připojené přímo na piny proce­ soru. Autor této práce zvolil přístup (2), protože chtěl minimalizovat počet součástek na desce a protože v dnešní době jsou malé procesory s větším počtem IO pinů již běžně dostupné. Schéma i DPS jsou vytvořeny v programu Eagle jako openhardware projekt, dostupné online1 2 , schéma také v příloze A.2. Okomentujme nyní zajímavé prvky schématu a DPS. Jádrem modulu je procesor ATmegal28. Autor této práce si zvolil procesor architektury AVR, protože s používáním těchto procesorů má dlouholeté zkušenosti. Model ATmegal28 byl pak zvolen proto, že je to nejmenší model rodiny ATmega, který obsahuje požadované množství pinů. Vstupy MTB-UNI v4 modul oproti modulu současnému obsahuje řádnou ochranu vstupů. Ochranný obvod vznikl ve spolupráci Jana Horáčka, Michala Petrilaka a Roberta Čížka. Zapojení jednoho vstupuje demonstrováno na obrázku 5.3. 12. https://github.com/kmzbrnoI/mtb-uni-4-ele 50 5- IMPLEMENTACE MTB V4 J I INPUT , 1 Fl 50mA £t> Schottky 12 CPU 1 Cl , lOOn 1 D2 R 3 5V1 2k2 HZZ1 C2 , lOOn ' 7\ JI Ql BTlrsap auAHiseu euiaips :£'V >[9z?jqO LED2 BLUE R3 1 LED1 10k GREEN V. R4 l k > cn ^ : ' ~U "O "O "O O O ^ O r - i n r - i n M<" CD < hO K > < A H O I I H J 'V