Модельно-орієнтоване проєктування

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку

Модельно-орієнтоване проєктування (англ. Model-based design, MBD) — це математичний та наочний метод розв'язання проблем, пов’язаних із проєктуванням комплексного управління, обробкою сигналів [1] та систем зв’язку. Він використовується в багатьох системах управління рухом, промисловому обладнанні, аерокосмічній та автомобільній промисловості. [2] [3] [4] Модельно-орієнтоване проєктування — це методологія, яка застосовується при розробці вбудованого програмного забезпечення. [5] [6]

Огляд[ред. | ред. код]

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

  1. Моделювання об'єкту управління.
  2. Аналіз і синтез системи управління (controller for the plant).
  3. Моделювання керівної системи та об'єкту управління (simulating the plant and controller).
  4. Інтеграція всіх цих етапів шляхом розгортання контролера (deploying the controller).

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

Історія[ред. | ред. код]

Початок епохи електрики приніс багато інноваційних і передових систем управління. Ще в 1920-х роках два аспекти інженерії, теорії управління та систем управління, злилися, щоб зробити можливими великомасштабні інтегровані системи. У ті ранні часи системи управління широко використовувалися у промисловому середовищі. Великі технологічні об’єкти почали використовувати технологічні контролери для регулювання безперервних змінних, таких як температура, тиск і швидкість потоку. Електричні реле, вбудовані у ланцюгові схеми (ladder-like networks), були одними з перших дискретних керівних пристроїв, які автоматизували весь виробничий процес.

Системи управління набрали обертів, насамперед у автомобільній та аерокосмічній сферах. У 1950-х і 1960-х роках поштовх до космосу викликав інтерес до вбудованих систем управління. Інженери сконструювали системи керування, такі як блоки керування двигуном та симулятори польоту, які могли бути частиною кінцевого продукту. До кінця двадцятого століття вбудовані системи керування були повсюдно, оскільки навіть велика побутова техніка (white goods), такі як пральні машини та кондиціонери, містили складні та просунуті алгоритми керування, що робило їх набагато «розумнішими».

У 1969 році були представлені перші комп'ютерні контролери. Ці ранні програмовані логічні контролери (ПЛК) імітували роботу вже доступних технологій дискретного керування, які використовували застарілі релейні сходи. Поява технології ПК принесла різкі зміни на ринку процесів і дискретного контролю. Готовий робочий стіл, завантажений відповідним апаратним і програмним забезпеченням, може запускати весь процес, виконувати складні та встановлені алгоритми PID або працювати як розподілена система керування (DCS).

Кроки[ред. | ред. код]

Основними кроками процесу модельно-орієнтованого проєктування є:

  1. Моделювання об'єкту управління (Plant modeling). Моделювання об'єкта управління може базуватися на даних або на Першому принципі. Моделювання об'єкта на основі даних використовує такі методи, як ідентифікація системи. При ідентифікації системи модель об'єкта управління ідентифікується шляхом отримання та обробки необроблених даних із реальної системи та вибору математичного алгоритму для ідентифікації математичної моделі. Різні види аналізу та моделювання можуть бути виконані з використанням ідентифікованої моделі, перш ніж вона буде використана для розробки керівної системи на основі моделі. Моделювання на основі першого принципу засноване на створенні моделі блок-схеми, яка реалізує відомі диференціально-алгебраїчні рівняння, що керують динамікою об'єкта. Типом моделювання на основі першого принципу є фізичне моделювання, де модель складається з пов’язаних блоків, які представляють фізичні елементи фактичного об'єкта управління.
  2. Аналіз та синтез системи керування (Controller analysis and synthesis) Математична модель, задумана на кроці 1, використовується для визначення динамічних характеристик моделі об'єкта управління. Потім на основі цих характеристик можна синтезувати систему керування.
  3. Офлайн моделювання та моделювання в режимі реального часу. Досліджено часову реакцію динамічної системи на складні, що змінюються в часі входи. Це робиться шляхом моделювання простої моделі LTI (лінійної інваріантної в часі) або моделювання нелінійної моделі установки за допомогою контролера. Моделювання дозволяє виявити специфікації, вимоги та помилки моделювання негайно, а не пізніше в процесі проєктування. Симуляцію в режимі реального часу можна виконати шляхом автоматичного створення коду для контролера, розробленого на кроці 2. Цей код можна розгорнути на спеціальному комп’ютері для створення прототипів у реальному часі, який може запускати код і керувати роботою заводу. Якщо прототип заводу недоступний, або випробування на прототипі є небезпечним або дорогим, код може бути автоматично згенерований з моделі заводу. Цей код можна розгорнути на спеціальному комп’ютері реального часу, який можна підключити до цільового процесора за допомогою коду контролера. Таким чином, контролер можна протестувати в режимі реального часу з моделлю заводу в режимі реального часу.
  4. Розгортання (Deployment). В ідеалі це робиться за допомогою генерації коду з контролера, розробленого на кроці 2. Малоймовірно, що контролер буде працювати на фактичній системі так добре, як це було під час моделювання, тому ітераційний процес налагодження виконується шляхом аналізу результатів на фактичній цілі та оновлення моделі контролера. Інструменти проєктування на основі моделі дозволяють виконувати всі ці ітераційні кроки в єдиному візуальному середовищі.

Недоліки[ред. | ред. код]

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

  • Одним з основних недоліків є те, що застосований підхід є загальним або загальним підходом до стандартної розробки вбудованих і систем. Часто час, необхідний для портування між процесорами та екосистемами, може переважити тимчасову цінність, яку він пропонує в простіших лабораторних реалізаціях.
  • Більша частина ланцюжка інструментів компіляції є закритим вихідним кодом і схильна до помилок огорожі та інших подібних поширених помилок компіляції, які легко виправляються в традиційній системній інженерії.
  • Шаблони проєктування та повторного використання можуть призвести до реалізації моделей, які погано підходять для цього завдання. Наприклад, реалізація контролера для виробництва конвеєрних стрічок, який використовує термодатчик, датчик швидкості та датчик струму. Ця модель, як правило, не дуже підходить для повторної реалізації в контролері двигуна тощо. Хоча дуже легко перенести таку модель і внести в неї всі помилки програмного забезпечення.


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

Переваги[ред. | ред. код]

Деякі з переваг, які пропонує модельно-орієнтоване проєктування у порівнянні з традиційним підходом:

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

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

Інструменти графічного моделювання спрямовані на покращення цих аспектів розробок. Ці інструменти забезпечують дуже загальне та уніфіковане середовище графічного моделювання, і вони зменшують складність проєктів моделей, розбиваючи їх на ієрархії окремих блоків проєктування. Таким чином, проєктувальники можуть досягти кількох рівнів точності моделі, просто замінивши один елемент блоку іншим. Графічні моделі також допомагають інженерам концептуалізувати всю систему і спрощують процес перенесення моделі з однієї стадії на іншу в процесі проєктування. Симулятор Boeing EASY5 був одним із перших інструментів моделювання, які отримали графічний інтерфейс користувача разом з AMESim, багатодоменною багаторівневою платформою, заснованою на теорії Bond Graph. Незабаром за цим виникнули такі інструменти, як 20-sim і Dymola, які дозволили складати моделі з фізичних компонентів, таких як маси, пружини, резистори тощо. Пізніше за ними виникнули багато інших сучасних інструментів, таких як Simulink і LabVIEW.

Дивись також[ред. | ред. код]

Посилання[ред. | ред. код]

 

  1. . ISBN 0-86341-560-1. {{cite conference}}: Пропущений або порожній |title= (довідка)
  2. A Software Safety Certification Plug-in for Automated Code Generators: Feasibility Study and Preliminary Design (PDF). Архів оригіналу (PDF) за 26 січня 2017. Процитовано 15 листопада 2021.
  3. General Motors Developed Two-Mode Hybrid Powertrain With MathWorks Model-Based Design; Cut 24 Months Off Expected Dev Time. Архів оригіналу за 24 липня 2017. Процитовано 15 листопада 2021.
  4. Dias, B. M. D.; Laganá, A. A. M.; Justo, J. F.; Yoshika, L. R.; Santos, M. M. D.; Gu, Z. H. (2018). Model-Based Development of an Engine Control Module for a Spark Ignition Engine. IEEE Access. 6: 53638-53649. doi:10.1109/ACCESS.2018.2870061.
  5. Nicolescu, Gabriela; Mosterman, Pieter J., ред. (2010). Model-Based Design for Embedded Systems. Computational Analysis, Synthesis, and Design of Dynamic Systems. Т. 1. Boca Raton: CRC Press. ISBN 978-1-4200-6784-2.
  6. Model-based design reshaping Disney parks. Архів оригіналу за 28 серпня 2016. Процитовано 18 лютого 2016.