Формально-алгоритмічна та програмна імплементація моделей кейсів даних про процес буріння Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.942

М.С. ЧЕСАНОВСЬКИЙ*

ФОРМАЛЬНО-АЛГОРИТМ1ЧНА ТА ПРОГРАМНА 1МПЛЕМЕНТАЦ1Я МОДЕЛЕЙ КЕЙС1В ДАНИХ ПРО ПРОЦЕС БУР1ННЯ

1 вано-Франювський нацюнальний техтчний утверситет нафти 1 газу, м. 1вано-Франювськ, Украша_

Анотаця. Проанал1зовано доцтътстъ та перспективи г^бридизацИ кейс-базованих м1ркуванъ та спецификаций тформацтно-пошукових задач на основ! обмеженъ. Узагалънено резулътати форма-лъно-алгоритм!чног гмплементацИ моделей кейав даних про процес бургння шляхом моделювання в!дпов!дних типових кейав. Показано, що кейс е певного роду екземпляром для процесу ршення технолог1чног проблеми, що виникае у процес бур1ння. Видыено два основних компоненти кейсу: власне опис проблеми та ршення поточног технолог1чног проблеми як таког. В резулътат1 пропо-нована методолог1я максималъно опираетъся на попередмй досв1д ттелектуалъног системи у форм1 вже вир1шених успшних кейав, з яких формуетъся можливий наб1р релевантних контро-лъованих параметр1в технолог1чного процесу в1дпов1дно. В той же час, весъ процес модифтацт-ног адаптацп кейав пропонуетъся розглядати як процес ршення тформацтно-пошукових задач 7з накладеними обмеженнями, що дае можлив1стъ розвинути доситъ ефективну методолог1ю, яка може бути поширена на цыий ряд предметних областей. За допомогою релевантност1 кейсу в заданий момент часу можливо встановлювати меж1, при яких необх1дно пов1домляти операторам про в1дпов1дтстъ отриманих значенъ до оч1куваних у кейа. Це мае сенс у режим7 реалъного часу при накладанм кейав, якг отримали пов1домлення про небезпеку або некоректм налаштуван-ня буровог установки, що може призвести до надм1рного зношення, зупинки чи виведення з ладу буровог. Проведене тестування системи тдтвердило устштстъ функщонування спроектованого тформацтного ттелектуалъного ршення на множим фактичних даних про процес буртня наф-тових та газових свердловин.

Ключов1 слова: кейс-базоват м1ркування, тформацтно-пошуков1 задач1 на основ7 обмеженъ, тех-нолог!чт проблеми, релевантнгстъ, ршення кейсу, бургння свердловин, 7нтелектуалъна система.

Аннотация. Проанализированы целесообразностъ и перспективы гибридизации кейс-базированных размышлений и спецификаций информационно-поисковых задач на основе ограничений. Обобщены резулътаты формалъно-алгоритмической имплементации моделей кейсов данных о процессе бурения путем моделирования соответствующих типовых кейсов. Показано, что кейс является своего рода экземпляром для процесса решения технологической проблемы, возникающей в процессе бурения. Выделены два основных компонента кейса: собственно описание проблемы и решения текущей технологической проблемы как таковой. В резулътате предлагаемая методология максималъно опирается на предыдущий опыт интеллектуалъной системы в форме уже решенных успешных кейсов, из которых формируется возможный набор релевантных контролируемых параметров технологического процесса соответственно. В то же время, весъ процесс моди-фикационной адаптации кейсов предлагается рассматриватъ как процесс решения информационно-поисковых задач с наложенными ограничениями, что дает возможностъ развитъ достаточно эффективную методологию, которая может бытъ распространена на целый ряд предметных. С помощъю релевантности кейса в заданный момент времени возможно устанавливатъ границы, при которых необходимо сообщатъ операторам о соответствии полученных значений, ожидаемых в кейсе. Это имеет смысл в режиме реалъного времени при наложении кейсов, которые получают сообщение об опасности, или некорректные настройки буровой установки, что может привести к чрезмерному износу, остановке или выводу из строя буровой. Проведенное тестирование системы подтвердило успешностъ функционирования спроектированного информационного интеллектуалъного решения на множестве фактических данных о процессе бурения нефтяных и газовых скважин.

Ключевые слова: кейс-базированные рассуждения, информационно-поисковые задачи на основе ограничений, технологические проблемы, релевантностъ, решение кейса, бурение скважин, интел-лектуалъная система.

© Чесановський М.С., 2018

1028-9763. Математичш машини 1 системи, 2018, № 4

Abstract. The expediency and prospects of hybridization of case-based considerations and specifications of information-search constraints based problems are analyzed. The results of the formal-algorithmic implementation of case data models on the drilling process by simulating the corresponding typical cases are generalized. It is shown that the case is a kind of instance for the process of solving a technological problem that occurs during the drilling process. There are two main components of the case - the actual description of the problem and the solution of the current technological problem as such. As a result, the proposed methodology is based as much as possible on previous experience of the intellectual system in the form of already solved successful cases from which a possible set of relevant controllable parameters of the technological process is formed, respectively. At the same time, the whole process of modifying adaptation of cases is proposed to be regarded as a process of solving information retrieval problems with imposed constraints, which makes it possible to develop a very effective methodology that can be extended to a number of subject areas. With the help of relevance of the case at a given time point it is possible to set limits on which it is necessary to inform operators about the correspondence of the received values to the expected in the case. It makes sense in real-time when applying cases that have reports of danger or incorrect drilling rig settings, which can lead to excessive wear, stopping, or malfunctioning of the drilling rig. The conducted testing of the system has confirmed the success of the operation of the designed information intelligent decision on the set of actual data on the process of drilling of oil and gas wells. Keywords: case-based considerations, constraints based problems, technological problems, relevance, case handling, well drilling, intellectual system.

1. Вступ

Кейс-базоваш MipKyBaHra ^ркування на 0CH0Bi прецедешив вщповщно) [1-6] е одшею i3 найбшьш просунутих техшк у штучному штелекп, оскшьки дозволяе ефективно поеднати типи базових концепцш у штучному штелекп (методи мiркyвання i методи машинного навчання для виршення проблем), базуючись на попередньому досввд в формi кейав-прецеденпв-випадюв. Виходячи i3 задано! проблеми (технолопчно! проблеми в области буршня нафтових i газових свердловин [7-8]), методологию мiркyвання (розмiрковyвання) слщ вщповщно застосовувати для того, щоб видобути минyлi схожi кейси з метою повторного або модифшованого застосування виршення проблем, що в них закладено. Як тшьки ршення буде знайдено, то можна застосувати вщповщш методи машинного навчання для покращання знань системи, базованих на прецедентно-кейсовому експертному досввд систем: з програмно-прагматично! точки зору слщ приеднати до баз-кейсiв новий кейс, а до баз знань новий експертний досвщ.

Розвиток технологий за принципом швидкого розроблення застосувань накладае свш вiдбиток, безумовно, i на дослщжувану проблему, що вимагае створення методологий для ефективного дослiдження простору ршень та вiдповiдного вибору ршення з най-меншою вартiстю та найбшьшою ефективнiстю, покращеною фyнкцiональнiстю, i якiстю застосування як такого. Поставлена задача мае значний простир виршення. Проте, безумовно, комплектнiсть проблеми е суттевим бар'ером для ii вирiшення. Поява саме класу пев-них систем, систем на основi знань дае можливiсть використання саме минулого досвщу для побудови нових ефективних рiшень. Тому серед пiдходiв менеджменту знань слiд ви-дшяти саме ефективнiсть пiдходy кейс-базованих мiркyвань (КБМ) та шформацшно-пошукових задач на основi обмежень (1ПО) (Constraints satisfaction problem - CSP, вщповь дно) [9-10], !х можливому поеднанш та спiльнiй гiбриднiй iмплементащi, що визначае за-гальний фреймворк представленого дослщження, метою якого е формально-алгоршмчна та програмна iмплементацiя моделей кейав даних про процес бyрiння, що дасть можли-вiсть надавати рекомендацп операторам технологiчного процесу у чаа, наближеному до реального, без необхщности ручного введення значень контрольованих параметрiв.

2. Основна частина

Кожен кейс представляв вщповщно опис деяко! минуло! проблемы TI'"' i вщповщного асощйованого р1шення минуло! проблемы TPsrc.Sol —» Solsrc. На ochobí введених характеристик надшност та метрично! вiдстанi найбiльш схож кейси можуть бути видобут з необ-хщною адаптащею при вщповщнш потреб^ що буде розглядатися як вщповщне р1шення для ново! проблеми 7 '1)S,C. Sol —» Solsrc. Суть ново! проблеми полягае у формуванш модел1 знань через визначену кшыасть 3míhhhx (параметр! в, технологичного процесу): Mi(KB.TP) = {{V}, {V}, ...,{Vn}}j j m, тобто виражатимемо модель знань через вид предста-

влення для бази знань. Базуючись на такш основi (змiннi - параметри), можна також легко переходити вщ piBra даних до рiвня знань, що вже е задачею концептуального piBra, яка проте початково може мати просте виршення, якщо виходити з того, що база даних - це сукупшсть iнiцiалiзованих паpаметpiв, що спостеpiгаються (або контролюються вщповщно) на входi i виходi технологiчного процесу TPm, TPout. Вщповщно, можемо розглядати представления виду АВ = {р1 =vi,---,pnl=vnl,pl = v, 2 =vn2¡ для бази даних тех-

нолопчного процесу ТРт ■ АВ та вщповщно представления через стршку для бази знань

Тобто, в найбiльш загальному випадку кейс представлятиметься деяким кортежем виду (TP,Sol,Out Tp, де ТР, власне, технология проблеми, Sol - 11' очшуване piшення, OutTp - очшуваш результати. Проте таке представлення не може претендувати на повну вичерпшсть щодо складових компонент кейсу. Наприклад, за аналопею з експертними системами можна також включати константу пояснень, що дасть змогу пщсилити складову зворотного зв'язку з Тентом.

У загальному випадку сутшсть пропоновано! методологи така:

1. Видобування початкового первинного набору обмежень (обов'язкового), що за-довольняе кейс:

C**t\=TP.Casemw

set |

2. Видшення початкового набору паpаметpiв, пiдстановки яких покриватиме набip щльових обмежень:

3. Виpiшити накладеш обмеження за допомогою солвера:

Solve(CStrg) Кр;"',..pf ) |=CStrg }.

4. Визначити ютиншсть для стану надобмеженосп (недообмеженостi) системи (ви-падок, коли накладено надто багато (надто мало) обмежень i, вщповщно, через це немае ршення (юнуе надто багато ршень)):

{,Sol.#(CS'rg) « #[CS**]} -> RclaxK '.V"" |.

{,Sol.#(CS'rg) » #[CS'rg ]} -> RcstrictK 'V"" |.

5. Пеpевipити iстиннiсть стану, для якого юнуе piвно одне piшення:

# p[TP.State\Sol = mm{Solve[CStrg\).

#

6. Якщо система е надообмеженою (недообмеженою) вiдповiдно, то слiд повторити реструктуризащю початкового набору паpаметpiв:

ifZZ {(CStrs)} Reshuffle0" {p?"CSet, p^CSet}.

7. Вивести рiшення для експерта. Якщо ршення задовольнятиме експерта та пере-ходитиме до завершення 3i збереженням вибраного методу адаптацп та отриманого ршен-ня вiдповiдно:

if {pfCSets°lpskolCSef°l}.{CSetxk°lCSetks°l} |=sd {CStrg},

де sd = CF, де CF - стушнь впевненосп експерта в видшеному сташ {TP.State:CStrs}.

8. Якщо ршення не задовольнятиме експерта, то тодi слщ змiнити метод адаптацп шляхом модифшацп пiдстановки i перейти до кроку 3.

if sd о CF -» Reshuffle"5' {{pf .CSet,Г', ■ ■ ■,pfCSetso1}), де I < к.

9. Зберегти нове рiшення та використаний метод адаптацп у випадку ix достатностi релевантности (задаючи ступiнь релевантностi як тако1).

rd({pf .CSet^, • • -,pfCSetkso1}, '/'/'.State. CS"*),

if rd -> 1, CBase. { {pf CSetf, • • •, pfCSetkso1}, TP. State. CS**, Reshuffle0"'^()}.

Такий пiдxiд, на вiдмiну вщ стандартно': монол^но': арxiтектури, дозволить розроб-ляти, впроваджувати та масштабувати тдсистеми незалежно одна вiд одно':.

Переваги такого тдходу:

1. Дае можливють розвивати кожну частину рiшення паралельно, невеликими командами.

2. Кожен такий сервю можна розгортати незалежно. Якщо одна частина системи вже готова до впровадження, то немае потреби затримувати ii, якщо iншi сервюи ще на стади розробки. Це дае можливiсть доставки рiшення швидше.

3. Масштабованiсть. Кожен iз сервiсiв можна запускати в багатьох примiрникаx. Якщо е навантаження тiльки на деяю сервiси, то можна саме цей розмножити i горизонтально масштабувати.

4. Сервюи, якi вiдповiдають тiльки за одну частину, е бшьш простим ршенням, нiж загальна монолiтна система. Якщо конкретний сервю перестае задовольняти конкретним вимогам, його можна викинути чи переписати заново. Це не буде настшьки складним i дорогим, якщо б змши потрiбно було вносити в монол^, особливо, якщо необхщно змши-ти цiлий тдхщ.

5. Можливiсть застосовувати рiзнi технологи. Стандартизацiя повинна бути, але якщо е достатньо тдстав помiняти технологш, то можна це зробити як частково, так i по-внютю. При цьому не потрiбно робити такий перехщ вiдразу, а можна роздшити це на де-кшька iтерацiй.

Таким чином, розроблене ршення було роздiлено на ряд тдсистем (сервiсiв).

1. AdapterService - кожен екземпляр даного сервюу пiдлаштовуеться тд конкретне джерело(давач, панель управлiння тощо) для отримання значень параметрiв.

2. ParameterService - вiдповiдае за управлшня параметрами та збереження значень параметрiв.

3. CaseService - вiдповiдае за управлшня кейсами.

4. CaseResolverService - виконуе резолвшг кейсiв за заданими критерiями, а також зберiгае результати виконання резолвшпв.

5. NotificationService - вщповщае за доставку повiдомлень на сторонш ресурси для iнформування персоналу про виникнення позаштатних ситуацiй.

6. CaseManagementPortal - Be6-0pieHT0BaHHñ nopTa.n g.ra MeHeg^MeHTy napaMeTpiB Ta KeñciB, a TaKo^, pe30.raiHry KeñciB y pynHOMy pe^HMi, ^o Mo^e BHKopHcToByBaTHcb onepaTo-paMH.

7. IdentityService - cepBic g.ra aBToproa^ï Ta ayTeHTH^iKa^ï, no6ygoBaHHñ 3a TexHo-.noriero, npH BHKopHCTaHHi akoi KopHCTyBan nepexogHTb Big ogHoro cepBicy go ÎHmoro.

KpiM Toro, IdentityServer e pea.ni3a^ero TexHo^oriï Single SignOn g.ra npoeKTiB Ha 6a3i ASP.NET Core. 3a gonoMororo ^eï TexHo^oriï 6y.no pea.ni30BaH0 Mo^^HBicTb B3aeMogiï mí^ pi3HHMH nacTHHaMH CHCTeMH 6e3 noTpe6H noBTopHoï aBToproa^ï, $aKTHHH0, ogHH Ac-cessToken BHK0pHcT0ByeTbca g.ra Bcix nigcHCTeM. 3ara^bHa apxiTeKTypa po3po6.neHoro pimeH-ha Mae BHra^g:

Central Architecture

Driling unit 1 . . n

Third-party sources

Adapter 1

Adapter 2

Adapter 3

Adapter 4

CaseBasedSystem project

ParameterService

Web API

DependencyService

Web API

CaseService

Web API_

CaseResolverService

Web API

I-^ Pu

Cas eM anegementPorta l ASP.NET MVC_

PushNotificationServ

ParametersDB (NoSQL)

CasesDB (NoSQL)

ResultsDB (NoSQL)

PortalDB (SQL)

Sensor 1

Sensor 2

Depe ndenci esDB (Graph NoSQL)

Sensor 3

ashbord

PucyHoK 1 - 3ara^bHa apxiTeKTypa po3po6neHoro pimeHHa

AdapterService

Пpoцec 36opy gaHHx BHMarae K0HKpeTH0ï cTaHgapTH3a^ï BxigHHx 3HaneHb napaMeTpiB, mi 6ygyTb 36epiraTHc^ b 6a3i gaHHx. Btím, gaHi 3 gaBaniB e pi3H0TunHHMH, ^o BHMarae aganTa^ï цнx n0T0KiB 3HaneHb napaMeTpiB nepeg gocTaBKoro ïx y cHcTeMy. CaMe T0My 6y.no p03p06^eH0 KoH^mya^bHy apxiTeKTypy g.ra pimeHH^ npo6^eMH aganTa^ï gaHHx. 3ara^bHa apxiTeKTypa цboro pimeHH^ Mae BHraag:

PncyH0K 2 - 3ara^bHa apxiTeKTypa cepBicy «aganTep»

Кожен давач повертае свш формат даних, саме тому необхщно, щоб для кожного виду давача повинна бути розроблена своя реалiзацiя загального абстрактного класу Pa-rameterCollector з перевизначеним методом GetValue(). Тодi це дасть можливють зчитувати та конвертувати значення параметрiв в единий формат перед вщправкою ix на ParameterService.

Арх^ектура даного рiшення представлена абстрактною, оскшьки конкретна реаль зацiя кожного адаптера може бути виконана в будь-якш формi програмного рiшення. Таким чином, дане ршення може бути розроблене на рiзних мовах програмування i бути представлене як консольне, веб- або мобшьне ршення залежно вiд потреб i можливостей середовища, в якому йому необхщно буде виконуватися. На базi ще'1' концепцп було роз-роблено консольне ршення для адаптацп даних, отриманих iз давачiв, та веб-рiшення для адаптацп даних, отриманих з пульта управлшня буровим процесом.

ParameterCollectorFactory розроблений за шаблоном проектування «абстрактна фабрика», що забезпечуе шкапсулящю окремих давачiв пiд единим iнтерфейсом, упускаючи ix реалiзацiю.

Кожна реалiзацiя цього штерфейсу матиме власний тип та реалiзацiю методу Get-Value(). Вхщний параметр dataDictionary може бути використаний для передачi необxiдниx вxiдниx даних, наприклад, ключiв доступу.

Клас AdapterContext мiстить необxiдний набiр даних для збору та вщправки даних.

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

ParameterService було розроблено як ASP.NET Web API ршення, що забезпечува-тиме отримання даних iз рiзниx джерел по HTTP-протоколу. Шзшше було додано реалiза-цiю для взаемодп мiж сервiсами через штеграцшну шину даних (ESB), реалiзовану на базi RabbitMQ. Це дозволяе забезпечити неявну взаемодш мiж сервiсами. Таким чином, зберь гаеться можливiсть масштабування сервiсу незалежно вiд iншиx сервiсiв.

Обов'язками даного сервiсу е:

- збереження миттевих значень параметрiв;

- витягування значень для заданих параметрiв з додатковими часовими фiльтрами;

- створення, редагування, видалення та витягування параметрiв.

Створення кейав е важливою складовою системи, але при цьому це не е постшно навантажуваною частиною системи. Таким чином, винесення ща частини в окремий сер-вiс дозволить вiддiлити i використовувати проект вщповщно до потреб. Для збереження кейав вибрано SQL-базу даних, оскшьки на даний момент це повнютю покривае вимоги швидкоди за умови дотримання основних принцитв нормалiзацii та iндексування SQL-баз даних.

Сервiс розроблено як ASP.NET Web API з застосуванням арх^ектурного стилю

REST.

Обов'язками даного сервюу е створення, редагування, видалення та витягування

кейав.

Зважаючи на те, що рекомендацшш повiдомлення повинш вiдправлятись на панель управлiння як тшьки вони створюються, то необхщним було створення сервiсу, який вщ-повiдав би за вiдправку повщомлень на рiзнi пристро'1' за вимогою. Для даного ршення було вибрано server push технологию, реалiзовану за допомогою Notification Hub service, розробленим компашею Microsoft, який дозволяе вщправляти повщомлення з сервера на iншi платформи.

Процес вiдправки повiдомлень складаеться з двох етатв:

1. Пристрш рееструеться на отримування push-повщомлень.

2. Вiдправка повiдомлень на пщписаш пристро!.

Крiм того, сервiс мае можливють вiдправляти електроннi листи на вибiрку адрес як альтернативу push-повщомленням.

Однiею Ï3 найзавантаженiших частин системи е CaseResolverService, яка вiдповiдае за виконання кейав на вимогу оператора або в автономному режимi за наявносп вщповщ-них конфiгурацiй системи. Причина високого навантаження е та, що для адекватно! роботи кейав необхщно опрацьовувати великий об'ем миттевих значень.

Сам процес обробки одного кейса складаеться з трьох базових дш:

1. Попередня обробка даних (pre-actions).

2. Виршення основно! задачi кейсу для отримання вихiдного результату (action).

3. Обробка вихщного результату та формування рекомендацшного висновку (postactions).

Програмна реалiзацiя CaseResolver-а вiдбуваеться з застосуванням CaseContext кла-су, що описуе одиничний процес резолвшгу.

Попередня обробка даних - це не обов'язковий крок, але необхщний, якщо е потреба в пщготовщ значень перед виршенням основно! задач^ наприклад, змша одиниць вимь рювання значень параметра.

Обробка вихiдного результату необхщна для формування зрозумiлого повщомлення на основi вихiдних параметрiв.

Вхщний параметр CaseArgs мае необхiдний набiр параметрiв, щоб запустити процес виршення кейсу. Цей аргумент використовуеться для створення CaseContext класу, який передаватиметься.

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

В основi розроблено! системи сто!ть обробка параметрiв, яю описують певну влас-тивiсть чи стан об'екта або явища. Враховуючи, що параметр може описувати рiзнi стани, властивостi чи явища, було виршено розробити окрему сутнiсть Parameter, яка б описува-ла будь-який параметр iз заданим дiапазоном значень.

Було видшено два типи параметрiв: числовий та текстовий.

Числовий тип параметрiв мае заданий дiапазон значень у виглядi мiнiмального(min) i максимального(max) значень, а також додаткового параметра крок(step), який по замов-чуванню приймае значення одиницi (1). Таким чином, встановлеш межi описують можливi дiапазони значень для кожного числового параметра.

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

Кожен параметр повинен належати до певно! категорп параметрiв. Загалом видшя-ються такi категорп: динамiчно керованi, статично кероваш, збурюючi та вихiднi.

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

В окремому вiкнi можна переглянути вс створенi параметри з описом.

База даних кейав представляе собою колекщю, кожен елемент яко! описуе певний випадок за допомогою очiкуваних вхiдних та вихiдних параметрiв. При цьому для створення кейсу важливим е тшьки опис параметрiв, а не !х конкретних значень.

PncyHoK 3 - BÍKHO пepeглядy пapaмeтpiв

PncyHoK 4 - BÍKHO пepeглядy кeйciв

Ha pиcyнкy пpeдcтaвлeнo двa випaдки, кoжeн з яких oпиcye двa нaбopи дaниx: вxi-дш (dcp, ucp, tcp) тa вихщш (ocp). Пpи цьoмy для кoжнoгo кeйcy кoжeн пapaмeтp мoжe пpиймaти звyжeний дiaпaзoн знaчeнь y мeжax cвoгo глoбaльнoгo дiaпaзoнy, oпиcaнoгo ^и cтвopeннi пapaмeтpa.

Ha pиcyнкy пpeдcтaвлeнo вiкнo cтвopeння нoвoгo кeйcy з двoмa вxiдними тa oдним вихщним пapaмeтpoм. Koжeн пapaмeтp мae зaдaний пiддiaпaзoн знaчeнь y мeжax глoбaль-нoгo дiaпaзoнy.

Ствopeнi кeйcи мoжyть 6ути викopиcтaнi в вiкнi Case Resolver для знaxoджeння cпiвпaдiнь пo зaдaнoмy дiaпaзoнy.

Рeлeвaнтнicть кeйciв e вaжливoю cклaдoвoю cиcтeми, щo зaбeзпeчyeтьcя шляxoм нaклaдaння Ha кeйcи вeликиx oб'eмiв oтpимaниx знaчeнь y ^o^ci бypiння з piзниx бypo-виx кoмплeкciв.

Haклaдaння вiдбyвaeтьcя шляxoм пopiвняння oтpимaниx знaчeнь iз вxiдними тa ви-xiдними знaчeннями кoжнoгo Ke^y для вcтaнoвлeння piвня вiдпoвiднocтi oтpимaниx зм-чeнь y пpoцeci бypiння з oчiкyвaними знaчeннями, oпиcaними в кoжнoмy кeйci. Рeзyльтa-тoм нaклaдaння e oтpимaнe вiдcoткoвe знaчeння peлeвaнтнocтi дaнoгo кeйcy для пoтoчнoï бypoвoï ycтaнoвки в пeвний мoмeнт чacy.

Пpи цьoмy peлeвaнтнicть кeйcy вiднocнo бypoвoï ycтaнoвки oпиcyeтьcя як cepeднe вiдcoткoвe знaчeння вcix нaклaдaнь Ke^y.

Тaким чинoм, кoжeн кeйc мae нaбip peлeвaнтнocтeй для кoжнoï ycтaнoвки, щo дae мoжливicть oцiнювaти якють кeйcy, a тaкoж пpoвoдити пoшyк кeйciв зa peлeвaнтнicтю в бaзi знaнь.

Ha pиcyнкy кoжeн pядoк пpeдcтaвляe нaбip знaчeнь piзниx пapaмeтpiв, oтpимaниx зa oдин дeнь.

Тaким чинoм, пicля нaклaдaння дaнoгo Ke^y дo кoжнoгo чacoвoгo пepioдy oтpимa-ho peзyльтaт, зoбpaжeний Ha p^. 5.

Дата Релевантшсть, % Опис

2018-06-06 12:00:00 100

2018-06-07 12:00:00 95 Оскшьки LUBiiflKicTb обертання перевищус оч1кувану

2018-06-08 12:00:00 15 Порода ¡нша, швццкють нилма i результат нижчий очгуваного

2018-06-09 12:00:00 78 Оскшьки швидккть обертання суттево перевищус очкуване значения. Результат bmll|iiî н1жоч1куваний

Середне значения 72

Рисунок 5 - Релевантшсть кейсу для р1зних часових перюд1в

Отже, для вибрано'1 бурово'1 релевантнiсть даного кейсу становить 72%, що може бути використано тд час пошуку кейав iз виведенням за релевантнiстю.

Також, за допомогою релевантностi кейсу в заданий момент часу можливо встанов-лювати межi, за яких необхщно повщомляти операторам про вiдповiднiсть отриманих значень до очшуваних у кейсг Це мае сенс у режимi реального часу при накладанн кейсiв, якi мають повiдомлення про небезпеку або некоректн налаштування бурово'1 установки, що може призвести до надмiрного зношення, зупинки чи виведення з ладу бурово'1.

Враховуючи той факт, що щеальш спiвпадiння тд час пошуку зустрiчаються надто рщко, було розглянуто пошук наближення шуканого результату(ER, expected result) до фактичних дiапазонiв значень (AR, actual result), описаних у кейсах.

Пошук ствпадшь та визначення наближеностi шуканого результату до фактичного для числових титв параметрiв описуеться за одним з 6 сценарпв поведiнки:

1. Дiапазон значень ER входить у дiапазон значень AR. Це вiдбуваеться, якщо дiа-пазон значень ER повнютю входить у дiапазон AR. У такому випадку можна говорити про повне ствпадшня шуканого результату для вибраного кейсу.

1 2 3 4 5 6 7 8

ERfliana30H ARfliana30H

Сценарш, коли дiапазон значень ER входить у дiапазон значень AR

2. Дiапазон значень AR входить у дiапазон значень ER. У такому випадку можна говорити про частковий результат, де необхщно вирахувати, який вщсоток AR входить у дiапазон значень ER.

1 2 3 4 5 6 7 8

ERfliana30H О ARfliana30H

Сценарш, коли дiапазон значень AR входить у дiапазон значень ER

3. Часткове ствпадшня, де ER злiва, описуеться як часткове перетинання крайтх правих значень ER вщносно крайтх лiвих значень AR.

1 2 3 4 5 6 7 8

ERfliana30H О ARfliana30H

4. Часткове ствпадшня, де ER справа, описуеться як часткове перетинання крайтх лiвих значень ER вщносно крайтх правих значень AR.

1 2 3 4 5 6 7 8

ERfliana30H □ ARfliana30H

5. Немае ствпадшь, де ER злiва. У даному сценарп релевантнiсть параметра визна-чаеться як вiдсоткове наближення крайнiх правих значень ER вщносно крайнiх лiвих зна-чень AR.

1 2 3 4 5 6 7 8

ERfliana30H ARfliana30H

6. Немае ствпадшь, де ER справа. Визначаеться як вщсоткове наближення крайтх лiвих значень ER вiдносно крайнiх правих значень AR.

1 2 3 4 5 6 7 8

ERfliana30H □ AR д1апазон

Для текстових дiапазонiв значень повним ствпадшня вважаеться тiльки тод^ коли всi значення ER входять у дiапазон значень AR, а частковим - якщо тiльки частина значень дiапазону ER входить у дiапазон значень AR. При цьому вщсоткове значення вираховуеть-ся пропорцшно вiдносно кiлькостi спiвпадiнь до загального розмiру дiапазону значень ER.

Програмна реалiзацiя кожного сценарiю представлена реалiзацiею iнтерфейсу IRelevantResolver, лiстинг якого представлено нижче:

public interface IRelevantResolver {

/// <summary>

/// Used to specify the ParameterType of the scenario /// </summary>

ParameterType ParameterType { get; } /// <summary>

/// Used to describe scenario /// </summary>

/// <param name="actualParameter">AR</param> /// <param name="expectedParamater">ER</param>

bool IsValid(ResolveParamater actualParameter, ResolveParamater expectedParamater);

/// <summary>

/// Use to find relevation of the expected parameter to actual parameter

/// </summary>

/// <param name="actualParameter">AR</param> /// <param name="expectedParameter">ER</param> /// <returns></returns>

double Resolve(ResolveParamater actualParameter, ResolveParamater expectedParameter);

}

Поле ParameterType використовуеться для встановлення типу параметра для поточного сценарiю, що дозволяе легко видшити всi можливi сценарiï з загально'1 колекцiï по типу параметра для дiапазону значень ER, що дозволяе уникнути зайвих перевiрок.

Метод IsValid() використовуеться для знаходження необхщного сценарiю. Таким чином, якщо результат виконання методу е True, то необхщний сценарп знайдено i вщбу-ваеться виконання методу Resolve(), в шшому випадку вiдбуваеться перехiд до наступного сценарп.

Метод Resolve() порiвнюе два дiапазони значення й визначае рiвень вiдповiдностi мiж ними у вщсотковому вiдношеннi, який повертаеться як цшочисельне значення.

Псевдокод пошуку та резолвшгу для дiапазону значень виглядае таким чином:

Iнiцiалiзацiя параметрiв вщбуваеться через IoC-контейнер, що дозволяе динамiчно створювати екземпляри.

Результат резолвiнгу представлено у виглядi 100 кейсiв iз найвищими показниками релевантность При потребi оператор може змшити кiлькiсть результуючих значень, але при цьому резолвшг вiдбуватиметься повторно.

Кейс 2 50%

Вх\дн\ параметри Вих1дн1 параметри

Тип ripCbKOl' породи Мехашчна швидккть буршня

Вапняки 141,325

Кшьккть шарошок у доло-ri

3

Рисунок 6 - Виведення результат резолвшгу

Також, оператор може вщразу переглянути кожен результуючий кейс у списку ре-зультатiв.

Важливим пунктом роботи системи е пiдтримка миттевих повiдомлень для кейсiв, якi необхщно вiдправляти, якщо релевантнiсть кейсу досягла наперед визначено! вiдмiтки.

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

гу.

Кожен кейс може мати одне чи бшьше повiдомлень з рiзними рiвнями релевантнос-

тi.

Крiм того, при створенш повiдомлення можна зазначати тип повщомлення, що до-помагатиме встановлювати додатковi кольоровi чи звуковi сигнали, щоб оператор мiг швидше реагувати на важливi повiдомлення.

Загалом видшяються 3 типи повiдомлень:

• шформативне - встановлюеться, якщо повщомлення несе суто рекомендацшний характер;

• попереджувальне - встановлюеться, якщо повщомлення несе попередження про можливi критичш ситуацп;

• критичне - встановлюеться для кейав, вихiдними результатами яких е опис кри-тичних ситуацiй.

IdentityServer

Захист даних та методiв роботи системи е важливою складовою в нафтогазовш галузi, оскiльки вразливiсть безпеки може призвести до витоку даних про нафтогазовi об'екти або до виведення з ладу чи зупинки роботи бурово! установки. Для захисту даних i забезпе-чення зручного способу авторизацп та аутентифшацп було виршено використати техноло-гiю IdentityServer 4, яка е реалiзацiею стандарту OpenID, що дае можливiсть створювати

единий облшовий запис для аутентифшацп на багатьох штернет-ресурсах, що можуть бути не зв'язаш мiж собою.

3. Висновки

Таким чином, центральним елементом створено'' системи е тдтримка миттевих повщом-лень для кейсiв, яю необхiдно вiдправляти, якщо релевантнiсть кейсу досягла напередвиз-начено'1 вiдмiтки. Це особливо актуально для резолвшгу кейав, де вихiднi значення яких несуть попереджувальний чи аваршний характер. Кожен кейс може мати одне чи бшьше повщомлень з рiзними рiвнями релевантностi. Створенi кейси можуть бути використаш для знаходження спiвпадiнь за заданим дiапазоном. Релевантнiсть кейсiв е важливою скла-довою системи, що забезпечуеться шляхом накладання на кейси великих об'емiв отрима-них значень у процес бурiння iз рiзних бурових комплексiв. Накладання вiдбуваеться шляхом порiвняння отриманих значень iз вхщними та вихiдними значеннями кожного кейсу для встановлення рiвня вiдповiдностi отриманих значень у процес бурiння з очшу-ваними значеннями, описаними в кожному кейа. Результатом накладання е отримане вщ-соткове значення релевантности даного кейсу для поточно'1 бурово'1 установки в певний момент часу. При цьому релевантшсть кейсу вщносно бурово'1' установки описуеться як середне вщсоткове значення всiх накладань кейсу. Таким чином, кожен кейс мае набiр ре-левантностей для кожно'1 установки, що дае можливiсть ощнювати якiсть кейсу, а також проводити пошук кейсiв за релевантнiстю в базi знань.

СПИСОК ДЖЕРЕЛ

1. Abdrabou E. A. M. L., Salem A.-B. M. Case-based reasoning tools from shells to object-oriented frameworks. InICCOMP. 2008. Vol. 67. P. 781-786.

2. Bergmann R., Schaaf M. Structural case-based reasoning and ontology-based knowledge management: A perfect match. Journal of Universal Computer Science. 2003. Vol. 9, N 7. P. 608-626.

3. Bierer A., Hofmann M. Dimensions of case-based reasoner quality management / ed. L. McGinty, D. Wilson. Case-Based Reasoning Research and Development: Lecture Notes in Computer Science. Springer Berlin Heidelberg. 2009. Vol. 5650. P. 90-104. DOI: 10.1007/978-3-642-02998-1 53.

4. Gronau N., Laskowski F. Using case-based reasoning to improve information retrieval in knowledge management systems / ed. E. Menasalvas, J. Segovia, P. Szczepaniak. Advances in Web Intelligence : Lecture Notes in Computer Science. Springer Berlin Heidelberg. 2003. Vol. 2663. P. 94-102. DOI: 10.1007/3-540-44831-49.

5. Hüllermeier E. Case-Based Approximate Reasoning. Berlin: Springer, 2007. - 63 p.

6. Hüllermeier E. Schlegel P. Preference-based CBR: first steps toward a methodological framework. In Proceedings of the 19th International Conference on Case-Based Reasoning Research and Development: ICCBR'11: Springer-Verlag, 2011. P. 77-91. DOI: 10.1007/978-3-642-23291-6_8 38,63.

7. Sheketa V.I., Melnyk V.D., Romanyshyn Y.L., Chesanovskyy M.S. The Construction of Technological Problems Cases for the Purpose of Intelligible Control. Perspective technologies and methods in MEMS design (MemsTech'2016): XIIth International Conference (Lviv-Polyana, 20-24 th April 2016). Lviv, 2016. P. 96-99.

8. Sheketa V.I., Pikh V.Y., Styslo T.R., Chesanovskyy M.S. Modeling methodology for knowledge-based systems of wells drilling control. Perspective technologies and methods in MEMS design (Mem-sTech '2017). XIIIth International Conference (Lviv-Polyana, 20-23 th April 2017). Lviv, 2017. P. 56-58.

9. Barták R., Dechter R. Constraint Processing. New-York: Morgan Kaufmann Publisher, 2003. 210 p.

10. Tsang E. Foundations of Constraint Satisfaction. London and San Diego: Academic Press, 1993. 421 p.

Стаття надтшла до редакцп 26.10.2018