Был ли Boost когда-либо использован в регулируемом проекте (FDA, FAA)?

Ответ 1

Я бы сказал, что много, если дело доходит до того, как проектировщик системы обрабатывает безопасность системы на архитектурном уровне.

утроение

Например, если подход будет трехкратным резервированием с доверенным избирателем, то системные испытания/тестирование станут основным шагом в утверждении реализации. Предположим, что одна из команд развития трех игроков выбрала Boost. Если система в целом передала все свои тестовые векторы, можно было бы утверждать, что не нужно тралить через Boost, ища ошибки реализации. Очевидно, что если бы все три тройки выбрали использовать Boost, это могло бы вызывать беспокойство, потому что тогда объем тестовых векторов становится неуправляемым.

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

Важно, но не критически важно

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

Например, автомобильная промышленность имеет набор правил программирования под названием MISRA. Предполагается, что программное обеспечение для системы ABS будет записано в этот набор правил, а средства разработки должны быть установлены для обеспечения соблюдения этих правил в исходном коде. Идея заключается в том, что это уменьшит риск необнаруженных ошибок до приемлемого уровня. И поскольку в конечном счете есть водитель, управляющий автомобилем, они всегда могут делать свое собственное каденционное торможение. И, таким образом, автомобильная промышленность избегала трехкратной реализации ABS.

Они распространяют одну и ту же философию на более сложные автомобильные системы, такие как адаптивный круиз-контроль и автомобили для самостоятельного вождения. Лично я считаю, что такое расширение необоснованно для самостоятельных автомобилей. Соответствующее законодательство дает понять, что это вина водителей, если у такого транспортного средства произошел сбой (т.е. Вы все еще "возили" его), но глянцевая реклама не будет останавливаться на этом важном аспекте.

Это то же самое в мире медицинских устройств; там должна быть медсестра или кто-то, кто наблюдает за пациентом, так что случайный клип покрывается этим наблюдением. В любом случае все это очень плохо; в то время как программное обеспечение для медицинского устройства, возможно, было написано протестированным и утвержденным, нередко это происходит во встроенной Windows XP. Они все подключаются к сети и в конечном итоге заражаются компьютерными вирусами и т.д. FDA не позволит вам иметь систему автоматического обновления на месте, только поставщик оборудования может ее обновить, и, конечно же, они никогда не смогут рассчитывать на, Таким образом, вы получаете хорошо написанное хорошо проверенное и хорошее медицинское программное обеспечение, работающее поверх установки ОС, в которой все мировые хакеры бегали внутри нее, и бог знает что. Я думаю, что использование Boost в этих обстоятельствах не будет сильно влиять на общий системный риск.

Итак, если совместимая с MISRA инструментальная цепочка предложила Boost как часть этой инструментальной цепочки, тогда я не понимаю, почему это будет отличаться от инструментальной цепочки, предлагающей стандартную библиотеку C. Если поставщик инструментальной цепочки сертифицирует его, то он ничем не отличается от ситуации ни с чем другим.

Есть недостатки в этом подходе. По моему опыту я столкнулся с цельной инструментальной цепочкой, совместимой с MISRA, в широко распространенном использовании, компилятор которой оказался кодом нежелательных объектов, когда все оптимизации были включены. Я действительно смог проверить это при разборке. Затем я взглянул на исходный код стандартной библиотеки C инструментальных цепей, и он, очевидно, сам по себе не был записан в набор правил MISRA, а кроме того, он содержал вопиющие и ужасные ошибки.

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

Критическая безопасность без трипликации

Окончательный подход - это не трехкратное и не наблюдение за человеком. Это действительно сложно, потому что тогда вам нужно формальное подтверждение правильности каждого компонента цепочки инструментов, ОС, драйверов, чипов и т.д. AFAIK никогда не выполнялся для действительно критически важной для безопасности системы, такой как ядерные реакторы, авионика управления полетом или другие системы, которые действительно будут убивать людей, если они ошибаются.

Единственное, что можно сказать, это набор компиляторов Greenhill и их операционная система INTEGRITY. Они могут предоставить вам (за большую плату) формальные доказательства тестирования и проверки для каждой отдельной строки ОС, всех их библиотек и их компилятора, все. Если бы кто-нибудь когда-либо пытался создать действительно критическую для безопасности систему без трехкратного умножения, это было бы отправной точкой.

Я не думаю, что они уже сделали С++ 11, хотя я добавил Boost в свою инструментальную цепочку, и он работал отлично (это не было в критичной для безопасности системе, которую я спешу добавить).

Заключение

Конечно, если наряды, такие как Greenhills с заслуженной и хорошей репутацией надежных и тщательно протестированных инструментальных цепей, предлагают Boost, тогда я думаю, что можно было бы использовать его в регулируемой системе. Однако я сомневаюсь, что весь Boost будет предложен таким образом; они с большей вероятностью следуют стандартам компилятора.

Я также знаю, что GCC в прошлом подвергался формальному тестированию проверки компилятора, чтобы его можно было использовать в Stuff That Matters. Я ожидаю, что это будет повторено раньше, для более поздних воплощений, которые взяли на себя аспекты Boost.

Ответ 2

Думаю, лучший ответ, который у нас есть, - "да и нет". Я попытаюсь объяснить, почему.

Boost - огромный зонтик для многих составных библиотек. Некоторые из них зависят друг от друга различными способами (например, когда библиотека более высокого уровня нуждается в функциях, предоставляемых более низкоуровневой частью Boost типа Type Traits). Это вызывает вопросы о полезности простого ответа на вопрос, потому что, если три компонента Boost использовались в регулируемом проекте, но они являются разными частями, чем вы хотите использовать, то это не имеет большого значения, чтобы знать это. И мы никогда не узнаем полного ответа на все части, потому что вы не можете доказать отрицательный (и слишком много частей, чтобы когда-либо ожидать ответа "100% да" ).

Boost (и всегда был) быстро развивается. Все новые библиотеки добавляются все время. ASIO - это большая, которая вообще не существовала до недавнего времени. Это затрудняет ответ на этот вопрос, потому что со временем есть части Boost, которые молоды и не так хорошо протестированы, как другие. Кроме того, существующие библиотеки иногда проходят обратно-несовместимые версии (например, "Boost Filesystem 3" не так давно).

Многие части Boost заканчиваются проектами не традиционной зависимостью, а скорее копированием кода из Boost и, возможно, его модификацией по вкусу (например, добавлением или удалением поддержки для определенных компиляторов). Аналогичным образом, многие части Boost оказываются в проектах благодаря тому, что Boost является своеобразной пробной площадкой для многих новых стандартных функций библиотеки С++, таких как shared_ptr (С++ 11) и unordered_map (TR1). Некоторые функции, которые сегодня являются частью языка, были частью Boost, поэтому многие люди использовали "Boost code", даже не зная об этом.

Обратите внимание, что код не становится более безопасным при переходе к официальному статусу в языке - у GCC были ошибки, которых не было в эквивалентных реализациях Boost тех же понятий. Это имеет значение при рассмотрении таких практических вопросов, как "Должны ли мы разрешить использование Boost в нашем проекте или мы должны ограничиться тем, что дает нам поставщик компилятора"? Если вы думаете об использовании функции, которая была реализована совсем недавно вашим компилятором (скажем, в течение прошлого года), вам может быть лучше использовать стороннюю (например, Boost) реализацию, которая более зрелая.

Наконец, поскольку кажется, что импульс для этого вопроса состоит в том, чтобы получить некоторую уверенность в том, что использование Boost - не плохая идея для производственного проекта: я бы, конечно, сказал, что в целом использование Boost прекрасное и хорошее, с огромным оговоркой что вам нужен локальный эксперт в Boost, который знает, какие части Boost не должны использоваться в вашем домене. Например, Boost Spirit, Phoenix и Wave являются примерами библиотек, которые были в Boost на некоторое время, но которые очень немногие действительно понимают, понимают. Одно дело использовать библиотечный код, который вы не полностью понимаете (все мы делаем), но совсем другое - использовать код, который практически никто не понимает на земле.

В целом, я не думаю, что кто-то сможет дать вам уверенность в том, что вы ищете, чтобы Boost был в порядке для критически важных систем. Вам необходимо оценить его самостоятельно, так же, как вам нужно оценить собственное программное обеспечение поставщика компилятора, ваши другие сторонние зависимости и код, который вы пишете сами. Я использовал все четыре категории программного обеспечения довольно много, и по моему опыту у Boost было меньше критических ошибок, чем у любого другого, и меньше регрессий, чем GCC или мой собственный код.