Zarządzanie komunikacją w sytuacjach awaryjnych
Jednym z kluczowych zadań systemów utrzymania ruchu w zakładach produkcyjnych, transportowych, jednostkach służby zdrowia – a więc wszędzie tam, gdzie istnieją służby utrzymania ruchu i funkcja dyspozytora – jest zapewnienie szybkiej, sprawnej i skutecznej obsługi łączności w sytuacjach awaryjnych. Do sytuacji takich zaliczyć można np. zatrzymanie urządzenia, pożar, wypadek, czy jakiekolwiek inne zdarzenie skutkujące koniecznością reorganizacji ruchu, szczególnie na potrzeby akcji ratowniczej.
Najważniejszym zadaniem dyspozytora jest szybkie i skuteczne powiadomienie o zdarzeniu wszystkich osób przewidzianych w procedurze postępowania w sytuacji awaryjnej. Kluczowe jest także uzyskanie potwierdzenia, że wszystkie te osoby komunikat otrzymały. Oczywiste jest, że dostarczenie komunikatu i uzyskanie potwierdzenia jego otrzymania powinno odbyć się w jak najkrótszym czasie.
Automatyzacja tego procesu pozwala dyspozytorowi zoptymalizować ten czas i zająć się koordynacją pozostałych działań przewidzianych przez procedurę, podczas gdy proces powiadamiania automatycznie postępuje w tle.
Jak zaoszczędzić czas, odciążyć dyspozytora i zagwarantować skuteczność powiadamiania w nagłej sytuacji awaryjnej?
DiAlert to rozwiązanie, które stworzyliśmy dzięki połączeniu znajomości specyfiki potrzeb komunikacyjnych zakładów, w których istnieje ryzyko wystąpienia nagłych sytuacji awaryjnych, oraz wiedzy i doświadczenia w obszarze rozwiązań telekomunikacyjnych. DiAlert usprawnia pracę dyspozytora, eliminując konieczność manualnej obsługi łączności w sytuacji awaryjnej.
DiAlert - zasada działania:
- Dyspozytor podejmuje decyzję o rozpoczęciu akcji ratowniczej.
- Dyspozytor loguje się do aplikacji i wybiera scenariusz, który odpowiada zdarzeniu w odpowiedniej lokalizacji.
- Aplikacja dzwoni do zdefiniowanych grup użytkowników, uwzględniając zależności służbowe oraz ich dostępność.
- Odbiorca dostaje informację o rodzaju i lokalizacji zdarzenia oraz prośbę o potwierdzenie.
- Dyspozytor obserwuje postęp statusów powiadomień on-line.
- Po zakończeniu akcji dostępny jest raport ze szczegółami właściwości powiadomień.
Automatyzacja procesu powiadamiania
Proces powiadamiania jest całkowicie zautomatyzowany. W zależności od rodzaju sytuacji alarmowych można zdefiniować wiele różnych planów powiadamiania, i w konkretnej sytuacji alarmowej wyzwalać odpowiedni z nich (decyduje dyspozytor). Plan powiadamiania określa grupy abonentów, które mają być powiadomione, wybór komunikatu słownego oraz abonentów alternatywnych.
Skuteczne dostarczenie informacji
Telefoniczne powiadomienie abonentów jest interaktywne - przebieg procesu oraz jego skuteczność są w czasie rzeczywistym dokumentowane i prezentowane dyspozytorowi. Ma on zatem możliwość stwierdzić, których osób czy służb nie udało się powiadomić. Służy do tego graficzny interfejs użytkownika w standardowej przeglądarce internetowej.
Istnieje możliwość zdefiniowania kalendarza planowych nieobecności abonentów, którzy tym samym będą automatycznie pomijani w kolejce powiadamiania w dniu swojej nieobecności.
Aby abonenci mogli potwierdzić odebranie informacji, można skonfigurować funkcję obligatoryjnego potwierdzenia ustalonym kodem numerycznym.
Szczegółowe raporty
Po zakończeniu kampanii powiadamiania dostępne są raporty z ich przebiegu, informujące o skuteczności powiadamiania poszczególnych abonentów. Raporty obejmują: numer telefonu, liczba podejmowanych prób skomunikowania się z danym abonentem oraz czas, w jakim odebrano połączenie. Można też w prosty sposób wygenerować raport dla listy abonentów, z którymi nie udało się skomunikować w czasie przebiegu kampanii.
Zróżnicowane uprawnienia
Dostęp do niektórych funkcjonalności w interfejsie użytkownika (operatora), np. możliwość definiowania kampanii, zmiany planów niedostępności czy możliwość wyzwalania kampanii, może być ograniczany przez zróżnicowanie typu konta użytkownika, które jest chronione hasłem.
DiAlert - OPIS TECHNICZNY
DiAlert składa się z komponentów umożliwiających sprawne telefoniczne powiadamianie wielu abonentów (np. pracowników odpowiednich służb) o zaistniałych zdarzeniach oraz otrzymanie informacji o skuteczności powiadomienia.
Serwer HTTP
Serwer HTTP zapewnia graficzny interfejs użytkownika i obsługuje żądania przeglądarki internetowej operatora, który kieruje wyzwalaniem kampanii powiadamiania.
Operator, używając ustalonego adresu URL, ma możliwość interaktywnej komunikacji z usługą automatu powiadamiającego, przygotowywania kampanii powiadamiających oraz wprowadzania i edycji danych potrzebnych do definiowania tych kampanii.
Do budowy serwera wykorzystano technologię ASP.NET MVC. Aplikacja pracuje na serwerze Microsoft IIS i komunikuje się z resztą komponentów za pomocą komponentu bazy danych. Zaimplementowano kilkadziesiąt tzw. kontrolerów MVC, odpowiedzialnych za działanie poszczególnych segmentów interfejsu użytkownika, np. CampaignController – odpowiadający za akcje związane z przesłaniem sygnału sterującego stanem kampanii, AbsenceReasonController – odpowiadający za edycję okresów niedostępności abonenta, CallGroupController – odpowiadający za sterowanie przynależnością abonentów do powiadamianych przedstawicieli grupowych.
Zastosowana technologia sprawia, że składniki są łatwo testowalne, a system jest otwarty na opcje rozbudowy.
Usługa automatu (DiAlertService)
Usługa ta jest instancją silnika (DiAlertEngine) automatyzującego wykonywanie połączeń do abonentów poprzez polecenia wysyłane do centrali (PBX). Analizuje ona również stan tych połączeń oraz potwierdzenia odebrania wiadomości (IVR) za pośrednictwem komponentu bazy danych. Sterowanie centralą odbywa się za pośrednictwem interfejsów udostępnianych przez Avaya CTI Server oraz AES (Avaya Aura® Application Enablement Services ).
Do analizy sygnałów wysyłanych z centrali i przetworzenia ich na transformację stanu powiadamiania reprezentantów grup powiadamiania zaimplementowano rozbudowaną maszynę stanową. Oprócz interfejsu z komponentem bazy danych (DiAlertDAL) i sterowania centralą (CisServerConnector) posiada ona interfejs do koncentratora zdarzeń GUI (HubClient), umożliwiającego automatyczną aktualizację interfejsu operatora.
Baza danych
Komponent bazy danych umożliwia przechowywanie stanu kampanii powiadamiania oraz danych dla komponentu automatu oraz serwera HTTP. Dostęp do bazy zrealizowano w technologii ORM (object-relational mapper) za pomocą Entity Framework, umożliwiającej obiektowy dostęp do relacyjnej bazy danych. Możliwy jest jednakże jednoczesny bezpośredni dostęp do bazy (SQL), co wykorzystano do zapisywania w niej informacji z systemu IVR.
Standardowo bazą wykorzystywaną przez Entity Framework jest baza z rodziny Microsoft SQL Server i taką też zastosowano w rozwiązaniu. Ścieżki z parametrami dostępu do bazy danych znajdują się w plikach konfiguracyjnych każdego komponentu wymagającego dostępu do bazy.
Koncentrator zdarzeń dla GUI
Koncentrator zdarzeń jest komponentem zapewniającym interaktywność interfejsu użytkownika i rekompensującym brak dwustronności kanału w protokole HTTP, który jest wykorzystywany przez przeglądarki.
Źródłem sygnałów zmieniających obiekty w GUI jest usługa automatu. Aktualizuje ona np. widoczny w przeglądarce pasek postępu kampanii powiadamiającej, zwalniając operatora od cyklicznego odświeżania witryny.
Komponent zaimplementowano w technologii ASP.NET MVC, a do zapewnienia dynamicznej aktualizacji witryny użyto mechanizmu WebSocket. Interfejs wejściowy (HubClient) wykorzystuje protokół HTTP.
Avaya CTI Server
Platforma middleware udostępniająca wybrane funkcje systemu centralowego dla aplikacji zewnętrznych.
AES
AES jest interfejsem wykorzystywanym w łańcuchu sterowania centralą przez usługę automatu. AES wykorzystuje TSAPI do komunikacji z PBX, a udostępnia JTAPI, który wykorzystano w tym rozwiązaniu.
PBX/IVR
Centrala PBX komunikuje się z IVR za pomocą interfejsu LINK CTI.