Category Archives: praca magisterska

prezentowana praca jest pracą magisterską

Migracja usługowa do sieci NGN

W chwili obecnej można stwierdzić, iż na rynku telekomunikacyjnym dokonuje się proces migracji sieci operatorów do sieci typu NGN. Oczywiście jest to długotrwały proces, w którym istotne jest zachowanie ciągłości usługowej w ofercie operatora. Oznacza to, iż jeżeli docelową siecią operatora będzie sieć NGN, konieczne jest w pierwszej kolejności zapewnienie w tej sieci wszystkich usług świadczonych do tej pory w tradycyjnych sieciach telefonicznych. Dopiero wówczas można rozważać usługi w pełni wykorzystujące możliwości „nowej” architektury sieciowej.

Etapy migracji usługowej do sieci NGN można zatem ująć w dwóch punktach:

  • Emulacja usług klasycznych – „przeniesienie” do sieci NGN wszystkich usług realizowanych w sieciach typu PSTN/ISDN
  • Rozwój usług o wartości dodanej

Opisane podejście jest prezentowane przez organizację standaryzacyjną TISPAN , gdzie w specyfikacji NGN Release 1 zdefiniowano system PES – PSTN/ISDN Emulation Subsystem ([51], [52]). Zadaniem systemu PES jest właśnie emulacja klasycznych usług sieci telefonicznej w ramach architektury NGN opisanej przez TISPAN.

W odniesieniu do rozważań związanych z usługami multimedialnymi, należy podkreślić, iż w kontekście migracji usługowej do NGN kluczowe jest zapewnienie niezbędnych funkcjonalności multimedialnych. Na potrzeby emulacji klasycznych usług PSTN/ISDN do grupy tych funkcjonalności zaliczyć można odtwarzanie zapowiedzi oraz interakcję z abonentem czy połączenia konferencyjne. Jak wspomniano, wszystkie takie funkcjonalności są dostarczane przez serwer mediów. Zgodnie z koncepcją wysuniętą przez ciała standaryzacyjne, serwer ten zastępuje w sieci NGN wszystkie tradycyjne systemy, jak IVR, centrale SSP z modułami Intelligent Peripheral, a także mostki audio- / videokonferencyjne.

Ilustruje to poniższy rysunek: [1] [2]

Rys. 1 Migracja funkcjonalności multimedialnej z sieci PSTN/ISDN do sieci NGN

Schowek01Oczywiście migracja odnosi się również do sieci komórkowych(2G), gdzie obecnie wykorzystuje się dedykowane systemy zapewniające tylko jedną grupę funkcjonalności multimedialnych na potrzeby konkretnej usługi.

Serwer mediów, jako część architektury NGN opartej na koncepcji IMS[3], staje się zatem uniwersalnym zasobem sieciowym, który zastępuje dotychczasowe rozwiązania i którego różnorodne funkcjonalności są wykorzystywane do symulacji klasycznych jak i realizacji „nowych” usług multimedialnych.

W tym kontekście kluczowym zagadnieniem jest problem sterowania pracą serwera mediów i jego interakcją z innymi modułami sieci. Przyjęty dla sieci V OIP wzorzec architektoniczny[4] zakłada, iż sterowanie to odbywa się z poziomu aplikacji usługowej zlokalizowanej w module Application Server (serwer aplikacji). Różna może być relacja, jaką poprzez wymianę sygnalizacji nawiązują moduły AS i MS, co znacząco wpływa na kształt logiki usługowej i nierzadko implikuje zastosowanie dedykowanych mechanizmów. Ponadto, nierozstrzygniętą w standaryzacji kwestię stanowi problem odwzorowania funkcji serwera mediów na wiadomości protokołów sygnalizacyjnych służących do komunikacji z tym modułem.

Okazuje się również, że MS jest niekiedy postrzegany jako moduł pracujący na styku sieci z komutacją kanałów i sieci pakietowej.

Wobec takiego stanu rzeczy istnieje wyraźna konieczność uporządkowania wiedzy w obrębie omawianej tematyki.

—

[1]  Telecoms & Internet converged Services & Protocols for Advanced Networks – ciało standaryzacyjne w ramach ETSI, które ma na celu opracowanie architektury łączacej sieci stacjonarne z komutacją kanałów z siecią Internet. Pierwsza wersja specyfikacji takiej architektury nosi nazwę TISPAN Release 1 i bazuje na architekturze 3GPP IMS.

[2] Pierwsza wersja specyfikacji sieci NGN

[3] Patrz też rozdziały 4.2 oraz 5.3.

[4]  Sieć NGN jest siecią opartą na technologii V2OIP, patrz też rozdział 4.3.

[51] TISPAN DES/TISPAN-02019-NGN-R1 “PSTN/ISDN Emulation Sub-system (PES); Functional architecture“, Marzec 2006

[52] TISPAN DTS/TISPAN-03044-NGN-R1 „ IMS-based PSTN/ISDN Emulation Stage 3 specification”, Maj 2006

Architektura funkcjonalna i interfejsy sieciowe modułu MS/MRF

Architektura funkcjonalna i interfejsy MRF wg ETSI

Rys. 6 Architektura funkcjonalna MRF wg ETSI.

1-1

Powyższy rysunek przedstawia architekturę funkcjonalną bloku MRF wg ETSI ([39], [38];.

Wyróżnione na rysunku interfejsy zestawiono w poniższej tabeli:

Nazwa interfejsu Protokół w ramach interfej su Opis
Mr SIP + dodatkowy protokół Jest to interfejs pomiędzy MRF a serwerem S-CSCF.

Służy do sterowania pracą MRFC za pomocą protokołu SIP, przez aplikację usługową zlokalizowaną na serwerze aplikacji (AS). S-CSCF pracuje tutaj jako element routujący wiadomości pomiędzy serwerem aplikacji a modułem MRF51. Funkcjonalność         multimedialna serwera mediów wykraczająca poza standardowe mechanizmy SIP jest kontrolowana poprzez dodatkowy protokół przenoszony w polu SDP.52
Mp H.248 / Megaco Interfejs do sterowania blokiem MRFP przez MRFC. Interfejs ten powinien wspierać w pełni standard H.248 ([39]), ponadto umożliwiać późniejsze wprowadzanie rozszerzeń,jeśli zostaną zdefiniowane.

Styk Mp jest wykorzystywany tylko w przypadku, gdy implementacja MRF zakłada funkcjonalną separację bloków MRFP i MRFC. Wówczas możliwe jest aby jeden MRFC zarządzał pracą kilku bloków MRFP.

W sytuacji, gdy MRF stanowi jeden moduł funkcjonalny, interfejs Mp nie jest implementowany i nie wyróżnia się bloków MRFP i MRFC. Szczegółowe wymagania funkcjonalne dla styku Mp (listę obowiązkowych i opcjonalnych funkcjonalności) zdefiniowano w [42], specyfikację protokołu na tym styku opisano w [43].
51  Patrz rozdział 6.

52  ETSI nie określiło jednoznacznie dodatkowego protokołu na styku Mr. W rozdziale 7 niniejszej pracy zawarto analizę protokołów możliwych do wprowadzenia na tym styku.
Mb RTP Zdefiniowany w [38]jako interfejs do usług sieciowych IPv6, w tym usług transportowych.

W rzeczywistych implementacjach modułu MRF wykorzystywany jest transport w ramach sieci z adresacją IPv4.

W ramach tego interfejsu w pakietach protokołu RTP transportowane są strumienie multimedialne.
Sr HTTP Interfejs zdefiniowany w [40]. Umożliwia pobieranie różnych dokumentów przez MRFC (np. pliki ze skryptami VXML) w ramach delegacyjnego modelu sterowania modułem MS.[1] W tym celu wykorzystuje się protokół HTTP.
Cr HTTP

TCP/SCP

 Interfejs zdefiniowany w [40] na potrzeby protokolarnego modelu sterowania serwerem mediów z wykorzystaniemdedykowanego kanału sterowania. Przesyłane są tutaj wiadomości sterujące blokiem MRFC (Jako protokół transportowy ETSI zaleca TCP/SCTP).

Interfejs umożliwia również pobieranie przez MRFC różnych dokumentów z sieci (np. pliki ze skryptami VXML)[2] – w tym celu wykorzystywany jest protokół HTTP.
Rf DIAMETER Interfejs do przesyłania informacji taryfikacyjnej w ramach off-line charging w architekturze IMS[3].
Ro DIAMETER Interfejs do przesyłania informacji taryfikacyjnej w ramach on-line charging w architekturze IMS[4].
Tabela 1 Interfejsy modułu MRF wg ETSI

Architektura funkcjonalna i interfejsy serwera mediów w architekturze V2OIP

Jeżeli blok MS nie jest rozpatrywany w kontekście sieci IMS, wówczas architekturę funkcjonalną oraz interfejsy można przedstawić następująco:

Rys. 7 Ogólna architektura funkcjonalna i interfejsy serwera mediów

2Na rysunku wyróżniono następujące warstwy funkcjonalne:

  • Warstwa sterowania

Do zadań tej warstwy należy:

o komunikacja z otoczeniem poprzez protokoły sieciowe

  • SIP – komunikacja z serwerem aplikacji, który korzysta z zasobów MS na potrzeby aplikacji usługowych
  • DIAMETER – przesyłanie danych taryfikacyjnych do systemów bilingowych na potrzeby mechanizmu chargingu
  • HTTP – pobieranie dokumentów, plików audio/video na potrzeby konkretnych operacji niższych warstw MS
  • TCP/SCTP – obsługa wymiany wiadomości protokołu sterowania serwerem mediów [5]

o Zarządzanie pracą dwóch niższych warstw na podstawie logiki usługi, która korzysta z zasobów MS

o Zarządzanie zasobami operacyjnymi MS – przydzielanie zasobów do poszczególnych operacji celem obsłużenia przychodzących żądań. Zasoby zależą od fizycznej implementacji MS. W razie braku zasobów na obsłużenie danego żądania, serwer mediów wysyła odpowiedź opisującą zaistniały problem.

  • Warstwa przetwarzania sygnałów

W tej warstwie MS wykonuje wszelkie operacje na sygnałach cyfrowych (przetwarzanie sygnałów, syntetyzowanie, miksowanie etc)

  • Warstwa transportowa

Jest to warstwa odpowiedzialna za wysyłanie/odbieranie strumieni multimedialnych z wykorzystaniem protokołu RTP.

Na rysunku pominięto interfejsy pomiędzy poszczególnymi warstwami. MS jest tutaj rozpatrywany jako jeden blok funkcjonalny . Wewnętrzne mechanizmy MS są nieistotne z punktu widzenia realizacji usług multimedialnych.

Istotne jest natomiast, aby interfejsy adresowały wszystkie funkcje MS. Protokoły wspierane w ramach przedstawionej na powyższym rysunku generycznej architektury serwera mediów dla sieci V OIP są identyczne z protokołami wymienionymi przez ETSI dla MRF. Zbieżność ta wynika z faktu, iż na rynku telekomunikacyjnym serwery oferujące funkcjonalność MS obecne były zanim wyklarowała się idea IMS. MRF stanowi zatem abstrakcję MS w ramach koncepcji IMS.

Porównanie architektury MS i MRF

Potwierdzeniem tezy, iż nie jest błędem zamienne stosowanie terminów MS i MRF na określenie tego samego bloku funkcjonalnego, jest porównanie przedstawionych wyżej architektur funkcjonalnych. Ilustruje to poniższy rysunek: [6]

Rys. 8 Zestawienie architektury MS i MRF

3Jeżeli MS jest postrzegany jako blok MRF, wówczas można mówić o interfejsie pomiędzy warstwą sterującą a warstwami przetwarzania sygnałów i transportową, w postaci protokołu H.248 / MEGACO.

Serwer mediów typu I

W sytuacji gdy MS pełni następujący zbiór funkcji:

  • Operacje na sygnałach cyfrowych audio/video
  • Transkodowanie
  • Odtwarzanie zapowiedzi, plików audio/video, pobieranie cyfr i symboli DTMF
  • Rejestrowanie strumieni audio / video (nagrywanie głosu, obrazu, Lawful Interception)
  • Miksowanie strumieni na potrzeby prostych konferencji (trójstronnych połączeń)

wówczas można mówić o tzw. serwerze mediów typu I (MS typu I). Jego architekturę przedstawia rysunek:

Rys. 9 Serwer mediów typu I

4

Jak widać, funkcjonalnie MS typu I odpowiada blokowi MRFP. Jego praca sterowana jest za pomocą protokołu H.248/Megaco, który adresuje wymienione funkcje. Warstwa sterowania, opisana w ramach architektury MS, jest w tej sytuacji zlokalizowana na serwerze aplikacji, wspierającym protokół H.248.

Serwer mediów typu II

Można mówić o serwerze mediów typu II w sytuacji, gdy MS wspiera wszystkie funkcje MS typu I oraz dodatkowo:

  • W spomaga realizacj ę zaawansowanych usług konferencyj nych
  • Zawiera funkcje IVR, ASR, TTS etc.
  • Wspiera standard VXML oraz inne języki oparte na XML (CCXML, SCXML)
  • Wspiera inne funkcjonalności MS wymienione w rozdziale
  • Wspiera interfejs oparty na protokole SIP, poprzez który adresowane są wszystkie jego funkcjonalności

Architekturę MS typu II ilustruje rysunek:

Rys. 10 Serwer mediów typu II

5MS typ II to serwer mediów o rozproszonej architekturze, w której warstwa sterowania funkcjonalnie odpowiada blokowi MRFC i jest oddzielona od pozostałych warstw poprzez interfejs oparty na protokole H.248. Pozostałe dwie warstwy tworzą blok odpowiadający blokowi MRFP.

Pracą całego MS steruje serwer aplikacji poprzez protokół SIP wzbogacony o dodatkowe funkcjonalności[7].

Można zatem powiedzieć, że MS typu I to „podstawowy” typ serwera mediów, udostępniający proste operacje na strumieniach multimedialnych. MS typu II to „zaawansowany” MS udostępniający szeroki wachlarz funkcjonalności[8].

Należy dodać, iż w sytuacji, w której nie rozpatruje się interfejsu opartego na H.248 i nie ma funkcjonalnej separacji pomiędzy warstwą sterowania a pozostałymi warstwami MS, również mówi się MS typu II.

Architektura MS/MRF a funkcje TTS, ASR, IVR.

W przypadku serwerów mediów dostępnych na rynku telekomunikacyjnym bardzo często zdarza się, że producenci nie implementują wszystkich funkcjonalności w ramach swojego produktu. Oferowana jest natomiast integracja MS z rozwiązaniami zewnętrznych firm, zapewniającymi określone funkcje. Dotyczy to najczęściej funkcjonalności ASR / TTS, nierzadko jednak bloki odpowiedzialne za interpretację skryptów VXML[9], jak również repozytoria plików audio/video czy skryptów dla różnych języków opartych o XML, stanowią oddzielne moduły od innych dostawców. Pozostałe funkcje (takie jak przetwarzanie sygnałów odtwarzanie/nagrywanie multimediów) są zwykle wspierane przez producentów MS.

W związku z powyższym możliwe jest różne usytuowanie bloków odpowiadających za wymienione funkcje na tle opisanej powyżej architektury funkcjonalnej MS/MRF. Można wyróżnić dwa podejścia opisane w poniższych podrozdziałach.

Wsparcie wszystkich funkcjonalności w ramach bloków funkcjonalnych MS/MRF

To podejście ilustruje poniższy rysunek:

Rys. 11 Funkcjonalności MS/MRF wspierane przez wewnętrzne bloki funkcjonalne

9

Rysunek obrazuje serwer mediów, który nie wymaga dodatkowej integracji z zewnętrznymi blokami funkcjonalnymi. Taki MS jest „widziany” jako jednolite „czarne pudełko” o określonym zestawie funkcjonalności. Z punktu widzenia współpracy z innymi elementami sieci istotne jest jedynie, aby wspierane były określone interfejsy.

Rysunek ilustruje również logiczne usytuowanie wyróżnionych funkcji względem MRFP i MRFC. IVR, TTS i ASR są rozproszone pomiędzy MRFC i MRFP, ponieważ ich realizacja wymaga sterowania pracą MRFP (synteza sygnałów cyfrowych, transport strumieni) wg. skryptów interpretowanych przez MRFC. Repozytoria skryptów oraz interpretery języków skryptowych należy funkcjonalnie przypisać do MRFC. Z kolei repozytoria plików A/V mogą być logicznie zlokalizowane w ramach MRFC lub MRFP.

Takie podejście znajduje odzwierciedlenie w specyfikacji ETSI, w dokumencie [42]. Wymieniono w nim zestaw funkcjonalności wspieranych przez interfejs Mp. Zawarta tam lista obejmuje:

  • Odgrywanie tonów rozmównych
  • Odgrywanie komunikatów
  • Nagrywanie strumieni audio
  • Text to Speech
  • Automatic Speech Recognition
  • Pobieranie cyfr i symboli DMTF
  • Odtwarzanie multimediów
  • Nagrywanie multimediów
  • Konferencja audio
  • Konferencja multimedialna
  • Transkodowanie strumieni
  • Audio o Video

Wymienione funkcjonalności są podzielone pomiędzy MRFP i MRFC i w całości przez nie realizowane, przy czym dla każdej z nich wyróżniono zbiór obowiązkowych jak i opcjonalnych operacji.

Lokalizacja pewnych funkcjonalności w zewnętrznych blokach funkcjonalnych i ich integracja z MS/MRF.

Ten wariant został przedstawiony na poniższym rysunku:

Rys. 12 MS/MRF zintegrowany z zewnętrznymi blokami funkcjonalnymi

9-1

Na rysunku przedstawiono MS „w otoczeniu” zewnętrznych modułów o określonej funkcjonalności. Ich współpraca z serwerem mediów przebiega poprzez wyróżnione interfejsy, które podzielić można na dwie grupy:

  • Interfejsy sterujące: A, B

Są to interfejsy pomiędzy modułami ASR/TTS a MRFC służące do sterowania pracą tych modułów. W rzeczywistych implementacjach wykorzystywanym tutaj protokołem jest zazwyczaj Media Resource Control Protocol (MRCP), zdefiniowany w [17]. Został on zaprojektowany specjalnie celem kontrolowania i wykorzystywania takich zasobów sieciowych jak syntezatory mowy, elementy rozpoznające mowę, faksy, detektory sygnałów etc.

  • Interfej sy transportowe

o a, b – służą do pobierania plików audio/video na potrzeby odtwarzania treści multimedialnej dla abonentów. Wykorzystuje się tutaj protokół HTTP. Pliki mogą być pobierane przez MRFC (interfejs a) w sytuacji, gdy do ich dystrybucji z MRFC do MRFP nie jest konieczny osobny interfejs (bloki te zintegrowane są ze sobą). W przeciwnym razie MRFP pobiera pliki (interfejs b), po uprzednim wskazaniu właściwego pliku przez MRFC.

o c – służy do pobierania przez MRFC plików zawierających skrypty języków opartych na XML (VXML, SCXML, CCXML). Tutaj również wykorzystuje się protokół HTTP.

o 1, 2 – interfejsy do przesyłania strumieni multimedialnych do/z bloków ASR/TTS. Wykorzystuje się tutaj protokół RTP.

Należy podkreślić, iż w rzeczywistych implementacjach sieci telekomunikacyjnej serwer mediów oraz współpracujące z nim moduły (zilustrowane na powyższym rysunku) są najczęściej traktowane „całościowo” jako jeden blok funkcjonalny MS/MRF (mimo, iż moduły „składowe” pochodzą od różnych producentów i nie stanowią jednolitego elementu sieciowego). Upraszcza to sterowanie wszystkimi modułami, oczywiście przy spełnionym warunku, iż są one zintegrowane ze sobą oraz ich funkcjonalności zostają wyeksponowane poprzez standardowe interfejsy zdefiniowane dla serwera mediów.

Rzeczywiste implementacje zależą silnie od producentów i operatorów telekomunikacyjnych i mogą znacznie różnić się między sobą.

[1]   Patrz rozdział 6.6.2.1

[2]   Patrz rozdział 6.6.2.2.

[3]   Dokładniejsze omówienie tego interfejsu wykracza poza zakres niniejszej pracy.

[4]   Dokładniejsze omówienie tego interfejsu wykracza poza zakres niniejszej pracy.

[5]   Patrz rozdział 6.6.2.1

[6]    W rozdziałach 5.4.3.1 oraz 5.4.3.2 rozważono podział MS na bloki funkcjonalne odpowiadające architekturze MRF.

[7]   Patrz rozdział 6.

[8]   Możliwe jest oczywiście, aby MS typu II udostępniał jedynie zbiór funkcji MS typu I. Będą one dostępne poprzez protokół SIP.

[9]   Można rozważać również interpretery innych języków skryptowych, przykładowo CCXML, SCXML etc. Patrz rozdział 6.6.4.

Wnioski

System Joomla! okazał się przyjaznym w użytkowaniu systemem oraz w pełni potwierdził on swoją przynależność do zaawansowanych systemów CMS liczących się w Internecie. [niestety, coraz mniej]

Na podstawie opisanych wcześniej wybranych stron internetowych stwierdzam, że systemy CMS są rozpowszechnione i z powodzeniem wykorzystywane nawet przez amatorów.

Strona wykonana w systemie Joomla umożliwia równoczesne publikowanie treści prze wiele osób bez informatycznego doświadczenia.

Zaletą systemu Joomla jest fakt, że ciągle jest on rozwijany i ulepszany – nowe wersje pojawiają się średnio co dwa miesiące.

Systemy CMS należące do otwartego oprogramowania stosuje się w tworzeniu serwisów, gdzie niepożądana zmiana treści nie będzie miała istotnego wpływu na działanie danej instytucji, a więc przede wszystkim w portalach informacyjnych, komunikacyjnych i edukacyjnych.

W wielu wypadkach system CMS nie jest w stanie zastąpić profesjonalnych programów, również stworzenie nowych komponentów jest czasochłonne i kosztowne.

Często problemem oprogramowania open source jest brak pełnej dokumentacji. Użytkownik może skorzystać z wiedzy zawartej na stronach internetowych, forach dyskusyjnych lub zamówić płatne wsparcie techniczne. Należy zauważyć, że czas odpowiedzi na zadane na oficjalnym forum pytanie, to od kilkunastu minut do około godziny, co jednak nie gwarantuje rozwiązania problemu.

Wspieranie i upowszechnianie systemów open-source może dać realne korzyści finansowe.

Joomla! to ciekawe rozwiązanie dla osób prywatnych oraz instytucji pragnących mieć stronę internetową i warto przyjrzeć się temu systemowi bliżej.

Literatura

Boiko B., „Content Management Bible (2nd Edition)”, Wiley 2004 Danowski B., „Tworzenie stron WWW w praktyce.”, Helion, Gliwice 2007 Frankowski P., „CMS. Jak szybko i łatwo stworzyć stronę WWW i zarządzać nią.”, Helion, Gliwice 2007

Graf H., „Joomla! System zarządzania treścią.”, Helion, Gliwice 2007

Howil W., „CMS. Praktyczne projekty”, Helion, Gliwice 2007

Jarosz D., „Płatny hosting czyli gdzie się ulokować”, Magazyn Internet 2006

Kolbusz E., „Informatyka w zarządzaniu”, Zeszyt naukowy Instytutu Informatyki w Zarządzaniu, Uniwersytet Szczeciński, Szczecin 1999

Krug S., „Nie każ mi myśleć o życiowym podejściu do funkcjonalności stron internetowych”, Helion, Gliwice 2006

Linderman M., Fried J., “Przyjazne witryny WWW”, Helion, Gliwice 2005 Nielsen J., „Projektowanie funkcjonalnych serwisów internetowych”, Helion, Gliwice 2004

Rosenfeld L., Morville P., „Architektura informacji”, Helion, Gliwice 2003 Sosna Ł., „Drupal. CMS system zarządzania treścią”, Nakom, Poznań 2008 Ullman L., „Dynamiczne strony WWW. PHP i MySQL”, Helion, Gliwice 2004 Zeldman J., „Projektowanie serwisów WWW. Standardy sieciowe.”, Helion, Gliwice 2007

Niederst Robbins J., „HTML i XHTML. Leksykon kieszonkowy.”, Helion, Gliwice, 2006

Funkcjonalność MS

Funkcjonalność podstawowa

Podstawowa funkcjonalność serwera mediów obejmuje:

  • Przesyłanie strumieni danych cyfrowych audio/video do terminali użytkowników:

o Pochodzących z plików multimedialnych, silników syntezy mowy, audio lub video lub innych zasobów wewnętrznych serwera mediów

  • Rejestrowanie strumieni audio/video (do różnych formatów) i przechowywanie ich w ramach zasobów lokalnych
  • Operacje na strumieniach audio/video:

o Zmiana parametrów sygnałów cyfrowych (filtrowanie, zmiana głośności, zmiana rozdzielczości video etc.)

o Miksowanie strumieni audio/video (sumowanie sygnałów audio, łączenie strumieni video w jeden strumień)

o Transkodowanie pomiędzy strumieniami danych audio/video kodowanymi różnymi kodekami

■ W połączeniach dwustronnych, w konferencjach, przy nagrywaniu / odtwarzaniu (np. gdy dane w pliku są kodowane innym kodekiem niż wspierany przez terminal użytkownika) o Funkcjonalność Text-To-Video (TTV), Text-Insertion-In-Video – dodawanie tekstu do strumienia video, tak aby widoczny był na ekranie

  • Pobieranie cyfr i symboli od abonenta (DTMF collection)

o W paśmie – Inband

o Poza pasmem – Outband

  • Funkcjonalność IVR – wsparcie interakcji z abonentem poprzez interpretację skryptów języka VXML, odtwarzanie odpowiednich komunikatów audio/video, pobieranie cyfr i symboli DTMF (cyfry i symbole mogą zostać przekazane do innego elementu sieciowego).
  • Funkcjonalność TTS – synteza mowy z tekstu oraz przesyłanie zsyntetyzowanego strumienia audio
  • Funkcjonalność ASR – automatyczne rozpoznawanie mowy – wykorzystywane często w ramach IVR, rezultaty rozpoznania mowy mogą zostać przekazane do innego elementu sieciowego

Obsługa kodeków i transkodowania

Należy zapewnić, aby MS wspierał możliwie najszerszy zbiór kodeków audio/video stosowanych w sieciach V OIP (nie jest to niestety regułą w przypadku dostępnych implementacji serwerów mediów).

Ponadto należy podkreślić, iż wsparcie jak najszerszego zbioru kodeków oraz wsparcie transkodowania pomiędzy każdą ich parą to funkcjonalności, które są obowiązkowe dla każdego serwera mediów (nawet jeżeli nie jest on w sieci wykorzystywany do transkodowania strumieni w dwustronnych połączeniach).

Wymaganie to można uzasadnić następująco: rozważmy sytuację, w której dla terminala obsługującego jedynie kodek A zażądano od serwera mediów odegrania pewnej zapowiedzi. Zapowiedź jest zapisana w pliku, w którym dane audio zakodowano kodekiem B. Jeśli MS wspiera zarówno kodek A jak i B w ramach sesji RTP zestawianych z terminalami, ale nie wspiera transkodowania kodeka B (dane audio w pliku) na A, nie będzie mógł odegrać zapowiedzi dla terminala.

Inny przykład to usługa konferencji/miksowanie strumieni. Załóżmy, że serwer mediów wykorzystywany jest do miksowania strumieni audio dla trzech terminali, z których każdy wspiera tylko jeden kodek, różny od dwóch pozostałych. Jeżeli MS wspiera wszystkie trzy kodeki dla sesji RTP z terminalami, ale nie wspiera transkodowania pomiędzy każdą parą spośród nich, wówczas nie będzie możliwe poprawne miksowanie strumieni.

Funkcjonalność konferencyjna

Serwer mediów uczestniczy w realizacji usługi konferencji poprzez miksowanie strumieni i ich przetwarzanie. Zgodnie z rozważaniami w rozdziale 4.2, w generycznym funkcjonalnym modelu systemu konferencyjnego opartego na sygnalizacji SIP serwer mediów pełni funkcję miksera [14].

Z tego względu do funkcji serwera mediów zaliczyć można także:

  • Tworzenie „miksu” konferencyjnego – miksowanie strumieni audio i video od uczestników konferencji i przesyłanie do nich strumienia zmiksowanego audio i video
  • Rezerwację zasobów miksujących strumienie i aktywację miksowania (czyli utworzenie instancji konferencji) np. o wskazanej wcześniej porze, na wskazany okres czasu
  • Włączanie w zmiksowane strumienie a/v wysyłane do wskazanego użytkownika o dodatkowych zapowiedzi/danych audio/video o dialogu IVR[1]
  • Operowanie na sygnałach cyfrowych pochodzących od uczestników konferencji przed włączeniem ich w zmiksowany strumień

o Zwiększanie/zmniejszanie siły głosu poszczególnych uczestników konferencji

o Transkodowanie pomiędzy różnymi kodekami audio/video

  • Elastyczne modyfikowanie strumienia zmiksowanego:

o Przesyłanie w „miksie” sygnałów tylko od jednego uczestnika (tryb wykładu) do kilku wybranych uczestników, dla których poziom sygnału audio przekracza określony poziom (określany w ramach aplikacji usługowej)

o Dla danego uczestnika włączanie/eliminowanie do/ze konferencji pochodzącego od niego strumienia audio (np. dla trybu secret participating czy dla uczestnika bez prawa głosu). o Modyfikacja zmiksowanego strumienia video odpowiednio dla trybów VAS – Voice Activated Switching, Continous Presence, lecture mode o Tworzenie subkonferencji – czyli przesyłanie kilku sygnałów zmiksowanych do grup użytkowników wyróżnionych logicznie w ramach konferencji

o Łączenie dwóch lub więcej konferencji w jedną konferencję.

Wsparcie mechanizmu uprawnionego przechwytu (Lawful Interception)

Jednym ze sposobów implementacji mechanizmu przechwytywania treści w sieciach typu V OIP jest wykorzystanie serwera mediów. W tym przypadku dla wskazanych połączeń/sesji/użytkowników kopiowane są strumienie multimedialne wysyłane/odbierane przez MS. Skopiowane dane mogą być przechowywane w ramach MS lub zapisywane w osobnej lokalizacji w sieci. Do kopiowania strumieni MS może wykorzystywać funkcjonalność agenta SIP typu Back To Back User Agent (B2BUA) – kopiowane strumienie przesyłane są do innej lokalizacji w ramach ustanowionej sesji SIP, powiązanej z „kopiowaną” sesją.

Uprawniony przechwyt (Lawful Interception) wymaga zdefiniowania dodatkowych mechanizmów służących do wskazywania źródła przechwytywanej treści oraz do zarządzania nią. Funkcjonalność ta nie wchodzi jednak w zakres funkcji serwera mediów i nie jest rozpatrywana w niniejszej pracy.

Oczywiście aby przechwytywanie treści z wykorzystaniem MS było optymalnym rozwiązaniem dla danej sieci, należy zapewnić, aby wszystkie strumienie multimedialne w tej sieci „przechodziły” przez ten moduł. Nie jest to jednak optymalne podejście z punktu widzenia zarządzania ruchem w sieci.

Mechanizmy naliczania opłat – charging/billing

Strumienie multimedialne RTP przesyłane do/z modułu MS opisać można pewnym zbiorem informacji, do których zaliczyć można:

  • objętość (w bajtach) danych multimedialnych wysyłanych/odbieranych przez MS w ramach danego strumienia
  • data i godzina rozpoczęcia i zakończenia odbierania/wysyłania strumieni przez MS, czas trwania tej sesji RTP (np. w sekundach)
  • ilość otwartych strumieni RTP
  • pasmo zarezerwowane w ramach danego strumienia RTP
  • typ kodeka zastosowany w przesyłanych danych

Informacje te mogą zostać udostępnione przez MS i wykorzystane przez systemy billingowe do naliczania opłat za korzystanie z sieci (charging). Możliwe jest wsparcie dwóch typów mechanizmów:

  • on-line charging – obciążanie użytkownika „na bieżąco” – w trakcie trwania połączenia/sesji
  • off-line charging – tworzenie informacji taryfikacyjnej po zakończeniu połączenia sesji i na jej podstawie obciążanie użytkownika.

Mechanizmy te wymagają wzbogacenia funkcjonalności MS o generowanie rekordów CDR[2] oraz obsługę interfejsu do systemów bilingowych danej sieci, celem przesyłania wygenerowanych danych. W rzeczywistych implementacjach MS wykorzystuje się w tym celu protokół DIAMETER[3].

Bardziej wnikliwa analiza funkcjonalności taryfikacyjnej MS nie jest celem niniejszej pracy magisterskiej.

[1]    Dialog IVR to określenie przebiegu interakcji z abonentem, np. przejścia przez menu głosowe i dokonanie wyboru poprzez DTMF etc. Dialogi mogą być definiowane np. poprzez skrypty VXML.

[2]   CallDetailRecord- rekord danych z informacjami na temat danego połączenia takimi jak: czas trwania połączenia, adresy źródłowe i docelowe, pora dnia, kiedy nawiązano połączenie, dodatkowe parametry połączenia etc. Może reprezentować różne typy połączenia: np. połączenie PSTN/3G, sesję VoIP, sesję GPRS etc. Rekordy CDR są wykorzystywane przez systemy bilingowe w procesie taryfikacji rozmów.

[3]    DIAMETER to zdefiniowany w [10] protokół sieciowy realizujący funkcje AAA (Authentication, Authorization andAccounting- Uwierzytelnianie, Autoryzacja i Obsługa Konta Użytkownika).

Protokół SIP i jego zastosowanie dla usług multimedialnych

Protokół SIP (Session Initiation Protocol) został zdefiniowany przez organizację IETF w dokumencie [2] w roku 1996. Dokument ten zaktualizowano w roku 2002 przez publikację [1], gdzie zawarto obecnie obowiązującą specyfikację SIP.

Protokół zyskał akceptację wielu ciał standaryzacyjnych, m.in. ETSI oraz 3GPP. Jego specyfikację włączono w zbiór standardów opisujących takie architektury sieciowe jak IMS, UMTS[1], NGN[2] [3] [4].

  • Mechanizm protokołu i architektura sieci SIP

SIP jest protokołem warstwy aplikacji przeznaczonym do sterowania zestawianiem sesji multimedialnych pomiędzy różnymi elementami sieci. Samodzielnie nie stanowi jednak mechanizmu realizacji połączeń – w tym celu musi być wykorzystywany wraz z innymi protokołami sieciowymi (SDP , RTP etc).

Jest to protokół tekstowy, który do transportu wiadomości wykorzystuje protokoły TCP lub UDP. Opiera się na transakcyjnym modelu wymiany wiadomości (podobnie jako protokół HTTP, z którym wykazuje wiele innych podobieństw). Transakcje są przeprowadzane wg zasady „żądanie-odpowiedź”, co implikuje podział wiadomości protokołu na żądania (Requests) oraz odpowiedzi (Responses).

W ramach podstawowego zbioru wiadomości SIP można wymienić:

  • Żądania:

o INVITE – wiadomość oznaczająca żądanie zestawienia sesji. Innymi słowy – jest to zaproszenie adresata do zestawienia połączenia. o BYE – wiadomość kończąca ustanowioną sesję.

o CANCEL – umożliwia anulowanie rozpoczętego procesu zestawiania sesji

o REGISTER – pozwala na zarejestrowanie adresu SIP, który reprezentuje terminal użytkownika lub inny element sieci. Rejestracja powoduje, że dany adres staje się „osiągalny” w danej sieci, a wiadomości na ten adres wysyłane trafią do skojarzonej z nim lokalizacji. o ACK – wiadomość wykorzystywana do potwierdzenia otrzymanej przez stronę wywołującą zgody na połączenie przesłanej przez stronę wywoływaną

o OPTIONS – żądanie przesłania przed odbiorcę jego funkcjonalności i cech (capabilities)

  • Odpowiedzi – analogicznie jak dla HTTP, podzielone na klasy związane z typem przenoszonej informacji:

o 1xx – odpowiedzi informacyjne (np. 180 RINGING). Oznajmiają, iż realizacja żądania (Request) jest w toku o 2xx – potwierdzają pozytywne zakończenie transakcji (np. 200 OK. – oznacza akceptację sesji przez wywoływaną stronę) o 3xx – odpowiedzi opisujące przekierowania, czy też wskazujące zmianę lokalizacji adresu wywoływanego (np. 301 MOVED PERMANENTLY – strona docelowa na stałe zmieniła swoją lokalizację) o 4xx – opisują zaistniały po stronie wywoływanej błąd (np. 486 BUSY HERE – strona wywoływana jest zajęta i nie może zaakceptować wywołania)

o 5xx – błąd serwera – np. (503 SERVICE UNAVAILABLE – serwer niedostępny)

Dla protokołu SIP zdefiniowano architekturę funkcjonalną, która obejmuje następujące elementy :

  • Agent Użytkownika (User Agent, UA) – blok funkcjonalny umożliwiający inicjowanie i odbieranie sesji. Jest częścią terminala abonenta sieci (SIP UE – User Equipment). Może również stanowić część innych elementów sieci (np. serwera aplikacji, serwera mediów, Media Gatewaya, etc).
  • Serwer Proxy – serwer pośredniczący w połączeniach. Odbiera wiadomości od SIP UA i kieruje je pod właściwy adres w sieci (np. do kolejnego serwera Proxy).
  • Serwer Registrar – rejestruje adresy SIP (identyfikatory zapisywane w formie URI, np. „user@domena.com”) agenta użytkownika i przypisuje je do
    określonej lokalizacji sieciowej agenta. Udostępnia informacje o lokalizacji danego agenta na potrzeby procesu realizacji połączenia.
  • Serwer Redirect – serwer, który generuje dla klienta odpowiedzi typu 3xx, wskazujące adres, z którym klient powinien się skontaktować.

Można powiedzieć, że zarówno serwer Proxy jak i Registrar stanowią realizację usługi lokalizacyjnej dla protokołu SIP, czyli umożliwiają uzyskanie informacji o lokalizacji danego agenta SIP.

  • Back-To-Back User Agent – agent użytkownika SIP, który logicznie składa się z dwóch agentów SIP UA. Każdy z nich może inicjować lub terminować jedną sesję SIP[8]. Pomiędzy sesjami może istnieć pewna relacja logiczna i może polegać np. na nawiązywaniu drugiej sesji na podstawie parametrów pierwszej z nich Przykładowe zastosowanie B2BUA to np. transfer połączeń (call transfer) oraz 3rd Party Call Control (zestawianie połączenia pomiędzy dwiema stronami i inicjowanego przez trzecią stronę, która tym połączeniem następnie steruje).

Architekturę SIP można zilustrować w następujący sposób:

Rys. 2 Podstawowa architektura funkcjonalna SIP wg [1]

rysunek

Na rysunku przedstawiono agentów SIP UA zarejestrowanych w dwóch domenach SIP. Domeny są ustanawiane przez adresy serwerów Proxy i Registrar. Bardzo często w rzeczywistych implementacjach oba te serwery stanowią jeden blok funkcjonalny.

[1]   UniversalMobile Telecommunications System – system komórkowy trzeciej generacji (3G).

[2]     Next Generation Network – sieć następnej generacji. Sieć pakietowa, w której z usług telekomunikacyjnych abonenci korzystają niezależnie od rodzaju technologii dostępowej ich terminali.

[3]   Przez sesje multimedialne można rozumieć połączenie, w ramach którego strony połączenia przesyłają strumienie multimedialne, dane tekstowe etc.

[4]    Session Description Protocol ([3])- protokół wykorzystywany do opisu sesji multimedialnych w sieciach opartych o protokół IP.

[8]    Przez sesję SIP rozumiemy tutaj zbiór transakcji SIP skojarzonych z danym połączeniem (sesją multimedialną).

Congestion Avoidance Using Proportional Control (CAPC)

[1, 3, 4, 11]

Algorytm został zaproponowany przez Andy Barnhart’a z Hughes Systems. W algorytmie, podobnie jak w ERICA, przełącznik stara się utrzymać współczynnik wykorzystania pasma z blisko jedności. Przełącznik mierzy prędkość wejściową danych, oblicza z i na podstawie tych danych aktualizuje fairshare-maksymalną prędkością z jaką może pracować dany kanał wirtualny.

04

Algorytm rozróżnia dwie sytuacje:

  1. Jeżeli stopień wykorzystania pasma jest mniejszy od zakładanego: z<1, współczynnik fairshare jest zwiększany:

Faishare=Faishare*Min(ERU, 1+(1-z)*Rup),

gdzie Rup jest parametrem pomiędzy (0.0.25 a 0.1), ERU określa maksymalne jednorazowe zwiększenie pasma i standardowo wynosi 1,5.

  1. Jeżeli stopień wykorzystania pasma jest większy od zakładanego: z>1, współczynnik fairshare jest zmniejszany:

Faishare=Faishare*Max(ERF, 1-(1-z)*Rdn),

gdzie Rdn jest parametrem pomiędzy (0.2 a 0.8), ERF określa minimalne jednorazowe zmniejszenie pasma i standardowo wynosi 1,5.

Źródło nie może nigdy transmitować z większą prędkością niż obliczony współczynnik fairshare.

Dodatkowo, oprócz obliczanego współczynnika z, algorytm pozwala na ustawienia progu kolejki w przełączniku. Jeżeli długość kolejki przekroczy ustalony próg, przełącznik ustawia bit wystąpienia przeciążenia CI (Congestion Indication) we wszystkich komórkach zarządzających RM. Zapobiega to przed zwiększaniem prędkości transmisji przez urządzenia nadawcze  i pozwala na zmniejszenie długości kolejek w buforze.

Poziom konstruowania i badania

Można postawić pytanie, jakie są konieczne warunki, aby ciąg {Pk} był ciągiem rosnącym i jaka jest jego granica. Tak jak już było powiedziane k-ty wyraz ciągu przyjmuje postać

Wyraz Pk będzie większy od Pk-1, jeżeli

.                                                                                                 (62)

Zależność (62) podaje warunek na to, aby Pk > Pk-1 Gdy spełniona jest równość

,                                                                                                 (63)

to wyraz Pk  nie może być większy od Pk-1  Skoro tak, to warunek (63) powinien zapewnić, że ciąg (62) jest rosnący do wyrazu Pk. Stąd można wyciągnąć wniosek, że granica ciągu {Pk} jest następująca:

.                                                                                       (64)

Wartość prawdopodobieństwa, którą można uzyskać w pojedynczej próbie, jest uwarunkowana możliwościami naukowo-technicznymi. Jeżeli jest ciągły proces poprawiania konstrukcji ( a  > 0) oraz niedopuszczalna jest możliwość pogorszenia konstrukcji ( b = 0 ), to wówczas ciąg (61) zbieżny jest do jedności,

.                                                                                        (65)

Z zależności (65) wynika, że dla pewnego poziomu konstruowania i badania możliwy jest do osiągnięcia tytko pewien określony poziom niezawodności. Czyli po odpowiedniej liczbie cykli ( faz projektowania i badań ) powinien poziom niezawodności zbliżyć się do stanu równowagi.

Mając określone prawdopodobieństwo Pk można określić ciąg rozkładów dwumianowych dla próbki N – elementowej ( N modeli wyrobu k-tej wersji):

j = 1, 2,…, N,                                                                                                  (66)

k = 1, 2, 3,…

Dla każdego Pk otrzymuje się rozkład liczby sukcesów w próbce N- elemen­towej.

Jak już powiedziano, średnie wartości tych sukcesów będą wynosiły:

.                                                                                              (67)

Wariancje natomiast będą miały postać

.                                                                         (68)

Z postaci wzorów (67) i (68} wynika, że dla danej próbki N-elementowej, jeżeli Pk będą rosły, to średnie Ek[XkN] będą również rosły, a wariancje sk2 będą malały.

Dla ustalonego poziomu prac konstrukcyjnych i poziomu badań okreś­lonych przez a i b, ciąg rozkładów (66) (dla warunku (64)) będzie zbieżny do rozkładu:

,                                       (69)

j = 1,…, N.

Stąd możliwy do osiągnięcia rozkład ma postać następującą:

.                                                (70)

Wykorzystując (70) można określić prawdopodobieństwo, jakie możliwe jest do osiągnięcia dla przyjętego poziomu konstruowania i badań,

,                                                        (71)

gdzie j* jest wyznaczone z założeń na pojedynczą próbę. Schemat rozkładów dwumianowych dla kolejnych cykli badań pokazany jest na rys. 5.

Można również przedstawić zarys modelu kształtowania niezawodności wyrobu, gdy a i b przyjmują zmienne wartości w poszczególnych fazach projektowania i badań. Wzory na prawdopodobieństwa sukcesu lub porażki dla k-tej wersji modelu wyrobu przyjmują postać

,                                                                     (72)

gdzie Pk + qk = 1.

Dla próbki N-elementowej rozkład dwumianowy przyjmuje postać

,                                                                           (73)

07

Rys. 7. Wykres Pk

Dla dolnej granicy prawdopodobieństwa niezawodnej pracy wyrobu wzór przyjmuje postać

,                                                                           (74)

gdzie j* wyznacza się w warunku Pk = j* /N ( j* — minimalna liczba sukcesów w próbce N-elementowej, Pk – dolna dopuszczalna granica prawdopodobień­stwa poprawnej pracy modelu).

W rezultacie projektowania i badań otrzymuje się następujący ciąg:

P1, P2, P3,…, Pk, Pk+1,… = {Pk}                                                                        (75)

W procesie projektowania dąży się do tego, aby ten ciąg był rosnący.

Można postawić pytanie, jakie muszą być spełnione warunki, aby ciąg (75) był ciągiem rosnącym, uwzględniając, że w każdej fazie projektowania i badań  ak i bk zmieniają swoje wartości. Zgodnie z (72) k-ty wyraz ciągu określa się następującym wzorem:

Dokonuje się przekształcenia powyższego wzoru:

Oznacza  się    , Aby  Pk > Pk-1, to A > 0,

, ,                                         (76)

Aby Pk > Pk-1, to musi być spełniony warunek (76). Ponieważ prawa strona nierówności (76) zależy od właściwości cech projektowych w k-tej fa-zie projektowania i badań, to jeżeli

Pk-1 < ak /( ak + bk ) otrzymamy Pk > Pk-1.

Skoro ak i bk zmieniają się w każdej fazie projektowania i badań, to możemy postawić pytanie, jak mają się zmieniać ciągi {ak} i {bk}, aby ciąg (75) był ciągiem rosnącym. W wyniku projektowania powinno się zapewnić:

.                                                                                 (77)

Dokonuje się przekształcenia zależności (77):

(78)

Warunek (78) można również napisać w następującej postaci:

.                                                                                                  (79)

Zależność (78) będzie zawsze spełniona, gdy (a) ciąg {ak}  będzie rosnący;

(b) ciąg {bk} będzie malejący. Jeżeli zależność (78) lub (79) będzie spełniona dla każdego k, to ciąg (75) będzie rosnący. Jeżeli te warunki będą spełnione, to w wyniku procesu projektowania otrzymamy, po odpowiedniej liczbie faz projektowania i badań, wyrób o żądanych cechach niezawodnościowych.

Omówiony przypadek jest w pewnym sensie uproszczeniem problemu. W praktyce projektowania powstają niekiedy rozwiązania nietrafne, które powodują obniżenie prawdopodobieństwa poprawnej pracy. W następnej fazie (w miarę rozpoznawania problemu) powstają pomysły bardziej udane, które wpływają na rozwiązania bardziej trafne, co w wyniku prowadzi do wzrostu prawdopodobieństwa poprawnej pracy. W wyniku całego procesu projek­towania w czasie mogą być przypadki, że ciąg (75) w pewnych przedziałach czasu jest ani rosnący, ani malejący. Dopiero po zdobyciu doświadczenia przekształca się w ciąg rosnący.

Rozpatrzone zostaną obecnie niektóre przypadki szczególne procesu kon­struowania i badań:

  1. Niech ak = 0, bk = 0, k = 2, 3,…

Ze wzoru (72) wynika, że wszystkie wyrazy ciągu (75) przyjmują taką samą wartość. Cechy niezawodnościowe modeli wyrobu przy tym sposobie projek­towania pozostają takie same jak w etapie pierwszym-

  1. ak ¹ 0, bk = 0, k = 2, 3,…

W tym przypadku mamy ciągły proces poprawiania konstrukcji. Ciąg (75) jest rosnący. Granicą ciągu jest l.

  1. ak = 0, bk ¹ 0, k = 2, 3,…

W tym przypadku mamy ciągły proces pogarszania konstrukcji. Ciąg (75) jest malejący. Granicą ciągu jest 0.

  1. ak = 1, bk = 1, k = 2, 3,…

Ze wzorów (72) wynika, że gdy ak = 1 i bk = 1 ( k = 2, 3,…, ), to w każdym kroku następuje zamiana Pk na qk, a qk na Pk. W praktyce oznacza to, że w każdej następnej fazie projektowania i badań poprawiamy wszystkie stany zawodne modeli wyrobu ( ak = 1 ) i jednocześnie pogarszamy wszystkie stany niezawodne modeli wyrobu ( bk = 1 ).

  1. ak ¹ 0, bk ¹ 0 i ak + bk = 1

Dla lego przypadku wzory (72) przyjmują postać:

.                                                                    (80)

W tym przypadku ak i bk stają się prawdopodobieństwami pracy modeli w poszczególnych krokach. Oznacza to, że nie nakłada się historia projek­towania z poprzednich faz.

  1. Niekiedy w pracach projektowo-badawczych chodzi nam o szybkie rozwiązanie problemu, bez względu na koszty. Wtedy proces projektowo-badawczy, zaproponowany wg schematu (rys. 5), można przyspieszyć.

W czasie Dt, w k-tej fazie projektowania, wykonuje się niejedną wersję modeli wyrobu a kilka różnych wersji modeli. Wtedy otrzymuje się ciąg wyników:

Pk1, Pk2,…, Pki,

gdzie i oznacza liczbę wersji modeli w k-tej fazie projektowania.

Wyniki prawdopodobieństw Pki poddaje się obróbce statystycznej, aby uwzględnić ewentualne różnice w liczności poszczególnych próbek oraz aby ustalić istotne bądź nieistotne różnice pomiędzy wynikami prawdopodobieństw.

Do następnej fazy projektowania (k + l), wybiera się tę wersję modelu, który w fazie k osiągnął najwyższą wartość prawdopodobieństwa Pki. W przy­padku. gdy różnice Pki dla różnych wersji modeli są nieistotne, o wyborze decydują inne czynniki (cechy), np. prostota konstrukcji.

Podział metod badań niezawodności

Niezawodnościowy model obiektu tworzy się w celu prze­prowadzenia na nim teoretycznych badań niezawodności. Badania niezawodności stanowią drugi element systemu racjonalnego od­działywania na niezawodność obiektu w fazie jego konstruowania (p. rozdz. 2).

Do badań niezawodności w fazie konstruowania mogą być uży­te przede wszystkim metody teoretyczne. Będą one przedstawione szczegółowo w dalszej części tego rozdziału. Drugą grupę two­rzą metody eksperymentalne, do których można zaliczyć metody eksploatacyjne i metody doświadczalne.

Badania eksploatacyjne, a więc przeprowadzane w warunkach obserwowanej eksploatacji, są najdokładniejszą metodą wyzna­czania poziomu niezawodności i skutków niesprawności. Jednakże badania takie nadają się do stosowania w fazie konstruowania tylko w ograniczonym stopniu, bo ich koszt jest duży a wyniki nie mają na ogół istotnego wpływu na poziom niezawodności ba­danego obiektu. Badania eksploatacyjne stanowią natomiast bo­gate źródło informacji potrzebnych do kształtowania poziomu niezawodności obiektów przyszłych, podobnych do badanego. Są to m.in. informacje o procesie eksploatacji obiektu, o przy­czynach i skutkach niesprawności różnych fragmentów obiektu, o poziomach niezawodności różnych elementów obiektu itd.  Są one szczególnie potrzebna przy tworzeniu niezawodnościowego modelu konstruowanego obiektu, głównie przy wyborze punktów kontrolnych, przy wyborze zjawisk fizycznych prowadzących do niesprawności, przy modelowaniu eksploatacji obiektu itd.

Proponowany system  racjonalnego oddziaływania na nieza­wodność konstruowanego obiektu może w dużym stopniu wymuszać rodzaje i sposoby badań eksploatacyjnych, przeprowadzanych na już istniejących obiektach. System ten, a zwłaszcza tworzenie modelu niezawodnościowego, mogą stymulować dodatkowe badania specjalne w celu uzyskania brakujących informacji. W pewnych przypadkach te dodatkowe badania mogą być prowadzone w celu uzupełnienia niezawodnościowego modelu konstruowanego obiektu o wartości wskaźników niezawodności niektórych PK, elementów oraz zespołów. Zachodzi to wtedy, gdy niedostateczna wiedza lub brak odpowiednich danych uniemożliwiają zbudowanie nieza­wodnościowych modeli tych PK, elementów lub zespołów.

Badania doświadczalne przeprowadzane są na obiektach rze­czywistych albo na ich modelach materialnych na specjalnych stanowiskach lub poligonach doświadczalnych. Mogą dotyczyć całych obiektów lub ich elementów. Badania takie wymagają odwzorowywania procesu eksploatacji obiektu, procesu oddziały­wań zewnętrznych na obiekt lub jego elementy. Często mają one charakter badań symulacyjnych, przy czym symulacja dotyczy procesu eksploatacji obiektu albo procesu oddziaływań zewnętrznych albo procesu starzenia się obiektu.

Badania doświadczalne mogą natomiast być dobrym źródłem informacji o przyczynach niesprawności.

Cele badań doświadczalnych stymulowanych przez systemy ra­cjonalnego oddziaływania na niezawodność są podobne do celów badań eksploatacyjnych, wymienionych uprzednio. W tym przypad­ku chodzi przede wszystkim o uzyskanie brakujących informacji potrzebnych przy tworzeniu modelu niezawodnościowego, np. o własnościach wytrzymałościowych różnych M, o innych własno­ściach materiałowych, które wpływają na przebieg zjawisk fizy­cznych prowadzących do niesprawności, o przebiegu tych zjawisk itd. Czasami celem badań doświadczalnych może być również określenie niezawodności niektórych PK, elementów lub zespołów konstruowanego obiektu.

Badania eksperymentalne (eksploatacyjne i doświadczalne) w systemie racjonalnego oddziaływania na niezawodność obiektu w fazie jego konstruowania odgrywają więc pomocniczą rolę. Dostarczają mianowicie informacji potrzebnych przy tworzeniu niezawodnościowego modelu obiektu, a w szczególnych przypad­kach zastępują badania niezawodności przeprowadzane na modelu teoretycznym.

Metody teoretycznych badań niezawodności (na podstawie zbudowanego uprzednio modelu) można podzielić na dwie grupy metod: analityczne i numeryczne (głównie symulacyjnej). Wybór metody zależy od stopnia skomplikowania niezawodnościowego mo­delu badanego obiektu. W przypadku punktów kontrolnych, któ­rych stan niezawodnościowy zależy od jednej cechy lub kilku cech niezależnych stochastycznie, ich modele niezawodnościowe aa zwykle na tyle mało skomplikowane, że badania niezawodności mogą być przeprowadzane zarówno metodami analitycznymi, jak i numerycznymi.

Znacznie bardziej skomplikowane są niezawodnościowe modele obiektów mechanicznych złożonych z kilku (lub większej liczby) PK. W takich przypadkach analityczne metody badań niezawodno­ści obiektu mogą być wykorzystane na ogół wówczas, gdy do mo­dela wprowadzi się silne założenia upraszczające, polegające głównie na pominięciu zależności stochastycznych między cecha­mi zdatności Zn(t)  (n)= 1, 2,…, n)  lub między czasami Ti (i = 1, 2,…, m)  bezawaryjnej pracy odpowiednich PK. W innych przypadkach analityczne metody zwykle zawodzą i wówczas pomoc­ne mogą być teoretyczne metody numeryczne (symulacyjne). Sto­sując metody symulacyjne, można przezwyciężyć niektóre z trud­ności, na jakie napotyka się przy stosowaniu metod analitycz­nych. Między innymi znacznie łatwiejsze staje się właśnie uwzględnienie wymienionych zależności stochastycznych, oczy­wiście jedynie w zakresie określonym przez model.

Obydwie grupy metod teoretycznych badań niezawodności zo­staną przedstawione w następnych punktach tego rozdziału.

Nowa „generacja sie” – systemy ekspertowe

Dane, zbierane w trakcie funkcjonowania SIE, gromadzone w banku informacji (bazie danych) mogą być wykorzystywane na etapach projektowania, wytwarzania i eksploatacji. Wiedza eksploatacyjna zdobyta w ten sposób, może zostać wykorzystana w bardziej efektywny sposób poprzez zastosowanie nowoczesnych metod prezentacji (bazy wiedzy) lub metod sztucznej inteligencji (systemy ekspertowe). Wiedza eksploatacyjna jest zasobem produkcyjnym niezbędnym przy planowaniu i wykonywaniu zadań produkcyjnych, rozwiązywaniu typowych problemów eksploatacyjnych, rozpoznawaniu krytycznych sytuacji eksploatacyjnych oraz wyborze stosownych działań zaradczych lub korekcyjnych.

Komputerowy system ekspertowy stwarza możliwość reprezentacji i prezen­tacji wiedzy w sposób bardziej pełny i dynamiczny niż ujęcie wiedzy w formie książkowej instrukcji. W momencie czytania instrukcji żaden fragment wiedzy pisanej nie oddziałuje aktywnie na zmysły użytkownika. Z tego względu istotne informacje mogą być pominięte lub niezauważone. Struktura tekstu jest liniowa i statyczna, w związku z tym istotne informacje mogą być rozproszone w tekście. Wady tej nie posiadają komputerowe systemy ekspertowe, gdyż istnieje moż­liwość tworzenia dynamicznych powiązań pomiędzy informacjami specyficz­nymi dla rozwiązywania konkretnych problemów.

System ekspertowy stanowi więc nową formę „opakowania” wiedzy, dającą w porównaniu z tradycyjną dokumentacją książkową znacznie większe moż­liwości inteligentnej, aktywnej prezentacji wiedzy uwzględniającej możliwości percepcyjne użytkownika.

Technologie informacyjne wypracowane w ramach badań nad sztuczną inteligencją pozwalają na ujęcie wiedzy eksploatacyjnej w formie programów komputerowych oraz taką strukturalizację tej wiedzy, która stwarza nową jakość określaną jako inteligentna dokumentacja eksploatacyjna.