SGCom je navrhnutý tak, aby bol odolný voči rôznym formám výpadkov. Pri svojom štarte sa musí pripojiť k centrále, aby získal konfiguráciu (bez ktorej nevykoná žiadnu akciu), ale potom môže pracovať aj v prípade, že stratí s centrálou na nejaký čas kontakt. Je robustný aj v prípade, že nedokáže vykonať zber dát, o čom informuje centrálu a poskytuje mechanizmy, ako neskôr dáta opätovne získať. Životný cyklus ilustruje nasledujúci obrázok a možno ho tiež popísať v nasledovných krokoch.

 Image Removed

Obrázok 3 Ilustrácia životného cyklu

is designed to be resilient to various forms of outages. When it starts, it must connect to the metering central to get the configuration (without which it will not perform any action), but then it can work even if it loses contact with the metering central for some time. It is robust even if it fails to collect data, which it reports to the metering central and provides mechanisms to recover the data later. The life cycle is illustrated in the following figure and can also be described in the following steps.

 Image Added

Figure 3 - Illustration of the life cycle

1. Starting the application, processing the command line parameters, which, among other things, contain the address for connecting to the D2000 kernel, login data, and the address of the so-called "point of first contact".
2. Performing maintenance on the DataStorage module:
   • Deleting records older than 90 days. The task repeats every 24 hours.
   • Removing the transaction number tag from all records (details in step 7).
3. Connection to the D2000 kernel of the metering central. SGCom tries to get a D2Japi Session, which will be represented in DODM by an object with the name in the form SGCOM1.SGC. If unsuccessful, the connection is retried every 30 seconds.
4. Signing in to the "point of first contact" The address of the object is defined by the -f command-line parameter, which is an instance of an object of type D2000 Event that implements the I.SGC_FirstContactServer interface. It signs in by calling RPC SignIn with the _name parameter value set to the process name (from the command line). RPC is asynchronous and establishes an application-defined conversation that ensures that either SGCom or metering central knows when its partner crashes.
5. The metering central responds to the establishment of the first contact by sending a new configuration to SGCom, or changes the existing one. The D2000 Event that controls sending the configuration must implement the I.SGC_Configurator interface, SGCom implements the I.SGC_Configurable interface for reception.
   1. Configuration transfer is transactional. All changes are either OK and accepted as a whole, or all are rejected and the configuration is left in its original state. The sequence of steps is as follows:
      1. Open Transaction: I.SGC_Configurable^OpenTransaction
      2. Submit changes: I.SGC_Configurable^Set* and Delete*.
   2. Commands must be entered in such a sequence that the referential integrity of the configuration database is not violated at any time.
      1. Commit of the transaction: I.SGC_Configurable^Commit
      2. Confirmation of acceptance of changes I.SGC_Configurator^OnTransactionAccepted, or rejection of changes I.SGC_Configurator^OnTransactionDenied with a list of errors in the parameter.
   3. Alternatively, the transaction can be rolled back from the metering central by calling I.SGC_Configurable^Rollback, which SGCom will confirm with I.SGC_Configurator^OnTransactionRolledBack. The transaction is automatically canceled also if the application-defined conversation is interrupted.
6. According to the current SGCom configuration, SGCom sets its task schedule - for each PeriodicEvent entity, it creates a separate record and schedules its execution.
7. When the time point for which a periodic event is scheduled occurs, SGCom looks at the current configuration and starts performing all related tasks. In the TaskExecutor module, tasks for collecting and transferring data are inserted into the appropriate queues, which the TaskExecutor then executes. The execution of tasks that do not compete with each other is parallel. (Note: two tasks that are executed on the same logical device and also tasks that serve logical devices connected by the same communication line compete with each other. Data collection and transmission do not compete with each other.)
   Data collection of each variable, whether successful or unsuccessful, ends with the result being recorded in the DataStorage module. On successful collection it's a list of values with timestamps, on failure it's the error code and description, also timestamped.
   Values are transferred to the metering central by individual logical devices and individual quantities (DataPoint). Each transfer represents a separate transaction, and only when the central office confirms the successful transfer of values, the data is removed from DataStorage. The upload for one logical device and quantity consists of the following steps:
   1. Generation of a unique transaction ID.
   2. All records for a given logical device and quantity are identified by a transaction number. (If the previous transaction has not ended, only new records are marked.)
   3. The values and timestamps of tagged records are sent by calling I.SGC_DataCollector^OnDataCollected.
   4. After data processing, the transaction is terminated by calling I.SGC_DataProducer^OnDataAccepted.
   5. Records marked with the corresponding transaction number are deleted from DataStorage.
      (Note: RPC communication takes place as part of an application-defined conversation, so if the processing of transferred data fails for some reason, SGCom will learn about this fact and the transaction will be canceled. The data will remain in DataStorage until the next scheduled data transfer, and the transaction number will be removed.)
8. At any time after sending the configuration, the metering central can send a command to perform an "immediate" task. Most often, the reading of archived data of measured variables is performed for the period for which data is missing in the central station, but also the setting of the exact time in the meters and others. Commands are controlled by pair interfaces
9. Štart aplikácie, spracovanie parametrov príkazového riadku, ktoré okrem iného obsahujú adresu pre pripojenie sa ku D2000 kernelu, prihlasovacie údaje a adresu tzv. „bodu prvého kontaktu".
10. Vykonanie údržby modulu DataStorage:
    • Vymazanie záznamov starších ako 90 dní. Úloha sa opakuje každých 24 hodín.
    • Odstránenie označenia číslom transakcie zo všetkých záznamov (podrobnosti v kroku 7).
11. Pripojenie ku D2000 kernelu centrály. SGCom sa pokúša získať D2Japi Session, ktorá bude v DODM reprezentovaná objektom s názvom v tvare SGCOM1.SGC. V prípade neúspechu sa pokus o pripojenie opakuje každých 30 sekúnd.
12. Prihlásenie sa do „bodu prvého kontaktu" Adresa objektu je definovaná parametrom z príkazového riadku –f., čo je inštancia objektu typu D2000 Event, ktorá implementuje rozhranie I.SGC_FirstContactServer. Prihlási sa volaním RPC SignIn s hodnotou parametra _name nastavenou na meno procesu (z príkazového riadku). RPC je asynchrónne a zakladá aplikačne riadenú transakciu, ktorá zabezpečí, že sa buď SGCom alebo centrála dozvie, keď jej partner havaruje.
13. Centrála na nadviazanie prvého kontaktu reaguje tým, že odošle do SGCom-u novú konfiguráciu, resp. zmení existujúci. D2000 Event, ktorý riadi zasielanie konfigurácie musí implementovať rozhranie I.SGC_Configurator, SGCom pre prijatie implementuje rozhranie I.SGC_Configurable.
    1. Prenos konfigurácie je transakčný. Všetky zmeny sú buď v poriadku a prijaté ako celok, alebo sú všetky zamietnuté a konfigurácia je ponechaná v pôvodnom stave. Postupnosť krokov je nasledovná:
       1. Otvorenie transakcie: I.SGC_Configurable^OpenTransaction
       2. Odoslanie zmien: I.SGC_Configurable^Set* a Delete*.
    2. Príkazy je nutné zadávať v takom poradí, aby nebola v žiadnom okamihu porušená referenčná integrita konfiguračnej databázy.
       1. Commit transakcie: I.SGC_Configurable^Commit
       2. Potvrdenie prijatia zmien I.SGC_Configurator^OnTransactionAccepted, alebo zamietnutie zmien I.SGC_Configurator^OnTransactionDenied so zoznamom chýb v parametri.
    3. Alternatívne môže byť transakcia zrušená zo strany centrály volaním I.SGC_Configurable^Rollback, čo SGCom potvrdí I.SGC_Configurator^OnTransactionRolledBack. Transakcia je automaticky zrušená aj v prípade, že sa preruší aplikačne riadená konverzácia.
14. SGCom podľa aktuálnej konfigurácie SGCom nastaví svoj harmonogram úloh – pre každú entitu PeriodicEvent vytvorí zvlášť záznam a naplánuje jej vykonanie.
15. Keď nastane časový okamih, na ktorý je naplánovaná periodická udalosť, SGCom prezrie aktuálnu konfiguráciu a začne vykonávať všetky súvisiace úlohy. Do modulu TaskExecutor vloží do príslušných front úlohy na zber a odovzdávanie dát, ktoré TaskExecutor následne vykoná. Vykonanie úloh, ktoré si vzájomne nekonkurujú je paralelné. (Pozn.: vzájomne si konkurujú dve úlohy, ktoré sú vykonané na tom istom logickom zariadení a tiež úlohy, ktoré obsluhujú logické zariadenia pripojené tou istou komunikačnou linkou. Zber a odovzdávanie dát si vzájomne nekonkuruje.)
    Zber dát každej jednej veličiny, či už úspešný alebo neúspešný, končí tým, že je výsledok zaznamenaný do modulu DataStorage. Pri úspešnom zbere je to zoznam hodnôt s časovými značkami, pri neúspešnom je to kód a popis chyby, tiež s časovou značkou.
    Odovzdanie hodnôt centrále prebieha po jednotlivých logických zariadeniach a jednotlivých veličinách (DataPoint). Každé odovzdanie predstavuje samostatnú transakciu a až keď centrála potvrdí úspešné prevzatie hodnôt, sú dáta odstránené z DataStorage. Odovzdanie pre jedno logické zariadenie a veličinu pozostáva z nasledujúcich krokov:
    1. Vygenerovanie unikátneho ID transakcie.
    2. Všetky záznamy pre dané logické zariadenie a veličinu sú označené číslom transakcie. (V prípade, že predchádzajúca transakcia neskončila, sú označené len nové záznamy.)
    3. Hodnoty a časové značky označených záznamov sú odoslané volaním I.SGC_DataCollector^OnDataCollected.
    4. Po spracovaní dát je transakcia ukončená volaním I.SGC_DataProducer^OnDataAccepted.
    5. Záznamy označené príslušným číslom transakcie sú vymazané z DataSorage-u.
       (Pozn.: RPC komunikácia prebieha v rámci aplikačne riadenej transakcie, takže ak spracovanie odovzdaných dát z nejakého dôvodu zlyhá, SGCom sa túto skutočnosť dozvie a transakcia sa zruší. Dáta zostanú v DataStorage-i do nasledujúceho plánovaného odovzdávania dát a označenie číslom transakcie sa odstráni.)
16. Centrála môže kedykoľvek po odoslaní konfigurácie zadať príkaz na vykonanie „okamžitej" úlohy. Najčastejšie sa vykonáva čítanie archivovaných dát meraných veličín za obdobie, pre ktoré v centrále chýbajú dáta, ale tiež nastavenie presného času v meračoch a iné. Príkazy sú riadené párovými rozhraniami I. SGC_ImmediateReadMaster – Slave, I.SGC_SetRTCMaster – Slave, I.SGC_ConsumerDisconnectMaster – Slave, kde centrála implementuje Master rozhranie a SGCom implementuje Slave. Všetky príkazy prebiehajú v režime aplikačne riadených konverzácií ale vždy pozostávajú len s jednoduchej výmeny príkaz – oznámenie výsledku.
17. Ak SGCom stratí spojenie s centrálou, naďalej pokračuje vo vykonávaní plánovaných úloh, ako je popísané v bode 7. Zber dát prebieha bez zmeny, všetky pokusy o odovzdanie zlyhajú a zozbierané dáta sa preto zhromažďujú v DataStorage-i až dovtedy, kým sa nepodarí spojenie obnoviť a dáta odovzdať. Po nadviazaní nového spojenia pokračuje vykonávanie bodom 4.

Modul TaskExecutor

Modul TaskExecutor je zodpovedný za vykonávanie všetkých úloh, ktoré vyplývajú z konfigurácie ako aj všetkých „okamžitých" úloh. Používa pri tom zoznam pravidiel, ktoré určujú, ktoré úlohy je možné vykonať paralelne. Úlohám, ktoré paralelne vykonať nemožno (lebo si vzájomne konkurujú v prístupe k meračom), definuje poradie, v akom sa vykonajú tak, aby bola maximalizovaná priepustnosť. Zároveň tieto pravidlá definujú časové okná, počas ktorých komunikácia s niektorými meračmi nie je možná – po ukončení spojenia nie je možné určitý čas nadviazať nové spojenie.
Pri vytváraní konfigurácie je potrebné brať do úvahy tieto pravidlá, ako aj čas, ktorý trvá vytvorenie spojenia, vykonanie jednotlivých úloh, zatvorenie spojenia a výluka spojenia, aby nebolo naplánovaných viac úloh, ako je možné obslúžiť.
Pri obsluhe meračov sa vykonávanie úloh riadi nasledujúcimi pravidlami:

1. where the metering central implements the Master interface and SGCom implements the Slave. All commands take place in the mode of application-defined conversations but always consist of a simple exchange of command - notification of the result.
2. If the SGCom loses connection with the metering central, it continues to perform the scheduled tasks as described in point 7. Data collection continues unchanged, all transmission attempts fail, and the collected data is therefore collected in DataStorage until the connection is restored and the data uploaded. After establishing a new connection, the execution continues with point 4.

TaskExecutor module

The TaskExecutor module is responsible for executing all tasks that result from the configuration as well as all "immediate" tasks. It uses a list of rules that determine which tasks can be executed in parallel. For tasks that cannot be executed in parallel (because they compete for access to the meters), it defines the order in which they are performed to maximize throughput. At the same time, these rules define time windows during which communication with some meters is not possible - after the connection is terminated, it is not possible to establish a new connection for a certain time.
These rules must be taken into account when creating the configuration, as well as the time it takes to establish a connection, execute each task, close the connection, and shut down the connection so that more tasks than can be serviced are not scheduled.
When operating meters, the performance of tasks is governed by the following rules:

1. It is not possible to create two or more connections to a single logical device at the same time.
2. It is not possible to create simultaneous connections to two logical devices that are connected by the same communication line (they share the same Connector entity in the configuration).
3. If there is an active connection to a logical device, all tasks queued for that device must be executed before the connection is closed (for optimization reasons). Tasks are selected from the queue using a "first-came-first-served" policy.
4. After the last task from the queue is executed, the connection to the logical device remains active for 10 seconds. The length of waiting for a new task can be adjusted with the command line parameter -n. If a new task is added to the queue during this time interval, it is also executed and the connection is kept established for another 10 seconds. The connection is closed only when no new task is added. (In order to efficiently serve fast-repeating tasks.)
5. After canceling the connection, it is not possible to create a new connection to any of the logical devices that are connected by the used communication line for 20 seconds. The length of the protection interval can be changed from the command line with the parameter -s. (Because the connection would still be rejected and would last longer until the connection could be established again.)
6. After the 20-second guard interval expires, the next logical device waiting in the queue is served.
7. If an attempt to establish a connection with a logical device is unsuccessful 3 times in a row, it is considered disconnected - HardError state - and a connection cannot be established with it for the next 5 minutes. The number of attempts can be changed with the command line parameter -r. The duration of the HardError state can be modified with the command-line parameter -d. All jobs in the queue that should have been executed on this device are canceled, as well as all new jobs for the duration of the HardError state. After this period, it is possible to try to connect to the device again.
8. All tasks that do not compete with each other can be executed in parallel by the threads of the respective ThreadPool. The maximum number of threads in the ThreadPool is 512. The maximum number of threads can be adjusted with the command line parameter -t, but it changes dynamically according to current needs
9. Nie je možné vytvoriť súčasne dve alebo viac spojení s jedným logickým zariadením.
10. Nie je možné vytvoriť súčasne spojenia na dve logické zariadenia, ktoré sú pripojené tou istou komunikačnou linkou (v konfigurácii zdieľajú tú istú entitu Connector).
11. Ak existuje aktívne spojenie k nejakému logickému zariadeniu, musia sa vykonať všetky úlohy, ktoré sú pre dané zariadenie zaradené do fronty úloh skôr, ako bude spojenie ukončené (z optimalizačných dôvodov). Úlohy sú z fronty vyberané politikou „first-came-first-served".
12. Po vykonaní poslednej úlohy z fronty zostáva spojenie k logickému zariadeniu aktívne ešte 10 sekúnd Dĺžku čakania na novú úlohu je možné upraviť parametrom z príkazového riadku -n.. Ak je v tomto časovom intervale do fronty zaradená nová úloha, je tiež vykonaná a spojenie sa opäť ponecháva aktívne ďalších 10 sekúnd. Až keď nepribudne žiadna nový úloha, je spojenie uzatvorené. (Aby bolo možné efektívne obslúžiť rýchlo sa opakujúce úlohy.)
13. Po zrušení spojenia nie je možné vytvoriť nové spojenie na žiadne z logických zariadení, ktoré sú pripojené použitou komunikačnou linkou po dobu 20 sekúnd Dĺžku ochranného intervalu je možné zmeniť parametrom z príkazového riadku -s.. (Lebo by bolo spojenie aj tak odmietnuté a trvalo by to dlhšie, kým by sa spojenie podarilo opäť nadviazať.)
14. Po uplynutí 20-sekundového ochranného intervalu je obslúžené ďalšie logické zariadenie čakajúce vo fronte.
15. Ak je pokus o vytvorenie spojenia s nejakým logickým zariadením neúspešný 3-krát po sebe Počet pokusov je možné zmeniť parametrom z príkazového riadku -r., považuje sa za odpojené – stav HardError – a spojenie s ním nie je možné nadviazať po dobu nasledujúcich 5 minút Dĺžku trvania HardError stavu je možné upraviť parametrom z príkazového riadku -d.. Všetky úlohy vo fronte, ktoré mali byť vykonané na tomto zariadení, sú stornované, ako aj všetky nové úlohy po dobu trvania HardError stavu. Po uplynutí tejto lehoty je možné sa opäť pokúsiť pripojiť k zariadeniu.
16. Všetky úlohy, ktoré si vzájomne nekonkurujú, je možné vykonať paralelne vláknami príslušného ThreadPool-u. Počet vlákien v ThreadPool-e je maximálne 512 Maximálny počet vlákien je možné upraviť parametrom z príkazového riadku -t., ale dynamicky sa mení podľa aktuálnych potrieb.