Národní knihovna České republiky
SMLOUVA O POSKYTOVÁNÍ SLUŽEB SYSTÉMOVÉHO INTEGRÁTORA
Smluvní strany:
Národní knihovna České republiky
IČ: 00023221
se sídlem Praha 1, Klementinum 190, PSČ 110 01, jejímž jménem jedná Xxx. Xxxxx Xxxx, generální ředitel
(dále jen „Národní knihovna“ nebo „Objednatel“)
číslo smlouvy:
a
Logica Czech Republic s.r.o.
se sídlem: Praha 6, Na Okraji 335/42, PSČ: 162 00 IČ: 624 12 388, DIČ: CZ 62412388
společnost zapsaná v obchodním rejstříku vedeném Městským soudem v Praze,
xxxxx X, vložka 34304
bank. spojení: ING Bank N.V., č. účtu: 1000466200/3500
jejímž jménem jedná Xxx. Xxxxx Xxxxxxx, jednatel (dále jen „Poskytovatel“)
číslo smlouvy:
dnešního dne uzavřely tuto smlouvu v souladu s ustanovením § 269 odst. 2 a s přihlédnutím k § 536 a násl. zákona č. 513/1991 Sb., obchodní zákoník, ve znění pozdějších předpisů (dále jen „Obchodní zákoník“)
(dále jen „Smlouva“)
Smluvní strany, vědomy si svých závazků ve Xxxxxxx obsažených a s úmyslem být Smlouvou vázány, dohodly se na následujícím znění Smlouvy:
1. ÚVODNÍ USTANOVENÍ
1.1 Objednatel prohlašuje, že
1.1.1 je právnickou osobou – státní příspěvkovou organizací, jejíž zřízení, působnost, zásady činnosti a organizace jsou stanoveny ve statutu Národní knihovny České republiky vydaném ve formě rozhodnutí ministra kultury České republiky;
1.1.2 splňuje veškeré podmínky a požadavky v této Smlouvě stanovené a je oprávněn tuto Smlouvu uzavřít a řádně plnit závazky v ní obsažené;
1.2 Poskytovatel prohlašuje, že
1.2.1 je právnickou osobou řádně založenou a existující podle českého právního řádu;
1.2.2 splňuje veškeré podmínky a požadavky v této Smlouvě stanovené a je oprávněn tuto Smlouvu uzavřít a řádně plnit závazky v ní obsažené.
2. ÚČEL SMLOUVY
2.1 Objednatel je hlavním realizátorem a garantem projektu s názvem
„VYTVOŘENÍ NÁRODNÍ DIGITÁLNÍ KNIHOVNY", který byl schválen jako projektový záměr Usnesením vlády ČR ze dne 14. 5. 2008 č. 536 o strategických projektových záměrech pro čerpání prostředků ze Strukturálních fondů EU v rámci Smart Administration pod číslem 116, a to pod registračním číslem projektu CZ.1.06/1.1.00/07.06386 (dále jen „Projekt NDK“). Bližší popis a specifikace Projektu NDK jsou obsaženy v Příloze č. 5 Zadávací dokumentace ve smyslu této Smlouvy s názvem „Popis stávajícího stavu“.
2.2 Projekt NDK bude financován s využitím finanční podpory poskytované z Evropského fondu regionálního rozvoje v rámci Integrovaného operačního programu (IOP). Projekt NDK bude realizován v partnerství Objednatele a Moravské zemské knihovny (dále jen „MZK“). Cílem Projektu NDK je vytvoření fungujícího systému „Národní digitální knihovny“ jako součásti vznikající České digitální knihovny a Europeany (Evropské digitální knihovny). Za účelem dosažení výše uvedených cílů a za účelem vytvoření složitého a komplexního informačního systému „Národní digitální knihovny“ (dále jen
„IS NDK“), který se skládá ze čtyř subsystémů - subsystému digitalizace, subsystému dlouhodobého uložení dokumentů (LTP subsystém), subsystému pro transformace a kontroly konzistence (transformační modul) a subsystému zpřístupnění informací a dokumentů - a řady vzájemné propojených technických komponent, potřebuje Objednatel technicky, administrativně a procesně zkušeného a erudovaného partnera, Poskytovatele, který za tímto účelem poskytne Objednateli veškeré potřebné
2
know-how, technické, projektové a administrativní znalosti a zkušenosti pro | |||
úspěšné navržení, vytvoření a provoz IS NDK a ostatních komponent Projektu | |||
NDK. Poskytovatel bude při realizaci | Projektu | NDK spolupracovat také | |
s osobou hájící zájmy Objednatele, | která byla | vybrána Objednatelem | |
v samostatném zadávacím řízení (dále jen „Projektový manager“). | |||
2.3 | Pro dosažení výše uvedeného účelu | uveřejnil Objednatel dne 4.7.2011 | |
v Informačním systému o veřejných zakázkách pod evidenčním číslem VZ 60062201 oznámení otevřeného řízení na zadání veřejné zakázky s názvem
„Systémový integrátor projektu Vytvoření Národní digitální knihovny“ (dále jen „Veřejná zakázka“). Na základě zadávacího řízení byla pro plnění Veřejné zakázky vybrána nabídka Poskytovatele v souladu s ustanovením § 81 odst. 1 zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen „ZVZ“). V souladu s ustanovením § 82 odst. 2 ZVZ smluvní strany uzavírají Smlouvu.
2.4 Poskytovatel Smlouvou garantuje Objednateli splnění zadání Veřejné zakázky a všech z toho vyplývajících podmínek podle zadávací dokumentace Veřejné zakázky, která tvoří volnou přílohu Smlouvy jako její Příloha č. 7 (dále jen „Zadávací dokumentace“). Tato garance je nadřazena ostatním podmínkám a garancím uvedeným ve Smlouvě. Pro vyloučení jakýchkoliv pochybností to znamená, že
2.4.1 v případě jakéhokoliv rozporu Smlouvy a Zadávací dokumentace se uplatní výslovné, závazné a konkrétní ustanovení Zadávací dokumentace, nerozhodne-li Objednatel jinak; a
2.4.2 v případě chybějících ustanovení Smlouvy budou použita dostatečně konkrétní ustanovení Zadávací dokumentace.
3. PŘEDMĚT SMLOUVY
3.1 Poskytovatel se touto Smlouvou zavazuje poskytnout Objednateli plnění spočívající v navržení, vybudování (implementaci), dodávce IS NDK a dalších komponent komplexního informačního systému „Národní digitální knihovny“ v rámci Projektu NDK (dále jen „Systém“). Poskytovatel se jako hlavní dodavatel Systému zavazuje k provedení dodávek veškerého potřebného software a hardware a k vybudování (implementaci) Systému tvořeného jednotlivými subsystémy (moduly). Systém je tvořen:
3.1.1 technickou, systémovou a síťovou infrastrukturou společnou pro jednotlivé subsystémy (moduly) ve smyslu odst. 3.1.2 až 3.1.5 Smlouvy včetně zahájení provozu workflow digitalizace;
3.1.2 subsystémem digitalizace;
3.1.3 subsystémem dlouhodobého uložení dokumentů (LTP subsystém);
3.1.4 subsystémem pro transformace a kontroly konzistence (transformační modul); a
3.1.5 subsystémem zpřístupnění informací a dokumentů.
3.2 Součástí plnění dle této Smlouvy je rovněž poskytování služby systémové integrace, kdy Poskytovatel zabezpečí, že Systém bude plně integrován a provázán se stávajícími systémy a prvky Projektu NDK, které již u
3.3 Poskytovatel se dále po dobu účinnosti této Smlouvy zavazuje řádně poskytovat službu podpory provozu a maintenance Systému a jeho jednotlivých subsystémů ve smyslu odst. 3.1.1 až 3.1.5 Smlouvy, a to nejpozději ode dne akceptace posledního ze subsystémů ve smyslu odst.
3.1.1 až 3.1.5 Smlouvy postupem dle této Smlouvy, a to v požadované kvalitě a úrovních (SLA) a rovněž se zavazuje poskytovat aktualizaci software nebo zajistit software maintenance od výrobce, to vše do 31. prosince 2014 (dále jen „Podpora“). V úvodní fázi poskytování Podpory a jako její součást se Poskytovatel zavazuje k testování, ověření funkčnosti a vyhodnocení fungování Systému a jeho jednotlivých subsystémů ve smyslu odst. 3.1.1 až
3.1.5 Xxxxxxx, k optimalizaci workflow, podpoře digitalizace a tvorby metadat, podpoře konverze existujících dat, a to po dobu pěti (5) měsíců v souladu s Přílohou č. 8 Zadávací dokumentace a dle Specifikace plnění ve smyslu této Smlouvy (dále jen „pilotní provoz“).
(Systém, Systémová integrace a Podpora dále společně také jen „Plnění“).
3.4 V rámci poskytování Plnění se Poskytovatel zavazuje rovněž k:
3.4.1 provedení analýzy požadavků Objednatele na Systém (dále jen
„Analýza“);
3.4.2 vypracování Prováděcího projektu, který konkretizuje vymezení jednotlivých plnění dle Specifikace plnění a bude obsahovat také návrh řešení Systému a bude výstupem provedené Analýzy, přičemž jeho rámcový obsah je uveden v Příloze č. 7 Zadávací dokumentace (dále jen „Prováděcí projekt“);
3.4.3 dodávce hardware (technologií) a software potřebného k realizaci Systému, včetně jejich instalace resp. implementace v rozsahu dle Specifikace plnění ve smyslu této Smlouvy;
3.4.4 vývoji a implementaci software potřebného k realizaci Systému;
3.4.5 zpracování dokumentace a uživatelských příruček k jednotlivým součástem Systému a jednotlivým subsystémům ve smyslu odst.
3.1.1 až 3.1.5 Xxxxxxx;
3.4.6 školení uživatelů a administrátorů Systému dle Příloh č. 10 a 11 Zadávací dokumentace vztahujících se k subsystému digitalizace a subsystému dlouhodobého uložení dokumentů (LTP subsystém).
3.5 Smluvní strany sjednávají, že součástí Plnění dle této Smlouvy bude rovněž dodávka, instalace a plné zprovoznění veškerých potřebných technologií pro vybudování Systému, přičemž Poskytovatel převede na Objednatele vlastnické právo k veškerým dodaným technologiím. Tyto technologie bude Poskytovatel povinen uložit a instalovat do tří (3) datových center, která se nacházejí v Praze v Klementinu (Datové centrum K02), Hostivaři (Datové
centrum H02) a v Brně v budově MZK (Primární datové centrum). Během realizace Projektu NDK dojde ke stěhování dodané technologie v lokalitě Hostivař ze stávajícího datového centra do nového datového centra, přičemž Poskytovatel se zavazuje v takovém případě na základě písemné výzvy Objednatele provést zabezpečení a přípravu technologie ke stěhování, a následně opětovně plně zprovoznit a zfunkčnit přestěhovanou technologii do stavu před stěhováním, to vše dle podmínek blíže uvedených v Příloze č. 5 Zadávací dokumentaci (dále jen „Příprava ke stěhování technologie“). Přípravu ke stěhování technologie provede Poskytovatel nejpozději do sedmi
(7) ode dne doručení písemné výzvy Objednatele. Cena za Přípravu ke stěhování technologie již je obsažena v ceně za vytvoření technické, systémové a síťové infrastruktury dle odst. 3.1.1 této Smlouvy. Samotné stěhování technologie není předmětem této Smlouvy.
3.6 Smluvní strany sjednávají, že technická specifikace Systému a detailnější vymezení jeho jednotlivých subsystémů a modulů, stejně jako detailní parametry Podpory, jsou podrobněji popsány a vyplývají z Přílohy č. 1 této Smlouvy s názvem „Specifikace plnění“ (dále jen „Specifikace plnění“). Prováděcí projekt, jakožto výstup Poskytovatele ve smyslu odst. 3.4.2 Xxxxxxx vycházející ze Specifikace plnění, bude po jeho řádné akceptaci Objednatelem v souladu s touto Smlouvou představovat závazné upřesnění a specifikaci Plnění, přičemž Prováděcí projekt bude po jeho řádné akceptaci pro definici Plnění aplikován přednostně před Specifikací plnění.
3.7 Smluvní strany dále sjednávají, že způsob, podmínky a detailnější vymezení jednotlivých činností Poskytovatele při poskytování Systémové integrace a s tím související práva a povinnosti smluvních stran jsou podrobněji popsány a vyplývají z Přílohy č. 2 této Smlouvy s názvem „Popis systémové integrace“ (dále jen „Popis systémové integrace“).
3.8 Smluvní strany se rovněž dohodly, že bližší vymezení podmínek poskytování Plnění a s tím související práva a povinnosti smluvních stran v rámci této Smlouvy mohou vyplývat rovněž z jednotlivých metodických dokumentů vypracovaných Projektovým managerem dle smlouvy o poskytování služeb Projektového managera (dále jen „Instrukce“), přičemž taková Instrukce bude vždy pouze v rámci plnění dle této Smlouvy a nebude jej žádným způsobem rozšiřovat a nebude mít vliv na cenu a termíny plnění dle této Smlouvy. K závaznosti Instrukce pro Poskytovatele je nezbytné, aby Objednatel prokazatelně seznámil Poskytovatele s takovou Instrukcí.
3.9 Objednatel se zavazuje převzít veškerá plnění Poskytovatele dle této Smlouvy a zaplatit Poskytovateli za poskytování Plnění dle této Smlouvy cenu za podmínek touto Smlouvou blíže stanovených.
3.10 Objednatel se zavazuje poskytnout Poskytovateli veškerá oprávnění a zmocnění potřebná pro řádné poskytování Plnění. Objednatel se dále zavazuje řádně a včas předkládat Poskytovateli všechny potřebné dokumenty a podklady a vyvinout veškerou potřebnou součinnost k řádnému poskytování Plnění.
4.1 Poskytování Plnění dle této Smlouvy bude Poskytovatelem zahájeno bezprostředně po jejím uzavření, nestanoví-li Objednatel jinak, a bude poskytováno v souladu se závazným harmonogramem, který tvoří Přílohu č. 3 této Smlouvy (dále jen „Harmonogram“).
4.2 Místem poskytování Plnění je celé území České republiky, zejména sídlo Objednatele a sídlo partnera Projektu NDK - Moravská zemská knihovna (MZK), Kounicova 65a, 601 87 Brno, a dále též místa umístění datových center ve smyslu odst. 3.5 této Smlouvy. Místo poskytování Plnění je dále specifikováno v Specifikaci plnění a může být upřesněno Prováděcím projektem, Instrukcí Projektového managera nebo jinou instrukcí Objednatele.
5. CENA A PLATEBNÍ PODMÍNKY
5.1 Za komplexní poskytnutí Plnění včetně dodávky a převedení vlastnického nebo užívacího práva k potřebnému software a hardware se sjednává cena v členění a ve výši:
Druh plnění | Cena v Kč bez | Sazba DPH | Výše DPH v Kč | Cena v Kč s DPH | |
DPH | |||||
XXX | |||||
Celková cena za Plnění | 169 265 523,00 | 20% | 33 853 104,60 | 203 118 626,00 | |
kromě Podpory (investiční | |||||
část – jednorázové náklady): | |||||
Tato cena za poskytnutí Plnění je maximální, konečná a nepřekročitelná a zahrnuje veškerá plnění dle této Smlouvy (s výjimkou Podpory), přičemž její výši není možné změnit s výjimkou změny daňových předpisů týkajících se daně z přidané hodnoty (DPH) a s výjimkou níže uvedených podmínek, a to pouze v části ceny včetně DPH.
5.2 Za poskytování Podpory v požadované kvalitě a úrovních (SLA) se pro jednotlivé součásti Systému dle této Smlouvy sjednává měsíční cena ve výši:
Cena v Kč bez | Sazba | Výše DPH v | Cena v Kč | |||
DPH | DPH | Kč | s DPH | |||
XXX | ||||||
Celkem za měsíc | 1 049 271,00 | 20% | 209 854,20 | 1 259 125,20 | ||
poskytování Podpory | ||||||
Celková měsíční cena za poskytování Podpory bude účtována a hrazena ode dne předpokládaného zahájení poskytování Podpory dle Harmonogramu, nejdříve však ode dne skutečného zahájení poskytování Podpory ve smyslu odst. 3.3 této Smlouvy. Celková měsíční cena za poskytování Podpory bude v případě nedodržení požadované kvality a úrovně (SLA) pro poskytování Podpory, Poskytovatelem automaticky snížena o výši kreditu (slevy z ceny) ve smyslu této Smlouvy dle pravidel v této Smlouvě uvedených. O úrovni
poskytování Podpory v daném kalendářním měsíci bude Poskytovatelem vyhotovován Report SLA ve smyslu odst. 6.14 Xxxxxxx.
5.3 Cena za poskytování Plnění dle odst. 5.1 Smlouvy je vždy splatná na základě faktur - daňových dokladů (dále jen „Faktura“) vystavených Poskytovatelem až po řádné a úplné akceptaci nebo převzetí a předání předmětného Plnění postupem dle čl. 7 této Smlouvy. Celková měsíční cena za poskytování Podpory je vždy splatná na základě Faktur vystavených Poskytovatelem po skončení každého kalendářního měsíce poskytování Podpory, za který má být účtována a hrazena cena dle odst. 5.2 Smlouvy. Poskytovatel se zavazuje všechny Faktury vystavit do patnácti (15) pracovních dnů od výše uvedeného rozhodného dne pro fakturaci. Poskytovatel odešle Fakturu Objednateli nejpozději následující pracovní den po vystavení Faktury. Splatnost všech plateb je stanovena na třicet kalendářních (30) dnů ode dne prokazatelného doručení Faktury Objednateli.
5.4 Všechny Faktury musí obsahovat ustanovení tohoto znění: „Plnění bylo poskytnuto v rámci projektu reg. č. CZ 1.06/1.1.00/07.06386 Integrovaného operačního programu“ a musí dále splňovat všechny náležitosti požadované zákonem č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů, účinných v době fakturace, avšak výslovně musí vždy obsahovat minimálně následující údaje: označení smluvních stran (Poskytovatel a Objednatel) a jejich adresy, IČ, DIČ, údaj o zápisu vystavovatele Faktury v obchodním rejstříku, označení Smlouvy, přesný popis poskytnutého plnění, číslo Faktury, den vystavení a lhůtu splatnosti Faktury, označení peněžního ústavu a číslo účtu, na který se má platit, fakturovanou částku a podpis oprávněné osoby. Přílohou Faktury budou vždy všechny Objednatelem akceptované akceptační protokoly, předávací protokoly nebo Reporty SLA vztahující se k danému Plnění nebo období.
5.5 Nebude-li Faktura obsahovat stanovené náležitosti, nebo v ní nebudou správně uvedené údaje dle Smlouvy, je Objednatel oprávněn ji vrátit ve lhůtě splatnosti. V takovém případě se přeruší běh lhůty splatnosti a nová lhůta splatnosti počne běžet doručením nové Faktury Objednateli po provedeném odstranění vytčených nedostatků. V této souvislosti smluvní strany prohlašují, že veškeré jejich vzájemné pohledávky jsou navzájem započitatelné ve smyslu ustanovení § 364 Obchodního zákoníku.
5.6 Faktury se platí bankovním převodem na účet příslušné smluvní strany uvedený ve Faktuře. Dnem úhrady se rozumí den, kdy je částka odepsána z bankovního účtu odesílatele platby ve prospěch účtu příjemce platby.
5.7 V případě prodlení kterékoliv smluvní strany se zaplacením peněžitého závazku, je tato smluvní strana povinna zaplatit druhé smluvní straně úrok z prodlení ve výši 0,03 % za každý i započatý den prodlení.
6. DALŠÍ PRÁVA A POVINNOSTI SMLUVNÍCH STRAN
6.1 Poskytovatel bude v průběhu celého trvání Smlouvy odpovědný za řádné a včasné vytvoření, implementaci a fungování Systému jako celku a jeho jednotlivých komponent.
6.2 Poskytovatel bude v průběhu celého trvání Smlouvy poskytovat Plnění v souladu s účelem Smlouvy a Zadávací dokumentace tak, aby vždy byla zachovávána vysoká kvalita poskytovaného Plnění a bylo dbáno na dosažení cílů Objednatele stanovených touto Smlouvou a Zadávací dokumentací.
6.3 Poskytovatel se zavazuje uchovávat veškerou dokumentaci související s realizací Projektu NDK, včetně účetních dokladů v souladu s článkem 90 Nařízení Rady (ES) č. 1083/2006 po dobu realizace Projektu NDK a následně po dobu deseti (10) let od ukončení Projektu NDK, minimálně však do konce roku 2021, a pokud je v českých právních předpisech stanovena lhůta delší než v evropských předpisech, musí být pro úschovu použita delší lhůta. Každý originální účetní doklad musí obsahovat informaci, že se jedná o projekt Integrovaného operačního programu a musí být označen číslem projektu.
6.4 Poskytovatel se zavazuje umožnit osobám oprávněným k výkonu kontroly Projektu NDK, z něhož je Veřejná zakázka hrazena, provést kontrolu dokladů, a to po dobu danou příslušnými právními předpisy k jejich archivaci.
6.5 Poskytovatel se zavazuje po dobu realizace Projektu NDK a následně po dobu deseti (10) let od ukončení Projektu NDK, minimálně však do konce roku 2021 za účelem ověřování plnění povinností vyplývajících z podmínek programu IOP poskytovat požadované informace a dokumentaci zaměstnancům nebo zmocněncům pověřených orgánů (OSF MV ČR, MMR, Ministerstva financí, Evropské komise, Evropského účetního dvora, Nejvyššího kontrolního úřadu, příslušného finančního úřadu a dalších oprávněných orgánů státní správy) a je povinen vytvořit výše uvedeným osobám podmínky k provedení kontroly, vztahující se k realizaci Projektu NDK a poskytnout jim při provádění kontroly součinnost.
6.6 Poskytovatel se zavazuje provádět informační a propagační opatření na základě Nařízení Komise (ES) č. 1828/2006, kde je mimo jiné stanovena odpovědnost příjemců, pokud jde o informační a propagační opatření pro veřejnost.
6.7 Poskytovatel se podle ustanovení § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů, ve znění pozdějších předpisů, zavazuje spolupůsobit při výkonu finanční kontroly prováděné v souvislosti s úhradou zboží nebo služeb z veřejných výdajů.
6.8 Poskytovatel je povinen všechny písemné zprávy, písemné výstupy a prezentace dle této Smlouvy opatřit vizuální identitou projektů dle Pravidel pro provádění informačních a propagačních opatření (viz příloha č. 4 Příručky pro žadatele a příjemce finanční podpory v rámci Integrovaného operačního programu pro prioritní osu 1a a 1b – Oblasti intervence 1.1a a 1.1b – Rozvoj informační společnosti ve veřejné správě – Výzva číslo 07 – časově neomezená – Elektronizace služeb veřejné správy). Poskytovatel prohlašuje, že ke dni nabytí účinnosti této Smlouvy je s těmito pravidly seznámen. V případě, že v průběhu plnění této Smlouvy dojde ke změně těchto pravidel, je Objednatel povinen o této skutečnosti Poskytovatele bezodkladně informovat.
6.9 Poskytovatel se zavazuje, že Plnění bude poskytováno v kvalitě a rozsahu specifikovaném ve Smlouvě. Poskytovatel se zavazuje proaktivně sledovat
6.10 Poskytovatel se zavazuje, že Podporu bude poskytovat minimálně v kvalitě a úrovních definovaných v jednotlivých SLA (Service Level Agrement, dále jen
„SLA“), které jsou uvedeny Příloze č. 4 a ve Specifikaci plnění. SLA obsahují měřené parametry pro Podporu poskytovanou Objednateli.
6.11 | V případě, že Poskytovatel neposkytuje Objednateli | Podporu | v souladu |
s příslušnými SLA, zavazuje se Poskytovatel: | |||
6.11.1 bez zbytečného prodlení zajistit na své náklady další zdroje nebo | |||
kapacity s cílem poskytovat Podporu v souladu se SLA, | |||
6.11.2 odstranit takový závadný stav v nejkratší možné době v souladu se | |||
Smlouvou. | |||
6.12 | V případě, že Poskytovatel neposkytuje Objednateli | Podporu | v souladu |
s příslušnými SLA, zavazuje se Poskytovatel poskytnout Objednateli kredity (slevy z ceny), jež jsou pro nedodržení jednotlivých parametrů SLA stanoveny v Příloze č. 4 a ve Specifikaci plnění.
6.13 Poskytovatel je povinen neprodleně po zahájení poskytování Podpory hlídat a monitorovat kvalitativní úroveň poskytování Podpory tak, aby měl Objednatel dle svého uvážení kdykoliv přístup k průběžným, aktuálním a průkazným výsledkům monitorování kvalitativní úrovně poskytování Podpory.
6.14 Poskytovatel je povinen minimálně jednou (1) měsíčně předkládat Objednateli přehledné a kompletní výkazy a výsledky monitorování kvalitativní úrovně poskytování Podpory v členění dle jednotlivých subsystémů (dále jen „Reporty SLA“), ze kterých bude jednoznačně zřejmé, zda byla Podpora poskytována v kvalitě definované v jednotlivých SLA dle této Smlouvy.
6.15 Objednatel nebo Projektový manager je oprávněn kdykoli v průběhu poskytování Podpory provádět kontrolu úrovně a kvality Poskytovatelem poskytované Podpory, přičemž Poskytovatel je povinen k tomu poskytnout Objednateli, resp. Projektovému managerovi, veškerou nezbytnou a přiměřenou součinnost. Bližší pravidla součinnosti smluvních stran jsou uvedena v Popisu Systémové integrace.
6.16 Objednatel je dále oprávněn udělovat Poskytovateli závazné instrukce ke způsobu poskytování Podpory, které je Poskytovatel povinen respektovat a dodržovat, nebudou-li v rozporu se Smlouvou, Specifikací plnění, Popisem systémové integrace nebo Prováděcím projektem. Budou-li instrukce udělené Objednatelem v rozporu se zájmy Objednatele nebo s účelem této Smlouvy, Specifikací plnění, Popisem systémové integrace nebo Prováděcím projektem, je Poskytovatel povinen na tuto skutečnost Objednatele bez zbytečného prodlení písemně upozornit a projednat tuto skutečnost s Oprávněnou osobou Objednatele, hrozí-li provedením instrukce Objednateli vážná újma.
6.18 Poskytovatel bude po celou dobu trvání Smlouvy udržovat v platnosti certifikáty systému řízení jakosti, systému řízení služeb IT a managementu bezpečnosti informací dle požadavků Zadávací dokumentace, vydané podle českých technických norem akreditovanou osobou, nebo rovnocenné certifikáty vydané akreditovanou osobou v členském státě Evropské unie.
6.19 Poskytovatel bude po celou dobu plnění Smlouvy udržovat v platnosti a účinnosti pojistnou smlouvu, jejímž předmětem je pojištění odpovědnosti za škodu způsobenou Poskytovatelem třetí osobě, přičemž limit pojistného plnění nesmí být nižší než 100.000.000,- Kč (slovy: sto milionů korun českých) a na požádání Objednatele neprodleně prokázat existenci a platnost takové pojistné smlouvy Objednateli. Zároveň je Poskytovatel povinen oznámit Objednateli každé ukončení platnosti pojistné smlouvy, dojde-li k takovéto skutečnosti a bezodkladně sjednat novou pojistnou smlouvu odpovídající výše uvedeným podmínkám.
7. AKCEPTACE JEDNOTLIVÝCH VÝSTUPŮ POSKYTOVATELE
7.1 Výsledky a výstupy Poskytovatelem poskytovaného Plnění budou akceptovány Objednatelem na základě příslušné akceptační procedury.
7.2 Bude-li Plnění Poskytovatele spočívat v samotné dodávce hardware (technologií) nebo licencí k software, proběhne předání a převzetí takového Plnění na základě protokolárního předání těchto Plnění. Smluvní strany provedou fyzickou kontrolu předávaného hardware (technologií) a licencí software v předávacím místě a v případě řádného Plnění podepíšou předávací protokol na dodaný hardware (technologie) nebo předávané licence software. Hardware (technologie) a licence software lze předávat i po částech.
7.3 Bude-li Plnění Poskytovatele spočívat ve vypracování dokumentu v listinné nebo elektronické podobě běžného (každodenního) charakteru (zejména konkrétní výzva, upomínka, Report SLA apod.), bude takový dokument považován za akceptovaný uplynutím třetího (3.) dne ode dne jeho převzetí, nevznese-li příslušná smluvní strana vůči takovému dokumentu písemné námitky.
7.5 Akceptační procedura zahrnuje ověření, zda Poskytovatelem provedené Plnění vedlo ke smluvenému výsledku, tedy zda odpovídá specifikaci, která je na základě Smlouvy závaznou, a to porovnáním skutečných vlastností jednotlivých částí takového Plnění s jejich specifikací obsaženou ve Specifikaci plnění, Popisu systémové integrace nebo Prováděcím projektu.
7.6 Akceptace dokumentů v listinné nebo elektronické podobě
7.6.2 Poskytovatel se zavazuje předat první verzi dokumentu Objednateli k akceptaci v takové lhůtě, aby nebyla ohrožena lhůta (milník) pro vyhotovení daného dokumentu stanovená v Harmonogramu. Milník dle Harmonogramu představuje časový okamžik, kdy nejpozději má být dané Plnění s konečnou platností akceptováno.
7.6.3 Objednatel se zavazuje vznést veškeré své výhrady nebo připomínky k první verzi dokumentu předložené dle odst. 7.6.2 do pěti (5) pracovních dnů od jejího doručení. Nevznese-li Objednatel ve stanovené lhůtě k první verzi dokumentu žádné výhrady ani připomínky, považují smluvní strany uplynutím této lhůty dokument ve znění jeho první verze za řádně akceptovaný a pro smluvní strany závazný.
7.6.4 Vznese-li Objednatel ve stanovené lhůtě své výhrady nebo připomínky k první verzi dokumentu dle odst. 7.6.3, zavazuje se Poskytovatel do tří (3) pracovních dnů od jejich doručení provést veškeré potřebné úpravy dokumentu dle opodstatněných výhrad a relevantních připomínek Objednatele a takto upravený dokument předat jako jeho druhou verzi Objednateli k akceptaci.
7.6.5 Objednatel se zavazuje vznést veškeré své výhrady nebo připomínky k druhé verzi dokumentu předložené dle odst. 7.6.4 do pěti (5) pracovních dnů od jejího doručení. Nevznese-li Objednatel ve stanovené lhůtě k druhé verzi dokumentu žádné výhrady ani připomínky, považují smluvní strany uplynutím této lhůty dokument ve znění jeho druhé verze za řádně akceptovaný a pro smluvní strany závazný. K výhradám nebo připomínkám, které Objednatel mohl a měl vznést již k první verzi dokumentu, ale neučinil tak, se pro účely akceptace nebude přihlížet, Poskytovatel však bude povinen takovéto výhrady nebo připomínky Objednatele vypořádat do deseti (10) pracovních dnů od akceptace dokumentu.
7.6.6 Vznese-li Objednatel ve stanovené lhůtě své výhrady nebo připomínky k druhé verzi dokumentu dle odst. 7.6.5, zavazují se smluvní strany zahájit společné jednání za účelem odstranění veškerých vzájemných rozporů a akceptace dokumentu, a to nejpozději do tří (3) pracovních dnů od výzvy kterékoliv smluvní strany. Smluvní strany se zavazují nepřerušit zahájené jednání za účelem odstranění vzájemných rozporů a akceptace dokumentu až do úspěšné akceptace dokumentu.
7.6.7 Smluvní strany se zavazují po akceptaci dokumentu dle odst. 7.6.3, odst. 7.6.5 nebo odst. 7.6.6 potvrdit akceptaci sepsáním písemného akceptačního protokolu, a to nejpozději do tří (3) pracovních dnů od akceptace dokumentu. Účinky akceptace nastávají podpisem
akceptačního protokolu oběma smluvními stranami dle odst. 7.8 Smlouvy.
7.6.8 K akceptaci lze předložit i dílčí části Prováděcího projektu. Akceptace každé dílčí části Prováděcího projektu se řídí ustanoveními odst. 7.6 Xxxxxxx. Prováděcí projekt jako celek je však akceptován až akceptací všech jeho dílčích částí.
7.7 Akceptace jiných Plnění, zejména jednotlivých subsystémů
7.7.1 Akceptační procedura bude zahrnovat akceptační testy, které budou probíhat před zahájením pilotního provozu na základě specifikace akceptačních testů vypracované Poskytovatelem jako součásti Prováděcího projektu, přičemž tato bude podléhat schválení (akceptaci) Objednatelem. Specifikace akceptačních testů bude pro jednotlivá Plnění podléhající akceptaci dle tohoto odst. 7.7 obsahovat specifikaci konkrétních testovacích scénářů, akceptačních kritérií, příkladů a dat na akceptační test.
7.7.2 Poskytovatel vyzve Objednatele písemně k účasti na akceptační proceduře nejméně deset (10) dní před jejím zahájením. Objednatel je oprávněn se akceptačních testů zúčastnit a osvědčit jejich konání. Pokud se Objednatel nedostaví v termínu určeném pro provedení akceptačních testů, přestože byl Poskytovatelem k účasti řádně a včas vyzván, je Poskytovatel oprávněn provést příslušné akceptační testy bez jeho přítomnosti. Objednateli budou poskytnuty kopie veškerých dokumentů vypracovaných v souvislosti s provedením akceptačních testů, jinak akceptační testy nebyly provedeny řádně.
7.7.3 Jestliže jednotlivý předmět akceptačních testů splní akceptační kritéria, považuje se smluvními stranami za akceptovaný dnem úspěšného ukončení akceptačních testů. Smluvní strany akceptaci potvrdí sepsáním písemného akceptačního protokolu, a to nejpozději do tří (3) dnů od akceptace dokumentu. Účinky akceptace nastávají podpisem akceptačního protokolu oběma smluvními stranami dle odst. 7.8.
7.7.4 Pokud kterýkoliv předmět akceptačních testů nesplňuje stanovená akceptační kritéria příslušného akceptačního testu, sdělí Objednatel své připomínky písemně Poskytovateli formou strukturovaného rozdílového protokolu, a to nejpozději do patnácti (15) dnů ode dne ukončení příslušného akceptačního testu, nebo ode dne, kdy mu Poskytovatel poskytl veškerou dokumentaci daného akceptačního testu, podle toho, co nastane později. Nevznese-li Objednatel své připomínky ve stanovené lhůtě, považuje se daný předmět akceptačních testů uplynutím této lhůty za akceptovaný.
7.7.5 Rozdílový protokol je dokument obsahující připomínky Objednatele k předmětu akceptačních testů, který nesplnil akceptační kritéria příslušného akceptačního testu. Připomínky musí být Objednatelem specifikovány v dostatečné podrobnosti a při zachování pravidla konkrétnosti. Formulace připomínek provedená příslušnými pracovníky Objednatele musí vždy obsahovat přinejmenším tyto náležitosti: (i) název výstupu, k němuž se připomínka vztahuje; (ii)
(iii) pokyny upřesňující postup realizace připomínky nebo charakteristiku cíle, cílového stavu po zapracování připomínky.
7.7.6 Vznese-li Poskytovatel výhrady nebo připomínky k řádně a včas dodanému rozdílovému protokolu, zavazují se smluvní strany k bezodkladnému započetí vzájemných jednání o způsobu a termínu jejich odstranění. Nevznese-li Poskytovatel k řádně a včas dodanému rozdílovému protokolu výhrady nebo připomínky ve lhůtě pěti (5) dnů od jeho doručení, považuje se rozdílový protokol za schválený dnem uplynutí této lhůty.
7.7.7 Poskytovatel je povinen na základě schváleného rozdílového protokolu připomínky zapracovat a bez zbytečného prodlení předložit příslušný předmět akceptačních testů k opakované akceptaci, která se přiměřeně řídí ustanoveními tohoto odst. 7.7. Proces testování a následných oprav se bude opakovat, dokud daný předmět akceptačních testů nesplní veškerá akceptační kritéria příslušného akceptačního testu.
7.8 K podpisu akceptačního protokolu podle tohoto čl. 7 je oprávněn statutární orgán smluvní strany, dále oprávněná osoba smluvní strany ve smyslu čl. 13 této Smlouvy, případně těmito osobami písemně pověřená osoba, nebude-li vyplývat z této Smlouvy nebo jiného závazného dokumentu jinak.
8. UŽÍVACÍ PRÁVA
8.1 K písemným výstupům Poskytovatele poskytnutým v rámci poskytování Plnění nebo k tzv. unikátním počítačovým programům, tedy počítačovým programům vytvořeným výhradně pro potřeby Objednatele, které mají povahu autorského díla dle zákona č. 121/2000 Sb, autorského zákona, ve znění pozdějších předpisů (dále jen „autorské dílo“), je Objednateli Poskytovatelem poskytována pro území České republiky nevýhradní licence bez omezení co do množství a způsobu užití, a to po celou dobu trvání majetkových práv autorských k takovému autorskému dílu (dále jen
„Licence“). Jako součást Licence dle tohoto odstavce uděluje Poskytovatel Objednateli i souhlas k provedení jakýchkoliv změn nebo modifikací výsledků uvedených autorských děl, a to i prostřednictvím třetích osob a výslovný souhlas k postoupení Licence a k poskytnutí oprávnění užít tyto výsledky
8.2 Poskytuje-li Poskytovatel Licenci k unikátním počítačovým programům, vztahuje se ve stejném rozsahu k počítačovým programům ve zdrojovém a strojovém kódu, jakož i ke koncepčním přípravným materiálům. Poskytovatel se zavazuje v případě, že se Licence vztahuje k počítačovým programům, poskytnout Objednateli zdrojové kódy takových počítačových programů a koncepční přípravné materiály (zahrnující zejména analýzy a technické designy) a tyto v případě změny průběžně aktualizovat a poskytovat i dokumentaci provedených změn. Poskytovatel se dále zavazuje předat Objednateli aktuální dokumentované zdrojové kódy a koncepční přípravné materiály všech počítačových programů do třiceti (30) dnů od skončení účinnosti této Smlouvy.
8.3 Bude-li výsledkem plnění nebo jiné činnosti Poskytovatele prováděné dle této Smlouvy počítačový program, který nebyl vytvořen výhradně pro potřeby Objednatele, ale jedná se zejména o tzv. standardní počítačový program Poskytovatele nebo třetí strany, který je autorským dílem, nabývá Objednatel Licenci dnem poskytnutí autorského díla Objednateli k užívání. Součástí Licence je rovněž neomezené právo Objednatele poskytnout třetím osobám podlicenci k užití autorského díla v rozsahu shodném s rozsahem Licence a také souhlas Poskytovatele k postoupení Licence na třetí osoby. Licence se automaticky vztahuje i na všechny nové verze, aktualizované verze, i na úpravy a překlady autorského díla, dodané Poskytovatelem.
8.4 Poskytovatel je povinen postupovat tak, aby udělení Licence k autorskému dílu dle této Smlouvy včetně oprávnění udělit podlicenci zabezpečil, a to bez újmy na právech třetích osob. Nebude-li možné po Poskytovateli spravedlivě požadovat udělení Licence v rozsahu dle odst. 8.1, 8.2 nebo 8.3 této Smlouvy, je Poskytovatel povinen na to písemně Objednatele upozornit spolu s náležitým odůvodněním a poskytnout Objednateli nebo zajistit pro Objednatele poskytnutí licence či podlicence v nejširším možném rozsahu. Postup dle předchozí věty je možný jen s výslovným písemným souhlasem Objednatele, přičemž Objednatel se zavazuje, že tento souhlas neodmítne poskytnout bez vážného důvodu.
9. ODPOVĚDNOST ZA ŠKODU
9.1 Každá ze smluvních stran nese odpovědnost za způsobenou škodu v rámci platných právních předpisů a Smlouvy. Poskytovatel plně odpovídá za plnění Smlouvy rovněž v případě, že příslušnou část plnění poskytuje prostřednictvím třetí osoby (subdodavatele). Seznam subdodavatelů Poskytovatele je obsažen v Příloze č.6 této Smlouvy.
9.2 Obě smluvní strany se zavazují k vyvinutí maximálního úsilí k předcházení škodám a k minimalizaci vzniklých škod.
9.3 Žádná ze smluvních stran neodpovídá za škodu, která vznikla v důsledku věcně nesprávného nebo jinak chybného zadání, které obdržela od druhé smluvní strany. V případě, že Objednatel poskytl Poskytovateli chybné zadání
nebo pokyn a Poskytovatel s ohledem na svou povinnost poskytovat plnění s odbornou péčí mohl a měl chybnost takového zadání nebo pokynu zjistit, smí se ustanovení předchozí věty dovolávat pouze v případě, že na chybné zadání Objednatele písemně upozornil a Objednatel trval na původním zadání. Žádná ze smluvních stran není odpovědná za nesplnění svého závazku v důsledku prodlení druhé smluvní strany nebo v důsledku okolností vylučujících odpovědnost (§ 374 Obchodního zákoníku).
9.4 Objednatel je oprávněn požadovat náhradu škody i v případě, že se jedná o porušení povinnosti, na kterou se vztahuje smluvní pokuta, a to v plné výši dle Smlouvy.
9.5 Případná náhrada škody bude zaplacena v měně platné na území České republiky, přičemž pro propočet na tuto měnu je rozhodný kurs České národní banky ke dni vzniku škody.
9.6 Smluvní strany prohlašují, že celková předvídatelná výše škody, která může z porušení povinností odpovědné smluvní strany při plnění této Smlouvy vzniknout poškozené smluvní straně a kterou může nebo mohla odpovědná smluvní strana v době vzniku této Smlouvy při vynaložení obvyklé péče předvídat, nepřesáhne částku rovnající se limitu pojistného plnění vyplývajícího z pojistné smlouvy Poskytovatele ve výši 100.000.000,- Kč (slovy: sto milionů korun českých). Toto omezení se netýká škod způsobených smluvní stranou úmyslně nebo z hrubé nedbalosti. Smluvní strany shodně prohlašují, že v souladu s ustanovením § 379 Obchodního zákoníku se škoda způsobená neúmyslně nebo nedbalostně poškozené smluvní straně, převyšující výši předvídatelné škody dle tohoto odstavce, nenahrazuje.
10. VYŠŠÍ MOC
10.1 Žádná ze smluvních stran není odpovědná za prodlení s plněním závazků stanovených Smlouvou, pokud bylo způsobeno okolnostmi vyšší moci.
10.2 Smluvní strany se zavazují upozornit druhou smluvní stranu bez zbytečného odkladu na vzniklé okolnosti vyšší moci, bránící řádnému plnění Smlouvy. Smluvní strany se zavazují k vyvinutí maximálního úsilí k odvrácení a překonání vyšší moci.
11. SANKCE
11.1 Smluvní strana je v prodlení s plněním svého závazku, který pro smluvní stranu vyplývá ze Smlouvy anebo platných právních předpisů, jestliže jej nesplní řádně a včas. Žádná ze smluvních stran není v prodlení s plněním svého závazku v důsledku prodlení druhé smluvní strany.
11.2 V případě prodlení Poskytovatele s vypracováním Prováděcího projektu, vzniká Objednateli nárok na smluvní pokutu ve výši 30.000,- Kč (slovy: třicet tisíc korun českých) za každý i započatý den prodlení s vypracováním tohoto dokumentu.
11.3 V případě prodlení Poskytovatele s poskytnutím některého Plnění dle milníku uvedeného v Harmonogramu, vzniká Objednateli nárok na smluvní pokutu
11.4 V případě prodlení Poskytovatele s poskytnutím součinnosti dle odst. 6.13, nebo 6.19, vzniká Objednateli nárok na smluvní pokutu ve výši 10.000,- Kč (slovy: deset tisíc korun českých) za každý i započatý den prodlení s poskytnutím této součinnosti.
11.5 V případě prodlení Poskytovatele s Přípravou ke stěhování technologie na základě příslušné výzvy Objednatele dle odst. 3.5 Smlouvy, vzniká Objednateli nárok na smluvní pokutu ve výši 30.000,- Kč (slovy: třicet tisíc korun českých) za každý i započatý den prodlení s provedením takové Přípravy ke stěhování technologie.
11.6 V případě prodlení Poskytovatele s plněním jiného závazku ve smyslu odst.
3.4 této Smlouvy, pokud Poskytovatel nezjedná nápravu ani do pěti (5) pracovních dnů od písemného upozornění Objednatele na toto prodlení, vzniká Objednateli nárok na smluvní pokutu ve výši 30.000,- Kč (slovy: třicet tisíc korun českých) za každý i započatý den prodlení s plněním každého jednotlivého závazku.
11.7 V případě jednání Poskytovatele spočívajícího v porušení povinnosti chránit Osobní údaje dle odst. 12.4 Smlouvy, vzniká Objednateli nárok na smluvní pokutu ve výši pěti (5) násobku sankce uložené Úřadem na ochranu osobních údajů za každý jednotlivý případ.
11.8 Smluvní strana, která poruší povinnosti vyplývající ze Smlouvy ohledně ochrany Důvěrných informací ve smyslu čl. 12 Smlouvy, je povinna zaplatit druhé smluvní straně smluvní pokutu ve výši 100.000,- Kč (slovy: sto tisíc korun českých) za každé porušení takové povinnosti, a to do třiceti (30) dnů ode dne doručení písemné výzvy na její uhrazení, přičemž maximální výše této pokuty je omezena v souhrnu na částku 1.000.000,- Kč (slovy: jeden milion korun českých). Tím není dotčen ani omezen nárok na náhradu vzniklé škody.
12.3.2 nebo odst. 12.3.3 Xxxxxxx.
11.10 Smluvní pokuta je splatná třicátý (30.) kalendářní den ode dne doručení písemné výzvy oprávněné smluvní strany k jejímu uhrazení povinnou smluvní stranou.
11.11 Není-li dále stanoveno jinak, zaplacení jakékoliv sjednané smluvní pokuty nezbavuje povinnou smluvní stranu povinnosti splnit své závazky a nedotýká se nároku na náhradu škody v plné výši dle Smlouvy.
11.12 Maximální souhrnná výše všech pokut dle Smlouvy je omezena na částku ve výši 200.000.000,- Kč (slovy: dvě stě milionů korun českých). Tím není dotčen ani omezen nárok na náhradu vzniklé škody.
12. OCHRANA INFORMACÍ
12.1 Smluvní strany jsou si vědomy toho, že v rámci plnění závazků ze Smlouvy:
12.1.1 si mohou poskytnout informace, které budou považovat nebo budou označeny za důvěrné (dále jen „Důvěrné informace“);
12.1.2 mohou jejich zaměstnanci a osoby v obdobném postavení získat vědomou činností druhé smluvní strany nebo i jejím opominutím přístup k Důvěrným informacím druhé smluvní strany.
12.2 Smluvní strany se zavazují, že žádná z nich nezpřístupní třetí osobě Důvěrné informace, které při plnění Smlouvy získala od druhé smluvní strany.
12.3 Za třetí osoby podle odst. 12.2 se nepovažují:
12.3.1 zaměstnanci smluvních stran a osoby v obdobném postavení, ve vztahu k Objednateli,
12.3.2 statutární orgány smluvních stran a jejich členové,
12.3.3 ve vztahu k Poskytovateli jeho subdodavatelé,
za předpokladu, že se podílejí na plnění Smlouvy, Důvěrné informace jsou jim zpřístupněny výhradně za tímto účelem a zpřístupnění Důvěrných informací je učiněno v rozsahu nezbytně nutném pro naplnění jeho účelu a za stejných podmínek, jaké jsou stanoveny smluvním stranám ve Smlouvě.
12.4 Smluvní strany se zavazují v plném rozsahu zachovávat povinnost mlčenlivosti a povinnost chránit Důvěrné informace vyplývající ze Smlouvy a též z příslušných právních předpisů, zejména osobní údaje dle zákona č. 101/2000 Sb., o ochraně osobních údajů, ve znění pozdějších předpisů (dále jen „ZOOÚ“). Smluvní strany se v této souvislosti zavazují poučit veškeré osoby, které se budou podílet na plnění Smlouvy, o výše uvedených povinnostech mlčenlivosti a ochrany Důvěrných informací a dále se zavazují vhodným způsobem zajistit dodržování těchto povinností všemi osobami podílejícími se na plnění Smlouvy.
12.5 Budou-li informace poskytnuté Objednatelem či třetími stranami, které jsou nezbytné pro plnění dle Smlouvy, obsahovat data podléhající režimu zvláštní ochrany podle ZOOÚ, zavazuje se Poskytovatel zabezpečit jejich ochranu a splnění všech ohlašovacích povinností, které ZOOÚ vyžaduje, a obstarat předepsané souhlasy subjektů osobních údajů předaných ke zpracování. Poskytovatel je povinen si vyžádat k provedení úkonů dle tohoto odstavce zvláštní plnou moc od Objednatele.
12.6 Budou-li informace poskytnuté Objednatelem či třetími stranami, které budou nezbytné pro plnění dle Smlouvy obsahovat i Osobní údaje podléhající režimu zvláštní ochrany podle ZOOÚ, zavazují se smluvní strany uzavřít samostatnou smlouvu o zpracování osobních údajů ve smyslu § 6 ZOOÚ, přičemž Objednatel bude správcem a Poskytovatel zpracovatelem osobních údajů.
12.7 Veškeré Důvěrné informace zůstávají výhradním vlastnictvím předávající smluvní strany a přijímající smluvní strana vyvine pro zachování jejich důvěrnosti a pro jejich ochranu stejné úsilí, jako by se jednalo o její vlastní Důvěrné informace. S výjimkou rozsahu, který je nezbytný pro plnění Smlouvy, se obě smluvní strany zavazují neduplikovat žádným způsobem Důvěrné informace druhé smluvní strany, nepředat je třetí straně ani svým vlastním zaměstnancům a zástupcům s výjimkou těch, kteří s nimi potřebují
12.8 Nedohodnou-li se smluvní strany výslovně písemnou formou jinak, považují se za Důvěrné informace implicitně všechny informace, které jsou a nebo by mohly být součástí obchodního tajemství, tj. například, ale nejenom, popisy nebo části popisů technologických procesů a vzorců, technických vzorců a technického know-how, informace o provozních metodách, procedurách a pracovních postupech, obchodní nebo marketingové plány, koncepce a strategie nebo jejich části, nabídky, kontrakty, smlouvy, dohody nebo jiná ujednání s třetími stranami, informace o výsledcích hospodaření, o vztazích s obchodními partnery, o pracovněprávních otázkách a všechny další informace, jejichž zveřejnění přijímající smluvní stranou by předávající smluvní straně mohlo způsobit škodu.
12.9 Bez ohledu na výše uvedená ustanovení se za Důvěrné informace nepovažují informace, které:
12.9.1 se staly veřejně známými, aniž by to zavinila záměrně či nedbalostně přijímající smluvní strana,
12.9.2 měla přijímající smluvní strana legálně k dispozici před uzavřením Smlouvy, pokud takové informace nebyly předmětem jiné, dříve mezi smluvními stranami uzavřené smlouvy o ochraně informací,
12.9.3 jsou výsledkem postupu, při kterém k nim přijímající smluvní strana dospěje nezávisle a je to schopna doložit svými záznamy nebo důvěrnými informacemi třetí strany,
12.9.4 po podpisu Xxxxxxx poskytne přijímající smluvní straně třetí osoba, jež takové informace přitom nezíská přímo ani nepřímo od smluvní strany, od které tyto informace pocházejí;
12.9.5 jejichž zveřejnění je vyžadováno zákonem či pravomocným rozhodnutím orgánu státní správy, obecných či stálých rozhodčích soudů.
12.10 Povinnost utajovat Důvěrné informace uvedená v tomto článku zavazuje smluvní strany po dobu účinnosti Smlouvy a po dobu třech (3) let od ukončení jejich smluvního vztahu.
13. OPRÁVNĚNÉ OSOBY
13.1 Každá ze smluvních stran jmenuje oprávněnou osobu či osoby. Oprávněné osoby budou zastupovat smluvní stranu v záležitostech souvisejících s plněním dle Smlouvy.
13.2 Jména oprávněných osob jsou uvedena v Příloze č. 5 této Smlouvy. Každá ze smluvních stran je oprávněna jednostranně změnit své oprávněné osoby, je však povinna na takovou změnu druhou smluvní stranu písemně upozornit nejpozději do tří (3) pracovních dnů. Účinnost změny oprávněných osob vůči druhé smluvní straně nastává dnem doručení oznámení o této změně. Změna oprávněných osob není považována za změnu Smlouvy ve smyslu ustanovení odstavce 20.1 Smlouvy.
14. SOUČINNOST A VZÁJEMNÁ KOMUNIKACE
14.1 Smluvní strany se zavazují vzájemně spolupracovat a poskytovat si veškeré informace potřebné pro řádné plnění svých závazků. Smluvní strany jsou povinny informovat druhou smluvní stranu o veškerých skutečnostech, které jsou nebo mohou být důležité pro řádné plnění Smlouvy.
14.2 Smluvní strany jsou povinny plnit své závazky vyplývající ze Smlouvy tak, aby nedocházelo k prodlení s plněním jednotlivých termínů a se splatností jednotlivých peněžních závazků.
14.3 Poskytovatel je povinen poskytovat přiměřenou součinnost a spolupracovat s Projektový managerem nebo s osobami, které může Objednatel dle svého uvážení v přiměřené míře využívat pro kontrolu a dohled nad řádným plněním Smlouvy.
14.4 Veškerá komunikace mezi smluvními stranami bude probíhat prostřednictvím oprávněných osob nebo jimi pověřených pracovníků nebo statutárních zástupců smluvních stran.
14.5 Všechna oznámení mezi smluvními stranami, která se vztahují ke Smlouvě, nebo která mají být učiněna na základě Smlouvy, musí být učiněna v písemné podobě a druhé smluvní straně doručena dle odst. 14.6 Xxxxxxx, pokud není výslovně stanoveno jinak.
14.6 Písemnost, která má být dle Xxxxxxx doručena druhé smluvní straně (oznámení, výpověď, odstoupení od smlouvy, atp.), je doručena dnem jejího převzetí oprávněnou osobou dle Xxxxxxx, dnem jejího otevření, byla-li doručena do Datové schránky nebo dnem, kdy byla doručena osobně nebo prostřednictvím držitele poštovní licence do sídla této smluvní strany a převzata osobou oprávněnou za smluvní stranu jednat nebo zaměstnancem pověřeným přejímáním písemností.
14.7 Nepodaří-li se písemnost doručit dle předchozího odstavce, za den doručení se považuje též den, kdy bylo přijetí této písemnosti adresátem odmítnuto. Je-li doručováno prostřednictvím držitele poštovní licence do vlastních rukou na adresu uvedenou ve Xxxxxxx nebo na adresu, kterou smluvní strana písemně oznámila jako změnu této adresy, za den doručení se xxx xxxxxxxx xxxxx (0.) den od oznámení o uložení zásilky na poště, i když se adresát o tom nedozvěděl, nebo den, kdy zásilka byla odeslána zpět jako nedoručitelná, protože smluvní strana nadále tuto adresu nevyužívá.
14.8 Účinky doručení mohou nastat též doručením písemnosti telegraficky, faxem nebo elektronickou poštou za podmínky, že taková písemnost bude neprodleně, nejpozději však do tří (3) pracovních dnů, potvrzena způsobem uvedeným v odst. 14.6, ledaže by Smlouva výslovně připouštěla v konkrétním případě doručení pouze elektronickou formou.
14.9 Ukládá-li Smlouva doručit některý dokument v písemné podobě, může být doručen buď v listinné podobě nebo na elektronickém nosiči dat jako dokument textového editoru MS Word verze 2003 a vyšší, příp. tabulkového kalkulátoru MS Excel verze 2003 a vyšší nebo ve formátu PDF na dohodnutém médiu.
14.10 Smluvní strany se zavazují, že v případě změny své adresy budou o této změně druhou smluvní stranu informovat nejpozději do tří (3) pracovních dnů.
15. JAKOST PLNĚNÍ
15.1 Poskytovatel nese odpovědnost za to, že všechna Plnění ve smyslu této Smlouvy budou poskytovány v nejvyšší dostupné kvalitě tak, aby vyhovovaly potřebám Objednatele, se kterými byl Poskytovatel seznámen, přičemž budou poskytovány s náležitou odbornou péčí a prostřednictvím osob, které mají potřebnou kvalifikaci i zkušenosti k plnění svých úkolů.
16. ZÁRUKA
16.1 Poskytovatel poskytuje záruku, že hardware a technologie poskytnuté Objednateli v rámci plnění této Smlouvy mají ke dni podpisu akceptačního protokolu příslušného Plnění nebo jeho části dle této Smlouvy funkční vlastnosti uvedené v Prováděcím projektu.
16.2 Pokud není v této Smlouvě výslovně uvedeno jinak, poskytuje se na hardware a technologii záruka po dobu dvacetičtyř (24) měsíců ode dne řádné a úplné akceptace takového hardware a technologie.
16.3 Záruční doba hardware a technologií začíná plynout dnem podpisu akceptačního protokolu Plnění nebo té jeho části, ve které je předmětný hardware obsažen, v souladu s touto Smlouvou.
16.4 Pokud není v této Smlouvě výslovně uvedeno jinak, je Objednatel povinen vady hardware a technologií písemně oznámit Poskytovateli bezodkladně, nejpozději do patnácti (15) dnů ode dne jejich zjištění, jinak jeho právo z odpovědnosti za vady zaniká. Poskytovatel v takovémto případě prošetří oznámenou vadu a v případě, že se na ni vztahuje záruka dle této Smlouvy, tuto vadu bez zbytečného odkladu odstraní. Objednatel mu přitom poskytne potřebnou součinnost, a to zejména pro odhalení příčiny vady.
16.5 Poskytovatel nenese odpovědnost za vady hardware a technologií vzniklé z důvodů na straně Objednatele nebo třetích osob, ani v případě, že Objednatel neprováděl stanoveným postupem údržbu hardware a technologií, nepoužíval všechny opravné programy dodané Poskytovatelem, užíval hardware nebo technologie i přes existenci vady, ačkoliv byl Poskytivatelem upozorněn na nutnost přerušení užívání hardware, nebo do hardware nebo technologií zasáhl bez předchozího souhlasu Poskytovatele s takovým konkrétním zásahem.
17. ZMĚNOVÉ ŘÍZENÍ
17.1 V případě, že Objednatel či Poskytovatel požaduje změnu rozsahu Plnění nebo kvalitativní úrovně poskytované Podpory, předloží smluvní strana navrhující tuto změnu druhé smluvní straně návrh změny písemně.
17.2 Obě smluvní strany se zavazují takový požadavek, včetně jeho důsledků na Celkovou cenu, projednat a v případě zájmu smluvních stran o plnění ve změněném rozsahu nebo za změněných podmínek, zavazují se smluvní
17.3 Smluvní strany berou na vědomí, že změnové řízení musí být provedeno způsobem a v rozsahu, který bude v souladu s předpisy vztahujícími se k zadávání veřejných zakázek, zejména pak v souladu se ZVZ.
18. ŘEŠENÍ SPORŮ
18.1 Práva a povinnosti smluvních stran výslovně neupravené touto Smlouvou se řídí Obchodním zákoníkem a ostatními příslušnými právními předpisy českého právního řádu.
18.2 Smluvní strany se zavazují vyvinout maximální úsilí k odstranění vzájemných sporů vzniklých na základě Smlouvy nebo v souvislosti s ní, včetně sporů o jejich výklad či platnost a usilovat se o smírné vyřešení těchto sporů nejprve prostřednictvím jednání oprávněných osob, pověřených zástupců nebo statutárních orgánů smluvních stran či jejich členů.
18.3 Nebude-li sporná záležitost vyřešena do šedesáti (60) dnů ode dne doručení výzvy k jednání dle odst. 18.2 Smlouvy, budou všechny spory vznikající z této Smlouvy a v souvislosti s ní rozhodovány s konečnou platností u Rozhodčího soudu při Hospodářské komoře České republiky a Agrární komoře České republiky podle jeho Řádu a Pravidel třemi rozhodci.
19. ÚČINNOST SMLOUVY
19.1 Smlouva nabývá platnosti a účinnosti dnem jejího podpisu oběma smluvními stranami. Xxxxxxx se uzavírá na dobu určitou do 31. prosince 2014.
19.2 Účinnost Smlouvy zaniká výhradně:
19.2.1 dohodou smluvních stran, jejíž součástí bude i zajištění poskytování Plnění a Podpory a vypořádání veškerých vzájemných závazků a pohledávek;
19.2.2 písemným odstoupením od Smlouvy v případě podstatného porušení Smlouvy jednou ze smluvních stran, které je účinné dnem doručení písemného oznámení o odstoupení druhé smluvní straně; nebo
19.2.3 písemným odstoupením Objednatele od Smlouvy v případě nepředvídatelných okolností souvisejících s nemožností další realizace Projektu NDK. Takovéto odstoupení od Xxxxxxx je účinné dnem doručení písemného oznámení o odstoupení Poskytovateli.
19.3 Podstatným porušením Smlouvy se rozumí zejména prodlení smluvní strany s plněním závazků podle Smlouvy po dobu delší než třicet (30) dnů, pokud druhá smluvní strana nezjedná nápravu ani v dodatečné přiměřené lhůtě, která jí byla první smluvní stranou poskytnuta na základě písemné výzvy ke splnění povinnosti, přičemž tato lhůta nesmí být kratší než deset (10) dnů od doručení takovéto výzvy.
19.4 Smluvní strany se dohodly, že při odstoupení od Xxxxxxx je Objednatel ve lhůtě jednoho (1) měsíce oprávněn určit, které poskytnuté plnění (a
19.5 Ukončením účinnosti Smlouvy nejsou dotčena ustanovení týkající se náhrady škody, smluvních pokut, ochrany informací a řešení sporů.
20. ZÁVĚREČNÁ USTANOVENÍ
20.1 Smlouva představuje úplnou dohodu smluvních stran o předmětu Smlouvy. Smlouvu je možné měnit pouze písemnou dohodou smluvních stran ve formě číslovaných dodatků Smlouvy, oboustranně odsouhlasených a podepsaných oprávněnými zástupci obou smluvních stran.
20.2 Pokud by se kterékoliv ustanovení Smlouvy ukázalo být neplatným z důvodu rozporu s kogentním ustanovením obecně závazných právních předpisů, pak tato skutečnost nepůsobí neplatnost než onoho konkrétního ustanovení, pokud je toto oddělitelné od ostatního obsahu Smlouvy. Smluvní strany se zavazují takové neplatné ustanovení dohodou nahradit ustanovením svým obsahem nejbližším duchu takového neplatného ustanovení, respektujícím požadavky obchodního zákoníku nebo právních předpisů, na něž obchodní zákoník odkazuje.
20.3 Veškerá práva a povinnosti vyplývající ze Xxxxxxx přecházejí, pokud to povaha těchto práv a povinností nevylučuje, na právní nástupce smluvních stran.
20.4 Nedílnou součást Smlouvy tvoří tyto přílohy: Příloha č. 1 Specifikace plnění
Příloha č. 2 Popis Systémové integrace
Příloha č. 3 Harmonogram
Příloha č. 4 SLA
Příloha č. 5 Oprávněné osoby
Příloha č. 6 Seznam subdodavatelů
Příloha č. 7 Zadávací dokumentace Veřejné zakázky (volná příloha)
20.5 Smlouva byla vyhotovena a účastníky podepsána ve čtyřech (4) vyhotoveních, každé s platností originálu, z nichž každá ze smluvních stran obdrží po dvou (2) vyhotoveních.
Smluvní strany prohlašují, že si Xxxxxxx přečetly, že s jejím obsahem souhlasí a na důkaz toho k ní
připojují svoje podpisy. | |
Objednatel | Poskytovatel |
V Praze dne 25. 10. 2011 | V dne . . _ |
............................................................................... | ............................................................................... |
.... | .... |
Národní knihovna České republiky | Logica Czech republic s.r.o. |
Xxx. Xxxxx Xxxx, generální ředitel | Xxx. Xxxxx Xxxxxxx, jednatel |
Příloha č. 1 SPECIFIKACE PLNĚNÍ
1.1 Celková koncepce navrhovaného řešení
Celková koncepce řešení Systému NDK nabízeného Poskytovatelem vychází ze snahy co nejefektivněji naplnit požadavky kladené v Zadávací dokumentaci. Cílem je dosáhnout vyváženého poměru stability, výkonu, dostupnosti a bezpečnosti systému, výrazné flexibility a rozšiřitelnosti systému a snadnosti obsluhy a užívání systému.
Při návrhu nabízeného Systému NDK jsme vycházeli z procesů, které je potřeba v rámci digitalizace, archivace a zpřístupnění realizovat a s podporou Systému NDK efektivně řídit a také z výchozích parametrů pro dimenzování požadovaného řešení definovaných Objednatelem:
Předpokládané kvantitativní parametry
Celkový počet digitalizovaných stran za dobu | 26 mil. |
projektu na obou pracovištích: | |
Celkový počet digitalizovaných stran za dobu | 13 mil. |
projektu na 1 pracovišti: | |
Celkový počet digitalizovaných stran za dobu | 13 200 |
projektu na 1 pracovišti za jeden den: | |
Průměrný počet stran za 1 den při dvou směnách | 26 400 |
na 1 pracovišti: | |
Maximální počet digitalizovaných stran za 1 den | 39 600 |
na 1 pracovišti: | |
Počet pracovních stanic: | 51 pracovních stanic |
Objem dat v LTP do konce projektu: | 622,730 TB |
1.1.1 Architektura Systému NDK
Rámcové schéma výsledné architektury Systému NDK, včetně rozdělení na komponenty a znázornění datových toků, je vidět na Obrázku 1. Jednotlivé stavební prvky navrženého Systému NDK a také vysvětlení technických, koncepčních, strategických a organizačních rozhodnutí, které jsme při návrhu architektury a koncepce učinili, jsou popsány dále v textu pod obrázkem.
XXX
Obrázek 1 – Schéma výsledné architektury Systému NDK
1.1.1.1 Technické řešení Systému NDK
XXX
1.1.2 Procesní model Systému NDK
Obrázek 2 – Podpora procesů v subsystémech
Základní procesy, z nichž vychází popsaná architektura nabízeného Systému NDK, a které tak bude Systém NDK podporovat, jsou následující:
Procesy plánování digitalizace – na základě vstupů obsahujících požadavky na digitalizaci (Registr digitalizace), parametrů celého Systému NDK (výkonové a formátové možnosti skenerů, výkonové parametry postprocessingu apod.) a při zohlednění zpětné vazby získané monitoringem provozu Systému NDK je v rámci procesu plánování vytvořen cca jednou za měsíc plán digitalizace. Plán digitalizace sumarizuje požadavky na dodání knih k digitalizaci tak, že specifikuje požadovanou formátovou (primární ukazatel, na kterém typu skeneru bude skenováno) skladbu titulů a množství pro jednotlivé formáty. Hlavním cílem procesu plánování je plné a rovnoměrné využití digitalizačních technologií. Vhodné plánování by mělo zamezit prostojům skenerů z důvodu nedostatku vstupů stejně jako přetěžování některých druhů skenerů z důvodu převahy jednoho konkrétního typu dokumentu. Podpora nabízeného Systému NDK pro procesy plánování spočívá v následujících funkcích:
o Konfigurace parametrů Systému NDK nutných pro plánování
o Přijetí požadavků na digitalizaci do Systému NDK
o Generování požadavku na dodání dokumentů pro digitalizaci
Procesy digitalizace – podpora tohoto základního procesu si klade za cíl zkombinovat efektivní využívání technologických (skenery), lidských (obsluha skenerů, pracovníci postprocessingu) a výpočetních zdrojů systému. Postup převodu sestává z celé řady nezbytných či volitelných kroků, které musí být systémem podporovány, sledovány a řízeny. Během průchodu dokumentu základním procesem digitalizace se střídají manuální úlohy, kde je nezbytná akce ze strany uživatele, s úkony plně automatizovanými, které jsou vykonávány autonomními komponentami Systému NDK. V rámci procesu digitalizace bude vstupní dokument řízeným způsobem převeden do digitální podoby a připraven na vložení do dlouhodobého úložiště. Podpora nabízeného Systému NDK pro procesy digitalizace se skládá ze zpřístupnění manuálních operací nad dokumentem a řízení automatizovaných kroků zpracování. Systém NDK nabízí podporu především následujících funkcionalit:
o Přijetí/Vrácení fyzického dokumentu k digitalizaci
o Zahájení/dokončení skenování dokumentu
o Zahájení/Dokončení postprocessingu hrubých naskenovaných dat
o Provedení postprocessingu hrubých naskenovaných dat pomocí specializovaných nástrojů
o Treventus ScanGate – pro dokumenty s požadavkem na zachycení logické struktury (logická strukturální metadata budou získávána maximálně z 5 % digitalizovaných dokumentů, což odpovídá předpokládanému množství zvláště důležitých monografií)
o ScanTailor – pro dokumenty typu kniha s většinově homogenní strukturou stránek
o Řízení automatizované konverze obrazů do požadovaných formátů (master copy, user copy)
o Řízení provedení automatizovaného OCR na zvoleném OCR modulu (součástí dodávky je modul založený na řešení ABBYY Recognition Server) - tato funkcionalita pokrývá i možné použití jiného modulu pro OCR dle volby Objednatele (bude dodána dokumentace popisující integraci externích OCR modulů)
o Manuální řešení nízké úspěšnosti OCR (prostředky řízení Workflow, prostředky Recognition Serveru – verifikační rozhraní)
o Řízení kompletace metadat dokumentu (automatizovaný sběr z podporovaných zdrojů, manuální doplnění metadat)
o Podpora řešení chybových či výjimečných situací – v případě, že některý z kroků skončí chybou, nebo jsou identifikovány problémy technického rázu, systém poskytuje GUI pro nápravu a řešení problému (rozhraní Workflow pro nápravu stavu dokumentu, editační aplikaci pro řešení problémů v datech dokumentu na pracovním úložišti)
o Řízení předání dokumentu do LTP
Procesy přijetí dat z jiných zdrojů – pro ukládání dat z externích zdrojů nabízený Systém NDK podporuje řízení zpracování jak dávek dokumentů, tak jednotlivých dokumentů v definovaném formátu (dle zdroje).
o Přijetí dokumentu či dávky ke zpracování
o Provedení transformací v transformačním modulu podle zdroje dat
o Manuální úprava zpracovávaných dat editačním modulem (v případě, kdy jsou již ve formě standardní struktury pracovního prostoru)
o Předání dokumentů k uložení do LTP a aplikací pro zpřístupnění
o Podpora řešení chybových či výjimečných situací pomocí zpřístupnění dat editačním modulem
o Nabízený systém je dimenzován tak, aby v průběhu doby trvání projektu zajistil rovněž migraci stávajících obrazových dat do nové LTP infrastruktury. Plánovaný výkon dedikovaný pro migraci bude dostatečný a umožní migraci v průměru 20 000 stran denně (celkem 10 000 000 dokumentů do roku 2014)
Procesy archivace dat – data v definovaném formátu jsou v rámci procesu převzata subsystémem LTP, je provedena validace a data jsou po transformaci do AIP uložena do dlouhodobého úložiště.
Procesy dlouhodobé ochrany dat – pro data uložená v dlouhodobém úložišti jsou v pravidelných intervalech spouštěny procesy dlouhodobé ochrany.
o Verifikace uložení bitstreamu
o Ověření bezpečnosti použitých datových formátů (ve formě reportu všech datových formátů v úložišti)
o Migrace dat definovaných vlastností do nových formátů
Výběr dat dle formátu, ve kterém jsou uložena (alternativně i jiných metadat) a provedení exportu vybraných dat.
Pomocí služeb transformačního modulu spustit migrační transformační
Workflow
Uložit do LTP novou verzi dat
Procesy vyzvednutí dat z archivu - data uložená v archivu je možné podle metadat vyhledat a z úložiště vyzvednout pomocí následujících funkcionalit:
o vyhledání sady dokumentů k vyzvednutí z archivu podle daných kriterií
o spuštění úlohy vyzvednutí dat
o v dedikované části pracovního prostoru vznikne balík DIP obsahující vyzvednutá data
Procesy zpřístupnění – mají za úkol zajistit přístup k dokumentům z různých zdrojů pro běžné uživatele a to v jediném, uživatelsky vlídném rozhraním, aniž by uživatel musel vědět, ve
kterém zdrojovém systému se hledané informace nacházejí. Za tímto účelem tedy subsystém Subsystém zpřístupnění poskytuje následující funkce:
o Sklízení dat z definovaných zdrojů
o Poskytování dat (OAI-PMH provider)
o Indexaci sesbíraných dat
o Zpřístupnění prohledávání dat pomocí webové aplikace
o Zprostředkování zobrazení nalezených obrazů dokumentů resp. stažení PDF verzí
Procesy řízení a monitoringu digitalizace – operativní procesy řízení jsou podporovány systémem Workflow. Pro podporu dlouhodobého řízení a monitoringu bude využíván modul RDC. Modul RDC poskytuje následující funkcionality:
o Definování globálních metrik a interních projektů digitalizace
o Sběr statistických dat o povozu systému NDK
o Konsolidace a zpracování sebraných dat
o Vizualizace statistických dat ve formě reportů a grafů
o Export reportů ve formě XLS
1.1.3 Bezpečnost
Společnost Logica se dlouhodobě profiluje na místním i světovém trhu jako specialista na informační bezpečnost. Cílem této kapitoly je demonstrovat náš systematický přístup k řešení bezpečnosti, který není omezený pouze na technologický pohled.
Z tohoto pohledu je naše řešení navrženo tak, že robustnost a bezpečnost je jeho inherentní vlastností.
1.1.3.1 Základní východiska
Požadavkem Objednatele je zajistit vysokou úroveň bezpečnosti a ochrany digitální dat. Další požadavkem na systém je odolnost proti výpadku. Ze Zadávací dokumentace rovněž vyplývá záměr Objednatele podstoupit certifikaci podle standardu TRAC. Tento standard odkazuje na další normy – mezi nimi na BS 17799 resp. ISO 27001:2005.
Z hlediska uvedených standardů je nutné řešit v oblasti bezpečnosti následující:
a) Omezení dodavatelského rizika (TRAC článek C 3.1)
b) Dodržení souladu s předpisy a zákony ((TRAC článek C 3.1, ISO 27001 – článek A 7.1.2 přílohy)
c) Ochrana fyzického a logického perimetru (TRAC článek C 3.2)
d) Ochrana integrity dat
e) Dostupnost dat
1.1.3.2 Omezení dodavatelského rizika
Omezení rizika Poskytovatele znamená učinit kroky, které ochrání Národní knihovnu a jí investované prostředky pro případ selhání (úpadku, změny obchodních podmínek, změny vlastnické struktury) Poskytovatele komponent systému digitalizace a dlouhodobé ochrany. Jestliže nastane takový případ, pak je jedinou ochranou dostupnost zdrojového kódu.
Proto jsme se při výběru subdodavatelů orientovali na tuzemské společnosti, které v zájmu úspěchu projektu respektují požadavek poskytnutí zdrojového kódu a licenční podmínky uvedené v Zadávací dokumentaci. Současně tím naše společnost a její subdodavatelé deklarují dostupnost vývojových pracovníků pro podporu dodávaných SW komponent a jejich další vývoj. Stejně tak v případě podpory skenerů, je náš subdodavatel jediným autorizovaným servisem robotických skenerů 4Digital Books v regionu CEE. Jsme přesvědčeni, že takovou úroveň ošetření dodavatelského rizika není možné zajistit s účastí zahraničního subdodavatele.
1.1.3.3 Dodržení souladu s předpisy a zákony – vlastnictví dat
Požadavek dodržení právní shody současně znamená vyřešit otázku vlastnictví informačních aktiv, v tomto případě především dat. Pokud nebude vyřešeno vlastnictví dat a právně podloženo, nelze předpokládat úspěšnou certifikaci podle TRAC. Nebyl by tedy splněn jeden z cílů projektu.
Národní knihovna poskytne svá zařízení k umístění do prostor MZK. Zde budou předlohy ve vlastnictví MZK digitalizovány. Předlohy, stejně jako jejich digitální kopie však zůstávají vlastnictvím MZK, i když jsou uloženy na HW ve vlastnictví NK. Pokud tedy nebude smluvně vyřešeno vlastnictví dat, nelze uspokojivě vyřešit organizačně i odpovědnost za jejich ochranu. To povede k nesplnění požadavků, které TRAC klade na organizační stránku ochrany dat.
Upozorňujeme na tuto skutečnost, jako na jeden z faktorů úspěšnosti řešení a omezení rizik celého projektu.
1.1.3.4 Ochrana fyzického a logického perimetru
Řízení bezpečnosti znamená chránit informační aktiva na úrovni fyzického a logického perimetru. Vzhledem k územní rozsáhlosti umístění fyzických komponent systému, je jediným správným řešením omezení velikosti fyzického perimetru.
Toho dosahujeme koncentrací technologických zdrojů (výpočetní kapacita, pracovní úložiště) do jednoho vysoce výkonného datového centra, které zajistí efektivitu prováděných operací při zpracování velkých objemů dat. Vzhledem k relativně vysokému objemu zpracovávaných dat je datový tok systémem navržen tak, aby všechna data, která mají být zpracována, byla dopravena na centrální uzel do centrálního pracovního úložiště a tam pak zpracovávána v rámci lokálních SAN/LAN sítí.
Dodávané řešení je koncipováno tak, že se stane de facto vnitřním systémem NK. Z tohoto pohledu přejímá charakter a metody prostředí, do nějž je integrováno.
1.1.3.5 Ochrana integrity dat
Integrita dat je chráněna v celém životním cyklu dat. Během jejich vzniku jsou všechna zařízení vybavena záložními zdroji s dostatečnou kapacitou. V průběhu zpracování a transferu do LTP je
integrita dat průběžně validována a chráněna. Tím je zaručena jejich správnost a neporušenost. Ochrana uložených dat v LTP je předmětem procesů dlouhodobé ochrany dat (v souladu se standardem OAIS), které jsou popsány dále.
1.1.3.6 Dostupnost dat
Jak již bylo uvedeno výše, data jsou průběžně chráněna. Samotný obsah LTP pak existuje ve třech kopiích, z čehož dvě kopie jsou uloženy v navzájem vzdálených geografických lokalitách. XXX
1.1.3.7 Další opatření k posílení bezpečnosti
Požadavek na dodržení bezpečnostních standardů předpokládá jejich plnění i v průběhu dodávky projektu. Standard TRAC vyžaduje jako základ pro zahájení certifikačního procesu existenci certifikátu dle BS 17799 (ISO 27001:2005). To znamená, že je nutné zpracovat veškerou dokumentaci vyžadovanou touto normou. Pro Poskytovatele je takovým dokumentem analýza rizik řešení. Ta bude zpracována standardizovanou metodou Treath Model a bude součástí prováděcího projektu, stejně jako dokument Plán ošetření rizik obsahující opatření pro eliminaci rizik.
V průběhu realizace bude trvale monitorováno naplňování bezpečnostních požadavků.
1.2 Popis vytvoření Prováděcího projektu
V rámci plnění první projektové fáze vytvoří Poskytovatel Prováděcí projekt. Součástí Prováděcího projektu bude podrobný návrh architektury řešení, podrobný návrh jednotlivých dodávek a služeb Projektu NDK a návrh řešení bezpečnosti.
V souladu s požadavky Objednatele bude Prováděcí projekt obsahovat níže popsané části. Projektová příprava, zahrnující:
Projektový plán
o Specifikace cílů Projektu NDK
o Rozsah Projektu NDK
o Popis způsobu a organizace řízení Projektu NDK s odkazy na využitou metodiku a související platné normy
o Organizační struktura projektu.
o Popis zdrojů (lidských i hmotných) pro zapojení na projektu
o Informace o účastnících Projektu NDK vč. kontaktů a jejich hlavní působnosti
o Harmonogram Projektu NDK
12
o Přehled souvisejících projektů
o Vymezení základních rizik Projektu NDK
o Charakteristika jednotlivých fází projektu
o Charakteristika předmětu plnění podle jednotlivých fází
o Charakteristika předpokládaných a využitelných vstupů a vazeb
o Konkrétní výstupy jednotlivých etap
o Rozpočet projektu na jednotlivé fáze Projektu NDK včetně harmonogramu jeho čerpání (součinnost Objednateli)
Plán kvality
o Plán postupů při řízení kvality
o Organizace při řízení kvality Plán testů
o Strategie testování pro Projekt NDK SI
o Specifikace akceptačních testů
o Akceptační kritéria pro Projekt NDK SI i jednotlivé fáze Plán školení
Analytická příprava, zahrnující:
Analýza požadovaných pracovních postupů a procesů Analýza a vyhodnocení uživatelských požadavků
Návrh řešení, zahrnující:
Konceptuální návrh celého řešení Procesní model
Detailní návrh celkové logické architektury řešení
Detailní návrh celkové fyzické/technologické architektury řešení Detailní návrh dodávek a služeb v rámci jednotlivých subsystémů Funkční specifikace jednotlivých subsystémů
Specifikace rozhraní na externí systémy
Detailní návrh implementace jednotlivých komponent řešení Bezpečnostní dokumentace, zahrnující:
Analýza bezpečnostních rizik
o Dokument popisující procesní a technická rizika Projektu NDK jejich závažnosti. Na tomto základě budou identifikovaná a kvantifikovaná rizika prioritizována. Pro zpracování dokumentu bude použita metoda Threat Modelling.
Plán ošetření bezpečnostních rizik
o Dokument vycházející ze seznamu prioritizovaných rizik a popisující způsob jak tato rizika eliminovat. V rámci testování bude prověřena účinnost opatření.
Bezpečnostní politika a navazující podřízené dokumenty
o Dokument určující bezpečnostní cíle, organizaci bezpečnosti a role jednotlivých osob. Návrh zálohování a obnovy dat
Akceptací výsledků či výstupů této části plnění budou Objednatelem a Poskytovatelem dále zpřesněny a doplněny detailní parametry poskytovaných dodávek a služeb pro Projekt NDK SI.
14
1.3 Specifikace realizace technické, systémové a síťové infrastruktury, včetně popisu zajištění odolnosti proti výpadku, náročnosti obsluhy a zaškolení jednotlivých uživatelů a úrovně bezpečnosti a ochrany digitálních dat
Při návrhu technické, systémové a síťové infrastruktury NDK se Logica řídila níže uvedenými požadavky Objednatele zmíněnými v technické části odpovídajících částech Zadávací dokumentace. Při návrhu výkonových parametrů jednotlivých komponent architektury této technické infrastruktury vycházela Logica nejen ze základních požadavků na dimenzaci řešení, ale také z požadavků kladených na jednotlivé subsystémy a na hlavní výkonové cíle celého Projektu NDK. Všechny tyto požadavky jsou navrženou technickou, systémovou a síťovou infrastrukturou splněny. Navržená technická infrastruktura tedy plně splňuje následující potřeby Objednatele:
Navržená technická, systémová a síťová infrastruktura tvoří po technické stránce jednotný, maximálně homogenní a plně integrovaný celek
Navržená technická, systémová a síťová infrastruktura a její provozní parametry splňuje požadavky vysoké bezpečnosti, dostupnosti i výkonu. Infrastruktura umožňuje vertikální i horizontální škálovatelnost podle reálných potřeb Objednatele, jejich postupného upřesňování a nárůstu.
Navržená architektura technické, systémové a síťové infrastruktury tvoří maximálně konsolidovanou a homogenní a hlavně plně funkční informační infrastrukturu
Obrázek 3 - Logické členění technologií
XXX
16
1.3.1 Serverová infrastruktura
XXX.
1.3.1.1 Servery pro SQL Cluster
XXX
1.3.1.2 Servery pro OCR
XXX
1.3.1.3 Server pro modul Transformace
XXX
17
1.3.1.4 Servery pro prostředí standardní virtualizace
Provoz systémů s menšími požadavky na výkon bude řešen prostředím virtualizace na platformě systémů společnosti VMware. Řešení je koncipováno s vysokou dostupností.
XXX
1.3.1.5 Servery pro virtualizaci pracovních stanic
XXX
1.3.1.6 Externí servery
XXX
1.3.1.7 Servery pro FS cluster – CIFS
XXX
18
XXX
1.3.1.8 Server pro TSM
XXX
1.3.2 Systémy pro ukládání dat
1.3.2.1 Úložiště pro Systém NDK
XXX
1.3.2.2 Rozšíření úložiště pro uživatelské kopie
Pro data, která budou generována v rámci digitalizace v průběhu provozování systému pokrytém touto nabídkou, bude dodána disková kapacita, která je určena pro uložení nově vzniklých uživatelských kopií. Předpokládáme, že uživatelská kopie je generována tak, že průměrná velikost jednotlivého souboru stránky je cca 0,5MB. Po uložení předpokládaného počtu 26 mil. Obrazů ve formátu uživatelské kopie. Kapacita potřebná na uložení uživatelských kopií za výše uvedených předpokladů je 20TB.
XXX
1.3.3 Infrastruktura SAN
XXX
1.3.3.1 Blade SAN
XXX
1.3.3.2 Externí SAN přepínače
XXX
1.3.4 Prostředí sítě LAN
XXX
1.3.5 Příslušenství, RACK
Pro umístnění dodávaného hardware navrhujeme použít standardní skříň RACK. V této skříni bude umístěno Blade řešení, externí servery, disková úložiště, monitor, přepínače SAN.
XXX
1.3.6 Software
1.3.6.1 Operační systémy
XXX
1.3.6.2 SQL Databáze
XXX
1.3.6.3 Virtualizace
1.3.6.3.1 Virtualizace serverů
Virtualizace serverů nabízí vyšší využití výkonu serverů i vyšší dostupnost. Umožňuje dosáhnout vysoké úspory nákladů a zároveň stabilnější a snáze řiditelný provoz. Změny a migrace ve virtuální infrastruktuře pak mohou probíhat výrazně pružněji, bezpečněji s minimálními nebo nulovými nároky na odstávky serverů. Provoz serverů je díky virtualizaci nezávislý na fyzickém zařízení.
XXX
1.3.6.3.2 Desktopová virtualizace
XXX
1.3.7 Technická infrastruktura LTP
Řešení LTP archivu pro NDK, jakožto jednoho ze čtyř základních modulů digitalizace NDK, je dle požadavků Objednatele navrženo tak, aby splňovalo požadavky vysoké bezpečnosti, dostupnosti,
25
SMLOUVA O POSKYTOVÁNÍ SLUŽEB SYSTÉMOVÉHO INTEGRÁTORA
výkonu, škálovatelnosti archivních svazků nejméně 400% velikosti dat v roce 2014 a také aby vyhovovalo potřebám dlouhodobé archivace.
1.3.7.1 Návrh řešení
Pro archivaci dat v LTP produkčním i testovacím systému jsme zvolili produkt XXX, který vyhovuje náročným požadavkům dlouhodobého uložení a vysokému stupni ochrany digitalizovaných dat. XXX
1.3.7.2 Funkční popis archivace
XXX
1.3.7.3 Produkční a testovací prostředí archivace
Pro produkční i testovací prostředí bude použit sdílený virtuální archív, který bude dále rozdělen na dvě prostředí. Oddělení obou prostředí bude realizováno na základě politik, které zajistí různě definovatelné parametry archivace, jako jsou doba archivace, typ a umístění dat v úložišti.
Rozdělení úložiště dat bude řešeno na úrovni storage poolu a to jak pro primární pool typu disk tak i pro sekundární pool i copy pool typu páska. Znamená to, že na diskovém poli tak bude samostatný prostor pro každé prostředí a sady pásek budou sdruženy do poolu, který bude dedikován pro každé prostředí.
Systém LTP (klient s TSM API) – node SSAM se asociuje s politikou podle typu prostředí – produkční nebo testovací. Na serveru můžeme mít oba nody současně nebo každý z nich na dedikovaném serveru.
XXX
1.3.7.4 Popis systému a operací s páskami
Archivovaná data budou nejprve uložena v „poolu“ typu disk. Po dosažení určité hranice zaplnění nebo na základě jiných pravidel definovaných politikou budou data z tohoto prostoru migrována na pásky. V prvním kroku budou data migrována do primárního poolu (1. kopie), a také budou současně synchronně kopírována do prvního „copy poolu“ (2. kopie). Tímto bude zajištěna dostupnost dat v případě výskytu chyby na některé pásce. Dále pak pomocí naplánované administrativní úlohy, budou data kopírována do druhého „copu poolu“ (3. kopie). Dále pak budou obsahy pásek automatizovaně v pravidelných intervalech např. 1x týdně (bude upřesněno v prováděcím projektu) z obou copy poolů (pásky typu WORM) označeny jako offsite a přemístěny do IO slotů knihovny. Odtud budou operátory vyjmuty z páskové knihovny a odnášeny do fyzicky vzdálené lokality k dlouhodobému uskladnění.
XXX
28
1.3.7.5 Popis operace s vadnou páskou
V případě výskytu chyby na pásce se tato nahradí novou nebo volnou páskou. Administrátor IA bude identifikovat jméno pásky pomocí čárového kódu jedné ze dvou validních kopií. Kopie pásky pak bude převezena ze vzdálené lokality. Poté ji administrátor vloží do IO slotu knihovny a spustí proces zkopírování pásky na novou náhradu. Po skončení této operace bude páska vrácena opět do IO slotu. Po vyjmutí z IO slotu se páska odveze zpět do fyzicky vzdálené lokality.
Obrázek 10 - IO Slot páskové knihovny
Pro ochranu pásky před vnějšími vlivy či před mechanickým poškozením budou pásky přenášeny ve speciálním boxu s kapacitou 20 pásek.
1.3.7.6 Pravidelná kontrola offsite pásek
IBM IA disponuje prostředky pro verifikaci pásek. Verifikace probíhá tak, že při čtení pásky jsou porovnány informace o archivovaných datech s informacemi uloženými v interní databázi IA. Při tomto procesu se zjistí případné nekonzistence.
V případě, že verifikace pásky odhalí nesrovnalost nebo nečitelnost pásky, administrátor IA provede náhradu poškozeného média dle výše uvedeného popisu.
Administrátor IA bude identifikovat pásky podle čárových kódů za určité období (rozsah bude upřesněn). Například nejstarší pásky za dva kalendářní měsíce, které ještě nebyly verifikovány - cca
20 pásek. Takto vybrané pásky přivezené ze vzdálené lokality vloží do IO slotů. Následně administrátor spustí proces verifikace pásek a řeší případné problémy. Po skončení kontroly administrátor IA přesune programově pásky do IO slotu, pásky vyjme a tyto opět převeze zpět do vzdálené lokality.
1.3.7.7 Navrhovaná konfigurace – popis
XXX
1.3.7.7.1 XXX
XXX
1.3.7.8 Zálohování
1.3.7.8.1 Zálohování IA
XXX.
1.3.7.8.2 Zálohování nově dodaných systémů
XXX.
Zálohovaná data budou uložena do primárního poolu typu disk, následně deduplikována a migrována do úložišť sdílené páskové knihovny, kde se provede replikace dat. K replikaci záložních/archivních dat bude využívána technologie TSM copy storage poolů. Data primárních storage poolů boudou replikována do páskových copy storage poolů jednou denně poté, co doběhnou noční zálohovací schedule. Replikace bude spouštěna administrativní úlohou TSM serveru. Evidence všech zálohovacích schedulí plánů je v režii centrálního scheduleru plánovače TSM serveru. Vlastní spouštění úloh na klientech v součinnosti s TSM serverem zajišťuje TSM klientský Schedule (plánovač), který je součástí instalace TSM BA klienta.
1.3.8 Zálohované entity infrastruktury
1.3.8.1 Operační systémy
Zálohování operačních systémů je prováděno nativními prostředky příslušného OS. Zálohu OS Windows systému má na starosti klientský SW (TSM Backup Archive klient), který za pomoci VSS služeb vytvoří obraz systémového disku (image backup) a ten následně uloží do TSM.
1.3.8.2 Souborové zálohy
Zálohování bude zajišťovat TSM Backup Archive klient – software určený pro zálohování a obnovu souborových dat. Zálohování bude probíhat denně metodou inkrementálních záloh (technologie Incremental Forever). Zálohovány budou všechna data, vyjma těch, které jsou vyspecifikovány v Exclude listech. Do denní inkrementální zálohy nebudou zahrnuty datové soubory databází, které se zálohují speciálním SW TSM for Databases.
1.3.8.3 Databázová data včetně archivních logů
Zálohování komponent systému MS SWL bude částečně pokryto zálohou souborových systémů (operační systém, binární soubory, konfigurační soubory) a částečně zálohou databáze MS SQL. Kombinací těchto záloh bude zajištěna kompletní či částečná obnovitelnost systémů v případě ztráty či poškození dat. K zálohování databází bude využíván software TSM for Databases (MS SQL), který poskytuje nástroj pro přímou zálohu do úložišť TSM serveru.
1.3.8.4 Popis produktu TSM server
Základní softwarovou komponentou TSM serveru je vestavěná relační databáze. Veškeré definované politiky, logování, autentizace, správa médií a objektů je řízena touto databází. Pro ukládání zálohovaných dat TSM používá storage repository. Tím se rozumí jakákoli kombinace diskových,
33
optických nebo páskových zařízení, které jsou lokálně (popř. přes SAN) připojeny k TSM serveru. V rámci storage repository mohou zařízení operovat samostatně, nebo mohou být spojeny dohromady a tvořit tak jednu nebo více storage hierarchií.
Specifikace:
Filosofie snadné zálohy a rychlé obnovy s využitím funkcionality "Progressive Incremental Backup" (stálá rozdílová záloha).
Plně automatizované řešení nezávislé na hardwaru, typu operačních systémů nebo online zálohovaných aplikací.
Centrální výkonná vnitřní databáze pro jakoukoliv konfiguraci velikosti zálohovacího řešení. Server i klienti nabízejí tři administrátorská rozhraní - Web, GUI nebo příkazovou řádku.
TSM je plně integrovatelný s monitorovacím řešením Tivoli Monitoring pro real-time monitoring a historický reporting.
Vysoká variabilnost životnosti záloh a archivů v úložištích (disk, optická média, pásková média). Možnost nastavení řešení pro 7 vrstev Disaster Recovery (definované mezinárodní skupinou SHARE)
Provázanost s IBM Tivoli monitoringem, zahrnuto v základní licenci. Možnost diagnostického sledování zálohovacího řešení v reálném čase, možnost vytváření historických pohledů včetně trendů.
Pokročilá diagnostika a reporting backup procesů.
Provádí výkonnostní a rozšiřitelné zálohování a obnovu, které minimalizují síťový provoz a zajišťují účinné a plánované přenosy dat, a poskytuje funkce pro sledování externích úložišť.
Využívá funkce odstraňování duplicit a hierarchizaci ukládání dat ke zvýšení účinnosti a k úspoře prostředků.
1.3.8.5 Popis TSM Backup archive klient
TSM je software pracující na bázi klient-server. Klientská část (B/A klient), která musí být instalována na každé pracovní stanici, kterou požadujeme zálohovat, slouží ke komunikaci klienta a TSM serveru. Podobně jako server se klient skládá z programové části a z konfiguračních souborů.
Mezi hlavní výhody patří:
Efektivní zálohování různorodých operačních systémů, filesystémových dat nezávislé na použitém hardware.
Jednoduchý management a automatizace zálohovacích operací
Snadné využití funkcionalit jednotlivých operačních systémů jako Windows ASR, VSS nebo technologií diskových polí jakou je Snapshot .
Možnost úpravy, optimalizace binárního kódu klienta, aby vyhověl nadstandardním požadavkům zákazníka.
1.3.8.6 Popis Tivoli data protection for Databases (MS SQL)
TDP pro MS SQL Server je komplexní zálohovací produkt, který umožňuje online zálohu, obnovu Microsoft SQL databází s využitím úložišť TSM serveru.
Mezi hlavní výhody patří:
Efektivní zálohování databázových dat bez omezení funkčnosti aplikace.
Rychlý a snadný backup a restore, který nevyžaduje žádné mezikroky, což značně přispívá k ochraně důležitých dat a snižuje dobu zálohy i obnovy.
1.3.8.7 Popis Tivoli data protection for SAN
Storage agent ve spojení s TSM serverem umožňuje implementovat LAN-free backup s využitím SAN infrastruktury. Vhodný je zejména pro objemné zálohy, které směřují přímo na páskové úložiště.
1.3.8.8 Popis Tivoli data protection for virtual environment
Využívá VMware’s vStorage APIs for Data Protection, včetně block-level incremental zálohování založeném na VMware Change Block Tracking. Přesouvá zátěž spojenou se zálohováním z virtuálních strojů a produkčních ESX hostu na vStorage backup server. Poskytuje flexibilní možnosti obnovy – file, volume nebo image. Automatizuje discovery nových virtuálních strojů a automaticky aplikuje pravidla pro zálohování.
1.3.9 Navrhované umístění HW infrastruktury
Celé dodávané řešení infrastruktury serverů, LAN, SAN a LTP – IBM IA navrhujeme společně umístit do lokality Depozitáře NK – Hostivař - Datové centrum H02.
Následující obrázek reprezentuje předpokládané fyzické umístění skříní RACK.
XXX
35
1.3.10 Hmotnostní a příkonová analýza
XXX
1.3.11 Dodávaná prostředí
1.3.11.1 Produkční prostředí
Produkční prostředí systému se skládá z následujících komponent: Skenery a skenovací pracoviště – lokality Brno a Praha Hostivař
Pracovní stanice – celkem 51 stanic, které mohou být rozmístěny dle potřeby Objednatele
Datové centrum – koncentruje veškerou kapacitu jak úložiště, tak výpočetní. Komponenty datového centra pro Systém NDK jsou umístěny v datovém centru Hostivař. Datové centrum zahrnuje veškerý HW a SW provozovaný centrálně (Workflow, LTP, Subsystém zpřístupnění)
Uložení off-line záloh pásek – ve dvou lokalitách rozdílných od primární lokality datového centra budou uloženy pásky obsahující zálohy dat LTP
Celý systém zajišťuje bezpečnost řešení (využívání bezpečných protokolů HTTPS apod., bezpodmínečná autentizace všech uživatelů i systémů navzájem). Dostatečný výkon systému je zajištěn využitím nejmodernějších serverů a řešení pro úložiště. Zároveň je možné systém výkonově
36
škálovat prostým přidáváním výpočetních uzlů (transformační modul a OCR) a dodáváním diskové a páskové kapacity do infrastruktury úložišť.
Pro lokalitu Brno nepředpokládáme instalaci serverových komponent. Pouze bude instalován dodatečný aktivní síťový prvek pro připojení nových pracovních stanic a skenerů.
XXX
Obrázek 15 - Schéma produkčního prostředí
1.3.11.2 Testovací prostředí
Pro testování bude v rámci systémů v datovém centru vytvořeno testovací prostředí, kde bude nakonfigurována logicky stejná architektura jako v produkčním prostředí.
Pro vytvořené testovací prostředí budou vyhrazeny:
Dva fyzické blade servery jako hostitelské pro virtualizované testovací prostředí Prostor na úložišti
Prostor v LTP úložišti o velikosti 10TB bez dalších omezení
37
SMLOUVA O POSKYTOVÁNÍ SLUŽEB SYSTÉMOVÉHO INTEGRÁTORA
1.3.12 Zálohování napájení
1.3.12.1 Praha-Hostivař
XXX
Silový rozvaděč RUPS bude instalován v datovém centru v blízkosti zdroje UPS. Z výstupu UPS bude napájena zálohovaná sběrnice a z ní bude napájena konfigurace IT HW umístěná ve čtyřech serverových skříních (racích), jedna ze skříní bude bez napájení. Do každé skříně budou přivedeny dva silové okruhy s příslušnou dimenzí kabelu a typem průmyslové zásuvky, zpravidla IEC 309. Do nich pak budou zapojeny napájecí lišty PDU, které budou instalovány ve skříních a nejsou součástí této nabídky.
Z rozvaděče RUPS bude vyveden kabel pro napájení rozvaděče RSD, který bude umístěn v místnosti skenerů nebo na chodbě v její blízkosti. Z tohoto rozvaděče budou napájeny veškeré skenery instalované v této místnosti. Silové okruhy s patřičnými dimenzemi kabelů a jištěním budou přivedeny do blízkosti skenerů a zakončeny zásuvkou odpovídající typu skeneru.
Počty silových okruhů jsou zřejmé ze zjednodušeného schématu:
Napájení IT:
XXX
Ve výkonu zdroje UPS je již započítána rezerva 50% dle Zadávací dokumentace. Pokud by měl být zálohován pouze IT HW, postačil by výkon zdroje UPS 30kVA.
Předpokládáme, že pracovní stanice se dvěma monitory a připojeným skenerem budou napájeny lokálním zdrojem UPS, který není součástí naší nabídky, neboť očekáváme, že bude součástí dodávky dodavatele pracovních stanic.
Hlavní položky dodávky:
XXX
1.3.12.2 MZK Brno
XXX
Manuální bypass bude realizován v silovém rozvaděči RUPS – viz nástin zapojení. Předpokládáme, že vývod/jistící prvek pro připojení zdroje UPS bude připraven ve stávajícím rozvaděči a rovněž bude k dispozici zařízení na měření odběru elektrické energie.
XXX
Silový rozvaděč RUPS bude instalován v datovém centru v blízkosti zdroje UPS. Z výstupu UPS bude napájena zálohovaná sběrnice a z ní bude možné v budoucnosti napájet zařízení instalovaná v datovém centru. V této fázi bude připraven rozvaděč s jističi, ale nebudou realizovány silové okruhy z důvodu omezení investičních nákladů.
Z rozvaděče RUPS bude vyveden kabel pro napájení stávajícího rozvaděče na chodbě S137 před místností č. S140.
Z tohoto rozvaděče budou napájeny veškeré skenery instalované v místnosti č. 140. Silové okruhy s patřičnými dimenzemi kabelů a jištěním budou přivedeny do blízkosti skenerů a zakončeny zásuvkou odpovídající typu skeneru.
Počty silových okruhů jsou zřejmé ze zjednodušeného schématu:
XXX
Dále bude připraveno napájení pro venkovní klimatizační jednotky (propojení mezi venkovními a vnitřními jednotkami bude provedeno při samotné instalaci chlazení a je započítáno v ceně - jedná se o verzi split jednotek).
41
XXX
Ve výkonu zdroje UPS je již započítána rezerva 50% dle Zadávací dokumentace.
Předpokládáme, že pracovní stanice se dvěma monitory a připojeným skenerem budou napájeny lokálním zdrojem UPS, který není součástí naší nabídky, neboť očekáváme, že bude součástí dodávky dodavatele pracovních stanic.
Hlavní položky dodávky:
XXX
42
SMLOUVA O POSKYTOVÁNÍ SLUŽEB SYSTÉMOVÉHO INTEGRÁTORA
XXX
1.3.13 Chlazení
1.3.13.1 Praha Hostivař
Nově instalovaný HW do datového centra si vyžádá navýšení chladící kapacity o 8kW, která již v sobě také zahrnuje zmiňovanou rezervu 50%. Byla vybrána jednotka o max. chladícím výkonu 10kW. Jedná se o venkovní jednotku XXX.
Pokud budeme uvažovat o redundanci řešení, je nutné vzít v úvahu, že v datovém centru je volná kapacita chlazení cca 9,8kW. Touto kapacitou by byl pokryt jak výpadek jedné ze stávajících klimatizací, tak výpadek navrhované klimatizační jednotky. Do datového centra tedy navrhujeme na doplnění chladící kapacity pouze jednu jednotku.
V místnosti se skenery by se měly použít klimatizační jednotky o celkovém chladícím výkonu 11kW. I v této hodnotě je počítáno s rezervou 50%. Pro zvýšení spolehlivosti a dostupnosti chlazení navrhujeme jednotky v redundanci 1+1 o max. chladícím výkonu 12,3kW. Navrhujeme venkovní
XXX | XXXX | XXX | XXX. Vzhledem k tomu, |
že neznáme přesné dispozice | objektu v Praze | Hostivaři, | vytvořili jsme cenovou kalkulaci za |
předpokladu, že potrubí mezi venkovními a vnitřními jednotkami nepřesáhne délku 20m. XXX | |||
43 | |||
XXX
Začlenění do monitoringu APC Infrastruxure Central
Předpokládáme, že zdroj UPS APC Galaxy bude připojen přes SNMP adaptér, který je standardní výbavou, do Objednatelovy sítě. Spolupráce s APC Infrastruxure Central je nativní vlastností tohoto adaptéru.
Klimatizační jednotky jsou schopny předat signál o poruše, který bude moci Infrastruxure Central zpracovat prostřednictvím adaptéru typu kontakt.
1.3.13.2 MZK Brno
Chlazení je navrženo dle projektu, který je součástí Zadávací dokumentace, protože lze předpokládat, že Objednatel bude chtít řešit chlazení nového datového centra na jedné straně a na straně druhé není na základě obdržených odpovědí na dotazy účastníků výběrového řízení zcela jasné, jak k problematice chlazení DC přistoupit v případě, že řešení nepředpokládá umístění nabízeného HW do tohoto DC, protože je uvedeno, že alternativy výběrové řízení nepřipouští.
Avšak dvě venkovní kondenzační jednotky jsou nutné kvůli chlazení skenerů, které je povinné, jak jsme také pochopili z obdržených odpovědí.
Dvě jednotky jsou navrženy z důvodu redundance (1+1). Toto řešení je zvoleno také z důvodu příliš dlouhé trasy pro trubky vedoucích od venkovních jednotek a pro příliš velké převýšení vnitřních a venkovních jednotek.
44
Pokud bude rozhodnuto nechladit DC, lze odečíst 12 vnitřních jednotek z cenové kalkulace. V rámci hledání rezerv jsme tyto jednotky z kalkulace vypustili a ponechali v DC dvě jednotky pro chlazení zdroje UPS a dvě jednotky v místnosti skenerů – verze kondenzačních jednotek.
Ještě jsme přidali variantu chlazení v MZK Brno pouze s dvěma dvojicemi split jednotek, jednou pro
DC a jednou pro místnost skenerů.
Výkon venkovních jednotek je dodržen ve shodě s projektem, vnitřní jednotky v místnosti skenerů
mají oproti projektu výkon vyšší.
V místnosti se skenery by se měly použít klimatizační jednotky o celkovém chladícím výkonu 11kW.
I v této hodnotě je počítáno s rezervou 50%. Z důvodu přiblížení se k požadavkům projektu chlazení, navrhujeme chlazení jednotkami v redundanci 1+1 o max. chladícím výkonu 7,1kW.
Hlavní položky dodávky verze split jednotky:
Popis | Množství |
XXX
1.3.14 Přehled dodávaných komponent
1.3.14.1 Servery a související infrastruktura
XXX
1.3.14.2 Úložiště a LTP
XXX
50
1.3.14.3 Licence po zadání
XXX
1.3.14.4 Síťová infrastruktura
XXX
1.3.14.5 Systémový SW
XXX
1.4 Specifikace realizace subsystému digitalizace
Subsystém digitalizace je, vzhledem k hodnotícímu kritériu celého Projektu NDK, kterým je počet digitalizovaných stran, klíčovou součástí celého systému, na které závisí úspěch či neúspěch Projektu NDK. Zajišťuje převod fyzických předloh do jejich digitální podoby a jejich přípravu pro transformaci,
52
dlouhodobé uložení a prezentaci. Cílem digitalizace je připravit podmínky pro dlouhodobé uchování obrazů originálních publikací a jiných listinných pramenů v digitální formě jako AIP. Celý proces je řízen prostřednictvím Workflow
Proces digitalizace obsahuje jak fyzický tok materiálu, tak samozřejmě pořizování, úpravu dat a jejich přesun v infrastruktuře až do okamžiku uložení. Fyzické přesuny znamenají přesun předloh z depozitáře na digitalizační pracoviště, jejich manipulaci na pracovišti a následné vrácení zpracovaných knih zpět na původní pozice ve skladech. Přesuny mezi jednotlivými komponentami infrastruktury jsou fázemi zpracování pořízených dat, postupného obohacování a doplňování metadat. Digitální obrazy budou vytvářeny na digitalizačních zařízeních (skenerech) jejichž vlastnosti plně odpovídají požadavkům definovaným v Zadávací dokumentaci.
Úkolem navrhovaného řešení je vytvoření intelektuální entity odpovídající konkrétní předloze. U monografií tak vzniká entita na úrovni svazku. Jedná-li se o vícesvazkovou publikaci, pak jsou vzájemné vazby popsány v metadatech, jejichž množina vzniká během zpracování. Obdobně u svázaných periodik jsou intelektuální entitou jednotlivá čísla a přiřazená do konkrétního ročníku.
Vytvářením entit ve formátu vhodném pro uložení v LTP projdou také předlohy, které jsou již v digitální podobě a budou čerpány z externích zdrojů (Manuscriptorium, WebArchiv, Kramerius). Data z těchto zdrojů budou zpracovávána Transformačním modulem (viz kapitola 1.6).
Zpracování končí vytvořením PSP odeslaným do Transformačního modulu, který vytvoří SIP 1 a 2, které jsou ukládány do LTP a do aplikace Kramerius.
V dalším textu je popsána struktura dodávaných komponent Subsystému digitalizace a popis procesu digitalizace.
1.4.1 Struktura dodávky
S cílem dodat vybavení digitalizačních pracovišť pro NK a MZK bude mít dodávka následující části:
a) Digitalizační zařízení – skenery v počtech a struktuře vyžadované Zadávací dokumentací. Každý ze skenerů je vybaven čtečkou čárových kódů, stanicí resp. serverem (v závislosti na typu)
b) Software pro importně exportní funkce umožňující minimálně následující:
a. importovat bibliografické záznamy digitalizovaných dokumentů ve formátech MARC 21, MARC XML
b. importovat popisná metadata ve formátech MODS aktuální verze nebo verze předchozí, DublinCore, MARC XML, strukturální metadata ve formátu XML
c. importovat obrazové soubory vytvořené na skenerech v běžných formátech (min. TIFF, JPEG2000, JPEG, PNG)
d. importovat textové soubory ve formátu TXT a soubory ve formátu ALTO XML
e. importovat čárové kódy (identifikace jednotlivých svazků)
f. importovat digitalizované dokumenty nebo jejich části (pro opravy, editace apod.)
g. importovat digitální dokumenty po konverzi
h. exportovat digitalizované dokumenty v předepsané struktuře dle přílohy Definice SIP/PSP pro digitalizaci v rámci NDK IOP
i. exportovat dokumenty nebo jejich části (data a metadata) v různém stadiu zpracování
j. exportovat výstup podle vlastní konfigurace
c) Software pro zpracování obrazových dat (imageprocessing) umožňující minimálně následující
a. provádět ořez (uvnitř a vně okraje dokumentu), narovnání (podle řádků textu), potlačení šumu a pozadí ve formátu TIFF a uložení ve formátu JPEG2000 bez komprese nebo s bezeztrátovou kompresí (preservation master), dle specifikace pro LTP a se ztrátovou kompresí dle specifikace pro Kramerius 4, aplikace bude schopna porovnat shodu archivních souborů ve formátu TIFF a JPEG2000
b. bude možné specifikovat parametry příkazu pro konverzi do JPEG2000 včetně volby kodeku (knihovny, např. Kakadu)
c. provádět konverze z formátu TIFF do JPEG2000, JPEG
d. vytvářet kontrolní součty pro každý soubor při uložení
e. kontrolovat kvalitu obrazových souborů
f. parametrizovat, že obrazové soubory budou obsahovat 1 stranu dokumentu
g. spojovat dva obrázky do jednoho souboru (mapy, tabulky apod.)
x. xxxxxxxxx velké předlohy po sekcích a kompletovat je (stitching)
i. skenovat všechny strany dokumentu včetně nepotištěných
d) Aplikace pro přípravu a plánování digitalizace umožňující minimálně následující:
a. provádět výběr a vyžádání dokumentu pro digitalizaci
b. zařadit tento dokument do digitalizačního plánu
c. provede základní přípravné operace včetně přiřazení dokumentu ke konkrétním skenerům
d. výběr dokumentů z dostupných zdrojů
e. sledovat lhůty dodání dokumentů pro digitalizaci
f. provádět varovná hlášení při nedodání dokumentů
g. vytvářet dílčí a celkové reporty pro řízení procesu a pracovišť
e) Aplikace pro OCR umožňující minimálně následující:
a. vytvářet z obrazových souborů obsahující tištěné texty fulltext ve formátech ALTO XML dle Zadávací dokumentace
b. z výše uvedeného výsledného formátu ihned nebo dodatečně generovat soubory ve formátu TXT a dvouvrstvé PDF (horní – viditelná vrstva obrázek, spodní text)
c. automatické vyhodnocování úspěšnosti OCR
d. využívat externí slovníky a sady starších fontů vytvořených v rámci vývojových projektů v ČR
e. implementovat vybrané nástroje evropského projektu IMPACT a dalších projektů výzkumu a vývoje
f) Systém pro management a sledování procesu digitalizace - v rámci celoplošného systému, který bude zajišťovat management a sledování všech procesů a monitoring systému jako takového, budou v subsystému digitalizace evidovány minimálně následující typy operací:
a. toky dokumentů
b. plnění závazných indikátorů
c. sledování výkonů
V průběhu celého pracovního procesu (příprava dokumentů, skenování, zpracování a editace metadat) budou dokumenty evidovány na jednotlivé operátory. Každý operátor si bude přebírat dokumenty ke zpracování načtením čárového kódu na knize na vlastní konto. Pro každý typ zpracování bude možné nastavit časový limit, do kterého bude třeba knihu předat k dalšímu zpracování, nebo vrátit prostřednictvím knihovního systému. Po uplynutí časového limitu budou formou logu vypsány nevrácené dokumenty a upozorněn příslušný operátor a jeho vedoucí.
Systém pro management a sledování procesu digitalizace dále umožní minimálně následující:
d. evidenci zhotovených obrazových souborů, digitalizovaných stran, digitalizovaných svazků dle předem definovaných časových intervalů
e. sledování pracovních výkonů podle skenerů, pracovních stanic a operátorů dle předem definovaných časových intervalů
f. v případě neplnění přednastavených hodnot bude zobrazovat varovné logy
x. xxxxxxx definování projektů a bude schopen přiřadit operátory specifickým úkolům nebo projektům a fázím
h. sledování všech zpětných logů pro případné možné realokování zdrojů v různých fázích nebo projektech
i. provádět změny v následnosti fází, akceptování již částečně vytvořených dokumentů
na externím pracovišti a zahájit fázi uvnitř Workflow prezentovat získaná data formou tabulek a grafů
g) Školení obslužného personálu – dosažení cíle zpracovat 26 mil. stran předloh je závislý na výkonu technologie a vycvičenosti obsluhy a organizaci práce. Kapacita technologie je nezpochybnitelná a prověřená. Limitujícím faktorem je v případě hromadné digitalizace výkonnost obsluhy. Společnost Logica na základě svých zkušeností doporučuje vyškolit skupinu tzv. klíčových uživatelů, kteří budou představovat základnu expertýzy pro zbytek zaměstnanců zapojených do digitalizace. Vzhledem k předpokládanému počtu obsluhy zahrnující operátory skenerů, pracovníky pro úpravu obrazů (grafik) a obsluhu pracoviště přípravy předloh a směnnosti je předpokládaný počet klíčových zaměstnanců odhadnut na max. 30 pracovníků. Po vyškolení a zapracování budou klíčoví uživatelé využiti jako interní
trenéři ostatních pracovníků. Klíčoví uživatelé budou rozděleni do tří skupin (max. 10) a budou procházet školeními na jednotlivých zařízeních a aplikacích.
Požadavky na pracovníky v roli klíčového uživatele:
- Předchozí praxe ze stávajících digitalizačních pracovišť
- Počítačová gramotnost na úrovni pokročilého uživatele
- Min. pasivní znalost anglického jazyka
Před zařazením do skupiny klíčových uživatelů bude nutné ověřit kvalifikaci frekventantů školení. Tento krok je nezbytný pro odstranění rizika zpoždění projektu z důvodu uživatelských chyb.
Každá skupina projde následujícím školícím cyklem:
I. Proces digitalizace a jeho řízení (Plánovací modul a Workflow) – 4 hodiny
II. Práce s aplikacemi (postprocessing, OCR, Editační modul, transformační modul) – 8 hodin
III. Obsluha robotických skenerů – 8 hodin
Kurzy jsou řazeny takto z důvodu, aby je bylo možné uspořádat nezávisle na dodávce a instalaci robotů. Harmonogram školení bude součástí prováděcího projektu a bude stanoven na základě zhodnocení dostupnosti vhodných uchazečů pro roli klíčového uživatele.
h) Školící materiály obsahující popis jednotlivých operací a činností při digitalizaci
i) Plné uživatelské manuály/příručky ke všem hardwarovým a softwarovým řešením digitalizačního pracoviště. Součástí těchto dokumentů bude i specifikace produktu s jeho
optimálním nastavením a uživatelská příručka ve vztahu k servisním podmínkám a maintenance V dokumentaci pro aplikaci Workflow bude rovněž uveden popis procesů a subprocesů včetně jejich nutné sekvence nebo paralelizace.
j) Školení administrátorů (2)
k) Administrátorské příručky
Subsystém digitalizace ve spolupráci s Workflow umožní dále minimálně následující:
a) v různých krocích procesu digitalizace opatřovat dokumenty všemi požadovanými metadaty (popisná metadata, strukturální metadata a technická a administrativní metadata) požadovanými a definovanými Zadávací dokumentaci.
b) spolupracovat s dalšími systémy (knihovní systém Aleph, Registr digitalizace, Kramerius, LTP a Resolver URN:NBN). Pro manipulaci se záznamy, digitálními daty a knižními svazky budou využívány identifikátory definované v Zadávací dokumentaci
c) předávat sestavy metadat a souborů vztahujících se k jednotlivým digitalizovaným svazkům formou kontejnerového formátu METS 1.9 definovaný v Zadávací dokumentaci
d) vytvářet identifikátory pro skenery, pracovní stanice a operátory
e) provádět kontrolu konzistence
f) přebírat úkoly mezi lokalitami (Praha, NKČR a Brno, MZK)
g) zhotovené uživatelské kopie dokumentů vzájemně replikovat mezi systémy NKČR a MZK
1.4.2 Řízení digitalizace
Celý proces digitalizace je řízen prostřednictvím Workflow (blíže popsané v kapitole 2.3.1), prostřednictvím kterého je možné sledovat stav zpracování předloh a které slouží jako rozhraní pro řízení manuálních operací s předlohami. Zároveň jsou do něj promítány změny stavu předloh, které nastávají jako výsledek automatického zpracování. Workflow umožňuje spouštění jak celého procesu, tak autonomní spuštění jednotlivých kroků nebo jejich vynechání. Rovněž tak zaznamenává provozní poruchy a vyvolává potřebu náhradního postupu.
V celém průběhu procesu digitalizace je možné provádět validace struktury pracovního adresáře a úpravy dat pomocí Editačního modulu. Manuální úpravy pomocí Editačního modulu budou dostupné zejména při doplňování metadat, vytváření entit a řešení chybových stavů. Editační modul je popsán v kapitole 1.6.6.2
1.4.2.1 Podpora plánování digitalizace
Žádný projekt rozsahu srovnatelného s Projektem NDK se v dnešní době neobejde bez kvalitního plánování prací a kapacit. Po uvedení technické infrastruktury do provozu se těžištěm projektu stane samotná digitalizace dokumentů. Jde o fázi projektu organizačně neméně složitou než budování technického zázemí. Cílový objem digitalizovaných dat je značný a mají-li být dodrženy zadané termíny, je třeba využívat kapacity pracovišť co možná nejefektivněji. Pro tyto účely vyvine Poskytovatel v rámci Subsystému digitalizace Aplikaci pro podporu plánování digitalizace. Jejím účelem je zajistit plynulou a rovnoměrnou dodávku vhodných dokumentů na digitalizační linky tak, aby byla plně využívána kapacita instalovaných zařízení a byla tak dodržena produkce dostatečná pro splnění cílů Projektu NDK.
1.4.2.1.1 Koncept plánování
Aby bylo maximálně využito kapacit skenovacích zařízení, je třeba umožnit jejich nepřetržité zásobování prací, neboli zajistit odpovídající dodávku dokumentů určených k digitalizaci. Aplikace pro podporu plánování k tomuto účelu využívá kapacity meziskladů jako zásobníku pro samotný proces digitalizace. Z pohledu plánování je navrhovaný cyklus digitalizovaného dokumentu v systému následující:
Aplikace přijímá požadavky na digitalizaci v podobě seznamu děl. Přijaté požadavky jsou validovány a informace o dokumentech jsou uloženy ve Workflow a doplněny o základní data z dalších interních či externích zdrojů (Aleph, RD). Periodicky nebo na vyžádání obsluhy je možné vygenerovat seznam požadavků na dodávku dokumentů na digitalizační pracoviště, na jehož základě jsou fyzické dokumenty postupně dodávány z depozitářů do meziskladů, kde si je přebírají pracovníci digitalizačních linek a dále je zpracovávají. Po úspěšném zpracování naskenovaných obrazů jsou fyzické dokumenty odevzdány zpět do původního umístění.
Plánování jednotlivých dokumentů
Po úspěšném přijetí seznamu požadavků na digitalizaci jsou informace o dokumentech zaznamenány ve Workflow a následně obohaceny o popisné informace z externích zdrojů. To umožňuje dokumenty
rozdělit do kategorií dle typu dokumentu (stáří, rozměry apod.). Dokumenty jsou následně zařazeny do fronty dokumentů připravených k digitalizaci. Pro plynulou digitalizaci je potřebné udržovat v meziskladech digitalizačních pracovišť dostatečnou zásobu vhodných dokumentů. Aplikace je úzce propojena s Workflow a jeho prostřednictvím kontroluje aktuální naplnění meziskladů a v případě volné kapacity generuje požadavek na dodání dostatečného počtu čekajících děl z jednotlivých kategorií. Součástí tohoto požadavku může být jmenný seznam vhodných dokumentů.
Celková požadovaná úroveň naplnění meziskladu odpovídá součtu denních kapacit jednotlivých zařízení na daném pracovišti násobenému určitým koeficientem (předpokládá se naplnění skladu v řádu jednotek dnů denní produkce). Bude počítána pro jednotlivé kategorie dokumentů na základě možností a schopností konkrétních zařízení/skenerů na pracovišti. V případě, že zařízení je schopno zpracovávat více kategorií dokumentů, bude jeho kapacita rozdělena mezi kategorie v poměru odpovídajícím počtu dokumentů v příslušných kategoriích čekajících ve frontě na digitalizaci. Volná kapacita meziskladu bude stanovena jako rozdíl požadované úrovně jeho naplnění a jeho aktuálního využití.
O pořadí, v jakém budou konkrétní fyzické dokumenty dodávány do meziskladu, budou rozhodovat pracovníci NDK na základě svého uvážení/preferencí. Systém bude poskytovat indikativní informace o využití kapacit zařízení a vydávat doporučení o vhodné skladbě dodávek tak, aby bylo využití kapacit optimální.
Obdobně budou rozhodovat pracovníci digitalizační linky o pořadí a vhodné volbě skenerů pro digitalizaci dokumentů již připravených v meziskladu. Systém bude mít samoregulační efekt. Nebude- li v dostatečné míře docházet k digitalizaci určité kategorie dokumentu (např. z důvodů odstávky vhodného skeneru), přestane modul generovat požadavky na dodávku příslušných dokumentů do meziskladu. Naopak při vyšší výkonnosti zařízení budou požadavky na dodávku vhodných dokumentů frekventovanější. Zároveň bude takto zajištěna určitá tolerance vůči odchylkám nominální kapacity zařízení od reálných možností – fakticky bude ovlivněna pouze doba, po kterou je mezisklad schopen dodávat dokumenty k digitalizaci bez přísunu nových zásob. Využití pracoviště samotného je neustále maximální.
Pro případ, kdy by celková kapacita digitalizační linky byla dlouhodobě nižší než součet kapacit jednotlivých zařízení (např. z důvodů zdlouhavého OCR), bude systém umožňovat regulování požadované úrovně naplnění meziskladu určitým redukčním koeficientem. Zamezí se tak např. zaplnění kapacity pracovního datového úložiště.
Uvolnění dokumentu z meziskladu je řízeno informací z Workflow a nastává ve chvíli, kdy se dokument dostane do stavu zpracování, kdy již nemůže být požadováno doskenování.
Aplikace plánování
Depozitář
Knihovník
Požadavky na dodávku
Stav
Úkol y
Zpracování obrazů
Obsluha digitalizační linky
Legenda:
LTP
Dokumenty
Požadavky na digitalizaci
Objekty k | Stav digitalizace | Mezisklad |
digitalizaci | Metadata dokumentů | A |
C | ||
Stav | B | |
Úkoly | ||
Obsluha | ||
digitalizační linky |
Extenrí zdroje | |
(Aleph, RD, | Stav |
URN Resolver) | WF |
Úkoly |
Obsluha | ||
digitalizační linkySkener 1 | Skener 2 | Skener 3 |
Data
Informace
Obrázek 20 - Zjednodušené schéma plánování
Interní projekty
Aplikace pro podporu plánování bude umožňovat seskupovat digitalizované dokumenty do ucelených logických celků. To usnadní dohled nad postupem digitalizace a umožní smysluplnou prioritizaci dodávek na digitalizační pracoviště. Pro tyto účely bude možné v grafickém rozhrání aplikace definovat interní projekty a jejich atributy. Pod interním projektem si je možné představit např. soubor periodik první poloviny 19. Století apod. Základními atributy projektu budou:
Název interního projektu Kód projektu
Popis projektu
Předpokládaný objem digitalizovaných dokumentů
Předpokládané datum zahájení digitalizace dokumentů náležejících do projektu Datum, do kterého má být dokončena digitalizace dokumentů náležejících do projektu
Na základě definovaných atributů interního projektu a informací z Workflow bude v kterémkoli okamžiku možné vyhodnotit stav zvoleného interního projektu.
1.4.2.1.2 Postup plánování
Zadávání požadavků na digitalizaci
Zadání požadavku na digitalizaci představuje načtení seznamu dokumentů v předem definovaném formátu (předpokládáme XLS/CSV) do modulu plánování. Alternativně může být tento seznam získán prostřednictvím integrace s Registrem digitalizace. Systém provede kontrolu formátu vstupních dat a ověří přítomnost všech údajů potřebných pro zahrnutí jednotlivých dokumentů do plánu digitalizace. V případě nevalidních, či neúplných údajů bude uživatel upozorněn a bude mu předán seznam neúspěšných požadavků společně s důvodem zamítnutí. Předpokládá se dodání následujících základních identifikačních údajů o díle:
Identifikátor dokumentu
Pracoviště, ke kterému dokument přísluší (možno odvodit i dle zadávajícího uživatele) Identifikátor interního projektu (volitelné)
Systém automaticky doplní další údaje o díle potřebné k plánování s využitím integrace s Aleph, resp. URN Resolveru. Jedná se zejména o následující údaje:
URN (z URN Resolveru)
Počet stran (z Aleph) Rozměry (z Aleph)
Typ dokumentu (periodikum, monografie, stáří, rozměry apod. – z Aleph)
V případě neúspěšného doplnění některého z údajů bude uživatel notifikován o nutnosti doplnění těchto údajů ve zdrojových systémech prostřednictvím úkolu Workflow. Rovněž dojde-li ke zjištění, že totožný dokument již byl, nebo má být digitalizován na jiném pracovišti (využití Registru digitalizace), bude na to uživatel upozorněn prostřednictvím Workflow.
Po doplnění potřebných metadat je dokument již považován za připravený k digitalizaci a je možné ho dodat na digitalizační pracoviště. Zároveň je informace o jeho zahrnutí do plánované digitalizace v rámci NDK zanesena do registru digitalizace (v případě, že zde již není veden). Nebude-li dokument připravený k digitalizaci dodán na digitalizační pracoviště ve stanovené lhůtě, bude o tom zodpovědný uživatel notifikován prostřednictvím nástrojů Workflow.
Dodávka do meziskladu
V kterémkoli okamžiku bude mít oprávněný uživatel možnost vygenerovat seznam požadavků na dodávku dokumentů do meziskladu. Aplikace bude využívat aktuální informace o stavu digitalizace a
využití meziskladu z Workflow. Výstupní seznam bude obsahovat souhrnnou informaci o počtu dokumentů v jednotlivých kategoriích, které je třeba dodat do meziskladu, aby byla udržena dostatečná úroveň rezervy pro digitalizační linku. Volitelně bude pak obsahovat podrobný seznam dokumentů v jednotlivých kategoriích vhodných k dodávce (tj. takových dokumentů, kde jsou mj. dostupné všechny potřebné údaje).
Po dodání fyzických dokumentů do meziskladu bude v systému alokována odpovídající kapacita daného skladu. Po úspěšném skenování a zpracování obrazů budou dokumenty vyskladněny a kapacita bude opět uvolněna.
Digitalizace a vrácení dokumentu
Od chvíle přijetí dokumentu do meziskladu bude až do okamžiku opětovného vyskladnění manipulace s ním čistě v kompetenci oprávněných pracovníků. Modul plánování nijak nezasahuje do samotného procesu digitalizace. O konečné volbě vhodného skeneru rozhodují pracovníci na pracovišti dle svého odborného úsudku. To umožňuje maximální flexibilitu procesu a odbourává zdržení zapříčiněná formálními změnami plánu. Veškeré informace o stavu a průběhu digitalizace jsou ukládány ve Workflow.
Po celou dobu fyzické přítomnosti dokumentu na pracovišti je z pohledu modulu plánování na tento dokument nahlíženo jako na dokument blokující část kapacity příslušných zařízení. Dokument je určen k vyskladnění v momentu úspěšného zpracování naskenovaných obrazů, kdy je již nepravděpodobné, že by bylo nutné s ním dále fyzicky manipulovat (re-sken apod.). V okamžiku vyskladnění je blokovaná kapacita uvolněna a modul plánování tento dokument považuje za odbavený.
1.4.2.1.3 Nastavení parametrů plánovací aplikace
Aplikace pro podporu plánování bude umožňovat konfiguraci parametrů plánování týkajících se digitalizační linky. Jedná se zejména o typy skenerů na pracovištích, jejich kapacity, nutné rezervy, kategorie dokumentů, které jsou schopny zpracovávat atd. Konfigurace bude prováděna kvalifikovanou osobou prostřednictvím konfiguračního souboru ve formátu definovaném v průběhu prováděcího projektu.
Konfigurace obsahuje:
Definice kategorií dokumentů
o Druh dokumentu
o Stáří (rozpětí)
o Rozměry (rozpětí)
o Náročnost manipulace Definice typu zařízení
o Kapacita
o Rezerva
o Přípustné kategorie dokumentů
61
Definice pracovišť
o Maximální kapacita pracoviště
o Maximální kapacita meziskladu
o Optimální využití meziskladu (násobek denní kapacity pracoviště)
o Seznam zařízení
1.4.3 Proces digitalizace
Vstupem do procesu digitalizace je seznam požadavků na dodávku předloh sestavený na základě dostupnosti a vlastností předloh, kapacity digitalizačních zařízení a propustnosti digitalizačních pracovišť. Dalším vstupem jsou samotné předlohy fyzicky připravené k digitalizaci, a data ze systémů NK/MZK (Aleph, Resolver URN:NBN). Popis procesu digitalizace vychází z podmínky uvedené v zadávací dokumentaci, uvádějící požadavek zpracování 95% předloh na robotických zařízeních a současně jsou 2/3 předloh ve formátu A4, 1/3 formátu A3. Proto se detailní popisy postupů (pokud jsou uvedeny) týkají robotických zařízení.
1.4.3.1 Krok 1 Plánování digitalizace
Podpora plánování je popsána v předchozí kapitole.
1.4.3.2 Krok 2 – Fyzická příprava předloh
Předlohy zařazené do plánu digitalizace jsou připraveny v meziskladu podle svých vlastností (typu předlohy) pro jednotlivá digitalizační zařízení (skenery). V případě meziskladu se nemusí jednat o fyzicky oddělený prostor, ale pouze o část regálové kapacity doplněné manipulační plochou. Poskytovatel předpokládá použití ručních manipulačních prostředků pro dopravu předloh z meziskladu ke skenerům. Personál meziskladu předlohy roztřídí podle toho, na kterém skeneru mají být předlohy zpracovávány a postupně dle požadavku obsluhy skeneru je bez rozlišení obsahu konkrétní předlohy (rozhoduje pouze typ) dodává na pracoviště skeneru. Podle zkušeností z jiných pracovišť v obdobných institucích je dvoučlenná obsluha meziskladu schopna připravit za 8 hodin dávku pro zpracování na dalších 24 hodin.
1.4.3.3 Krok 3 – Příprava k digitalizaci
Na základě údajů digitalizačního plánu jsou na digitalizačním pracovišti předlohy rozděleny podle svého charakteru a přiděleny k jednotlivým zařízením, resp. operátorům. Podstatným faktorem pro dodržení plánované kapacity pracoviště je přiřazení množiny předloh se stejnými vlastnostmi konkrétnímu zařízení. Tyto vlastnosti jsou zejména:
a) Rozměry knihy
b) Typ vazby
c) Druh papíru a jeho stav
Obrázek 21 – Šetrné nakládání s poškozenou předlohou
Pokud nejsou předlohy takto setříděny, vznikají prostoje z důvodu přenastavování skenerů.
Ve Workflow je od přijetí na digitalizační pracoviště dávka přiřazená na směnu zaznamenána a je sledován průběh jejího zpracování.
Obsluha skeneru zahájí zpracování předlohy provedením záznamu v aplikaci na počítači, ke kterému je skener připojen, sejmutím čárového kódu čtečkou připojenou ke skeneru. Jestliže bude použit robotický skener, vloží předlohu do zařízení a provede nastavení a fixaci. Způsob fixace předlohy se liší podle typu zařízení.
Např. u skeneru TREVENTUS ScanROBOT 2.0 MDS je dokument vkládán do kolébky zajišťující citlivé zacházení s předlohou a nerozevírající plně vazbu. Pro citlivé zacházení s poškozenými tisky je u tohoto zařízení světelným zdrojem osvitu předlohy LED dioda, která neemituje tepelné záření. Použitím kolébky a diodového zdroje světla je dosaženo fyzikálně neutrálního prostředí, v němž je předloha zpracovávána.
V případě jiných zařízení je předloha fixována magnetickými pásky nebo zarážkami. Způsob nastavení a jeho kontroly je vždy popsán v uživatelské dokumentaci, která je součástí dodávky.
Operátoři skenerů budou proškoleni na všechny typy zařízení z důvodu zajištění vzájemné zastupitelnosti. Jestliže je použit ruční skener, pak je nastavení rovněž kontrolováno, fixace nikoli. Na každém z dodávaných zařízení je možné zvolit formát snímků, rozlišení, kontrast, hloubku, barevné vyvážení apod.
1.4.3.4 Krok 4 – Pořízení digitální kopie předlohy
Obsluha skeneru provede naskenování předlohy a po jeho dokončení tuto skutečnost manuálně zaznamená do aplikace na počítači, ke kterému je skener připojen.
V průběhu zpracování sleduje obsluha robotického skeneru na pracovní stanici průběh skenování a provádí vizuální kontrolu kvality. Současně dohlíží na činnost skeneru a polohu předlohy. Jednotlivé stránky jsou oddělovány proudem vzduchu automaticky. Současné otočení dvou stran je u robotických skenerů kontrolováno ultrazvukovým čidlem. Další kontrolou je počítadlo stránek, které
je uživatelsky nastavitelné (možno nastavit hodnotu i polohu v rámci obrazovky) – je sledována shoda s číslováním stránek. Pokud obsluha zjistí současné otočení dvou stránek, je možné vrátit se zpět a spojené strany odělit manuálně za použití pistole s proudem vzduchu.
Skenování prvních a závěrečných stran předloh a vyrovnávání předlohy je v případě robotických skenerů řešeno konstrukcí lůžka, které je konstruováno jako dvoudílné pohyblivé nebo jako kolébka. Bližší popis je uveden v kapitole 1.6.4.
Pokud operátor zjistí, že nebyly zpracovány všechny stránky sekvenčně, automatika robotického skeneru zaznamená tuto provozní událost a zaznamená informaci do Workflow.
Obsluha poté zvolí náhradní postup např. doskenování vynechaných stran na skeneru s plochým ložem
- tento typ skeneru je součástí robotického zařízení (Treventus) - nebo použije jiný typ. Případně zvolí nové skenování. Doskenovávané snímky jsou ukládány do stejného adresáře (Treventus), nebo jsou ukládány do adresáře v jiném použitém zařízení, a pak jsou importovány do adresáře v původním skeneru k ostatním snímkům.
Stejným způsobem jsou doskenovávány nestandardní strany (obálky, vložené přílohy na křídovém papíře). Sjednocení korektního pořadí stran je prováděno v rámci postprocessingu/imageprocessingu.
Na základě zkušeností z jiných digitalizačních pracovišť je možné konstatovat, že za předpokladu správného nastavení robotických skenerů nejsou problémy se zpracováním lesklého nebo křídového papíru. Prodloužení doby zpracování jsou způsobována těžkou vazbou, křehkým papírem a listy uvolněnými z vazby.
Kvalifikovaný odhad pracovní kapacity v závislosti na stáří a typu předlohy:
Typ předlohy | Kapacita |
Monografie 19. století | |
Formát A5 | 1.500 – 2.800 stran/hodina |
do 250 stran bez obrazových příloh rozlišení 300 DPI, barevně
Noviny 19. a 20. století 150 stran/hodina
formát A3
svázané v rámci 1 ročníku, černobílé
obrazové přílohy, rozlišení 300 DPI škála šedi
Novodobý sborník 1.400 – 2.200 stran/hodina
formát A5, křídový papír
600 stran, barevné přílohy, rozlišení 400 DPI
Obrazy předlohy jsou generovány ve formátu, kterým je bezeztrátový TIFF. Obraz ve formátu TIFF bude využit pro dočasnou kopii, vytvořenou při skenování, která se po úpravách (postprocessing, imageprocessing) převádí na bezeztrátový a ztrátový soubor JPEG2000 a původní obraz je vymazán.
Obrazy jsou ukládány do lokálního úložiště na počítači nebo serveru připojeném ke každému skeneru do adresářové struktury. Pro každou předlohu (svazek) je automaticky vytvořena složka reprezentující intelektuální entitu. Pokud má dílo (monografie) více než jeden svazek, pak jsou považovány za oddělené entity a jsou tak zpracovávány. Jejich vzájemný vztah je následně popsán na úrovni metadat.
U periodik je vytvářena intelektuální entita odpovídající svázanému dokumentu (intelektuální entity z jednotlivých čísel a přiřazení do konkrétního ročníku probíhá v dalších krocích Workflow).
Po dokončení skenování je předloha vrácena do meziskladu. Jestliže obsluha rozhodne o novém skenování předlohy, je ve Workflow vedena jako nezpracovaná. Z meziskladu je pak vyjmuta k novému zpracování. Po celou dobu fyzické přítomnosti předlohy na pracovišti je z pohledu modulu plánování na tento dokument nahlíženo jako na dokument blokující část kapacity příslušných zařízení. Dokument je určen k vrácení v okamžiku úspěšného zpracování naskenovaných obrazů, kdy je již nepravděpodobné, že by bylo nutné s ním dále fyzicky manipulovat (re-sken apod.). V okamžiku vyskladnění je blokovaná kapacita uvolněna a modul plánování tento dokument považuje za odbavený.
1.4.3.5 Krok 5 – Vrácení předloh do meziskladu
Po ukončení skenování jsou předlohy obsluhou skenerů uloženy zpět do manipulačního prostředku a předány obsluze meziskladu. Ta zajistí jejich vrácení na původní pozice (popis tohoto postupu není součástí řešení poptávaného Objednatelem). Poskytovatel předpokládá, že budou provedena organizační opatření, která zajistí plynulost fyzického toku předloh na digitalizační pracoviště a zpět. Vrácení předlohy je evidováno ve Workflow.
1.4.3.6 Krok 6 – Přesun dat
Data jsou po ukončení skenování automaticky odeslána z lokálního úložiště stanice do datového centra a uložena do pracovního prostoru. V rámci přenosu dojde (dle typu skeneru) ke konsolidaci dat, případné migraci obrazových formátů (je-li potřeba), extrakci metadat z proprietárních formátů skeneru do standardizovaného interního formátu struktury pracovního adresáře, extrakci a normalizaci fyzických strukturálních metadat. Zároveň je automaticky ověřováno dodržení kvalitativních parametrů obrazů (DPI, barevná hloubka apod.)
Skenování může probíhat i v případě, kdy ze skeneru není dostupné centrální pracoviště (viz architektura systému). V tomto případě jsou naskenovaná data shromažďována na pracovišti skeneru a odeslána do centra po obnovení připojení. Po jejich úspěšném uložení do pracovního prostoru jsou z dočasného úložiště skeneru automaticky odstraněna.
1.4.3.7 Krok 7 – Postprocessing - Imageprocessing
Postprocessing je soubor částečně automatizovaných a manuálních činností. Z tohoto důvodu dochází ke kapacitnímu nesouladu skenování a postprocessingu. Tím se vytváří nezpracovaná zásoba obrazů. Při plánování kapacity pracoviště je nutné brát v úvahu tuto skutečnost. Na základě zkušeností lze konstatovat, že poměr kapacity skenování a pracoviště postprocessingu je 1:4.
Činnosti postprocessingu (imageprocessingu) jsou prováděny na jiném pracovišti než skenování a průběžná kontrola kvality pořizovaných obrazů. Postprocessing je prováděn na virtualizovaných pracovních stanicích a je možné ho provádět na libovolné fyzické stanici, která má připojení do datového centra. Rychlost zpracování výstupů skenování nemá vliv na rychlost samotného pořizování hrubých obrazových dat za podmínky kompletnosti obrazů. Na datech, která jsou výstupem kroku skenování, je proveden poloautomatický postprocessing naskenovaných souborů. Pomocí převážně interaktivních nástrojů jsou připraveny parametry pro následné dávkové zpracování obrazů. Hrubá obrazová data jsou zpracována do finální podoby master kopií. Obrazy jsou transformovány (aby byl dodržen požadavek věrnosti s předlohou) tak, aby majoritní směr řádků byl vodorovný, je proveden ořez obrazů, rozdělení na stránky (pokud skener produkuje dvoustrany). Dále jsou doplněny chybějící obrazy stránek, desek nebo sloučeny obrazy z paralelního skenování do jedné entity. Součástí postprocessingu je rutinní vizuální kontrola úplnosti skenu stránek a viditelných chyb obrazu.
Pro manuální postprocessing se používají GUI nástroje. Použit může být libovolný nástroj včetně externích a součástí dodané dokumentace bude popis integrace takového nástroje do Workflow. Po zpracování obrazu jsou původní zdrojové obrazy vymazány. V zásadě je technicky možné uchovávat zdrojové obrazy ve formátu TIFF. Avšak je třeba vzít v úvahu vliv na požadovanou kapacitu paměťových médií.
1.4.3.8 Krok 7a – Rozdělení vázaných periodik
Pro vázaná periodika následuje krok logického členění pomocí Editačního modulu. Obsluha Editačního modulu provede dělení předlohy na jednotlivá čísla tak, že v GUI rozhraní na základě zobrazení náhledů
„nakliká“ dělení na jednotlivá čísla. Editační modul tuto činnost podporuje ve formě poloautomatických postupů pro dělení na stejně dlouhé části dle počtu stran, generováním číslování apod. Předloha je v rámci digitalizace nadále zpracovávána jako jedna entita. K rozdělení na jednotlivá čísla dojde až v posledním kroku zpracování před publikací do LTP.
1.4.3.9 Krok 7b – Vytvoření logické struktury intelektuální entity
Pro předlohy, u kterých je požadováno zachycení logického členění, je provedeno rozčlenění s využitím komfortních funkcí (detekce číslování stran, detekce kapitol, analýza obsahu dokumentu) v aplikaci Treventus Scan Gate.
Po dokončení práce v Treventus Scan Gate je ve standardní struktuře pracovního adresáře uložena logická struktura ve formě metadat.
1.4.3.10 Krok 8 – Generování uživatelské kopie
Zpracované obrazy jsou automaticky ukládány do standardní struktury pracovního adresáře uživatelské kopie.
1.4.3.11 Krok 9 - OCR
Nad uživatelskými kopiemi je spuštěno automatické OCR. Aplikace pro OCR vytváří z obrazových souborů obsahujících tištěné texty fulltext ve formátu ALTO XML. Z formátu ALTO XML budou generovány soubory ve formátu TXT a dvouvrstvé PDF (horní – viditelná vrstva obrázek, spodní text).
Součástí aplikace OCR je funkce pro automatizované vyhodnocování úspěšnosti OCR podle zadaných parametrů v % neúspěšně rozpoznaných znaků. Podle úspěšnosti OCR jsou tříděny úspěšně a neúspěšně zpracované předlohy. Úspěšně zpracované obrazy (nad stanovenou hodnotou) jsou automaticky uloženy do jiného adresáře než chybně naskenované obrazy, které by byly pod hranicí nastaveného rozlišení v DPI.
Pokud výsledek OCR nedosahuje požadované kvality, je možné ve Workflow problém řešit buď ignorováním OCR dat a pokračováním bez OCR, nebo akceptací OCR dat s vyšší mírou chybovosti a pokračování, nebo odesláním k alternativnímu OCR, nebo manuální verifikací a nápravou výsledku OCR pomocí funkcí Verifikačního modulu Recognition Serveru.
Výsledkem OCR v dodávaném OCR modulu jsou soubory TXT obsahující text, PDF obsahující anotované obrázky a ALTO XML obsahující text se specifikací layoutu v míře nutné pro provádění highlightingu výsledků hledání.
OCR a rozvojové aktivity v průběhu projektu:
a) Během projektu bude možné využít externí slovníky a sady starších fontů vytvořené v rámci vývojových projektů za předpokladu kompatibility s Enginem FR9 a vyššími verzemi.
b) Pro OCR bude použita aplikace ABBYY Recognition Server, která je partnerem projektu
IMPACT (xxxx://xxx.xxxxxxxxxxxxxx.xx/xx:xxxxxxxx:xxxxxx). Proto bude technicky možné v průběhu projektu implementovat vybrané výstupy IMPACT a případné související výsledky vývoje.
1.4.3.12 Krok 10 – Kompletace balíčku PSP
Je provedena kompletace předlohy. Na základě validace a předepsaného formátu výstupu je provedena konsolidace, dojde k provázání dosud získaných logických (pokud jsou k dispozici) a fyzických strukturálních metadat s výsledky OCR a jsou generovány výsledné sady metadat (METS/ALTO, a další). Probíhá rovněž obohacování metadat o údaje a data z externích zdrojů. Hlavním zdrojem bibliografických metadat je knihovní katalog Aleph.
Pokud se jedná o svázané periodikum, dochází k rozdělení jedné logické entity, která reprezentovala předlohu při zpracování v digitalizaci, na jednotlivé logické entity reprezentující jednotlivá čísla.
Proces digitalizace končí a na pracovním prostoru ve standardizované struktuře pracovního adresáře jsou uložena data ve formě vhodné k předání k uložení do LTP ve formě SIP.
1.4.4 Digitalizační zařízení – skenery
Společné vlastnosti všech zařízení:
Úroveň obrazových výstupů minimálně 300 DPI a vyšší bez interpolace
Všechna zařízení snímají digitální obrazy černobíle, v odstínech šedi i barevně Velikost snímaného obrazu je minimálně 8 bitů/kanál
Každé zařízení je kalibrovatelné
Zařízení jsou obsluhována maximálně jedním operátorem
Každý skener je vybaven čtečkou čárových kódů propojenou s pracovní stanicí Tabulka ISO 210/DIN 476 definující nejběžnější formáty v Česku
A | B | C | D | E | |||||
0 | 841 × 1189 | 1000 | × 1414 | 917 × 1297 | |||||
1 | 594 | × 841 | 707 × 1000 | 648 | × 917 | 545 | × 771 | ||
2 | 594 | × 420 | 500 | × 707 | 458 | × 648 | 385 | × 545 | |
3 | 420 | × 297 | 353 | × 500 | 324 | × 458 | 272 | × 385 | 400 × 560 |
4 | 210 | × 297 | 250 | × 353 | 229 | × 324 | 192 | × 272 | 280 × 400 |
5 | 148 | × 210 | 176 | × 250 | 162 | × 229 | 136 | × 192 | 200 × 280 |
6 | 105 | × 148 | 125 | × 176 | 114 | × 162 | 96 × 136 | 140 × 200 | |
7 | 74 × 105 | 88 × 125 | 81 × 114 | 68 | × 96 | ||||
8 | 52 | × 74 | 62 | × 88 | 57 | × 81 | |||
9 | 37 | × 52 | 44 | × 62 | 40 | × 57 | |||
10 | 26 | × 37 | 31 | × 44 | 28 | × 40 | |||
1.4.4.1 Velkoformátový robotický skener
Požadavek | Robotický skener umožňující skenovat předlohy do formátu A2 |
(otevřená A1) | |
- musí umožnit skenování předloh do formátu předlohy A2 | |
(otevřená A1) | |
- musí být vybaven šetrným mechanismem uchycení | |
snímané předlohy, v ideálním případě ve formě vyvažující | |
se podložky | |
- musí být schopen nasnímat i předlohy, které nejsou | |
předem svázané (v tomto případě je tolerován externí | |
mechanismus provázání předloh, který nemusí | |
poskytovat perzistentní vazbu) | |
- musí být schopno snímat předlohy v rozlišení minimálně | |
300 DPI (optimálně 400 DPI) | |
1 x NK ČR | |
Počet a umístění | 1 x MZK |
1.4.4.1.1 Navrhované řešení
Digitalizační linka 4DigitalBooks DL 3003
Digitalizační linka je vhodná pro všechny typy knih, časopisů, svázaných novin a jiných vázaných předloh. Pracuje s knihami s různou tloušťkou, strukturou i porozitou papíru, měkkými či tuhými deskami vazby a toleruje i desky lehce zdeformované. Xxxxxx byl zkonstruován tak, aby se vyrovnal s rozmanitostmi knižních formátů a kvality papíru. Stránky předlohy jsou fixovány podtlakem.
Obrací stránky a skenuje jejich obsah automaticky bez asistence obsluhy. Vždy se obrátí pouze jedna strana. To je kontrolováno zaručeným systémem detekce papíru. Tak není žádná stránka vynechána, ani nebude naskenována dvakrát. Mechanika obrací vždy pouze jednu stránku zprava doleva.
Obrázek 22 - Digitalizační linka 4DigitalBooks DL 3003 | ||
Formát stránky | minimum A5 ( 148 x 210 mm ), maximum A2 ( 420 x 594 mm ) | |
A5/ A6/ A4/ A3 /A2 | ||
Vlastnosti předlohy | tloušťka knihy až 15 cm | |
maximální váha knížky 20 kg | ||
tloušťka papíru od 20 g/m2 do 200 g/m2 | ||
maximální zvlnění předlohy 25 mm | ||
automatická detekce váhy, tloušťky a velikosti předlohy | ||
Rozlišení | A2 | 200, 300 DPI |
A3 | 200, 300, 400 DPI | |
A4 | 200,300, 400, 600 DPI | |
A5 | 200,300, 400, 600 DPI | |
A6 | 200,300, 400, 600 DPI | |
Rychlost skenování | A5 černobíle: 1.500 – 1.700, barevně: 700 - 950 | |
(stran/hodina) při | A4 | černobíle: 1.800 – 2.200, barevně: 650 - 900 |
rozlišení 300 – 400 DPI | ||
A3 | černobíle: 1.000, barevně: 500 | |
A2 | černobíle: 900, barevně: 450 | |
Výstupní formáty | JPG, JPG2000, TIFF, TIFF G4 | |
Rozměry | d/š/v 3,1 x 1,5 x 2,2 m | |
69 | ||
Hmotnost | 1200 kg | |
Napájení | 3x400VAC, 50 Hz, 4 zásuvky | |
Příkon celkem | 7.800W | |
Tepelný výkon (BTU) | 26.614,80 | |
Příslušenství | SW – řídící systém skeneru, Page Improver | |
4 PC v 19“ rack skříni | ||
dotykový LCD display a TFT 24“ monitor + klávesnice + myš | ||
Provozní spolehlivost | a) Odhadovaná spolehlivost klíčových komponent: 1,5 milionů | |
provozních cyklů | ||
b) Povaha výměny: pravidelná plánovaná/roční revize | ||
c) Průběžná údržba: prizma – čištění stlačeným vzduchem | ||
Standardy | 72/23/CEE Low Voltage: | |
EN60204-1 | ||
89/336/CEE Electromagnetic Compatibility: | ||
EN 00000-0-0 | ||
EN 00000-0-0 | ||
98/37/CEE Machinery: | ||
EN 292-1 | ||
EN 292-2 | ||
EN 294 | ||
EN 418 | ||
Rozměry transportního | d/š/v 3,5 x 1,7 x 1,5 | |
balení | ||
Manupilace a usazení | a) Manipulace s transportním balením pouze za použití vidlicového | |
vozíku za podmínky mžnosti přistavené nákladního vozidla | ||
b) Stabilní betonová podlaha | ||
c) Nutné vyvedení chlazení na fasádu | ||
Potřebný pracovní | d/š/v 4,0 x 2,5 x 2,6 m | |
prostor |
Popis vkládání předloh a jejich skenování a vyjímání je převzat z uživatelské dokumentace. V souladu s požadavkem Zadávací dokumentace budou uživatelská menu lokalizovaná do češtiny.
1.4.4.1.2 Vkládání knih /Position Book and Apply Vacuum/
Obrázek 23 – Menu pro vkládání knih
Správné umístění knihy na Vakuové tabuli zajistí optimální otáčení stran, jako i kvalitu umístění z uměleckého hlediska pro dělání digitálních snímků.
Následujte instrukce na obrazovce a následující rady:
Při vkládání knihy nezapomeňte zkontrolovat, zda jsou všechny díry OBOU VAKUOVÝCH TABULÍ PŘEKRYTÉ OBALEM KNIHY. Prosím podívejte se na obrazovku "Load Book - Automatic Measuring" pro správnou volbu nasávacích masek.
Vložte knihu na pravou tabuli se záhybem mimo tabule.
Pokud je to možné, nakloňte vázání tažením předního obalu k levé tabuli tak, aby se záhyb dotýkal okraje levé tabule.
Pokud je potřeba, použijte Brzdu lůžka, abyste uzamkli polohu tabulí při vkládání těžké knihy.
Otevřete knihu na straně s významnými informacemi, aby bylo brzy možné nastavit skener na této straně.
Ujistěte se, že kniha je horizontálně a vertikálně dobře zarovnaná, abyste se vyhnuli pokřiveným snímkům.
Pokud je potřeba, použijte Xxxxx na knihy, aby držel knihu rovně. Dávejte pozor na polohu a stabilitu Držáku na knize: pozorně následujte instrukce poskytnuté během školení operátora na tuto otázku.
DŮLEŽITÉ:
NIKDY NEPOUŽÍVEJTE DRŽÁK NA KNIHY JINÝM ZPŮSOBEM, NEŽ JAKÝ BYL PŘEDVEDENÝ BĚHEM ŠKOLENÍ.
PO POUŽITÍ JEJ VŽDY VRAŤTE NA MÍSTO JEHO ULOŽENÍ.
Když je kniha správně vložená, stiskněte “Done”.
Odstranit Držák na knihy /Remove Book Maintainer/
Obrázek 24 – Menu fixace předlohy
Pokud jste na vložení knihy použili Držák, teď ho odstraňte.
Všeobecné tipy pro vkládání knih
Při vkládání knihy pomůže otočení vázání doleva automatickému otáčení vázání.
1. Vložení knihy s dostatečnou štěrbinou okolo hřbetu knihy pomáhá u velkých knih s tvrdým vázáním.
Obrázek 25 – Velká štěrbina
2. Vložení hřbetu knihy přímo na lůžko může pomoct při otáčení vázání u hrubých knih.
Obrázek 26 – Úzká štěrbina
1.4.4.1.3 Načítání okrajů /Border of first page/
(Okraj první strany)
(POTVRĎTE, ŽE TOTO JE OKRAJ PRVNÍ
STRANY)
Obrázek 27 – Obrazovka potvrzení okraje strany
Tato obrazovka se zobrazí pro potvrzení automatického načítání okraje strany. Najděte na stránce pod Senzorem červený bod. Měl by být na kraji pravé strany.
Obrázek 28 - Obrazovka “Indicate Border of Page” (Indikujte okraj strany)
Tato obrazovka se objeví, pokud jste v předchozí obrazovce “Border of first page” (Okraj první strany) odpověděli “NO”, nebo pokud jste zadali “Gap to not press book” 0 v obrazovce “Advanced Settings”.
Mezi kroky je určité zpoždění. Držte tlačítka a pusťte je ve správnou chvíli. Je zbytečné je stisknout rychle za sebou.
Pohyby nosníku jsou omezené vpravo a vlevo maximální a minimální šířkou knihy, jakou DL dokáže zpracovat.
1.4.4.1.4 Stav zpracovávání /Processing Status/
Obrázek 29 - Stav zpracovávání
Tato obrazovka se objeví, pokud DL automaticky otáčí strany a uživatel zvolí “More ”.
Zobrazuje stav V REÁLNÉM ČASE:
Počet stran, které byly otočené. Pokud operátor zadal počet stran na digitalizování, zobrazuje se celkový počet stran na digitalizování a procento hotové práce. Pokud operátor zvolil 9999, DL neví, kde je konec knihy, a kolik stran musí být digitalizovaných.
Některé rozšířené nastavení jako "Gap for turning" a "Border Aspiration" může DL upravit automaticky, aby se zajistilo lepší zpracování.
“0 sheet” indikuje, kolik bylo vykonáno takových opakovaných pokusů, při kterých nebyla uchycena žádná strana.
“2 sheets” indikuje, kolik bylo vykonáno takových opakovaných pokusů, při kterých byly uchyceny 2 nebo více stran.
Poznámky: - Celkový počet opakovaných pokusů je součet 2 čísel popsaných výše.
- 2 slepené strany mohou pro oddělení vyžadovat několik opakovaných pokusů. “Stop” můžete stisknout kdykoli, pokud chcete upravit nastavení a/anebo přerušit proces.
1.4.4.1.5 Zastavení procesu /End of Process – Confirmation/
(Potvrzení ukončení procesu)
Obrázek 30 - Zastavení procesu
Tato obrazovka se objeví po stisknutí tlačítka “Stop” na obrazovce “Processing Status” popsané výše, anebo po tom, co DL automaticky načetla konec knihy, anebo když se DL nepodařilo uchytit strany po všech opakovaných pokusech.
Stisknutí tlačítka “End of Book” ukončí proces a vyžádá odstranění knihy.
Po stisknutí tlačítka “Continue To Turn Pages” bude činnost jednoduše pokračovat. Stisknutí tlačítka “Open for Manual Intervention” umožní manuální zásah.
Stisknutí tlačítka “Adjust Machine Settings” operátorovi umožní upravit všechna nastavení zpracovávání a spustí skenování od začátku.
Stisknutí tlačítka "Adjust Cameras" umožní upravit nastavení kamer.
1.4.4.1.6 Vyjmutí knihy /End of Process – Open/
(Konec procesu – Otevřít)
Obrázek 31 - Vyjmutí knihy
Tato obrazovka otevře DL po stisknutí tlačítka “End of Book” na obrazovce “End of Process - Confirmation” popsané výše.
Stisknutí tlačítka „Partial Open“ bude možné použít držák. Stisknutí tlačítka „Complete Open“ otevře DL pro vyjmutí knihy.
Tato obrazovka slouží k uvolnění a vyjmutí knihy na konci procesu.
Po stisknutí tlačítka “Done” se zobrazí obrazovka “Settings change Savings”, pokud bylo změněné nastavení zpracovávání.
1.4.4.2 Středoformátový robotický skener
Požadavek | Robotický skener umožňující skenovat předlohy do formátu A2 |
(otevřená A3) | |
- musí umožnit skenování předloh do formátu předlohy A2 | |
(otevřená A3) | |
- musí být vybaven šetrným mechanismem uchycení | |
snímané předlohy, v ideálním případě ve formě vyvažující | |
se podložky | |
- schopen snímat předlohy v rozlišení minimálně 300 DPI | |
(optimálně 400 DPI) | |
Počet a umístění | 1 x NK ČR |
1.4.4.2.1 Navrhované řešení
Knižní skener 4 digitalBooks DL mini-i
Digitalizační linka je menší provedení automatického knižního skeneru. Je to kompletní digitalizační systém, sestávající z automatického obraceče stránek, propojeného s kamerou knižního skeneru. Model DL mini-i používá kameru i2S s vysokým rozlišením - snímací prvek CopiBook HD 600. Předloha je fixována podtlakem, otáčení stránek provádí podtlaková ruka. Obrací stránky a skenuje jejich obsah automaticky bez asistence obsluhy. Vždy se obrátí pouze jedna strana. To je kontrolováno zaručeným systémem detekce papíru. Žádná stránka se nevynechá ani nebude naskenována dvakrát. Systém obrací vždy pouze jednu stránku zprava doleva. Předpokládané použití pro současné a staré tisky. Popis manipulace s předlohou a skenování je stejný jako v případě DL 3003.
Obrázek 32 - Knižní skener 4 digitalBooks DL mini-i | |
Formát stránky | minimálně A6 (105 x 148 mm), maximálně A3 (297 x 420 mm) |
velikost snímané plochy max. 600 x 420 mm | |
Vlastnosti předlohy | tloušťka knihy až 10 cm |
maximální hmotnost knihy 10 kg | |
2 2 tloušťka papíru od 20 g/m do 200 g/m | |
maximální zvlnění předlohy 20 mm | |
Rozlišení | minimálně 300 DPI a maximálně 600 DPI |
Rychlost skenování | automatický režim více než 1500 stránek za hodinu |
Výstupní formáty | JPG, JPG2000, TIFF, TIFF G4 |
Rozměry | d/š/v/ 1,8 x 0,8 x 1,3 umístitelný na stůl |
Hmotnost | 175 kg |
Napájení | 120 - 240V, 50 - 60 Hz, 4 zásuvky |
Příkon | 3.700W |
78 |
Tepelný výkon (BTU) | 12.625 | |
Příslušenství | SW – řídící systém skeneru | |
PC sestava s OS TFT display, klávesnice + myš | ||
Provozní spolehlivost | a) Odhadovaná spolehlivost klíčových komponent: 1,5 milionů | |
provozních cyklů | ||
b) Povaha výměny: pravidelná plánovaná/roční revize | ||
Průběžná údržba: prizma – čištění stlačeným vzduchem | ||
Rozměry transportního | d/š/v 2,1 x 1,2x 1,4 | |
balení | Hmotnost: 450 kg | |
Umístění | Předpokládáno umístění na pracovním stole | |
Potřebný pracovní | minimálně 2 m2 pro obsluhu mimo zařízení a komunikace dle Nařízení | |
prostor | vlády č. 361/2007 Sb. § 47 a 48. |
1.4.4.2.2 Robotický skener pro skenování poškozených a degradovaných předloh
Požadavek | Robotický skener podporující techniku klínového skenování | |
- | Klínové skenování s maximálně šetrným mechanismem | |
obracení stránek (bez použití mechanickým součástek) | ||
předloh otevřeného v úhlu okolo 60°. | ||
- musí používat metodu klínového skenování | ||
- | musí obsahovat pohyblivou kolébku s nastavitelným | |
úhlem otevření originální předlohy v rozsahu okolo 60° | ||
- musí být schopno snímat předlohy v rozlišení minimálně | ||
300 DPI (optimálně 400 DPI) | ||
Počet a umístění | 1 x NK ČR | |
1 x MZK
1.4.4.2.3 Navrhované řešení
Knižní skener TREVENTUS ScanROBOT 2.0 MDS
Zařízení umožňuje kromě skenování v automatickém režimu také skenování v poloautomatickém a manuálním režimu. Otáčení stránek je automatické s kontrolou (např. otočení dvou stran), poloautomatické nebo manuální. Úhel otevření je plynule nastavitelný mezi 60° a 100°. Osvětlení zajišťuje LED bez zahřívání, infračervené nebo UV záření.
Obrázek 33 - Knižní skener TREVENTUS ScanROBOT 2.0 MDS | |||||||
Formát stránky | minimum 50 x 80 mm | ||||||
maximum 290 x 320 mm | |||||||
Vlastnosti předlohy | tloušťka knihy: až 14 cm | ||||||
tloušťka papíru: od 40 g/m2 do 260 g/m2 | |||||||
kvalita papíru: všechny stránky - i poničené kyselinou nebo zvlněné | |||||||
obálky: všechny - měkké i tvrdé | |||||||
stáří knihy - od 14. století po současnost | |||||||
Rozlišení | a) | konstantní | a | nezávislé | na | formátu | stránky |
300 DPI standardně, | |||||||
b) | 400 DPI volitelně barevná | ||||||
c) | hloubka: 30 bit | ||||||
d) | typy skenů: barevné, ve stupních šedi, černobílé | ||||||
Rychlost skenování | a) | automatický režim - až 2500 stran za hodinu | |||||
b) | poloautomatický režim - až 1000 stran za hodinu | ||||||
c) | jednotlivé skeny při manuálním režimu - až 350 stran za hodinu | ||||||
Výstupní formáty | JPG, JPG2000, TIFF, TIFF G4, PNG, gif, bmp, pdf (včetně vrstvy OCR), XML, | ||||||
DjVu | |||||||
Rozměry | v/š/h 1,90 x 0,78 x 0,78 m (bez monitoru) | ||||||
Hmotnost | 260 kg | ||||||
Příkon | 1.600W | ||||||
Napájení | 120 - 240V, 50 - 60 Hz, 4 zásuvky | ||||||
Tepelný výkon (BTU) | 5.459 | ||||||
Příslušenství | a) | plochý skener A3 | |||||
b) | Control,. Computer system | ||||||
c) | hi-end pracovní stanice | ||||||
d) | 22“ EIZO širokoúhlý display (barevně kalibrovatelný) | ||||||
80 | |||||||
e) integrovaný držák pro monitor, klávesnici, a myš
f) SW ScanGate – postprocessing, OCR
g) SW ScanFlow
Provozní spolehlivost | a) Odhadovaná spolehlivost klíčových komponent: minimálně 1 milion |
provozních cyklů | |
b) Povaha výměny: pravidelná plánovaná/roční revize | |
Průběžná údržba: prizma – čištění stlačeným vzduchem | |
Standardy a direktiva | Machinery Directive 2006/42/EC: |
DIN EN ISO 12100-1, Safety of machinery | |
DIN EN ISO 12100-2, Safety of machinery | |
DIN EN ISO 14121-1, Safety of machinery - Risk assessment | |
DIN EN ISO 13849-1, Safety of machinery - Safety-related parts of control | |
systems | |
DIN EN ISO 13850, Safety of machinery - Emergency stop | |
DIN EN 60204-1, Safety of machinery - Electrical equipment of machines | |
DIN EN ISO 11688-1, Acoustics - Recommended practice for the design of | |
low-noise machinery | |
DIN EN 62079, Preparation of Instructions | |
EMC Directive 89/336/EEC with amending directives 92/31/EEC & | |
93/68/EEC: | |
DIN EN 55022, Information technology equipment - Radio disturbance | |
characteristics (Class B) | |
DIN EN 55024, Information technology equipment - Immunity | |
characteristics | |
DIN EN 00000-0-0, Electromagnetic compatibility (EMC) | |
DIN EN 00000-0-0, Electromagnetic compatibility (EMC) | |
EC Low Voltage Directive 73/23/EEC: | |
DIN EN 60960 Information technology equipment - Safety | |
Rozměry transportního | Výrobce neuvádí |
balení | |
Manipulace a usazení | Manipulace s celým zařízením – vybaveno kolečky |
Potřebný pracovní | minimálně 2 m2 pro obsluhu mimo zařízení a komunikace dle Nařízení |
prostor | vlády |
č. 361/2007 Sb. § 47 a 48. |
Popis vkládání předloh a jejich skenování a vyjímání je převzat z uživatelské dokumentace. V souladu s požadavkem Zadávací dokumentace budou uživatelská menu lokalizovaná do češtiny.
Vložení knihy do skeneru ScanRobot
Vložte knihu až po zadní zarážku, nebo ji vyrovnejte se zadní hranou kolébky. Žádná část knihy by neměla vyčnívat za zadní hranu – rozsah pohybu oddělovacích trysek a senzoru pro detekci otáčení jednotlivých stran sahá právě sem (viz Obrázek 34 – Fixace předlohy).
Obrázek 34 – Fixace předlohy
Uzpůsobte šířku kolébky (Obrázek 35 – Kolébka s malým úhlem rozevření, SCR85 a SCR86)
Zafixujte knihu v pozici pomocí upevňovacích lišt (Obrázek 35 – Kolébka s malým úhlem rozevření, SCR63) nebo ploch (pro knihy s tenkou či papírovou vazbou)
82
Obrázek 35 – Kolébka s malým úhlem rozevření
Otevřete knihu přibližně ve třetině a uzpůsobte kolébku tak, aby laserový paprsek (Obrázek 35
– Xxxxxxx s malým úhlem rozevření, SCR84) mířil přímo na vazbu knihy
Posuňte skenovací hlavici pomocí tlačítka „dolů“ k vazbě knihy. Zkontrolujte, jak daleko se může hlavice pohybovat směrem k vazbě, a zkontrolujte úhel otevření kolébky (Obrázek 35 – Kolébka s malým úhlem rozevření, SCR83). (Obrázek 36 – Přiblížení snímací hlavy předloze – skenovací hlavice se posouvá do knihy)
Je-li to zapotřebí:
nastavte úhel kolébky širší nebo užší dle potřeby tak, aby skenovací hlavice měla dostatek prostoru k pohybu až k vazbě,
změňte úhel otevření kolébky – skleněné hranoly musí spočinout na stránkách knihy. Ve výšce oddělujících trysek (horní bod) by měla být mezera přibližně 2-5 mm (viz Obrázek 35
– Kolébka s malým úhlem rozevření),
v případě nutnosti změňte váhu skenovací hlavice (v profilu zařízení).
Posuňte skenovací hlavici lehce nahoru a pro opětovnou kontrolu posuňte zpět dolů. Je-li to nutné, proveďte další úpravy uložení knihy.
Obrázek 36 – Přiblížení snímací hlavy předloze
Obrázek 37 – Správné přiblížení snímací hlavy
1.4.4.3 Robotický skener pro skenování novodobých předloh
Požadavek | Robotický skener využívající pro uchopení předlohy pohyblivé | |
kolébky s variabilně nastavitelným úhlem otevření | ||
- | musí zabezpečit šetrné uchycení předlohy s využitím | |
pohyblivé kolébky s volně nastavitelným úhlem otevření | ||
- mechanické součástky nápomocné při otáčení stran jsou | ||
povoleny | ||
- předložené řešení musí být ověřeno při zpracovávání | ||
moderních typů předloh | ||
- | musí umožnit skenování předloh do formátu A3 | |
(otevřená A4) | ||
84 | ||
- musí být schopno snímat předlohy v rozlišení minimálně | ||
300 DPI (optimálně 400 DPI) | ||
Počet a umístění | 1 x NK ČR | |
1 x MZK |
1.4.4.3.1 Navrhované řešení
Knižní skener TREVENTUS ScanROBOT 2.0 MDS
Pro naplnění tohoto požadavku jsme se rozhodli použít stejné zařízení jako v případě předchozího požadavku z těchto důvodů:
a) Původně uvažované zařízení Kirtas Kabis III není schopno pracovat s předlohami formátu A3, ale pouze s formátem A3-. Při použití tohoto skeneru by Logica nesplnila požadavek uvedený v Zadávací dokumentaci.
b) Původně uvažované zařízení Kirtas Kabis III není schopno dosáhnout rozlišení 400 DPI, které je považováno za optimální bez interpolace. Při použití tohoto skeneru by Logica nesplnila požadavek uvedený v Zadávací dokumentaci.
1.4.4.4 Manuální skener pro formát A 1
Požadavek | Manuální skener s variabilně nastavitelnou kolébkou pro |
skenování předloh s poškozenou vazbou umožňující naskenovat | |
obálky i desky | |
- musí disponovat variabilně nastavitelnou kolébkou pro | |
skenování buďto ve formě V kolébky či pohyblivé plochy | |
- musí garantovat možnost naskenovat obálky, desky a | |
přílohy o jiném formátu než je originální předloha | |
- musí být schopno skenovat předloha do formátu | |
předlohu A2 (otevřená A1) | |
- musí být schopno snímat předlohy v rozlišení minimálně | |
300 DPI (optimálně 400 DPI) | |
Počet a umístění | 1 x NK ČR |
1.4.4.4.1 Navrhované řešení
Skener 4DigitalBooks Scan2page
Scan2page je samostatná poloautomatická skenovací jednotka, která akceptuje veškeré formáty stránek od nejmenších po A2++. Umožňuje skenování jakýchkoli vázaných předloh, volných listů, záložek a vsunutých listů. Pracovní cyklus je ovládán nožním pedálem. Umístění knihy – manuální zarovnání horizontálně, motoricky vertikálně.
Obrázek 38 - Skener 4DigitalBooks Scan2page | ||
Formát stránky | otevřená kniha maximálně 2 x A2 ( 880 x 600 mm ) | |
rozšířené maximum 2 x A2+ ( 1080 x 750 mm ) | ||
Vlastnosti předlohy | tloušťka knihy maximálně 300 mm | |
maximální hmotnost knihy 40 kg | ||
Rozlišení | 200/ 300/400/600 DPI | |
Rychlost skenování | až 1028 stránek za hodinu (záleží na rozlišení a velikosti skenované | |
předlohy) | ||
úhel otevření 180° | ||
Výstupní formáty | TIFF, JPEG | |
Rozměry | d/š/v 1640 x 900 x 850 mm + 19“ PC rack (800 x 600 x 1200 mm) | |
Hmotnost | 130 kg skener + 40 kg PC Rack | |
Napájení | 120 - 240V, 50 - 60 Hz, 4 zásuvky | |
Příkon | 1.500 W | |
Tepelný výkon (BTU) | 5.118 | |
Příslušenství | a) | SW – řídící systém skeneru |
b) | 19“ rack | |
c) PC pro rozhraní skeneru | ||
d) PC pro zpracování pořízených obrazů. | ||
e) 24“ TFT display, klávesnice, myš | ||
Provozní spolehlivost | a) Odhadovaná spolehlivost klíčových komponent: minimálně 1 | |
milion provozních cyklů | ||
b) Povaha výměny: pravidelná plánovaná/roční revize | ||
Průběžná údržba: prizma – čištění stlačeným vzduchem | ||
Rozměry transportního | 4 samostatná balení (bedny) | |
balení (m) | 1. Kolébka: d/š/v 1,9 x 1,1 x 0,85, hmotnost 275 kg | |
2. | Skener: d/š/v 1,9 x 1,1 x 0,85, hmotnost 250 kg | |
3. Paleta se sklem: d/š/v 1,27 x 0,77 x 1,06, hmotnost 88 kg | ||
86 | ||
4. Paleta pro rack: d/š/v 1,2 x 0,8 x 1,37, hmotnost 80 kg | ||
Manipulace a usazení | Výrobce neuvádí zvláštní požadavky | |
Potřebný pracovní | minimálně 2 m2 pro obsluhu mimo zařízení a komunikace dle Nařízení | |
prostor | vlády č. 361/2007 Sb. § 47 a 48. |
1.4.4.4.2 Obsluha skeneru
Popis vkládání předloh, jejich skenování a vyjímání ze skeneru: Vložení knihy:
Obrázek 39 – Scan2Page skenovací pracoviště
a) Kniha je do skeneru vkládána po sešlápnutí nožního pedálu, který umístní směrem dolů kolébku od přítlačného vyrovnávacího skla.
b) Kniha se opatrně vloží do kolébky, která se přizpůsobí vazbě. Přizpůsobení vazbě je znázorněno na obrázku.
Obrázek 40 – Vkládání předlohy do kolébky
Nastavení procesu snímaní na PC (nastavení hodnot skenování: DPI, hloubka barev, režim čb/šedivě/barevně)
Opětovným sešlápnutím pedálu se kolébka zdvihne do pracovní polohy pro snímání.
Obrázek 41 – Fixovaná předloha
a) Při snímání dalších stran se postup opakuje, při snímání knihy se vždy snímají obě strany najednou. Jsou-li skenované strany zobrazeny korektně, obsluha sešlápne pedál, kolébka sjede do spodní pozice a obsluha otočí další strany
Obrázek 42 – Otáčení listů předlohy
b) Obsluha pracuje v pohodlné a ergonomické poloze.
88
Obrázek 43 – Pracovní pozice obsluhy
Po ukončení skenování je publikace uložena a opětovným sešlápnutím pedálu je kolébka umístněna v poloze, kdy lze knihu bez poškození opatrně vyjmout.
1.4.4.5 Manuální velkoformátový skener
Požadavek | manuální velkoformátový skener umožňující digitalizovat | ||||
specifické typy předloh (plakáty, mapy, grafiky, atd.) do formátu | |||||
A0+. | |||||
- musí disponovat variabilně nastavitelnou kolébkou pro | |||||
skenování buďto ve formě V kolébky či pohyblivé plochy | |||||
- | musí | umožňovat | skenování | velkoformátových | |
jednolistových předloh s využitím podtlakového stolu, | |||||
který musí být součástí dodávky | |||||
- musí být schopno skenovat předlohy do formátu A0 | |||||
- musí být schopno snímat předlohy v optickém rozlišení | |||||
alespoň 600 DPI při skenování formátu A0 | |||||
- musí podporovat kalibraci barev | |||||
- | počet | skenovaných | stran formátu | A0 v plné barvě | |
v maximálním optickém rozlišení (včetně všech úkonů | |||||
operátora včetně obracení stránek) nesmí klesnout pod | |||||
50 stran za hodinu | |||||
- počet skenovaných stran formátu A3 v plné barvě v rozlišení 300 DPI (včetně všech úkonů operátora včetně obracení stránek) nesmí klesnout pod 200 stran za hodinu
- musí být integrován do Workflow softwaru Počet a umístění 1 x MZK
1.4.4.5.1 Navrhované řešení
DigiBook SUPRASCAN A0+ (14000 RGB)
Manuální velkoformátový flexibilní skener s vysokou obrazovou kvalitou a produktivitou. Předloha je fixována vakuovým stolem nebo knižní kolébkou.
Obrázek 44 - DigiBook SUPRASCAN A0+ | ||
Formát stránky | maximální skenovací plocha skeneru 870 ( výška ) x 1250 ( šířka ) mm | |
do velikosti A0 / E | ||
Vlastnosti předlohy | Předlohy do formátu A0 | |
Rozlišení | formát DPI | |
A0 | 200 | |
A0 | 400 | |
2xA3 | 400 | |
2xA3 | 600 | |
2xA3 | 800 | |
Rychlost skenování | formát | 14000-RGB |
A0 | 31 sec | |
A0 | 62 sec | |
2xA3 | 32 sec | |
2xA3 | 47 sec | |
2xA3 | 63 sec | |
Výstupní formáty | JPEG s nastavitelnou mírou komprese | |
TIFF G4 pro binární obrazy | ||
LZW, PNG | ||
Rozměry | šířka 2 m x hloubka 1,5 m x výška 2 m | |
90 | ||
Hmotnost | 160 kg | |
Napájení | 120 - 240V, 50 - 60 Hz, 4 zásuvky | |
Příkon | 500 W | |
Tepelný výkon (BTU) | 1.706 |
Příslušenství | a) | Řídící systém skeneru, Ovladač TWAIN / API |
b) | vakuový stůl | |
c) | knižní kolébka | |
Provozní spolehlivost | a) | Odhadovaná spolehlivost klíčových komponent: min. 1,5 milionů |
provozních cyklů | ||
b) | Povaha výměny: pravidelná plánovaná/roční revize | |
Průběžná údržba - měsíční | ||
Rozměnry transportního | a) | Skener: d/š/v 2,15 x 1,32 x 95, hmotnost 250 kg |
balení (m) | b) | Kolébka: d/š/v 1,9 x 1,1 x 85, hmotnost 275 kg |
Potřebný pracovní | minimálně 2 m2 pro obsluhu mimo zařízení a komunikace dle Nařízení | |
prostor | vlády | |
č. 361/2007 Sb. § 47 a 48. | ||
Vložení knihy
Kniha musí být umístěna na digitalizačním panelu
Pokud je skener DigiBook vybaven kolébkou, musí operátor umístit předlohu na pravou plochu a otevřít ji tak, aby „levé“ strany byly položeny na levé ploše. Kniha pak musí být umístěna tak, aby byla perfektně vycentrována na podpoře, a plochy musí být uzamčeny v pozici (je-li to třeba, pomocí pedálu spojeného s kolébkou). K dispozici je několik modulů kolébek.
Obrázek 45 – Umístění předlohy do kolébky
Pokud kolébka nesedí přesně, operátor musí umístit předlohu na tabuli.
Obrázek 46 – Fixace předlohy
Adresář pro ukládání
Na začátku, po zvolení formátů, zvolte adresář pro ukládání naskenovaných obrazů. Můžete pro to využít menu „Files, Saving directory“.
Obrázek 47 Menu pro vytvoření adresáře
Formát skenu
Změřte výšku a šířku předlohy.
Klikněte na menu „Format“ a zadejte o trochu větší hodnoty, než jste změřili.
Obrázek 48 Menu volby výstupního formátu
Souborový formát
Zvolte formát souborů v okně „General configuration“.
Obrázek 49 – Volba výstupního formátu
Je-li třeba, povolte dvojí skenování – funkce „Check double scan“ v menu „Automate“.
Obrázek 50 – Volba kontroly proti opakovanému skenování
1.4.4.5.2 Scanning
Obrázek 51 – Spuštění skenování
„Digitizing“
Tento příkaz se používá pro digitalizaci jedné, nebo dvou stránek předlohy. Lze ho vyvolat pomocí klávesy „mezera“ a nožního přepínače. Kamera se posune nad rejstřík a real-time se zobrazuje skenovaný obraz na displeji. Kamera se vrací zpět do své výchozí pozice. Příkaz bude ignorován, pokud probíhá automatické ukládání.
Je-li povolena volba „Check double scan“, může vyvolat zobrázení následující zprávy: „You are starting a new digitization before the last image has been recorded … Do you wish to continue recording?“. Pokud si tuto zprávu nepřejte zobrazovat, jednoduše deaktivujte tuto volbu.
Poznámka: Ujistěte se, že se stránky předlohy během skenování nehýbají. Stiskněte „ESC“ pro přerušení skenu.
Někdy je výhodné otočit předlohu o 90 stupňů. Předloha je poté skenována odshora dolů. Výhody jsou následující:
Žádné odlesky v případě lesklého papíru Dobré osvětlení poblíž vazby
Žádné zakřivení textu
Obrázek 52 – Ukázka výsledků rotace po skenování
Pro otočení zvolte „90“ v orientaci formátu bez záměny výšky a šířky.
1.4.4.5.3 Záznam
Uložení
Tento příkaz se používá k uložení posledního skenu na disk.
Lze ho vyvolat rovněž klávesou „0“ na numerické klávesnici. Stisknutím klávesy „1“, resp. „2“ se pak uloží pouze levá, resp. pravá strana předlohy.
Pokud se uživatel pokusí uložit stranu, která již byla uložena, zobrazí se hlášení „Scan before saving“. Pro umožnění vícenásobného uložení bez opětovného skenu použijte menu „File, Options, Mulitple backup“.
Při ukládání se objeví modré hlášení „Saving in progress“. Po dokončení ukládání se zobrazí zpráva
„Image saved“, která nahradí zprávu předešlou.
Je-li povolena volba „Automate, Automatic save“, bude ukládání probíhat automaticky po dokončení skenu.
Menu „Save as“ (klávesa „3“ na numerické klávesnici) umožňuje zvolení cesty a jména souboru před uložením.
1.4.4.6 Automatický předlohový skener
Požadavek | automatický předlohový skener pro jednotlivé listy do formátu |
A3, umožňující oboustranné skenování rychlostí minimálně | |
100 str. za minutu | |
- schopen skenovat do formátu předlohy A3 | |
- umožní oboustranné skenování při rychlosti nejméně 100 | |
stran za minutu | |
- schopen trvalého výkonu 5000 stran za hodinu | |
95 |
- funkce kontrolního počítání počtu stránek skenovaných | ||
předloh | ||
Počet a umístění | 1 x NK ČR | |
1 x MZK | ||
1.4.4.6.1 Navrhované řešení
Canon DRX10C IMAGEFORMULA
Stolní A3 skener s automatickým podáváním.
Obrázek 53 - Canon DRX10C IMAGEFORMULA | |
Formát stránky | šířka stránky: 50,8 – 305 mm |
délka stránky: 70 – 432 mm | |
Vlastnosti předlohy | tloušťka stránky: |
a) Automatické podávání: 52 - 123 g/m² (0,06 - 0,15 mm) | |
b) Režim Bypass: 40 - 255 g/m² (0,05 - 0,30 mm) | |
c) Možnost využití režimu dlouhé stránky 1 000 mm max. - lze | |
nastavit na ovládacím panelu. (Tloušťka méně než 0,2 mm | |
a obrazová data méně než 348 MB) | |
Rozlišení | optické rozlišení 600 DPI CMOS/CIS snímač |
100 × 100 DPI, 150 × 150 DPI, 200 × 200 DPI, 240 × 240 DPI, | |
300 × 300 DPI, 400 × 400 DPI, 600 × 600 DPI | |
Rychlost skenování | Na výšku (A4): |
Jednostranně: | |
Černobíle/stupně šedi: 200/300 DPI 100 str./min.; | |
Barevně: 200 DPI 100 str./min.; | |
Barevně: 300 DPI 100 str./min. | |
Oboustranně: | |
Černobíle/stupně šedi: 200/300 DPI 200 str./min.; | |
Barevně: 200 DPI 200 obr./min.; | |
Barevně: 300 DPI 170 obr./min. | |
96 |
Na šířku (A4) | |
Jednostranně: | |
Černobíle/stupně šedi: 200/300 DPI 128 str./min.; | |
Barevně: 200 DPI 128 str./min.; | |
Barevně: 300 DPI 128 str./min. | |
Oboustranně: | |
Černobíle/stupně šedi: 200/300 DPI 256 obr./min.; | |
Barevně: 200 DPI 256 obr./min.; | |
Barevně: 300 DPI 170 obr./min. | |
Výstupní formáty | TIFF, JPG, BMP, PDF |
Rozměry | Zavřená přihrádka: 528 mm (Š) x 563 mm (H) x 375 mm (V) |
Otevřená přihrádka: 528 mm (Š) x 861 mm (H) x 432 mm (V) | |
Hmotnost | 40 kg |
Napájení | 120 - 240V, 50 - 60 Hz, 4 zásuvky |
Příkon | 125 W |
Tepelný výkon (BTU) | 427 |
Příslušenství | SW: Capture Perfect 3.0 |
Ovladače: | |
Ovladače ISIS/TWAIN Windows 2000 Professional SP4-Windows XP | |
Home Edition SP2/SP3 | |
Windows XP Professional Edition SP2/SP3-Windows XP | |
Professional (64bit) | |
Windows Vista SP1-Windows Vista (64bit)-Windows 7 | |
(32bit/64bit) | |
HW: PC HP Compaq 8200 Elite Series | |
Provozní spolehlivost | Výrobce neuvádí spolehlivost podle celků |
Rozměry transportního d/š/v 74X60X70, hmotnost 54 kg | |
balení | |
Manipulace a usazení | Ruční manipulace, umístění na pracovním stole |
Potřebný pracovní | minimálně 2 m2 pro obsluhu mimo zařízení a komunikace dle |
prostor | Nařízení vlády č. 361/2007 Sb. § 47 a 48. |
1.4.4.6.2 Manuální plochý skener
Požadavek | manuální plochý skener do formátu A3 jako pomocný |
k robotickým skenerům pro skenování obálek knih a jiných | |
neobvyklých součástí | |
- schopen naskenovat obálky knih, desky a jiné | |
nestandardní součásti | |
- schopen skenovat do formátu A3 | |
97 |