Technické zadání

Tato kapitola popisuje funkční požadavky ("co to vlastně umí?") datové platformy Golemio, co se týče softwarového nástroje (aplikačního setu).

Funkční požadavky

Integrace dat z externích systémů měst a městských společností

1. Systém bude zpracovávat real time data
   1. Vystavené push API schopné zpracovat
      1. JSON data
      2. XML data
      3. Plaintext data
      4. Binární data
   2. Data na vstupním API budou validována
   3. Vstupní API bude autorizováno
      1. Na úrovni API klíče (v hlavičkách nebo těle)
      2. Na úrovni IP whitelistu
      3. Jednotlivé druhy a úrovně autorizace budou nastavitelné pro každý API endpoint (data z jednoho zdroje) zvlášť
2. Systém bude umět oboustranně komunikovat s připojenými zařízeními
   1. Volání externího ovládacího API
   2. Napojení přes websocket
3. Systém bude zpracovávat statická data a data z API / DB
   1. Pull API
      1. JSON REST API
      2. XML/SOAP API
      3. Proprietární HTTP/S API
   2. Externí FTP úložiště
      1. Stahování dat v intervalu 1 min až 1 rok
   3. Nastavitelné konfigurací (definice CRON)
4. Přijatá data budou validována a kontrolována jejich správnost, s možností nastavení operativních alertů v případě chyby
5. Systém bude zpracovávat ruční vstupy (mapové podklady, číselníky) - přímým nahráním do databáze
   1. Formát GeoJSON, JSON, CSV
6. Systém bude umožňovat automatické nahrávání do katalogu OD
   1. Týdenní, denní frekvence
7. Nad přijatými daty budou prováděny výpočty
   1. Geoprocessing, výpočet zpoždění, predikce, obohacení dat

Úložiště dat

1. V systému budou použity SQL a NoSQL databáze s možným přímým přístupem pro datové analytiky
2. Systém bude ukládat aktuální data (aktuální poloha, aktuální obsazenost)
3. Systém bude ukládat historická data (historie obsazenosti, historie polohy, historie stavu)

Datová analýza

1. Možnosti připojení nástrojů pro datovou analýzu (Grafana, PowerBI, R studio, ArcGIS Desktop, popř. jiné standardní nástroje)
2. Systém bude uchovávat přijatá raw data po různou dobu dle potřeb projektu

Webové aplikace

1. Webová aplikace interních dashboardů, dispečinku (operativního monitoringu) a administračního panelu DP, popř. využití webu Golemio pro veřejné dashboardy
   1. Zobrazení dashboardů pro veřejnost
   2. Zobrazení interních dashboardů
   3. Možnost ovládání připojených zařízení přes aplikaci dispečinku
2. Přístup skrze přihlašovací údaje k webové aplikaci určené k zobrazování specifických dashboardů
   1. Přihlašování a rozdělení přístupů k jednotlivým dashboardům dle rolí
   2. Rozdělení přístupů k jednotlivým datům na dashboardech (např. Dashboard lampy, některý uživatel vidí pouze lampy s parametrem “městská část: Praha 7”, některý uživatel všechny)
      1. Přístup na základě městské části
      2. Přístup na základě povolených ID jednotlivých záznamů
3. Aktualizace dat (nejmenší možná doba aktualizace)
   1. Pro veřejné dashboardy od 30 min
   2. Interní dashboard od 1 min
   3. Dispečerský panel od 10s
4. Webová aplikace pro administrační panel pro správu uživatelů a práv
   1. Správa uživatelů, uživatelský skupin, API přístupů (více definováno v kapitole Open API)
5. Webová aplikace pro správu API klíčů pro veřejnost
   1. Možnost zaregistrovat se
   2. Možnost vygenerovat svůj API klíč
   3. Možnost smazání API klíče
   4. Aplikace v české a anglické lokalizaci

Open API

1. Implementace výstupní gateway pro zpřístupnění dat z DP pro třetí strany (mobilní vývojáři, externí systémy)
   1. Jednotné REST API
   2. API nad relačními i dokumentovými daty
   3. Dokumentace výstupního API, vč. popisu endpointů, popisu HTTP metod a parametrů, struktury návratových dat a ukázkových dat
   4. Výstupní API bude podporovat stránkování, limitaci počtu vrácených záznamů
   5. Výstupní API bude podporovat dotaz pomocí lokace (geolokační dotaz) a řazení výsledků dle vzdálenosti od bodu
   6. Výstupní API bude podporovat filtrování výsledků dle městské části či dalších specifikovaných filtrů
   7. Výstupní API bude poskytovat historická data s parametry Od-Do (datum a čas) pro filtrování výsledků
   8. Výstupní API bude používat cachování (každý dotaz nebude znamenat dotaz do databáze)
2. Nastavení request limitů, role a oprávnění přístupu, logování přístupů
   1. Administrační panel s přehledem přístupů/využití
   2. Logování všech přístupů a generování statistik
   3. Blokace dříve poskytnutého přístupu
   4. Bude možné určovat celkový rate limit pro uživatele
   5. Nastavení oprávnění přístupů bude možné jak za základě datové sady (endpoint) tak i podle atributů v datech
   6. Nastavitelné přístupy
   7. Přístup k jednotlivým API endpointům
   8. Přístup na základě městské části
   9. Přístup na základě povolených ID jednotlivých záznamů
   10. Přístup s maximálním limitem (velikosti) dotazu
3. Automatické generování API klíčů
   1. Uživatelé musí mít možnost si sami vygenerovat svůj klíč, který bude mít výchozí hodnotu rate limitu
   2. Ověří se emailem - posílání verifikačního emailu pro aktivaci klíče

Alerting a monitoring

1. Kontrola dat
   1. V daném časovém úseku musí přijít dávka dat, jinak se odešle upozornění
   2. Periodické provolání externích zdrojů a validace schématu
   3. Ověřování hodnot vůči stanoveným pravidlům
2. Monitoring
   1. Všechny služby budou monitorované přes heartbeat
   2. Bude logováno a monitorováno počet přijatých dat (jak přijatá push data na input API, tak pull z externích API)
   3. Bude probíhat pravidelná kontrola datových zdrojů a reporting
   4. Budou sbírány logy a nastaven alerting na jakékoliv závažné chyby v aplikacích
   5. Výše zmíněné požadavky na monitoring budou mít GUI

Nefunkční požadavky

1. Dispečink a dashboardy budou dostupné jako webová aplikace s řízením přístupů
2. Administrační panel bude dostupný jako webová aplikace s řízením přístupů
3. Jednotlivé moduly řešení budou horizontálně škálovatelné - vrstva pro integraci dat, vrstva pro výstupní rozhraní, databázová vrstva, napojení na senzory
4. Moduly umožní navýšení výkonu a počtu zpracovávaných požadavků/kapacity úložiště pomocí horizontálního škálování bez zásahu do zdrojových kódů řešení
5. Jednotlivé moduly/vrstvy budou jednotlivě nahraditelné - integrace dat, výstupní rozhraní, databázová vrstva, napojení na senzory (vstupní rozhraní)
6. Řešení bude využívat systému queue (fronty) pro zajištění perzistence a synchronizace přijímaných dat/zpráv
7. Celé řešení bude možné nasadit na virtualizované architektuře VMWare
8. Jednotlivé moduly budou k nasazení využívat technologii linuxových kontejnerů (Docker)
9. Zdrojový kód jednotlivých částí řešení bude udržován v git repozitáři, nebude obsahovat citlivá data a bude připraven k publikaci jako open-source
10. Zdrojové kódy budou pokryty jednotkovými testy, které se budou automaticky spouštět před nasazením nové verze
11. Modul výstupního rozhraní a integračního rozhraní s databázovou vrstvou bude možno plnohodnotně zprovoznit samostatně bez závislosti na ostatních modulech
12. Celé řešení bude monitorovatelné standardními monitoring nástroji
13. Předpokládaný objem dat je 1 TB za dobu 3 měsíců, řešení bude dimenzováno minimálně na tento objem
14. Systém bude dimenzován na vstup 200 datových zpráv za 1s
15. Řešení bude robustní k výpadku jakéhokoliv jednoho modulu (vrstvy) aplikace po omezený čas
16. Celé řešení bude nasazené v režimu vysoké dostupnosti, odolné vůči výpadku jakéhokoliv z virtuálních strojů:
17. Systém bude provádět automatické zálohy dat z datového úložiště a ostatních modulů
18. Dostupnost služeb bude:
    • Výstupní API: 99,5
    • Databázová vrstva: 99,5
    • Dispečink: 99,5
    • Monitoring: 99,5
    • Alerting: 99,5
19. Součástí řešení je i návrh řešení Disaster recovery a kritických scénářů
20. Součástí řešení je návrh automatického zálohování, export dat pro migraci dat