Інформаційна система контролю якості поліетилену в циркулярній економіці

console.log('First'); console.log('Second');

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

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

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

Об'єкт застосунок Express також надає методи для визначення оброблювачів маршрутів для всіх інших HTTP-дієслів, які зазвичай використовуються однаково: post (), put (), delete (), options (), trace (), copy ( ), lock (), mkcol (), move (), purge (), propfind (), proppatch (), unlock (), report (), mkactivity (), checkout (), merge ( ), m-search (), notify (), subscribe (), unsubscribe (), patch (), search () і connect ().

Маршрути дають змогу зіставляти певні шаблони символів у URL-адресі, видобувати деякі значення із URL-адреси і передавати їх як параметри оброблювачу маршруту (як атрибути об'єкта запиту, переданого як параметр). Для прикладу, використання функції маршрутизації: var wiki = require('./wiki.js'); app.use('/wiki', wiki);

Щоб використовувати маршрутизатор, надається модуль route (wiki.js), із викликом use () в застосунку Express, щоб додати маршрутизатор у шлях опрацювання проміжного програмного забезпечення.

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

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

Для використання стороннього проміжного програмного забезпечення спочатку необхідно встановити його в свій застосунок за допомогою NPM. Після цього надається можливість викликати use () для об' єкта застосунка Express, щоб додати проміжне програмне забезпечення у стек: var express = require('express'); var logger = require('morgan'); var app = express(); app.use(logger('dev'));

Окрім всього вищесказаного, можна додати функції проміжного програмного забезпечення в ланцюжок опрацювання за допомогою app.use () або app.add (), залежно від того, чи є необхідність застосувати проміжне програмне забезпечення до всіх відповідей або до відповідей з певним дієсловом HTTP (GET, POST тощо). Маршрути задають однаково в обох випадках, хоча маршрут необов'язковий у разі виклику app.use ().

Express надає користувачу змогу використовувати проміжне програмне забезпечення express.static для обслуговування статичних файлів, зокрема зображення, CSS і JavaScript (static - єдина функція проміжного програмного забезпечення, яка фактично є частиною Express).

Наприклад, постає необхідність використовувати рядок нижче для обслуговування зображень, файлів CSS і файлів JavaScript із каталогу з ім'ям public на тому ж рівні, де викликається вузол:

app.use(express.static('public'));

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

app.use(express.static('public')); app.use(express.static('media'));

Також можна створити віртуальний префікс для статичних URL-адрес, замість додавання файлів до базової URL-адреси. Наприклад, вказуємо шлях монтування, щоб файли завантажувалися з префіксом "/ media":

app.use('/media', express.static('public'));

Після цього надається можливість завантажувати файли, що містяться в публічному каталозі, з префіксу/media path. Помилки опрацьовуються однією або декількома спеціальними функціями проміжного програмного забезпечення, які мають чотири аргументи замість звичайних трьох: (err, req, res, next), наприклад:

app.use(function(err, req, res, next) { console.error(err.stack); res.status(500).send('Something broke!');});

Вони можуть повертати будь-який необхідний контент, але повинні викликатися після всіх інших app.use () і маршрутизувати виклики, щоб вони були як останній проміжний ПО в процесі опрацювання запитів. Express поставляється із вбудованим оброблювачем. Ця проміжна функція опрацювання помилок за замовчуванням додається у кінець стека функцій проміжного програмного забезпечення. Якщо користувач передає помилку в next () і не опрацьовує її в обробнику помилок, її опрацює вбудований оброблювач помилок. Надалі помилка буде записана клієнту з трасуванням стека. Фреймворк Express може використовувати будь-який механізм бази даних, підтримуваний Node. Є багато варіантів, зокрема PostgreSQL, MySQL, Redis, SQLite, MongoDB тощо. Щоб використовувати їх, користувач повинен спочатку встановити драйвер бази даних, застосувавши NPM. Наприклад, щоб встановити драйвер для популярної NoSQL MongoDB, він повинен використовувати команду: $ npm install mongodb. Сама база даних може бути встановлена локально або на хмарному сервері. Іншим популярним підходом є непрямий доступ до бази даних за допомогою Object Relational Mapper (“ORM”). За такого підходу свої дані визначають як “об'єкти” або “моделі”, і ORM відображає їх у базовий формат бази даних. Перевага цього підходу в тому, що і розробник, і користувач може продовжувати думати із погляду об'єктів JavaScript, а не семантики бази даних, і що це очевидне місце для виконання перевірки вхідних даних. Для цієї системи вибрали базу даних PogstgreSQL, зважаючи на функції, які дають змогу виконувати деякий код безпосередньо сервером бази даних. Ці функції можуть бути написані на SQL, який має деякі примітивні програмні оператори, такі як розгалуження та цикли. Але гнучкішою буде функція, написана на одній із мов програмування, з якими PostgreSQL може працювати [31]. До мов програмування у PostgreSQL належать:

Вбудована мова, подібна до процедурної мови PL/SQL компанії Oracle.

Мови розроблення сценаріїв: PL/Perl, PL/Python, PL/Tcl, PL/Ruby, PL/sh.

Класичні мови програмування C, C++, Java (за допомогою PL/Java).

Функції можуть виконуватись із привілеями користувача, який їх викликав, або із привілеями користувача, який їх написав.

Механізми шаблонів у Express дають змогу вказувати структуру вихідного документа в шаблоні, використовуючи наповнювачі для даних, які будуть заповнюватися під час створення сторінки. Шаблони часто використовують для створення HTML, але можуть також створювати інші типи документів. В Express є підтримка певних шаблонних движків, і тут корисне порівняння популярніших движків: Jade, Mustache, Dust і More. У коді налаштувань програми надається можливість задати механізми шаблонів для використання і місце, де Express повинен шукати шаблони, використовуючи налаштування “views” і “engine”, як показано нижче: var express = require('express'); var app = express();

app.set('views', path.join( dirname, 'views')); app.set('view engine',

'some_template_engine_name');

Зовнішній вигляд шаблону залежатиме від того, який движок використано. Припустимо, що є файл шаблону з ім'ям “index”.

<Template_extension> », який містить наповнювачі для змінних даних з іменами “title” і “message”, користувач повинен викликати Response.render () у функції обробника маршруту для створення і надсилання відповіді HTML:

app.get('/', function(req, res) { res.render('index', {title: 'About dogs',

message: 'Dogs rock!' });});

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

Розроблена інформаційна система контролю якості поліетилену доволі складна за структурою та наповненням. Для того, щоб зрозуміти принцип її функціонування, необхідно виконати детальний аналіз логічної структури, функціональних можливостей, а також комунікації елементів системи, зв'язаних між собою. Окрім цього, з огляду на те, що система має потенціал для розширення і розвитку, постає необхідність опису створеного програмного засобу, для подальшого подання інформації новим розробникам, службі технічної підтримки, тестувальникам чи іншим зацікавленим особам. Функціональне призначення інформаційної системи полягає у контролі штучним інтелектом якості продукції в реальному часі, із виявленням дефектної продукції на ранніх етапах, та встановлення відповідності показників продукції і процесів вимогам нормативно-технічної документації, зразкам, еталонам, і запобігання цим випуску неякісної продукції. Окрім цього, користувачам інформаційної системи необхідно надати повну інформацію про перебіг виробничого процесу та підтримання його стабільності, мінімізуючи необхідність втручання користувача у виробничий процес, завдяки чому буде зменшено вплив помилок, спричинених людським фактором, і збільшено ефективність інформаційної системи. Необхідно забезпечити можливості комунікації в середині інформаційної системи про перебіг виробничого процесу. Важливим є повноваження штучного інтелекту і користувача. Хоча користувач обмежений в своїх діях і його вплив на інформаційну систему стає мінімальним після виставлення параметрів для продукції, однак у нього залишається можливість призупинити виробничий процес або достроково завершити його. Логічна структура кожної інформаційної системи може бути подана на основі чотирьох основних моделей: лінійної моделі, моделі “ґрати”, деревоподібної моделі та “павутини”. Варто зазначити, що існують додаткові комбінації на базі основних моделей, які надають змогу реалізувати будь-яку логічну структуру сайта. Оскільки, як зазначено вище, інформаційна система доволі складна, а розроблення такого ресурсу - клопітка робота, наявність оптимальної структури зведе до мінімуму можливість технічних помилок. Це стосується як помилок у коді, так і наявності або відсутності окремих сторінок і матеріалів на них. З огляду на ці фактори, вибрано логічну деревоподібну структуру. Логічна деревоподібна структура - це модель організації системи, що є найпопулярнішою. Така структура дає користувачам системи змогу за бажанням керувати глибиною відвідування системи. Користувачі мають змогу входити тільки на сторінки найвищих рівнів або ж “спускатись” до нижчих рівнів. Наявні можливості вибору залежать від “ширини дерева”. Якщо користувачам для досягнення поставленої кінцевої цілі необхідно виконати занадто багато клацань миші, то структура ієрархії системи може виявитися у цьому випадку занадто вузькою. Користувачів дратуватиме нескінченне “клацання”, оскільки їхні дії не даватимуть очікуваних результатів. Водночас дуже широке “дерево”, яке ґрунтується на доволі великій кількості варіантів вибору, змусить користувачів системи витратити багато часу на вивчення пропонованих варіантів. Це також не дасть позитивних результатів. Беручи до уваги ці фактори логічної структури системи, ми прагнули до забезпечення оптимального рівня глибини і ширини. Графічне зображення логічної деревоподібної структури системи подано на рис. 12.

Рис. 12. Логічна структура системи

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

./app - директорія, що містить файли, які є основою фронтенду системи.

./dist - директорія із транспільованим вихідним кодом бекенду (із TS в JS).

./node_modules - містить бібліотеки платформи NodeJS.

./public - скомпільована збірка фронтенду (build), відкрита для публічного доступу користувачам, а також статичні файли системи.

./src - директорія, яка містить вихідний код бекенду.

./typings - директорія, в якій міститься опис об'єктів та типів всієї аплікації.

./env - файл, що містить ключові параметри запуску аплікації.

./knh.ts - файл, який є вхідною точкою для запуску бекенду.

./package.json - файл, що містить опис необхідних для аплікації бібліотек.

./tsconfig.json - файл конфігурації налаштувань компілятора TypeScript.

./webpack.config.js - файл конфігурації налаштувань бандлера Webpack.

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

FrontEnd і BackEnd реалізовані мовою програмування TypeScript, яка є суперпозицією мови JavaScript.

BackEnd створений на основі фреймворку ExpressJS. Детальний опис цього феймворку наведено в третьому розділі.

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

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

Web-аплікація - SPA (Single Page Application) застосунок, написаний на фреймворку ReactJS. SPA є вебзастосунком чи вебсайтом, який вміщується на одній сторінці, щоб забезпечити користувачу досвід, близький до користування настільною програмою.

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

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

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

Автентифікація запрограмована стандартом JWT. JSON Web Token - це стандарт токена доступу на основі JSON, стандартизованого в RFC 7519. Використовується для верифікації, шифрування і передавання даних авторизованих користувачів між постачальником ідентифікації та постачальником послуг.

Базою даних слугує реляційна БД PogstgreSQL. Сервер PostgreSQL написаний мовою C. Зазвичай розповсюджується у вигляді набору текстових файлів із сирцевим кодом.

Для зручного користування базою даних використано ORM (Objectrelational mapping) технологію. Ця технологія зв'язує бази даних із концепціями об'єктно-орієнтованих мов програмування, надаючи “віртуальну об'єктну базу даних” та створюючи запити до бази об'єктно- орієнтованими мовами програмування.

Для того, щоб система почала функціонувати в мережі інтернет для користувачів у звичайному режимі, адміністратору системи необхідно виконати певні важливі дії із завантаженням системи і її розгортанням. Завершивши розроблення системи та перевірку її функціоналу на локальному хостингу, необхідно розгорнути систему для широкого доступу. Передусім необхідно скомпілювати як FrontEnd, так і BackEnd. Командою “npm run build” здійснюємо транспіляцію вихідного коду бекенду із TypeScript в JavaScript, який платформа NodeJS вже зможе інтерпретувати, після чого розпочнеться робота бандлера Webpack. Окрім трансформації TS в JS, він перетворить код ECMAScript 2015+ на зворотну сумісну версію JavaScript для старих браузерів чи середовищ. Основний файл бекенду, до якого задіюється транспіляція, це knh.ts: import Express from 'express' import { api } from './src/routers' import { requestHandler } from './src/middleware' const { PORT } = process.env new Express()

. use(requestHandler)

.use(api.routes())

.listen(PORT, () => console.log('E Launching @KNH'))

Подальша робота бекенду запускається командою “node dist/knh .js”. У випадку “живого” сервера використали програму Process Manager 2 (PM2), яка є відкритим вихідним кодом, розробленим Node.js та менеджером процесів, що допомагає розробникам управляти Node.js. Порівняно з іншими менеджерами процесів, такими як Supervisord, Forever, Systemd, ключовими особливостями PM2 є автоматичне збалансування навантаження програми, декларативна конфігурація програми, система розгортання та моніторинг. Скрипт із виклику knh.js, а також додаткові відомості про конфігурацію системи описані у файлі ecosystem.config.js: module.exports = { apps : [{ name: 'knh', script: './dist/knh.js', instances: 1,

max_memory_restart: '128M', log_date_format: 'MM/DD HH:mm', env:

{

PORT: 8007, HASH_KEY: '7+frf9pyVhQLOyw5YYdOMAso08c9hdOl',

POSTGRESQL: 'postgres://username:password@localhost/knh' } }] }

Виходячи із цього файла, можна побачити основний ключ, а також інформацію про те, що бекенд обслуговується на внутрішньому порті 8007, із використанням ngix як зворотного проксі (для доступу до системи через зовнішні порти 443/80). Під час функціонування інформаційна система використовує вхідні дані, для виконання покладених на неї функцій контролю якості поліетилену. До вхідних даних інформаційної системи належать: час роботи виробничого процесу; каталізатор; фракція; розчинник; метанол; добавки; метиловий спирт; технічні засоби.

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

export const validateSessionCreation: IMiddleware = async (ctx, next) =>{

Важливий крок - деструктуризація у цьому файлі вхідних даних із тіла запиту на локальні змінні:

const { time, catalizator, fraction, disolver, methanol, additive, methyl, gatherer, granulator, centrifugeFirst, centrifugeSecond, centrifugeThird } = ctx.request.body as TSessionCreation

Після цього виконується перевірка наявності змінних (якщо змінні відсутні, інформаційна система надсилає помилку із кодом 400 і відповідне повідомлення): if (time === void 0 || catalizator === void 0 || fraction === void 0 || disolver === void 0 || methanol === void 0 || additive === void 0 || methyl === void 0 || gatherer === void 0 || granulator === void 0 || centrifugeFirst === void 0 || centrifugeSecond === void 0 || centrifugeThird === void 0) throw new ApiError(400, 'Missing required fields')

Наступним кроком є перевірка відповідності типів змінних (якщо відповідність не підтверджена, інформаційна система надсилає помилку із кодом 400 і характерне повідомлення): if (typeof time !== 'number' || typeof catalizator !== 'string' || typeof fraction !== 'string' || typeof disolver !== 'number' || typeof methanol !== 'number' || typeof additive !== 'number' || typeof methyl !== 'boolean' || typeof gatherer !== 'boolean' || typeof granulator !== 'boolean' || typeof centrifugeFirst !== 'boolean' || typeof centrifugeSecond !== 'boolean' || typeof centrifugeThird !== 'boolean') throw new ApiError(400, 'Type mismatch')

Останнім елементом файла є здійснення перевірки технічних засобів, а також меж величини вхідних даних та допустимості їх заповнення:

if (time < 1 || time > 240) throw new ApiError(400, 'Bad time value') if (+catalizator < 1 || +catalizator > 1000) throw new ApiError(400, 'Bad catalizator value')

if (+fraction < 1 || +fraction > 1000) throw new ApiError(400, 'Bad fraction value')

if (disolver < 1 || disolver > 100) throw new ApiError(400, 'Bad disolver value')

if (methanol < 1 || methanol > 100) throw new ApiError(400, 'Bad methanol value')

if (additive < 1 || additive > 100) throw new ApiError(400, 'Bad additive value')

if ((centrifugeThird && (!centrifugeSecond || !centrifugeFirst)) || (centrifugeSecond && !centrifugeFirst)) throw new ApiError(400, 'Bad centrifuge configuration') return next() }

Після виконання валідації даних стає доцільною подальша робота із вхідними даними, яка описана у файлі services.ts:

export const onCreateSession: TAuthorizedMiddleware = async (ctx) => {

Під час виконання експорту здійснюється деструктуризація вхідних даних із тіла запиту на локальні змінні:

const { time, catalizator, fraction, disolver, methanol, additive, methyl, gatherer, granulator, centrifugeFirst, centrifugeSecond, centrifugeThird } = ctx.request.body as TSessionCreation const { id } = ctx.state

Отримуємо об'єкт користувача або повертаємо помилку, якщо такого не існує: const user = await User.findByPk(id) if (!user) throw new ApiError(404, 'User not found')

Виконуємо перевірку та визначаємо стан виробничого процесу. Якщо процес активний - отримуємо характерне повідомлення, якщо ж сеанс неактивний, створюємо нову сесію: if (ctx.state.session) throw new ApiError(409, 'An active or paused session already exists')

const session = await user.createSession({ disolver, methanol, additive, methyl, gatherer, granulator, centrifugeFirst, centrifugeSecond, centrifugeThird,

time: time * 60, timeLeft: time * 60, catalizator: +catalizator, fraction: +fraction, status: 'active'})

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

createSimulation(session, 2000) ctx.state.data = { session: session.toJSON()

} }

Основою для будь-якої звітності та аналізу виробничого процесу є вихідні дані. В цьому випадку вони зображені у вигляді рухомого рядка, під час перегляду якого клієнт користувача кожні дві секунди запитує сервер про нові результати. Після завершення сесії, навіть якщо це екстрене завершення, всі вихідні дані записуються у відповідну базу даних інформаційної системи, яку згодом можна переглянути, виконати відповідний аналіз та надати звітність. Робота із вихідними даними описана у файлі services.ts. Її структура така: здійснюємо експорт та констатуємо сесію. Параметр skip вказує на кількість результатів, які необхідно пропустити від початку списку рядка: export const onGetResults: TAuthorizedMiddleware = async (ctx) => { const { session } = ctx.state

const skip = ctx.query.skip as string | undefined

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

if (!session) throw new ApiError(404, 'No active session') const results = await session.getResults({ offset: skip ? +skip : 0, raw: true })

Останній крок - повернення результатів користувачу системи:

ctx.state.data = { results, session: session.toJSON() } }

БД створена для зберігання інформації про користувачів системи та про вихідні дані виробничого процесу, який прив'язаний до користувача. Як зазначено вище, запити до БД виконуються за допомогою ORM технології, а сама база створена за допомогою PogstgreSQL. Графічно ER-діаграму бази даних зображено на рис. 16. БД містить три таблиці, а саме:

Users. У цій таблиці містяться відомості про користувача, такі як: id-користувача, email- адрес, ім'я, прізвище, дата створення.

Session. Містить id-сесії, id-користувача, статус сесії, відомості про сесію, відомості про вхідні дані, а також про технічні засоби.

Result. Містить id-результату, id-сесії та вихідні дані системи.

Відношення між Users та Session як один до багатьох, Session до Result також один до багатьох. Графічно ER-діаграму бази даних зображено на рис. 13.

Рис. 13. ER-діаграма бази даних інформаційної системи (рис. 14). Навігація головного меню

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

Для системи контролю якості виробництва поліетилену інструкція користувача необхідна, оскільки допомагає користувачам ефективно запускати та контролювати виробництво. Оскільки розроблена інформаційна система надає повний доступ до процесу виробництва, неналежне користування нею хоч і не може спричинити фатальних наслідків для технічних засобів виробництва (з огляду на контроль процесу штучним інтелектом), однак помилкові дії користувача можуть призвести до браку виготовленої продукції. З огляду на зручність користування інформаційною системою, вся необхідна інструкція для користувача міститься безпосередньо у самій системі, на спеціально відведеній сторінці, перейти до якої можна з головного меню, натиснувши відповідне посилання (детальне зображення зв'язків між сторінками наведено на рис. 15). Таке рішення дасть змогу користувачеві звертатися до інструкції незалежно від місця його перебування на виробництві та за короткий проміжок часу приймати ефективні рішення. Навігацію по головному меню системи зображено на рис. 14 зліва (виділено червоним і пронумеровано одиницею), початок роботи із системою - посередині із кнопкою “СТАРТ” (пронумеровано двійкою). Інформаційна система містить три класи вирішуваних завдань. Відповідно до вимог оформлення інструкції користувача, опишемо детально кожне із завдань та чіткі способи їх виконання.

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

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

* Отримати документ із дозволом частково запустити виробничий процес.

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

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

Запустити виробництво та вести моніторинг системи.

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

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

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

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

Після завершення виробництва перейти до бази даних, в якій записаний весь робочий процес та його показники якості.

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

Надіслати дані на відповідну електронну пошту, зазначену в документі із вказівками запуску.

Завершити роботу із інформаційною системою.

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

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

Величини каталізатора і фракції повинні бути рівні, тобто становити по 50 % кожний.

Відсоток розчинника повинен перевищувати 30 %.

Метанол повинен становити менше ніж 40 %.

Відсоток добавки повинен бути меншим, ніж 8 %.

Під час запуску виготовлення всі технічні елементи повинні бути ввімкнені.

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

Варто зазначити, що для користувачів є відповідні вказівки на обмеження (рис. 15), це можуть бути як заборони (вказані червоним кольором, 1), так і попередження (жовтим, 2).

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

Рис. 15. Вказівки на обмеження та дотримання вимог системи

Рис. 16. Дорожня карта виробництва

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



Рис. 17. Заповнення даними для звичайного режиму

Рис. 18. Виведення показників якості

Для режиму діагностики інформаційної системи виконуємо схожі дії із заповненням параметрами, однак вмикаємо тільки ті технічні засоби, які нам потрібно діагностувати. В цьому режимі допускається введення параметрів, які не відповідають вимогам, щодо виготовлення поліетилену. Цей фактор зумовлений тим, що під час діагностики не виготовляється кінцевий продукт, а отже, визначення і контроль якості у цьому випадку недоцільні. Заповнення параметрів для діагностики відображено на рис. 19. Після того як всі параметри заповнені, а відповідні технічні засоби увімкнені, натискаємо кнопку запуску виробництва та спостерігаємо розраховані значення опрацьованої сировини (рис. 20). Останнім етапом є виведення детальної інформації про завершену сесію. Для цього відкриваємо базу даних і шукаємо потрібну нам сесію або ж відповідним запитом здійснюємо виведення потрібної нам сесії. Виводимо параметри для третьої сесії, написавши такий запит: select * from results where "sessionId" = 3.



Рис. 19. Заповнення даними для режиму діагностики

Рис. 20. Виведення показників опрацьованої сировини

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

Рис. 21. Виведення показників якості технологічних процесів для третьої сесії

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



Висновки

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

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

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

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

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

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

Список літератури

1. Kohl H. (2020). Standards for management systems. Management for Professionals.

2. Fitriani S., Sofyan Y. (2020). Simulator Human Machine Interface (HMI) using visual basic on the SCADA system. In IOP Conference Series: Materials Science and Engineering, Vol. 830, No. 3, p. 032016. IOP Publishing.

3. Faccia A., Petratos, P. (2021). Blockchain, enterprise resource planning (ERP) and accounting information systems (AIS): Research on e-procurement and system integration. Applied Sciences, 11(15), 6792.

4. Sarvaiya H. B., Keswani R. A., Pannase D., Patil S., Turankar P., Janbandhu A., Patle V. (2022). Recent Developments in SCADA System for Remote Industry and It's Experimental Implementation. International Journal of Engineering Technology and Management Sciences. Website: ijetms. in, 6(3).

5. Upadhyay D., Sampalli S. (2020). SCADA (Supervisory Control and Data Acquisition) systems: Vulnerability assessment and security recommendations. Computers & Security, 89, 101666.

6. Tien N. H. (2019). International economics, business and management strategy. Dehli: Academic Publications.

7. Ceko E. (2021). On relations between creativity and quality management culture. Creativity studies, 14(1), 251--270.

8. World Health Organization. (2021). WHO global air quality guidelines: particulate matter (PM2. 5 and PM10), ozone, nitrogen dioxide, sulfur dioxide and carbon monoxide: executive summary.

9. Baran M., Kuzmin O., Bublyk M., Panasyuk V., Lishchynska K. (2021). Information System for Quality Control of Polyethylene Production in a Circular Economy. CEUR Workshop Proceedings, Vol. 2917, 465-502.

10. Mukheijee P., Acharyya A., Dash N., Alam A., Barik K. C., Behera S., Dash R. N. (2022). Linear Bottle filling system using Simatic S7-200 and S7-1200 PLC with HMI control. In International Conference on Industrial Electronics: Developments & Applications, 78-82.

11. Yamazaki M., Nakagawa, W. (2021). How open systems support end users: End users have been vocal about wanting open systems, and automation vendors are responding by delivering systems compliant with international standards. Control Engineering, 68(4), 30-34.

12. Schneider, M. J. (2017). Anti-inflammatory effects of herbal preparations in cytokine-challenged normal human colon cells: doctoral dissertation. DOI: 10.25358/openscience-843

13. Gozhyj A., Vysotska V., Yevseyeva I., Kalinina I., Gozhyj V. (2019). Web Resources Management Method Based on Intelligent Technologies. In: Shakhovska, N., Medykovskyy, M. (eds) Advances in Intelligent Systems and Computing III. CSIT 2018. Advances in Intelligent Systems and Computing, Vol. 871. Springer, Cham.

14. Lytvyn V., Pukach P., Bobyk І., Vysotska, V. (2016). The method of formation of the status of personality understanding based on the content analysis. Eastern-European Journal of Enterprise Technologies, (5 (2)), 4-12.

15. Vysotska V., Chyrun L., Chyrun L. (2016). Information technology of processing information resources in electronic content commerce systems. In 2016 XIth International Scientific and Technical Conference Computer Sciences and Information Technologies (CSIT), Lviv, Ukraine, 2016, 212-222

16. Luis P., Van der Bruggen B. (2014). Exergy analysis of energy-intensive production processes: advancing towards a sustainable chemical industry. Journal of Chemical Technology & Biotechnology, 89(9), 1288-1303.

17. Michler G. H., Balta-Calleja F. J. (2016). Mechanical properties of polymers based on nanostructure and morphology. CRC Press.

18. Han Y., Dai L. (2019). Conducting polymers for flexible supercapacitors. Macromolecular chemistry and physics, 220(3), 1800355.

19. Gozhyj A., Kalinina I., Vysotska V., Gozhyj V. (2018). The method of web-resources management under conditions of uncertainty based on fuzzy logic. In 13th International Scientific and Technical Conference on Computer Sciences and Information Technologies, 343-346. IEEE.

20. Berko A., Vysotska V., Chyrun L. (2014). Features of information resources processing in electronic content commerce. Applied Computer Science, 10(2).

21. Vysotska V., Chyrun L., Kozlov P. (2016). Analysis of business processes in electronic content-commerce systems. ECONTECHMOD: an international quarterly journal on economics of technology and modelling processes, 5(1), 111-125.

22. Chyrun L., Vysotska V., Laba, R. (2016). Information Resources Analysis in Electronic Content Commerce Systems. Applied Computer Science, 12(1), 48-66.

23. Vysotska V., Berko A., Lytvyn V., Kravets P., Dzyubyk L., Bardachov Y., Vyshemyrska S. (2021). Information Resource Management Technology Based on Fuzzy Logic. Advances in Intelligent Systems and Computing, Vol. 1246. Springer, Cham.

24. Berko A., Vysotska V., Lytvyn V., Naum O. (2018). Planning the activities of intellectual agents in the electronic commerce systems. Radio electronics, informatics, management, 4 (47), 143-158.

25. Chyrun L., Kowalska-Styczen A., Burov Y., Berko A., Vasevych A., Pelekh I., Ryshkovets, Y. (2019). Heterogeneous Data with Agreed Content Aggregation System Development. In MoMLeT, 35-54.

26. Bachle M., Kirchberg P. (2007). Ruby on rails. IEEE Softw., 24(6), 105-108.

27. ReactJS.

28. AngularJS.

29. Node.js.

30. PostgreSQL.

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