4.2: Перевірка та валідація

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

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

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

Як описано багатьма авторами (Balci, 1994; Balci, 1996; Banks, Carson, Nelson and Nicol, 2009; Carson, 2002; Law, 2007; Sargent, 2009), перевірка та перевірка вимагають збору доказів того, що модель та її комп'ютерна реалізація точно представляють досліджувану систему щодо питань проекту і цілі рішення. Перевірка та валідація - це питання ступеня. У міру отримання більшої кількості доказів, тим більша ступінь впевненості в тому, що модель перевірена та дійсна, збільшується. Однак слід пам'ятати, що абсолютної впевненості (100%) досягти неможливо. Завжди будуть певні сумніви щодо того, чи перевірена та перевірена модель.

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

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

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

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

Малюнок 4-1: Приклад двох робочих станцій у послідовності, повторюється

4.2.1 Процедури верифікації

Далі слідують деякі загальнозастосовні методи пошуку доказів перевірки.

1. Наприклад, на двох робочих станціях у серійній моделі має триматися таке рівняння «балансу сутностей»:

   Кількість суб'єктів, що входять до системи =

   кількість сутностей, що відходять від системи + кількість об'єктів, що залишилися в системі в кінці моделювання

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

   Кількість суб'єктів, що входять до системи, складається з кількості суб'єктів, спочатку там на початку моделювання плюс кількість суб'єктів, що надходять під час моделювання.

   Наприклад, для одного моделювання двох робочих станцій у серійній моделі було 14359 об'єктів, які прибули до моделі, 6 яких були там спочатку. В кінці моделювання було 14357 суб'єктів, які відійшли та дві сутності в системі. Одна з двох сутностей була в роботі робочої станції А, а інша - в роботі робочої станції B.

2. Етапи процесу в моделі, реалізованої в комп'ютерній версії моделі і концептуальної моделі, повинні відповідати і будь-які відмінності повинні бути виправлені або обґрунтовані.

   Етапи процесу на двох робочих станціях у моделі серії такі:

   1. Приїжджайте в систему.
   2. Введіть вхідний буфер робочої станції A.
   3. Трансформуватися робочою станцією A операція.
   4. Переміщатися і ввести вхідний буфер робочої станції B.
   5. Трансформуватися робочою станцією B.
   6. Відходимо від системи.
3. Реалізація моделі повинна включати перевірку, необхідну для забезпечення правильності введення та використання значень вхідних параметрів.

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

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

   Наприклад, припустимо, модель двох станцій серії моделювалася протягом 40 годин із середнім часом між заїздами 10 секунд. Очікувана кількість прибуття становитиме 14400 (= 40 годин/10 секунд). Припустимо, було зроблено 20 незалежних симуляцій, а кількість прибуття коливалася від 14128 до 14722. Оскільки цей діапазон включає 14400, будуть отримані докази перевірки. Як зробити самостійне моделювання розглянуто в розділі 4.3 і далі.

   Крім того, можна обчислити довірчий інтервал для справжньої середньої кількості прибуття. Якщо цей довірчий інтервал включає очікувану кількість прибуття, буде отримано підтвердження підтвердження. У тому ж прикладі 95% довірчий інтервал для середньої кількості прибуття становить від 14319 до 14457. Знову ж таки, отримані перевірочні докази.

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

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

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

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

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

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

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

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

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

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

4.2.2 Процедури перевірки

Далі слідують деякі загальнозастосовні методи пошуку доказів перевірки.

1. Це повторення принципу 11 глави 1. Наприклад, середня кількість зайнятих одиниць ресурсу можна легко обчислити, як описано в розділі 6.

   У двох робочих станціях у серійній моделі припустимо, що час роботи на другій робочій станції є постійною 8,5 секунди, а середній час між заходами становить 10 секунд. Відсоток часу зайнятості для робочої станції B дорівнює 8,5/10 секунд або 85%. Моделювання робочої станції надає дані, з яких можна оцінити відсоток зайнятого часу. Діапазон використання робочої станції B за кількома незалежними моделюваннями становить від 83% до 87%. Довірчий інтервал для справжнього середнього використання також може бути обчислений. Довірчий інтервал 95% становить від 84,4 до 85,4. Таким чином, отримують валідаційні докази.

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

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

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

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

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

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

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

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

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

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

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

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

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

   Наприклад, в промисловому зразку розділу 1.2 системні експерти вважали, що порожні залізничні вагони провели на заводі від 6 до 7 днів. Результати моделювання підрахували, що порожні вагони провели в середньому 6,6 днів на заводі. Таким чином, були отримані валідаційні докази.