Израда софтверске апликације Електронски диспечерски дневник у РДЦ

TEHNIČKE SPECIFIKACIJE.pdf ТЕХНИЧКЕ СПЕЦИФИКАЦИЈЕ НАПОМЕНА: Понуђач подношењем понуде прихвата наведене техничке спецификације и обавезан је да у случају добијања уговора испуни све наведене захтеве како следи. Понуђач попуњава Табелу 4 из техничке спецификације и документ учитава уз електронску понуду. 1. Увод Предмет пројекта је креирање, имплементирање, тестирање и пружање техничке подршке (техничка подршка у гарантном року од најмање 12 месеци од момента ''go live'') апликације Диспечерски дневник РДЦ (у даљем тексту: ЕДД РДЦ) кроз интеграцију са платформом Integration Hub произвођача Synsoft имплементираног у ЕМС АД. Synsoft систем је специјализовани програмски пакет базиран на микросервисној архитектури, намењен електроенергетским системима, који се састоји од више модула (сервиса): User Manager, API Flux, Energy Flux, Schema Flux, Registry, Administration, Integration Hub . Кроз њих се обезбеђује покривање функционалних специфичности у процесу обраде података и супервизија електро -енергетских система из области преноса електричне енергије, посебно имајући у виду обраду података са SCADA система, сложене моделе стања различитих система, моделе системских процеса, као и отвореност интерфејса (REST API) према другим системима из области преноса електричне енергије. Integration Hub (communication interface) обезбеђује интеграцију (повезивање) са екстерним системима као што су: • SCADA • MMS • ЕДД НДЦ • ЕДОП • Радови (двосмерна веза) • Energy Flux • Scalar • POI – планирање искључења и одржавања • ЕПД ТС • САП Модул управљање временом • ... друге апликације (нпр. аутоматско преузимање временских услова и слично) Софтверска апликацијска Диспечерски дневник представља надоградњу модула Integration Hub (communication interface) Synsoft система базирану на web -у и служи диспечерским центрима ЕМС -а за управљање евидентирањем догађаја у електроенергетском и преносном систему. ЕДД РДЦ користе оператери диспечерских центара (у даљем тексту: диспечери), различити корисници апликације у складу с правима приступа. ЕДД РДЦ диспечерима у смени пружа могућност уноса података у реалном времену о разним догађајима као што су промене стања електроенергетског система, прекиди и кварови опреме, промена топологије мреже, проблематика расположивости генератора и остал их информација релевантних за рад преносног система у надлежности центра управљања који користи ЕДД РДЦ. ЕДД РДЦ би требао да осигура поуздано чување и заштиту информација о догађајима, као и да омогући брз и квалитетно организован приступ корисника апликације. Нова апликација се развија да би програмски пакет био опремљен најновијим и најсигурнијим алатима јер је стара апликација развијена у застарелим алатима. Тако би се повећала сигурност, брзина евидентирања и дистрибуирања информација о раду преносног система. Потребно је дефинисати инфраструктуру коју захтева апликација, како би по потреби обезбедила средства за набавку хардвера и пратећих лиценци. 2. Опште информације ЕДД РДЦ треба да омогући уношење и трајно складиштење оперативних и пословних података генерисаних из рада ел ектроенергетског система. Диспечерски дневник треба да приказује све евиденције и уносе које региструје диспечер током једне смене. С обзиром да ЕМС АД има пет РДЦ-ова потребно је да се ЕДД РДЦ инсталира у свих пет центара као јединствена апликација. Све евиденције треба водити тако да сваки запис у диспечерском дневнику треба да буде под једном шифром евиденције ( у даљем тексту: бројем налога). Приликом креира ња новог записа у ЕДД РДЦ потребно је генерисати јединствени број налога. Због тога је неопходно да се бројеви налога генеришу са предзнаком сваког РДЦ. За сваки РДЦ се аутоматски генерише предзнак: • 011 Београд; • 014 Ваљево; • 021 Нови Сад; • 030 Бор; • 037 Крушевац. Након горе дефинисаног броја, број налога треба да започиње бројем месеца у години, растућим троцифреним бројем почевши од 001 и треба да се ресетује почетком сваког новог месеца. (нпр: за РДЦ Београд: 011.11.226 последњи налог у месецу новембру, а 011.12.001 први налог за месец децембар). За НДЦ предлажем да остане без префикса. Свака смена тре ба да поседује своју јединствену шифру смене која се аутоматски додељује новој смени по завршетку примопредаје смене. Ове шифре је набоље организовати према датумима са додатком слова које означава ноћну или дневну смену (пример ноћне смене 17.02.2022: шиф ра смене 17022022Н). Приступ апликацији ЕДД РДЦ треба да буде омогућен корисни цима који приступају својим username/pasword, са посебно дефинисаним правима приступа. Администрацију корисничких налога потребно је имплементирати као посебан модул који није на мењен диспечерима већ корисницима са посебним дефинисаним админ/супервизор правима. 3. Архитектура и техничка спецификација 3.1. Функционална и техничка спецификација Диспечерски дневник РДЦ-а је потребно направити у складу са следећим принципима и захтевима: • Web апликација (MVC) • Микросервисна архитектура • Подржан истовремен рад више корисника (multi user mode) • Права приступа дефинисана RBAC (Role Based Access Control) • Приjaвa корисника коришћењем корисничког имена и лозинке • Безбедност података • Додавање нових функционалности (модуларност и скалабилност) • Конфигурабилност (флексибилан и ефикасан систем конфигурације у случају промене бизнис процеса) • Архивирање података • Генерисање предефинисаних извештаја у различитим форматма (pdf, word, excel) 3.2. Архитектура система Софтверско решење за Диспечерски дневник представља web апликацију за мануелни унос, претрагу и извештавање о догађајима у електроенергетском систему. Приликом уноса нових записа о догађајима неопходно је категорисати елементе ставки уноса у скл аду са постојећ ом класификацијом елемената електроенергетског система (усклађивање са ТИС базом података). Осим ручног уноса записа, web апликација треба да обезбеди и евидентирање догађаја из екстерних информационих система као што су SCADA, ЕДД НДЦ, ЕД ТС, „Радови“, SCALAR итд . Ручни унос података из других информационих система треба да буде подржан могућношћу оператора (диспечера) да изабере начин уноса као и могућношћу ручног едитовања унесених података без обзира из ког система се преузимају, а све у току једне смене. Апликација Диспечерски дневник РДЦ-а има могућност процесирања различитих типова догађаја који у базу апликације долазе посредством Integration Hub (communication interface) компоненте. Ова компонента обезбеђује интеграцију (повезивање) са екстерним системима као што су: • ТИС база података • SCADA (повлачење сигнала о проблемима, испадима и њихово повезивање са налозима) • ЕДД НДЦ (преузимања информација о искључењима неких елемената ЕЕС) • Апликација ’’Радови’’- (преузимање информације о захтевима и дозволама) • Energy Flux (слање обавештења - нотификације) путем мобилне апликације • SCALAR – временске прилике • POI • ЕПД Трафостаница ЕМС-а • САП Модул управљање временом • ... друге апликације (нпр, аутоматско преузимање временских услова, и слично) Изглед архитектуре система: 3.3. Интеграција података Integration Hub ( Flux Hub ) је софтверски производ који омогућава повезивање и интеграцију различитих апликација и информационих система у оквиру једне или више организација. Он омогућава брзо и лако повезивање различитих система који међусобно деле податке у микросервисној архитектури. Integration Hub подржава више приступа за интеграцију апликација. Различити приступи могу се поделити у четири основна типа интеграције: • Пренос датотека - свака апликација производи датотеке дељених података које други могу да конзумирају. Integration Hub обезбе ђује скуп основних операција за рад са датотекама, као и могућност парсирања, конверзије и програмске обраде стандардних формата (XLSC, XML, JSON) • Заједничка база података - апликације складиште податке које желе да деле у заједничку базу података. Уколико апликације користе различите инстанце (па чак и типове) база података, Integration Hub омогућава директно повезивање на базе и „пресипање“ података (ЕТL) из једног у други систем, имплементирају ћи могућност конекције постојећим стандардизованим протоколима (драјверима) (JDBC, ODBC). • Даљинско позивање процедура - апликација изложи неке од својих процедура тако да се могу позвати на даљину, а друге апликације их позивају да би покренуле размену података. За даљинско позивање могу се користити неки од стандардних протокола као сто је REST, SOA, JMS, SNMP. Integration Hub има могућност како излагања даљинских процедура (сервер) тако и позивања (клијент). • Размена порука - апликација се повеже на заједнички систем за размену порука (МОМ – message oriented midleware) и размењује податке помоћу порука. Овај метод се користи за асинхрону интеграцију слабо повезаних апликација (loosly coupled) у оквиру дистрибуираног система (микросервисна архитектура). Integration Hub имплементира свој message oriented midleware (MOM) али се мо же конектовати и на друге/екстерне МОМ системе који подржавају неки од стандардних протокола (ЈМS, STOMP, MQTT, REST ) Да би конекција ка разнородним софтверским комп онентама била могућа Integration Hub имплементира велики број стандарних протокола, управљања током података (динами чко рутирање) и обезбе ђује методе за обраду и трансформацију података (трансформација) током интеграције. Integration Hub омогућава дијаграм тока података (визу елизацију), мониторинг тока података у реалном времену кроз web интерфејс, као и могућност конфигурисања и динамичког покретања интеграционих рута кроз web интерфејс за администрацију. У новој апликацији ЕДД РДЦ је потребно омогућити коришћење података из периода од настанка претходне апликације ЕДД РДЦ. 4. ИТ инфраструктура и окружење 4.1. Софтверске лиценце Понуђач је дужан да у своју понуду укључи цену за све лиценце за системски и апликативни (тзв. Third Party) софтвер неопходан за функционисање понуђеног софтвера. Изабрани понуђач нема право да од Наручиоца током имплементације захтева додатне софтверске лиценце које повлаче обавезу плаћања за ЕМС АД. За потребне лиценце изабрани понуђач је дужан да обезбеди подршку у трајању од најмање једне године од момента пуштања у продуктивни рад. 4.2. ИТ архитектура платформе ИТ арихтектура платформе је предмет усаглашавања представника изабраног понуђача и ЕМС АД током фазе дизајн система. Изабрани понуђач сачињава предлог препоручене системске инфраструктуре за оптималан рад будућег система као архитектуру система у свом понуђеном решењу, односно структуру, број и функцију апликативних и базних сервера који се у њему налазе, са детаљним описом начина решења за редундантност система, уз опис функционалности и безбедносних механизама, који мора бити усвојен од стране ЕМС АД након усаглашавања. Концепт платформе у домену ИТ безбедности мора испуњавати услове најбоље светске праксе у смислу заштите података од неовлашћеног приступа и измена. Наручилац треба да поседује стандардне системе за заштиту корпоративне мреже (firewall, WAF, PKI инфраструктура и слично) при чему је у употреби интерни (LAN) u јавни (DMZ) сегмент мреже. Уколико се за рад платформе буде користио неки од јавних сервиса (cioud, hosting u слич но), изабрани понуђач је у обавези да обезбеди све заштитне механизме и о томе достави потврду ЕМС АД. Евентуално коришћење јавних сервиса и обрада података на инфраструктури која није у власништву ЕМС АД могуће је само у случајевима када је то технички оправдано и мора бити одобрено од стране ЕМС АД. Изабрани понуђач, кроз дизајн система, мора да обезбеди примену одговарајуће политке лозинки (комплексност, периодичност промене итд) као и заштиту од аутоматског генерисања захтева за регистрацију (captcha). Део платформе на ресурсима ЕМС АД мора да има могућност рада на виртуелизованој серверској инфраструктури VMware. EMC АД ћe за серверску инфраструктуру обезбедити ресурсе (VCPU, RAM, storage простор у складу са усвојеном архитектур ом). ЕМС АД обезбеђује Виртуализовано серверско окружење (VMware) неопходно за инсталацију софтвера и свих неопходних компоненти за рад понуђеног решења. ЕМС АД ћe за потребе серверске инфраструктуре обезбедити оквирно 16 GB RAM и 500 GB storage простора. Оправдани додатни ресурси моry бити одобрени за коришћење након фазе Дизајн система. Изабрани понуђач је у обавези да ЕМС АД достави детаљну спецификацију система на основу које ћe се конфиryрисати заштитни механизми ИТ мреже у власништву ЕМС АД. На додељеним виртуелним машинама (VM), изабрани понуђач је обавезан да континуирано обезбеђује: • редовно ажурирање оперативног система и апликативног софтвера (update/upgrade), • инсталацију и примену свих безбедносних закрпа испоручених кроз ИС наручиоца • управљање и правовремено обнављање дигиталних сертификата (SSL/TLS и других релевантних) у договору са наручиоцем, • примену политика лозинки и осталих мера дефинисаних током фазе дизајна, • процедуре за backup и restore апликативних компоненти које се налазе на тим VM , • евиденцију и извештавање о свим активностима везаним за безбедносне инциденте или проблеме у раду. 5. Основни модули апликације Апликација ЕДД РДЦ треба да има неколико основих функционалности имплементираних кроз следеће делове/модуле апликације • Администрација и управљање корисничким налозима • Распоред рада диспечера • Пријављивање корисника и примопредаја смене • Класификација података и каталози • Евидентирање података о раду система • Генерисање и слање Извештаја • Документација 6. Администрација и управљање корисничким налозима Диспечер започиње рад у апликацији пријавом/логовањем на систем. Приступ апликацији Диспечерски дневник је омогућен само за пријављене кориснике. Неопходно је имплементирати посебан модул за администрацију корисничких налога коме ће имати приступ само одређена група корисника са Админ/Супервисор правима. Модул за администрацију корисника треба да омогући креирање, измену и деактивацију корисничких налога, као и доделу различитих нивоа приступа тј. права. Основни подаци које један кориснички налог треба да садржи су: • Име корисника • Презиме корисника • Корисничко име • Email • Лозинка • Права корисника на основу којих је могуће одредити које акције корисника су омогућене у апликацији • Позиција у организацији (нпр. диспечер приправник, оперативни диспечер, координатор – руководилац смене...) Потребно је омогућити чување и додатних података за кориснички налог који могу бити касније проширени и дефинисани, нпр. број телефона и остали контакт подаци. 7. Распоред рада диспечера Тренутно се распоред о раду диспечера прави у виду у облику .excel документа. Овај фајл садржи распоред рада диспечера по сменама за сваки дан (план) у наредних месец дана. У једној смени је потребно планирати различите улоге/квалификације: • X1 Водећи диспечер смене (у дневној смени / (у ноћној смени) • X2 Самостални диспечер у смени (у дневној смени / (у ноћној смени) • X3 Самостални диспечер у смени (у дневној смени / (у ноћној смени) • А Асистент диспечер на обуци (у дневној смени / (у ноћној смени) У оквиру постојећег RBAC (Role Based Access Control) система потребно је предвидети различите квалификације диспечера у смени (само водећи диспечер смене може бити распоређен на оба радна места у оквиру једне смене (X1, X2 и Х3), али самостални диспечер може бити распоређен само на место диспечера X2/3. Поред неопходних улога у смени могуће је дефинисати и додатне статусе у плану: • O Обука • ДС Диспечерски састанак • СП Службени пут • КС Крсна слава • 8 Редовно радно време • ПО Плаћено одсуство • Б Боловање • П Приправност • Г Годишњи одмор • СД слободан дан (није расположив) • Произвољан унос броја сати (од 1 до 8) • едитабилно празно поље Приказ треба да садржи другачије бојење викенда и да предвиди да администратор може да обележи дане који се воде као празници другачијим бојењем. Модул за планирање рада диспечера треба да прати постојећи процес који се одвија кроз .excel тј треба да садржи четири функционалности: Планирање распореда за диспечере за сваку смену у планираном месецу. Ова форма приказује матрицу са X oсом – дани у месецу и Y осом – диспечери. Руков одилац сектора/шеф службе РДЦ прави план попуњавајући матрицу са једним од горе наведених статуса за сваког диспечера и за сваки дан у месецу. Потребно је направити ограничења за немогуће уносе (ноћна смена пре дневне, обуке викендом...). Такође ова форма треба да предвиди упозорења када се унесе непредвиђени режим рада, на пример три исте смене за редом или пребацивање дозвољене недељне норме од 60 радних сати, већи или мањи број запослених од прописаног у једној смени итд. За сва ова упозорења потребано је да диспечер који ради потврди да жели да ради у оваквом режиму. Преглед попуњености распореда представља матрицу са X oсом – дани у месецу и Y осом – статуси (тј улоге диспечера) из распореда. Овај преглед омогућава јасан и сумаран преглед попуњености распореда (јасно се види ако за неки дан недостаје диспечер са одређеном улогом или квалификацијом ) Седмични (детаљни) преглед распореда преставља календар са данима у седмици и додатим диспечерима (са одређеним квалификацијама) по данима. Претрага којом је потребно предвидети рад диспечера током празника и водити евиденцију броја празничних смена за сваког диспечера. Такође, потребно је предвидети филтрирање распореда рада по диспечеру са статистиком колико је смена радио у току задатог периода претраге, к олико је дана радио у режиму са редовним радним временом. У оквиру ове функционалности потребно је предвидети и рачунање преосталог броја дана годишњег одмора на основу податка који администратор уноси на почетку сваке године. Годишњи одмор може имати две квалификације ``стари`` и ``нови``, где се не може трошити нови годишњи одмор док се не искористи стари, а исто тако да се за први део „новог“ годишњег мора користити најмање 10 дана Дати модул треба да омогућава извештавање за изабрани месец у .pdf формату и то • Извештај за распоред рада • Извештај распореда рада за изабраног диспечера • Извештај за распоред диспечера у сменама Извештаји не треба да прикажу другачије бојење поља у ком је диспечер обележио да неће бити расположив. Омогућити да, након завршетка календарског месеца Руководилац сектора/шеф службе РДЦ потврди реализовани распоред рада диспечера и аутоматски, повезивањем са апликацијом САП/ управљање временом, попуни обрачун сати у датој апликацији. Модул треба да има могућност аутоматског слања извештаја и потребно је предвидети контролу приступа функционалностима у овом модулу додавањем нових права приступа у оквиру постојећег RBAC (Role Based Access Control) система. 8. Приjaвa корисника и примопредаја смене Да би диспечер започео унос догађаја о раду система, у апликацију мора претходно да се пријави на систем. На крају смене, када су сви записи дневника унети, апликација мора да омогући затварање и примопредају смене. Неопходно је да апликација обезбеди извођење поступка примопредаје смене диспечера. Не сме се допустити ’’празан ход’’ у смислу да је у неком тренутку тренутна смена одјављена , а да следећа није претходно пријављена (нпр. да се тренутна смена одјави у 19:01, а да се наредна пријави у 19:02). За време примопредаје смене, за све догађаје у смени одговорна је тренутна смена тј. диспечери који тренутно предају смену. Примопредаја није могућа ако нису присутни сви диспечери (тренутна и следећа смена), сем у специјаним случајевима када је могуће направити изузетак, а што ће бити детаљно деф инисано у фази израде апликације. Када стигну, диспечери из следеће смене пријављују се у апликацију да потврде своје присуство и спремност, и за време примопредаје не могу да мењају или убацују записе. Приja вa на систем може се вршити са било ког рачунара на коме је апликација инсталирана у диспечерској сали. • Диспечери из следеће смене се пријављују на систем и потврђују спремност за пријем информација означавањем поља за потврду „спремно за пријем“ (или се самом пријавом на систем може сматрати да су диспечери спремни). • Након усмене предаје, штампања свих извештаја и потписивања, одлазна смена може затворити смену. • Када се смена затвори, аутоматски се додељује нова шифра смене (отвара се нова смена са подацима о присутним диспечерима) и „диспечери следеће смене“ могу да убаце нове записе па су од тог тренутка они одговорни за догађаје у наредној смени. Штампани извештај о смени треба да садржи одштампане све записе дневника током смене која се затвара и примопредаје. На крају одштампаног сменског извештаја потребно је оставити простор за потпис диспечера који предају смену. Након затварања смене, записе дневника треба заштитити од промене и брисања. Додавање евиденције у затвореној смени такође треба да буде онемогућено. У случајевима када је неопходна пром ена, брисање или додавање евиденције у затвореној смени, треба предвидети посебну процедуру. 9. Класификација података и каталози У апликацији је потребно користити постојеће (без могућности промене од стране администратора ЕДД РДЦ) класификације података: • врсте објеката • елементи • догађаји • узроци • утицаји • опрема • релејна заштита • сопствена потрошња • комуникације по којима ће се вршити праћење оперативних догађаја. На основу класификација потребно је имплементирати шифрарнике који ће се користити у апликацији и приказати листу вредности у пољима (која се појављују у обрасцима за евиденцију података) на основу којих корисник може одабрати жељену вредност а администратор ЕДД РДЦ додати нову за следеће категорије приликом уноса : • Манипулације • Елементи електоенергетског система • Искључења • Рад АПУ • Временски услови • Тип обавештења 10. Евидентирање података о раду система Да би се један догађај евидентирао потребно је обезбедити најмање: • Недвосмислену идентификацију догађаја и активности о раду система • Идентификацију времена догађаја ( време које се уписује може бити различито за различите догађаје. Н а пример, уколико се ради о испаду неког елемента, време може бити уписано ручно (претходно проверено на SCADA систему или са руковаоцем Т С) или аутоматски повучено са SCADA система, али обавезно са могућношћу ручне корекције од стране диспечера. • Недвосмислену идентификацију елемената електроенергетског система (у смислу манипулације или испада или обавештавања у случају активности у раду система). • Основне карактеристике догађаја у раду система или активности у раду система • Идентификацију других битних карактеристика догађаја у раду система • Текстуални опис догађаја Сваком запису дневника треба аутоматски доделити време када је уписан у базу података и корисника који га је уписао (Ово време се разликује од горе описане временске идентификације догађаја). Све промене налога/записа ће систем аутоматски евидентирати, тако да се мора сачувати траг претходног садржаја, време промене и корисник који је извршио промену. Овим подацима може приступити само овлашћено лице. Промене/допуне налога у отвореној смени су дозвољене само за пријављене кориснике у тој смени. Специфичне промене у затвореним сменама су дозвољене само овлашћеном кориснику ЕДД РДЦ-а, Информација о промени се придружује промењеном налогу. Остале промене извести преко допуне догађаја/смене. Информације о раду система које диспечер треба да уноси у Диспечерски дневник могуће је поделити на неколико врста/типова : • Евидентирање података уклопних стања и топологије система o Евидентирање података о манипулацијама (искључењима и укључењима) o Евидентирање података о испадима (outage) • Евидентирање дозвола за извођење радова у ЕЕС • Евидентирање информација о производњи ел. енергије ( нпр. улазак у погон после ремонта, испади генератора...) • Евидентирање информација о сопственој потрошњи и комуникационим системима (релевантне дозволе Д4 из ЕПД ТС, прекиди комуникације,.... ) • Евидентирање информација о прекидима напајања и испадима производних јединица • Евидентирање напајања приоритетних купаца/производње Заједничке каракеристике за све типове догађаја су: • Број налога (аутоматски се генерише, може имати префикс у зависности од типа) • Особа која води евиденцију (пријављени корисник) • Тип записа (избор једног од горе наведених типова догађаја) са предефинисаним маскама за унос података у зависности од типа догађаја • Елемент система (избор са листе вредности) • Наслов записа евиденције (аутоматски се генерише, тип + елемент система) – корисник може да измени текст • Датум/време догађаја (аутоматски се генерише – време, могућа мануелнa исправка/унос) • Напомена (аутоматски пренос из планера испада или ручни унос) • Одговорно лице од кога је примљен и/или коме је дат налог из: НДЦ-а, трафостанице, електране или другог КПС , • Додатни категорисани подаци (планирани/непланирани /ремонт/хитно, повезани налози за рад, повезани други записи евиденције итд.) • Специфичности за тај догађај (на пример, ако се ради о испаду, мора постојати поље где се уписује тип релејне заштите која је реаговала и додатна поља за к арактеристике те заштите... нпр . дистантна заштита, степен 2, фаза ’’0’’, земљоспој, локатор 54 km). 10.1. Евидентирање података о манипулацијама (искључењима и укључењима) Апликација треба да омогући евидентирање података о манипулацијама (искључењима и укључењима) као и евидентирање података о прекидима из тачака 10.7 и 10.8. Промену статуса топологије мреже региструје SCADA систем, и ове податке је неопходно повезати са базом података Категоризације елемената ЕЕС -а и пренети у апликацију ЕДД РДЦ преко одговарајућих интерфејса или уписом ових података у базу апликације ЕДД РДЦ. Пошто се статус топологије мреже пренет из постројења преноси у SCADA системе, може доћи до погрешног преноса, прекида преносног пута или невалидног уписа па због тога диспечер мора имати могућност да ручно ажурира/исправља записе у ЕДД РДЦ. Апликација треба да омогући евидентирање следећих података: • Стандардни подаци који се уносе за све евиденције • Крајеви (ако постоје) елемента (аутоматски или ручни унос - избор са листе вредности преузимање података из ЕД ТС) • Поље за напомену односно опис догађаја/разлог манипулације, уколико је потребно 10.2. Евидентирање података о испадима (outage) Апликација треба да омогући да одређена група евиденција буде логички повезана у једну целину која се уноси у унапред дефинисану форму као у садашњем ЕДД РДЦ , испуњени додатним (мастер) информацијама и повезани са записом у бази података који могу да се уносе аутоматски/ручно. Такође, апликација треба да врши евидентирање података о прекидима из тачака 10.7 и 10.8. Апликација треба да омогући евидентирање следећих података: • Стандардни подаци који се уносе за све евиденције • Крајеви (ако постоје) елемента (аутоматски или ручни унос - избор са листе вредности) • Врста заштите (аутоматски или ручни унос - избор са листе вредности) • Сигнал заштите (аутоматски или ручни унос - избор са листе вредности) • Датум/време окидања (аутоматско или ручно убацивање ако нема записа у SCADA систему) • Квалитет рада (аутоматски или ручни унос - избор са листе вредности) • Узрок испада уколико је познат (предефинисана листа и могућност додатних измена-едитовања) • Поље за напомену односно опис догађаја уколико је потребно (пример: ДВ је испао због неовлашћене сече шуме на траси, при чему је дошло до пуцања фазног проводника у фази ’’8’’. Нема повређених лица, на лицу места се врши увиђај МУП...) • Манипулације проузроковане испадом (уколико их је било) • Поље где се описују евентуалне последице догађаја У случају хаварије: апликација треба да омогући генерисање унапред дефинисаног документа у doc и pdf формату који описује хаварију. 10.3. Евидентирање докумената за рад Подаци о документима за радове у ЕЕС се обезбеђују из екстерног планера тј. апликације ’’Радови’’ и POI. Апликација треба да омогући преглед докумената за рад (издатих и затворених) и убацивање у налоге за манипулације. Такође, све дозволе које су тренутно на снази морају имати црвени ’’ flag’’ који је лако уочљив за све диспечере у смени. 10.4. Сопствена потрошња Апликација треба да омогући евидентирање података о раду сопствене потрошње аутомат ским превлачењем са SCADA система или ручним уносом. 10.5. Евидентирање информација о комуникационим системима Апликација треба да омогући евидентирање података о стању комуникационих система аутоматским превлачењем са SCADA система или ручним уносом: • Опрема (избор са листе вредности) • Тип догађаја (избор са листе вредности) • Преузимање података о релевантним Д4 дозволама из ЕПД ТС • Додатни категорисани подаци 10.6. Евидентирање важних информација (за примопредају смене) о статусима главних елемената електроенергетског систем Апликација треба да омогући примопредају смене у коме би се евидентирали следећи подаци: • Елементи којима је промењено уклопно стање у смени која се завршава, • Елементи чије је искључење најављено у смени која се завршава, • Напонске прилике, • Елементи или опрема који су нерасположиви дуже од једног дана. Извештај треба да садржи тип елемента, напонски ниво, назив елемента, разлог нерасположивости, реаговање уређаја за АПУ, временски период нерасположивости, време трајања нерасположивости. • Подаци о Производњи, подаци о осталој опреми (СКАДА, ИКТ систем..), • Учитани резултати анализе сигурности • Стање производних капацитета Подаци о стању производних капацитета у електоенергетском систему требa аутоматизовати, тако да се tracking вредност аутоматски рачуна у процесу импорта. Уносиће се пре примопредаје смене. 10.7. Евидентирање информација о прекидима напајања Апликација треба да омогући и посебно евидентирање прекида напајања кроз посебну форму која треба да садржи следеће податке: • Стандардни подаци који се уносе за све евиденције • ЕЕО који је остао без напајања (избор са листе вредности) • Врста прекида (планиран – непланиран) • Узрок прекида испоруке (избор са листе могућих разлога: ЕМС, Други субјекат, трећа страна..). У случају избора ЕМС-а обезбедити подмени избор са листе могућих разлога: пролазан/трајан квар на ДВ... • Испала снага и време трајања прекида (вредност у МW уноси корисник, а време трајања прекида и неиспоручена енергија се генеришу на основу уноса) • Назив и број мерних места на којима је прекинута испорука из падајућег менија • Додатни категорисани подаци • Коментар о прекиду 10.8. Евидентирање информација о прекидима производње Апликација треба да омогући и посебно евидентирање прекида производње кроз посебну форму која треба да садржи следеће податке: • Стандардни подаци који се уносе за све евиденције • ЕЕО који је престао са производњом (избор са листе вредности) • Врста прекида (планиран – непланиран) • Узрок прекида производње (избор са листе могућих разлога: ЕМС, Други субјекат, трећа страна..). У случају избора ЕМС-а обезбедити подмени избор са листе могућих разлога: пролазан/трајан квар на ДВ... • Испала снага и време трајања прекида (вредност у МW уноси корисник, а време трајања прекида и неиспоручена енергија се генеришу на основу уноса) • Подацио о уласку у погон/расположивости • Додатни категорисани подаци • Коментар о прекиду 10.9. Придруживање докумената налозима (attachment) За сва документа која су настала ван апликације, а неопходно је да буду део налога, апликација мора да омогући њихово придруживање налогу. У оквиру апликације треба омогућити приказ послатих и примљених email порука без напуштања апликације. Овај сервис би требало да повлачи послате и примљене email поруке са предефинисаног email налога и да их приказује у апликацији. Уколико пристигне нова порука, корисник би требало да буду обавештен. Документа се „уплоад“-ују и везују за сам налог. Подржани формати: - PDF - Word - Excel - CSV - JPG - PNG Дати модул треба да предвиди могућност повезивања са апликацијом ЕДОП (електронски дневник оперативног планирања) коришћењем ``activity stream`` функционалности. 10.10. Проблематика погона мреже Омогућити унос текста који се формира од одабраних обавештења унетих у смени. Формирање информације може се омогућити одабиром од стране диспечера већ унетих обавештења као и мануелним уносом. 10.11. Незавршени догађаји Апликација треба да омогући завршавање догађаја типа: Испад, Рад ТСУ, Рад ТК и Сопствена потрошња. 11. Генерисање и слање извештаја Неопходно је да апликација ЕДД РДЦ омогући покретање унапред дефинисаних извештаја и лако креирање различитих извештаја на основу ускладиштених података. Апликација треба да омогући преглед и штампање посебних извештаја за произвољно време који садржи евидентиране податке o: • Манипулацијама Укључењима/Искључењима • Испадима (outage) • Документима за рад • Статусима елемената електроенергетског система • Прекидима напајања и прекидима производње • Извештај о ангажовању руковаоца ДУ ТС • Обавештења (неспецифицирани подаци) Такође апликација треба да омогу ћи штампање извештаја о смени који треба да садржи од штампане све записе дневника током смене која се затвара и примопредаје и то поређане по редним бројевима налога. Апликација треба да омогући дистрибуцију предефинисаног извештаја о смени електронском поштом дефинисаним групама. Апликација треба да омогући израду и дистрибуцију предефинисаног обједињеног извештаја о смени свих РДЦ+НДЦ (омогућити израду група центара према потреби извештаја: било који/сви РДЦ и/или НДЦ респектабилно) електронском поштом дефинисаним групама који треба да буду хронолошки поређ ани на основу времена заузимања налога из појединих центара управљања или обједињено по центрима управаљања (НДЦ, РДЦ Бгд, РДЦ Ва, РДЦ НС, РДЦ Бор и РДЦ Кш). На основу унетих података у апликацију о испадима, кваровима и манипулацијама као и прекидима напајања потрошње и производње апликација треба да омогући генерисање и дистрибуцију извештаја о поремећају. Након креирања извештаја потребно је омогућити аутоматско чување извештаја на предефинисаној локацији у оквиру фолдера Диспечерска документација нако н примопредаје смене. Ради лакше претраге потребно је увести нову опцију у оквиру поља ''Тип налога'' чије име ће бити дефинисано концептуалним дизајном. Апликација треба да омогући креирање и дистрибуцију 1. и 2. информације о покретању екипе електронском поштом дефинисаним групама. Апликација треба да омогући креирање и дистрибуцију извештаја о ангажовању руковаоца ДУ ТС електронском поштом дефинисаним групама. Апликација треба да омогући креирање, слање, пријем и приказ конверзације СМС-ом према/од дефинисаних група или појединца Апликација ЕДД РДЦ треба да омогући преглед различитих типова датотека (PDF, слике у популарним форматима, МS Excel, МS Word, аудио/видео датотеке) приликом процеса евидентирања догађаја. Апликација треба да омогући креирање извештаја који би приказивао нерасположивост елемената преносних капацитета у неком временском периоду. Извештај треба да саджи тип елемента, напонски ниво, назив елемента, разлог нерасположивости, реаговање уређаја за АПУ, временски период нерасположиво сти, време трајања нерасположивости, број колико пута је елемент био нерасположив у задатом временском периоду, као и кумулативно време нерасположивости за сваки елемент у задатом временском периоду. Овај извештај је потребно лако филтрирати по свим критериј умима који се користе за креирање извештаја. Потребно је овакав извештај генерисати у .xls и .pdf формату. Сваки приложени документ треба да има опцију да буде означен као „садржај документа треба да буде одштампан у извештају о сменама“ или „само приложен као додатна информација“. Уколико је приложена датотека означена за штампање, потребно је омогућити преглед садржаја датотеке и штампање у оквиру сменског извештаја. 12. Документација Потребно је у менију апликације додати нови модул који би омогућио брз приступ докуметима из следећих категорија: • Категоризација • Лимити и заштите • Карактеристике елемената • Шеме објеката Прве три категорије су тренутно доступни као .xlsx документи и диспечерима је веома често потребан увид и претрага ових информација. Апликација би требала да омогући директан приступ датим документима (актуелним верзијама) без напуштања апликације. Процес категоризације је већ пребачен у апликацију ЕДОП те треба предвидети опцију да се диспечерима учини доступним форма са приказом актуелне категоризације која се води апликативно. Такође, потребно је обезбедити приступ свим једнополним и диспозиционим шемама 400 kV, 220 kV i 110 kV ЕЕС. Потребно је предвидети и контролу приступа овом модулу додавањем нових права приступа у оквиру постојећег RBAC (Role Based Access Control) система. 13. Преглед додатних функционалности ЕДД РДЦ 13.1. Унос налога у оквиру смене: - тип налога (манипулације, испади ...дефинисати накнадно као и филтрирање) - наслов - манипулације (ставке) (под овим се подразумева унос манипулација: могућнос т преузимања сигнала манипулација: • директно са SCADA система (предефинисање филтера SCADA система за манипулације), • ручни унос сигнала манипулација, • могућност повлачења сигнала манипулација из ЕД ТС - могућност претраге налога по: • броју • имену диспечера • претрага налога по картицама (grid) - унос напомена (напомене везане за затворене догађаје која носи информације o радном задатку који је затворен се директно повлаче из апликације “Радови“.) - повезивање налога који су у међусобној вези уз опцију бирања могућности штампе (повезивањ е два или више налога везани за исти догађај ) - унос предефинисаних/ручних имена руковаоца, диспечера ПДЦ-ова и ДДЦ-ова, као и руковалаца разводних постројења ЕПС-а и КПС-а из апликације „Радови“ директно у ЕДД везано за манипулацију. - могућност претраге догађаја са SCADA система у ЕДД (испис са SCADA система директно учитавати у ЕДД уз филтрирање сигнала појединих заштита). - унос електронских докумената са више страница. - филтрирање примедби упућених техничкој подршци (прекид комуникације са трафостаницама, далеководним пољем, квар видео надзора, ангажовања руковаоца, нерасположивост ДУ, ИНТ сигнал, итд...) - приказ дозвола које су на снази и позивање дозволе кликом (веза са апликацијом „Радови“) - могућност евидентирања испада и кварова, као и повлачење сигнала са SCADA система који су у вези са испадом. - немогућност уписа времена укључења елемента ЕЕС ако претходно дозвола за радове на том елементу није затворена - поред опције манипулације, увести опцију „од раније“ за елемент искључен од раније - испад сопствене потрошње ТС. - израда обавештења и коментара смене. - приказ ИНТ сигнала са SCADA система који се није деактивирао након 2-3 мин. - евидентирање Д4 дозвола које могу променити уклопно стање и комуникацију са трафостаницама (преузимање података из ЕД ТС). - налози за електране где постоји избор електране, као и начин ангажовања електране , име диспечера НДЦ-а који је издао налог и име руковаоца команде електране. 13.2. Извештај за текућу смену (примопредаја смене, задржати постојеће ставке) - упис елемената који нису расположиви дужи временски период - евидентирање електрана које су на мрежи - анализа сигурности - упис диспечера за следећу смену - могућност штампања извештаја 13.3. Информисање о промени уклопног стања елемената ЕЕС електроенергетског система и директног слања истог ка ЕДОП. 13.4. Помоћ (инф. о бројевима телефона људи задужених за ЕДД) 13.5. Унос предефинисаних података са Scalar-a (слика као прилог). 13.6. Обавештавање о новим документима са чекирањем садржаја 13.7. Извештај о стању производних јединица са SCADA система 13.8. Омогућити у дневнику пребацивање текста из латинице у ћирилицу и обрнуто. 13.9. Аутоматска опомена да се елемент налази у незавршеним догађајима и избацивање из те листе 13.10. Апликација мора да омогући да приликом примопредаје смене ноћ/дан, аутоматски одабрани догађаји типа Испад, Манипулације, Рад ТСУ, Рад ТК, Сопствена потрошња пређу у Погонски извештај, као и аутоматско затварање Погонског извештаја за претходни дан 13.11. Апликација мора да омогући да се подаци о Прекидима корисника и производње пренесу у БИ 14. Планирање и управљање пројектним активностима Наведена набавка има форму пројекта и прати одговарајућу пројектну методологију. 14.1. Прелиминарни план и припрема пројекта Имајући у виду активности које је неопходно спр овести у процесу имплементације, очекује се да понуда обухвати методологију имплементације предметног решења. У припремној фази пројекта потребно je доставити Прелиминарни План пројекта који треба да обухвата: • Оквирни план организације и управљања пројектом (у форми нацрта обзиром да ће исти бити усаглашен у фази припреме пројекта). • Оквирни план пројекта (којим су обухваћене све фазе у току имплементације, наведене очекиване активности са предвиђеним временом почетка и одговорностима учесника на пројекту). • Оквирни план обуке корисника (са информацијама о потребним предзнањима). • Оквирни план тестирања система. • Предвиђене процедуре управљања ризицима (идентификација, вероватноћа настајања, значај, одговор). У припремној фази пројекта , потребно је усагласити наведене планове у сарадњи са ЕМС АД и интегрисати их у Пословник пројекта, који треба да се усвоји од стране руководства пројекта. Пословником пројекта потребно је детаљније дефинисати процедуре и правила која ће важити на пројекту ЕДД РДЦ. Пословник треба да садржи: основне информације о Пројекту, пројектну организацију (односно информације о пројектном тиму који ће бити ангажован на реализацији пројектних задатака, процесима који се односе на рад и управљање Пројектом), пројектну документацији која ће бити вођена током реализације Прој екта као и процедуру прихватања документације, управљање захтевима за измену, смернице за комуникацију током реализације пројектних обавеза, процес управљања потенцијалним ризицима и проблемима, стратегију тестирања и прихватања решења. Осим наведеног обавезна је израда/усаглашавање Детаљног плана пројекта (временски гантограм) са дефинисаним фазама пројекта који може да буде основ за периодична плаћања уколико се договори фазно плаћање, по реализацији одређене фазе пројекта. 14.2. Израда концептуалног дизајна решења Након завршетка припремне фазе пројекта и усвајања пословника пројекта обавезна је израда Концептуалног дизајна ЕДД РДЦ који треба да буде обострано усаглашен. Концептуални дизајн треба да дефинише архитектуру система као и детаљан дизајн техничког и технолошког решења ЕДД РДЦ по којем ће се извршити имплемеатација истог. 14.3 Пројектни тим ЕМС АД ЕМС АД ће именовати најрелевантније познаваоце пословне проблематике у стално чланство пројектног тима и обезбедити сталну подршку пројекту. У току пројекта ангажоваће се и повремени чланови за специфичне задатке. Пројектни тим мора бити интегрисан као део тима Понуђача. Док ће одговорност за имплементацију система бити на Понуђачу, улога тима ЕМС АД ће бити да пружи помоћ Понуђачу и обезбеди све релевантне информације, како би Понуђач био у могућности да имплементира решења која су предмет имплементације 14.4 Пројектна организација Минимална предложена организација пројекта која се уобичајено обезеђује на сличним пројектима обухвата: • Директора пројекта ЕМС АД кога именује ЕМС АД и који промовише имплементацију овe апликација у организацији, додељује ресурсе потребне за успех, одговоран за надзор имплементације решења и решавање свих питања која могу да утичу на напредак пројекта. • Руководиоце пројекта са стране ЕМС АД и стране Испоручиоца. Одговорност руководилаца пројекта ће бити међусобна сарадња, извештавање Надзорног одбора о статусу пројекта и обезбеђивање напредка пројектних активности и испоруку уговорених обавеза у оквиру плана. • Тим за имплементацију у који ће, поред представника Испоручиоца, бити укључени релевантни представници ИКТ, изабрани чланови пословних служби као чланови тима за дизајн система из ЕМС АД. Одговорност тима за имплементацију је увођење и конфигурација система, као и стављање система у стање оперативности. Веома је значајно да чланови тима за имплементацију блиско сарађују током имплементације. Испоручилац ће у сарадњи са ЕМС АД, у припремној фази пројекта, усагласити организациону структуру пројекта и формирати пројектне тимове састављене од његових консултаната и запослених из ЕМС АД који ће радити на реализацији пројектних активности. 14.5 Остала подршка на пројекту Поред обезбеђења кадрова за руководство пројекта и пројектне тимове , ЕМС АД ће тиму Испоручиоца за имплементацију према потреби обезбедити и: • Канцеларијски простор за тим Испоручиоца док је на локацији. • Приступ салама за састанке. • Помоћ у организацији састанака са особљем и руководством ЕМС АД. Испоручилац ће у сарадњи са ЕМС АД, у припремној фази пројекта, усагл асити спецификацију остале подршке пројекту коју треба да обезбеди ЕМС АД. 15. Фазе реализације пројекта Табела 2: Фазе реализације пројекта Фаза 1: Припрема пројекта Активности • Формирање пројектних тимова • Планирање пројекта • Израда детаљног плана пројекта Излазна документација • План организације и управљања пројектом (Пословник пројекта који треба да обухвати и: План управљања ризицима, План тестирања решења, План обуке корисника) • План пројекта (ток имплементације са планираним временом почетка и краја сваке активности и одговорностима) • Спецификација подршке пројекту коју обезбеђује ЕМС АД Верификација завршетка фазе Извештај пројектног тима о успешно реализованим активностима на припреми пројекта усвојен од руководства пројекта Фаза 2: Израда концептуалног дизајна Активности • Израда концептуалног дизајна решења Излазна документација • Концептуални дизајн система – (енгл. Business Blueprint) Верификација завршетка фазе Након успешно реализованих Фаза 1 и 2, Наручилац и Испоручилац потписују Записник о изврш еној реализацији Фазе 1 и Фазе 2 , који представља потврду о завршетку наведених фаза и основ за плаћање у складу са уговором. Фаза 3: Имплементација решења (Развој, тестирање и пуштање у рад) • Фаза 3а: Развој, прилагођавање и интеграција Активности • Конфигурисање и развој решења у складу са захтеваним функционалностима • Приказ развијеног решења Излазна документација • Извештај о реализованој подфази 3а – Развој, прилагођавање и интеграција Верификација завршетка подфазе Извештај пројектног тима о успешно реализованој подфази 3а усвојен од руководства пројекта • Фаза 3б: Тестирање система Активности • Тестирање у складу са захтевима конкурсне документације и усвојеним Планом тестирања решења Излазна документација • Документација о тестирању система (енгл. Acceptance Testing Documentation) • Извештај о успешно извршеном тестирању Верификација завршетка подфазе Извештај пројектног тима о успешно реализованој подфази 3б усвојен од руководства пројекта • Фаза 3в: Припрема и пуштање у продукцију Активности • Припрема пред продукцију • Пуштање у рад (GoLive) Излазна документација • Одлука пројектног тима о почетку продукционог рада Верификација завршетка подфазе Извештај пројектног тима о успешно реализованој подфази 3в и успешном пуштању система у продукциони рад усвојен од руководства пројекта Верификација завршетка фазе 3 Након успешно реализованих подфаза 3а, 3б и 3в, Наручилац и Испоручилац потписују Записник о извршеној реализацији Фазе 3, који представља потврду о завршетку Фазе 3 и основ за плаћање у складу са уговором. Фаза 4: Обука корисника Активности • Обука за коришћење система (кључник и крајњих корисника) • Обука за администрацију имплементираног решења (опционо) Излазна документација • Кориснички приручници • Технички приручници • Извештај о извршеној обуци корисника Верификација завршетка фазе Након успешно реализоване обуке, Наручилац и Испоручилац потписују Записник о извршеној реализацији Фазе 4, који представља потврду о завршетку Фазе 4 и основ за плаћање у складу са уговором. 16. Тестирање Прилком испоруке софтвера неопходно је да се достави листа неопходне пројектне документације у фази тестирања. Тестирање се врши на основу добијених тест сценарија. На основу тестирања се врши верификација софтвера. Корисници из ЕМС АД ће урадити самостално неструктуриране тестове како би се осигурао квалитет достављеног решења. Тестови треба да потврде интегритет, перформансе и функционалности појединачних интеграција и да демонстрирају њихово функционисање у интегрисаном системском окружењу. Ови тестови би требало да потврде да су све захтеване интеграције у потпуности имплементиране. У случају да резултати тестирања нису задовољавајући, сви уочени недостаци или грешке биће документовани у извештајима о неусклађености на основу којих ће се извршити потребне корекције и тестирања ће се поновити. Овај поступак ће се понављати све док резултати теста не буду позитивни. 17. Обука корисника Oбзиром на значај који систем има за пословање ЕМС АД, посебна пажњa мора да се посвети обуци корисника (кључних и крајњих корисника), како би се осигурало да се код њих развију потребна знањa и вештине. Начин и рокови за спровођење обуке корисника биће дефинисани кроз План обука у фази припреме пројекта. План минимално треба да обухвати: • Обуку за коришћење ЕДД РДЦ. Предвиђено је да ова обука буде реализована у трајању од 2 дана по локацији седишта РДЦ (до 15 полазника) на крају пројекта. • Према потреби, обуку за администрацију и одржавање имплементираног решења у укупном трајању од 2 дана (до 10 полазника). Нaкoн зaвршeнe oбукe зaпoслeни мoрajу бити oспoсoбљeни зa