Был ли Boost когда-либо использован в регулируемом проекте (FDA, FAA)?
Публикуя комментарий недавно, я заметил, что, по моему опыту, Boost не широко используется в регулируемых отраслях (FDA, FAA). На самом деле, я не знаю ни одного проекта, который бы его использовал или использовал. Я понимаю, однако, что мой опыт здесь может не хватать, поэтому я хотел бы знать, если кто-нибудь имел знания о проекте с использованием наддува в медицинском устройстве или в авиационной системе полета (освещение, управление кабиной, оборудование кабины и т. д.).
Я не уверен, что это правильное место, чтобы спросить его (может быть, какой-то другой сайт SO), но я подумал, что это было бы хорошим местом для начала.
Вопрос не в том, следует ли использовать повышение в этих областях, а в том, чтобы кто-нибудь знал, использовался ли он.
РЕДАКТИРОВАТЬ Некоторые примеры проектов, которые могут помочь прояснить это: системы освещения салона самолета, системы управления кабиной, контрольно-измерительные приборы в кабине, инфузионные / пищевые / инсулиновые насосы, диализные аппараты, лабораторные диагностические устройства, системы сбора данных о центрах крови и т. Д. критические, некоторые собирают данные, некоторые собирают данные, используемые для принятия медицинских решений, и т. д., но я считаю, что все охвачены как регулируемые устройства FAA / FDA.
РЕДАКТИРОВАТЬ Внешние (не входящие в цепочку разработки) библиотеки часто включаются в проекты такого типа для других целей (графические библиотеки, драйверы, USB-стеки и т. Д.). Они рассматриваются как СУП. Использование надстройки подпадает под этот подход. Кто-нибудь знает о проекте, где Boost был использован таким образом?
РЕДАКТИРОВАТЬ Boost — это очень большая структура с несколькими компонентами. Я ищу любую его часть, которая была использована в проекте. Например, «Boost smart pointers» или «Boost Enable» или «Boost Array» или «Boost Optional» и т. Д. Но используется в «целом», а не в части. Не используется, глядя на код Boost и повторно используя идею; используется в качестве целого компонента системы (то есть в юридическом смысле).
Это имеет ключевое значение для вопроса, потому что использование таким образом означает, что необходимо найти компромисс с обработкой SOUP. Это может поставить этот вопрос за рамки этого SO сайта … не уверен.
Решение
Я бы сказал, что многое, если это сводится к тому, как разработчики систем управляют безопасностью системы на архитектурном уровне.
утроение
Например, если принятый подход является трехкратным резервированием с доверенным избирателем, то системные испытания / тестирование станут основным шагом в утверждении реализации. Предположим, что одна из разработчиков трех экземпляров решила использовать Boost. Если бы система в целом прошла все свои тестовые векторы, то можно было бы утверждать, что не нужно проходить через сам Boost в поисках ошибок реализации. Очевидно, что если бы все три тройки решили использовать Boost, то это было бы поводом для беспокойства, потому что тогда область действия тестовых векторов становится неуправляемой.
Трипликация — это стандартный подход к решению проблемы использования программных ресурсов, таких как компиляторы, библиотеки и программисты, которые все подвержены риску ошибки. Повышение это просто еще один из них. Можно утверждать, что общие указатели Boost явно снижают риск ошибок программиста. Это в раунде, скорее всего, будет выгодно для системы в целом.
Важно, но не критично для безопасности
Интересно, когда трипликация не используется, и сейчас нужно действительно доверять вещам. Интересно, что многие системы пытаются обойти проблему, говоря о том, что в конечном итоге все контролирует человек, который может вмешаться в случае системной ошибки.
Например, в автомобильной промышленности есть набор правил программирования, называемых MISRA. Предполагается, что программное обеспечение для системы ABS написано для этого набора правил, а средства разработки должны быть установлены для обеспечения соблюдения этих правил в исходном коде. Идея состоит в том, что это снизит риск необнаруженных ошибок до приемлемого уровня. И поскольку в конечном итоге за рулем находится водитель, они всегда могут сделать свое собственное торможение. И, таким образом, автомобильная промышленность избежала трехкратного внедрения ABS.
Они распространяют ту же философию на более сложные автомобильные системы, такие как адаптивный круиз-контроль и автомобили с самостоятельным вождением. Лично я считаю, что такое расширение нецелесообразно для самостоятельного вождения авто. В соответствующем законодательстве четко указывается, что в случае аварии на таком транспортном средстве (то есть, вы все еще «едете») виновата «вина» водителя, но глянцевая реклама не будет останавливаться на этом важном аспекте.
То же самое в мире медицинских приборов; в любом случае должна быть медсестра или кто-то, кто следит за пациентом, поэтому случайное сообщение покрывается этим наблюдением. Все это очень плохо в любом случае; в то время как программное обеспечение для медицинского устройства может быть написано протестировано и одобрено, довольно часто эти вещи работают на встроенной Windows XP. Все они подключаются к сети и в конечном итоге заражаются компьютерными вирусами и т. Д. FDA не позволит вам иметь систему автоматического обновления на месте, ее может обновлять только поставщик устройств, и, конечно, они не могут надеяться, что она будет работать. , Таким образом, в итоге вы получите хорошо написанное, хорошо протестированное и хорошее медицинское программное обеспечение, работающее поверх установки ОС, в которой все хакеры мира бегают по ней и, черт возьми, знают что. Я думаю, что использование Boost в этих условиях не сильно увеличит общий системный риск.
Так что, если MISRA-совместимый набор инструментов предлагает Boost как часть этого набора инструментов, тогда я не понимаю, почему это будет отличаться от набора инструментов, предлагающего стандартную библиотеку C. Если поставщик инструментария сертифицирует его, это ничем не отличается от ситуации с чем-либо еще.
У этого подхода есть недостатки. По своему опыту я часто встречал MISRA-совместимую цепочку инструментов, чей компилятор выдавал ненужный объектный код, когда все оптимизации были включены. Я действительно смог проверить это при разборке. Затем я взглянул на исходный код стандартной библиотеки C инструментальных цепочек, и он явно не был записан в набор правил MISRA, и, кроме того, он содержал вопиющие, ужасные ошибки.
И все же нет никакого нормативного блока для создания, тестирования и продажи автомобильной системы ABS с использованием этой цепочки инструментов, если вы установите флажок MISRA в настройках проекта. Добавление Boost в этот набор инструментов вряд ли ухудшит ситуацию.
Безопасность критична без трехкратного дублирования
Последний подход — это не тройное дублирование и не человеческий контроль. Это действительно сложно, потому что тогда вам нужно формальное подтверждение правильности каждого компонента цепочки инструментов, ОС, драйверов, микросхем и т. Д. AFAIK Это никогда не делалось для действительно критически важной системы безопасности, такой как ядерные реакторы, авионика управления полетом или другие системы, которые действительно убьют людей, если они пойдут не так.
Насколько я могу судить, единственное, что может быть близко, это набор компиляторов Гринхилла и их операционная система INTEGRITY. Они могут предоставить вам (за большую плату) официальные доказательства тестирования и проверки для каждой отдельной строки ОС, всех их библиотек и их компилятора, всего. Если бы кто-то попытался создать действительно критически важную для безопасности систему без тройного дублирования, это было бы отправной точкой.
Я не думаю, что они сделали C ++ 11, хотя я добавил Boost к их цепочке инструментов, и она работала просто отлично (это не было в критической системе безопасности, которую я спешу добавить).
Заключение
Конечно, если такие наряды, как Greenhills с заслуженной и хорошей репутацией надежных и тщательно протестированных наборов инструментов, предлагают Boost, то я думаю, что можно было бы использовать его в регулируемой системе. Однако я сомневаюсь, что весь Boost будет предложен таким образом; они более склонны следовать стандартам компилятора.
Я также знаю, что в прошлом GCC проходил формальную проверку компилятора, чтобы его можно было использовать в Stuff That Matters. Я ожидаю, что это повторится рано или поздно для более поздних воплощений, которые приняли аспекты Boost.
Другие решения
Я думаю, что лучший ответ, который мы можем получить здесь, это «да и нет». Я постараюсь объяснить, почему.
Повышение является огромным зонтиком для многих составляющих библиотек. Некоторые из них зависят друг от друга по-разному (например, когда библиотеке более высокого уровня требуются функции, предоставляемые частью Boost более низкого уровня, такой как Type Traits). Это поднимает вопросы о полезности простого ответа на вопрос, потому что, если три части Boost были использованы в регулируемом проекте, но они являются частями, отличными от тех, которые вы хотите использовать, знать об этом немаловажно. И мы никогда не узнаем полный ответ по всем частям, потому что вы не можете доказать отрицательный результат (и слишком много частей, чтобы ожидать ответа «100% да»).
Повышение (и всегда было) быстро развивается. Абсолютно новые библиотеки добавляются все время. ASIO — это большой продукт, которого не было до недавнего времени. Это затрудняет ответ на этот вопрос, потому что со временем появляются компоненты Boost, которые являются молодыми и не так хорошо проверены, как другие. Кроме того, существующие библиотеки иногда проходят через несовместимые версии (например, «Boost Filesystem 3» не так давно).
Многие части Boost заканчиваются в проектах не традиционной зависимостью, а скорее копированием-вставкой кода из Boost и, возможно, изменением его по вкусу (например, добавление или удаление поддержки определенных компиляторов). Точно так же многие части Boost заканчиваются в проектах благодаря тому факту, что Boost является своего рода испытательным полигоном для многих новых функций стандартной библиотеки C ++, таких как shared_ptr (C ++ 11) и unordered_map (TR1). Некоторые функции, которые сегодня являются частью языка, изначально были частью Boost, поэтому многие люди использовали «Boost code», даже не подозревая об этом.
Обратите внимание, что код не становится более безопасным, когда он переходит к официальному статусу в языке — в GCC были ошибки, которых не было в эквивалентных реализациях Boost с теми же концепциями. Это имеет значение при рассмотрении практических вопросов, таких как «Должны ли мы разрешить использование Boost в нашем проекте или мы должны ограничиться тем, что дает нам поставщик компиляторов?» Если вы думаете об использовании функции, которая была реализована совсем недавно вашим поставщиком компиляторов (скажем, в течение прошлого года), вам может быть лучше использовать стороннюю (например, Boost) реализацию, которая является более зрелой.
Наконец, поскольку кажется, что стимулом для этого вопроса является получение некоторой уверенности в том, что использование Boost не является плохой идеей для производственного проекта: я бы, конечно, сказал, что в целом использование Boost — это хорошо и хорошо, с огромным предостережением, которое вам нужно местный эксперт по Boost, который знает, какие части Boost не должны использоваться в вашем домене. Например, Boost Spirit, Phoenix и Wave являются примерами библиотек, которые были в Boost некоторое время, но которые очень немногие действительно глубоко понимают. Одно дело использовать библиотечный код, который вы не совсем понимаете (мы все понимаем), но совсем другое — использовать код, который почти никто не понимает.
Таким образом, я не думаю, что кто-либо сможет дать вам заверение, что вы ищете, что Boost подходит для систем, критичных для безопасности. Вы должны оценить его самостоятельно, так же, как вам нужно оценить программное обеспечение вашего собственного производителя компилятора, ваши сторонние зависимости и код, который вы пишете сами. Я довольно часто использовал все четыре категории программного обеспечения, и по моему опыту Boost имел меньше критических ошибок, чем любые другие, и меньше регрессий, чем GCC или мой собственный код.