Failsafe что это за программа

Кто знает что за функция такая Fail-Safe?

Регистрируясь на данном ресурсе Вы соглашаетесь с действующими Правилами форума и обязуетесь их соблюдать.
Незнание правил не освобождает Вас от наказания за их нарушение!

На форуме действует ряд ограничений для новых пользователей: запрещено заниматься торговлей, устанавливать автар и подпись, принимать участие в опросах, личный ящик ограничен 10-ю сообщениями.
Для снятия ограничений Вам надо оставить на форуме более 10 сообщений, а также с момента вашей регистрации должно пройти не менее 30 дней.

Для участников клуба доступна различная клубная атрибутика: рамки, наклейки, футболки, толстовки, кружки, карты и т.д. Причем некоторые виды атрибутики распространяются бесплатно на встречах. Более подробную информацию узнавайте в своем региональном разделе или теме. Также если Вы хотите заниматься клубной атрибутикой в своем городе, то напишите об этом администрации.

Источник: tourerv.ru

Настройка FAILSAFE в OpenTX и BetaFlight / INAV для новичков!

Failsafe: что это такое, как работает и настройка

Если у вас гоночный квадрокоптер, то рано или поздно вы упадете или врежетесь. Со съемочными это сделать сложнее, все-таки скорость маленькая и датчиков больше. Никакая радиоаппаратура управления не идеальна и когда-нибудь даст сбой. Что произойдет, если пропадет связь с квадрокоптером? Сработает функция Failsafe.

О функции, что она делает, как работает и о ее настройке вы узнаете ниже.

Что такое Failsafe?

Failsafe — это функция, которая будет управлять вашим квадрокоптером в тот момент, когда вы потеряете с ним радиосвязь. Простыми словами, вы улетели за дом или препятствие, связь оборвалась, но квадрокоптер не полетит дальше, так как у него сработает функция Failsafe, и выполнит действия, которые вы определили в настройках.

Российские пилоты так и называют эту функцию: «фэйлсэйф» или «файлсэйф». Есть еще аббревиатуры: «F/S» и «FS», они означают Failsafe в сокращении. Это полезно знать, если вы ищите ответ на англоязычных ресурсах.

Как работает Failsafe?

Failsafe работает так: вы физически теряете радиосвязь с квадрокоптером, это узнает пульт управления и будет постоянно пытаться восстановить связь. В этот же момент приемник на дроне поймет, что не получает сигнал с пульта управления и сообщит об этом полетному контроллеру. Полетный контроллер моментально обработает эту информацию и запустит функцию Failsafe. Дальнейшие действия зависят от конкретных настроек функции.

Настройка FailSafe на APM 2.6/ Customize FailSafe on APM 2.6

Эта функция срабатывает автоматически, но ее можно также настроить на какой-нибудь тумблер и включать принудительно. Например, если у вас есть GPS и вы чувствуете, что теряете управление, лучше включить Failsafe, и дрон сам вернется на то место, откуда он взлетел, главное, чтобы не было препятствий на его пути. Если у вас гоночный, то он просто отключит двигатели и упадет либо будет медленно снижаться.

Зачем нужен Failsafe?

Функция Failsafe предотвращает потерю квадрокоптера. Ваш квадрокоптер не полетит дальше, если потеряется связь — без настройки failsafe дрон летит дальше в том направлении, в котором он летел в момент потери связи.

Как уже говорилось выше, если у вашего дрона есть GPS и барометр, то вы можете настроить ему функцию возврата домой при потере связи, и он должен мягко приземлиться на точку, откуда взлетал. Но это не подходит для гоночных и фристайл-дронов, потому что такие датчики на них не ставят из-за ограниченного веса и места, да и не используются они там. Если вы настроите возврат домой без датчиков, то ничего хорошего не получится, данные брать неоткуда, да и даже простое снижение может нанести повреждения объектам и людям, так как пропеллеры крутятся с огромной скоростью. Летающая мясорубка.

Ниже расскажем, какой режим Failsafe следует настраивать гоночным квадрокоптерам.

Настройка Failsafe в Betaflight

Запустите Betaflight, поставьте галку для включения Режима эксперта (expert mode, в правом верхнем углу). У вас появится вкладка Failsafe.

Перед любыми манипуляциями и настройками квадрокоптера снимайте с него пропеллеры!

Valid Range (Допустимый диапазон)

Каждый стандартный радиоканал имеет диапазон от 1000 до 2000. Эти пределы можно делать больше также и через пульт управления, но для гоночных дронов этого делать не рекомендуем. В Valid Pulse Range Settings настраивается значение, как далеко вы должны «выйти» за пределы сигнала, чтобы полетный контроллер включил функцию Failsafe. Простыми словами, насколько слабый должен быть сигнал (а там уже начнутся проблемы с управлением, так как сигнала по факту почти не будет), чтобы сработала функция Failsafe.

В этом блоке значения по умолчанию: 885 и 2115, и их очень редко меняют, или если вы не будете вносить изменения в «end points» в пульте. Советуем не трогать эти цифры, если у вас нет каких-либо проблем с аппаратурой.

Шаг 1

Настройка и работа Failsafe начинается с блока «Channel Fallback Settings«. Здесь у каждого канала указано то, что с ним произойдет после активации функции спасения.

У throttle, pitch, roll и yaw (газ, вправовлево, вверхвниз и по своей оси, если вы еще этого не знаете) есть два пункта во вкладке:

Для AUX-каналов (эти каналы вы можете настроить на любой переключатель):

Что означают эти слова на практике?

• Hold — это значит, что канал будет удерживать свое положениепозицию как и в момент, когда пропал сигнал.
• Auto — тут есть тонкость:
  — Throttle (газ) снизится до минимума (выключится);
  — Roll, Pitch и Yaw уйдут в центр (будто стик на пульте будет по центру);
• Set — позволит вам выбрать конкретное значение, которое будет использовано, для этого появится текстовая область.

Шаг 1 активен только в течение короткого промежутка времени, это время настраивается на шаге 2. Хорошим временем считается 0.4 сек. Так как это все длится 0.4 секунды, получается, что незачем вмешиваться в настройки блока выше, слишком уж мало времени он будет задействован.

Шаг 1 полезен для вылавливания временных контрольных сигналов, например, если что-то было в качестве препятствия между вами и дроном. Если было препятствие и за это время дрон успел улететь из его зоны (когда сигнал совсем не проходит или крайне слабый), то управление не будет потеряно и дрон продолжит выполнять ваши команды. Это такая буферная зона, чтобы связь успела восстановиться.

Если вы обычно летаете в режимах acroratehorizon, то roll, pitch и yaw, следует установить на «Auto». Если дрон вращается в момент срабатывания Failsafe, то значение «Auto» остановит его, а вот со значением «Hold» квадрокоптер продолжит вращаться.

Пилотам, летающим в режиме ANGLE, рекомендуется оставлять значения в Auto, так как Auto будет выравнивать квадрокоптер.

Hold тоже можно использовать в ANGLE, но дрон просто продолжит лететь в том направлении и под тем углом, в каком летел до потери связи.

Для Throttle не прекращаются споры в вопросе, какой метод безопаснее:

• Auto — параметр будет полностью выключать двигатели. Таким образом, предполагается, что пропеллеры никому не смогут навредить при столкновении.
• Hold — пропеллеры будут крутиться с той скоростью, которую вы установите в настройках. Появляется возможность вернуть управление.

Рекомендуем сделать так:

Для Throttle поставить Auto. Для AUX — Hold

Шаг 2

Эти настройки включаются после отработки таймера 1 шага — этот таймер вы настраиваете в Stage 2 — Settings, как на скрине выше, где цифры 4 и 100.

В блоке Stage 2 — Failsafe Procedure вы выбираете, что делать дрону после срабатывания функции спасения — падать или приземляться. В сети очень много споров и мнений по поводу того, какой режим выбрать. Мы заранее рекомендуем — Drop.

Есть два режима того, как приземлиться квадрокоптеру:

Что такое Drop — этот режим сразу отключает все двигатели, дрон падает на землю. Или на голову кому-нибудь.

Что такое Land — двигатели начинают вращаться на низких оборотах, а акселерометр начинает выравнивать дрон и происходит посадка. Дрон все также может приземлиться кому-нибудь на голову, но к этому прибавляются еще и крутящиеся пропеллеры. Кроме того, контроллер полета все равно не поймет, когда он коснется земли и двигатели продолжат крутиться с той же силой, и если они заденут пропеллерами ветку/мусор и т.д., то последствия можно представить + могут сломаться не только лопасти, но и сам двигатель.

Вот об этом и споры — что безопаснее. Выбор за вами, но мы рекомендуем Drop.

Для режима Land есть настройка Throttle value used while landing — указывается уровень газа при активации режима. Будьте аккуратны при указывании числа, так как если поставите слишком большие обороты, то дрон вместо посадки улетит по своим делам.

Вторая настройка Delay for turning off the Motors during Failsafe — указывается время, через которое отключатся моторы после активации режима Land функции Failsafe. 1 = 0.1 секунды.

Тестирование и нюансы Failsafe

Тестирование следует проводить только в поле, вдали от людей, линий электропередач и прочих объектов.

При тестировании используйте заряженные аккумуляторы, например 4S, так как в зависимости от уровня заряда будет меняться и тяга. Значение 1500 будет разным при использовании только что заряженного и уже разряженного. Почему заряженный? Если на разряженном он у вас медленно приземляется, то при заряженном, скорее всего, наоборот, будет подниматься выше.

Вам также стоит знать один нюанс: после автоматического срабатывания Failsafe включается проверка безопасности полетного контроллера и вам не удастся снова заармить дрон, пока не пройдет 30 секунд после восстановления связи. Простыми словами — вы залетели за дом, сработал Failsafe, дрон упал, вы побежали за ним, пульт и приемник «увидели» друг друга, связь восстановилась, но вот беда — дрон не запускается. Тут многие начинают искать проблему, думают, что что-то сломалось, а на самом деле просто нужно подождать 30 сек. и попробовать заармить его снова.

Если вы включаете Failsafe руками через тумблер, то у вас есть 3 секунды, чтобы отключить режим спасения и вернуть управление в свои руки — если не успели, то дрон будет завершать свой сценарий спасения самостоятельно.

Во время выполнения шага 1 и 2 вы все еще можете перехватить управление! НО, если выбран режим Drop — у вас этого времени почти не будет, зато это безопаснее. В режиме Land у вас будет столько времени, сколько вы указали в Delay for turning off the Motors during Failsafe

Еще один нюанс: как только приемник «поймает» сигнал с пульта, он моментально передаст значения с пульта в полетный контроллер, то есть это все произойдет без предупреждения и дрон сразу «газанет» вверх/вбок/вниз и так далее. Достаточно непредсказуемый этот режим Land. Можно еще сильнее ухудшить ситуацию, поэтому еще один голос в пользу Drop.

Как установить Failsafe на тумблер/переключатель

Назначить функцию спасения на тумблер очень просто. Заходите в Betaflight во вкладку Modes и делаете примерно так, как на скрине выше, то есть ищите FAILSAFE и назначаете любой свободный тумблер, а ползунками выбираете промежуток для активации функции.

Также после назначения нужно выбрать, на какой шаг вы сразу перейдете после активации функции тумблером:

Настройка Failsafe на аппаратуре управления (на пульте)

У каждой аппаратуры управления есть возможность настроить собственную систему Failsafe. Лишняя подстраховка не помешает, потому что в зависимости от настроек аппаратуры управления полетный контроллер может не понять, что связь потеряна.

FrSky

Приемники FrSky (то, что вы ставите в дрон) получают настройки Failsafe из пульта управления.

Вам нужно зайти в меню модели, далее на странице Model Setup перейдите к настройке “Failsafe” или “Failsafe mode”. Здесь вы можете выбрать, что делать после потери сигнала:

• No pulses — все каналы на 0 (выключаются).
• Receiver — управление передается приемнику, то есть сработают настройки, заложенные в приемник.
• Custom — позволяет вам задать собственные настройки каждому каналу.
• Hold — удержание всех позиций каналов со значениями на момент потери сигнала на неопределенное время.
• Not set — все каналы на 0, но пользователь предупреждается, что он сознательно не настроил режим срабатывания Failsafe.

Для того, чтобы работали настройки Betaflight, необходимо установить режим No pulses.

На многих приемниках FrSky есть кнопка для настройки Failsafe, прочитайте инструкцию для вашего приемника по использованию этой кнопки.

Spektrum

У спектрумов Failsafe настраивается в момент привязки приемник-передатчик. Установите на пульте стик газа на 0, а правый стик в середину, затем выполните процедуру привязки. При необходимости «развяжите» их и выполните действие еще раз.

FlySky

Настройка Failsafe у флайскай немного мудреная, тут не ограничиться одним абзацем, поэтому почитайте информацию в нашей другой статье: https://profpv.ru/как-настроить-и-установить-flysky-fs-ia6b/

Заключение

После настройки Failsafe вам останется включить пищалку (зуммер) при активации функции спасения. Включить пищалку можно во вкладке Configuration в Betaflight, строчка называется RX_LOST. Пищалка поможет быстро найти ваш дрон в траве или на местности, так как писк будет сильным и громким.

Если у вас нет зуммера (пищалки), но используется протокол DShot, то вы можете настроить регуляторы оборотов, чтобы они начали пищать моторами. Это тоже делается во вкладке Конфигурация в Бетафлайт.

Говорят, что таким способом вы перегреете двигатели, но мы протестировали в течение часа такой способ и моторы не перегрелись. Второй тест — зажали моторы и испытывали в течение получаса, моторы тоже не перегрелись. В любом случае лучше потерять 1-2 мотора, чем весь квадрокоптер.

Всегда настраивайте Failsafe!

Источник: profpv.ru

Настройка FailSafe

В статье рассказано для чего нужен FailSafe (FS, ‘фэйлсейф’) и как его настроить. Данный режим является обязательным, чтобы полет не оказался последним!

В алгоритме ArduPilot предусмотрена защита коптера при нештатных ситуациях. Самым простым примером может быть потеря сигнала радиоуправления или разряд аккумулятора. При потере связи данный режим позволит выполнить автоматический возврат коптера на точку взлета («дом»). При разряде аккумулятора тоже будет делать это действие.

Срабатывание режима также предусматривает возможность возврата домой при обрыве связи телеметрии. Но чтобы работал режим возврата домой — необходимо, чтобы работал GPS и был 3D Fix. Если 3D Fix отсутствует, то срабатывает FS по GPS, который начинает процедуру посадки или удержания высоты.

Перед настройкой необходимо еще раз проверить, правильно ли у нас работает PPM энкодер (и по необходимости обновить его прошивку). Об этом рассказывал в статье «Прошиваем PPM-encoder». Если эти действия выполнены, то можно приступать к настройке режима. При потере связи радиоуправления проверяется уровень газа — далее буду писать «FailSafe по газу».

FailSafe по газу

• Улетели слишком далеко и потерялся сигнал радиоуправления.
• Выключили передатчик.
• Потерялось питание на приемнике.
• Потерялся сигнал с третьего канала газа.
• PPM энкодер не может отправить сигнал более двух секунд в контроллер.

• Отключение моторов (дизарм) — если включен режим Stabilize или Acro и уровень газа на нуле.
• Выполняется возврат домой (RTL) — если присутствует GPS Fix и коптер находится более двух метров от точки взлета.
• Выполняется посадка (Land) — если отсутствует GPS Fix и коптер находится менее двух метров от точки взлета.
• Продолжение миссии — если включен режим Auto и установлен режим FS «Enabled_continue_in_auto_mode».
• Если уровень газа поднимается выше величины (по умолчанию 975) сработки FS, то коптер остается в текущем режиме полета (RTL, Land, Auto). Автоматическое переключение обратно в режим, в котором вы летали, не происходит! Чтобы вернуть управление себе, необходимо переключить полетный режим (сначала проверить, чтобы уровень газа был в районе 50%, чтобы аппарат не упал). Например: вы летали в режиме Stabilize, связь потерялась, сработал FS по газу и коптер полетел на точку взлета и, чтобы вернуть управление себе — необходимо переключить режим в AltHold или Loiter. После этого сможете летать дальше.

Управление режимом FailSafe можно настроить и на аппаратуре, а так же на контроллере. Для того, чтобы все работало правильно, возможно потребуется настройка и аппаратуры (Futaba) и контроллера. Если у вас аппаратура Turnigy 9x, то достаточно настроить только контроллер. Приступим к процедуре.

Первым делом необходимо снять пропеллеры ! Должны быть сняты при всех шагах настройки и проверки!

Далее необходимо включить аппаратуру, подключить контроллер APM к Mission Planner. Открываем вкладку «Initial Setup» — «Mandatory Hardware» — «FailSafe».

Видим следующее:

Здесь мы видим уровни каналов радиоуправления. нас интересует уровень третьего канала — газа. Определяем минимальное значение (у меня 980).

• Уровень сработки FS должен быть на 10 единиц ниже минимального значения газа при включенном пульте. Лучше поставить 20, т.к. сигнал аппаратуры может «плыть», тем самым возможно получить ложное срабатывание.
• Уровень должен быть на 10 единиц выше значения газа при выключенном пульте (PPM энкодер должен установить значение 900), т.е. больше 900.

Значение «FS Pwm» я установил 960. В выпадающем списке выбираем «Enabled always RTL», что означает, что будет выполняться возврат домой. Дальнейшее выполнение авто миссии разработчик не рекомендует.

Далее делаем проверки.

Проверка 1 (изменение уровня сигнала газа):

Включите передатчик, установите уровень газа на минимум и включите режим Stabilize. Уровень газа должен показывать в районе значения 1000. Значение может быть больше или меньше, но главное чтобы было минимум на 10 выше, чем «FS Pwm». Выключите передатчик и значение должно получиться как минимум на 10 меньше, чем «FS Pwm».

Проверка 2 (дизарм моторов):

При установленном режиме Stabilize сделайте арминг, но не повышайте уровень газа. Выключите передатчик. Должен сработать дизарм. При этом красный индикатор на контроллере начнет моргать и в текущей вкладке Mission Planner увидите надпись «Disarmed».

Проверка 3 (включение RTL или Land):

При установленном режиме Stabilize сделайте арминг, повысьте немного уровень газа. Выключите передатчик. Полетный режим должен переключиться в RTL (при наличии 3D Fix) или в Land (при отсутствии 3D Fix). Режим будет видно в текущей вкладке.

Проверка 4 (возврат управления):

Делаем действия теста 3 заново. Затем включите передатчик. Проверьте, что на данный момент включился режим RTL или Land. Переключите режим, например в AltHold, а потом в Stabilize. Проверьте, что данный режим отобразился.

Проверка 5 (обесточивание примника, по желанию):

При установленном режиме Stabilize сделайте арминг, повысьте немного уровень газа. Отключите провода питания приемника. Полетный режим должен переключиться на RTL или Land (как в проверке 3). Перед подключением питания на приемник необходимо обесточить контроллер APM!

Дополнительную информацию о настройке можно получить в официальной Wiki.

Кроме FS по газу также можно настроить FS при разряде батареи и пропадании связи телеметрии.

FailSafe по разряду аккумулятора

• Низкое напряжение более 10 секунд.
• Потраченная емкость аккумулятора достигла указанной (должен быть установлен модуль питания с датчиком тока).

• Отключение моторов (дизарм) — если включен режим Stabilize или Acro и уровень газа на нуле.
• Выполняется возврат домой (RTL) — если присутствует GPS Fix и коптер находится более двух метров от точки взлета.
• Выполняется посадка (Land) — во всех других случаях.

Для настройки нам потребуется открыть ту же вкладку с настройкой FailSafe («Initial Setup» — «Mandatory Hardware» — «FailSafe»). Далее включаем галочку «Battery FailSafe» и устанавливаем значение минимального напряжения «Low Battery». Напряжение рекомендуется ставить с запасом, чтобы коптер успел вернуться на домашнюю точку. Напряжение хорошо поставить из расчета: оставшиеся 3.5В на банку * количество банок.

3,5*3=10.5В. Если летаете далеко, то лучше поставить большее значение. Тут подбираете опытным путем. При наличии датчика тока можно задать значение емкости аккумулятора.

FailSafe при потере связи телеметрии

Данная настройка позволяет задать поведение коптера при потере связи телеметрии (с наземной станцией).

Включить настройку моно также на вкладке «Initial Setup» — «Mandatory Hardware» — «FailSafe».

Либо воспользоваться списком «Full Patameter List» и найти пункт «FS_GCS_ENABLE».

• 0 — FS по телеметрии отключен
• 1 — FS включен, выполняется возврат домой (RTL) при потере связи или контакта
• 2 — не выполняется возврат (RTL), если включен режим миссии (Auto), миссия продолжается

• Отключение моторов (дизарм) — если включен режим Stabilize или Acro и уровень газа на нуле.
• Выполняется возврат домой (RTL) — если присутствует GPS Fix и коптер находится более двух метров от точки взлета.
• Выполняется посадка (Land) — если отсутствует GPS Fix или коптер находится менее двух метров от точки взлета.
• Продолжение выполнения миссии — если коптер в режиме Auto и опция установлена в 2 (продолжении миссии в режиме Auto)

Если связь с наземной станцией восстанавливается, коптер продолжает полет в текущем режиме (RTL, Land, Auto). Автоматическое переключение обратно в режим, в котором вы летали, не происходит! Чтобы вернуть управление себе, необходимо переключить полетный режим (сначала проверить, чтобы уровень газа был в районе 50%, чтобы аппарат не упал). Например: вы летали в режиме Stabilize, связь потерялась, сработал FS по газу и коптер полетел на точку взлета и, чтобы вернуть управление себе — необходимо переключить режим в AltHold или Loiter. После этого сможете летать дальше.

Теперь мы настроили режим FailSafe с необходимыми нам условиями (потеря связи РУ, разряд аккумулятора, потеря связи телеметрии) и можем быть спокойны, потому что после этой настройки шанс падения уменьшился.

Update 15.09.2014: Информация от Тимура Ганиева (5timur5, 5yoda5) по проверке работы PPM энкодера и настройке FailSafe (источник).

Если вы нашли ошибку на странице, то нажмите Shift + Enter или нажмите здесь, чтобы уведомить нас.

Источник: apmcopter.ru

Принцип «Fail Fast!» в разработке приложений

В далёком 2014 году уже был перевод этой статьи Кристиана Ньюманса, но впоследствии Ньюманс удалил старую статью, существенно дополнил её и опубликовал на Медиуме. Во-вторых, вероятно, после очередных обновлений Хабра, у старого текста поехало форматирование, и читать его стало тяжело. В общем, считаю, что статье необходимо дать второй шанс.

В этой статье описан принцип «Fail Fast!». Что это? Зачем он нужен? Как этот принцип поможет нам писать лучший код?

Всякий раз, когда в запущенном приложении происходит ошибка, есть три возможных подхода к её обработке:

• Ignore! — ошибка попросту игнорируется, приложение продолжает свою работу как ни в чём не бывало.
• Fail Fast! — приложение завершается с ошибкой.
• Fail Safe! — приложение учитывает ошибку в своей работе и продолжает свою работу по наилучшему сценарию из возможных.

Какой подход является лучшим? Какой из них следует применять в приложении?

Прежде чем ответить на этот жизненно важный вопрос, давайте посмотрим на простой пример.

Допустим, нам нужно написать примитивное веб-приложение, которое будет отображаться рядом с фонтаном и показывать прохожим предупреждающее сообщение, о том, что вода в фонтане грязная. Вот код, который это делает:

Important!

Please DO NOT drink this water!

Браузер покажет нам следующее сообщение:

Теперь добавим небольшой баг. Укажем вместо после фразы DO NOT:

Please DO NOT drink this water!

Возникают два интересных вопроса:

Ответ на второй вопрос получить довольно легко. Достаточно скормить наш код браузеру. Chrome, Edge, Firefox, Internet Explorer и Safari покажут нам следующее (на момент написания статьи):

Прежде, чем читать дальше, спросите себя: «Какой подход применяют браузеры?»

Очевидно, это не «Fail Fast!», поскольку приложение не сообщило об ошибке и продолжило, как ни в чём не бывало. Да, теперь больше текста стало отображаться жирным шрифтом, но текст по-прежнему корректен, и люди из фонтана не пьют. Не о чем беспокоиться!

Хорошо, давайте добавим другой баг. Вместо мы напишем DO NOT:

Please drink this water!

Упомянутые ранее браузеры покажут нам следующее:

Ужас! Теперь программа делает прямо противоположное, и последствия этому ужасны — приложение, призванное спасать жизни, превратилось в приложение-убийцу (но, к сожалению, не в то, которое каждый из нас мечтает когда-нибудь написать).

Важно осознавать тот факт, что приведённый выше пример не является преувеличением. Существует множество реальных случаев, когда мелкие баги приводили к катастрофе — например, космический корабль «Маринер-1», взорвавшийся через несколько мгновений после старта из-за пропущенного дефиса. Дополнительные примеры смотрите в Списке багов программного обеспечения.

Как мы видим, последствия отказа от «Fail Fast!» сильно отличаются и могут варьироваться от безвредных до катастрофических.

Итак, каков правильный ответ на вопрос: «Что должно произойти?»

Это зависит от ситуации. Но есть общие правила.

Правило первое:

Никогда не игнорируйте ошибку (не применяйте правило «Ignore!») — если для этого нет действительно веских причин.

В дополнительных пояснениях это правило не нуждается. Вспомним Заповедь Шестую из «Десяти Заповедей C-разработчика»:

Если провозглашается функция, возвращающая код ошибки в трудный час, ты должен обработать ошибку, даже если это утроит твой код и вызовет боль твоих пальцев, ибо, если ты уповаешь, что «это не случится со мной», боги обязательно накажут тебя за высокомерие.

Правило второе:

На этапе разработки применяйте подход «Fail Fast!».

Обосновать это правило легко:

• Подход «Fail Fast!» помогает при отладке. При любой ошибке выполнение кода прерывается, а сообщение об ошибке помогает обнаружить её, диагностировать и исправить. Поэтому подход «Fail Fast!» помогает написать надёжный код, снижает затраты на разработку и поддержку и предотвращает катастрофы в продакшене. Даже если ошибка не приводит к серьёзному сбою, всегда лучше обнаружить её как можно скорее, поскольку стоимость багфикса растёт в геометрической прогрессии вместе со временем, прошедшим в цикле разработки (компиляция, тестирование, вывод в продакшен).
• Ошибки, возникающие на этапе разработки, обычно не приводят к серьёзным последствиям. Заказчик не жалуется, деньги не зачисляются на неправильный счёт, ракеты не взрываются.

«Fail Fast!» считается хорошей практикой в разработке ПО. Вот несколько подтверждающих цитат:

Поощряйте хорошие практики кодинга. Следствий этому много, в том числе, и «fail fast!»

— Команда Google Guava, «Объяснение философии»

Может показаться, что «немедленный и явный сбой» сделает Ваше приложение более уязвимым, но на самом деле, он сделает его более надёжным. Такие баги легче находить и исправлять, и их меньше попадёт в продакшен.

— Джим Шор, Мартин Фаулер, «Fail Fast»

Некоторые из сложнейших для выявления багов были вызваны кодом, который молча падает и продолжает работу, вместо того, чтобы выбросить исключение. Лучше выбросить исключение, как только сбой будет обнаружен.

Хенрик Варн, «18 уроков после 13 лет работы с Tricky Bugs»

Зачем ждать, пока выяснится, что что-то не работает? Сразу падайте.

— Джошуа Кериевский, «Введение в современный Agile»

Однако, ситуация может радикально измениться с выводом приложения в продакшен.

К сожалению, здесь единого правила не существует. Практика показывает, что по умолчанию лучше использовать подход «Fail Fast!». Ущерб, нанесённый приложением, которое игнорирует ошибку, обычно значительно превышает ущерб, нанесённый приложением, которое внезапно падает. К примеру, если банковское приложение падает, пользователь злится.

Но если банковское приложение отображает неправильный баланс, пользователь очень злится. «Злой» лучше, чем «очень злой». Поэтому, лучше использовать «Fail Fast!».

В нашем примере с HTML-кодом подход «Fail Fast!» так же более оправдан. Предположим, что вместо сообщения браузеры выводили бы сообщение об ошибке. Разработчики сразу бы узнали о проблеме и быстро её исправили. Но даже если глючный код по каким-то причинам попадёт в продакшен, последствия будут не так уж и страшны. Призыв «Please drink this water» может иметь катастрофические последствия, в то время, как отсутствие сообщения вообще или отображение непонятной ошибки приведёт к тому, что очень малый процент прохожих выпьют воду из фонтана.

На практике же, каждый конкретный случай требует индивидуального подхода. И это особенно касается приложений, способных нанести большой ущерб — например, в медицинских, банковских приложениях или приложениях для захвата космоса. Применение «Fail Fast!» обосновано ровно до того момента, пока наша ракета не начала взлетать. Как только произошёл старт, остановить приложение (или, хуже того, проигнорировать ошибку) уже не вариант. Тут в свои права вступает подход «Fail Safe!».

Иногда хороший вариант: упасть, но минимизировать ущерб. К примеру, когда падает ваш текстовый редактор, он сначала сохраняет текущий файл во временный, затем показывает пользователю сообщение: «Бла-бла-бла, Ваши изменения были сохранены во временный файл abc.temp», отправляет отчёт об ошибке разработчикам, и только потом падает.

Отсюда третье правило:

В критических приложениях подход «Fail Safe!» должен быть реализован для того, чтобы свести к минимуму ущерб.

Подведём итог.

• На этапе разработки используем только «Fail Fast!».
• В продакшене: по умолчанию используем «Fail Fast!»; критически важные приложения, несущие риск большого ущерба в случае сбоя, нуждаются в индивидуальном, зависящем от контекста и исключающем (или минимизирующем) ущерб поведении. В отказоустойчивых системах должны применяться подходы «Fail Safe!» и «React Appropriately!» («Реагируйте адекватно!»)

Та же идея выражена в великолепном «Правиле исправления» книги «Искусство программирования Unix» Эрика Стивена Реймонда:

Исправляйте всё, что можно — но если нужно упасть, падайте громко и как можно скорее.

В любом случае, очень полезно использовать среду разработки, поддерживающую принцип «Fail Fast!». К примеру, его поддерживают компилируемые языки, поскольку компиляторы сообщают об ошибках компиляции. Вот пример глупой ошибки, которая ускользает от человеческого глаза, но может привести к бесконечному циклу:

var row_index = 1 . row_indx = row_index + 1

Подобные опечатки легко обнаруживаются приличным компилятором или (что ещё лучше) интеллектуальной IDE.

К счастью, существует огромное количество «Fail Fast!»-фич, встроенных в язык. Все они основаны на правиле:

Ошибки необходимо обнаруживать во время компиляции или как можно раньше во время работы приложения.

Вот примеры мощных «Fail Fast!» языковых фич: статическая и семантическая типизация, null-safety при компиляции, дженерики, встроенное модульное тестирование и так далее.

Но чем обнаруживать ошибки на ранней стадии, лучше не допускать их по замыслу. Это достигается, когда язык программирования не поддерживает уязвимые методы программирования — к примеру, глобальные изменяемые данные, неявная типизация, молчаливое игнорирование арифметических ошибок переполнения, достоверность (например, «», 0 и null равны false) и так далее.

Поэтому всегда нужно отдавать предпочтение окружению (языки программирования / библиотеки / фреймворки / инструменты), которое поддерживает принцип «Fail Fast!». Нам придётся меньше заниматься отладкой, а наш код будет надёжнее и безопаснее за меньшее время.

• программирование
• принципы разработки

• Программирование
• IT-стандарты

Источник: habr.com