Fotodokumentace z instalace v Magna Liberec

72 kusů průtokoměrů PU1-CA1 3/8" a 1"

TECHNICKÁ SPECIFIKACE

1.   Struktura a obsah nabídky

• Nabídky musejí být vždy vypracovány kompletně podle znění specifikace.
• Nabídková cena bude strukturovánatakto(vytvoření systémové architektury je z technických důvodů rozděleno na dvě etapy):
• Vytvoření systémové technologické architektury
• Digitalizace lakovny L4
• Monitoring spotřeb elektrických energií a stlačeného vzduchu
• Jednotlivé činnosti nemohou být nabízeny zvlášť, nabídka musí zahrnovat veškeré výše uvedené aktivity v plném rozsahu.
• Vzhledem k omezeným možnostem stávajícího HW nebude v první etapě projektu systémové technologické sítě kladen důraz na vysokou dostupnost. Tedy například nebude nutné realizovat testovací/vývojové prostředí a podobně. Rozdělení ceny v rámci etap musí být přímo úměrné objemu projektu.
• Vzhledem k posloupnosti jednotlivých projektů musí být ceny za jednotlivé části zřetelně odděleny. Fakturace i realizace bude probíhat u všech tří částí zvlášť.
• Veškeré nabídky musí být pro srovnatelnost cenově a technicky přehledné a musí obsahovat popis předpokládaného řešení.
• Součástí nabídky musí být vyplněný check list, který je přílohou tohoto popisu předmětu zakázky. Dodavatel do každého řádku v příslušném sloupci vepíše formou ANO/NE, zda jím nabízená technologie daný požadavek splňuje. Nesplnění jakéhokoliv z požadavků bude mít za následek vyřazení nabídky z výběrového řízení. V případě, že je v požadavku zadavatele uvedena hodnota v určitém rozmezí nebo hodnota minimální či maximální, uvede dodavatel přesnou hodnotu nebo parametr.
• Nabídka musí obsahovat náklady spojené se servisními úkony:
• Hodinová sazba servisních techniků a montážníků
• Hodinová sazba programátorů
• Nocležné, sazba za kilometr jízdy, cena za čas strávený na cestě atp.
• Součástí nabídky musí být uvedena informace o místě výkonu práce servisních techniků, kteří jsou schopni reagovat na potřebné požadavky na místě v Magně v Liberci.

Ceny budou uvedeny v Eurech (EUR, €). Cena musí být rozpadnuta na:

• Software – licence
• Jednotlivé části specifikace + jejich etapy.
• Služby – zprovoznění, vývoj, instalace atp.

Odesláním cenové nabídky a zahájením činností akceptujete veškeré požadavky zadavatele, zejména, a ne výlučně jen:

• Technickou realizovatelnost a splnění kvalitativních požadavků.
• Požadavky na dodavatele služeb vykonávajících činnosti na území závodů a odloučených pracovišť Magna Exteriors (Bohemia) s.r.o. a Magna Exteriors (Nymburk) s.r.o. v 2018-01-01;
• Kodex profesionálního chování a etiky pro dodavatele uveřejněný na stránkách www.magna.com;
• Nákupní podmínky uveřejněné na stránkách www.magna.com;
• Požadavky uvedené v technické specifikaci poptávky a všech jejich přílohách.
• vybraný dodavatel před uzavřením smlouvy předloží platný doklad (certifikát) od pojišťovny prokazující pojištění pro případ poškození majetku minimálně 3 měsíce od požadovaného ukončení realizace zakázky, a to s pojistnou částkou ve výši minimálně 50 mil. Kč. Dodavatel služby zodpovídá a uhradí případné zaviněné škody na majetku zadavatele.

2.   Popis dodávky, objem zakázky

• Zakázka zahrnuje kompletní dodání řešení, včetně instalace, zprovoznění, proškolení personálu a předání.
• Dodavatel je odpovědný za kompletní návrh řešení včetně dimenzování a specifikace jednotlivých systémů tak, aby společně fungovali jako celek a plnily očekávání řešení.
• Tato specifikace je podkladem pro dodavatele k vypracování nabídky, popř. pro realizaci požadovaného řešení. Je základem obsahujícím minimální požadavky na funkci, výkony, životnost atd.

3.   Účel a funkce jednotlivých částí specifikace

3.1.   Vytvořené systémové technologické architektury

• Předmětem specifikace je vybudování IT/OTsystémové architektury technologické sítě ve výrobním závodě Magna Liberec. Jedná se systémovou část sběru dat a jeho vyhodnocení. Součástí dodávky není fyzické propojení strojů a zařízení. Síť (fyzické propojení zařízení pro umožnění komunikace) je v interní správě oddělení infrastruktury Magny a není předmětem této zakázky.
• Vybudováním systémové architektury je základním pilířem digitální transformace výrobního závodu Magna Liberec, díky které bude dosaženo poskytnutí robustního a funkčního nástroje pro řešení dílčích projektů.

Základní nástroje (systémové architektury) jsou:

• Sběr dat - data sbíráme bez ohledu na to, kdo je konzumuje.
• Všichni mají k dispozici stejná surová data z jednotlivých technologií.
• Všichni mají přístup k datům. Jediným omezením jsou citlivá data, která budouchráněna přístupovými právy pro jednotlivé uživatele.
• Odstranění papírových záznamů.
• Jednoduchá a rychlá tvorba reportů dle požadavků jednotlivých uživatelů.
• Vytvoření standardu pro komunikaci s nově připojených zařízení / projektů.
• Zvýšení úrovně kybernetické bezpečnosti.

3.2.   Digitalizace lakovny L4

• Předmětem digitalizace lakovny L4 je sběr a vizualizace dat z obou řídících systémů Lakovny L4 a to Eisenmann a B+M.
• Digitalizace lakovny slouží k online sledování výrobního toku dílů a jednotlivých technologických parametrů. Pomocí nástrojů systémové technologické architektury bude umožněno tvořit automatická upozornění na překročení jednotlivých výrobních parametrů.
• Bude zajištěna zpětná dohledatelnost výrobních dat k jednotlivým skidům / dílům.
• Automatické předávání informací o neshodných výrobních parametrech třetím systémům (Magna ESVD atp.)

3.3.   Monitoring spotřeb elektrických energií a stlačeného vzduchu

• Monitoring spotřeb elektrických energií a stlačeného vzduchu bude rovněž implementován do systémové technologické architektury a bude využívat jejich nástrojů dle specifikovaných požadavků.
• Předmětem této implementace bude vizualizace dat z nově osazených i stávajících ektroměrů a měřících zařízení stlačeného vzduchu na vstřikovně č.2 a výrobní hale č.125 primárně pro potřeby oddělení energetiky, tedy sledování aktuálních spotřeb s možností škálovatelnosti v čase.
• Rozpočítávání nákladů na jednotlivá hospodářská střediska.
• Zavádění nápravných opatření z pohledu udržitelnost.
• Sledování uhlíkové stopy výrobku
• V budoucnu budou sbíraná data využívána pro potřeby prediktivní údržby.

4.   Technický popis zařízení

4.1.   Vytvoření systémové technologické architektury

• Architektura technologické sítě se skládá z několika dílčích propojených celků.
• Architektura technologické sítě bude rozdělena na dvě základní etapy ze dvou hlavních důvodů:

1. Je nutné přesně vyspecifikovat nároky na výpočetní výkon systému včetně požadavků na uložiště, které musí být dimenzovány na 5let vzhledem ke kalkulované životnosti HW. Tento výpočet, respektive specifikace HW je předmětem dodávky této specifikace a bude realizován po reálném zprovoznění všech jednotlivých částí.
2. Během realizace může dojít ke strategickému rozhodnutí přesunutí celé architektury, nebo její části na cloudové uložiště. Výsledkem může být i do jisté míry hybridní řešení, kdy část dat bude zůstávat na on-premis řešení a pro využití výhod cloudových nástrojů budou specifikovaná data na cloudovém uložišti.

• Veškeré aplikace, nástroje a procesy tedy musí být nabízeny s ohledem na možnou migraci do cloudového prostoru. Výjimkou jsou systémy OPC serveru.
• Veškeré aplikace a navrhovaná řešení musí využívat standardních veřejně dostupných programů / řešení tak, aby bylo možné rozšiřování pomocí vlastních kapacit programátorů Magny případně dodavatelů třetích stran. Není možné nabídnout vlastní naprogramované řešení, které neumožňuje integraci dalších projektů a jejich případné úpravy a support třetí straně.
• V rámci 1. Etapy dojde ke kompletnímu zprovoznění systémové architektury a všech částí předmětu této specifikace na stávajících HW možnostech kancelářské sítě Magny.
• Vzhledem k omezeným možnostem výpočetního výkonu nebude v rámci první etapy kladen důraz na vysokou dostupnost aplikace. Tedy nemusí být realizováno například vývojové a testovací prostředí – pouze produkční.
• Po zprovoznění dojde ke zmíněnému výpočtu požadavku na výpočetní kapacitu a uložiště na následujících 5let. Na základě, kterého dojde ke strategickému rozhodnutí fyzického umístění aplikace -> On premise, cloud nebo hybridní řešení.
• V rámci 2. Etapy dojde k překlopení na nový HW/cloud + rozšíření pro dosažení všech požadavků předmětu této specifikace jako je vysoká dostupnost, bezpečnost apod.

Popis jednotlivých nástrojů technologické architektury.

1. Fyzické propojení se stroji – Sběr dat

Technologická síť musí být připravena na komunikaci s výrobními stroji, IoT senzory, tiskárnami, čtečkami, řídícími systémy jednotlivých aplikací bez ohledu na jejich využití. Minimální požadované komunikační protokoly jsou:

Siemens, ABB, Fanuc, Engel, KraussMaffei. Allen Bradley, B&R, BeckhoffTwinCAT, Omron, Honeywell, Analog devices, Aromat Ethernet, Aromat Serial, IDEC Serial, InTouchClient, AutomationDirect, Comtrex, DDE Client,  OPC UA, OPC DA, Modbus, OPC AE, OPC HDA, MTConnect, REST, MQTT, ODBC, SattBus Ethernet a Serial, System monitor, WAGO Ethernet.

2. OPC Server

V rámci OPC serveru bude docházet ke sběru dat z výše popsaných technologických zařízení včetně jejich konverze na standardní komunikační protokol SparkplugB. S OPC serverem tedy musí být možné komunikovat jak s nativními protokoly jednotlivých zařízení, tak se standardními komunikačními protokoly viz bod č.1.

• OPC Server musí být připraven a dimenzován na výměnu tisíce tagů za vteřinu.

3. UNS/DATA OPS

Soubor komponent umožňující sběr dat online v reálném čase bez omezení.

Součástí UNS musí být MQTT Broker. Požadavky na MQTT Broker jsou:

• MQTT 5.0, Komunikace pomocí Sparkplug B
• Vysoká dostupnost – clustering, support, škálovatelnost,
• Výkonnost – zprocesování stovky tisíc/milionů zpráv za vteřinu
• MQTT Broker musí umožňovat přímé připojení do sw třetích stran

4. SCADA

Aplikace umožňující vizualizace a monitoring, řízení uživatelských přístupů, povolování jednotlivým aplikacím odběr / poskytování dat. Přístupná všem, přístup k datům dle levelů pravomocí. Okamžitě webově zobrazovat neomezenému počtu klientů v jejich počítačích, mobilních zařízeních nebo HMI panelech. Neomezeně škálovat. Snadno navrhovat průmyslové aplikace. Neomezený počet tagů.

Minimální požadavky na SCADA systém jsou:

• Komunikace s MQTT Brokerem, OPC UA, Siemens, Modbus Ethernet
• Vizualizace, HMI dashboardy – Umožní zobrazit/vytvořit jakékoliv informace, obrazovky, grafy, zmetkovitosti, online sledování.
• Mobilní Zařízení – Umožní mít k dispozici všechny informace obsažené ve SCADA systému v mobilním telefonu.
• Redundance a zabezpečení dat – Přístupy dle uživatelských přihlášení, spolehlivost systému díky možnosti redundance.
• Alarmy – Pomocí emailu, sms či hlasové zprávy informuje o jakémkoliv nastavené skutečnosti.
• Podpora integrace IIoT – Microsoft Azure, AWS IoT, Watson IoT
• Čtení i zápis dat – Nejen vizualizace dat, ale i ovládání zařízení – tedy obousměrný provoz z a do aplikace
• Přístup do aplikace není omezen počtem klientů – tedy cena za počet připojených uživatelů / udělených přístupů není závislá na počtu. Aplikace slouží pro vizualizaci dat všem pracovníků Magny.

5. Vizualizace

Vizualizace bude primárně sloužit pro předání již zpracovaných informací pro pracovníky či management o jednotlivých stavech procesů / výrobních parametrů atp.

Minimální požadavky na vizualizace jsou:

• Webově orientovaná vizualizace optimalizované i pro velké obrazovky
• Systém musí být navržen pro vizualizace na webovém prohlížeči Chrome.
• Pro přípravu takové vizualizace nebude nutné pokročilé programování čímž je zajištěno snadné a rychlé zpracování včetně dalšího rozvoje.

6. Orchestrace a historizace dat

Soubor SW komponent, které umožňují on-line data historizovat a dále je strukturovat pro použití v reportingu, vizualizacích, případně odesílat data přes definované interface do externích systémů. Řešení musí být koncipováno tak, aby v případě výpadku datového spojení nedošlo ke ztrátě dat

Minimální požadavky na systémy orchestrace a historizace dat jsou:

• Realtimová databáze pro sběr surových dat
• Datalake pro umožnění ukládání dat v přirozeném formátu ze zdrojových systémů
• Data warehouse pro ukládání strukturovaných dat
• Datové kostky pro koncové uživatele
• Orchestrace dat, alarmy a notifikace – Nástroj umožňující definici procesů zpracování dat, reakce na aktuální hodnoty, napojení na systémy alarmů a notifikací
• Výměna dat – Pro výměnu dat s externími systémy přes definovaná rozhraní - ERP, MES, Quality SW atp.

7. Reporting / Datová analytika / AI, ML

Soubor SW komponent, které umožňují nad posbíranými daty vytvářet reporty a vizualizace, analyzovat data.

Minimální požadavky pro reporting a datovou analýzu jsou:

• Reporting avizualizace – Sledování KPI, vývoje zmetkovitostí, spotřeb a podobných ukazatelů bez omezení.
• Datová analytika – pro hledání vzájemných závislostí.
• Systém musí být připraven na rozšiřování v podobě implementace umělé inteligence, machine learningu či nástrojů prediktivní údržby.
• Kompatibilita s Power BI

4.2.   Digitalizace lakovny L4

O řízení všech procesů v lakovně L4 a jejího Bypassu se starají systémy od společností B+M a Eisenmann. Společnost B+M má ve správě aplikační část lakovny s tím, že firma Eisenmann se stará o dopravníkovou část lakovny, řízení pohybu skidů atp. Součástí lakovny L4 je i její Bypass, na který se stahují veškeré požadavky digitalizace lakovny.Cílem projektu není zasahovat do řídících systémů B+M a Eisenmann.

Data budou k dispozici pro zpracování v následujících technologiích:

• B+M – Aplikační část lakovny PLC TwinCAT (uzavřený systém bez přístupu ke zdrojovému kódu) Požadovaná data a adresy budou dodána Magnou.
• Dopravníková technika Eisenmann – PLC S7 400 a B+M PLC Siemens S7 1500 – Magna má přístup ke zdrojovým kódům a zná umístění dat.

Magna poskytne pro realizaci zdrojové kódy PLC programů, které jsou k dispozici, včetně technika, který bude pomáhat s dohledáním jednotlivých adres.

Detailní popis Digitalizace lakovny L4

• Na základě dostupných dat bude připravena přehledná, jednotnou vizualizaci celého procesu lakovny tak, aby byla veškerá data k dispozici na jednom místě.
• Lakovna bude v rámci vizualizace rozdělena dle jednotlivých zón viz příloha.

V rámci těchto zón bude možné sledovat aktuální polohu skiduv zóně, Sledování času vstupu, výstupu a času setrvání v zóně.

• Záznam technologických parametrů (vlhkost, teploty atp.) bude přiřazen k danému skidu a bude jej možné dohledat i podle čísla výrobku.
• Pomocí nástrojů z vytvořené systémové sítě bude možné sledovat aktuální technologické parametry, nastavovat na ně automatické alarmy či notifikace na email, GSM apod. Nové alarmy a upozornění bude možné tvořit pomocí samostatné konfigurační matice dle libovolně navolené kombinace technikem.
• Systém musí sloužit k předcházením problémů z pohledu technologických parametrů, hledání souvislostí mezi těmito parametry a pro zpětné vyhodnocení/dohledání neshodného výrobku v případě interních či zákaznických reklamací.
• Aplikace musí umožňovat předávání informací systémům třetích stran. V tomto případě zejména k automatickému předávání systému ESVD tak, aby byl zajištěn přenos informací mezi nastavenými technologickými parametry a informování oddělení kvality v případě jejich překročení.
• Sběr dat, vizualizace a ukládání bude probíhat z 41 zón, které mohou obsahovat až 6 technologických parametrů.
• U jednotlivých parametrů musí být umožněno sledovat jejich nastavenou minimální a maximální hodnotu. V rámci překročení těchto hodnot bude umožněno tvořit patřičná upozornění, notifikace a alarmy dle definovaných eskalačních matic. Případně dle nastavených pravidel bude umožněno předávat informace o odchylkách do interního systému Magny (ESVD) tak, aby byli včas informovány i ostatní oddělení.
• Výměna dat do ESVD bude probíhat přes REST API
• Přenášené informace budou blíže specifikované v průběhu projektu, zpravidla se bude jednat o Datum a čas vzniku alarmu, číslo skidu, místo vzniku alarmu, uživatel systému a popis alarmového hlášení. REST API bude možné na jeden skid, během lakovacího kola zavolat vícekrát.
• Reporting na alarmy obecně včetně historických dat bude realizován přes Power BI.
• Součástí realizace bude vytvoření těchto reportu, které budou blíže specifikovány v průběhu projektu – TOP 10 alarmů, alarmy proložené v čase pro jednotlivé zóny, celkové trvání alarmů, průměrné trvání alarmů atp.

4.3.   Monitoring spotřeb el. energií a stlačeného vzduchu

• Třetí část předmětu této specifikace je zaměřena na vytvoření vizualizace a zprovoznění SCADA systému na reálném případě měření spotřeb el. energií a stlačeného vzduchu na hale č. 125 a vstřikovně č.2.
• Projekt monitoringu využije dostupných nástrojů z vytvořené architektury podnikové sítě.
• Vizualizace se bude týkat 193 elektroměrů a 72měřících zařízení stlačeného vzduchu.
• Zařízení bude možné do vizualizace později přidávat bez složitého programování.
• Musí být umožněno přepisování názvů jednotlivých zařízení.

Minimální požadavky na monitoring spotřeb energií

• V rámci monitoringu bude připravené intuitivní prostředí, v rámci kterého bude možné dohledat jak vizuálně, tak pod zadáním čísla elektroměru potřebné hodnoty.
• V rámci vizualizace bude obrazovka rozdělena na náhled výrobního závodu, následně na jednotlivé haly, jednotlivé stroje a rozvodny na halách a poté na jednotlivé měřící zařízení.
• V rámci vizualizace bude možné sledovat hodnoty dle vybraných pravidel v čase i mezi měřícími zařízeními. Respektive bude možné sledovat spotřebu energií na celé hale, pro jednotlivý vstřikolisů, nebo pro vytvořenou skupinu elektroměrů, a to dle zvoleného období.

Vizualizace dat z měřících zařízení bude možné zobrazit dle následujících pravidel:

• Online vizualizace stavu elektroměru (exaktní hodnota pro potřeby odpisů)
• Rozdělení spotřeby dle pracovních směn
• Hodinová spotřeba vybraných elektroměrů /měřících zařízení
• Měsíční spotřeba vybraných elektroměrů /měřících zařízení
• Denní spotřeba vybraných elektroměrů / měřících zařízení
• Součástí projektu bude vytvoření přehledných souhrnných tabulek ve vizualizačním prostředí pro hromadné zpracování spotřeb na vybraných elektroměrech/strojích/provozech dle aktuálních potřeb pracovníka energetiky.
• Reporty bude možné připravit pro management ve vizuální podobě + musí systém umožňovat export dat do excelu pro další zpracování.
• Hodnota ceny elektřiny pro tvoření reportů a přepočtů na cenu bude zadávána ručně
• Jednotlivé spotřeby bude možné následně rozpočítávat pro reporting na přidělená hospodářská střediska.
• Celková spotřeba výrobního závodu bude zadávána ručně. V rámci reportingu bude možné zadat poměr z celkově zadané spotřeby výrobního závodu.

Pro jednotlivé zařízení bude nutné zaznamenat následující hodnoty:

• Čas odečtu
• Typ měřícího zařízení, jeho ID, výrobce měřícího zařízení + název
• Stav měřícího zařízení
• Skutečný stav pro zajištění odečtů
• Monitoring spotřeb energií bude dále vizualizovat spotřebu / cenu energií na jednotlivé výrobky. K jednotlivým výrobkům budou přirazeny vždy všechny měřící zařízení, které pro daný proces zaznamenávají sčítání.
• Díky nástrojům systémové architektury bude umožněno data spárovat se systémem ESVD, kde je k daném stroji v čase zaznamenán stav, respektive produkce aktuálního výrobku.
• Z pohledu reportingu bude tedy možné vizualizovat cenu/spotřebu na jednotlivé výrobky
• Spotřeby energií při jednotlivých zarážkách v systému.
• Součástí integrace budou notifikace na komunikaci systému s měřícím zařízením. Respektive v případě, že data nebudou sbírána, nebo když měřící zařízení nebude komunikovat tak bude nutné zasílat technikům energetiky automatická upozornění pomocí GSM sítě, či emailem.

5.   Instalace a zprovoznění architektury

• Instalace jednotlivých prvků, propojení a otestování bude probíhat na stávajícím HW společnosti Magna.
• Systémová implementace musí být snadno přenositelná mezi HW.
• Instalace a zprovoznění systémové architektury a jejich dílčích částí může probíhat přes vzdálenou plochu.
• Aktuální HW možnosti společnosti Magna, které je nutné brát v potaz při návrhu realizace jsou:

Konfigurace pro OPC server:

OS Windows

CPU – 4jádra 2GHz

Pevný disk – SSD 100GB

Paměť RAM 16GB

Konfigurace serveru pro UNS:

OS Linux – CentOS/redHat

CPU – 12 jáder o 2GHz

Pevný disk SSD100GB

Paměť RAM – 16GB

Konfigurace serveru pro Scada systém:

OS Linux – CentOS/redHat

CPU 12 jáder 3GHz

Pevný disk SSD 100GB

Paměť RAM 64GB

Konfigurace serveru pro RealTime databáze:

OS Windows

CPU 4 Jádra 2GHz

HDD/SSD 1TB

RAM 16GB

Konfigurace serveru pro datové analytické kostky:

Windows OS server

CPU 6 jáder 3GHz

HDD 1TB

RAM 64GB

SW Microsoft SQL server 2019 standard – SQL + SSAS

6.   Komunikace v průběhu realizace zařízení

• V průběhu celé doby zakázky, musí být umožněno zadavateli nahlédnout do veškerých podkladů vztahujících se k předmětu zadání, a to z důvodů lepšího posouzení efektivity prací a pracovního postupu jako i skutečného stavu věci, dodržování termínů, tak případných slabých míst v interních procesech dodavatele.
• Firma Magna Exteriors (Bohemia) s.r.o. si vyhrazuje možnost v průběhu celého projektu kontrolovat stav rozpracovanosti zakázky v prostorách dodavatele.
• Firma Magna Exteriors (Bohemia) s.r.o. si v případě nedodržení písemně dohodnutých termínu, nebo potencionálního rizika z prodlení, vyhrazuje právo na zainteresování třetí strany, za účelem zajištění úspěšného a včasného dokončení projektu. Veškeré náklady třetí strany spojené s touto podporou budou napřímo fakturovány dodavateli předmětu této specifikace.

7.   Převzetí a instalace

• Požadavky na složení případných zařízení, připravenost ze strany zadavatele jako jsou např. napájení, datové přípojky atp. musí být dodavatelem předem písemně zaslány žadateli.
• Převzetí do zkušebního provozu proběhne po instalaci a zprovoznění v závodě objednávajícího, a je podmíněno předáním kompletní dokumentace k zařízení, zaškolením pracovníků.
• V případě splnění všech podmínek převzetí do zkušebního provozu dodavatel i zadávající podepíšou dokument „Převzetí zařízení do zkušebního provozu“.
• Uvolnění zařízení do sériového provozu je podmíněno splnění všech kvalitativních a technických požadavků zmíněných v tomto dokumentu + připomínek vedených v zápisech.
• Převzetí zakázky proběhne teprve tehdy, když veškeré odchylky, které byly dodavateli písemně sděleny nebo vedeny v zápisech byly odstraněny a bude dodána aktuální dokumentace.

8.   Školení

• Školení proběhne v jazyce uživatele (v češtině).
• Současně se zaškolením výrobce předá aktuální školící manuál pro obsluhu v jazyce uživatele.
• Zaškolení obsluhy předmětu této specifikace je nedílnou součástí pro splnění požadavků na převzetí zakázky.
• Počet termínů školení v návaznosti na rozsah zakázky (minimálně však 40 h pro skupinu účastníků), konkrétní datum a čas školení bude prezentováno zadavatelem v průběhu realizace projektu.
• Toto zaškolení, v závislosti na potřebném rozsahu, může být jednoduché zaškolení na místě instalace až po teoretické školení a briefing na místě v trvání několika dní v případě složitých systémů.
• Povinností dodavatele je nejen potřebný personál zaškolit, ale i ověřit jeho odbornou způsobilost po ukončení školení.
• Součástí školení bude praktický výcvik úkonů obsluhy, simulace a následná diagnostika poruch.

9.   Dokumentace

Součástí dokumentace je detailní technický popis zařízení. Dále:

• Technická data zařízení
• Podrobný manuál k obsluze.
• Podrobný manuál k obsluze jednotlivých komponent.
• Školící manuál pro obsluhu.
• Plán preventivní údržby. Plán strukturovat podle periody (cyklus, hodina, směna, den, týden, měsíc, půlrok, rok, popř. počet cyklů, nebo hodin).
• V souvislosti s vytvářením plánů údržby a inspekcí musí být poskytnuty informace v souladu s VDI 2890. Musí být rozdělena do tabulkové podoby podle následujícího schématu a musí obsahovat požadované informace:
• Popis součásti
• Počet komponent
• Aktivita, která se má provádět vč. Času
• Cyklus / Období
• Naměřené hodnoty, v případě potřeby s nominální nebo minimální a maximální hodnotou.
• Schémata propojení
• Řídící program se všemi plány a vytištěnými programy.
• Kompletní a aktuální verzi zálohy řídícího softwaru na datovém nosiči (kompatibilním se čtecím zařízením ve stroji).
• Popis procesu (blokové schéma).
• Veškerý potřebný SW, včetně potřebných licencí.

10.   Záruka

• Záruční doba počíná po finální akceptaci v závodě Magna Exteriors (Bohemia) s.r.o..
• Záruka se vztahuje na celý objem zakázky. Záruční doba činí 3 roky
• Záruční doba na nakupované díly činí dva roky.
• Sw bude nabízen s roční technickou podporou
• Výrobce provede bezplatně kontrolu zařízení před ukončením záruční doby zařízení a zjištěné poznatky a doporučení předá zadavateli.
• Plnění závazků výrobce po dodání, uvedených v odstavci „Záruka“ není podmíněno podepsáním servisní smlouvy mezi objednatelem a výrobcem zařízení a tyto požadavky jsou pro výrobce/dodavatele závazné.

11.   Platební podmínky

• Dodavatel je oprávněn vystavit fakturu ve výši 100% po finální akceptaci objednatelem se splatností faktury 60 dní net.
• Na faktuře musí být uvedeno číslo dotačního projektu CZ.31.2.0/0.0/0.0/22_014/0005788
• Uvolnění zařízení je podmíněno splněním všech kvalitativních a technických požadavků zmiňovaných v tomto dokumentu a v dohodnutém termínu (dle platného termínového plánu) pověřenými zástupci fy Magna Exteriors (Bohemia) s.r.o.

12.   Přílohy

Technický check list.