Slajdy z opisem projektów

• 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.

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).

• 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).

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.

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.

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

Bardziej zlozony przyklad reguł: n_gs_e_2.pl

• 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%.”

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).

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

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

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.