Wyniki 1-5 spośród 5 dla zapytania: authorDesc:"Damian Duda"

STANDARD STANAG 5066 JAKO ELEMENT WARSTWY TRANSPORTOWEJ DYNAMICZNEJ ARCHITEKTURY SYSTEMÓW TAKTYCZNYCH - TACTICS DOI:10.15199/59.2017.8-9.19


  Potencjalna różnorodność technologii radiowych (VHF, UHF, WiFi, SAT itp.) występująca w ramach jednego systemu łączności taktycznej prowadzi do konieczności stosowania dedykowanych protokołów transportowych dla konkretnych segmentów sieci taktycznej. Architektura TACTICS [1] [2] proponuje wykorzystanie potencjalnie różnych protokołów transportowych w ramach danej transmisji e2e (ang. end to end) w zależności od jakości (QoS) segmentu sieci po którym wiadomość jest przesyłana np. : (a) DTN (ang. Disruption Tolerant Network) np. IBR-DTN, (b) protokół dla komunikacji wąskopasmowej HF np. STANAG 5066 [3], czy (c) protokół UDP dla połączeń bez-sesyjnych. Niniejszy artykuł pokazuje wyniki badań rozwiązania transmisji danych STANAG 5066 w środowisku laboratoryjnym, zapewniającym emulację łączy UHF, VHF i SATCOM oraz przedstawia wybrane wyzwania 1 Praca realizowana w ramach projektu kat. B współfinansowanego przez Europejską Agencję Obrony pk. TACTICS. 2 oprogramowanie RDC 9000 WMS w.3.0 OBR CTM S.A. związane ze stosowaniem różnorodnych mechanizmów transportowych w ramach jednego systemu. 2. ŚRODOWISKO SYMULACYNE 2.1. Środowisko symulacyjne Badania symulacyjne wykonano w zestawie testowym wykorzystującym maszyny wirtualne z oprogramowaniem funkcjonalnym i bazowym STANAG 5066 - Rys.1. Maszyny wirtualne A i B, poprzez zdefiniowane interfejsy sieciowe, dołączone były do fizycznych urządzeń zapewniających emulację łącza radiowego oraz synchronizację ich zegarów systemowych. Jako emulator łącza wykorzystano urządzenie LANforge ICE WAN Emulator. Usługę synchronizacji zapewniał serwer NTP Galleon 6000. Routery Rtr1 i Rtr2 to routery programowe wykorzystujące system OpenBSD. Machine A (virtual) 10.50.10.151 (st: 1.1.1.1) Stanag 5066 SIS Server <> (3) Radio Link Emulator (5b) Stanag 5066 SIS Client <> (2) Application <> (1) Wireshark <> (4) Ethernet (I1) Rtr1 (5a) [...]

USŁUGA TRANSLACJI NAZW DLA APLIKACJI W SIECI TAKTYCZNEJ ZORIENTOWANEJ NA USŁUGI - KONCEPCJA I REALIZACJA DOI:10.15199/59.2017.8-9.42


  System nazw domenowych (ang. Domain Name Service, DNS), to złożony system serwerów, protokołów komunikacyjnych oraz usługa, która umożliwia przekształcanie mnemonicznych (łatwych do przyswojenia przez człowieka) nazw urządzeń i usług dołączonych do Internetu na adresy wymagane przez urządzenia sieciowe. Podobne zastosowanie DNS ma miejsce w sieciach * Prezentowane wyniki uzyskane w ramach prac projektu TACTICS EDA B 0980 GP taktycznych IP, gdzie również bardziej praktyczne jest posługiwanie się nazwami niż adresami numerycznymi poszczególnych węzłów. Dostępnych jest wiele implementacji internetowej usługi translacji nazw - zarówno komercyjnych, jak i otwartych (ang. open source). Reprezentatywnymi przykładami są: oprogramowanie BIND (aktualnie w wersji 9), Microsoft DNS, CISCO Network Registrar, Unbound, NSD i wiele innych. Oprogramowanie to zapewnia funkcje zebrane w szeregu dokumentów RFC, mających na celu zapewnienie jednolitego interfejsu dla tej usługi i interoperacyjności między różnymi producentami oprogramowania DNS [6] i powiązane RFC. Zgodność ze specyfikacją IETF może być zarówno zaletą, jak i wadą: w przypadku sieci komercyjnych pozwala na dobór implementacji na podstawie wymagań funkcjonalnych, bez zbytniego przywiązania do producenta danego oprogramowania, a w kontekście sieci taktycznych oznacza mniejszą elastyczność w dostosowaniu danego oprogramowania do indywidualnych potrzeb tego środowiska. W ramach prowadzonego projektu TACTICS wymagania w stosunku do usługi translacji nazw odnosiły się do obsługi mobilności węzłów i wielokrotnego dowiązania do sieci (tzw. multi-homing) oraz dopasowania do architektury zorientowanej na usługi (ang. Service Oriented Architecture, SOA). Z tego też względu została zaproponowana nowa usługa translacji nazw - TACTICS Name Service (TNS), zdefiniowana jako komponent z interfejsem usługi, gotowym do wykorzystania przez pozostałe usługi funkcjonalne w ramach systemu TACTI[...]

SPOSÓB WSPÓŁPRACY SYSTEMU INSIGMA Z KRAJOWYM SYSTEMEM POWIADAMIANIA RATUNKOWEGO DOI:10.15199/59.2015.4.13


  W artykule opisano możliwość współpracy systemu INSIGMA z krajowym Systemem Powiadamiania Ratunkowego. INSIGMA 1) jest złożonym systemem informacyjnym do celów kompleksowej detekcji i identyfikacji zagrożeń oraz monitoringu i identyfikacji obiektów ruchomych. Obszary tematyczne zadań projektu pokrywają się w istotnym zakresie z dziedzinami Systemu Powiadamiania Ratunkowego, zatem współpraca obu systemów i współdzielenie przez nie informacji mogą znacząco poprawić bezpieczeństwo obywateli. 1. WSTĘP Bezpieczeństwo obywateli jest ważnym filarem nowoczesnego państwa i jednym z największych priorytetów UE; ma zarazem szeroki, wieloaspektowy wymiar - np. w sytuacjach kryzysowych silnie zależy od działania systemu ratownictwa. Funkcjonowanie tego systemu jest z kolei uwarunkowane obowiązującymi procedurami i skutecznością powiadamiania o zdarzeniach stanowiących zagrożenie dla zdrowia i życia ludzi. Obsługa zgłoszeń alarmowych w krajach UE - w tym kierowanych na numer 112 oraz przyjmowanych przez systemy E112 i eCall - jest uregulowana odpowiednimi dyrektywami, komunikatami i zaleceniami [1…4]. Ustawa o Systemie Powiadamiania Ratunkowego (SPR), obowiązująca od 1 stycznia 2014 r. [5], w sposób kompleksowy normuje zagadnienia z zakresu powiadamiania ratunkowego, opierając SPR na Centrach Powiadamiania Ratunkowego (CPR). Podstawowym zadaniem SPR jest obsługa zgłoszeń alarmowych kierowanych do numerów 112 i 9xx. CPR-y wykonujące zadania SPR współpracują z Policją, Państwową Strażą Pożarną (PSP), dysponentami zespołów Państwowego Ratownictwa Medycznego (PRM) oraz dodatkowo z innymi podmiotami, których zadaniem jest ochrona życia, zdrowia, bezpieczeństwa i porządku publicznego, mienia lub środowiska (np. staż gminna). 2. SYSTEM POWIADAMIANIA RATUNKOWEGO SPR jest częścią Krajowego Systemu Ratownictwa (medycznego - PRM; technicznego - PSP; porządkowego - Policja itd.). Schemat funkcjonalny SPR przedstawiono na rys. 1. Zadani[...]

SPRAWNOŚĆ OBSŁUGI ZGŁOSZEŃ W SYSTEMIE INSIGMA*) POPRZEZ INFRASTRUKTURĘ DOSTĘPOWĄ O OGRANICZONEJ PRZEPUSTOWOŚCI DOI:10.15199/59.2015.8-9.93


  W referacie zamieszczono wyniki testów Systemu Obsługi Zgłoszeń o Zdarzeniach i Zagrożeniach (SOZZ) w warunkach zmniejszonej przepustowości łącza dostępowego. Referat ten jest próbą odpowiedzi na pytania dotyczące sprawności przekazu informacji o zdarzeniach w środowisku ogólnie określanym jako zdegradowane. Uzyskane wyniki wskazują na możliwości realizacji obsługi zgłoszeń z pewnymi ograniczeniami. Jako zasadniczy protokół do przekazu informacji o zdarzeniach zastosowany jest standardowy protokół SIP. 1. WSTĘP Zadaniem Systemu Obsługi Zgłoszeń o Zdarzeniach i Zagrożeniach jest dostarczanie danych dla podsystemu analizy ruchu drogowego w systemie INSIGMA. Obsługa zgłoszeń rozumiana jest tu jako zespół czynności wykonywanych w celu przyjęcia, przetworzenia i udostępnienia informacji o zdarzeniach i zagrożeniach w ruchu drogowym, napływających do systemu. Zgłaszane zdarzenia mogą mieć wpływ na jakość obsługi ruchu drogowego w aglomeracjach miejskich ale przede wszystkim wykorzystywane są do uzyskiwania informacji i monitorowania obszarów nieobjętych zasięgiem sensorów systemu INSIGMA. System SOZZ zapewnia tę funkcjonalność poprzez wykorzystanie tzw. sensorów mobilnych, którymi są różnego typu terminale przenośne - np. PDA, smartfony i inne urządzenia wyposażone w aplikację umożliwiającą zgłaszanie zaobserwowanych zagrożeń, wypadków czy innych zdarzeń mających wpływ na bezpieczeństwo ruchu drogowego. Jednym z problemów, które należało rozwiązać było zapewnienie możliwie krótkiego czasu przekazywania informacji o zdarzeniach drogowych do systemu INSIGMA. Zagadnienie to jest m.in. jednym z elementów sprawnego działania wszelkiego rodzaju służb ratowniczych (np. funkcjonujących w ramach Krajowego Systemu Ratownictwa). Znane są nowe techniki powiadamiania o zdarzeniach w sposób automatyczny (np. system eCall [13]), mimo to często jedynym źródłem informacji okazuje się być człowiek wyposażony w terminal przenośny (np. telefo[...]

TACTICS - ARCHITEKTURA USŁUGOWA DLA SYSTEMÓW TAKTYCZNYCH - WYNIKI PROJEKTU DOI:10.15199/59.2017.8-9.21


  Architektura systemu C4I (ang. Command, Control, Communications, Computers and Intelligence) dla działań sieciocentrycznych różni się w znaczący sposób od architektur dotychczas stosowanych. Bazuje ona na rozwiązaniach umożliwiających łączenie |współpracujących domen systemowych oraz współdzielenie informacji i wiedzy o polu walki. Efektywność procesu dowodzenia często zależy od jakości i wiarygodności informacji, na bazie których dowódca podejmuje decyzję oraz od czasu, w jakim jest w stanie te informacje otrzymać. Niezwykle istotne jest więc zastosowanie mechanizmów pozwalających na tworzenie świadomości sytuacyjnej na wszystkich szczeblach dowodzenia oraz zapewniających synchronizację współpracujących jednostek. Architektura tego typu powinna być architekturą otwartą, pozwalającą na interoperacyjność, skalowalną, umożliwiającą efektywną pracę w różnego typu konfiguracjach systemu, zapewniać pełną dostępność źródeł danych, a także rozproszone ich działanie i utrzymanie. Odpowiedzią na te potrzeby oraz wymagania jest zastosowanie architektury zorientowanej usługowo SOA (ang. Service Oriented Architecture). Jest ona architekturą rekomendowaną przez NATO w Studium Wykonalności NEC (NNEC FS [1]), bazującą na modelu Internetu oraz podstawą budowy infrastruktury teleinformatycznej NATO, w tym sieci FMN (ang. Federated Mission Network). Podstawową cechą systemów zbudowanych na bazie SOA jest orientacja usługowa. Wszystkie funkcje systemu, nawet te, które wcześniej były postrzegane, jako część infrastruktury (np. bezpieczeństwo, zapewnienie jakości usług) oraz te, które zazwyczaj należą do dedykowanych aplikacji systemu informatycznego (np. podawanie czasu, kalkulacje, itp.), a także standardowe usługi telekomunikacyjne (np. wideo, głos), widziane są w SOA, jako usługi i udostępniane użytkownikom jako funkcje rozproszone. Podejście to umożliwia tworzenie modułowych systemów, dostosowanych do aktualnych wymagań, wykorzystywa[...]

 Strona 1