Автоматизована інформаційна система об'єднаної диспетчерської служби ЖКГ - як інноваційний інструмент підвищення енергоефективності муніципального освіти. I-DS Система диспетчерського управління Диспетчерська інформаційна система створює

Під диспетчерською службою розуміють централізовану форму оперативного управління на основі застосування технічних засобів зв'язку, збору інформації, її обробки та здійснення оперативного контролю та регулювання сільськогосподарського виробництва.

Організація диспетчерської служби дозволяє значно підвищити продуктивність управлінської праці, розширити норми керованості та підвищити ефективність управління. Вона складається з наступних елементів: диспетчерського персоналу центрального диспетчерського пункту, диспетчерських постів у бригадах та фермах; комплексу технічних засобів управління (внутрішньовиробнича радіо- та телефонний зв'язок, технологічний та документальний зв'язок, засоби наочного відображення інформації); застосовуваних методів централізованого оперативного управління.

Диспетчерська служба створюється для виконання таких видів робіт:

в галузі інформаційного забезпечення:

Збір, зберігання та обробка поточної оперативної інформації про перебіг виробничих процесів у всіх підрозділах господарства та подання відповідних даних керівникам, головним спеціалістам господарства та сільськогосподарським органам на рівні району;

Здійснення двостороннього оперативного зв'язку керівників та головних фахівців один з одним, а також з керівниками та спеціалістами внутрішньогосподарських виробничих підрозділів; передача всієї командної інформації, що виходить від керівників, у первинні виробничі підрозділи;

Збір різних питань та заявок, що надходять із структурних підрозділів та адресованих керівникам господарства, а також керівникам окремих функціональних підрозділів;

Проведення диспетчерських нарад за спеціально розробленим графіком;

в галузі обліку та контролю:

Контроль за виконанням усіма внутрішньогосподарськими підрозділами вказівок та розпоряджень керівників господарства;

Контроль за виконанням робочих планів, затверджених усіма структурними підрозділами господарства, у тому числі за такими параметрами, як строки та обсяг намічених робіт, здавання продукції державі;

Контроль за своєчасним виконанням усіма функціональними службами та різними внутрішньогосподарськими підрозділами запитів та заявок, переданих ним з диспетчерської служби;

Контроль за роботою машинно-тракторного парку;

у галузі оперативного розпорядження- Оперативне управління виробництвом, координація господарської діяльності всіх структурних підрозділів господарства; усунення відхилень, що виникають у виробничій діяльності;

в галузі організації та обслуговування виробництва:

Організація та проведення силами спеціальних ланок (бригад та ланок майстрів-наладчиків) своєчасного технічного обслуговування та аварійного ремонту сільськогосподарських машин та механізмів;


Збір заявок та контроль за внутрішньогосподарським матеріально-технічним постачанням усіх структурних підрозділів, у тому числі паливом та мастильними матеріалами, запасними частинами тощо на основі відповідних планів, що розробляються функціональними службами спільно з керівниками первинних структурних підрозділів;

Організація централізованих внутрішньогосподарських транспортних перевезень вантажів та громадян відповідно до розроблених планів, а також за заявками структурних підрозділів.

Обсяг робіт, що виконуються диспетчерською службою, може бути різним, особливо в частині оперативного розпорядження. В останні роки у зв'язку з розширенням самостійності внутрішньогосподарських підрозділів багато видів робіт з оперативного розпорядження передано на нижчий рівень управління - керуючим, бригадирам, проте це не виключає необхідності координації робіт за допомогою оперативного управління загалом по підприємству.

Завдяки диспетчерській службі інші функціональні та лінійні служби управління отримують можливість вирішувати завдання, пов'язані з довгостроковими перспективами розвитку господарства, вирішувати такі кардинальні проблеми, як удосконалення техніки та технології виробництва, організація праці, впровадження у виробництво новітніх досягнень науки та передового досвіду.

Для вирішення питань оперативного управління апарат диспетчерської служби повинен мати відповідні знання. Діяльність диспетчера ґрунтується на правильній оцінці ходу виробництва, умінні передбачати наслідки відхилень від плану та намітити конкретні заходи, що ведуть до усунення виявлених недоліків. Для цього диспетчерський апарат крім знання сільськогосподарського виробництва повинен мати здатність до прогнозу та аналізу, вміння швидко орієнтуватися в складній, постійно мінливій виробничій обстановці.

Структура диспетчерської служби визначається масштабами виробництва, його концентрацією, територіальним розміщенням, віддаленістю виробничих підрозділів, змістом та обсягом виконуваних робіт. У великих сільськогосподарських підприємствах оперативне управління здійснюється через центральний диспетчерський пульт та мережу диспетчерських пунктів під час виробничих підрозділів. У середніх та невеликих господарствах воно здійснюється через центральний диспетчерський пункт та диспетчерські пости у бригадах та фермах.

Керує диспетчерською службою у господарствах головний (старший) диспетчер,виконує функції заступника з оперативного управління. На цю посаду зазвичай призначають кваліфікованих досвідчених фахівців, які мають практику керівництва сільськогосподарським виробництвом. Головному диспетчеру підпорядковуються з оперативних питань усі керівники підрозділів основного та обслуговуючого виробництв.

Сфера діяльності головного (старшого) диспетчера є надзвичайно різноманітною. Практика роботи диспетчерської служби показала, що йому доводиться вирішувати питання, що потребують найрізноманітніших знань.

Безпосереднім помічником головного (старшого) диспетчера з оперативного управління диспетчер-оператор,що забезпечує своєчасне надходження, прийом та обробку оперативної інформації про хід виробничого процесу, підготовку її для керівників господарства та вищих організацій.

У напружені періоди сільськогосподарських робіт до штату диспетчерської служби запроваджується посада тимчасового диспетчера-операторадля чергування диспетчерським пунктом. Технік-радистздійснює технічне обслуговування засобів зв'язку та несе відповідальність за їх справність. Обов'язки диспетчерів-інформаторіву господарствах покладаються за сумісництвом на бригадирів рослинницьких бригад, обліковців молочно-товарних ферм, завідувачів ферм, обліковців транспортних бригад та автопарку, бригадира будівельної бригади, начальників допоміжних цехів.

Вирішальним фактором, який забезпечує ефективність функціонування диспетчерської служби, є чітко регламентована діяльність її працівників на основі розроблених функціональних прав та обов'язків. Для досягнення найбільшої ефективності роботи диспетчерської служби працівники підприємства зобов'язані дотримуватись правил обміну службовою інформацією, користуватися засобами диспетчерського зв'язку та дотримуватись вимог охорони праці, своєчасно інформувати диспетчерську службу про результати виконання розпоряджень, регламентованих термінами.

У роботі диспетчерської служби велике значення мають регламентація, порядок використання технічних засобів диспетчерського зв'язку та термін подання оперативної інформації.

Організація та порядок роботи диспетчерської служби у конкретному господарстві визначаються відповідними документами:

1. Положення про диспетчерську службу, в якому відображені її завдання та місце у структурі управління, штати та посадові інструкціїпрацівників, організація диспетчерського обліку, призначення та порядок заповнення його форм, графіки виходу на зв'язок інформаторів відділень, порядок організації та проведення диспетчерських нарад тощо.

2. Розпорядок роботи диспетчерської служби, в якому визначено щогодини час прийому інформації від виробничих ділянок, її обробки та проведення диспетчерських нарад.

Розпорядок робочого дня диспетчерської служби залежить від напруженості роботи у господарстві та складається на літній та зимовий періоди.

Ефективність диспетчерської служби багато чому визначається організацією її. Важливе значення при цьому мають диспетчерська нарада та диспетчерське вбрання. У практиці склалася певна система проведення диспетчерських нарад та нарядів.

Технологія проведення диспетчерської наради.Проводиться раз на тиждень з 17 до 18 год. Присутні: керівник господарства, головний диспетчер, а також залежно від порядку денного головні та старші спеціалісти.

Нарада проводиться за наступним сценарієм:

1. Рапорт головного диспетчера про хід виконання робочих планів (завдань) минулого тижня. Відзначають відсоток виконання плану робіт та найбільші недоліки в організації праці, технології та використання техніки (10-12 хв).

2. Звіти керівників відділеннями, виконроба та завідувача майстернями про виконану за тиждень роботу (тільки про недоліки, недоробки та невиконання) (2-3 хв на кожного).

3. Доповіді головних спеціалістів (по 5-8 хв), які мають складатися із трьох частин: аналіз перебігу робіт за минулий тиждень з виявленням недоліків та їх причин; пропозиції щодо усунення недоліків; проекти робочих планів, попередньо складених разом із керуючими в кожному відділенню.

4. Зауваження щодо робочих планів.

5. Висновок директора чи його заступника з виробництва.

Технологія проведення диспетчерського вбрання.Проводиться щодня з 18 до 18 год. 30 хв. 11в наявності: на центральному диспетчерському пункті - керівник господарства, головний диспетчер, головні фахівці; на диспетчерському пункті відділень - керуючий, спеціалісти відділень, бригадири та завідувачі ферм.

План проведення диспетчерського вбрання такий:

1. Перекличка присутніх.

2. Рапорт головного диспетчера про хід виконання завдань минулого дня. Зазначаються відсоток виконання плану та причини простоїв людей і техніки у відділеннях, зазначаються винуватці (5-6 хв).

3. Короткі доповіді (2-3 хв) головного агронома, головного інженера та головного зоотехніка про порушення технології у використанні техніки. За бажанням надається слово та іншим фахівцям.

4. Управляючі відділеннями аналізують причини допущених зривів, простоїв, пропонують план робіт із відділення наступного дня у разі, якщо вважають із якоїсь причини необхідним відхилитися від робочого плану на тиждень (2-3 хв).

5. Головний диспетчер розподіляє автомобілі та іншу техніку, яка знаходиться у нього в розпорядженні, за попередньо отриманими із відділень заявками (1-2 хв).

6. Висновок директора господарства (3-4 хв). Проведення диспетчерських нарад та диспетчерських нарядів

дозволяє підвищити ефективність оперативного управління, сприяє реальності управління та дисциплінує працівників.

Швидкими темпами здійснюється комплексна диспетчеризація сільського господарства на рівні району та області. Тут до складу диспетчерських об'єктів, крім сільськогосподарських підприємств, включаються всі взаємопов'язані з сільським господарством організації. Це дозволяє оперативно вирішувати багато питань, пов'язаних із реалізацією сільськогосподарської продукції, постачанням та обслуговуванням сільськогосподарських підприємств. Крім того, створення обласних та районних диспетчерських систем та поєднання їх з обчислювальними центрами дозволяє здійснити поступовий перехід до автоматизованих систем управління.

УДК 614.8:351.86+519.8

Проблеми організації інформаційної взаємодії чергово-диспетчерських служб екстрених оперативних служб у процесі створення Системи-112

В. Н. Зубков, С. В. Агєєв, О. В. Денисов, В. В. Тиминський, А. С. Акульшин Анотація

У статті викладено основні проблеми створення та функціонування інформаційних систем екстрених оперативних служб.

Ключові слова: Система-112, виклик екстрених служб, єдина чергово-диспетчерська служба муніципальної освіти, підтримка ухвалення рішення, автоматизовані кошти.

Problems of the Organization Information Interaction of Emergency Field services in the Course of Creation of sistemy-112

В. Зубков, С. Агеев, О. Денісов, В. Тиминський, А. Акульшін, Абстрактний Абстрактний

У матеріалі основні проблеми створення і функціонування інформаційних систем емергенці польових послуг є встановлені.

Key words: System-112, call emergency services, united dispatch office of municipal entity, decision support, automated tools.

Задовго до ідеї створення Системи-112 в Росії з'явилися і дотепер існують різні служби, які здійснюють прийом викликів від населення про різні події та організовують екстрене реагування на них. При цьому заявник сам кваліфікує проблемну подію, за якою бажає отримати допомогу з відомою йому компетенцією оперативної служби та сам обирає, якій екстреній службі адресувати свою проблему за одним із спеціалізованих номерів служб (01, 02, 03, 04 тощо). Як правило, це не викликає жодних складнощів. Випадки звернення «не за адресою» не є системними, і їх кількість не перевищує звичай-

кількість помилкових повідомлень, одержуваних даними службами.

У тих випадках, коли потрібне комплексне застосування сил та засобів кількох оперативних служб, різними спільними наказами, інструкціями, регламентами та угодами організовано досить ефективну взаємодію по лінії чергових (диспетчерських) служб.

З метою оптимізації роботи диспетчерського складу з прийому, обробки, реєстрації повідомлень та організації оперативного реагування на них у відомствах розроблено та ефективно застосовуються різні алгоритми та правила. В сучасних умовах

Майже скрізь реєстрація повідомлень і дій зусиль і коштів із реагування ними, і навіть облік результатів реагування ведеться у електронній формі (від найпростіших форм у форматі Word чи Excel до «програм», розроблених, зазвичай, відомчими фахівцями на місцях). Для розробки повноцінних диспетчерських комплексів завжди потрібні фахівці високого рівнята різних напрямків у галузі інформаційних технологій, тому таких систем насправді сьогодні небагато. При цьому навіть у рамках одного якогось відомства немає єдиного підходу, тому різні підрозділи на територіях оснащені різними системамирізних розробників, з різним рівнем опрацювання функціоналу, різним ступенем автоматизації. Це викликає подив, тому що структура підрозділів всіх розглянутих відомств суворо централізована від федерального до муніципального рівнів, у всіх відомствах є затверджені даними відомствами алгоритми та правила прийому, обробки повідомлень, організації реагування на них, урахування результатів та статистики, єдині для всіх підрозділів даного відомства у всіх суб'єктах.

Необхідно відзначити, що МНС Росії та МВС Росії докладали зусиль для створення систем і комплексів, що автоматизують оперативно-диспетчерські функції, проте централізовано розроблювані та впроваджувані в даних відомствах системи носять характер швидше інформаційно-довідковий та обліково-статистичний, ніж оперативно-диспетчерський та керуючий.

При цьому слід зауважити, що алгоритми та правила прийому, обробки, реєстрації повідомлень, організації реагування на них силами та засобами, облік результатів реагування (вирішення ситуацій) принципово не різняться у всіх екстрених оперативних службах. Підтвердженням цього висновку може послужити і розуміння хронології дій будь-яких служб при реагуванні на повідомлення про подію, що відноситься до їхньої компетенції:

а) прийом, обробка та реєстрація повідомлень;

б) організація реагування на повідомлення - диспетчеризація повідомлення до служб (підрозділів, посадових осіб), компетентних на їх дозвіл;

в) контроль (відстеження) дій щодо реагування, координація дій різних учасників, які здійснюють безпосередньо реагування підлеглими силами та засобами;

г) інформаційна підтримкаприйняття рішень (за потреби) учасникам реагування;

д) реєстрація проміжних та кінцевих результатів; формування статистичної звітності; ведення бази даних подій.

Це дозволяє припустити, що можлива розробка єдиного програмно-апаратного комплексу, що автоматизує на єдиних принципах цей процес у всіх екстрених оперативних службах або будь-якої з них.

Проведений аналіз використовуваних у різних міністерствах та відомствах РФ систем, що автоматизують процес оперативно-диспетчерського управління,

не виявив на сьогоднішній день наявності будь-якої автоматизованої системи, яка об'єднує більшою чи меншою мірою різні чергові та чергово-диспетчерські підрозділи оперативних служб на єдиній організаційній та програмно-технічній платформі, на єдиних принципах управління. Такий підхід значною мірою ускладнює організацію взаємодії між черговими підрозділами всередині відомства, а тим більше ДДС інших відомств.

З появою ідеї (концепції) створення системи-112 з'явилася можливість створення програмно-технічної та інформаційної платформи, що об'єднує всі ДДС екстрених оперативних служб (і, можливо, не тільки екстрених) в єдиний інформаційний простір (або навіть спільнота «e-emergency» - електронні екстрені служби) з метою зручного для населення виклику екстрених оперативних служб за принципом «одного вікна» та організацію комплексу заходів, що забезпечують прискорене реагування та покращення взаємодії оперативних служб при викликах (повідомленнях про подію) від населення. Уніфікований програмно-технічний комплекс Системи-112 міг би стати програмною основою (модулем) в організацію інформаційного взаємодії ДДС оперативних служб у суб'єктах РФ.

Таким чином Система-112 може стати інформаційно-комунікаційною платформою об'єднаної системи оперативно-диспетчерського управління (ОСОДУ) суб'єкта.

Однак спочатку, виходячи із завдань та функцій, що покладаються Концепцією на Систему-112, необхідно усвідомити, що таке Система-112: інформаційна (інформуюча), диспетчерська, керуюча система або всі разом, а потім визначити роль і місце цієї системи серед інших систем суб'єкта , що реалізують аналогічні та суміжні завдання та функції.

Система, яка приймає та обробляє повідомлення (інформацію) від заявника щодо визначення ГОСТу, є інформаційною та підтвердження чи доказу цього факту не потребує. Також Концепція серед завдань Системи-112 чітко виділяє диспетчерські - прийом повідомлень та передачу інформації про подію у ДДС відповідно до їхньої компетенції для організації екстреного реагування; реєстрацію та документування всіх вхідних та вихідних повідомлень, формування статистичної звітності за повідомленнями. З визначень Концепції випливає, що Система-112 за покладеними на неї завданнями є оперативно-диспетчерською системою.

Яка ж роль і місце оперативно-диспетчерської Системи-112 у загальній структурі підрозділів та служб суб'єкта, які реалізують відповідно до компетенції та покладених повноважень аналогічні оперативно-диспетчерські функції?

Концепція визначає Систему-112 як територіально-розподілену інформаційну систему, призначену об'єднувати на основі єдиних чергово-диспетчерських служб (ОДС) муніципальних утворень чергово-диспетчерські служби екстре-

оперативних служб (служба пожежної охорони; служба реагування у надзвичайних ситуаціях; служба міліції; служба швидкої медичної допомоги; аварійна служба газової мережі; служба "Антитерор").

У описі алгоритму дій операторів «112» вбачаються управлінські функції, і навіть передбачається управлінська вертикаль; тому вважатимуться, що Система-112 є информационно-управляющей.

На ґрунті згоди чи заперечення такого підходу відбувається більшість суперечок.

На наш погляд Система-112 є в повсякденному режимі роботи інформаційною системою, але при переході в режим «НС» вона повинна мати можливість перехоплення функції управління, що загалом і закладено в Концепції.

Остаточно звести разом позиції прихильників Системи-112 як інформуючої та розглядають її як керуючу, дозволить розробка нормативно-правового акта, можливо Типового положення про ОСОДУ суб'єкта чи самої Системи-112, де знайде відображення та законодавче закріплення роль та місце ЄДДС та кожної екстреної оперативної служби . У свою чергу розуміння цілей, завдань та функцій ОСОДУ загалом та окремих її елементів, особливо ЄДДР, дозволить підготувати технічні вимогидо програмно-апаратного комплексу, що автоматизує процеси управління та міжвідомчої взаємодії між окремими елементами системи.

Відповідно до схваленої Урядом РФ Концепцією створення Системи-112 її побудова має базуватися на ЄДДС муніципальних утворень. Тому одним із ключових моментів під час створення Системи-112 є визначення статусу та нормативно-правової основи ЄДДС.

Проведений аналіз створюваних у суб'єктах РФ ЄДДС показав, що, як правило, вони не мають жодного штату і, тим більше, юридичного статусу (самостійної юридичної особи, організації), а є якимись позаштатними підрозділами при адміністрації. Такий підхід занижує роль та місце ЄДДС у системі екстреного реагування на НП, а також не дозволяє правильно організувати фінансове забезпечення цієї служби, а отже – і системи загалом.

Проведений аналіз форм та методів створення ОДРС показав, що найбільш раціональним є створення ОДРС на штатній основі як якесь самостійне юридична особа, наприклад спеціальна муніципальна установа, або ж у складі аварійно-рятувального формування, що також є муніципальною установою.

Залежно від адміністративно-територіального поділу регіону та чисельності населення у муніципальних утвореннях можливе створення таких установ у кожному районі чи одного – на весь суб'єкт із філіальною мережею в інших районах.

Такий підхід, на наш погляд, дозволить вирішити проблеми як організаційного характеру при створенні Системи-112, так і надалі вирішити питання з ба-

Також одним із ключових моментів під час створення Системи-112 є оцінка готовності інформаційно-комунікаційної (ІК) інфраструктури регіону до можливості використання сучасних інформаційних технологій (ІТ) у системі виклику екстрених служб. Як показав аналіз, канали зв'язку між ДДС екстрених оперативних служб у більшості суб'єктів РФ були створені в 60-ті роки і фізично зношені, що призводить періодично до проблем з доведення оператором зв'язку виклику до екстрених служб, а тим більше організації передачі інформації (даних), чергово-диспетчерський персонал не володіє сучасними інформаційними засобами та технологіями. За Концепцією Система-112 це багатофункціональна інформаційно-комунікаційна територіально-розподілена система, яка передбачає створення розвиненої та сучасної телекомунікаційної складової, тобто оптоволоконних каналів передачі даних, з досить великою пропускною спроможністю та надійністю, впровадження WEB-технологій у систему передачі даних та викликів між ЄДДС та ДДС.

Тому для вибору регіонів з метою поетапного впровадження Системи-112 зараз необхідно розробити методику оцінки готовності регіонів, у тому числі ДДС екстрених служб, до впровадження Системи-112, яка є, на наш погляд, однією зі складових (сегментом) створюваного в Росії інформаційного суспільства.

Аналіз розгортання та функціонування Сі-стеми-112 у пілотних регіонах показав, що найбільш важливою в плані організації інформаційної взаємодії відомчих ДДС є підсистема прийому та обробки викликів (повідомлень про події), що надходять до єдиної чергово-диспет-черської служби. До складу зазначеної підсистеми входить центр обробки дзвінків (ЦОВ).

Підсистема прийому та обробки викликів, або так звана диспетчерська підсистема, є підсистемою, що управляє, в автоматизованій системі (АС) ЄДДС.

Нині можливі кілька програмно-технічних варіантів побудови цієї підсистеми з погляду організації міжвідомчої взаємодії.

Розглянемо два варіанти, що найчастіше зустрічаються.

Варіант 1

У ДДС екстрених служб (01, 02, 03 тощо) вже є свої відомчі диспетчерські системи.

У цьому випадку має створюватися спеціальне програмне забезпечення (СПО) з обробки викликів для ЦЗГ на базі ЄДДС та для ДДС екстреної оперативної служби, що територіально відповідає ЄДДС. На практиці це може бути реалізовано розміщенням у ДДС віддаленого клієнтського робочого місця із СПО ЦОВ ЄДДС додатково до відомчого

АРМ щодо прийому повідомлень про події або в кращому разі розробкою спеціального інтеграційного програмного модуля для забезпечення інформаційної взаємодії СПО ЦОВ ЄДДЗ із спеціальним програмним забезпеченням ДДС екстрених служб.

Позитивним у такому рішенні є те, що розгортання системи та впровадження її у ДДС відбувається без корінної ломки вже наявних відомчих автоматизованих засобів, які довели користувачам свою ефективність практичною експлуатацією.

Недоліки цього підходу визначаються безпосереднім способом реалізації. Так, наприклад, при розміщенні в ДДС екстреної служби додаткового клієнтського АРМ зі СПО ЦОВ ЄДДС оператору доведеться обробляти повідомлення, що надійшли лінією Системи-112 і відомчою системою, окремо. Для вирівнювання статистики в обох системах оператору доведеться вручну переносити інформацію з однієї в іншу, що не тільки не прискорює процес обробки повідомлень та реагування на них, але схиляє оператора у певному сенсі до «саботування» нової системи, віддаючи пріоритет роботі нехай і сучасної і менш функціональної, але знайомішою старої системі. Крім того, одним із завдань, що стоять перед Системою-112, є «гармонізація способу виклику екстрених оперативних служб із законодавством Європейського союзу», а відповідно до Європейських вимог у оператора має бути одне автоматизоване робоче місце(Одна клавіатура, миша і т. д.). Використання інтеграційних модулів є проблематичним з іншої причини. Простий підрахунок кількості ДДС потенційних об'єктів інтеграції показує, що на практиці в кращому разі доведеться інтегруватися з чотирма-шістьма АС у суб'єкті – служб 01, 02, 03, 04, служба реагування на НС (або ЦУКЗ), служба «Антитерор». При цьому в кожному суб'єкті можлива наявність АС, відмінних від АС у такій самій службі сусіднього регіону. Тобто ми маємо понад 250 потенційних об'єктів інтеграції. Крім того, аналіз наявності та стану автоматизованих систем у ДДС екстрених служб показує, що більшість ДДС не оснащені якими-небудь не те щоб диспетчерськими програмами, а навіть більш-менш сучасними інформаційно-довідковими або обліково-статистичними системами. Тому інтеграція викличе складнощі на програмному рівні. Для успішного поєднання систем розробникам необхідно відкрити один одному свої розробки, фахівцям у галузі безпеки інформації докласти додаткових зусиль щодо захисту своїх мереж та інформаційних ресурсів після інтеграції. Не сприяє ефективній роботі з інтеграції та позиція багатьох керівників служб, спрямована на певну відомчу ізольованість. За значних організаційних зусиль і безумовно великих витрат як фінансових, і ресурсів фахівців у сфері інформаційних технологій позитивний ефект від реалізованого рішення не очевидний.

Варіант 2

Як ми згадували вище, проведений аналіз показав, що у більшості випадків у відомствах взагалі відсутня автоматизована система, реєстрація повідомлень ведеться найчастіше в журналі, організація реагування та координація дій сил та засобів по телефону.

Також ми згадували вище про єдність основних алгоритмів та принципів при прийомі, обробці, реєстрації повідомлень про події, організацію реагування на них та управління підлеглими силами та засобами реагування у всіх ДДС оперативних служб незалежно від сфери їх призначення.

В цьому випадку найбільш раціональною є розробка певної єдиної автоматизованої системи, що автоматизує процеси оперативно-диспетчерського управління в кожній з ДДС окремо та ОСОДУ в цілому, та постановка її на постачання у всіх відомствах. Єдина система повинна забезпечувати принцип введення даних через одну програму лише один раз, дані повинні бути доступні для інших програм без їх копіювання. Всі дії оператора (диспетчера) в системі повинні автоматично фіксуватися в режимі реального часу зі збереженням інформації, ким ця дія була здійснена і коли таким чином, щоб подію та дії персоналу екстрених служб за ним можна було повністю відновити, у тому числі й для навчальних цілей.

При реалізації цього завдання також неминучі певні складнощі, пов'язані, з одного боку, з необхідністю розробки єдиної системи для кількох служб, за схожості принципів оперативно-диспетчерського управління об'єктивно мають таки власну специфіку. З іншого боку, суб'єктивна, спрямована на ізольованість позиція керівників та фахівців у цих відомствах та службах не значно відрізнятиметься від позиції при розробці інтеграційних модулів.

Однак у даному варіанті позитивні моменти є очевидними - кожне відомство отримує спеціалізований програмний продукт, розроблений за погодженням (або за участю) «під завдання» даного відомства; система управління в кризових ситуаціях суб'єкта отримує єдність програмної платформивсіх ДДС, ЄДДС та ЦУКБ, що дозволяє реалізувати єдині та узгоджені правила інформаційного обміну в системі РСНС. Крім того, з урахуванням аналізованих вище ролі та місці Системи-112 в ОСОДУ суб'єкта доцільна розробка АС у рамках саме цього проекту.

Кожен варіант має право існування і може бути реалізований у тому чи іншому суб'єкті.

Але, на наш погляд, кращим є другий варіант, який є більш складним у початковій стадії (при розробці єдиної АС), але згодом при тиражуванні системи в регіонах впроваджувальний ефект нівелює проблеми, що виникли при розробці.

Те, що Концепцією передбачено розгортання Системи-112 на базі саме ЄДДС муніципальних

утворень, що є органами повсякденного управління територіальної підсистеми РСЧС суб'єкта, видається вірним і виправданим. На сьогоднішній день ЄДДС мають легітимні повноваження щодо організації та здійснення повсякденного управління ДДС, у тому числі і екстрених оперативних служб (визначених Постановою Уряду РФ...), проте за фактом відсутня технічна основа для управління. З іншого боку, в Системі-112 така програмно-технічна основа закладена. Подібність більшості завдань і функцій також дозволяє розглядати Систему-112 з урахуванням ЄДДС муніципальних утворень як невід'ємну частину системи оперативно-диспетчерського управління з урахуванням органів повсякденного управління територіальної підсистеми РСЧС, т. е. з урахуванням ЄДДС. І централізація оперативно-диспетчерського управління усіма ДДС всіх взаємодіючих служб, а не лише оперативних на базі ЄДДС є ще одним аргументом на користь розробки типової автоматизованої системи об'єднаної системи оперативно-диспетчерського управління для суб'єкта.

Але при цьому слід не забувати, що Система-112 є складною інформаційно-комунікаційною системою, яка має стати певним сегментом створюваного інформаційного суспільства, що дозволяє населенню отримувати своєчасну, оперативну та кваліфіковану допомогу. А це неможливо без підготовки висококваліфікованого чергово-диспетчерського персоналу чи людського капіталу, який володіє сучасними інформаційними технологіями, та без створення належної інформаційно-комунікаційної інфраструктури в регіоні. В іншому випадку всі зусилля щодо впровадження системи-112 можуть бути зведені до купи закупленого так званого заліза, на якому будуть показувати все нові і нові презентації про систему-112, але яка так і не функціонуватиме на належному рівні.

література

1. Розпорядження Уряду РФ від 25 серпня 2008 р № 1240-р про схвалення Концепції створення Системи-112.

2. Наказ МНС Росії від 15.12.2008 р №779 «Про реалізацію розпорядження Уряду РФ від 25 серпня 2008 р № 1240-р.

3. Розпорядження Міністра від 27.10.2009 р. № 379 «Про створення робочої групи з розгортання системи забезпечення виклику екстрених оперативних служб через єдиний номер«112» з урахуванням ЄДДС муніципальних утворень Російської Федерації».

4. Наказ МНС Росії від 9.04.2009 р № 224 "Про відпрацювання методології розгортання та функціонування системи забезпечення виклику екстрених оперативних служб через єдиний номер "112" на базі ЄДДС муніципальних утворень у пілотних регіонах Російської Федерації".

5. Наказ МНС Росії від 1. 06.2009 р № 331 «Про міжвідомчу робочу групу для відпрацювання методології розгортання та функціонування системи забезпечення виклику екстрених оперативних служб через єдиний номер «112» на базі ЄДДС муніципальних утворень у пілотних регіонах.

6. Постанова Уряду РФ від 31 грудня 2004 р. № 894 «Про затвердження переліку екстрених оперативних служб, виклик яких цілодобово та безкоштовно зобов'язаний забезпечити оператор зв'язку, та про призначення єдиного номера виклику екстрених оперативних служб».

7. Рішення колегії МНС Росії від 29 серпня 2007 р № 7/1 «Про підготовку до розгортання на території Російської Федерації та системи виклику екстрених оперативних служб через єдиний номер «112».

9. ГОСТ Р22. 7.01-99 ЄДДС. Основні положення.

зубків Василь Миколайович, Головне управління МНС Росії по Курській області, начальник. агеїв Сергій Володимирович, к.т. н., ФГУ ВНДІ ГОЧС (ФЦ), провідний науковий співробітник. денисов Олег В'ячеславович, ЦФ ФГУ ВНДІ ГОНС (ФЦ), начальник.

тимінський Володимир Валентинович, ГУ «ЦУКС МНС Росії Курської області», начальник. акульшин Сергій Борисович, ГУ "ЦУКС МНС Росії по Курській області", спеціаліст.

Технологічний моніторинг процесів виробництва

Докладніше

Призначена для безперервного контролю над усіма параметрами технологічних процесів, що характеризують поточний стан виробництва, як реального часу. Об'єктами моніторингу є технологічні установки, резервуари, склади, вузли обліку, виробничі лінії та ін. Основне завдання технологічного моніторингу – максимально точно передавати стан усіх технологічних і виробничих процесів.

Планування та облік переміщення сировини та напівфабрикатів

Докладніше

Призначена для планування та обліку операцій переміщення сировини, напівфабрикатів та готових продуктів. У рамках вирішення завдання планування переміщення реалізується: інтеграція з підсистемами планування, приймання сировини та відвантаження готової продукції; розрахунок плану операцій переміщення; прогнозування стану резервуарних парків, складів; аналіз запланованих та фактично скоєних операцій руху нафти та нафтопродуктів. У рамках розв'язання задачі обліку переміщення реалізується: оперативний облік надходження сировини; оперативний облік напрямів та потоків передачі сировини, напівфабрикатів та готових продуктів; оперативний облік кількості сировини, напівфабрикатів та готових продуктів у резервуарних парках, на складах підприємства.

Контроль за дотриманням технологічних регламентів

Докладніше

Призначена для безперервного контролю за дотриманням норм технологічних регламентів ведення процесів з виробничих об'єктів. У підсистемі виконуються такі функції: завдання набору вручну та/або на основі архівних даних технологічних режимів для виділеного технологічного об'єкта; візуалізація та видача тривожних повідомлень; формування спеціалізованих звітів та зведень щодо порушень технологічних режимів.

Контроль стану технологічного обладнання

Докладніше

Призначена для безперервного моніторингу та прогнозування фактичного стану технологічного обладнання. Для цього підсистема дозволяє автоматизувати процеси: контролю роботи/простою обладнання; обліку та аналізу простоїв; обліку напрацювання обладнання; розрахунку ключових показників ефективності; інтеграції із спеціалізованими системами діагностики.

Контроль ключових показників

Докладніше

Призначена для розрахунку та контролю у реальному часі ключових показників фактичної роботи виробництва на основі даних щодо якості, технології та енергетики: оперативний контроль виконання виробничих планів; розрахунок у реальному часі техноекономічних показників за кожним процесом та об'єктом; глибокий аналіз виробничих процесів

Диспетчерська звітність провадження

Докладніше

Призначена для автоматизованого формування повного набору звітів, рапортів, зведень, що містять інформацію про стан виробничого процесу. Формування диспетчерської звітності проводиться з будь-якою дискретністю, всі звіти оновлюються протягом доби із зазначеною дискретністю. Приклади звітів: режимний лист; зведений звіт про роботу заводу; залишки по парках; зміна залишків за сировиною, напівфабрикатами, товаром; відхилення від плану; будь-які спеціалізовані звіти довільної форми.

Надіслати свою гарну роботу до бази знань просто. Використовуйте форму нижче

Студенти, аспіранти, молоді вчені, які використовують базу знань у своєму навчанні та роботі, будуть вам дуже вдячні.

Розміщено на http://www.allbest.ru/

[Введіть текст]

Вступ

Розробка ІС диспетчерської служби таксі провадиться на прикладі складеного каталогу диспетчерська служба таксі. Каталог покаже автомобілі, їхніх водіїв, клієнтів, дати замовлень, виконання замовлення, вартість замовлення, адреси замовлень.

1. Предметна область

Областю розгляду є діяльність диспетчерів служби таксі, які повинні:

Вести список клієнтів, у якому вводиться номер картки, прізвище та ім'я, домашню адресу та мобільний телефон.

Список автомобілів, у якому вводиться номер автомобіля, марка автомобіля, державний номер автомобіля, водій автомобіля.

Список замовлень, до якого вводиться код замовлення, дата замовлення, номер автомобіля, номер картки, сума замовлення, стан замовлення.

Список водіїв, у якому запроваджується прізвище водія, ім'я, стаж роботи.

2. Постановка задачі

Розробку моделей процесу наведено на прикладі створення бази даних «Диспетчерська служба таксі».

Моделювання елементів системи.

Діаграми IDEF0

Діаграми DFD

3. Концептуальні вимоги

Для проектування бази даних вибрано універсальний метод проектування ER-метод (метод “сутність-зв'язок”). При використанні цього методу необхідно, перш за все, створити ER-модель, що відображатиме зв'язки сутностей заданої предметної області. Далі, виходячи з ER-діаграми, будується бази даних.

Сутності - концептуальні вимоги, які необхідно врахувати під час розробки БД: каталоги клієнтів, замовлень, автомобілів, водіїв.

Нормалізація

Для створення бази даних необхідно розкрити сутності концептуальних вимог і нормалізувати їх. Нормалізація таблиці є послідовне зміна структури таблиці до того часу, поки вона задовольняти вимогам останньої форми нормалізації.

I нормальна форма

Таблиця знаходиться в першій нормальній формі тоді і тільки коли, коли жодне з полів не містить більше одного значення і будь-яке ключ. поле не порожнє.

Розкриваємо сутності концептуальних вимог:

Автомобілі (НомерАвто, МаркаАвто, ДержНомерАвто, Водій).

Клієнт (Номеркартки, Прізвище Ім'я, Домашній Адреса, Номер Телефону).

Замовлення (Код Замовлення, Дата Замовлення, Час Замовлення, Номер Авто, Номер Картки, Сума Замовлення, Стан Замовлення).

Водій (Прізвище, Ім'я, СтажРоботи).

II нормальна форма

Таблиця знаходиться у другій нормальній формі, якщо вона задовольняє вимогам першої нормальної форми і всі її поля, що не входять до первинного ключа, пов'язані повною функціональною залежністю з первинним ключем:

Таблиця 1 - Автомобіль

Таблиця 2 - Замовлення

Таблиця 3 - Клієнти

III нормальна форма

Таблиця знаходиться в третій нормальній формі, якщо вона задовольняє вимогам другої нормальної форми і жодне з її не ключових полів не залежить функціонально від будь-якого іншого не ключового поля:

Малюнок 3 - Таблиця Автомобіль

Малюнок 4 - Таблиця Замовлення

Малюнок 5 - Таблиця Клієнти

Малюнок 6 - Таблиця Водій

4. Структурна схема

З третьої нормальної форми створюємо структурну схему бази даних «Диспетчерська служба таксі».

створіння структурної схемибази даних.

Увійти до схеми даних: вкладка Робота з базами даних.

На панелі інструментів натисніть кнопку «Схема даних».

Малюнок 7

Вікно з переліком таблиць

Подвійним клацанням на ім'я таблиці додати таблиці на полі

Малюнок 8

Встановити зв'язок між таблицями

Малюнок 9

5. Порядок виконання роботи

Для початку створимо базу даних, натиснувши «Файл - Створити - Нова базаданих». Задаємо ім'я бази, місце збереження, клацаємо Створити.

Малюнок 10

Тепер задаємо структуру таблиць.

На закладці вибираємо режим «Конструктор».

Малюнок 11

Зберігаємо таблицю під вибраним ім'ям.

Малюнок 12

Створюємо таблицю у вікні конструктора.

Малюнок 13

6. Створення таблиць у режимі конструктора

Натиснути «Створити таблицю як конструктора».

Введіть ім'я поля.

Виберіть тип даних.

Поставити первинний ключ, клацнувши на кнопці «Ключ» на панелі інструментів, попередньо встановивши курсор на полі зліва від потрібного імені (ключове поле має знаходитися на першому місці списку полів).

Задати ім'я таблиці при закритті після введення всіх необхідних полів та їх типів.

Аналогічним способом побудовано таблиці:

Автомобіль.

Водiй.

Створення зв'язку між таблицями.

Клацніть на значку «Схема даних» на панелі інструментів, відкрити схему даних.

З додаткового вікна «Додати таблиці» виділити клацанням необхідні імена таблиць і клацнути по кнопці «Додати».

Об'єднати ключові поля таблиць: клацанням миші виділити в одній із таблиць поле, яке з'єднуватиметься в однойменному полі іншої таблиці, і, затиснувши мишу, перетягнути це поле на поле, що з'єднується. Відпустити мишу, при цьому відкриється вікно «Зміна зв'язків» із зазначенням полів, що з'єднуються, відповідних таблиць і тип зв'язку цих полів: «один-до-одного», «один-до-багатьом»:

При типі зв'язку один до одного ставимо прапорець в полі забезпечення цілісності даних і клацаємо кнопку ОК.

При типі зв'язку «один-багатьом».

Забезпечення цілісності даних.

Каскадне оновлення пов'язаних полів.

Каскадне видалення пов'язаних полів.

Натискаємо кнопку ОК.

В результаті маємо схему зв'язків між таблицями БД "Диспетчерська служба таксі".

7. Створення форм

Переходимо на вкладку Створення. Тиснемо на кнопку «Форма» на панелі зверху. Створюється форма заповнення. Зберігаємо форму під назвою «Форма введення». Зберігаємо. Тиснемо правою кнопкою миші за назвою форми та вибираємо «Режим форми». Або у вкладці «Створення» вибираємо «Майстер форм»:

8. Створення запитів

база дана таксі конструктор

Типи запитів:

Простий запит – створення запиту з певних полів.

Перехресний запит - створення запиту, що виводить дані у компактному форматі, подібному до формату електронної таблиці.

Записи, що повторюються - створення запиту на пошук повторюваних записів у простій таблиці або запиті.

Записи безпідлеглих - створення запиту на пошук записів, яким відповідає жодна запис у підпорядкованої таблиці.

Простий запит

На вкладці Створення групи Запити клацніть Майстер запитів.

Малюнок 14

У діалоговому вікні Новий запит виберіть Простий запит і натисніть кнопку ОК.

Малюнок 15

Малюнок 16

У групі Таблиці та запити виберіть таблицю, яка містить потрібні дані. Зверніть увагу на те, що як джерело даних можна використовувати інший запит. Після вибору таблиці поля відображаються в області Доступні поля.

9. Перехреснийзапит

На вкладці Створення в групі Інші клацніть Конструктор запитів.

Малюнок 17

У діалоговому вікні Додавання таблиці двічі клацніть кожну таблицю або запит, які потрібно використовувати як джерела записів.

Увімкніть поля, які ви бажаєте використовувати, до списку "Вибрані поля", а потім натисніть кнопку "Далі". Тепер слід задати критерій угруповання, який застосовується для поділу ваших рядків на стовпці

Увімкніть поля, які ви бажаєте використовувати, до списку "Вибрані поля", а потім натисніть кнопку "Далі". Тепер слід задати критерій угруповання, який використовується для поділу ваших рядків на стовпці. У цей момент можна вибрати поле.

Виберіть поле для угрупування стовпців і натисніть кнопку "Далі". На останньому кроці потрібно підібрати обчислення, яке хочете виконувати для отримання підсумків. Виберіть поле для обчислення, а потім виберіть функцію для підрахунку зведених даних.

10. Створення звітів

Щоб створити звіт, потрібно перейти на вкладку «Створення» і вибрати «Звіт»

Звіти можна створити за допомогою:

Конструктор звітів.

Майстри звітів.

І вручну.

У нашій базі даних звіт створюється майстром звітів. Потрібно натиснути на "майстер звітів". Відкриється вікно.

Малюнок 18

Переносимо доступні поля по одному, потрібно натиснути кнопку «>».

Щоб перенести всі поля, відразу потрібно натиснути кнопку «>>»

Малюнок 19

У наступному вікні можна розподілити рівні угруповання.

У наступному кроці можна вибрати вид макета звіту, а також вибрати орієнтацію книжкову або альбомну.

До звіту можна прикріпити наклейки. Також можна створити порожній звіт.

Наприкінці створення бази даних повинен бути створений загальний звіт, що включає всі поля.

Висновок

Розробка моделі процесу диспетчерська служба таксі зроблена на прикладі складання каталогу диспетчерська служба таксі

Каталог диспетчерська служба таксі показує автомобілі їхніх водіїв, клієнтів, дати замовлень, виконання замовлення, вартість замовлення, адреси замовлень.

Література

1. Гвоздєва В.А., Лаврентьєва І.Ю., основи побудови автоматизованих інформаційних систем – Москва, ВД Форум – ІНФРА – М, 2007. – 320с.

2. Фуфаєв Д.Е., Фуфаєв Д.Е. Розробка та експлуатація автоматизованих інформаційних систем – Москва, видавничий центр Академія, 2010. – 304с.

3. Гагаріна Л.Г., Кисельов Д.В., Є.Л. Федотова. Розробка та експлуатація автоматизованих інформаційних систем - Москва, ВД Форум - ІНФРА - М, 2009. -384с.

4. Дімов Ю.В. Метрологія, Стандартизація та Сертифікація – Пітер, 2005

5. Пирогов В.Ю. Інформаційні системи та бази даних: організація та проектування: навч. Посібник - СПБ.БВХ-Петербург, 2009. -528с.

6. Харитонова І.А., Міхєєва В.Д. MicrosoftAccess 2000 – СПБ. : БВХ-Петербург, 1999. - 1088с.

7. Максимов Н.В. та ін. Сучасні інформаційні технології. Підручник-М: "ФОРУМ": ІНФРА-М, 2011.

Розміщено на Allbest.ru

Подібні документи

    Створення таблиць бази даних як конструктора. Схема зв'язків між таблицями та зміст таблиць. Встановлення зв'язку з підтриманням цілісності. Структури двох запитів (у режимі конструктора) та опис процесу їх створення. Результати виведення звітів.

    курсова робота , доданий 28.06.2015

    Поняття основних компонентів бази даних Access. Таблиці, звіти, макроси та модулі, форма, запити до бази та їх види. Типи даних. Створення бази даних "Кадри". Створення таблиці як конструктора. Використання майстра підстановок для створення зв'язків.

    курсова робота , доданий 10.03.2016

    Створення бази даних у Microsoft Access за допомогою майстра шаблонів. Створення таблиць шляхом введення даних, за допомогою майстра таблиць або таблиці в режимі конструктора таблиць. Створення запитів у Microsoft Access за допомогою майстра або конструктора запитів.

    реферат, доданий 08.09.2010

    Створення таблиць бази даних за допомогою MS Access "Країни Азії". Форма бази даних та запити до вибірок даних. Модифікація структури таблиць, створення зв'язків між головними таблицями, редагування даних та проектування форм для реальної бази даних.

    контрольна робота , доданий 25.11.2012

    Створення таблиць бази даних як конструктора. Найменування та структура таблиць бази даних "Бібліотека". Застосування поля підстановок та створення фіксованого списку значень для полів. Схема зв'язку між таблицями. Формування та виконання запиту.

    контрольна робота , доданий 24.07.2009

    Поняття нормалізації таблиць бази даних та її мети. Етапи процесу нормалізації. Приклад ненормалізованих даних. Нормальні форми, яких наводяться таблиці. Реляційна алгебра над навчальною базою. База даних для предметної галузі "Навчальні посібники".

    контрольна робота , доданий 30.07.2010

    Розробка бази даних деканату магістратури, що включає інформація про студентів, форму навчання, іспити. Створення таблиць і запитів як конструктора, звіту з допомогою майстра звітів. Виведення даних за допомогою форм. Вкладки кнопкової форми.

    курсова робота , доданий 18.07.2014

    Автоматизація діяльності книгарні. Інформація про базу даних. Заповнення полів таблиць "Книги", "Покупець", "Постачальник", "Співробітники". Створення запиту як конструктора. Виведення даних за допомогою форм. Розробка програми СУБД MS Access.

    курсова робота , доданий 13.01.2015

    Створення бази даних, планування розробки та системні вимоги. Проектування бази даних у середовищі Microsoft Access, елементи та типи даних. Створення таблиці та використання конструктора для їх модернізації. Побудова запитів та створення макросів.

    курсова робота , доданий 16.04.2011

    Створення програм, що дозволяють створювати бази даних. Створення таблиці баз даних. Створення схеми даних. Створення форм, звітів, запитів. Збільшення обсягу та структурної складності даних, що зберігаються. Характеристика системи керування базою даних Access.

Система диспетчерського управління I-DS є базою для створення комплексної системи управління виробництвом, що інтегрує дані щодо технологічних процесів, енергоресурсів, якості, погоджених матеріальних балансів. I-DS – передове рішення, розроблене відповідно до сучасних тенденцій розвитку систем диспетчеризації виробничих процесів.

Сучасні інформаційні технології надають можливість на новому рівні організувати взаємодію виробничо-диспетчерських служб підприємства. Автоматизація диспетчерського контролю дозволяє створити оперативну системуоповіщення профільних служб підприємства, контролювати виконання диспетчерських вказівок, формувати верифіковані зведення про стан виробництва та компанії загалом за всіма територіально-розподіленими виробничими об'єктами.

Компанія «ІндаСофт» планомірно розробляє та вдосконалює рішення щодо автоматизації процесів управління виробничою діяльністю, максимально орієнтуючись на специфіку вітчизняних підприємств. Спеціалізований програмний продукт I-DS (I-Dispatch System), розроблений співробітниками компанії, є комплексним рішенням з автоматизації всіх складових процесу диспетчерського контролю та управління, включаючи:

  • технологічний моніторинг;
  • формування диспетчерської звітності;
  • ручне введення та управління даними;
  • керування подіями;
  • виробничий облік.

У жовтні 2016 року програмні продукти ЛІМС I-LDS та Система диспетчерського управління I-DS, розроблені компанією «ІндаСофт», включені до Єдиного реєстру російських програм для електронних обчислювальних машин та баз даних.

Реєстр створено відповідно до статті 12.1 Федерального закону«Про інформацію, інформаційні технології та захист інформації» з метою розширення використання російських програм для електронних обчислювальних машин і баз даних, підтвердження їх походження з Російської Федерації, а також з метою надання правовласникам програм для електронних обчислювальних машин або баз даних заходів державної підтримки. Реєстр містить відомості про все програмне забезпечення, яке офіційно визнано тим, що відбувається з Російської Федерації.

Технологічний моніторинг

Головним завданням автоматизації процесів технологічного моніторингу є забезпечення всіх служб підприємства оперативною інформацією стан виробництва. Для вирішення цього завдання I-DS автоматизує процеси збирання, обробки, зберігання даних, подання поточної, історичної та агрегованої інформації про перебіг технологічних процесів. Інтерфейс користувача налаштовується під потреби кожного фахівця і дозволяє здійснювати доступ як до типових затверджених форм відображення виробничої інформації, так і до динамічно формованих користувачем таблиць, трендів, мнемосхем і діаграм.

До складу I-DS входить набір розроблених фахівцями «ІндаСофт» шаблонів мнемографічного представлення виробничої інформації:

  • продуктові схеми підприємства;
  • аналіз виконання плану виробничими об'єктами;
  • запаси, залишки, незавершене виробництво;
  • якість сировини, напівфабрикатів та готової продукції;
  • схеми розподілу енергоресурсів;
  • ефективність використання енергоресурсів, стан обладнання та ін.

Диспетчерська звітність

Одним із найважливіших процесів в управлінні виробництвом є формування виробничої звітності. Звіти - найбільш поширені та формалізовані засоби, що застосовуються фахівцями підприємства для аналізу стану виробництва. Водночас звітність є універсальним засобом обміну інформацією між цехами, виробництвами та службами підприємства.

Програмне забезпечення I-DS повністю автоматизує процеси формування виробничих звітів на кожному рівні управління виробництвом: секційним, цеховим та загальнозаводським. При цьому до складу I-DS вже входять готові шаблони найпоширеніших звітів: "Режимний лист", "Робочий журнал оператора зміни", "Добове зведення по цеху", "Матеріальний баланс установки" і т.д.

Ручне введення та керування даними

Ручне введення даних, корегування та затвердження параметрів технологічного процесу, авторизація госпрозрахункових показників операторами та диспетчерами різного рівня є базовими процесами в диспетчеризації підприємства. Програмний продукт I-DS містить усі необхідні інструменти для організації АРМ операторів та диспетчерів на будь-якому рівні підприємства, призначені для ручного введення, коригування та затвердження даних.

У складі I-DS для формалізації алгоритмів введення та обробки даних використовуються спеціальні візуальні інструменти конфігурації робочих процесів (так звані workflow або блок-схеми). Дані засоби дозволяють наочно описати (вибудувати) та регламентувати процеси автоматизованого збору, ручного введення, коригування, затвердження та публікації обліково-звітних даних, які використовуються великою кількістю операторів технологічних об'єктів, диспетчерів виробничих служб. Опис стандартних процедур дозволяє оперативно проводити зазначені процеси, адаптуючи систему під зміни технології чи організації виробництва.

Управління подіями

Процеси управління виробництвом багато в чому мають подієвий характер. Диспетчери та оператори різних рівнів реєструють події: пуску/зупинки обладнання, зміни режиму, початку/закінчення операцій переміщення матеріалів, подій, позаштатних ситуацій, перевищення питомого споживання енергоресурсів, перевитрати сировини або реагентів тощо. I-DS в даному випадку автоматизує основні функції щодо виявлення подій, класифікації та реакції на них відповідно до виробничих інструкцій. При цьому I-DS забезпечує:

  • автоматичну ідентифікацію подій (перевищення меж параметрів, швидкості зміни параметрів) за заздалегідь описаними алгоритмами (наприклад, межам параметрів, що динамічно розраховується, та ін.).
  • автоматизоване формування диспетчерських команд з вищого рівня управління нижчестоящого та контроль їх виконання;
  • реєстрацію подій, позаштатних та аварійних ситуацій фахівцями підприємства та за необхідності оповіщення суміжних та вищих підрозділів відповідно до затверджених регламентів та інструкцій;
  • зберігання в єдиній базі всіх класів та видів подій по підприємству;
  • квітування, призначення та ведення генеалогії подій.

Інструменти оповіщення (SMS, e-mail, звукові тривоги), візуалізації на мнемосхемах, аналітика з історії подій дозволяють фахівцям підприємства бути впевненими, що вони не пропустять жодної події та оперативно зможуть ухвалити рішення про те, як реагувати на ту чи іншу ситуацію.

Контроль за дотриманням норм технічних регламентів

Регламенти дозволяють виробникам гарантувати якість товарної продукціїпри обмеження собівартості. На кожному підприємстві відповідно до посадовими обов'язкамиРізні підрозділи розробляють: стандарти на показники якості сировини, напівфабрикатів, товарної продукції, норми технологічних режимів, норми витрати сировини та реагентів, норми питомих витрат енергоресурсів. Безперервний і повномасштабний контроль усіх регламентів, норм і режимів можна проводити лише автоматизованим способом.

Автоматизація моніторингу відхилень показників процесів від регламентних норм надає можливість широкому колу користувачів відстежувати відхилення від технологічних, екологічних норм, нормативного рівня якості продукції, норм витрат енергоресурсів, матеріалів та реагентів. Також I-DS дозволяє користувачеві створювати індивідуальні норми процесів, що цікавлять, шаблони режимів повторюваних технологічних процесів, за якими система буде створювати групові або персональні події і тривоги. Накопичена історія подій дозволяє оперативно аналізувати поведінку контрольованих процесів, не витрачаючи час на пошук проблем трендів чи журналів.

Тривоги, що генеруються, про відхилення контрольованих параметрів від заданих значень у темпі з виробництвом розсилаються по всіх можливих каналах оповіщення. Для моніторингу та аналізу подій та тривог розроблено різні інструменти: списки з можливістю накладання фільтрів за параметрами та встановлення часових меж, дерево тривог, аналітичні звіти.

Диспетчерські журнали та завдання

Ефективність системи диспетчеризації великих територіально розподілених об'єктів залежить від організації взаємодії диспетчерів різного рівня та операторів технологічних об'єктів. Автоматизація ведення диспетчерських журналів, управління виконанням завдань знижують тимчасові витрати на комунікації між різними рівнями управління та ризики впливу людського фактора при передачі команд.

Диспетчерські завдання та записи в журналах є одним із видів виробничих подій, що обробляються за власними алгоритмами та конфігурованими робочими процесами, які дозволяють гнучко описати процеси реєстрації, визначення статусу завдання, угруповання у дерево завдань, протоколювання (ведення журналу). Стандартні інструменти роботи з подіями дозволяють зменшити тимчасові витрати диспетчерських служб на ведення журналів.

Робота з позаштатними та аварійними ситуаціями

Оперативне реагування на нештатні та аварійні ситуації, що виникають на виробництві, - одне з ключових завдань диспетчерських служб. Своєчасне виявлення неординарних подій та чітке дотримання регламентів та інструкцій є визначальним фактором оперативної локалізації та запобігання подальшого розвиткупозаштатних та аварійних ситуацій, небезпечних для персоналу та технологічного обладнання.

Автоматизація процесів роботи в позаштатних та аварійних ситуаціях:

  • забезпечує реєстрацію позаштатних ситуацій;
  • спрощує проведення класифікації, оцінки та визначення категорії важливості подій;
  • дозволяє здійснювати підтримку прийняття диспетчерських рішень у разі виникнення позаштатних та аварійних ситуацій;
  • забезпечує оповіщення відповідальних спеціалістів підприємства відповідно до затвердженого регламенту;
  • спрощує контроль розвитку позаштатних та аварійних ситуацій;
  • здійснює зберігання архіву подій для «розбору польотів» з можливістю застосування будь-якої необхідної документації у форматах *.pdf, *.doc, *.jpg та ін.

Розрахунок мас за ГОСТ

Достовірність та легітимність облікових даних щодо матеріальних та енергетичних потоків при розподіленій системі збору інформації від різних джерел визначає якість виробничого обліку. На будь-якому підприємстві стоїть завдання забезпечення єдності первинних вимірювань, а також мінімізації впливу «людського фактора» на розрахунок мас запасів, споживання сировини та енергоресурсів, вироблення напівфабрикатів та товарної продукції по кожному технологічному об'єкту та підприємству загалом. Основний підхід полягає у збиранні первинних вимірювань з рівня КВП та централізації розрахунків мас в єдиному сервері системи диспетчеризації - що забезпечує єдність вимірювань та швидку зміну алгоритмів обчислень при виході нових нормативних документів.

Фахівцями «ІндаСофт» розроблено та сертифіковано у складі загального рішення серверний модуль розрахунку мас I-DS/CM, призначений для побудови та виконання обчислювальних алгоритмів за ГОСТ, МІ та локальними для конкретних підприємств методиками. Таким чином, реалізується функція знаходження способу розрахунку (і власне розрахунку) необхідних масових та енергетичних величин деяких відомих параметрів (наприклад, тиск, перепад тиску, температура продукту, лабораторна щільність тощо) шляхом:

  • визначення методик і відповідних вхідних параметрів, за допомогою яких можна розрахувати вихідний параметр, що цікавить, для конкретного продукту;
  • завдання одиниць вимірів, у яких відбувається розрахунок та автоматичне перетворення величин усередині розрахунків, унікальних для підприємства;
  • перевірки розрахунків та правильності введення вихідних значень;
  • підтримки умовних розрахунків;
  • перевірки меж допустимих значень.

Система розрахунку мас дозволяє підключити додаткові модулі з розрахунковими методиками, розробленими фахівцями підприємства.

Облік руху матеріалів

Для ефективного управління матеріальними потоками та запасами підприємства необхідно в темпі з виробництвом здійснювати облік руху сировини, напівфабрикатів та готової продукції по всьому виробничому ланцюжку - що дозволяє забезпечити:

  • динамічний облік надходження сировини;
  • динамічний облік напрямів та потоків передачі сировини, напівфабрикатів та продуктів по підприємству;
  • динамічний облік кількості сировини, напівфабрикатів та продуктів у ємностях;
  • оперативний розрахунок наявності сировини та продуктів на виробництвах та залишків за ємностями;
  • розрахунок маси операцій переміщення матеріалів.

Залежно від рівня автоматизації резервуарних парків, складів тощо. інформація про виконання операцій руху сировини та продуктів (час початку та закінчення операції, об'єкт - джерело, об'єкт-приймач, маса) може вводитися автоматизованим способом або вручну. За наявності достатнього рівня автоматизації інформація про операції руху може формуватися автоматично.

Для автоматизації операцій обліку спеціальне рішення I-DS/MS надає оператору набір діалогових вікон для внесення значень параметрів, що характеризують стан резервуарів, та фіксації операції переміщення матеріалів резервуарами, складами, бункерами. У програмі використовується ряд алгоритмів, що забезпечують розрахунок мас операцій переміщення матеріалів у темпі виробництва. У рішенні реалізовано гнучку систему побудови звітності для операторів та диспетчерів підприємства.

Моніторинг роботи обладнання

До ряду завдань диспетчерського управління також входить завдання автоматизації процесів контролю стану основного та допоміжного обладнання, що безпосередньо впливає на виконання виробничої програми. Автоматизація процесу моніторингу роботи обладнання надає можливість здійснювати розгорнутий контроль за станом об'єктів шляхом:

  • публікації показників стану устаткування оперативного контролю стану одиниць/груп устаткування (підрозділів загалом);
  • використання як вихідні дані тривог, зауважень, напрацювань, план/фактів проведення ремонтів;
  • формування кожного з показників за окремим алгоритмом;
  • реалізації можливості зміни складу показників (зокрема зміна алгоритмів їхнього розрахунку).

Отримані значення показників роботи устаткування використовуються розрахунку показника його технічного стану - операційної готовності. Також реалізується автоматизований облік простоїв, що забезпечує:

  • діагностику виникнення елементарних простоїв, пов'язаних із повною зупинкою обладнання чи суттєвим зниженням продуктивності;
  • візуалізацію та сигналізацію виникнення елементарних простоїв на мнемосхемах;
  • реєстрацію простоїв за участю технологічного персоналу шляхом складання опису комплексного простою;
  • введення первинних причин виникнення зупинки обладнання;
  • передачу зареєстрованих фактів простоїв для аналізу ERP-систему або систему класу EAM.

Розрахунок ключових показників ефективності виробництва

Інформативність та достатність існуючої на підприємстві системи оцінки фінансових та виробничих показників безпосередньо впливають на якість управлінських рішень. Для оцінки результативності та ефективності роботи виробничих потужностей підприємства (технологічних установок, виробництв) та організаційних одиниць, задіяних у виробництві окремих підрозділів, активно використовуються ключові показники ефективності (KPI).

Одним із завдань автоматизованої системи диспетчеризації виробництва є формування оперативних та достовірних даних для інформаційного наповнення показників ефективності виробництва від рівня окремого технологічного об'єкта до рівня підприємства загалом.

ПО I-DS забезпечує автоматизацію процесу збору даних для розрахунку KPI, автоматизацію процесів розрахунку KPI та організацію єдиного інформаційного просторуз можливістю наочного подання KPI у вигляді бізнес-графіки та аналізу факторів впливу на показники.

Прикладка © 2022 Мобільні та комп'ютерні гаджети