Funkční bloky GE Mark VI pro řídicí logiku plynové turbíny

Diagnostika problému s plynovou turbínou je snazší, když technici oddělí tři vrstvy: hardware v poli, aplikační logiku řídicího systému a nadřazené nástroje používané k monitorování a údržbě obou vrstev. Systémy GE Mark VI a Mark VIe provádějí aplikační logiku sestavenou z propojených funkčních prvků, ale přesné názvy bloků, knihovny a hardwarová rozhraní závisí na nainstalované generaci a revizi projektu.

Toto rozlišení je během odstávky důležité. Poruchu rozhraní I/O nebo chybějící signál z pole nevyřešíte změnou sekvenční logiky. Funkční vstup, který je odmítnut podmínkou povolení, hlasovacím obvodem, časovačem nebo přechodem mezi stavy, nevyřešíte výměnou jiné svorkovnicové desky. Prvním úkolem je určit, která vrstva přestala plnit svou funkci.

Hardware přenáší signály z pole a provádí aplikaci; projekt funkčních bloků určuje, jak se z těchto signálů stanou příkazy, podmínky povolení, alarmy a vypnutí.

Začněte určením nainstalované generace řídicího systému

Mark VI a Mark VIe patří do stejné řady řídicích systémů, ale nejde o vzájemně zaměnitelné platformy. Liší se řídicí jednotkou, I/O, sítí i podrobnostmi inženýrských nástrojů. Výkres, záloha nebo náhradní díl musí odpovídat skutečné konfiguraci jednotky, nikoli obecnému označení „Mark VI“, které se používá v běžné komunikaci.

U systémů Mark VIe popisuje GE Vernova softwarovou sadu ControlST jako prostředí zahrnující ToolboxST pro konfiguraci a diagnostiku spolu s aplikacemi pro pracovní stanice, trendy, alarmy a správu systému. Užitečnou referencí pro tyto funkce je oficiální přehled softwarové sady ControlST. Klasické instalace Mark VI mohou mít jiné nástroje a omezení daná revizí, proto vycházejte z licencí pro dané pracoviště, záznamů o nainstalovaném softwaru a dokumentace OEM pro konkrétní jednotku.

Pokud oprava vyžaduje hardware, porovnejte úplnou identifikaci dílu, revizi, požadavky na firmware, vazbu na svorkovnicovou desku a úlohu v redundantním systému. Příslušné položky lze prohlédnout ve kolekci desek GE a řízení turbín, kompatibilitu však určujte podle kusovníku a příruček pro dané pracoviště, nikoli podle vizuální podobnosti.

Aplikační logiku čtěte podle funkce, ne podle zapamatovaného názvu bloku

Projekt turbíny se snáze chápe, když je jeho logika rozdělena podle účelu v rámci inženýrství. Přesné proprietární názvy bloků se mohou lišit, zatímco základní řídicí povinnosti zůstávají rozpoznatelné.

Sekvenční řízení a podmínky povolení

Spouštění, proplach, zapálení, zrychlování, synchronizace, zatěžování, odlehčování a odstavení jsou procesy řízené stavy. Každý přechod závisí na podmínkách povolení, jako jsou poloha ventilu, stav mazacího oleje, otáčky, plamen, ventilace a časování. Zastavenou sekvenci sledujte až k první nesplněné podmínce přechodu. Vynucení následného stavu skryje příčinu a může obejít důkazy potřebné k bezpečné opravě.

Řízení paliva a zatížení

Požadavek na palivo je určován provozním stavem, řízením otáček nebo zatížení, teplotními limity, limity zrychlení, charakteristikou ventilů a omezeními palivového systému. Selektory vybírají nejvíce omezující platný požadavek nebo limit. Rampy a omezovače rychlosti změny zabraňují náhlým příkazům. Nízký výsledný požadavek proto nemusí znamenat poruchu regulátoru; výběr může správně ovlivňovat jiný limit.

Řízení průtoku vzduchu a teploty

Plánování polohy vstupních rozváděcích lopatek a řízení teploty výfukových plynů vzájemně působí s provozními podmínkami kompresoru, režimem spalování, okolními podmínkami a zatížením. Než změníte ladicí konstantu, diagnostikujte měřicí řetězec a aktivní limit. Zkreslený teplotní vstup, neplatný medián nebo nesprávný stav kvality může způsobit, že se správně fungující regulační smyčka jeví jako špatně vyladěná.

Ochrany a hlasování

Funkce ochrany proti nadotáčkám, zhasnutí plamene, vibracím, teplotě ložisek, problémům se spalováním a dalším stavům určují, zda může provoz pokračovat. Redundantní kanály mohou být vybírány, zpracovávány hlasováním nebo posuzovány podle kvality a časování. Obsluha musí vědět, který jednotlivý kanál se rozcházel s ostatními, který výsledek hlasování se stal aktivním a zda vypnutí vzniklo uvnitř řídicího systému turbíny, nebo v externím ochranném systému.

Uchovávejte kvalitu signálu společně s jeho hodnotou

Funkční blok by neměl považovat každou číselnou hodnotu za stejně důvěryhodnou. Inženýrská diagnostika potřebuje surovou nebo upravenou hodnotu, stav kvality, informaci o překročení rozsahu, indikaci poslední platné hodnoty a údaje o neshodě mezi kanály. Vadný převodník zamrzlý na zdánlivě věrohodné hodnotě může být nebezpečnější než signál se zjevně překročeným rozsahem.

Než obviníte aplikační logiku, sledujte signál od začátku do konce: zařízení v poli, vedení a napájení, svorkovnicový bod, diagnostiku I/O, proměnnou v řídicí jednotce, úpravu signálu, hlasování nebo výběr a konečného příjemce. Porovnejte redundantní kanály a historické trendy. Pokud řídicí jednotka vidí jinou hodnotu než displej obsluhy, zjistěte, kde se liší škálování, komunikace nebo zpracování pro zobrazení.

Používejte inženýrské nástroje jako důkaz

GE Vernova uvádí, že ekosystém řízení Mark VIe podporuje řízení, sekvenční a ochranné funkce, monitorování a alarmy i funkce sekvence událostí nebo historie vypnutí. Tyto záznamy používejte společně. Trend ukazuje, jak se hodnoty měnily; seznam alarmů zobrazuje deklarované stavy; data sekvence událostí pomáhají určit pořadí; monitorování aplikace ukazuje aktivní cestu přes podmínky povolení a selektory.

Důkazy zaznamenejte ještě před vypnutím a opětovným zapnutím napájení nebo výměnou hardwaru. Zapište stav řídicí jednotky a I/O, aktivní diagnostiku, informace o prvním vyvolaném alarmu, stav synchronizace času, relevantní trendy a přesný stav jednotky. Restart může příznak odstranit a současně vymazat časovou posloupnost událostí.

Systematický diagnostický postup

1. Definujte nesplněnou funkci

Popište, co systém neprovedl: přechod při spouštění nebyl dokončen, požadavek na palivo zůstal omezený, kanál byl odmítnut nebo se aktivoval výstup vypnutí. Nezačínejte předpokladem, že selhal konkrétní díl.

2. Najděte první rozhodující podmínku

Sledujte aplikaci od konečného příkazu nebo stavu zpět přes selektory, podmínky povolení, časovače a logiku kvality. Určete první nadřazenou podmínku, která výsledek vysvětluje. Ověřte její zdroj, místo abyste ji přemostili.

3. Ověřte hardwarovou cestu

Pokud je to bezpečné, použijte diagnostiku I/O a nezávislé měření. Zkontrolujte napájení, vedení, konfiguraci kanálu, svorkovnicový hardware, stav sítě a stav redundance. U vibračních signálů podle potřeby zahrňte také externí monitor a řetězec sond; související komponenty lze prohlédnout v kolekci Bently Nevada.

4. Porovnejte stav se schválenou základní konfigurací

Ověřte verzi aplikace, konfiguraci řídicí jednotky, revizi knihoven a nahraný stav podle schválené zálohy. Nezdokumentovaný rozdíl je problémem správy konfigurace, i když turbína právě pracuje.

5. Otestujte zotavení a chování při poruše

Po opravě ověřte normální provoz i příslušný abnormální stav. Prokažte zpracování kvality kanálu, přechod redundance, signalizaci alarmu, časování sekvence, pravidla resetu vypnutí a viditelnost pro obsluhu. Pouhé zhasnutí alarmu není akceptační zkouškou.

Změny vyžadují řízení na úrovni odstávky

Změny aplikace mohou ovlivnit spalování, rotující zařízení, ochranné zásahy, emise a rizika pro personál. Používejte autorizovaný přístup, schválený balíček změn, kontrolu OEM nebo kvalifikovaného inženýrství, zálohy, kontrolu druhou osobou, simulaci nebo offline kontrolu, pokud jsou k dispozici, a zdokumentovaný plán návratu k předchozímu stavu. Nikdy neimportujte logiku z jiného rámu nebo jednotky jen proto, že blokové schéma vypadá povědomě; palivový systém, přístrojové vybavení, volitelné funkce a úpravy na pracovišti se mohou lišit.

Prakticky vzato je „reference funkčních bloků“ nejcennější jako mapa odpovědností, nikoli jako univerzální katalog proprietárních názvů. Technici, kteří rozumějí sekvenčnímu řízení, omezování, hlasování, kvalitě signálu a hranicím ochranných funkcí, dokážou v projektu daného pracoviště najít rozhodující důkaz. Ti, kteří si zapamatují název bloku, ale neověří nainstalovanou revizi, riskují opravu nesprávné vrstvy systému.