====== ZTB: Projekty 2014 ======

{{:pl:ztb:ztb-projekty-lighting.pdf|Slajdy z opisem projektów}}

=====  1. Warstwa podkładu GIS =====

  * Wykorzystuje narzędzia GIS, zarządza _wszystkimi_ danymi geograficznymi.
  * Model danych do przechowywania informacji o „mapie”: ulice, budynki, drzewa, słupy, itd.
  * Wstępny wsad z [OpenStreetMap](http://www.openstreetmap.org).
  * Do rozwiązania problem synchronizacji zmian wprowadzanych lokalnie z serwerami OSM.


===== 2. Warstwa obiektów =====

Przechowuje informacje o:

  * oprawach (*fixtures*) i sterownikach (*drivers*),
  * szafach (*cabinets*) i sterownikach segmentowych (*segment controllers*),
  * słupach wykorzystanych do montażu opraw,
  * lokalizacji czujników (szczegółowe informacje odnośnie typów czujników zesłownikowane w ramach projektu 3).

Do określenia:

  * struktury danych,
  * atrybuty oraz ich wartości stałe i chwilowe -- na podstawie istniejących systemów zarządzania oświetleniem (do których Katedra posiada dostęp).



===== 3. Model danych sensorów =====

  * Określa katalog możliwych czujników.
    * np. pętle indukcyjne, czujniki ruchu, wideodetektory (kamery), czujniki oświetlenia zewnętrznego, liczniki pojazdów,
    * ale również zegar astronomiczny, ręczne sterowanie, itd.
  * Specyfikuje obszar działania sensorów poprzez dowiązanie do elementów w warstwie GIS (projekt nr 1) przynajmniej z wykorzystaniem geolokalizowanej krzywej zamkniętej.
  * Służy do specyfikacji typu dla instancji sensorów dla warstwy obiektów (projekt nr 2).



===== 4. Model wymagań  =====

Określa wymagania dla systemu dynamicznego sterowania w „idealnym” przypadku, tzn. przy założeniu, że mamy precyzyjną sensorykę.

Przykład: na drodze samochody poruszają się z prędkością 30 km/h (ok. 8,3 m/s), więc chcemy, aby „śledziła“ je plama światła o długości 60 m.

Z tego wymagania wynika decyzja: dzielimy obszar na segmenty o długości 20 m i rozświetlany będzie segment z wykrytym pojazdem oraz po jednym przed i za nim.

Definiowane elementy logiczne niezbędne do sterowania tj:
  * obszary,
  * segmenty,
  * profile oświetleniowe (tylko nazwa / ilość),
  * lampy,
  * sensory.


===== 5. Reguły sterujące =====

Moduł musi przechowywać reguły w logice predykatów, określające jaką konfigurację zaaplikować na lampach przy określonej kombinacji wartości i zdarzeń na sensorach.

<code prolog>
r('1a1b') :-                    % reguła 1a1b
    v(d=dark,L,detected=false), % wierzchołek o indeksie L typu d=dark o etykiecie detected=false
    e(d=dark,L,s,J),            % krawędź od wierzchołka d=dark o indeksie L do wierzchołka s o idneksie J
    \+ v(s,J,off),              % wierzchhołek s o indeksie J nie ma etykiety off
    e(s,J,c,_,_),               % istnieje krawędź od s o ideksie J do jakiegoś wierchołka c posiadającego jakąś etykietę
    then,                       % to
    vla(s,J,off).               % dla wierzchołka s o indeksie J ustaw etykietę na off
</code>

Bardziej zlozony przyklad reguł: {{:pl:ztb:n_gs_e_2.pl|}}

=====  6. Profile i konfiguracje =====

  * Moduł przechowuje informacje wygenerowane przez system do projektowania oświetlenia, tzn. wiąże lampy (projekt 1) z segmentami (projekt 4) i konfiguracjami, pozyskanymi z oprogramowania do obliczeń fotometrycznch.
  * Dane do modułu dostarczone będą w wyspecyfikowanym formacie danych.
  * Przykad interpretacji rekordu: "Aby uzyskać w danym segmencie normę oświetlenia ME3, przy 20% oświetleniu zewnętrznym, należy zapalić lampy L3 i L4 ze ściemnieniem 30%."

===== 7. Logowanie =====

Moduł odpowiedzialny za gromadzenie historii działania systemu, w tym:

  * zmian wartości odczytywanych z sensorów,
  * zmian parametrów życiowych lamp,
  * decyzji podejmowanych przez system sterowania,
  * komunikatów wysyłanych do urządzeń.

Moduł zadbać musi o synchronizację czasową innych modułów (tak, aby logi były ze sobą porównywalne).


=====  8. GUI =====

Grupa odpowiedzialna będzie za przygotowanie prostej aplikacji webowej, pozwalającej na odczytywanie i wpisywanie wartości do baz poszczególnych modułów funkcjonalnych.



===== 9. REST API =====

Grupa odpowiedzialna za wsparcie poszczególnych grup w przygotowaniu (tam gdzie to konieczne) API REST.



===== 10. Uwierzytelnianie i autoryzacja =====

Grupa odpowiedzialna za stworzenie modułu uwierzytelniania i autoryzacji, w tym:

  * przygotowanie bazy użytkowników,
  * przygotowanie interfejsów,
  * określenie możliwych uprawnień do poszczególnych modułów,
  * wstępne zasilenie danymi.