Jak na smart city a data?

Jedním z klíčových aspektů strategického rozvoje Smart Cities jsou koncepce a metodiky, díky kterým je možné město sjednotit. A to platí zejména u dat. Praha jako celek se skládá z 57 městských částí, desítek městských firem a příspěvkových organizací, magistrátu a mnoha dalších organizací a každý si dle vlastního uvážení může pořizovat řešení, která lze zařadit do kategorie Smart City. A tato řešení většinou, kromě svého primárního účelu, generují různá data a ve spoustě případů mají hodnotu až po propojení a doplnění s dalšími daty. Aby bylo možné data zapojit do Datové Platformy a pracovat s nimi na celoměstské úrovni, je klíčové, aby k surovým datům měl přístup primárně sám objednatel. To bývá v průběhu zadávacího řízení ovšem opomíjeno a součástí dodávky je často pouze možnost předem definovaného náhledu na data, a nikoliv přístup ke zdrojovým datům. Rozumíme tomu, že často není ani v technických možnostech objednatele Smart City řešení taková data přímo zpracovávat. A proto tuto možnost nabízíme. Pro objednatele to má tu výhodu, že nebude muset poptávat speciální vizualizační a reportingové nástroje a nemusí pak pokaždé, když bude chtít něco změnit, generovat další a další objednávky a zakázky. Pro nás to má výhodu, že budeme mít více dat k dispozici a bude tak možné město lépe a efektivněji řídit.

Níže uvádíme prozatím získané poznatky a specifikace, které mohou být promítnuty přímo do zadávacího řízení a následně do smlouvy s dodavatelem. Specifikace jsou uvedeny s ohledem na již existující řešení a zkušenosti, nicméně je vždy možné datovou strukturu rozšiřovat (přidávání čidel apod.) dle možností konkrétních řešení a požadovaných funkcionalit. V případě potřeby tvorby nové specifikace je tým Datové platformy připraven spolupracovat, stejně jako v případě potřeby úpravy na základě specifických požadavků objednatele.

A pokud máte zkušenosti, které byste rádi zařadili mezi níže uváděnou dobrou praxi, budeme rádi, když se nám ozvete. Tato doporučení budeme dále rozšiřovat.

Obecné požadavky na smluvní a zadávací dokumentaci

Vlastnictví dat

Je klíčové, aby měl objednatel kromě přístupu k datům také právo s daty libovolně nakládat. Vhodné je ujednání ve smlouvě, které stanoví, že objednatel je „vlastníkem dat“, a to ve smyslu (i) neomezeného přístupu k datům, (ii) absence podmínek, které by omezovaly objednatelovu možnost nakládání s daty a (iii) omezení práv dodavatele na nakládání s daty pro účely přesahující rámec plnění smluvního vztahu. Objednatel by si měl dále vyhradit právo zveřejňovat shromážděná data formou otevřených dat ve smyslu § 3 odst. 11 zákona č. 106/1999 Sb., o svobodném přístupu k informacím. V souladu s Usnesením vlády č. 889/2015 Sb. by měl objednatel dále požadovat, aby byl každý nový informační systém tzv. open data ready.

Legislativní změny

Smlouva by měla obsahovat ujednání, které stanoví povinnost dodavatele zabezpečit vždy soulad dodávaného řešení s aktuálně platnou legislativou, například v případě povinného vykazování vůči MHMP.

Anti Vendor Lock-In

Často opomíjenou součástí smluv, která výrazně prodražuje následný provoz ICT projektů, je ujednání zamezující vzniku Vendor Locku, tedy situace, kdy v důsledku nevhodně nastavených práv dochází k nucené vazbě objednatele na dodavatele. S tím souvisejí ujednání ohledně autorskoprávních vztahů, vedení a předání dokumentace a zdrojových kódů, migrace dat apod.

V případě získávání dat z IoT zařízení je vhodné požadovat možnost přímého napojení do zařízení skrze bezdrátovou technologii dle návrhu zhotovitele (např. LoRa, Sigfox, GSM apod.), včetně poskytnutí dokumentace. Tento požadavek zajistí možnost ovládat zařízení a stahovat z něj data bez nutnosti poplatků za infrastrukturu dodavatele.

Požadavky na SLA

Nedílnou součástí smluvní dokumentace je Service Level Agreement (SLA), tedy „smlouva o provozu a údržbě“. Zásadní je uvedení sankce při nedostupnosti rozhraní. Pokud nebude uvedena sankce na dodavatele ze strany objednatele (MČ), dostupnost není nijak vynutitelná, což může způsobit nedodržení smlouvy o spolupráci pro účely čerpání finančních prostředků z rezervy Smart Cities. Jako dostačující uvádíme dostupnost dat z rozhraní na úrovni minimálně 99,5 % za měsíc , což znamená nedostupnost dat nejvíce 3,6 hodiny v měsíci. Strukturou a obsahem SLA se detailně zabývá např. soubor best practices ITIL.

 

Příklad formulace

„Měsíční dostupnost služby v rozsahu SLA 99,5 % s možností vystavení reportu o plnění SLA (o dosažených hodnotách) v minulém měsíci. Při nedodržení maximální hodnoty SLA dle předchozího odstavce má Objednatel právo požadovat slevu za nedodržení SLA v uvedeném měsíci ve výši 5 % z měsíční ceny služby uplatněnou v následujícím měsíci.“

Požadavky na přístup k datům a příklady pro jednotlivé oblasti

Níže uvádíme podmínky pro to, aby data mohla být integrována do Datové platformy HMP. Specifikace je však natolik obecná, že je vhodná i pokud o integraci do Datové platformy HMP neuvažujete. Dále jsou uvedeny konkrétní příklady toho, co lze sledovat.

Obecná specifikace rozhraní

Klíčové je mít specifikovaný přístup k datům v podobě API. Rozhraní by mělo umožňovat export aktuálních dat skrze API rozhraní postavené na filozofii REST, implementované nad zabezpečeným protokolem HTTPS (včetně vracení stavových kódů), mělo by obsahovat standardní autentizace (OAuth, přihlašování, popř. token), výstup dat ve formátu JSON případně XML, kompletní dokumentaci API, verzování rozhraní.

Standardní řešení je rozhraní, ze kterého si objednatel stahuje data (pull). V případech, kdy dochází ke změně stavu zařízení, například naplnění koše nebo zaparkování vozidla nad senzorem, je vhodné, aby komunikace probíhala opačným směrem, tedy aby řešení dodavatele zasílalo notifikace v předem stanovené struktuře datové věty (push). Konkrétní schéma této datové věty bude navrženo společně s objednatelem v průběhu tvorby zadávací dokumentace a posléze s dodavatelem a Operátorem ICT tak, aby vyhovovalo rozhraní Datové platformy.

Měla by být specifikována dostupnost dat z rozhraní minimálně 99,5 % za měsíc.

Ukazatele/data ze zařízení mohou být zprůměrována na daný časový úsek.

Inteligentní monitorovací systém

Data budou poskytována ze zařízení/systému umožňujícího rozpoznávání událostí. Data jsou rozdělena na statické informace, které budou poskytnuty po zavedení systému a v případě, že dojde ke změně v umístění zařízení. Níže je uveden minimální rozsah požadovaných dat.

Statické informace

  • unikátní identifikátor zařízení;
  • Timestamp změny statických údajů;
  • poloha zařízení ve formátu GPS;
  • poloha zařízení jako textový popis;
  • popis/výčet funkcionality, např.: noční vidění, rozpoznávání: zbraní, podezřelých předmětů, davů, krádeží, dopravních přestupků; v co největším detailu, viz stručný popis projektu.

Real-time

Aktuální data událostí s maximálním intervalem periodicity 5 - ti minut (všechny události za daných 5 minut) ve struktuře:

  • unikátní identifikátor zařízení;
  • Timestamp;
  • typ události, viz seznam výčet funkcionalit

Statistická real-time

Aktuální data s maximálním intervalem periodicity 5 - ti minut ve struktuře:

  • unikátní identifikátor zařízení;
  • Timestamp;
  • Průměrný počet osob ve sledované lokalitě.
  • Průměrný počet vozidel ve sledované lokalitě.
  • Průměrný počet osobních vozidel ve sledované lokalitě (pokud umí systém rozpoznat).
  • Průměrný počet nákladních vozidel ve sledované lokalitě (pokud umí systém rozpoznat).
  • Průměrný počet cyklistů ve sledované lokalitě (pokud umí systém rozpoznat).

Rozhraní pro přístup k datům by mělo poskytovat historická data s minimálně sedmidenní historií, ve stejné struktuře, jako real-time data.

Parkování na základě dat mobilních operátorů

Data jsou rozdělena na statické informace, které budou poskytnuty po zavedení systému a v případě, že dojde ke změně v úseku nebo úsecích a real-time (aktuální) data. Níže je uveden minimální rozsah požadovaných dat.

Statické informace

  • unikátní identifikátor úseku;
  • Timestamp změny kapacity úseku;
  • kapacita parkovacích míst na daném úseku (s přesností 80 %, +/-10 % směrodatná odchylka).

Real-time

Aktuální data s maximálním intervalem periodicity 5 minut ve struktuře:

  • unikátní identifikátor úseku;
  • Timestamp;
  • GeoJSON úsek typ polygon podle (RFC 7946);
  • Počet obsazených parkovacích míst na daném úseku (s přesností 80 %, +/-10 % směrodatná odchylka).

Dále by mělo rozhraní pro přístup poskytovat historická data s minimálně 7denní historií ve stejné struktuře jako real-time data. Přístup k historickým datům je objednatelem nebo třetí stranou využíván jen v případě neúspěšného stažení real-time dat.

Chytré lavičky

Data jsou rozdělena na statické informace, které budou poskytnuty při instalaci a v případě přesunu zařízení, a real-time (aktuální) data.  Níže je uveden minimální rozsah požadovaných dat.

Statické informace

  • unikátní identifikátor zařízení;
  • datum instalace;
  • poloha zařízení ve formátu GPS;
  • typy a výrobci senzorů pro měřené veličiny včetně jednotky a výšky instalace nad zemí např.: (vlhkost, procenta, Honeywell HIH4030, 200cm ; teplota, celsius, STMicroelectronics LPS25H, 200cm; ….)

Real-time

Aktuální data s maximálním intervalem periodicity 10 minut k funkcionalitám, které zařízení poskytuje (např. teplota, kvalita ovzduší, vlhkost atd.), ve struktuře:

  • unikátní identifikátor zařízení;
  • Timestamp;
  • počty připojených uživatelů k WIFI;
  • indikace probíhajícího nabíjení skrze USB port/porty;
  • data z jednotlivých senzorů.

Chytré osvětlení

Rozlišujeme data o jednotlivých zařízeních jako statické informace, které budou poskytnuty při instalaci a v případě přesunu zařízení, a real-time (aktuální) data. 

Statické informace

  • unikátní identifikátor zařízení;
  • datum instalace;
  • poloha zařízení ve formátu GPS.

Real-time

Aktuální data s maximálním intervalem periodicity 10 minut k funkcionalitám, které zařízení poskytuje (např. teplota, kvalita ovzduší, vlhkost atd.), ve struktuře:

  • unikátní identifikátor zařízení;
  • Timestamp;
  • data z jednotlivých senzorů či případně z nabíjecí stanice (je-li součástí).

Dále by mělo rozhraní pro přístup poskytovat historická data s minimálně 14denní historií ve stejné struktuře jako real-time data. Přístup k historickým datům bude objednatelem nebo třetí stranou využíván jen v případě neúspěšného stažení real-time dat.

Chytrý přechod

Rozlišujeme data o jednotlivých zařízeních jako statické informace, které budou poskytnuty při instalaci, a real-time (aktuální) data.  Níže je uveden minimální rozsah požadovaných dat.

Statické informace

  • unikátní identifikátor zařízení;
  • datum instalace;
  • poloha zařízení ve formátu GPS.

Real-time

Aktuální data s maximálním intervalem periodicity 10 minut k funkcionalitám, které zařízení poskytuje (např. počet chodců a průjezdů, teplota, kvalita ovzduší, vlhkost atd.), ve struktuře:

  • unikátní identifikátor zařízení;
  • Timestamp;
  • počet chodců;
  • počet průjezdu vozidel;
  • data z jednotlivých senzorů.

Dále bude rozhraní pro přístup poskytovat historická data s minimálně 14denní historií ve stejné struktuře jako real-time data. Přístup k historickým datům bude objednatelem nebo třetí stranou využíván jen v případě neúspěšného stažení real-time dat.

Kompresní koše

Rozlišujeme data o jednotlivých zařízeních jako statické informace, které budou poskytnuty při instalaci, a real-time (aktuální) data.  Níže je uveden minimální rozsah požadovaných dat.

Statické informace:

  • unikátní identifikátor zařízení;
  • datum instalace;
  • poloha zařízení ve formátu GPS;
  • lokace (umístění), např. u vchodu do parku, atd.

Real-time

Aktuální data s maximálním intervalem periodicity 5 minut k funkcionalitám, které zařízení poskytuje (zaplněnost, technický stav atd.), ve struktuře:

  • unikátní identifikátor zařízení;
  • Timestamp;
  • zaplněnost v % (alespoň 2 úrovně);
  • technický stav;
  • data z jednotlivých senzorů;
  • lokace (umístění), např. u vchodu do parku, atd.

Dále bude rozhraní pro přístup poskytovat historická data s minimálně 14denní historií ve stejné struktuře jako real-time data. Přístup k historickým datům bude objednatelem nebo třetí stranou využíván jen v případě neúspěšného stažení real-time dat.

Z důvodu omezení dotazování se na stav koše lze po dohodě dodavatele s Operátorem ICT zasílat datovou větu skrze API ve struktuře real-time dat do Datové platformy. Konkrétní schéma této datové věty bude navrženo společně s objednatelem v průběhu tvorby zadávací dokumentace a posléze s dodavatelem a Operátorem ICT.