Автоматична перевірка вимог ТЗ у процесі динамічного моделювання

Продовжуючи тему «Які ваші докази?»подивимося на проблему математичного моделювання з іншого боку. Після того, як ми переконалися, що модель відповідає серм'яжній правді життя, можна відповідати на основне запитання: «А що, власне, ми маємо?». Створюючи модель технічного об'єкта, ми зазвичай хочемо переконатися, що цей об'єкт відповідатиме нашим очікуванням. Для цього проводяться динамічні розрахунки процесів і результат порівнюється з вимогами. Це і є цифровий двійник, віртуальний прототип та інше. модні шняги, які на стадії проектування вирішують завдання як зробити так, щоб ми отримали те, що планували.

Як же нам швидко переконається, що наша система це саме те, що ми проектуємо, чи полетить, чи попливе, наша конструкція? А якщо полетить, то як високо? А як попливе, то як глибоко?

У статті розглядається автоматизація перевірки виконання вимог технічного будинку під час створення динамічних моделей технічних систем. Як приклад подивимося на елемент технічного завдання системи повітряного охолодження літального апарату.

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

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

Наприклад, розглянемо такий маленький, але реальний набір вимог:

1. Температура атмосферного повітря на вході до СВО:
   на стоянці – від мінус 35 до 35 ºС,
   у польоті – від мінус 35 до 39 ºС.
2. Статичний тиск атмосферного повітря в польоті – від 700 до 1013 гПа (від 526 до 760 мм рт. ст.).
3. Повний тиск повітря на вході в повітрозабірник СВО у польоті – від 754 до 1200 ГПа (від 566 до 1050 мм рт. ст.).
4. Температура охолоджуючого повітря:
   на стоянці – не більше 27 ºС, для технічних блоків – не більше 29 ºС,
   у польоті – не більше 25 ºС, для технічних блоків – не більше 27 ºС.
5. Витрата охолоджуючого повітря:
   на стоянці – не менше 708 кг/год,
   у польоті – не менше 660 кг/год.
6. Температура повітря у приладових відсіках – не більше 60 ºС.
7. Кількість дрібнодисперсної вільної вологи в охолоджувальному повітрі – не більше 2 г/кг сухого повітря.

Навіть у такому обмеженому наборі вимог можна виділити принаймні дві категорії, які потрібно по-різному обробляти у системі:

• вимоги до умов експлуатації системи (п.п. 1-3);
• параметричні вимоги до системи (п.п. 3-7).

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

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

Ідентифікація та кодування вимог

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

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

У таблиці 1 наведено простий приклад кодування вимог.

1. код джерела вимог R- вимоги ТЗ;
2. код тип вимог Е – вимоги – параметри зовнішнього середовища, або умови експлуатації
   S - вимоги, що забезпечуються системою;
3. код стану літака 0 – будь-яке, G – на стоянці, F – у польоті;
4. код типу фізичних параметрів T – температура, P – тиск, G – витрата, вологість H;
5. номер порядковий вимоги.

ID Вимоги	Опис	Параметр
REGT01	Температура атмосферного повітря на вході до СВО: на стоянці від мінус 35ºС. до 35 ºС.
REFT01	Температура атмосферного повітря на вході до СВО: у польоті – від мінус 35 ºС до 39 ºС.
REFP01	Статичний тиск атмосферного повітря у польоті від 700 до 1013 гПа (від 526 до 760 мм рт. ст.).
REFP02	Повний тиск повітря на вході в повітрозабірник СВО у польоті від 754 до 1200 гПа (від 566 до 1050 мм рт. ст.).
RSGT01	Температура повітря, що охолоджує: на стоянці не більше 27 ºС
RSGT02	Температура повітря, що охолоджує: на стоянці, для технічних блоків не більше 29 ºС
RSFT01	Температура охолоджуючого повітря в польоті трохи більше 25 ºС
RSFT02	Температура повітря, що охолоджує: у польоті, для технічних блоків не більше 27 ºС
RSGG01	Витрата охолоджуючого повітря: на стоянці не менше 708 кг/год
RSFG01	Витрата охолоджуючого повітря: у польоті не менше 660 кг/год
RS0T01	Температура повітря у приладових відсіках не більше 60 ºС
RSH01	Кількість дрібнодисперсної вільної вологи в повітрі, що охолоджує, не більше 2 г/кг сухого повітря

Проект системи перевірки вимог.

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

А якщо перевірка – це алгоритм, то можна використовувати ті самі засоби та інструменти, які ми використовуємо для створення програм управління. Наприклад, середовище SimInTech дозволяє створювати пакети проектів, що містять різні частини моделі, виконані у вигляді окремих проектів (модель об'єкта, модель системи управління, модель довкілля тощо).

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

Можливий приклад оформлення проекту системи наведено малюнку 1.

1. Приклад оформлення проекту перевірки.

Також як алгоритмів управління вимоги можна оформляти вигляді набору листів. Для зручності роботи з алгоритмами серед структурного моделювання типу SimInTech, Simulink, AmeSim використовуються можливості створення багаторівневих структур у вигляді субмоделей. Така організація дозволяє групувати різні вимоги набори для спрощення роботи з масивом вимог, як це робиться для алгоритмів управління (див. рис. 2).

2. Ієрархічна структура моделі перевірки вимог.

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

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

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

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

3. Підключення проекту перевірки до комплексної моделі.

Приклад базового аркуша перевірки вимог представлений малюнку 4. З погляду розробника, він є звичайну розрахункову схему, де у графічному вигляді представлений алгоритм перевірки вимог.

Малюнок 4. Аркуш перевірки вимог.

Основні частини аркуша перевірки описані малюнку 5. Алгоритм перевірки формується аналогічно розрахунковим схемам алгоритмів управління. У правій частині знаходиться блок читання сигналів із бази даних. У цьому блоці відбувається звернення до бази даних сигналів під час моделювання.

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

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

Малюнок 5. Структура розрахункового аркуша перевірки вимог.

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

Наприклад, така вимога:

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

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

Типовий блок перевірки вимог.

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

Блок містить два вхідні порти, param та condition.

На перший подається параметр, що перевіряється. У разі «Температура довкілля».

На другий порт подається булева змінна – умова виконання перевірки.

Якщо другий вхід приходить TRUE (1), то блок виконує розрахунок перевірки вимоги.

Якщо на другий вхід приходить FALSE (0), умови перевірки не виконуються. Це необхідно для того, щоб можна було врахувати умови розрахунку. У нашому випадку цей вхід використовується, щоб увімкнути або вимкнути перевірку залежно від стану моделі. Якщо ЛА під час моделювання знаходиться на землі, то вимоги, що відносяться до польоту, не перевіряються, і навпаки – якщо ЛА знаходиться в польоті, то не перевіряються вимоги, пов'язані з роботою на стоянці.

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

Як параметри даного блоку задаються:

• граничні умови: верхній (UpLimit) та нижній (DownLimit) межі діапазонів, які мають бути перевірені;
• необхідний час витримки системи на граничних діапазонах (TimeInterval) за секунди;
• ідентифікатор вимоги ReqName;
• допустимість виходу за діапазон Out_range – булевська змінна, яка визначає, чи є порушенням вимоги вихід значення за діапазон, що перевіряється.

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

Рисунок 6. Типовий блок перевірки властивості на схемі та її параметри.

В результаті розрахунку даного блоку на виході формується змінна Result, яка набуває наступних значень:

• 0 - rNone, значення не визначено;
• 1 - rDone, вимога виконується;
• 2 – rFault, вимога не виконується.

Зображення блоку містить:

• текст ідентифікатора;
• цифрові відображення параметрів меж вимірювання;
• колірний ідентифікатор стану параметра

Усередині блоку може бути досить складна схема логічного виведення.

Наприклад, для перевірки робочого діапазону температур блоку, наведеного малюнку 6, внутрішня схема представлена ​​малюнку 7.

7. Внутрішня схема блоку визначення діапазону температур.

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

Результати розрахунку передаються на вихід блоку і одночасно записуються до загального файлу звіту, який створюється на підставі результатів по всьому проекту. (Див. рис. 8)

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

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

Результати розрахунку передаються на вихід блоку і одночасно записуються до загального файлу звіту, який створюється на підставі результатів по всьому проекту. (Див. рис. 8)

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

Рисунок 8. Приклад файлу звіту за результатами моделювання.

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

Рисунок 9. Налаштування формату звіту у глобальних сигналах проекту

Використання бази даних сигналів для вимог.

Для автоматизації роботи з налаштуваннями властивостей кожного типового блоку створюється типова структура у базі даних сигналів. (Див. рис. 10)

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

База даних сигналів забезпечує:

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

Структури бази даних сигналів для вимог можуть бути легко налаштовані на роботу із сторонньою системою керування вимогами, Загальна схема взаємодії із системами керування вимог представлена ​​на малюнку 11.

Малюнок 11. Схема взаємодії із системою управління вимог.

Послідовність взаємодії тестового проекту SimInTech із системою управління вимоги така:

1. Технічне завдання розбивається вимоги.
2. Виділяються такі вимоги технічного завдання, які можна перевірити шляхом математичного моделювання технічних процесів.
3. Атрибути виділених вимог передаються до бази даних сигналів SimInTech у структури типових блоків (наприклад, максимальна та мінімальна температура).
4. У процесі розрахунку дані структур передаються до розрахункових схем блоків, виконується аналіз і результати зберігаються базу даних сигналів.
5. Після розрахунку результати аналізу передаються до системи управління вимогами.

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

Висновки.

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

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

Джерело: habr.com