Opis Przedmiotu Zamówienia

Transkrypt

1 Opis Przedmiotu Zamówienia Załącznik nr 2 do SIWZ do Umowy nr Część 1 zamówienia - Dostawa i wdrożenie systemu Wycinarka Spis treści 1 Słownik pojęć Wstęp Wymagania Wymagania ogólne Wymagania na dokumentację Wymagania na testy Wymagania na funkcje Systemu Rejestrator Panel definiowania zleceń Transkoder Publikator API Moduł administracyjny Interfejsy Wymagania niefunkcjonalne

2 1 Słownik pojęć Wyrazy pisane w niniejszym dokumencie wielką literą należy interpretować zgodnie z poniższymi definicjami. TVP Telewizja Polska S.A., podmiot administrujący i użytkujący System Wycinarka Zamawiający TVP System Wycinarka oprogramowanie dostarczone przez Wykonawcę spełniające wymogi Opisu Przedmiotu Zamówienia, zwane dalej Wycinarką lub Systemem Kodowanie transformacja między formatami audio-wideo Multicast sposób dystrybucji sygnału telewizyjnego Rejestrator moduł systemu Wycinarka odpowiedzialny za rejestrację sygnału dostarczanego przez Zamawiającego m.in. z Multicastu, w celu wycięcia z niego fragmentu Transkoder główny moduł systemu Wycinarka, służący do przetwarzania (kodowanie) formatu wewnętrznego Wycinarki na format audio-wideo oczekiwany przez Zamawiającego Publikator moduł systemu Wycinarka odpowiedzialny za publikację wyjściowych plików multimedialnych w formacie oczekiwanym przez Zamawiającego CDN system dostarczania treści użytkowany przez Zamawiającego CMS system zarządzania treścią użytkowany przez Zamawiającego Wykonawca firma zakontraktowana do realizacji Systemu 2 Wstęp Wycinarka jest systemem dostarczającym na potrzeby internetowych kanałów dystrybucyjnych TVP pliki multimedialne, w odpowiednich formatach dostosowanych do tego medium transmisyjnego, w szczególności również będące fragmentami audycji antenowych lub fragmentami materiałów audiowizualnych. Na poniższym diagramie zaprezentowane zostały w ujęciu poglądowym komponenty, z którym współpracuje Wycinarka: 2

3 cmp Wycinarka Źródło sygnału Wycinarka CDN CMS 3

4 Wycinarka jest systemem modułowym, w skład której wchodzą m.in.: a) Moduł rejestrujący sygnał wejściowy (Rejestrator) b) Panel definiowania zleceń wycinania fragmentów z materiału audiowizualnego (Panel Zleceń) c) Główny moduł transkodowania (Transkoder) d) Moduł publikujący (Publikator) e) Usługi biznesowe udostępniane przez System (API) f) Moduł administracyjny (Administracja) Na poniższym diagramie zaprezentowana została w ujęciu poglądowym architektura logiczna Wycinarki, z uwzględnieniem wybranych modułów: composite structure Wycinarka_Moduły Multicast Wycinarka::Wycinarka Administracja Panel Zleceń API Strumienie Rejestrator Transkoder Ingest plików Publikator CDN CMS Pliki Obiekty multimedialne 3 Wymagania Poniżej opisano wymagania względem Systemu. Wymagania te zostały podzielone na następujące grupy: 1) Wymagania ogólne - wymagania funkcjonalne względem całego Systemu tj. takie, których nie przyporządkowano do konkretnego modułu 2) Wymagania na dokumentację 3) Wymagania na testy 4) Wymagania na funkcje Systemu (poniższy podział został przygotowany przez Zamawiającego i jego celem jest tylko logiczne pogrupowanie wymagań na funkcje Systemu): a) Rejestrator - wymagania względem modułu rejestrującego sygnał z materiałem wejściowym b) Panel definiowania zleceń - wymagania względem modułu tworzenia zleceń wycinania z materiału wejściowego c) Transkoder - wymagania względem kodującego format wewnętrzny na format materiału wyjściowego d) Publikator wymagania względem modułu publikującego materiał wyjściowy e) API wymagania względem modułu udostępniającego funkcje biznesowe systemom zewnętrznym f) Moduł administracyjny wymagania względem modułu administracyjnego 4

5 5) Wymagania niefunkcjonalne lista wszystkich wymagań pozafunkcjonalnych takich jak oczekiwania względem użyteczności, niezawodności i wydajności. 3.1 Wymagania ogólne 1. Wykonawca Systemu musi zrealizować co najmniej następujące etapy zarządcze projektu: a) Etap 1 Plan Projektu, Projekt Techniczny, Plan Testów b) Etap 2 wdrożenie Testowe c) Etap 3 wdrożenie Produkcyjne, którego celem będzie wdrożenie pełnej funkcjonalności Systemu w środowisku produkcyjnym 3.2 Wymagania na dokumentację 1. Wykonawca, w trakcie realizacji wdrożenia dostarczy co najmniej następującą dokumentację projektową w języku polskim: a) Plan Projektu b) Projekt Techniczny c) Plan Testów d) Scenariusze testowe (testy integracyjne, wydajnościowe, funkcjonalne, bezpieczeństwa i akceptacyjne) e) Raport z testów f) Dokumentację użytkownika g) Dokumentację administratora h) Dokumentację programisty i) Dokumentację powykonawczą 2. Wykonawca przygotuje Plan Projektu zawierający co najmniej: a) Zakres projektu b) Wszystkie założenia projektowe c) Organizację projektu po stronie Wykonawcy i Zamawiającego wraz z opisem ról d) Szczegółową strukturę produktową projektu e) Doprecyzowanie, w którym Etapie dostarczane są jakie produkty i w jakim Etapie będą one aktualizowane f) Harmonogram prac uwzględniający w szczególności oczekiwania zasobowe względem Zamawiającego g) Procedurę zarządzania zagadnieniami, ryzykami i zmianą włącznie z procedurą eskalacji. h) Standardy nazewnictwa i sposobu zarządzania dokumentacją projektową m.in. strukturę folderów. i) Szablony kluczowych dokumentów projektowych takich jak Projekt Techniczny i Plan Testów. 3. Wykonawca przygotuje Projekt Techniczny zawierający co najmniej: a) Wnioski z weryfikacji koncepcji biznesowej zawartej w OPZ włącznie z uzgodnieniami co do ewentualnej optymalizacji funkcji Systemu b) Niskopoziomową architekturę techniczną opisującą sposób realizacji wymagań za pomocą dostarczanych licencji (oprogramowanie gotowe) i artefaktów programistycznych tworzonych na potrzeby TVP (oprogramowanie dedykowane) c) Macierz realizacji wymagań przez konkretne komponenty techniczne (oprogramowanie gotowe lub dedykowane) d) Szczegółowy model przypadków użycia, oraz model aktorów e) Szczegółowy model danych f) Szczegółowy model uprawnień g) Szczegółową specyfikację interfejsów z systemami TVP h) Przygotowanie i weryfikację modelu dziedziny, jego uzupełnienie i uszczegółowienie i) Fizyczny model danych j) Specyfikację raportów k) Procedurę awaryjną l) Plan wdrożenia Produkcyjnego 4. Wykonawca przygotuje Plan Testów zawierający co najmniej: a) Podział testów na fazy b) Specyfikację zakresu testów dla każdej z faz c) Opis sposobu realizacji testów integracyjnych, wydajnościowych, funkcjonalnych, bezpieczeństwa i akceptacyjnych m.in. jakie narzędzia i środowiska będą zastosowane d) Opis sposobu rejestracji i weryfikacji zgłaszanych uwag e) Kryteria rozpoczęcia i zakończenia każdej z fazy testów 5

6 f) Opis dokumentacji testowej wraz z szablonami dokumentów g) Sposób przygotowania danych testowych h) Plan realizacji testów swobodnych tj. niepowiązanych ze scenariuszami testowymi 5. Wykonawca dostarczy dokumentację użytkownika zawierającą co najmniej: a) Opis wszystkich funkcji możliwych do wykorzystanie przez każdego z aktorów wraz ze zrzutami z ekranów 6. Wykonawca dostarczy dokumentację administratora zawierającą co najmniej: a) Instrukcję instalacji Systemu b) Dokumentację architektury infrastrukturalnej rozwiązania c) Dokumentację archiwizacji danych i ich odtwarzania d) Pełną dokumentację ustawień konfiguracyjnych e) Listę wszystkich czynności, które powinny być okresowo wykonywane przez administratora Systemu f) Opis sposobu korzystania ze skryptów, jeżeli takie zostaną dostarczone w ramach wdrożenia 7. Wykonawca dostarczy dokumentację programisty zawierającą co najmniej: a) Dokumentację narzędzi wykorzystywanych do realizacji prac programistycznych b) Dokumentację architektury technicznej rozwiązania c) Dokumentację klas dotyczącą oprogramowania stworzonego na potrzeby TVP lub możliwego do samodzielnej zmiany przez TVP d) Dokumentację przygotowania build u Systemu i przygotowania paczki instalacyjnej e) Dokumentację oprogramowania stworzonego w trakcie realizacji wdrożenia w TVP na poziomie umożliwiającym modyfikację tego oprogramowania przez pracowników TVP lub inne zasoby zewnętrzne. Dopuszcza się realizację tego wymagania poprzez komentowanie kodu pod warunkiem automatycznego wygenerowania dokumentacji programistycznej np. z wykorzystaniem takich narzędzi jak Javadoc, GitHub lub analogicznego. 8. Wykonawca dostarczy dokumentację powykonawczą zawierającą co najmniej: a) Specyfikacje interfejsów udostępnianych przez System na zewnątrz takich jak API i usługi Web Services b) Specyfikację interfejsów realizowanych przez System c) Szczegółowy opis komponentów zrealizowanych na potrzeby TVP (oprogramowanie dedykowane) d) Dokumentację kodu zrealizowanego na potrzeby TVP (oprogramowanie dedykowane) e) Model danych w postaci diagramów encji (dla oprogramowania gotowego na wysokim poziomie ogólności) albo obiektów f) Rekomendowany sposób realizacji usługi utrzymania przez TVP włącznie z listą sugerowanych działań pielęgnacyjnych, sposobem monitorowania bieżącego działania Systemu oraz procedurami zarządzania zgłoszeniami potencjalnych błędów przez trzy linie wsparcia (diagnostyka) g) Zdefiniowanie zakresu zmian możliwych do samodzielnego wykonania przez TVP, zmian wymagających konsultacji lub wsparcia ze strony Wykonawcy wraz z procedurą postępowania w każdym z powyższych przypadków. 3.3 Wymagania na testy 1. Wykonawca zrealizuje testy integracyjne, wydajnościowe, funkcjonalne i akceptacyjne w obecności przedstawicieli Zamawiającego, w oparciu o zaakceptowany przez Zamawiającego Plan Testów oraz przygotuje paczki danych testowych (w zakresie i czasie uzgodnionym z Zamawiającym) 2. Zamawiający będzie mógł przekazać Wykonawcy paczki danych testowych, na których Wykonawca zrealizuje testy Systemu 3. Wykonawca dostarczy raport z testów wewnętrznych (testów systemowych) przed rozpoczęciem testów z Zamawiającym dokumentujący wykonanie wewnętrznej kontroli jakości oraz jego efektów. 4. W ramach realizacji testów oprogramowania Wykonawca zaplanuje i zapewni wsparcie przy realizacji testów swobodnych. 5. W ramach realizacji testów oprogramowania Wykonawca zaplanuje i dostarczy niezbędne dane testowe. 6. Wykonawca zrealizuje testowe odtworzenie danych z wykonanego wcześniej backupu danych. 7. Wykonawca zrealizuje testowe odtworzenie całego Systemu (reinstalację) z wykonanego wcześniej backupu Systemu. 3.4 Wymagania na funkcje Systemu Rejestrator 6

7 System umożliwi przetwarzanie sygnału z materiałem wejściowym, a w szczególności: 1. (opcja) System umożliwi weryfikację czy materiał wejściowy jest zgodny z parametrami zdefiniowanymi w profilu do kodowania materiału wejściowego (więcej o profilach kodowania materiału wejściowego w opisie modułu Administracja) jeżeli materiał wejściowy nie spełnia minimalnych kryteriów ustawionych w parametrach profilu, to nie zostanie on zakwalifikowany do zarejestrowania 2. System umożliwi bezbłędną rejestrację wielu strumieni, plików oraz sygnału Multicast: a. MPEG-TS b. rodzaje kodeków H.264/MP2 3. System umożliwi bezbłędną rejestrację wielu strumieni w formacie H.265 (kodowanie audio zgodne ze specyfikacją kontenera wejściowego do ustalenia z Zamawiającym na etapie Projektu Technicznego) 4. (opcja) System umożliwi bezbłędną rejestrację wielu strumieni innego typu, w tym m.in.: a. rodzaje kodeków: AAC 5. System umożliwi pobieranie z zasobów zewnętrznych i bezbłędną rejestrację wielu strumieni: a. rodzaje protokołów: np. HTTP b. formaty, np.: i. MP3 6. (opcja) System umożliwi pobieranie z zasobów zewnętrznych i bezbłędną rejestrację wielu strumieni, w tym m.in.: a. rodzaje protokółów: np. HTTP, RTMP, RTSP b. formaty, np.: i. ISMV ii. Vorbis w kontenerze Ogg (Ogg/Vorbis) iii. MP4 (H.264, AAC, H.265, AC-3) 7. System umożliwi przekazanie do niego (przesyłanie do Wycinarki) wielu strumieni: a. ISMV po HTTP (kodek: np. H.264/AAC) 8. (opcja) System umożliwi przekazanie do niego (przesyłanie do Wycinarki) wielu strumieni, w tym m.in.: a. ISMV po HTTP (kodeki: np. H.265, AC-3) b. fragmentowany MP4 po HTTP (kodeki np. H.264, AAC, H.265, AC-3) 9. System umożliwi ingest wielu plików (różne formaty) z materiałem audiowizualnym albo audio: a. typ kontenera i rodzaj kodeka: Apple MOV, MP4 (kodeki: np. H.264, MP3, AAC, AACP, AACPv2), WMV, WAV, 3GP, 3G2, PRO-RES 10. (opcja) System umożliwi ingest wielu plików (różne formaty) z materiałem audiowizualnym albo audio, w tym m.in.: a. typ kontenera i rodzaj kodeka: np. MP2, MP3, H.265, AC-2, Vorbis w kontenerze Ogg (Ogg/Vorbis), VOB, XDCAM-HD, DVC-PRO, IMX 11. System wykona bezbłędną rejestrację materiałów wejściowych z pliku w formacie H.264/AAC w kontenerze MP4, w tym: liczba klatek 25FPS, proporcje 4:3 lub 16:9 12. System wykona bezbłędną rejestrację materiałów wejściowych w pozostałych formatach i różnymi parametrami w tym: liczba klatek na sekundę, proporcje, rozdzielczość (w tym 2K, 4K) 13. System umożliwi dla każdej instancji wejściowego kontenera multimedialnego: a. możliwość pełnej i nieograniczonej konfiguracji w zakresie adresowania zasobów wejściowych, np. foldery, URL-e, zasoby CDN Zamawiającego, protokół (np. CIFS, NFS) b. możliwość wybrania/ignorowania ścieżek w kontenerze wejściowym (np. audio, wideo, napisy, teletekst, audiodeskrypcja) c. (opcja) możliwość pełnej i nieograniczonej konfiguracja w zakresie parametrów technicznych dla weryfikacji materiału wejściowego (w oparciu o słowniki i krzyżówki per kontener + kodek, w celu wykonania przez System walidacji dozwolonych kombinacji tych parametrów), w tym m.in.: i. ilość ramek na sekundę ii. rozmiar ramki iii. rozdzielczość (w tym np. 2K, 4K) iv. proporcje v. przepływność vi. jakość vii. inne 14. System umożliwi równoległe rejestrowanie wielu materiałów wejściowych jednocześnie, w czasie rzeczywistym (minimalne wymagania dla anten telewizyjnych: 40) 15. (opcja) System umożliwi parametryzację w zakresie zarządzania archiwizacją plików po zakończeniu kodowania (w tym usuwanie plików, jako opcja domyślna) 7

8 16. (opcja) System umożliwi na żądanie użytkownika zatrzymanie i wznowienie rejestrowania materiałów wejściowych 17. System musi umożliwiać podpięcie pod jego zdarzenia skrypty przetwarzające, przygotowane przez Zamawiającego (zakres zdarzeń Systemu do ustalenia z Zamawiającym na etapie Projektu Technicznego) 18. System umożliwi również wykorzystanie zewnętrznych narzędzi kodujących np. ffmpeg, x264, sox, mp4box itp., przy użyciu skryptów przetwarzających uruchamianych przez zdarzenia Systemu 19. System musi przechowywać zarejestrowany materiał wejściowy (minimalny czas przechowywania materiału wejściowego: 72 godzinne okno czasowe) Panel definiowania zleceń System umożliwi wykonywanie operacji z poziomu GUI na materiale wejściowym, a w szczególności: 20. System umożliwi uruchomienie panelu definiowania zleceń bezpośrednio z zewnętrznego systemu, np. CMS użytkowany przez Zamawiającego 21. System umożliwi uruchomienie instancji panelu definiowania zleceń w kontekście nadrzędnego obiektu wideo CMS (identyfikator tego obiektu będzie przekazywany do Systemu przez CMS), a wszystkie operacje wykonywane w panelu (np. wycinanie fragmentu z materiału wyjściowego, zlecenie) będą realizowane tylko w kontekście tego obiektu 22. System umożliwi wyzwolenie przez użytkownika ingestowania wskazanego pliku 23. System umożliwi załadowanie materiału wejściowego z pliku lub z danych zarejestrowanych przez Rejestrator 24. System umożliwi podgląd wejściowych materiałów audiowizualnych 25. System umożliwi odsłuchanie wejściowych materiałów audio 26. (opcja) System umożliwi podgląd albo odsłuchanie materiału wejściowego w czasie rzeczywistym (to znaczy: użytkownik nie musi czekać aż Rejestrator zakończy rejestrację całego materiału wejściowego, tylko ma dostęp do porcji materiału wejściowego jaka została już zarejestrowana wartość minimalnej porcji materiału wejściowego jaka musi zostać zarejestrowana do ustalenia z Zamawiającym) 27. System umożliwi zdefiniowanie początku i końca wycinanego fragmentu z materiału wejściowego 28. System umożliwi użytkownikowi dodanie wielu ścieżek z napisami do wyciętego fragmentu materiału (formaty m.in.: EBUSTL (.stl), DFXP (.xml), SRT, SUB/SBV, WebVTT) 29. System umożliwi użytkownikowi dodanie wielu ścieżek z audio do wyciętego fragmentu materiału (np. audio zawierające audiodeskrypcję) 30. (opcja) System umożliwi podstawową edycję wyciętego fragmentu materiału: crop, nałożenie overlay, dodawanie plansz na początku i na końcu materiału, obracania, fade-in, fade-out 31. System umożliwi użytkownikowi utworzenie zlecenia na utworzenie materiału wyjściowego na podstawie wyciętego fragmentu, z możliwością wyboru wielu stopklatek (proporcje: np. 4:3, 16:9) 32. (opcja) System umożliwi opisanie materiału wyjściowego przy pomocy zestawu metadanych technicznych, które będą zapisane w kontenerze wyjściowym zgodnie ze standardem definiującym klucze meta danych dla danego typu kontenera (zakres metadanych do uzgodnienia z Zamawiającym na etapie Projektu Technicznego) 33. (opcja) System uzupełni automatycznie metadane techniczne w zakresie, który może być wyekstrahowany z pliku z materiałem (np. czas trwania materiału, rozdzielczość) 34. (opcja) System wyświetli powiadomienia o zakończeniu operacji kodowania materiałów wyjściowych przez Transkoder 35. (opcja) System będzie aktualizował informację o statusie wszystkich obiektów podrzędnych skojarzonych z nadrzędnym obiektem wideo w CMS Zamawiającego (np. obiekty reprezentujące format m3u8 playlisty HLS, obiekty reprezentujące MP4) 36. System umożliwi wyświetlenie użytkownikowi aktualnych statusów kodowania materiałów wyjściowych (zawierających co najmniej informację o czasie ostatniej aktualizacji tego statusu) z wyciętego fragmentu 37. System umożliwi wznawianie kodowania materiału wyjściowego utworzonego na podstawie fragmentu wyciętego przez tego użytkownika w przypadku, kiedy poprzednie kodowanie tego materiału zakończyło się błędem Transkoder System umożliwi wykonywanie kodowanie wyciętego fragmentu, a w szczególności: 38. System umożliwi zakodowanie wyciętego fragmentu z wykorzystaniem profili do kodowania materiału wyjściowego (więcej o profilach kodowania materiału wyjściowego w opisie modułu Administracja) 8

9 39. System umożliwi bezbłędne zakodowanie wyciętego fragmentu z użyciem formatu: a. ISMV (H.264, AAC) 40. (opcja) System umożliwi bezbłędne zakodowanie wyciętego fragmentu z użyciem formatów, w tym m.in.: a. strumienie w następujących standardach: MPEG-DASH, Apple HLS, SmoothStreaming b. kontenery wyjściowe: MPEG-TS, MPEG-2, MPEG-4, strumieniowane pliki MP4, Apple MOV, 3GP, 3G2, Ogg, c. kodeki: AAC, AACP, AACPv2, MP2, MP3, H.265, Vorbis 41. System umożliwi zintegrowanie i wykorzystanie zewnętrznego narzędzia kodującego Unified Origin posiadanego przez Zamawiającego ( przy pomocy którego mogą być tworzone z plików ISMV strumienie w następujących standardach: a. SmoothStreaming b. Apple HLS c. strumieniowane pliki mp4 d. MPEG-DASH 42. System umożliwi tworzenie strumieni w następujących standardach: a. Apple HLS b. MKV 43. System umożliwi dla każdej instancji kontenera multimedialnego: a. możliwość pełnej i nieograniczonej konfiguracji w zakresie adresowania zasobów wyjściowych, np. foldery, URL-e, zasoby CDN Zamawiającego, protokół (np. CIFS, NFS) b. możliwość wybrania/ignorowania strumieni (np. audio, wideo, napisy, teletekst, audiodeskrypcja) c. możliwość pełnej i nieograniczonej konfiguracja w zakresie parametrów technicznych materiału wyjściowego (w oparciu o słowniki i krzyżówki per kontener + kodek, w celu wykonania przez System walidacji dozwolonych kombinacji tych parametrów), w tym m.in.: i. ilość ramek na sekundę ii. rozmiar ramki iii. rozdzielczość (w tym np. 2K, 4K) iv. proporcje v. przepływność vi. jakość vii. odstęp między klatkami kluczowymi viii. inne 44. System umożliwi równoległe kodowanie wielu wyciętych fragmentów jednocześnie, pochodzących z różnych zleceń od różnych użytkowników 45. (opcja) System umożliwi parametryzację w zakresie zarządzania archiwizacją plików po zakodowaniu (w tym usuwanie plików, jako opcja domyślna) 46. (opcja) System umożliwi ustawienie priorytetów dla przetwarzania zadań, których wynikiem jest zakodowanie materiałów (priorytety ustawiane względem: czasu trwania materiału, czasu pozostałego do zakończenia kodowania, liczby materiałów o krótkim czasie trwania, liczby materiałów o długim czasie trwania, priorytety ustawiane ręcznie przez użytkownika o odpowiednich uprawnieniach) 47. System będzie domyślnie ustawiał priorytety dla przetwarzania, uwzględniając równomierne rozkładania obciążenia na zasobach sprzętowych na których System zostanie zainstalowany i uruchomiony (szczegóły do ustalenia z Zamawiającym na etapie Projektu Technicznego) 48. System będzie gwarantował określony parametrami poziom przetwarzania zadań o niskim priorytecie 49. (opcja) System umożliwi zmianę priorytetów dla kodowanych materiałów bez konieczności zatrzymywania albo restartowania Systemu i/albo komponentów Systemu 50. (opcja) System umożliwi na żądanie użytkownika zatrzymanie i wznowienie kodowania materiału 51. System umożliwi podpięcie pod jego zdarzenia skrypty przetwarzające, przygotowane przez Zamawiającego (zakres zdarzeń Systemu do ustalenia z Zamawiającym na etapie Projektu Technicznego) 52. (opcja) System będzie na bieżąco monitorował przestrzeń zasobów wyjściowych, a w przypadku osiągnięcia przez tą przestrzeń wartości granicznej wstrzyma kodowanie dla nierozpoczętych zleceń zapisanych w kolejce do kodowania (System nie będzie jednak blokował przetwarzania materiałów, dla których kodowanie już trwa) (szczegóły do ustalenia z Zamawiającym na etapie Projektu Technicznego) 53. (opcja) System wznowi kodowanie nierozpoczętych zleceń zapisanych w kolejce do kodowania, niezwłocznie po wykryciu, kiedy zasoby przestrzeni osiągną wartość większą niż graniczna 9

10 3.4.4 Publikator System umożliwi realizację publikowania zakodowanego materiału, a w szczególności: 54. System umożliwi publikowanie materiałów wyjściowych na zdefiniowanych przez Zamawiającego zasobach, np. w CDN użytkowanym przez Zamawiającego (System ma umożliwiać konfigurację w zakresie definiowania tych zasobów) 55. System umożliwi publikowanie danych wyjściowych w zdefiniowanych przez Zamawiającego systemach, np. w CMS użytkowanym przez Zamawiającego (System ma umożliwiać konfigurację w zakresie definiowania tych zasobów) 56. (opcja) Po zakończeniu umieszczania materiałów wyjściowych na zdefiniowanych zasobach np. w CDN użytkowanym przez Zamawiającego, System musi odświeżyć nadrzędny obiekt wideo w CMS (realizowane przy pomocy zewnętrznego skryptu albo wywołania funkcja API udostępnianej przez CMS) w kontekście którego te materiały wyjściowe były kodowane 57. (opcja) W przypadku kiedy odświeżany obiekt wideo w CMS zawiera już inne materiały wyjściowe, System musi odpublikować istniejące już dla tego obiektu materiały wyjściowe (realizowane przy pomocy zewnętrznego skryptu albo wywołania funkcja API udostępnianej przez CMS), a następnie dopiero odświeżyć nadrzędny obiekt wideo w CMS 58. (opcja) System będzie gwarantował, że w przypadku braku dostępu do zasobu wyjściowego nie zostanie przerwane kodowanie materiału materiał nadal będzie kodowany i będzie składowany na zasobach wewnętrznych Systemu (tzw. CACHE) 59. (opcja) System będzie gwarantował, że w przypadku odzyskania dostępu do zasobu wyjściowego zakodowany materiał umieszczony na zasobach wewnętrznych Systemu (w tzw. CACHE) zostanie przeniesiony na zasoby zewnętrzne bez utraty jego spójności i parametrów technicznych materiału 60. System umożliwi podpięcie pod jego zdarzenia skrypty przetwarzające, przygotowane przez Zamawiającego (zakres zdarzeń Systemu do ustalenia z Zamawiającym na etapie Projektu Technicznego) API System umożliwi realizację funkcji poprzez API (API wystawione w formie REST, albo WebService, albo równoważnej), a w szczególności: 61. (opcja) System umożliwi wystawienie szczegółów zleceń utworzonych przez danego użytkownika z ostatnich 2/4/8/24 godzin, z ostatniego tygodnia/miesiąca, oraz wszystkich zleceń (funkcja może być użyta np. w celu wyświetlenia z poziomu CMS-a takiej listy w kontekście użytkownika) Moduł administracyjny System umożliwi realizację czynności administracyjnych, a w szczególności: 62. Logowanie do modułu administracyjnego będzie zabezpieczone mechanizmami uwierzytelniania domenowego z domen Zamawiającego 63. Moduł administracyjny będzie pozwalał na aktualny podgląd stanu kolejek przetwarzania materiałów 64. Moduł administracyjny będzie pozwalał na zarządzanie i sterowanie priorytetami zadań aktualnie przetwarzanych, oraz zadań znajdujących się w kolejce do przetworzenia 65. Dostępna będzie funkcjonalność pozwalająca na podgląd zakończonych zleceń (np. zarówno przetworzonych prawidłowo jak i zakończonych błędem) 66. Dostępna będzie funkcjonalność generowania statystyk przetwarzania materiałów (np. w zależności od typu materiału i z uwzględnieniem zakresu dat przetwarzania) 67. System umożliwi ponawianie materiałów, których przetwarzanie zakończyło się błędem 68. System umożliwi monitorowanie obciążenia komponentów systemu (np. z uwzględnieniem rozlokowania fizycznego) 69. Z poziomu panelu administracyjnego będzie możliwość podglądu historii przetwarzania materiału 70. Z poziomu panelu administracyjnego będzie możliwość indywidualnej modyfikacji priorytetu zlecenie W ramach czynności administracyjnych System umożliwi konfigurację, a w szczególności: 71. (opcja) Definiowanie profili i zarządzanie profilami dla weryfikacji materiału wejściowego, w tym m.in. parametryzacja każdego profilu w zakresie: 10

11 a. typu sygnału, np. plik, multicast, unicast b. rodzaju protokołu: np. HTTP, RTMP, RTSP c. parametrów strumienia, np. audio + wideo, tylko audio, audio + wideo + podpisy, audio + wideo + podpisy + teletekst, tylko wideo, wideo + podpisy d. typ technologii strumieniowania, np. Apple HLS, MPEG-DASH, SmoothStreaming e. typ kontenera multimedialnego: np. ISMV, MPEG-TS, Apple MOV, MP4, WMV, WAV, 3GP, 3G2, Ogg f. rodzaju kodeka, np. H.264, H.265, AAC, AACP, AACPv2, MP2, MP3, Vorbis g. parametrów technicznych: ilość ramek na sekundę, rozmiar ramki, rozdzielczość, proporcje, przepływność, jakość, inne h. szablonu nazw plików po zakodowaniu (do ustalenia z Zamawiającym na etapie Projektu Technicznego) i. szablonów nazw katalogów, w których będą umieszczane materiały wejściowe (do ustalenia z Zamawiającym na etapie Projektu Technicznego) j. zasobów wejściowych, np. foldery, URL-e, zasoby CDN Zamawiającego, protokół (np. CIFS, NFS) 72. (opcja) Definiowanie profili dla weryfikacji materiałów wejściowych z samym audio 73. Definiowanie profili i zarządzanie profilami dla kodowania materiału wyjściowego, w tym m.in. parametryzacja każdego profilu w zakresie: a. typu sygnału, np. plik, multicast, unicast b. rodzaju protokołu: np. HTTP, RTMP, RTSP c. parametrów strumienia, np. audio + wideo, tylko audio, audio + wideo + podpisy, audio + wideo + podpisy + teletekst, tylko wideo, wideo + podpisy d. typ technologii strumieniowania, np. Apple HLS, MPEG-DASH, SmoothStereaming e. typ kontenera multimedialnego: np. ISMV, MPEG-TS, Apple MOV, MP4, WMV, WAV, 3GP, 3G2, Ogg f. rodzaju kodeka, np. H.264, H.265, AAC, AACP, AACPv2, MP2, MP3, Vorbis g. grup parametrów technicznych dla profilu (w ramach zakodowania dla jednego profilu może powstać kilka wersji materiału różniących się np. rozdzielczością, proporcjami, jakością): ilość ramek na sekundę, rozmiar ramki, rozdzielczość, proporcje, przepływność, jakość, inne h. szablonu nazw plików po zakodowaniu (do ustalenia z Zamawiającym na etapie Projektu Technicznego) i. szablonów nazw katalogów, w których będą umieszczane materiały wyjściowe (do ustalenia z Zamawiającym na etapie Projektu Technicznego) j. zasobów wyjściowych, np. foldery, URL-e, zasoby CDN Zamawiającego, protokół (np. CIFS, NFS) 74. Definiowanie profili dla kodowania materiałów wyjściowych z samym audio 75. Definiowanie listy priorytetów dla zadań kodowania materiału zawierającej m.in. kolejność priorytetu na liście, powiązanie z parametrami technicznymi materiału (szczegóły do ustalenia z Zamawiającym na etapie Projektu Technicznego) Interfejsy W ramach wdrożenia Systemu w TVP konieczna jest również integracja z innymi Systemami Informatycznymi TVP. Poniżej przedstawiono opis kluczowych interfejsów, które muszą zostać zaimplementowane. Szczegóły integracji będą ustalone z Zamawiającym na etapie Projektu Technicznego INTERFEJS WYCINARKA <-> CMS 76. Uruchomienie panelu definiowania zleceń z poziomu zewnętrznego systemu CMS, wraz z przekazaniem przez CMS identyfikatora nadrzędnego obiektu wideo 77. Zapis informacji o zakodowanym materiale wyjściowym i obiektach powiązanych z tym materiałem w CMS 78. (opcja) Odświeżanie opublikowanych obiektów w CMS 79. (opcja) Odpublikowanie materiałów w obiekcie w CMS INTERFEJS WYCINARKA -> CDN 80. Zapis materiałów wyjściowych w zasobach systemu CDN 11

12 MECHANIZM PODPINANIA POD ZDARZENIA I URUCHAMIANIA SKRYPTÓW ZEWNĘTRZNYCH 81. Zarządzanie podpinaniem pod zdarzenia skryptów Zamawiającego 82. Uruchamianie skryptów zewnętrznych Zamawiającego 83. Rejestracja i przetwarzanie danych zwróconych przez uruchomiane skrypty Zamawiającego (szczegóły do ustalenia z Zamawiającym na etapie Projektu Technicznego) 3.5 Wymagania niefunkcjonalne Architektura (A) System (i wszystkie jego komponenty składowe) musi zapewnić bezbłędne działanie i wydajność nie gorszą od wymaganej, na następującej infrastrukturze Zamawiającego: 1. Serwery fizyczne (Linux): a. 5 serwerów: Intel Xeon E GHz, 16GB RAM, Debian GNU/Linux b. 6 serwerów: Intel Xeon X GHz, 16GB RAM, Debian GNU/Linux c. 7 serwerów: Intel Xeon X GHz, 16GB RAM, Debian GNU/Linux d. 1 serwer: Intel Xeon X GHz, 24GB RAM, Debian GNU/Linux e. 1 serwer: Intel Xeon E v2 2.10GHz, 32GB RAM, Debian GNU/Linux f. 2 serwery: Intel Xeon E v2 2.10GHz, 64GB RAM, Debian GNU/Linux g. 1 serwer: Intel Xeon X GHz, 16GB RAM, Debian GNU/Linux h. 2 serwery: Intel Xeon X GHz, 96GB RAM, Debian GNU/Linux (jeden z nich jest też częścią systemu dystrybucji treści Zamawiającego) i. 2 serwery: Intel Xeon E v4,64 GB RAM, Debian GNU/Linux 2. Serwery wirtualne (Linux): a. 4 maszyny wirtualne: KVM, Debian GNU/Linux b. 1 maszyna wirtualna: VMware, Debian GNU/Linux 3. Na serwerach fizycznych i wirtualnych zainstalowany będzie system operacyjny Debian GNU/Linux Jessie albo wyższa wersja stabilna Debian GNU/Linux 4. Zamawiający dysponuje zasobami o pojemności do 18 TB które mogą być wykorzystane przez Wykonawcę (fizycznie jest to kilka zasobów rozproszonych) Wykonawca uzgodni z Zamawiającym docelową architekturę Systemu na etapie Projektu Technicznego. Niezawodność (N) Wymagania związane z poprawnością wyników Systemu, akceptowalnego czasu pomiędzy awariami, raportami poprawności działania i mechanizmami naprawczymi. 5. Architektura Systemu będzie pozbawiona pojedynczego punktu awarii 6. Architektura Systemu będzie umożliwiała skalowanie Systemu (m.in. w zakresie dodawanie nowych źródeł sygnału wejściowego do zarejestrowania) 7. Wykonawca zapewni, że w przypadku awarii krytycznej środowiska produkcyjnego będzie możliwość ponownej instalacji Systemu na środowisku zapasowym 8. Wykonawca stworzy plan realizacji backupu danych oraz będzie nadzorował jego wdrożenie. 9. Wykonawca zapewni dla środowiska produkcyjnego, że dopuszczalny czas, z którego dane mają zostać przywrócone nie będzie dłuższy niż 24 godziny (ang. Recovery Point Objective RPO). 10. Wykonawca zapewni dla środowiska produkcyjnego, że dopuszczalny czas, w którym System ma zostać przywrócony nie będzie dłuższy niż 24 godziny (ang. Recovery Time Objective RTO). 11. Wykonawca zapewni możliwość wykonania spójnej kopii bezpieczeństwa Systemu w trakcie jego pracy. 12. Wykonawca zapewni, że System nie będzie przechowywał haseł w postaci jawnej. 13. Wykonawca zapewni mechanizmy redundancji składowania danych np. składowanie backupów danych w innym środowisku niż środowisko produkcyjne, aby zapewnić dostęp do danych w przypadku awarii serwera bazy danych. 14. Wykonawca zrealizuje System działający w trybie 24 godz. 7 dni w tygodniu z możliwością zaplanowania okna serwisowego w ilości nie większej niż 100 godzin rocznie o dopuszczalnym czasie trwania do 1 godziny w godzinach 8:00 18:00 oraz 4 godzin w pozostałych godzinach doby. 12

13 15. Wykonawca zapewni, że w czasie trwania okna serwisowego System musi co najmniej generować stronę informującą o tym fakcie. 16. System będzie przechowywał informacje o działaniach wykonywanych przez System tzw. logów przez minimum 40 dni. 17. System musi posiadać mechanizm bieżącej archiwizacji logów operacji 18. System zapewni logowanie błędów z odpowiednią ich kategoryzacją (np. ostrzeżenie, błąd), wraz ze szczegółowym biznesowym opisem błędu (np. dlaczego z przyczyn biznesowych dana operacja nie doszła do skutku, z jakich powodów walidacja zakończyła się wynikiem negatywnym itd.) 19. Architektura Systemu musi zapewniać możliwość jego wdrożenia w środowisku wysokiej dostępności 20. Architektura System musi zapewniać jego skalowanie w zakresie zwiększania liczby użytkowników oraz zasobów dedykowanych do zadań kodowania i zakodowania materiałów (bez zwiększania liczby licencji) Wydajność (W) System posadowiony na infrastrukturze Zamawiającego osiągnie wydajność nie gorszą niż: 21. System umożliwi na pojedynczym węźle systemu jednostrumieniowe przekodowanie materiału wejściowego 1920x1080@25i (H.264; do 10Mb/s) bez zmiany rozdzielczości i ilości klatek na sekundę o przepływności wyjściowego strumienia wideo 1920x1080@25p 10Mb/s, z wykorzystaniem na wyjściu kodeka H.264 (o parametrach tożsamych z profilem medium kodeka x264) i kontenera MP4, w czasie poniżej 25% czasu rzeczywistego (czas mierzony od zlecenia przekodowania do uzyskania gotowych plików dystrybucyjnych na dysku lokalnym serwera obsługującego węzeł) 22. System umożliwi na pojedynczym węźle systemu wieloprofilowe przekodowanie materiału źródłowego 1920x1080@25i (H.264; do 10Mb/s) bez zmiany ilości klatek na sekundę, w rozdzielczościach 1920x1080@25p (10Mb/s), 1280x720@25p (5.4Mb/s), 960x540@25p (2.7Mb/s), 800x450@25p (1.7Mb/s), 640x360@25p (1.2Mbs), 480x270@25p (830Kb/s) 398x224@25p (580Kb/s) z wykorzystaniem na wyjściu kodeka H.264 (o parametrach tożsamych z profilem medium kodeka x264) i kontenera MP4 w czasie poniżej 50% czasu rzeczywistego (czas mierzony od zlecenia przekodowania do uzyskania wszystkich gotowych plików dystrybucyjnych we wszystkich wymaganych jakościach na dysku lokalnym serwera obsługującego węzeł) 23. System ma umożliwić skalowalność zbliżoną do liniowej (skalowalność przetwarzania równoległego - przy 4 węzłach czas przetwarzania powinien być co najmniej 3 krotnie krótszy niż czas przetwarzania dla samodzielnego węzła) Wspieralność (S) Wymagania związane z dostępem do zapisu operacji, kompatybilnością, konfigurowalnością, łatwością instalacji, szybkością naprawy i poziomu testowania Systemu. 24. Po wdrożeniu produkcyjnym, Wykonawca przekaże wszelkie hasła administracyjne występujące w elementach składowych infrastruktury Systemu wraz z instrukcją zmiany tych haseł po akceptacji wdrożenia produkcyjnego. 25. Po wdrożeniu produkcyjnym, Wykonawca przekaże prawa do kodów źródłowych aplikacji wykonanych w trakcie wdrożenia Systemu w TVP. TVP będzie dysponować tymi prawami w sposób nieograniczony i na wszelkich polach eksploatacji. 26. Wykonawca dostarczy dokumentacją programistyczną umożliwiającą wykonanie przez TVP lub przez wskazaną przez TVP firmę trzecią prostych napraw i zmian Systemu w uzgodnionym zakresie i trybie procedowania takich zmian np. mechanizm dokumentowania wprowadzonych zmian. 27. Po wdrożeniu produkcyjnym, Wykonawca przekaże kody źródłowe (w postaci patchset-ów) do zaimportowania ich repozytorium Git funkcjonującego w TVP. 28. W trakcie trwania gwarancji w przypadku naprawy zgłoszonych błędów lub zmian powodujących zmianę tego kodu, Wykonawca każdorazowo dokona skutecznej dostawy aktualizacji kodów źródłowych (w postaci patchset-ów) w sposób umożliwiający automatyczną aktualizację kodów w repozytorium Git Zamawiającego oraz automatyczny build włącznie z weryfikacją poprawności budowania aplikacji. Wdrożenie rozwiązania, które będzie wymagało kompilowania kodów źródłowych będzie odbywało się z repozytorium Git funkcjonującego w TVP. 29. Zamawiający udostępni na czas obowiązywania gwarancji dostęp do własnego systemu zgłaszania błędów i zmian np. JIRA, FogBugz, Bugzilla lub równoważne. 30. Wykonawca zrealizuje interfejsy do zewnętrznych systemów z wykorzystaniem protokołów SOAP lub REST (usługi WebServices) albo z wykorzystaniem mechanizmów bazodanowych. Każdy przypadek wykorzystania innego typu interfejsu wymaga każdorazowego potwierdzenia przez TVP na zasadzie wyjątku architektonicznego 13

14 i takie ustalenia mogą zostać podjęte w ramach odbioru Projektu Technicznego. Wykonawca przekaże wszelkie niezbędne do działania Systemu licencje (software) nieograniczone czasowo oraz zapewni ich wsparcie przez certyfikowanego w zakresie tej technologii Wykonawcę na minimum 1 rok od momentu pierwszego wdrożenia produkcyjnego. Wykonawca przekaże listę tych licencji ze wskazaniem Wykonawców świadczących usługę wsparcia. 31. Wykonawca zapewni dostarczenie co najmniej środowiska produkcyjnego i testowego, które będą zlokalizowane na dwóch platformach sprzętowych Zamawiającego, na których będzie zainstalowane oprogramowanie systemowe wskazane w wymaganiach niefunkcjonalnych Architektura (A). 32. W ramach gwarancji przewidzianej w Umowie Wykonawca będzie zobowiązany, po odbiorze wdrożenia produkcyjnego do momentu zakończenia okresu gwarancji, do realizacji następujących czasów reakcji oraz czasów naprawy błędów (ang. Service Level Agreement SLA): Kategoria błędu Czas reakcji Czas Czas obejścia Błąd krytyczny tj. brak możliwości korzystania z Systemu powodujący brak możliwości realizacji transkodowania materiałów Błąd poważny tj. błąd niekrytyczny, który jednak powoduje brak możliwości realizacji wymagania. Błąd drobny tj. błąd inny niż krytyczny naprawy 2 godziny 24 godziny 12 godzin 4 godziny 48 godziny 24 godziny 1 dzień 5 dni 5 dni lub poważny. a) Czas reakcji jest rozumiany jako czas liczony od momentu zgłoszenia wykonanego przez Zamawiającego do momentu odpowiedzi przez Wykonawcę. b) Czas naprawy jest rozumiany jako czas liczony od momentu zgłoszenia przez Zamawiającego do momentu usunięcia przez Zamawiającego wady, przywrócenia poprawnego działania. c) Czas obejścia jest rozumiany jako czas liczony od momentu zgłoszenia przez Zamawiającego do momentu zminimalizowania uciążliwości wady i doprowadzenia do przywrócenia prawidłowego działania komponentu. Obejście nie stanowi usunięcia wady, ale pozwala korzystać nieprzerwanie z wszystkich funkcjonalności dostarczanego Systemu. d) Powyższa tabela obowiązuje Wykonawcę w trybie 24/7 tj. 24 godziny na dobę 7 dni w tygodniu. 33. W ramach gwarancji przewidzianej w Umowie Wykonawca będzie zobowiązany, po odbiorze pierwszego wdrożenia do momentu zakończenia projektu, do wsparcia typu pytanie i odpowiedź przy założeniu, że Zamawiający będzie grupował swoje pytania i wysyłał je zbiorczo nie częściej niż 1 raz dziennie. Wykonawca jest zobligowany do udzielenia merytorycznej odpowiedzi na takie pytania w przeciągu nie dłużej niż 2 dni roboczych i ewentualnego pogłębienia swojej odpowiedzi w formie rozmowy telefonicznej lub spotkania. 34. W ramach gwarancji przewidzianej w Umowie Wykonawca zapewni i przeprowadzi dostosowanie oprogramowania dedykowanego do oprogramowania standardowego w przypadku wprowadzenia nowej wersji tego oprogramowania (kompatybilność z najnowszą wersją oprogramowania standardowego). 35. Wykonawca w uzgodnieniu z Zamawiającym będzie przeprowadzał aktualizacje oprogramowania standardowego w okresie gwarancyjnym 14

15 Część 2 zamówienia - Dostawa serwerów Informacja: we wszystkich poniższych opisach zadania Zamawiający rozumie 1 MB jako jeden milion bajtów (10 6 ), 1 GB jako jeden miliard bajtów (10 9 ) oraz 1 TB jako jeden bilion bajtów (10 12 ). 1. Serwery w konfiguracji "A" Wykonawca dostarczy cztery sztuki serwera typu rack : Lp. Parametr Wymagania 1. Obudowa Typu rack, nie wyższa niż 2 U, z dostarczonym zestawem do montażu w standardowym stojaku lub szafie komputerowej U. 2. Procesory Co najmniej dwa procesory, każdy umożliwiający wykonywanie kodu maszynowego w obliczeniach 64-bitowych, w co najmniej 24 wątkach. Jako odniesienie Zamawiający przyjmuje, że wynik bazowy powszechnie dostępnego testu SPEC CPU2006 dla danego systemu nie może być mniejszy niż Pamięć operacyjna Co najmniej 128 GB pamięci RAM w technologii DDR3 lub nowszej, single- lub dual-rank. 4. Nośniki danych Co najmniej dwa nośniki HDD o pojemności pojedynczego nośnika nie mniejszej niż 300GB, o wydajności odpowiadającej nośnikowi SATA 7200rpm. Nośniki półprzewodnikowe (SSD) w technologii NVMe, o sumarycznej pojemności nie mniejszej niż 8 TB i wydajności i wytrzymałości pojedynczego nośnika: odczyt liniowy: min. 3000MB/s, zapis liniowy: min. 1800MB/s, odczyt losowy bloków 4kb przy 32 wątkach: min 350 kiops, zapis losowy bloków 4kb przy 32 wątkach: min. 300 kiops; MTBF: min 1 mln godzin. Nośniki muszą być podłączone i uruchomione, tj. muszą zostać dostarczone i podłączone wszystkie niezbędne interfejsy i okablowanie, umożliwiające uruchomienie nośników w technologii NVMe. 5. Urządzenia we/wy Co najmniej dwa interfejsy LAN 1 GbE 1000BASE-T umożliwiające podłączenie do sieci Ethernet okablowaniem kat 6. Co najmniej dwa interfejsy LAN 10GbE z wkładkami SFP+, umożliwiające podłączenie do sieci Ethernet okablowaniem światłowodowym MultiMode. Co najmniej jedno wolne złącza PCI Express 3.0 x8 umożliwiające montaż dodatkowej karty. Co najmniej 6 dodatkowych wolnych slotów umożliwiających podłączenie dysków SAS/SATA, bez konieczności zakupu dodatkowych komponentów. 6. Zarządzanie - in-band, z poziomu systemu operacyjnego odpowiednie oprogramowanie oraz instrukcja instalacji musi być dostarczona wraz z urządzeniem; oprogramowanie tego typu musi działać pod kontrolą systemu Linux w dystrybucji Red Hat Enterprise Server (lub 15

16 odpowiednika np. CentOS) oraz Debian Linux 7 (lub odpowiednika np. Ubuntu Linux w wersji LTS); - out-of-band niezależny od systemu operacyjnego, sprzętowy kontroler (karta) realizująca wszystkie opisane poniżej funkcje i cechy: - pełne zarządzanie oraz zdalny restart serwera; - zarządzanie za pomocą konsoli graficznej dostępnej z poziomu przeglądarki internetowej w kanale szyfrowanym; - dedykowane złącze Ethernet BASE-T; - z poziomu przeglądarki musi być możliwość zarządzania systemem operacyjnym w sposób graficzny, po rozruchu; - możliwość podłączenia wirtualnych nośników danych, prezentowanych systemowi operacyjnemu jako nośnik danych; - zdalne zarządzanie z wykorzystaniem protokołu IPMI 2.0; - wbudowane mechanizmy zarządzania mocą i jej zużyciem oraz monitoring zużycia energii zgodne z pakietem oprogramowania cpufrequtils; - wbudowane mechanizmy zarządzania alarmami i zdarzenia poprzez SNMP; - karta zarządzająca musi mieć możliwość wysyłania powiadomień SMNP (tzw. traps); - możliwość przejęcia konsoli tekstowej systemu operacyjnego (np. w technologii SoL). Wszystkie powyższe opcje muszą być zainstalowane i dostępne dla administratora bez konieczności wykupienia dodatkowych licencji. 8. Zasilanie i chłodzenie co najmniej 2 redundantne zasilacze, każdy o mocy wystarczającej do zasilania systemu przy pełnym obciążeniu, z certyfikatem typu 80 Plus Gold ; zasilacze typu hot-plug, dostosowane do zasilania napięciem 230 VAC ±10% 50 Hz, zgodnie z PN-IEC60038, wraz z kablami zasilającymi typu C13-C14, po jednym kablu dla każdego zasilacza; chłodzenie redundantne, z poziomem zabezpieczenia N+1 c) Wymagania wydajnościowe dla konfiguracji "A": Zamawiający wymaga, aby serwery spełniały wymagania wydajnościowe zgodnie z procedurą testową opisaną w punkcie 4: - sumaryczny jednoczesny zapis i odczyt z nośników SSD co najmniej 30Gbps odczyt/12gpbs zapis - jednoczesne nadawanie i odbieranie danych na interfejsie bond co najmniej: 18,6 Gbps nadawanie, 16.5 Gbps odbieranie - jednoczesnie co najmniej: sumaryczny odczyt z nośników SSD min. 20 Gbps, sumaryczny zapis z nośników SSD min. 5 Gbps, nadawanie na interfejsie bond min. 18,6 Gbps, odbieranie min. 5 Gbps. 16

17 2. Serwery w konfiguracji "B" Wykonawca dostarczy cztery sztuki serwera typu rack : Lp. Parametr Wymagania 1. Obudowa Typu rack, nie wyższa niż 2 U, z dostarczonym zestawem do montażu w standardowym stojaku lub szafie komputerowej U. 2. Procesory Co najmniej dwa procesory, każdy umożliwiający wykonywanie kodu maszynowego w obliczeniach 64-bitowych, w co najmniej 24 wątkach. Jako odniesienie Zamawiający przyjmuje, że wynik bazowy powszechnie dostępnego testu SPEC CPU2006 dla danego systemu nie może być mniejszy niż Pamięć operacyjna Co najmniej 128 GB pamięci RAM w technologii DDR3 lub nowszej, single- lub dual-rank. 4. Nośniki danych Co najmniej dwa nośniki HDD o pojemności pojedynczego nośnika nie mniejszej niż 300GB, o wydajności odpowiadającej nośnikowi SATA 7200rpm. Nośniki półprzewodnikowe (SSD) w technologii NVMe, o sumarycznej pojemności nie mniejszej niż 2 TB i wydajności i wytrzymałości pojedynczego nośnika: odczyt liniowy: min. 3000MB/s, zapis liniowy: min. 1800MB/s, odczyt losowy bloków 4kb przy 32 wątkach: min 350 kiops, zapis losowy bloków 4kb przy 32 wątkach: min. 300 kiops; MTBF: min 1 mln godzin. Nośniki muszą być podłączone i uruchomione, tj. muszą zostać dostarczone i podłączone wszystkie niezbędne interfejsy i okablowanie, umożliwiające uruchomienie nośników w technologii NVMe. 5. Urządzenia we/wy Co najmniej dwa interfejsy LAN 1 GbE 1000BASE-T umożliwiające podłączenie do sieci Ethernet okablowaniem kat 6. Co najmniej cztery interfejsy LAN 10GbE z wkładkami SFP+, umożliwiające podłączenie do sieci Ethernet okablowaniem światłowodowym MultiMode. Co najmniej jedno wolne złącza PCI Express 3.0 x8 umożliwiające montaż dodatkowej karty. 6. Zarządzanie - in-band, z poziomu systemu operacyjnego odpowiednie oprogramowanie oraz instrukcja instalacji musi być dostarczona wraz z urządzeniem; oprogramowanie tego typu musi działać pod kontrolą systemu Linux w dystrybucji Red Hat Enterprise Server (lub odpowiednika np. CentOS) oraz Debian Linux 7 (lub odpowiednika np. Ubuntu Linux w wersji LTS); - out-of-band niezależny od systemu operacyjnego, sprzętowy kontroler (karta) realizująca wszystkie opisane poniżej funkcje i cechy: - pełne zarządzanie oraz zdalny restart serwera; - zarządzanie za pomocą konsoli graficznej dostępnej z poziomu 17

18 przeglądarki internetowej w kanale szyfrowanym; - dedykowane złącze Ethernet BASE-T; - z poziomu przeglądarki musi być możliwość zarządzania systemem operacyjnym w sposób graficzny, po rozruchu; - możliwość podłączenia wirtualnych nośników danych, prezentowanych systemowi operacyjnemu jako nośnik danych; - zdalne zarządzanie z wykorzystaniem protokołu IPMI 2.0; - wbudowane mechanizmy zarządzania mocą i jej zużyciem oraz monitoring zużycia energii zgodne z pakietem oprogramowania cpufrequtils; - wbudowane mechanizmy zarządzania alarmami i zdarzenia poprzez SNMP; - karta zarządzająca musi mieć możliwość wysyłania powiadomień SMNP (tzw. traps); - możliwość przejęcia konsoli tekstowej systemu operacyjnego (np. w technologii SoL). Wszystkie powyższe opcje muszą być zainstalowane i dostępne dla administratora bez konieczności wykupienia dodatkowych licencji. 8. Zasilanie i chłodzenie co najmniej 2 redundantne zasilacze, każdy o mocy wystarczającej do zasilania systemu przy pełnym obciążeniu, z certyfikatem typu 80 Plus Gold ; zasilacze typu hot-plug, dostosowane do zasilania napięciem 230 VAC ±10% 50 Hz, zgodnie z PN-IEC60038, wraz z kablami zasilającymi typu C13-C14, po jednym kablu dla każdego zasilacza; chłodzenie redundantne, z poziomem zabezpieczenia N+1 c) Wymagania wydajnościowe dla konfiguracji "B": Zamawiający wymaga, aby serwery spełniały wymagania wydajnościowe zgodnie z procedurą testową opisaną w punkcie 4: - sumaryczny jednoczesny liniowy zapis i odczyt z nośników SSD co najmniej 24 Gbps odczyt/12 Gpbs zapis - jednoczesne nadawanie i odbieranie danych na interfejsie bond co najmniej: 37 Gbps nadawanie, 32 Gbps odbieranie - jednoczesnie co najmniej: sumaryczny odczyt z nośników SSD 20 Gbps, sumaryczny zapis z nośników SSD 5 Gbps, nadawanie na interfejsie bond 36 Gbps, odbieranie 6 Gbps. 3. Serwery w konfiguracji "C" Wykonawca dostarczy dwie sztuki serwera typu rack : a) konfiguracja podstawowa: Lp. Parametr Wymagania 1. Obudowa Typu rack, nie wyższa niż 2 U, z dostarczonym zestawem do 18

19 montażu w standardowym stojaku lub szafie komputerowej U. 2. Procesory Co najmniej dwa procesory, każdy umożliwiający wykonywanie kodu maszynowego w obliczeniach 64-bitowych, w co najmniej 24 wątkach. Jako odniesienie Zamawiający przyjmuje, że wynik bazowy powszechnie dostępnego testu SPEC CPU2006 dla danego systemu nie może być mniejszy niż Pamięć operacyjna Co najmniej 32 GB pamięci RAM w technologii DDR3 lub nowszej, single- lub dual-rank. 4. Nośniki danych Co najmniej dwa nośniki SAS o pojemności pojedynczego nośnika nie mniejszej niż 300GB, o wydajności odpowiadającej nośnikowi SAS 10krpm. 6. Urządzenia we/wy Co najmniej dwa interfejsy LAN 1 GbE 1000BASE-T umożliwiające podłączenie do sieci Ethernet okablowaniem kat Zarządzanie - in-band, z poziomu systemu operacyjnego odpowiednie oprogramowanie oraz instrukcja instalacji musi być dostarczona wraz z urządzeniem; oprogramowanie tego typu musi działać pod kontrolą systemu Linux w dystrybucji Red Hat Enterprise Server (lub odpowiednika np. CentOS) oraz Debian Linux 7 (lub odpowiednika np. Ubuntu Linux w wersji LTS); - out-of-band niezależny od systemu operacyjnego, sprzętowy kontroler (karta) realizująca wszystkie opisane poniżej funkcje i cechy: - pełne zarządzanie oraz zdalny restart serwera; - zarządzanie za pomocą konsoli graficznej dostępnej z poziomu przeglądarki internetowej w kanale szyfrowanym; - dedykowane złącze Ethernet - z poziomu przeglądarki musi być możliwość zarządzania systemem operacyjnym w sposób graficzny, po rozruchu; - możliwość podłączenia wirtualnych nośników danych, prezentowanych systemowi operacyjnemu jako nośnik danych; - zdalne zarządzanie z wykorzystaniem protokołu IPMI 2.0; - wbudowane mechanizmy zarządzania mocą i jej zużyciem oraz monitoring zużycia energii zgodne z pakietem oprogramowania cpufrequtils; - wbudowane mechanizmy zarządzania alarmami i zdarzenia poprzez SNMP; - karta zarządzająca musi mieć możliwość wysyłania powiadomień SMNP (tzw. traps); - możliwość przejęcia konsoli tekstowej systemu operacyjnego (np. w technologii SoL). Wszystkie powyższe opcje muszą być zainstalowane i dostępne dla administratora bez konieczności wykupienia dodatkowych licencji. 8. Zasilanie i chłodzenie co najmniej 2 zasilacze, każdy o mocy min. 500 W, z certyfikatem typu 80 Plus Gold ; zasilacze typu hot-plug, dostosowane do 19