Сучасні вимоги з безпеки при проектуванні електричних та електронних систем управління
Проектування й створення систем управління промисловим обладнанням з використанням програмованих електронних систем управління. Вимоги до програмного забезпечення всіх систем з урахуванням специфікації задля їх безпеки відповідно до стандарту IEC 62061.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | статья |
Язык | украинский |
Дата добавления | 18.01.2022 |
Размер файла | 2,1 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.Allbest.Ru/
Національний технічний університет України
Київський політехнічний інститут імені Ігоря Сікорського
Сучасні вимоги з безпеки при проектуванні електричних та електронних систем управління
С.Ф. Каштанов,
Ю.О. Полукаров,
Л.O. Мітюк
м. Київ, Україна
Анотація
З метою визначення основних особливостей проектування, розробки й створення систем управління промисловим обладнанням, в яких використовуються електричні, електронні та програмовані електронні системи управління (ПБЕСУ) проаналізовані вимоги Directive 2006/42/EC і діючих у цій сфері технічних регламентів та гармонізованих стандартів EN 954-1 (ДСТУ EN 954-1: 2003), ENISO 13849-1 (ДСТУ ENISO 13849-1-2016) . Зазначено вимоги до програмного забезпечення всіх систем з урахуванням специфікації задля їх безпечного функціонування відповідно до стандарту IEC 62061 «Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems» - «Безпека машин. Функціональна безпека, що пов'язана з безпекою електричних, електронних та програмованих електронних систем управління».
Обґрунтовано доцільність врахування «людського фактору» під час проектування інтерфейсів систем, щоб уникнути помилок ще на етапі проектування. Розглянуто питання ремонтопридатності й умов тестування систем через аналіз їх функціонального призначення та реакції на відмову. Зосереджено увагу на важливості врахування складності ПБЕСУ й рівня повноти безпеки відповідно до функцій, які виконуватиме система управління.
Виокремлено вимоги й параметри для управління систематичними збоями й електромагнітною стійкістю (Directive 2014/30/EU): використання знеструмлення, контроль за впливом тимчасових відмов і наслідками помилок, а також виконання функцій безпеки без збоїв. Окрім особливих вимог до функціонування ПБЕСУ зазначено й загальні вимоги, яких слід дотримуватись під час проектування системи. Відповідно до стандарту IEC 62061 наведено структурований порядок проектування й розробки згідно з визначеним процесом і його необхідними аспектами.
Доведено важливість впровадження в Україні стандарту IEC 62061, який регламентує вимоги при проектуванні й розробці ПБЕСУ задля безпечної та ефективної роботи на високоякісному рівні.
Ключові слова: система, управління, ПБЕСУ, безпека, стандарт IEC 62061, проектування, розробка.
Аннотация
Современные требования по безопасности во время проектирования электрических и электронных систем управления
С.Ф. Каштанов, Ю.О. Полукаров, Л.O. Митюк, Национальный технический университет Украины «Киевский политехнический институт имени Игоря Сикорского»
С целью определения основных особенностей проектирования, разработки и создания систем управления промышленным оборудованием, в которых используются электрические, электронные и программируемые электронные системы управления (ПБЭСУ) проанализированы требования Directive 2006/42/EC и действующих в этой сфере технических регламентов и гармонизированных стандартов EN 954-1 (ДСТУ EN 954-1: 2003), ENISO 13849-1 (ДСТУ ENISO 13849-1-2016).
Указаны требования для программного обеспечения всех систем с учётом спецификации для их безопасного функционирования в соответствии со стандартом IEC 62061 «Safety of machinery - Functional safety of safety - related electrical, electronic and programmable electronic control systems» - «Безопасность оборудования. Функциональная безопасность систем управления электрических, электронных и программируемых электронных, связанных с безопасностью». Обоснована целесообразность учёта «человеческого фактора» во время проектирования интерфейсов систем для того, чтобы избежать ошибок ещё на этапе проектирования.
Рассмотрен вопрос ремонтопригодности и условий тестирования системы с помощью анализа их функционального предназначения и реакции на отказ. Сосредоточено внимание на важности учёта сложности ПБЭСУ и уровня целостности безопасности в соответствии с функциями, которые будет выполнять система управления. Выделены требования и параметры для управления систематическими сбоями и электромагнитной стойкостью (Directive 2014/30/EU): использование обесточивания, контроль за влиянием временных отказов и последствиями ошибок, а также выполнение функций безопасности без сбоев. Кроме особенных требований к функционированию ПБЭСУ указаны и общие требования, которые следует соблюдать во время проектирования системы. В соответствии со стандартом IEC 62061 приведен структурированный порядок проектирования и разработки согласно определённому процессу и его необходимыми аспектами. Доказана важность внедрения в Украине стандарта IEC 62061, который регламентирует требования во время проектирования и разработки ПБЭСУ для безопасной и эффективной работы на высококачественном уровне.
Ключевые слова: система, управление, ПБЭСУ, безопасность, стандарт IEC 62061, проектирование, разработка.
Annotation
Modern safety requirements during the design of electrical and electronic control systems
S. Kashtanov, Y. Polukarov, L. Mityuk, National Technical University of Ukraine «Igor Sikorsky Kyiv Polytechnic Institute»
Purpose. In order to identify the main features of the design, development and creation of industrial equipment control systems that use electrical, electronic and programmable electronic control systems (PBESU), the requirements for the software of all systems, taking into account the specifications for their safe operation in accordance with IEC 62061, are specified: «Safety of machinery - Functional safety of safety - related electrical, electronic and programmable electronic control systems», «Equipment safety. Functional safety of electrical, electronic and programmable electronic safety-related control systems».
Methodology. The expediency of taking into account the "human factor" during the design of system interfaces is justified in order to avoid errors at the design stage. The question of maintainability and conditions of system testing is considered by analyzing their functional purpose and reaction to failure. The focus is on the importance of accounting for the complexity of the PBESU and the level of security integrity in accordance with the functions that the control system will perform.
Results. The requirements and parameters for the control of systematic failures and electromagnetic resistance are highlighted: the use of de-energization, control over the effect of temporary failures and the consequences of errors, as well as the performance of safety functions without failures (Directive 2014/30/EU). In addition to the special requirements for the operation of PBESU, there are also specified general requirements that should be observed during system design.
Originality In accordance with the IEC 62061 standard, a structured design and development procedure is given according to a defined process and its necessary aspects. The importance of introducing the IEC 62061 standard in Ukraine, which regulates requirements during the design and development of PBESU for safe and efficient work at a high-quality level, has been proved. Without this task our state will not be able to continue to compete effectively in the European and world markets.
Practical value. References 10, figures 2.
Key words: PBESU control system, safety, standard IEC 62061, design, development.
Вступ
Актуальність роботи. Проектування пов'язаних з безпекою систем управління промисловим обладнанням повинно здійснюватися з урахуванням вимог Directive 2006/42/EC і діючих у цій сфері технічних регламентів та гармонізованих стандартів EN 954-1 (ДСТУ EN 954-1: 2003), ENISO 13849-1 (ДСТУ ENISO 13849-1-2016) та IEC 62061 [1-4].
Метою даної роботи є визначення основних особливостей щодо проектування та розробки пов'язаних з безпекою систем управління промисловим обладнанням, в яких використовуються електричні, електронні та програмовані електронні системи управління (ПБЕСУ). Основним стандартом, який визначає ці вимоги є IEC 62061 «Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems» - «Безпека машин. Функціональна безпека, що пов'язана з безпекою електричних, електронних та програмованих електронних систем управління» [5].
Матеріал і результати досліджень. Згідно з даним стандартом ПБЕСУ повинна бути розроблена (або обрана) з урахуванням специфікації вимог до системи безпеки і, де це необхідно, з урахуванням специфікації вимог до програмного забезпечення системи безпеки відповідно до вимог стандарту IEC 62061.
ПБЕСУ повинна відповідати:
a) вимогам безпеки апаратних засобів, включаючи:
- обмеження архітектури на повноту безпеки апаратних засобів;
- вимоги до ймовірності небезпечних випадкових відмов апаратних засобів:
b) вимогам до систематичної повноті безпеки, включаючи:
- вимоги до можливості уникнути відмови;
- вимоги до управління систематичними помилками;
c) вимогам до поведінки ПБЕСУ при виявленні помилки;
d) вимогам проектування та розроблення пов'язаного з безпекою програмного забезпечення.
Проект ПБЕСУ повинен враховувати можливості і обмеження людини (в тому числі розумно передбачуване неправильне використання) і бути придатним для дій, які виконуються операторами, обслуговуючим персоналом та іншими категоріями осіб, які можуть взаємодіяти з ПБЕСУ.
Також необхідно, щоб при проектуванні всіх інтерфейсів враховувався «людський фактор», а також рівень підготовки або обізнаності оператора, особливо при масовому виробництві підсистем, коли оператором може бути будь-яка людина.
Мета проекту повинна полягати у тому, щоб розумно передбачувані помилки, зроблені оператором або обслуговуючим персоналом, були попереджені або усунені на етапі проектування. Якщо це неможливо, то, щоб мінімізувати можливість виникнення помилок оператора повинні бути також застосовані відповідні додаткові засоби (наприклад, реалізація дії вручну з додатковим підтвердженням перед її виконанням).
З метою сприяння реалізації вищезазначених властивостей, в ході розробки ПБЕСУ повинні бути також розглянуті питання ремонтопридатності та придатності спроектованої ПБЕСУ до тестування. Необхідно, щоб проект ПБЕСУ, його діагностичні функції і функції реакції на відмову були документально оформлені, при цьому дана документація повинна:
- бути точною, повною і короткою;
- відповідати визначеній меті;
- бути доступною і підтримуваною.
Необхідно також зазначити, що дані, отримані в результаті проектування, розробки та реалізації ПБЕСУ, обов'язково повинні бути на відповідних етапах верифіковані. У разі виникнення небезпечного збою в будь-який з підсистем, має бути передбачено виконання специфікованої функції реакції на відмову. Така специфікація може містити дії щодо ізоляції несправних частин підсистеми для продовження безпечної експлуатації машини в той час, як відбувається ремонт несправних частин.
Для запобігання систематичним відмовам апаратних засобів повинні бути застосовані наступні заходи:
a) ПБЕСУ повинна бути спроектована та реалізована згідно з планом функціональної безпеки;
b) правильні вибір, склад, схеми, складання та встановлення підсистем, в тому числі кабелів, проводів і будь-яких з'єднань;
c) застосування ПБЕСУ відповідно до специфікації виробника;
d) дотримання вказівок виробника щодо застосування, наприклад, інструкцій з установки та експлуатації (див. ISO 13849-2);
e) застосування підсистем з сумісними робочими характеристиками (див. ISO 13849-2);
f) ПБЕСУ повинна бути захищена відповідно до IEC 60204-1;
g) запобігання втрати функції заземлення відповідно до IEC 60204-1;
h) не повинні використовуватися документально не оформлені режими роботи компонентів (наприклад, «зарезервовані регістри» програмованого обладнання);
i) розгляд передбачуваного неправильного використання, змін умов навколишнього середовища і т.п.
Крім того, повинен бути застосований, принаймні, один з наступних методів і/або заходів, з урахуванням складності ПБЕСУ і рівня повноти безпеки (РПБ) для тих функцій, які будуть реалізовані ПБЕСУ:
a) аналіз проекту апаратних засобів ПБЕСУ (наприклад, за допомогою перевірки або наскрізного контролю) для виявлення в результаті оглядів і/або аналізу розбіжностей між специфікацією і реалізацією;
b) пакети і/або засоби автоматизованого проектування, що забезпечують функції моделювання та/або аналізу, що дозволяють виконувати процедури проектування на систематичній основі з використанням попередньо розроблених і протестованих елементів [6].
Для управління систематичними збоями повинні бути застосовані наступні заходи:
a) використання знеструмлення - ПБЕСУ повинна бути сконструйована таким чином, щоб при відключені електроживлення машини переходили в безпечний стан і залишалися в ньому;
b) контроль за впливом тимчасових відмов підсистеми - ПБЕСУ повинна бути сконструйована таким чином, щоб, наприклад:
- зміна напруги (переривання, падіння і т.п.) в окремих підсистемах або елементах підсистеми не приводило до виникнення будь-якої небезпеки (наприклад, переривання напруги, що впливає на електричні кола управління двигуном, не повинно привести до його несподіваного запуску в тому випадку, коли електроживлення двигуна відновлено);
c) управління наслідками помилок і іншими наслідками, що виникають в результаті будь-якого процесу передачі даних, включаючи помилки передачі, видалення, вставки, повторне упорядкування, спотворення, затримка і нелегальне проникнення.
Примітки:
1. Більш детальну інформацію можна знайти в IEC 60870-5-1, EN 50159-2 і IEC 61508-2.
2. Термін «нелегальне проникнення» означає, що справжній зміст повідомлення визначено неправильно. Наприклад, повідомлення від небезпечного компонента прийняті як повідомлення від безпечного.
d) якщо в інтерфейсі відбувається небезпечний збій, то повинна бути виконана функція реакції на відмову до того, як може статися небезпека через цей збій. Якщо відбувається збій, який знижує стійкість до відмов апаратних засобів до нуля, то реакція на цей збій повинна бути виконана за час, що не перевищує передбачуваний середній час відновлення /MTTR/. Вимоги, перераховані в даному пункті, відносяться до інтерфейсів, які є входами і виходами підсистем і всіх інших частин підсистем, що включають або використовують кабельні з'єднання в процесі інтеграції (наприклад, вихідний сигнал перемикання пристрою світлової завіси, вихід датчика положення огорожі і т.п.).
Примітка: Підсистема або її елемент не повинні самі виявляти збій на своїх виходах. Функція реакції на відмову може бути ініційована також будь-якою подальшою підсистемою після виконання діагностичного тесту.
Для функціональної безпеки ПБЕСУ повинна відповідати наступним критеріям щодо електромагнітної стійкості (Directive 2014/30/EU):
- небезпечні умови або небезпеки не повинні вноситься;
- пов'язані з безпекою функції управління повинні виконуватися без збоїв; - виконання ПБФУ, що реалізуються ПБЕСУ, може бути порушено тимчасово або постійно, якщо безпечний стан машини підтримується або досягнуто до виникнення небезпеки. Якщо електромагнітні (ЕМ) явища можуть призвести до пошкодження компонентів, то необхідно впевнитися (наприклад, шляхом аналізу), що вони не будуть впливати на функціональну безпеку, в тому числі і для більш низьких значень параметрів ЕМ явищ, які можуть привести до часткового пошкодження компонентів.
При проектуванні та розробці ПБЕСУ повинні виконуватися наступні основні загальні вимоги:
1. ПБЕСУ повинна бути спроектована і розроблена відповідно до специфікації вимог до безпеки ПБЕСУ.
2. Необхідно дотримуватися чітко структурованого процесу проектування, який повинен бути документально оформлений.
3. Якщо для досягнення необхідної повноти безпеки при виявленні збою є потреба у застосуванні діагностики, то ПБЕСУ повинна забезпечувати виконання заданої функції реакції на відмову.
4. Якщо ПБЕСУ або компонент ПБЕСУ (тобто її підсистема(и)) реалізує(ють) ПБФУ і інші функції, які не стосуються безпеки, то всі її технічні засоби і програмне забезпечення повинні розглядатися як пов'язані з безпекою до тих пір, поки не буде встановлено, що ПБФУ і інші не пов'язані з безпекою функції виконуються досить незалежно (тобто відмова будь-якої функції, що не стосується безпеки, не стане причиною відмови ПБФУ).
5. Якщо ПБЕСУ або її підсистеми реалізують ПБФУ з різними РПБ, то вимоги до апаратних засобів і програмного забезпечення ПБЕСУ або її підсистем повинні визначатися ПБФУ з найвищим РПБ, якщо не буде встановлено, що виконання ПБФУ з різними РПБ досить незалежно.
6. З'єднання (наприклад, провідники, кабелі), крім тих, що використовуються для цифрової передачі даних, повинні розглядатися як елементи однієї з підсистем, до якої вони підключені.
7. Якщо система цифрової передачі даних реалізується як частина ПБЕСУ, то вона повинна задовольняти відповідним вимогам IEC 61508-2 відповідно до цільового значенням РПБ для ПБФУ.
8. Інформація щодо застосування ПБЕСУ повинна визначати методи і заходи, необхідні для використання протягом проектних стадій життєвого циклу ПБЕСУ і забезпечення відповідного РПБ.
Проектування і розробка ПБЕСУ повинні виконуватися відповідно до чітко визначеного процесу, що враховує всі пов'язані з ним аспекти. У стандарті IEC 62061 використовується підхід, заснований на застосуванні структурованого процесу проектування ПБЕСУ. Нижче наведено порядок процесу проектування і термінологія, яка застосовується на різних його стадіях:
1. Визначити пропоновані ПБЕСУ для кожної ПБФУ відповідно до специфікації вимог до системи безпеки (СВСБ).
2. Для кожної функції виконати декомпозицію ПБФУ до функціональних блоків і створити початкову концепцію архітектури.
3. Деталізувати вимоги безпеки для кожного функціонального блоку.
4. Виділити функціональні блоки для підсистем ПБЕСУ.
5. Виконати верифікацію.
Що стосується проектування архітектури ПБЕ- СУ, то кожна ПБФУ, як зазначено в специфікації вимог до безпеки ПБЕСУ, повинна бути структурно декомпозована до рівня функціональних блоків, наприклад, як це показано на рис. 1.
Рисунок 1 - Розподіл вимог до безпеки між функціональними блоками в підсистемах
стандарт програмний електронний система управління
Обов'язково необхідно, щоб така структура була документально оформлена і включала:
- її опис;
- вимоги до безпеки (функціональні вимоги та до повноти безпеки) для кожного функціонального блоку;
- визначення входів і виходів кожного блоку.
Примітки:
1. Процес декомпозиції дозволяє сформувати структуру функціональних блоків, яка повністю описує функціональні вимоги і вимоги до повноти ПБФУ. Цей процес повинен бути застосований до рівня, що дозволяє встановити функціональні вимоги і вимоги до повноти безпеки для кожного функціонального блоку, який буде реалізований в підсистемі.
2. На входах і виходах кожного функціонального блоку може бути інформація, що підлягає обробці (наприклад, про швидкість, положення, режим роботи тощо).
3. Функціональні блоки представляють функції ПБФУ і не включають діагностичні функції ПБЕСУ (для досягнення цілей стандарту IEC 62061-1 діагностичні функції розглядаються як окремі, що можуть мати структуру, відмінну від ПБЕСУ). Необхідно, щоб початкова концепція архітектури ПБЕСУ була створена відповідно до структури функціональних блоків.
Кожен функціональний блок повинен бути реалізований відповідної підсистемою в архітектурі
ПБЕСУ (одна підсистема може реалізовувати в собі більше одного функціонального блоку).
Кожна підсистема і реалізовані в ній функціональні блоки повинні бути чітко визначені.
Необхідно, щоб архітектура була документально оформлена, а її підсистеми і їх взаємозв'язок були детально описані [7-10].
Вимоги до безпеки для кожного функціонального блоку повинні бути сформульовані, як зазначено в специфікації вимог до безпеки відповідної ПБФУ, а саме стосовно:
- функціональних вимог (наприклад, вхідна та вихідна інформація функціонального блоку, внутрішня логіка роботи);
- деталізації вимог до повноти безпеки;
- проектування елементів підсистеми.
Вимоги з безпеки для підсистеми повинні бути такими ж, як і для функціональних блоків, які вона реалізує. Якщо система реалізує більше одного блоку, то для неї застосовується вимога з найбільшим значенням повноти безпеки. Ці вимоги повинні бути документально оформлені у вигляді специфікації вимог до безпеки системи. Процес проектування і розробки підсистеми повинен чітко дотримуватися визначеної процедури, що враховує всі аспекти, які охоплюються цим процесом. Структура даного процесу проектування та розробки підсистеми приведена на рис. 2.
Рисунок 2 - Структура процесу проектування та розробки підсистеми
Висновки
Приведені в даній роботі матеріали повинні допомогти інженерно-технічним працівника щодо запровадження у процес проектування та виготовлення промислового обладнання стандарту IEC 62061, який регламентує вимоги безпеки при проектуванні та розробці пов'язаних з безпекою систем управління, в яких використовуються електричні, електронні та програмовані електронні системи управління. Також ці матеріали свідчать про необхідність подальшої прискореної імплементації вітчизняного та європейського законодавств в сфері промислової безпеки.
Необхідність впровадження в Україні стандарту IEC 62061, який регламентує вимоги безпеки при проектуванні та розробці ПБЕСУ промисловим обладнанням, безумовно, є першочерговою задачею, яку необхідно вирішити, і зробити це необхідно як найшвидше. Без вирішення цієї задачі наша держава не в змозі буде в подальшому ефективно конкурувати на європейському та світовому ринках.
Література
1. Machinery Directive: Directive 2006/42/EC of the European Parliament and of the Council of 17 May 2006. Official Journal of the European Union 09.06.2006. L 157. Pp. 24-86.
2. Бондар-Підгурська О.В. Розробка концептуальної моделі системи управління сталим інноваційним соціально-орієнтованим розвитком економіки України. Вісник Кременчуцького національного університету імені Михайла Остроградського. Вип. 6(95), 2015. С. 25-32.
3. Згуровський М.З., Панкратова Н.Д. Системний аналіз: проблеми, методологія, застосування. К.: Наук. думка, 4. 2005.744 с.
4. Забезпечення промислової та цивільної безпеки в Україні та світі: управління, технології, моделі: колективна монографія. за наук. ред. проф. Матвійчук Л.О. Луцьк: РВВ Луцького НТУ, 2016. 220 с.
5. Analyzing the efficiency of short-term air quality plans in European cities, using the chimere air quality model. P. Thunis, B. Degraeuwe, E. Pisoni, F. Meleux, A. Clappier. Air Qual Atmos Health. 2017. Vol. 10. Р. 235-248.
6. Bhargava R. Atmospheric air pollution monitoring. Indian Journal of Engineering and Material Sciences. 1998. Vol. 5. Р. 249-254.
7. Каштанов С.А. Многофункциональная интегрированная система «ForSec». Системы безопасности. 2003. №2. С. 32-33
8. Levchenko O.G., Kuleshov V.A., Arlamov A.Yu. Noise characteristics during welding in argon- containing shielding gases. The Paton Welding Journal. 2015. №9. P. 53-55.
9. Самойленко М.І., Кобець А.О. Транспортні системи великої вимірності: монографія; за ред.. М.І. Самойленка. Харків: НТМТ, 2010. 212с.
10. Каштанов С.Ф., Полукаров Ю.О., Мітюк Л.О. Особливості сучасного європейського законодавства в сфері реєстрації, оцінки, дозволу та обмеження хімічних речовин. Вісник Кременчуцького національного університету імені Михайла Остроградського. Вип. 6/2018 (113), С. 122-129.
References
1. Machinery Directive: Directive 2006/42/EC of the European Parliament and of the Council of 17 May 2006, Official Journal of the European Union, 09.06.2006, L157, pp. 24-86.
2. Bondar-Pidhurska, O.V. (2015), Development of the conceptual model of the management system of the innovative socially-oriented development of the Ukrainian economy, Transactions of Kremenchuk Mykhailo Ostrohradskyi National University, Vol. 6 (95), pp 2532.
3. Zghurovskyi, M.Z., Pankratova, N.D. (2005), Systemnyi analiz: problemy, metodolohiia, zastosyvannia, [System analisis: problems, methodology, zasosuvannya.], K.: Nauk. Dumka, (vol.4), 744 p.
4. Matvijchuk, L.O. (2016). Zabezpechennya promislovoyi ta tsivilnoyi bezpeki v Ukrayini ta sviti: upravlinnya, tehnologiyi, modeli: kolektivna monografiya [Ensuring industrial and civil security in Ukraine and in the world: management, technology, models], NTU, Lutsk, Ukraine.
5. Thunis, P., Degraeuwe, B., Pisoni, E., Meleux, F., Clappier, A. (2017), “Analyzing the efficiency of shortterm air quality plans in European cities using the chimere air quality model”, Air Qual Atmos Health, vol. 10, pp. 235-248.
6. Bhargava, R. (1998), “Atmospheric air pollution monitoring”, Indian Journal of Engineering and Materials Sciences, vol. 5, pp. 249-254.
7. Kashtanov, S.A. (2003). “Mnogofunktsionalnaya integrirovannaya sistema “ForSec”, Systemy bezopasnosty, no. 2, pp. 32-33.
8. Levchenko, O.G., Kuleshov, V.A., Arlamov, A.Yu. (2015), Noise characteristics during welding in argon-containing shielding gases, The Paton Welding Journal, Vol 9, p. 53-55.
9. Samoylenko, M.I., Kobets, A.O. (2010), Transportni sistemi velikoyi vimirnosti :monografia [Transport systems of large measurableness: monograpf], NTMT, Kharkiv, Ukraine.
10. Kashtanov, S.F., Polukarov, Y.O., Mityuk, L.O. (2018), Peculiarities of modern European legislation in the registration, evalution, permission and limitation of chemical substances, Transactions of Kremenchuk Mykhailo Ostrohradskyi National University, Vol. 6 (113), pp 122-129.
Размещено на allbest.ru
Подобные документы
Проблеми розробки компонентного програмного забезпечення автоматизованих систем управління. Сучасні компонентні технології обробки інформації. Аналіз вибраного середовища проектування програмного забезпечення: мова програмування PHP та Apache HTTP-сервер.
дипломная работа [2,8 M], добавлен 11.05.2012Опис підрозділу гнучких виробничих систем (ГВС) як об‘єкта управління. Проектування алгоритмічного забезпечення системи оперативного управління. Складання розкладу роботи технологічного обладнання. Розробка програмного забезпечення підсистем СОУ ГВС.
курсовая работа [2,0 M], добавлен 11.07.2012Склад і зміст робіт на стадії впровадження інформаційних систем. Технологія проектування систем за CASE-методом. Порівняльні характеристики інформаційних систем в менеджменті та СППР. Створення бази моделей. Визначення інформаційних систем управління.
реферат [44,5 K], добавлен 09.03.2009Класифікація та характеристики інфрачервоних систем. Принцип роботи фотодіода. Встановлення норм часу по розробці дистанційного управління медіасистемою ПК. Основні можливості програми Light Alloy. Вимоги техніки безпеки при роботі з електроприладами.
дипломная работа [1,0 M], добавлен 19.08.2012Загальна класифікація роботів. Проектування та розробка системи управління промисловим роботом "Електроніка НЦ ТМ-01" на базі IBM–сумісного персонального комп’ютера. Структурно функціональна схема взаємодії систем робота. Блок схема системи управління.
дипломная работа [3,6 M], добавлен 25.10.2012Технології об'єктно-орієнтованого аналізу та проектування інформаційних систем. Історія та структура мови UML. Опис функціональної моделі засобами UML. Використання UML в проектуванні програмного забезпечення. Характеристика CASE-засобів Visual Paradigm.
дипломная работа [7,9 M], добавлен 26.05.2012Створення програмного забезпечення для управління продажем та орендою нерухомості. Аналіз роботи підприємства з продажу нерухомості; проектування системи взаємодії клієнта з продавцем; визначення вимог до програмного комплексу, який необхідно розробити.
курсовая работа [3,1 M], добавлен 08.07.2012Розгляд результатів аналізу загальних електронних документів та електронних бібліотечних фондів. Вивчення та характеристика особливостей сучасного документознавства, які полягають, насамперед, у широкому застосуванні комп’ютерних систем оброблення.
статья [31,6 K], добавлен 27.08.2017Вивчення структури Trace Mode - програмного комплексу, призначеного для розробки, налагодження і запуску в реальному часі систем управління технологічними процесами. Базові поняття систем – проект, вузол, об'єкт, канал. Особливості механізму автопобудови.
лабораторная работа [1,3 M], добавлен 20.03.2011Загальна характеристика систем управління проектами. Система автоматизації управління проектами Microsoft Project: властивості, переваги та недоліки. Запуск проекту, введення задач, створення структури, кодування, управління ресурсами та витратами.
контрольная работа [32,5 K], добавлен 03.04.2012