Як ми можемо знати, що формальні методи працюють?

Важлива мета формальних методів - довести правильність систем, або автоматизованими, або людськими способами. Однак, схоже, що навіть якщо ви зможете надати підтвердження правильності, ви, можливо, НЕ зможете гарантувати, що система не вийде з ладу. Наприклад:

• Специфікація може не моделювати систему належним чином, або виробнича система може бути надто складною для моделювання, або ж система може бути помилковою через суперечливі вимоги. Які методи відомі для перевірки, чи специфікація має сенс взагалі?
• Процес доказування може бути помилковим! Хто знає, що ці правила умовиводу є правильними та законними? Крім того, докази можуть бути дуже великими, і як ми можемо знати, що вони не містять помилок? Це серце критики "Мільто, Ліптона та Перліса" "Соціальні процеси та докази теорем і програм". Як дослідники сучасних формальних методів реагують на цю критику?
• Під час виконання існує багато недетермінованих подій та факторів, які можуть серйозно вплинути на систему. Наприклад, космічні промені можуть змінювати оперативну пам’ять непередбачуваними способами, і в цілому ми не маємо гарантій, що обладнання не зазнає візантійських помилок, проти яких Лампорт виявився дуже важким. Тож правильність статичної системи не гарантує, що система не вийде з ладу! Чи існують якісь методи, які пояснюють помилковість справжнього обладнання?
• В даний час тестування є найважливішим інструментом для встановлення того, що працює програмне забезпечення. Схоже, це має бути додатковим інструментом з формальними методами. Однак я в основному бачу дослідження, які орієнтовані або на формальні методи, або на тестування. Що відомо про поєднання двох?

Щодо 4: Є багато роботи, що поєднує формальні методи та тестування. "Тестування формальних методів" на Гуглі виявляє досить велику роботу. Хоча існує багато різних цілей такої роботи, одна з ключових цілей - створити більш ефективні набори тестів. Ця розмова дає приємний вступ, заснований на перевірці моделі.

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

Щодо пункту 3: Деяка робота була проведена для перевірки систем у налаштуваннях, де помилки явно моделюються, зокрема несправна логіка: обґрунтування помилкових програм. Метью Меола та Девід Уокер. Європейський симпозіум з програмування, 2010 р. Робота над імовірнісною перевіркою моделі та ймовірнісною верифікацією, безумовно, також певною мірою вирішує питання несправностей.

Ваші бали в порядку:

• Правильність усіх специфікацій в кінцевому рахунку суб'єктивна: вони сприймаються як правильно вирішити проблему відповідно до своїх користувачів, або вони ні. Немає уникнути цього - це розробка програмного забезпечення, і жоден метод не має срібної кулі для цього.
• Багато роботи спрямовано на те, щоб довести, що процес правильний щодо його припущень. Зазвичай експертам доступна інформація для підтвердження цих правил. Будь-яка діяльність людини піддається помилкам, але дуже формалізовані системи, що використовують добре вивчені підходи, значно менше піддаються помилкам, ніж майже всі інші людські процеси.
• У якийсь момент будь-яка система перебуває у режимі відмови поза межами цієї системи. Вам все-таки краще усунути всі передбачувані джерела помилок, навіть якщо ви залишили без уваги деякі непередбачувані.
• Тестування та доведення можуть легко співіснувати. Тестування є менш специфічним, більш спеціальним процесом, тому ви можете знайти менше формальної роботи над ним. Але вас може зацікавити такий інструмент, як QuickCheck, який доповнює тести доказів, пропонованих системою типу Haskell.

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

Ніякі мікрокораблі без їх логіки, що підлягають перевірці функціональної еквівалентності; без його ФПУ не підлягало ФВ; без протоколів узгодженості кешу, які підлягали FV (це було з 1995 року).

Якщо очевидні відмінності між програмними та інженерними фізичними системами (наприклад, мости, куди можна додати чинники безпеки), вони відіграють роль інженерної математики в КС. Однак використання FM завжди залежить від вигоди / вартості. Тестування Fuzz окупається великим часом у таких компаніях, як Microsoft (Google SAGE за один слайд).

Навіть всередині мікроконтролера є підсистеми (наприклад, мікропроцесорні трубопроводи), де FV не мав такого ж впливу, як в іншому місці (наприклад, FPU, де звичайні тестування взагалі не проводилися в багатьох випадках, коли формальна символічна оцінка траєкторії доводила відсутність помилок : Kaivola та ін. CAV'09).

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

Щодо 2: якщо система формалізована у помічника перевірки (наприклад, Twelf або Agda або Coq) і перевіряються властивості надійності та повноти, а докази виконуються в цьому кодуванні, це не проблема. Можливо, ви формалізували систему, яка не описує те, що ви задумали, але, принаймні, не матимете неправильних доказів чи зламану систему, в якій ви міркуєте.

Однак, схоже, що навіть якщо ви зможете надати підтвердження правильності, ви, можливо, НЕ зможете гарантувати, що система не вийде з ладу.

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

Які методи відомі для перевірки, чи специфікація має сенс взагалі?

Можливо, вас зацікавлять інструменти перевірки моделей щодо специфікацій офіційних систем .

Процес доказування може бути помилковим! Хто знає, що ці правила умовиводу є правильними та законними?

Я думаю (через теорему про незавершеність Геделя) показ системи правил виводу є послідовним обов'язково апеляцією до ще більш потужного набору правил виводу.

Крім того, докази можуть бути дуже великими, і як ми можемо знати, що вони не містять помилок?

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

Чи є відомі методи для обліку помилковості реального обладнання?

Як щодо мови збірки, набраної відмов ?

Однак я в основному бачу дослідження, які орієнтовані або на формальні методи, або на тестування. Що відомо про поєднання двох?

"Конференція TAP присвячена зближенню доказів і тестів" .

Тільки гугл для "доказів і випробувань" має кілька хороших хітів вище рази.

Які методи відомі для перевірки, чи специфікація має сенс взагалі?

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

Чи є відомі методи для обліку помилковості реального обладнання?

Звичайно, є поле перевірки, відоме як перевірка виконання , ви також можете перевірити модель, що базується на виконанні реальної системи, що працює в абсолютно віртуальному середовищі, залежно від конкретного сценарію (я сприяв цьому за допомогою V-DS + APMC ). Однак це, очевидно, є основною проблемою, щоб додати взаємодію між системою та середовищем до процесу верифікації.

Однак я в основному бачу дослідження, які орієнтовані або на формальні методи, або на тестування. Що відомо про поєднання двох?

Нічого собі, сьогодні я буду абсолютно безсоромно і знову цитую себе. З співавторами, які ми працюємо над поєднанням перевірки та тестування моделей, ви можете переглянути список публікацій колишнього докторанта нашої групи або пошукати "приблизну перевірку ймовірнісної моделі" або "перевірку статистичної моделі" в будь-якій хорошій пошуковій системі (робота виконана Younes et al., Sen et al. Або я та ін. Та багато інших).

Можливо, вам будуть дуже цікаві роботи Джона Рашбі , одного з розробників теореми PVS, який загалом зацікавлений саме у вказаних вами моментах. Вам може сподобатися, читаючи цей класичний звіт до FAA про використання формальних методів та сертифікацію критичних систем (1993) , а також його новіші статті про збірку ймовірних, формальних випадків безпеки з різних наданих доказів (тестування, докази, аналізи тощо).